0:00 0:00
記事
Claude Codeで安全にコミットとPRを作るワークフロー：差分確認・粒度・秘密情報チェックまで
Claude Codeが生成したコードをGitで安全に管理するための、差分確認・コミット粒度・PR説明・gh CLI連携・秘密情報チェック・/reviewと/security-reviewの使い分けまで、実務で回せる手順としてまとめます。
結論：Claude CodeのGit運用は「人間が必ず差分を読む」前提で組む
Claude Codeはgitコマンドもghコマンドも自分で叩けます。便利な一方で、**「Claudeがコミットして、Claudeがpushして、Claudeがレビューして、Claudeがマージする」**まで自動化してしまうと、AIが書いたバグや秘密情報をそのまま本番に流す危険があります。
安全に回すには、次の5ステップを毎回守るのが最短です。
- 作業用ブランチを切る（
mainに直接コミットさせない） - コミット前に
git diffを必ず読む（Claudeに要約させるのではなく自分で読む） - 1コミット=1意図に分ける（リファクタと機能追加を混ぜない）
gh pr createでPRを開く（CIの目を通してからレビュー）- マージ前に
/reviewまたは/security-reviewを当てる（人間レビューと併用）
この記事では、それぞれの手順をコピペで叩けるコマンドと依頼文で示します。CLI操作の全体像はClaude Codeの基本コマンドと日常的に使う操作まとめ、最初の機能追加の通しはClaude Codeで最初の小さな機能追加をする手順で扱っているので、本記事はGit／PRに特化します。
前提：gh CLIを入れて認証しておく
Claude CodeはGitHub APIに直接当たることもできますが、未認証だとレート制限にすぐ引っかかります。公式のBest Practicesも明示的に**「gh CLIを入れることを強く推奨」**としています。
brew install gh gh auth login WindowsやLinuxでもGitHub CLI公式に手順があります。認証後にgh repo viewが通れば準備完了です。
STEP1: 作業用ブランチを切らせる
mainに直接コミットさせないために、最初の依頼で必ずブランチを切らせます。CLAUDE.mdの「Git／PRルール」に書いておくのが理想ですが、毎回明示しても問題ありません。
これから {{機能名}} を実装する。
最初に作業用ブランチ feat/{{short-name}} を切ってから始めて。
main では作業しない。ブランチ命名規則（feat/、fix/、chore/）もCLAUDE.mdテンプレート完全版に書いておくと、毎回指定する必要がなくなります。
STEP2: コミット前にgit diffを自分で読む
Claudeに「変更を要約して」と頼むと人間が読まなくなるのが一番危険です。コミット前に必ず自分の手でターミナルから差分を見てください。
git diff git diff --stat ファイル数だけ確認したいときは--stat、全体を読むときは--statの後にファイル名を絞ってgit diff <path>が便利です。
Claudeに差分の要約をさせるなら、検証可能な形で頼む
要約自体は便利なので、「自分で読むことの代わり」ではなく「読んだ後の確認」として使います。
今回の変更を、次のフォーマットで要約して。
- 触ったファイル一覧（フルパス）
- 各ファイルで何を変えたか（1ファイル1〜2行）
- 触っていないが影響を受けそうなファイル
- 想定外の追加（依存パッケージ、設定ファイル、生成物）があれば列挙「想定外の追加」を列挙させることで、勝手にライブラリを追加していないか・設定をいじっていないかが見えやすくなります。
STEP3: 1コミット=1意図に分ける
Claudeは放っておくと機能追加・リファクタ・テスト追加・整形を1コミットに混ぜます。レビュー時に切り分けが難しくなるので、コミット粒度は明示的に依頼してください。
今の変更を、意味の単位で複数コミットに分けて。
1コミット=1意図にする。順序は次のとおり。
1. リファクタ（API不変。挙動を変えない範囲）
2. 機能追加（新しい仕様）
3. テスト追加（上の機能用）
各コミットメッセージは命令形・1行目72文字以内で書く。
コミット前に`git status`で意図したファイルだけがステージされているか確認する。git add -pをClaudeに使わせるとhunk単位で分けられます。一気にステージするより、コミットメッセージと一緒にレビューできる粒度の方が後で痛みが少ないです。
コミットメッセージ規約はCLAUDE.mdに集約
Conventional Commitsを使うなら次の1行をCLAUDE.mdに書いておくだけで揃います。
## Git
- コミットメッセージは Conventional Commits 形式
例: feat(auth): add OAuth callback handler
- 1行目72文字以内、命令形、ピリオドなしSTEP4: gh pr createでPRを開く
ブランチが揃ったら、PR作成はghに任せます。Claudeに「PR作って」と言うだけで体裁が整うように、PRテンプレをCLAUDE.mdに書いておくのが効きます。
## PRテンプレ
gh pr create --fill しない。次のテンプレで本文を生成すること。
### 概要
{{1〜3文で何をしたか}}
### 影響範囲
- 触ったレイヤー
- 既存挙動への影響（破壊的変更の有無）
### 確認手順
1. ローカルで `npm run dev`
2. {{確認URL／操作}}
3. 期待結果
### スクリーンショット（UI変更時のみ）
### 残課題 / TODO依頼文側はシンプルにします。
今のコミット群でPRを開いて。
本文は CLAUDE.md の「PRテンプレ」に従って書いて。
ベースブランチは main。gh pr createでPRを作るとそのセッションがPRに自動で紐付くので、後からclaude --from-pr <number>で同じ文脈を呼び戻せます。レビュー対応にそのまま入れる動線です。
STEP5: マージ前に/reviewと/security-reviewを当てる
Claude Codeには公式の組み込みコマンドとして/reviewと/security-reviewが用意されています。人間レビューの代わりではなく、人間が見落としやすい点を機械的に拾うための補助として使ってください。
| コマンド | 役割 | 主に拾える観点 |
|---|---|---|
/review | コード品質レビュー | 命名・重複・テスト不足・読みづらさ |
/security-review | セキュリティレビュー | SQL／XSS／コマンドインジェクション、秘密情報、認可漏れ |
PR詳細をClaudeに読ませた状態で、
/reviewまたは
/security-reviewと打つだけです。指摘が出たらClaudeに修正させる前に内容を吟味してください。/security-reviewの指摘は誤検知も混ざりますが、秘密情報のコミットだけは絶対に潰す価値があります。
人間が見るべき観点は、AIに任せきれない次の3カテゴリに絞ると効率的です。
- 設計判断：このレイヤーで持つべき責務か、別の場所に置くべきか
- UX影響：操作・表示・URL構造が壊れていないか
- 依存追加：本当に必要なライブラリか、ライセンス・メンテ状況は許容できるか
秘密情報チェックは多重に
Claude Codeは賢いですが、秘密情報を絶対に漏らさないわけではありません。多重チェックで防ぎます。
1. CLAUDE.mdの禁止事項に明記する
## 禁止事項
- ❌ APIキー・トークン・個人情報をコミットする
- ❌ .env / .env.local / credentials.json をコミットする
- ❌ ログ出力に秘密情報を含める
- ❌ コミットする前にこれらが含まれていないか必ず確認する2. .gitignoreを堅くする
.env
.env.local
.env.*.local
*.pem
*.key
secrets/
credentials.json3. ローカル＋CIでシークレットスキャナを走らせる
gitleaksやtrufflehogをpre-commitやCIに入れておくと、Claudeがうっかり混入させても弾けます。Claude任せにしない最後の砦として組み込んでおいてください。
4. 万が一漏らしたら：履歴ごと消す
コミット履歴に秘密情報が入ったら、**該当キーを必ず無効化（ローテート）**したうえでgit filter-repoなどで履歴から削除します。pushしてしまった後はリモート側にも残るので、ローテートが最優先です。
「Claudeに勝手にpushさせない」を守る
ここまでの手順を守っても、git pushを勝手に走らせると取り戻すコストが跳ね上がります。次のいずれかの方法で抑えてください。
- 依頼文に「pushはしない、私が判断する」と毎回書く
CLAUDE.mdの禁止事項に「main / develop への直接 push 禁止」を入れる- 権限設定で
Bash(git push *)を承認必須にする（/permissionsで確認） - どうしても自動化したいときは
feat/ブランチへのpushだけ許可ルールを作る
特にgit push --forceは破壊的なので、main／developに対しては絶対に許可しないのを明文化しておくのが安全です。
ロールバックの選択肢を覚えておく
Claudeに任せていると一気に5〜10ファイル変更ということが普通に起きます。間違ったら戻せる手段を3つ持っておくと安心です。
| 状況 | 戻し方 |
|---|---|
| まだコミットしていない変更を消したい | git restore <path> または git checkout -- <path> |
| 直前のコミットを取り消す（変更は残す） | git reset --soft HEAD^ |
| Claudeが行った変更だけ巻き戻したい | Esc + Esc または /rewind でチェックポイントから復元 |
/rewindはClaudeの会話とコードの状態の両方を復元できます。会話だけ戻したい・コードだけ戻したい・両方戻したいを選べるので、「コードはコミット済みだが会話だけ戻したい」ようなケースにも使えます。ただし公式の警告どおり、/rewindはClaudeが触った変更しか追跡しないので、gitの代わりにはなりません。コミット運用と併用してください。
安全運用のチェックリスト
PRを出す前に、必ず次を確認してください。
- 作業用ブランチで作業している（mainではない）
-
git diffを自分の目で読んだ - コミットが意図単位で分かれている（リファクタと機能追加が混ざっていない）
- 依存追加・設定変更がコミットメッセージで説明されている
-
.envや秘密情報がgit statusに出ていない - テスト・型チェック・lintがローカルで全て通っている
- PR本文が
CLAUDE.mdのPRテンプレに沿っている -
/reviewまたは/security-reviewを当てて指摘を確認した - 破壊的変更がある場合、PR本文と
CLAUDE.md「壊してはいけないUX」を更新した -
git pushは自分の判断で実行した（Claudeに任せていない）
ここまで習慣化すれば、Claude Codeに開発の大半を任せてもGitリポジトリは健全に保てるはずです。
次に読む
- Claude Codeで最初の小さな機能追加をする手順 — Git運用の前段、依頼から実装までの通し
- CLAUDE.mdテンプレート完全版 — Git／PRルールを集約する場所
- Claude Codeで既存コードを壊さずリファクタリングする依頼文 — リファクタを別コミットに切り分ける書き方
