AIが書いた変更をプルリクエストで確認する：差分レビューの観点表

最初の5分：差分の「形」を先に見る

コードを1行目から読む前に、変更の全体像を確認します。Gitでは --stat で変更量、--name-status で追加・変更・削除の別を一覧できます。また A...B（ドット3つ）は、Bのブランチが分岐してからの変更だけを表示します（git diffの公式ドキュメント）。

# 説明用の例：main から分岐した作業ブランチの変更を俯瞰する
git diff --stat main...HEAD
git diff --name-status main...HEAD

ここで見るのは次の点です。

• 依頼した内容と無関係なファイルが含まれていないか
• D（削除）や R（リネーム）がないか。特にテストファイル
• 設定・ロックファイル・CI設定など、アプリ本体以外が変わっていないか
• 変更量が依頼の大きさに見合っているか

空白だけの整形で差分が膨らんでいる場合は、-w（空白差を無視）を付けると実質の変更が見やすくなります。

観点表：差分のどこを見て、何を問うか

• 依存の追加、差分で見る場所：package.json、requirements.txt、go.mod など依存定義とロックファイル、危険なサイン：依頼にない新規パッケージ、ロックファイルだけ大きく変動、確認の問い：なぜ必要か。標準機能や既存の依存で足りないか
• テストの改変、差分で見る場所：test・spec を含むファイル、危険なサイン：期待値の書き換え、assertの削除、skipの追加、テスト自体の削除、確認の問い：仕様が変わったのか、通すために合わせたのか
• 秘密情報、差分で見る場所：設定ファイル、.env 系、ログ出力、サンプルコード、危険なサイン：キーらしい長い文字列、URLに埋め込まれた認証情報、秘密鍵、確認の問い：本物の値か。履歴に残っていないか
• 範囲の逸脱、差分で見る場所：--name-status の一覧、危険なサイン：無関係なファイルの変更、大規模な整形、確認の問い：依頼した範囲に収まっているか
• 権限・外部通信、差分で見る場所：新しいHTTP呼び出し、ファイル削除、コマンド実行、危険なサイン：未知のドメインへの送信、rmやexecの追加、確認の問い：送信先と目的は何か
• エラー処理、差分で見る場所：try/catch、except、危険なサイン：例外を握りつぶして成功扱いにする、確認の問い：失敗が隠れていないか

依存の追加

依存は、直接書かれた1行だけでなく、ロックファイル経由で間接的に増えることがあります。GitHubの依存関係レビュー（dependency review）は、PRで追加・削除・更新された依存と、公開日、脆弱性情報を表示し、ロックファイルで見つかる間接依存の変更も対象にします。公開リポジトリで利用でき、非公開リポジトリではプランやGitHub Code Securityの有効化などの利用条件を確認する必要があります。また、依存関係グラフの有効化が必要です（GitHub Docs：依存関係レビューについて、2026年10月29日に確認）。使えない環境では、依存定義ファイルの差分を人の目で読みます。

判断の目安は次のとおりです。

• 依頼に書いていない新規依存は、理由の説明がつくまで保留にする
• 名前が既存の有名パッケージと1文字違いなど、見慣れない綴りは実在と用途を確認する（これは編集上の注意です）
• 小さな機能のために大きなライブラリを入れていないか

テストの改変

AIは「テストを通す」ことを目標にすると、コードを直さずテストを変えてしまうことがあります。次のコマンドで、テスト関連の差分だけを取り出せます。

# 説明用の例：パスはプロジェクトに合わせて変更
git diff main...HEAD -- '*test*' '*spec*'

# 追加された行から、テストを無効化していそうな記述を探す
git diff main...HEAD | grep -nE '^\+.*(\.skip|xit\(|xdescribe|@pytest\.mark\.skip|@Ignore)'

見るのは、削除された（-で始まる）assertやexpect、期待値の変更、テストの丸ごと削除です。期待値の変更に正当な理由があるなら、PR説明にその旨が書かれているはずです。

秘密情報の混入

追加行を機械的に検索すると、見落としが減ります。

# 説明用の例：追加行だけを対象に、よくある名前を検索
git diff main...HEAD | grep -nE '^\+.*(API_KEY|SECRET|TOKEN|PASSWORD|BEGIN [A-Z ]*PRIVATE KEY)'

この検索は網羅的ではありません。名前が違えば拾えず、検出されても本物とは限りません。

GitHubのプッシュ保護（push protection）は、ハードコードされた認証情報を含むプッシュをブロックする機能です。コマンドラインからのプッシュ、GitHub上のコミット、ファイルのアップロードなどが対象です。ただし、リポジトリ側では既定で無効で、有効化にはGitHub Secret Protectionが必要です。リポジトリのプッシュ保護では、既定では書き込み権限のあるユーザーが理由を示して回避でき、その場合は警告と監査ログが残ります。回避できるユーザーは設定で制限できます（GitHub Docs：プッシュ保護について、2026年10月29日に確認）。「入っている」前提にせず、自分のリポジトリで有効かを設定画面で確かめてください。

本物らしい秘密情報が見つかった場合は、PRから消すだけでは足りません。履歴に残るため、その鍵は失効させて再発行する方針で考えるのが安全です。

確認依頼コメントの文例

GitHubのPRでは、「Files changed」タブで行を選んでコメントでき、確認が済んだファイルは「Viewed」にチェックして進捗を管理できます。レビューの送信は、Comment、Approve、Request changesから選びます。なお、Request changesだけでは、ルールセットまたは従来のブランチ保護ルールでPRを必須にしていない限りマージは止まりません（GitHub Docs：PRの変更をレビューする）。止めたい場合はルールの設定が必要です。

以下の文例は説明用の例です。〇〇の部分を差し替えて使ってください。

依存について

`package.json` に `〇〇` が追加されています。
依頼内容（〇〇の修正）に対して、この追加が必要な理由を教えてください。
既存の依存や標準機能で代替できない場合は、その根拠も添えてください。
理由が確認できるまで、この追加は外して再提出をお願いします。

テストについて

`〇〇.test` の期待値が `A` から `B` に変更されています。
仕様の変更によるものか、実装に合わせたものかを教えてください。
仕様変更でない場合は、テストを元に戻して実装側を直してください。
`skip` を付けたテストがあれば、その理由もお願いします。

秘密情報について

`〇〇` の行に、キーのように見える文字列があります。
本物の値でしょうか。本物の場合は、このPRに含めず、環境変数などで渡す形に変えてください。
また、すでにコミット履歴に入っている場合は、キーの失効が必要になるため教えてください。

AIに自己点検させる依頼文

AIに修正を頼むときは、差分の要約を出させると、レビューの手間が減ります。説明用の例です。

先ほどの変更について、次を箇条書きで報告してください。
1. 追加・削除・変更したファイルの一覧
2. 新しく追加した依存とその理由（なければ「なし」）
3. 変更または削除したテストと、その理由（なければ「なし」）
4. 設定値や認証情報に触れた箇所（なければ「なし」）
報告に含めなかった変更がないか、`git diff --name-status` の結果と照合してください。

ただし、AIの報告は自己申告です。報告と実際の差分が一致するかは、人が差分で確かめてください。

判断の流れ：マージしてよいか

1. --name-status に依頼外のファイルがある → 理由を確認するまで保留
2. 依存が増えている → 理由が説明できれば進める。できなければ外す
3. テストが弱まっている（削除・skip・期待値変更） → 仕様変更の根拠がなければ差し戻す
4. 秘密情報らしき文字列がある → 本物ならキー失効を含めて対応し、PRは修正が済むまで止める
5. 上の4つがなければ、動作確認と通常のコードレビューに進む

使い始めるときの小さな工夫

PRテンプレートに、前述の自己点検4項目を入れておくと、AIが書いた変更でも人が書いた変更でも、同じ観点で見られます。チェックの回数を増やすより、毎回同じ順で「形、依存、テスト、秘密情報」を見る習慣のほうが続きます。