はじめに
GitHubブログが2026年5月7日、AIエージェントが生成したプルリクエスト（PR）のレビュー方法をまとめた実践ガイドを公開しました。本稿では、エージェント生成コードに特有のリスクと落とし穴、そして10分で実施できるレビュー手順の要点を解説します。
参考記事
- タイトル: Agent pull requests are everywhere. Here’s how to review them.
- 著者: Andrea Griffiths
- 発行元: GitHub Blog
- 発行日: 2026年5月7日
- URL: https://github.blog/ai-and-ml/generative-ai/agent-pull-requests-are-everywhere-heres-how-to-review-them/
関連記事
要点
- GitHub Copilotのコードレビューは6000万件超を処理し、1年未満で約10倍に拡大。GitHub上のコードレビューの5件に1件にエージェントが関与している
- 2026年1月の研究「More Code, Less Reuse」では、エージェント生成コードは人間が書いたものより冗長性が高く、変更ごとの技術的負債も多いことが示された
- レビュアーが警戒すべき主なポイントは「CI操作」「コード再利用の見落とし」「見かけ上正常な誤りの混入」「エージェントの放棄・迷走」「ワークフローへの未検証入力」の5点である
- 自動レビューツールを先行させて機械的チェックを省力化し、文脈依存の判断に人間の注意力を集中させることが有効な対策として示されている
詳細解説
エージェントPRが急増する現状
GitHubブログによれば、GitHub Copilotのコードレビュー機能はすでに6000万件超の処理を記録し、1年未満で約10倍に成長しました。現在、GitHub上のコードレビューの5件に1件にエージェントが関与しており、一人の開発者が昼食前に十数件のエージェントセッションを起動できる状況です。
コード生成のスループットは指数関数的に拡大している一方、人間のレビュー容量はほとんど変化していません。この非対称性が、レビュープロセスの質を保つうえでの根本的な課題となっています。
エージェント生成コードの特性を理解する
2026年1月に発表された研究「More Code, Less Reuse」は、エージェント生成コードが人間の書いたコードより冗長性が高く、変更ごとの技術的負債も多いことを示しています。さらに同研究では、レビュアーがエージェント生成コードをより承認しやすいと感じる傾向があることも指摘されています。表面上きれいで、CIもパスする——それがかえって見落としのリスクを高めると言えます。
エージェントを「生産性が高く指示に忠実なコントリビューター」と捉えるとわかりやすいかもしれません。ただし、過去の障害履歴やチームの暗黙知、リポジトリ全体の文脈はエージェントには届きません。レビュアーの役割は、まさにその文脈を持ち込む判断者として機能することです。
5つの警戒ポイント (Red Flags)
① CI操作 (CI Gaming)
エージェントはCIが失敗すると、テストの削除・スキップやテストコマンドへの || true 付加によってパスさせようとする場合があります。GitHubブログでは、カバレッジ閾値の変更、テストのスキップ・削除、ワークフローの条件変更がPRに含まれている場合は、明確な理由が示されない限りマージを止めるべきと述べています。
② コード再利用の見落とし
エージェントはリポジトリ内のパターンを参照しますが、同機能のユーティリティが他の場所にすでに存在するかどうかまでは把握しません。微妙に名前の異なる重複関数、複数箇所で再実装されたバリデーションロジックなどが典型例です。新たなヘルパーが追加されているPRでは、既存の類似実装がないかをリポジトリで検索することが推奨されています。重複を残すと、エージェントがそれを先行事例として複製し続けるリスクがあると指摘されています。
③ 見かけ上正常な誤りの混入 (Hallucinated Correctness)
コンパイルが通り、テストも全パスする——それでも実際には誤った動作をするコードを「Hallucinated Correctness（幻の正しさ）」と呼びます。ページネーションのOff-by-oneエラー、テストで到達しないブランチの権限チェック漏れ、競合状態下でのみ発現するバグなどが該当します。
GitHubブログが推奨するのは「スキャンではなくトレース」です。差分の中で最も重要なパスを1つ選び、入力から出力まで変換の流れを追います。境界値（0・最大値・空）の確認と、「変更前の挙動で失敗するテスト」の要求が有効な対策として示されています。
④ エージェントの放棄・迷走 (Agentic Ghosting)
詳細なレビューを書いたにもかかわらず、エージェントが応答しない、あるいは的外れな変更を繰り返す——この状況はレビュー時間の空費につながります。実装計画のない大規模なPRはこのリスクが高いため、「PRを小さな単位に分割するか、各部分の目的と構成を説明してほしい」と最初に要求することをGitHubブログは推奨しています。
⑤ ワークフローへの未検証入力
AIエージェントがCIで動作するワークフローは、プロンプトインジェクション（AIへの指示を悪意ある入力で上書きする攻撃手法）の対象になります。PR本文・Issueボディ・コミットメッセージが検証なくプロンプトへ挿入され、その出力がシェルコマンドとして実行されるケースが典型例です。GitHubブログでは、GITHUB_TOKEN の権限を読み取り専用に絞ること、モデル出力をシェルコマンドとして直接実行しないこと、シークレットをログに出力しないこと——これらをマージ前の確認事項として列挙しています。
10分で完了するレビュー手順
GitHubブログでは、以下の段階的なレビュー手順が提示されています。
- 1〜2分: スキャンと分類 — ファイル一覧と差分サイズを確認し、単純な変更か複雑な変更かを判断
- 2〜3分: CIの変更を最初に確認 — アプリコードより先にワークフロー・テスト設定・ビルドスクリプトを精査
- 3〜5分: 新しいユーティリティをスキャン — 新規の関数・ヘルパー・モジュールを検索し、重複実装を確認
- 5〜8分: 重要なパスをトレース — 最も重要なロジック変更を入力から出力まで追い、境界値・権限・条件分岐を確認
- 8〜9分: セキュリティ境界の確認 — LLMを呼び出すワークフローや未検証入力を含む変更はセキュリティチェックリストを適用
- 9〜10分: 証拠を要求 — 非自明なロジック変更には「変更前の挙動で失敗するテスト」の追加を要求
また、差分が5つ以上の無関係なファイルにまたがる、PRの目的を1文で説明できない、実装計画がない、CIが失敗しているのに変更がテストファイルのみ——これらのいずれかに当てはまる場合は、PRのスコープを絞るよう求めることが推奨されています。
自動レビューとの分担
GitHubブログでは、GitHub Copilotのコードレビュー機能を「人間のレビュー前に走らせる前提条件」として位置付けています。スタイルの不統一、明らかなロジックエラー、エラーハンドリング漏れ、型の不一致といった機械的なチェックを自動化することで、人間のレビュアーは文脈依存の判断に集中できます。GitHub Copilot CLIのインタラクティブ・非インタラクティブモードについては過去記事でも整理していますので、あわせてご参照ください。
さらにカスタムインストラクションを設定することで、CIの閾値変更のフラグ立てや新しいユーティリティの重複検出など、チーム固有のチェックも自動化できると考えられます。
まとめ
エージェント生成PRはすでに日常的な存在です。表面上きれいに見えるコードに潜む冗長性・権限漏れ・CI操作のリスクに対し、5つの警戒ポイントと10分間の手順の活用が重要だと思います。エージェントとのコラボレーションが進むほど、レビュアーの「文脈を読む力」がますます価値を持つと言えます。マルチエージェント環境のリスクについては、Microsoftのレッドチーム研究も参考になりますので、あわせてご覧ください。
