Claude Codeでgit diffをレビューする方法｜変更内容を確認してから反映する

Claude CodeにGitの要約を頼んでも、最後に変更を取り込む前のdiffは自分で確認します。要約は全体像をつかむのに便利ですが、fileごとの意味、意図しない削除、既存WIPとの混在、secretの混入までは短い文章だけで判断できません。作業前の状態と現在の差分を比べ、変更目的・影響・検証結果がつながっているか確認します。

AnthropicのCommon workflowsではpull request作成を補助する流れも紹介されていますが、ClaudeがPRを作成できることと、変更が安全であることは別です。commitやPRを作る操作はreviewの後に置き、repository固有のapprovalやrelease手順に従います。

まずstatusで比較対象を決める

diffを読む前にworking treeの状態を把握します。Gitにはtracked変更、staged変更、untracked fileなど複数の状態があります。unstaged diffだけではstaged内容が含まれず、untracked fileの内容も通常のdiffへは出ません。確認範囲を分けて見ます。

表は横にスクロールできます

状態	見るもの	注意点
Tracked・unstaged	HEADとの差分	まだindexへ追加していない
Staged	indexとHEADの差分	cached diffで確認
Untracked	新規file一覧と必要な内容	自動でcommit対象にはならない
Deleted	削除fileと参照先	意図しない場合は復旧前に原因確認
Generated	元dataと生成時刻・semantic diff	timestampだけの差か判断

変更前にcleanだったか、既存WIPがあったかも重要です。作業開始時のstatusやdiff記録がないなら、現在の差分すべてを今回の作業由来と推定せず、fileごとに履歴と内容を調べます。

File一覧から目的外の差分を探す

最初にfile名と変更量を確認して、変更の広がりを見ます。想定したfeatureに関係するsource、test、docs以外に、lockfileやgenerated output、credential、backup、debug artifactが含まれていないか調べます。

表は横にスクロールできます

確認	問い
Path	このfileが変わる必要を説明できるか
Scope	共通設定や複数routeへ波及していないか
Added files	一時file、local config、secretが混ざっていないか
Deleted files	明示された削除か、参照先を壊さないか
Large diff	format一括変更や生成物の差か

file名だけでは分からないときは、diffの中身へ進みます。変更理由を説明できないfileは、すぐ削除せず、今回の作業前から存在したかを確認します。user-owned WIPを誤って戻すとdata lossになるためです。

Diffはbehaviorの単位で読む

一行ずつ眺めるだけでなく、入力、処理、出力、error pathがどう変わるか追います。関数名やコメントが変更意図と一致するか、callerが新しい契約に対応しているか、testが実際のbehaviorを確かめているかを確認します。

このdiffを、変更fileごとに説明してください。各fileについて、目的、変わるbehavior、呼び出し元、失敗時の影響、対応するtestを示してください。diffに現れない前提は推測せず、未確認として挙げてください。修正やcommitはまだ行わないでください。

「差分を要約」だけでなく、守るべきinvariantを渡すとreviewが具体的になります。例：既存API responseを維持、既存記事URLを変更しない、失敗時に部分更新しない、権限境界を広げない、などです。

高riskの変更を重点的に見る

すべての行を同じ深さでreviewする必要はありません。認証、権限、外部入力、database、金額、個人情報、削除、redirect、production configなど、誤りの影響が大きい部分を優先します。

表は横にスクロールできます

Risk	確認例
Access / auth	他userのdataを読めないか、fail closedか
Data write	retry・二重実行・partial failureに耐えるか
External input	validation、encoding、size制限があるか
File / shell	path traversal、意図しない削除、command injection
Routing	redirect loop、未知route、canonical
Secrets	envやtokenをlog・artifactへ含めていないか
Test	assertionを弱めて問題を隠していないか

ここで見つけた「気になる」はfindingと分けます。具体的な入力、変更行、期待behavior、影響、再現方法が説明できない場合は、未確認riskとして扱い、確定bugと混ぜません。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  Claude Code

  公式サイトを見るTool詳細を見る比較を見る

Claude Codeのreview結果を検証する

reviewを依頼するときは、対象diffのbaseと観点を指定します。無関係な全repositoryを「全部レビュー」と頼むより、今回の変更が守る契約を示す方が、確認可能な結果になります。

このbranchの変更だけをreviewしてください。各findingにはfileとline、成立する前提、ユーザー影響、根拠となる実装経路を付けてください。重大度を分け、問題がない場合もreview範囲と未確認条件を示してください。実装変更は行わないでください。

findingが返ったら、該当fileとcallerへ戻り、条件が本当に成立するか調べます。別案を提案するだけでなく、testを追加して再現するか、既存testで契約が保証されているか確認します。AI reviewのfindingも誤検出し得ます。review結果をそのまま採用せず、根拠をたどります。

反対に「findingなし」も全体安全の証明ではありません。toolが読めなかったfile、実行していないtest、外部service、Productionだけの設定など、範囲外を明示します。

Staged diffとcommit境界を分ける

review後は、実際にcommitされるstaged diffをもう一度読みます。unstaged diffが残っている場合、working tree全体の完成とcommit内容は同じではありません。対象fileのみstageし、cached diffを確認します。生成fileを含める場合は、正本から再生成できるか、内容が必要か確認します。

commit単位は、一つの目的と一つの検証結果が追える範囲にします。sourceとtestを一緒に含めるのは自然なことがあります。一方、無関係な文言修正、dependency upgrade、cleanupを一つに混ぜると、後から原因やrollbackを追いにくくなります。

Commit前チェックlist

• 作業前からの変更が保たれている

• tracked・staged・untrackedを別々に確認した

• 変更fileが目的と対応している

• secret、local path、debug、temporary artifactがない

• 削除と生成fileに理由がある

• test resultが差分の契約と対応している

• cached diffが意図したcommit内容と一致

• approvalが必要な操作を勝手に実行していない

各項目はrepositoryの運用ルールに合わせます。production deploy、main merge、DB writeなどは、feature branch上のcommit reviewとは別のGateです。

Stagedとunstagedが食い違う例

たとえばunstagedの修正は正常でも、stageした後に別fileの古い版が残ることがあります。反対に、最初にstageしたfileを後から直すと、working tree上の内容とcommitされる内容が異なります。確認ではfile一覧だけでなく、staged diffとunstaged diffの両方を開き、同じfileに二つの差分がある場合は意図を説明します。秘密を含むfileがある場合は値を貼らず、該当fileをcommit対象から外す運用に従います。

AIものさしの判断

Git diffは、AIが何を変えたかを読むだけでなく、作業前からあったものと今回の変更を分け、次の操作を安全に判断するための記録です。status、file一覧、unstaged、staged、high-risk behaviorの順に確認し、根拠が説明できる差分だけを取り込みます。Claude Codeのsummaryやreviewを使う場合も、最終判断は実際のdiff・test・既存契約に戻して行います。

状態別にdiffを読むコマンド例

git status --shortで変更状態を確認し、git diff --でunstaged、git diff --cached --でstagedの内容を読みます。git ls-files --others --exclude-standardはuntracked fileのpath一覧を示すだけなので、候補があれば内容を別に開いて確認します。重要なのは、git diff HEADだけではuntracked fileが含まれない点です。commit直前はgit diff --cached --checkでwhitespace errorも確認できます。これらは読み取り・検査用で、stageやcommitを実行するcommandではありません。