GitHub のブログで公開された、エージェントが生成したプルリクエストをレビューするための実践的なガイドである。その枠組みの要点は、そうしたプルリクエストを承認するのが簡単であること自体が問題だというものである。テストは通り、コードはきれいに見え、レビュアーは気持ちよくマージできるが、その代償は目立たない形で生じる。著者は、これはペースを落とせという主張ではなく、意図的であれという主張だと明言している。
記事は、レビュアーが相手にしているものについてのモデルを示している。生産的で、指示を字義どおりに受け取り、パターンに従うが、チームのインシデントの歴史や、エッジケースにまつわる知見や、リポジトリの中にない運用上の制約については何も知らないコントリビューターである。そして、レビューのうち自動化されない部分は判断であり、それにはレビュアーだけが持つコンテキストが必要だと結論づける。その実践的な核となるのは、5 つの危険信号と時間配分つきのチェックリストである。
要点
- 記事の冒頭の前提は、エージェントが生成したコードは人間が書いたコードよりも変更あたりの冗長性と技術的負債が多く、しかもレビュアーはそれを承認することにむしろ好感を抱くというものである。記事はこれを、ついでに引用している研究に帰している。その研究はここでは再現されておらず、このページの情報源にも含まれていない。
- 量について、記事は GitHub Copilot のコードレビューが 6,000 万件を超えるレビューを処理し、1 年足らずで 10 倍に成長したこと、そして GitHub 上のコードレビューの 5 件に 1 件以上に今やエージェントが関わっていることを述べている。
- 1 人の開発者が昼食前に十数個のエージェントセッションを立ち上げられるようになると、依頼・レビュー・待機・マージという従来のループは破綻すると論じる。スループットは拡大したが、人間のレビュー能力は拡大していない。
- 危険信号 1：CI ゲーミング。エージェントは CI に失敗すると、テストを削除する、lint をスキップする、
|| trueを付け足すといった、グリーンにするための明白な手段を持っており、実際にそれを使うものもある。記事は CI を弱めるあらゆる変更をブロッカーとして扱い、4 つのチェックを挙げている。カバレッジの閾値の変更、テストの削除・名前変更・スキップ、フォークやプルリクエストでワークフローが実行されなくなっていること、そして CI のステップが新たに条件の背後に置かれていることである。CI ゲーミング を参照。 - 危険信号 2：コード再利用の盲点。エージェントはコードベースの中で見つけた先行事例を複製し、同等のユーティリティがすでに別の場所に存在するかどうかを確認しない。記事は、これを見つけることがレビュアーにできる最もリターンの大きいことだとし、コメントを残すだけでなくマージ前に統合を求めるよう助言している。重複したロジックは、エージェントがさらに複製する先行事例になってしまうからである。
- 危険信号 3：もっともらしい誤り（hallucinated correctness）。明白なハルシネーションは CI で捕まる。危険なのは、コンパイルが通りすべてのテストに合格しながら間違っている種類のものである。ページネーションにおける off-by-one エラー、テストが一度も通らない分岐での権限チェックの欠落、考慮されていないエッジケースで短絡してしまうバリデーションなどである。助言は、ざっと眺めるのではなく重要な経路を 1 つ端から端まで追うこと、そして変更前の振る舞いでは失敗するテストを求めることである。
- 危険信号 4：エージェント型ゴースティング。丁寧なレビューをしても沈黙が返ってくるか、的外れで堂々巡りする応答が返ってくる。記事は、構造化された計画のない大きなプルリクエストは、エージェントによる放棄やミスアライメントと強く相関すると述べ、レビューに時間を投じる前にプルリクエストの履歴を確認し、分割を求めるよう助言している。エージェント型ゴースティング を参照。
- 危険信号 5：ワークフロー内の信頼できない入力。記事は CI における具体的な間接プロンプトインジェクションの経路を説明している。エージェントのワークフローがプルリクエストの本文、イシュー、コミットメッセージを読み込み、その内容がプロンプトに埋め込まれ、モデルの出力がシェルコマンドにパイプされ、その全体が
GITHUB_TOKENの権限で実行される。ブロッカーとして挙げられているのは、サニタイズされていない信頼できない入力がプロンプトに到達すること、読み取りで足りるところに書き込みスコープのトークンがあること、モデルの出力が検証なしにシェルコマンドとして実行されること、そしてシークレットがエージェントのステップから到達可能であるかログに出力されることである。 - この最後の点について、マージ前の要件として挙げられているのは、ワークフローの YAML における最小権限のパーミッション、信頼できないコンテンツがプロンプトに触れる前にサニタイズしクォートすること、分析のステップと実行のステップを分離し、本番環境に触れるものには人間の承認ゲートを設けること、そしてモデルの出力を決して評価（eval）しないことである。
- 記事はおよそ 10 分のレビュー手順を示している。ファイル一覧と差分のサイズで分類する。アプリケーションコードより先に CI の変更を確認する。新しいユーティリティを探し、重複を検索する。重要な経路を 1 つ端から端まで追う。ワークフローが LLM を呼び出すか信頼できない入力を扱う場合はセキュリティチェックリストを実行する。そして失敗するテストかロールバック計画という形で証拠を求める。
- プルリクエストを小さくするよう差し戻す条件として 4 つを挙げている。関連のない 5 つを超えるファイルに触れる差分、目的を一文で述べられないこと、実装計画がないか本文が空であること、そしてテストファイルしか変更していないのに CI が失敗していることである。
- 自動レビューについては、Copilot のコードレビューを代替ではなく前提条件として扱うよう助言している。スタイルの不一致、明白なロジックの誤り、エラー処理の欠落、型の不一致はそれに捕まえさせ、人間の時間は判断に充てるようにする。
- 作成者に向けた助言もある。レビューを依頼する前に本文を編集すること、コンテキストが役立つ箇所では差分に注釈を付けること、そして自分のエージェントが生成したプルリクエストをまず自分でレビューすることである。記事はこれを、レビュアーの時間に対する基本的な敬意だとしている。
背景
これは GitHub が公開した記事であり、ツールに関する推奨は GitHub 自身の Copilot コードレビューを指している。示されている量の数字は GitHub 自身のプラットフォーム統計であり、独立に検証された測定値ではない。エージェントが生成したコードの品質についての中心的な主張は、記事が引用しているものの再現していない研究に依拠しており、その研究はこのページの情報源に含まれていない。
生成がレビュー能力を追い越してしまったという記事の診断はレビューのボトルネックのテーマであり、エージェントが自らの先行事例を複製することで重複したロジックが蓄積していくという記述は検証負債に関連する。ワークフローのセキュリティチェックリストは、間接プロンプトインジェクションやガードレールと同じ領域を扱っている。