AIが書いたコード「問題なさそう」こそ本当は危ない GitHubが警告する“地雷”の正体：急増するAI生成コード、人間はどこを見るべきか

AIコーディングエージェントが生成するプルリクエスト（PR）が急増している。そうした中、GitHubがコーディングエージェントが生成するPRをレビューする際の実践ガイドを公開した。

[＠IT]

　AIコーディングエージェントが生成するプルリクエスト（PR）が急増する中、人間によるレビューの在り方が新たな課題になっている。GitHubは2026年5月7日（米国時間）、コーディングエージェントが生成するPRをレビューする際の実践ガイドを公開した。レビュワーが見るべき観点、見落としやすい問題、技術的負債を出荷前に検知する方法などを、実務目線で整理したものだ。

AIが生成したコード「問題なさそう」こそ本当は危ない理由

　GitHub Copilotのコードレビューは既に6000万件以上（2026年5月時点）を処理しており、1年足らずで10倍に成長している。GitHub上のコードレビューの5件に1件以上がエージェントを含む形で実施されているという。これは自動レビュー部分の数値であり、PR本体の量はレビュワーが処理できる速度を超えるペースで増えている。

　コーディングエージェントが生成するPRは表面上は整っている。テストはパスし、問題なく承認できそうに見える。だが、GitHubはそこに落とし穴があると指摘する。

　コーディングエージェントは、与えられた指示に従い、パターンを忠実に再現できる。一方、システムの過去のインシデント履歴、チームのエッジケース（極端なパラメーターや動作環境によって起きる不具合）の経緯、リポジトリ外の運用上の制約は把握していない。

　コーディングエージェントは、一見すると完成度の高いコードを生成する。だが、その「問題なさそうに見える」こと自体が落とし穴だ。システムの背景や過去の経緯といったコンテキスト（背景情報）を補えるのは人間のレビュワーであり、最終的な判断には、そうした知識や経験が欠かせない。

注意すべきコーディングエージェントの「5つの危険信号」

　GitHubは、コーディングエージェントが生成したPRをレビューする際、注意すべき「危険信号」として5つを挙げている。

危険信号1：CIをごまかす

　エージェントはCI（継続的インテグレーション）に失敗するとき、テストを通過させることを優先した変更を加えることがある。テストの削除、Lintステップのスキップ、テストが失敗してもCIを通過させるシェルコマンド「|| true」の付与などだ。

　コーディングエージェントによるPRを承認する前に確認すべき項目は以下の通り。

• カバレッジしきい値が変更されていないこと
• テストが削除、リネーム、スキップ指定されていないこと
• ワークフローがフォークやPRで実行されなくなっていないこと
• CIステップが、以前は付いていなかった条件付きの実行になっていないこと

　いずれかに該当する場合は、続行前に明示的な正当化を求める必要がある。

危険信号2：コード再利用の盲点

　これがレビュワーとして最も有効な作業だとGitHubは述べている。コーディングエージェントは、既に同じ役割を果たすユーティリティーが他に存在するかどうかを確認しないことが多い。

　典型的な兆候は次の通り。

• 既存ユーティリティーと役割が重複した、名前だけ異なる新しいユーティリティー関数
• 複数箇所で再実装されたバリデーションロジック
• 共有モジュールに既に存在するミドルウェアが、ゼロから書き起こされている
• 「ほぼ同じ」だが名前が異なるヘルパー

　エージェントのローカルコンテキストはリポジトリ全体を把握していない。エージェントPRの新規ヘルパーやユーティリティーに対しては、レビュワーが必ず簡単に検索し、同等の実装があれば「コメントで指摘」ではなく「マージ前に統合を必須化」すべきだとGitHubは強調する。重複ロジックを残せば、次のエージェントがそれを先行事例としてさらにコピーする悪循環につながる。

危険信号3：微妙なハルシネーション

　明らかなハルシネーション（存在しないAPIの呼び出し、スコープ外の変数参照など）はCIで検知できる。危険なのはより微妙なハルシネーションであり、コンパイルが通り、全てのテストもパスするが、誤っているコードだ。

　具体例として次のようなパターンがある。

• ページネーションのオフバイワン（1つずれる境界ミス）
• テストでは到達しないブランチでの権限チェック漏れ
• エージェントが想定しなかったエッジケースで短絡するバリデーション
• 規模が大きいときにのみ表面化する競合状態下の誤動作

　複雑なロジックを変更する場合は、修正前は失敗し、修正後は成功するテストの追加を求めるべきだ。バグを修正したというのであれば、そのバグを検知できるテストも併せて用意されている必要がある。コーディングエージェントがそのテストを書けないのであれば、修正が不完全であるか、問題を正しく理解できていない可能性が高い。

危険信号4：エージェントによる「レビュー放置」

　レビューで問題点や背景、修正方針まで丁寧に説明したにもかかわらず、その後PRが止まったままになる。あるいはエージェントが応答しても論点を理解できず、同じ修正を繰り返すだけ。GitHubはこうした状況を問題視している。

　特に、規模が大きく、実装計画が整理されていないPRほど、エージェントが途中で迷走したり、レビューとの認識ずれを起こしたりしやすい。スコープが曖昧な巨大PRでは、レビュー時間だけが消費され、成果につながらないケースが増える。

　そのためGitHubは、大規模なエージェント生成PRを詳細レビューする前に、以下を確認すべきだとしている。

• 過去のレビューに適切に応答していること
• 実装計画や変更方針が明確であること
• 計画なしにコードを書き始めていないこと

　もし実装計画が不十分であれば、詳細なレビューコメントを書く前に、PRの分割や説明追加を求めるべきだという。

危険信号5：ワークフローへの未信頼入力

　GitHubは、AIエージェントを組み込んだCI/CD（継続的インテグレーション／継続的デリバリー）ワークフローが、外部入力を信用し過ぎることで深刻なセキュリティリスクになると警告している。

　典型的な危険パターンは、「PR本文」「Issue本文」「コミットメッセージ」などの外部入力を、そのままプロンプトに埋め込むケースだ。

　その結果、「モデル出力→シェルコマンド実行」につながると、プロンプトインジェクション経由で不正コマンド実行や権限悪用が起こり得る。

　特に問題となるのは以下のケースだ。

• 未検証入力をプロンプトへ直接投入
• 不要に書き込み権限を持つ「GITHUB_TOKEN」
• モデル出力をそのままshell実行
• シークレット（認証情報や秘密鍵）へのアクセスやログ出力

　GitHubは、以下を必須対策として挙げている。

• ワークフロー権限を最小化（read-allがデフォルト）
• 外部入力をサニタイズやエスケープする
• 「解析」と「実行」を分離
• 本番操作前に人間承認を挟む
• AI出力をevalしない

レビューはAIと人間で分担する

　大規模で変更内容が複雑なPRはレビューの負担が大きくなり、問題の見落としにもつながりやすい。GitHubは、差分が5つ以上の無関係なファイルにまたがっている場合や、PRの目的を1文で説明できない場合、エージェントに実装計画がなくPR本文も空のままである場合、あるいはCIが失敗しているにもかかわらず差分がテストファイルの変更だけにとどまる場合は、PRをより小さく分割するよう求めるべきだとしている。

　人間のレビューを始める前に、AIで検出できる問題はあらかじめAIに任せることができる。Copilotレビューは、コーディングスタイルの不一致や単純なロジックミス、エラーハンドリングの漏れ、型不整合といった、機械的に検出しやすい問題の発見に向いているという。

　自動レビューは「人間のレビューの代替」ではなく、「事前フィルター」として使う。Copilotを先に動かし、明らかな指摘が検出されれば著者に対応させてからレビュー時間を投じる。

　GitHubは、AIによってコード量やPR数は増え続ける一方で、人間のレビュワーが価値を発揮できるのは、システム固有の背景や暗黙知を踏まえた最終的な判断だと結論付けている。