エージェントのプルリクエストはどこにでもあります。そのレビュー方法をご紹介します。

あなたはおそらく、気づかないうちにエージェントが生成したプルリクエストを承認したことがあるでしょう。テストはパスし、コードはきれいで、マージしました。しかし、その承認のしやすさこそが問題なのです。

2026年1月の研究「More Code, Less Reuse」によると、エージェントが生成したコードは、人間が書いたコードよりも変更ごとに多くの冗長性と技術的負債をもたらします。表面はきれいに見えますが、負債は静かに蓄積されます。そして、同じ研究によると、レビュアーは実際にそれを承認することに対してより良い気分になるのです。

これは速度を落とせという議論ではなく、意図的に行動せよという議論です。両者には違いがあります。

エージェントのプルリクエストはすでにレビュー帯域を飽和させている

その量はすでに驚異的です。GitHub Copilotのコードレビューは6000万件以上のレビューを処理し、1年足らずで10倍に成長しました。GitHub上のコードレビューの5件に1件以上がエージェントを介しています。これは自動レビューのパスだけです。プルリクエスト自体はレビュアーが処理できる速度よりも速く増加しています。

従来のループ（レビューを依頼し、コード所有者を待ち、マージする）は、一人の開発者が昼食前に十数件のエージェントセッションを開始できる場合、機能しなくなります。スループットは指数関数的に拡大しましたが、人間のレビュー能力はそうではありません。そのギャップは広がっています。

あなたはエージェントのプルリクエストをレビューすることになるでしょう。問題は、その際に重要な点を捉えられるかどうかです。

誰が（または何が）このプルリクエストを実際に書いたのか

差分を一行も見る前に、あなたがレビューしているもののモデルを理解する必要があります。

コーディングエージェントは、生産的で文字通り、パターンに従う貢献者ですが、あなたのインシデント履歴、チームのエッジケースの知識、リポジトリに存在しない運用上の制約についてはゼロのコンテキストしか持ちません。完全に見えるコードを生成しますが、その「完全に見える」という障害モードは危険です。

そのコンテキストを持っているのはあなたです。それは負担ではなく、実際の仕事です。自動化されないレビューの部分は判断であり、判断にはあなただけが持つコンテキストが必要です。

著者への注意

エージェントが生成したプルリクエストを開く場合は、レビューを依頼する前に本文を編集してください。エージェントは冗長さを好み、コード自体でよりよく探索できることを説明します。コンテキストが役立つ場所に差分を注釈してください。そして、他の人にタグを付ける前に自分でレビューしてください。正しさをチェックするだけでなく、エージェントがあなたの意図を捉えたことを確認したというシグナルを送るためです。

エージェントが関与する場合、自分のプルリクエストをレビューすることはオプションではありません。レビュアーの時間への基本的な敬意です。

さて、レビュアーに戻ります。プルリクエストがキューに届きました。著者は自分の役割を果たしました。以下に注意すべき点を示します。

注意すべき危険信号

1. CIゲーム

エージェントはCIで失敗します。その場合、テストを通過させるための明白なパスがあります：テストを削除する、lintステップをスキップする、テストコマンドに|| trueを追加する。一部のエージェントはそれを行います。

CIを弱体化する変更はすべてブロッカーです。完全停止。エージェントのプルリクエストを承認する前に、以下を確認してください：

• カバレッジしきい値が変更されていないか？
• テストが削除、名前変更、またはスキップとマークされていないか？
• ワークフローがフォークやプルリクエストで実行されなくなっていないか？
• 以前はなかった条件でCIステップがゲートされていないか？

これらのいずれかに「はい」と答えた場合、続行する前に明確な正当性が必要です。

2. コード再利用の盲点

これはレビュアーとして最もROIの高いことです。エージェントは先行事例を探します。コードベースのパターンを見つけて複製しますが、多くの場合、同じことを行うユーティリティが他の場所に存在するかどうかを確認しません。症状：既存の関数と微妙に異なる名前の新しいユーティリティ関数、複数の場所で再実装された検証ロジック、共有モジュールにすでにあるのにゼロから書かれたミドルウェア、「ほぼ同じ」だが名前が異なるヘルパー。

エージェントのローカルコンテキストには、リポジトリ全体の既存のものの完全な画像は含まれていません。あなたは含んでいます。

エージェントのプルリクエスト内の新しいヘルパーやユーティリティごとに、簡単な検索を行ってください。同等のものを見つけた場合、コメントを残すだけでなく、マージ前に統合を要求してください。重複ロジックを残すコストは、エージェントがそれを先行事例として見つけ、さらに複製することです。

💡 プロのヒント：サイズしきい値を超えるエージェントのプルリクエストでは、新しいユーティリティの追加に正当性を要求します。これにより、重複問題を早期にキャッチします。

3. 幻影的な正しさ

明白な幻覚（存在しないAPIの呼び出し、スコープ外の変数の参照）はCIでキャッチされます。危険なのは微妙なものです：コンパイルされ、すべてのテストにパスするが、間違っているコード。

ページネーションのオフバイワンエラー、テストで決してヒットしないブランチでの権限チェックの欠落、エージェントが考慮しなかったエッジケースでショートサーキットする検証、大規模でのみ表面化する競合状態での誤った動作。

スキャンするだけでなく、トレースしてください。差分の中で最も重要なパスを選択し、入力からすべての変換を通って出力まで追跡します。境界条件（ゼロ、最大、空）、外部値のバリデーションの欠落、すべてのブランチでの権限チェック、驚くべき条件ロジックをチェックします。

変更前の動作で失敗する新しいテストを要求します。エージェントが修正すると主張するバグをキャッチするテストを書けない場合、修正は不完全であるか、理解が間違っています。

4. エージェントのゴースト化

あなたは徹底的なレビューを行い、問題を説明し、コンテキストを提供し、方向性を提案します。プルリクエストは沈黙します。または、エージェントが応答するが要点を完全に見逃し、同じ場所をぐるぐる回ります。あなたはさらにラウンドを費やします。それでも何も役に立ちません。

構造化された計画のない大きなプルリクエストは、エージェントの放棄またはミスアライメントと強く相関します。プルリクエストが大きく、範囲が不明確であるほど、行き詰まるレビュー時間を費やす可能性が高くなります。

大きなエージェントのプルリクエストに深いレビューを投資する前に、プルリクエストの履歴を確認してください：以前のラウンドで応答性がありましたか？明確な実装計画がありますか、それともエージェントが単にコードを書き始めただけですか？

計画がない場合は、コメントを一つも書く前に分解を要求します。コピーペーストバージョン：

「このプルリクエストは大きすぎて、より明確な実装計画なしではレビューできません。より小さなスコープの単位に分割するか、各部分の目的と構造の理由の概要を追加していただけますか？その後、喜んでレビューします。」

断固として、短く、個人的ではありません。そして、あなたの1時間を節約します。

5. ワークフロー内の信頼できない入力

CIエージェントにおけるプロンプトインジェクションは実際に存在し、過小評価されています。パターンは次のとおりです：エージェントワークフローがプルリクエスト本文、イシュー、コミットメッセージからコンテンツを読み取り、そのコンテンツがプロンプトに挿入されます。プロンプトはモデルに送られ、モデル出力はシェルコマンドにパイプされます。全体がGITHUB_TOKEN権限で実行されます。

LLMを呼び出すワークフローをレビューする場合、これらはブロッカーです：

• 信頼できないユーザー入力（プルリクエスト本文、イシュー本文、コミットメッセージ）がサニタイズされずにプロンプトに挿入されていないか？
• GITHUB_TOKENが読み取りアクセスのみ必要なのに書き込みスコープになっていないか？
• モデル出力が検証なしでシェルコマンドとして実行されていないか？
• シークレットがエージェントステップにアクセス可能か、ログに出力されていないか？

マージ前に要求すること：ワークフローYAMLでの最小特権（permissions: read-allは合理的なデフォルト）、信頼できないコンテンツをプロンプトに触れる前にサニタイズして引用し、「分析」ステップと「実行」ステップを分離し、本番に触れるものには人間の承認ゲートを設置し、モデル出力を決してevalしない。

体系的なレビュープロセス

時間ステップ | 何をするか --- | --- 1-2分 | スキャンして分類：ファイルリストと差分サイズを確認。狭いタスク（ドキュメント、CI、小さな変更）か複雑なタスク（複数ファイル、ロジック、パフォーマンス、テスト）か？この分類により、その後のすべてのレビューの深さが決まります。

2-3分 | 最初にCIの変更をチェック：アプリケーションコードを一行も読む前に、.github/workflows、テスト設定、カバレッジ設定、ビルドスクリプトに触れるものを確認します。CIを弱体化するものをフラグします。ストップサインのチェック。

3-5分 | 新しいユーティリティをスキャン：新しい関数、ヘルパー、モジュールを検索します。それぞれについて、リポジトリ内で重複がないか簡単に検索します。既存機能を再発明しているものをフラグします。

5-8分 | 1つの重要なパスをトレース：最も重要なロジック変更を選び、エンドツーエンドでトレースします：入力→変換→出力。境界条件、権限、予期しない分岐をチェックします。これはスキップできないステップです。

8-9分 | セキュリティ境界：このプルリクエストがLLMを呼び出すワークフローや信頼できない入力を処理するものに触れている場合、上記のセキュリティチェックリストを実行します。

9-10分 | 証拠を要求：非自明なロジック変更には、変更前の動作で失敗するテストを要求します。リスクの高い変更にはロールバック計画を要求します。

いつより小さなプルリクエストを要求するか：

• 差分が5つ以上の無関係なファイルに触れている
• プルリクエストの目的を一文で説明できない
• エージェントに実装計画がない、またはプルリクエスト本文が空
• CIが失敗しており、差分の唯一の変更がテストファイル

まずCopilotにレビューさせる

自動レビューを得意分野に活用します：人間が介入する前に機械的なものをキャッチします。Copilotコードレビューはスタイルの不整合、明らかなロジックエラー、エラーハンドリングの欠落、型の不一致をフラグします。低レベルのスキャンを処理します。これにより、あなたは判断作業に集中でき、そこが実際に時間を費やす価値のある場所です。

それを前提条件として扱い、代替としてではありません。まずCopilotを実行させます。明白な問題をキャッチした場合、あなたがレビュー時間を投資する前に著者に対処させます。

チーム固有のカスタム指示で調整できます：CIしきい値を変更するものをフラグ、重複レビューのために新しいユーティリティを表示、すべての外部入力が検証されているかチェック。指示が具体的であるほど、自動パスはより有用になります。

💡 プロのヒント：最近、Copilot SDKを使用して自分のレビューチェックリストをコード化する実験をしました。すべてのプルリクエストで同じセキュリティチェックを実行することを覚えておく代わりに、個人のチェックリスト（管理エンドポイントの認証、テストの実際の実行、安全な環境変数の処理）を取得し、差分に対して自動的に実行するワークフローを構築しました。重大な問題を見つけた場合、マージをブロックします。

判断がボトルネックですが、それで構いません

コードの表面積は増えています。プルリクエストの数は増えています。ボイラープレートのスキャンに費やす時間は減るべきです。

しかし、減らないのはあなたが持っているコンテキストです。どこにも書かれていないシステムについてあなたが知っていること。それがあなたのレビューを価値あるものにし、自動化されない部分です。

3つのポイント：

• CIの弱体化は絶対的な停止です。
• エージェントにまずスキャンさせ、あなたは重要なパスをトレースします。
• 複雑なエージェントのプルリクエストには危険信号チェックリストをデフォルトとして使用します。

ドキュメントを読む >