Claude Codeが作った変更を読む順番：Git差分レビューの手順

読む前の準備：差分をClaudeの変更だけにする

先にやることは一つです。依頼する前に、作業ツリーを綺麗にしておきます。

git status --short      # 何も出ない状態が理想
git switch -c claude/feature-x   # 作業用ブランチを切る

自分の未コミット変更が残っていると、git diff に自分の変更とClaudeの変更が混ざります。コミットか退避をしてから依頼すると、以降の差分はすべてレビュー対象になります。

Claude Codeにはチェックポイントと /rewind があり、ファイル編集の巻き戻しができます。ただし公式ドキュメントによると、Bashコマンドだけで変更されたファイルや、サブエージェントによる編集の一部は追跡されません。公式もバージョン管理（Git）の代わりにはならないとしています（Checkpointing）。最後の保険はGitに置いてください。

差分の読み順5ステップ

ステップ1：範囲を確定する（読むのではなく数える）

git status --short
git diff HEAD --stat
git diff HEAD --name-status
git ls-files --others --exclude-standard

見るのは行の中身ではなく、ファイル数、追加・削除の規模、A（追加）D（削除）R（リネーム）の印です。最後のコマンドは未追跡の新規ファイルの一覧です。git diff は未追跡ファイルを出さないので、これを忘れると新規ファイルが丸ごと審査から漏れます。なお、ここでの git diff HEAD は HEAD と作業ツリーの差分を表示しますが、コミット済み変更は含まれません。依頼後にコミットした変更もレビューする場合は、比較対象を適切なベースコミットやブランチに変えてください。依頼内容と無関係なディレクトリが一覧に出たら、中身を読む前にそこで止めて理由をClaudeに聞きます。（git-diff、git-ls-files）

ステップ2：設定・依存・権限まわりを先に読む

次にファイル名だけで次の種類を拾い、先に読みます。

• 依存の定義とロックファイル（package.json、requirements.txt、go.mod など）
• CI設定（.github/workflows/ など）、ビルド・デプロイ設定
• 環境変数、秘密情報に近いファイル（.env*、認証情報）
• Claude Code自身の設定（.claude/ 配下、CLAUDE.md）
• DBマイグレーション、権限・認可のコード

ここは「動作が変わる」というより「安全の前提が変わる」場所です。ロックファイルは巨大なので、除外して本体の差分を見やすくすることもできます。

git diff HEAD -- . ':(exclude)package-lock.json'

ただし除外したロックファイルでも、追加された依存の名前だけは package.json 側で確認してください。

ステップ3：テストの変更を本体より先に読む

テストが通ったという報告は、テストが無傷であることが前提です。本体より先にテストの差分を読み、次を確かめます。

• 削除された、または skip された テスト
• 期待値の書き換え（実装に合わせてテスト側を直していないか）
• アサーションの削除、モックの増加

git diff HEAD -- '*test*' '*spec*'

テストが増えているのに、既存テストの期待値が変わっている場合は、機能追加と仕様変更が混ざっています。意図した仕様変更かを自分で判断します。

ステップ4：本体は「入口から奥へ」読む

本体の変更は、ファイル順ではなく呼び出しの入口（公開関数、APIハンドラ、画面のイベント）から内部へ辿ります。見るポイントは三つです。

1. 削除行（-）: 消えた処理は、追加行より気づきにくいです。バリデーション、ログ、リトライが消えていないか見ます。
2. エラー処理: catch で握りつぶしていないか、失敗時にデフォルト値を返して成功扱いにしていないかを見ます。
3. 変更の理由が依頼に書いてあるか: 頼んでいない整形、リネーム、関数の移動が混ざると、本質的な変更が埋もれます。

ステップ5：機械的な変更はサンプリングし、実行で確かめる

フォーマット変更、一括リネーム、生成ファイルは全行を読まず、数ファイルを抜き取って「本当に機械的か」を確認します。空白の違いを除いて見ると、整形だけの変更を除外できます。

git diff HEAD -w --stat

最後に、自分でテストやビルドを実行します。Claudeの「通りました」は報告であり、あなたの環境での結果ではありません。公式のベストプラクティスも、Claudeに「実行できる確認手段」を与えることを重視しています（Best practices）。

見落としやすい変更の一覧

• テストの削除・skip・期待値の書き換え、なぜ危険か：失敗を消して「通った」状態にできる、見つけ方（例）：git diff HEAD -- '*test*'
• 型・lintの抑制の追加、なぜ危険か：警告を黙らせて問題を残す、見つけ方（例）：追加行の @ts-ignore、eslint-disable、noqa を検索
• エラーの握りつぶし、なぜ危険か：失敗が成功に見える、見つけ方（例）：追加された catch、\、\、true、空の例外処理
• 依存の追加・バージョン変更、なぜ危険か：供給元・ライセンス・挙動が変わる、見つけ方（例）：package.json 等の差分
• CI・フック・コミット時検査の変更、なぜ危険か：チェック自体が弱まる、見つけ方（例）：.github/、--no-verify の追加
• 未追跡の新規ファイル、なぜ危険か：git diff に出ない、見つけ方（例）：git ls-files --others --exclude-standard
• 削除された処理（-行）、なぜ危険か：検証・ログ・認可が消える、見つけ方（例）：git diff HEAD の - 行を重点的に
• ハードコードされた値・秘密に近い文字列、なぜ危険か：漏えいや環境依存、見つけ方（例）：追加行の token、key、URL を検索
• 依頼外のリネーム・整形、なぜ危険か：本質的な変更が埋もれる、見つけ方（例）：git diff HEAD -w --stat、-M
• Claude Code設定・CLAUDE.md の変更、なぜ危険か：次回以降の挙動が変わる、見つけ方（例）：.claude/、CLAUDE.md の差分

追加行だけを機械的に絞る例です。

git diff HEAD | grep -nE '^\+.*(eslint-disable|@ts-ignore|noqa|\.skip|xit\(|--no-verify|\|\| true)'

ヒットしたものがすべて問題とは限りません。「この行を足した理由を説明できるか」を基準に、一件ずつ判断します。

Claude Codeに渡す依頼文

読む前に、Claude自身に「変更の地図」を作らせると、ステップ1〜2が速くなります。

git diff HEAD と未追跡ファイルを確認して、次の形式で報告してください。
1. 変更したファイルを「本体／テスト／設定・依存／生成物・整形のみ」に分類
2. 私の依頼に直接必要なかった変更とその理由
3. 削除または skip したテスト、書き換えた期待値
4. 追加した依存、設定変更、エラー処理の変更
5. 実行したコマンドと結果（実行していないものは「未実行」と明記）
推測は書かず、不明な点は「不明」としてください。

この報告は読む順番を決める材料です。報告に載っていない変更が差分にあれば、そこが最も注意すべき箇所になります。報告を鵜呑みにせず、必ず差分と突き合わせてください。

第二の目として `/code-review` を使う

公式ドキュメントによると、Claude Codeの /code-review は、引数なしの場合、上流ブランチより先のコミットと未コミットの変更を対象に、正しさのバグを探して報告します。対象の指定もでき、/code-review main...my-feature のようにブランチ間を比べたり、/code-review src/auth のようにパスを指定したりできます（Review locally with /code-review。挙動やオプションはバージョンによって異なるため、お使いの版の説明で確認してください）。

使うときの注意点が二つあります。

• 自分の読みの代わりにしない: 探すのはバグが中心で、「依頼にない変更が入っていないか」という意図との照合は人にしかできません。
• --fix は編集を伴う: --fix を付けると、指摘をもとにClaudeが作業ツリーを書き換えます。バックグラウンドで動くレビューの編集は、セッションのチェックポイントの外で行われ、/rewind では戻りきらないと公式に書かれています。使うならその前にコミットしておき、取り消しにはGitを使います。

判断の目安：どこまで読むか

• 設定・依存・CI・認証・マイグレーションに差分がある、読む深さ：全行を読む。意図を説明できなければ巻き戻す
• テストの削除・skip・期待値変更がある、読む深さ：理由が依頼に書かれていなければ差し戻す
• 本体のみで、テストも増え、自分で実行して通った、読む深さ：入口から追い、削除行とエラー処理を重点的に
• 整形・一括リネームのみ、読む深さ：抜き取り確認と -w 付き差分で足りる
• 差分が大きすぎて読み切れない、読む深さ：読む量を減らすのではなく、依頼を小さく分けてやり直す

最後の行が実務では一番効きます。一度に数十ファイルが変わる依頼は、レビューできる大きさではありません。「まず調査と方針だけ」「次にこのモジュールだけ」と区切り、区切りごとにコミットすれば、差分は毎回小さく保てます。