AIエージェントのコードをマージする前に確認する3点：diff・テスト・権限
コーディングエージェントが作った変更を、diff、再実行できるテスト、権限範囲の3点から短時間で確認するための実践的な手順です。
コーディングエージェントは、もっともらしく「修正は完了し、テストもすべて通りました」と報告できます。しかし、その一文だけではマージの根拠になりません。実際の変更では、必要なファイルだけが変わっているか、どのテストを自分で再実行できるか、エージェントがどの権限を使った、または要求したかを確認する必要があります。
GitHub Security Labは、エージェントを使ってファジングを行うtaskflowを紹介しています。ここから学ぶべきなのは、エージェントを最終承認者にすることではなく、作業を検証可能な技術的な出力に分けることです。自分のリポジトリでコーディングエージェントを使う場合も同じです。エージェントの説明はレビュー開始の手がかりにすぎず、diffと再実行した結果が証拠になります。
以下の例は架空のケースであり、GitHubや特定モデルのベンチマーク結果ではありません。
エージェントの要約ではなく、まずdiffを見る
たとえば、parseInvoice関数にnullチェックを追加し、テストも追加するというタスクを依頼したとします。エージェントが作ったプルリクエストには次の3変更がありました。
src/parseInvoice.ts：nullを処理する分岐を追加tests/parseInvoice.test.ts：テストを2件追加.github/workflows/deploy.yml：workflowの権限を読み取りから書き込みへ変更
最初の2ファイルは依頼内容の範囲内だと理解できます。しかし3つ目では一度止まるべきです。null処理の修正に、通常はデプロイ権限の変更は必要ありません。「エージェントには何か理由があるはず」と推測せず、FIXとして扱い、範囲外の変更を戻すか、人間が承認済みの技術要件で理由を説明させます。
まず変更ファイル一覧を見てから、各hunkを読みます。各ファイルについて、依頼達成に本当に必要か、変更範囲が依頼を超えていないか、credential・workflow・dependency・リリース設定に触れていないかを確認します。最後の項目に該当する場合は、より厳しい確認が必要です。
「Tests passed」は、自分で再実行できて初めて意味がある
エージェントは別の環境でテストしたかもしれませんし、一部しか実行していない、あるいはログを解釈しただけかもしれません。そのため、リポジトリにある関連テストのコマンドを使い、管理できる環境で再実行します。上の例なら、少なくともparseInvoiceのテストと、null対応によって通常ケースが壊れていないことを確認する既存動作のテストが必要です。
エージェントがテストを追加していても、そのテストが要件ではなく現在の実装だけを追認しているなら十分な証拠ではありません。入力と期待結果を読みます。null不具合に対する良いテストは、欠けた入力を望む仕様どおりに処理することを示すべきで、単一例でクラッシュしないことだけを示すものではありません。
本番用トークンがある端末で、信頼できないコードを実行しないでください。プルリクエストが未信頼のブランチや依存関係を含む場合は、リポジトリの方針に沿った隔離環境やCIを使います。
権限はタスクに必要な最小範囲にする
コーディングエージェントは通常、リポジトリの読み取りや作業ブランチへの書き込みが必要になることがあります。しかし、それは本番デプロイ、secret変更、組織設定の変更まで必要という意味ではありません。まずタスクの最小操作を書き出します。たとえば「ファイルを読む、2ファイルを修正する、テストを実行する、コミットを作る」です。そのうえで、エージェントが使うtoken、app permission、workflowと照合します。
純粋な関数修正なのに、より広い権限を与えなければ動かないなら、それは標準的なセットアップ手順ではなく調査すべき兆候です。GitHub Security Labの記事は特定のセキュリティtaskflowにおけるエージェントを説明しているのであって、すべてのエージェントやリポジトリで同じ権限設定を使うべきだと示しているわけではありません。
「エージェントは優秀か」ではなく3つの判断を使う
レビュー後は、次のいずれかを選びます。
MERGE — 変更ファイルがすべて依頼範囲内で、関連テストを再実行して成功し、不要な権限や機密性の高い変更がない。
FIX — 方針は妥当だが、範囲外のファイル、足りないテスト、または縮小すべき変更がある。たとえばparseInvoiceとテストの変更だけ残し、deploy.ymlは元に戻すと具体的に返します。
REJECT — 変更を依頼内容まで追跡できない、安全な条件でテストを再現できない、または承認された理由なしに広い権限が必要。こうした場合は、理解しにくいPRを継ぎ足しで直すより、タスクを小さくしてやり直す方が安全です。
レビュー記録は短くても構いません。
Scope: PASS / FAIL — 範囲外のファイルは？
Tests: PASS / FAIL — どのコマンドを再実行した？
Permissions: PASS / FAIL — 必要以上の権限は？
Decision: MERGE / FIX / REJECT
Evidence: diffのリンク + CI run + 権限メモ目的はレビューを長い儀式にすることではありません。重要なのは、エージェントが作った変更にも、重要な人間の変更と同じ種類の証拠を求めることです。scope、tests、permissionsの3点を答えられない限り、「エージェントが完了と言った」だけではマージに十分ではありません。