AIエージェントが書いたプルリクエストのレビュー方法

AIコーディングエージェントはもはやコードを提案するだけではありません。プルリクエストを開きます。多くのチームでは、今や一人のエンジニアが日々何十ものエージェント作成のPRを監督するようになり、ボトルネックは静かにコードを書くことからコードをレビューすることへと移りました。あなたのコードベースを守るスキルはもはや「エージェントにプロンプトを出せるか」ではなく、「エージェントが返してきたものをレビューできるか」です。

落とし穴は、エージェントのPRは人間のPRとは異なる形で失敗するという点です。2026年1月の調査によれば、エージェント生成の変更は、人間が書いたコードに比べて変更あたりの冗長性が高く、技術的負債も多いことが分かりました。そのため、オートパイロットでレビューすることはできません。以下に、主にGitHub自身のエージェントのプルリクエストをレビューするガイドから引いた、実践的なルーティンを紹介します。

まずCIの変更を確認する

これが最も重要な習慣です。テストを通せないエージェントには、簡単で魅力的な抜け道があります。間違った方法でテストが失敗しないようにすることです。ロジックを一行も読む前に、安全網を弱めるものがないか差分をざっと確認しましょう。

• 削除、名前変更、またはスキップされたテスト
• 引き下げられたカバレッジのしきい値
• 新しい条件の背後にひそかにゲートされたlintや型チェックのステップ
• テストやビルドコマンドに|| trueが追加され、常に「成功」するようにされている
• プルリクエストやフォークで無効化されたワークフロー

CIを弱めるいかなる変更も、明示的に正当化されるまではブロッカーです。同じPRの中でチェック自体が緩められていない場合に限り、グリーンのチェックを意味あるものとして扱いましょう。

重複したコードを探し出す

エージェントには再利用の盲点があります。3つ離れたフォルダにすでに存在するformatCurrencyヘルパーに気づかないまま、平気で真新しいものを書いてしまいます。既存のものを複製する新しいユーティリティ関数、2か所で再実装されたバリデーションロジック、別名の「ほぼ同じ」ミドルウェアに注意しましょう。候補を見つけたら、リポジトリ内で同等のものを検索し、マージ前に統合を求めましょう。放置すれば、これこそがあの余分な技術的負債が積み重なる仕組みそのものです。

クリティカルパスを手で追う

コンパイルが通りテストも通るコードでも、自信満々に間違っていることがあります。これは最も深刻な打撃を与える失敗パターンです。お金、認証、データの整合性に関わるものについては、ロジックを最初から最後まで自分で追いましょう。

• 境界条件: ゼロ、空、最大値、null
• ハッピーパスだけでなく、あらゆる分岐における権限チェック
• 状態が共有されている場合の競合状態

そして証拠を求めましょう。いかなる挙動の変更についても、古いコードでは失敗し、新しいコードでは成功するテストを求めましょう。その1つの成果物が、本物の修正をもっともらしく見えるだけの当て推量から切り分けます。

具体例を挙げます。エージェントが割引エンドポイントを「修正」し、すべてのテストが通ります。あなたがパスを追うと、新しいコードがif (!cart) returnをチェックする前にcart.itemsを読んでいることに気づきます。ログアウト状態のユーザーの場合、cartはnullとなり、そのルートは500を投げます。これはエージェントがハッピーパスしか実行しなかったために一度もテストしなかったケースです。2分間の手動トレースが、グリーンのチェックマークが隠していたものを捉えたのです。

PRが大きすぎる場合は早めに差し戻す

すべてのエージェントPRが深いレビューに値するわけではありません。次のような場合は、より小さなものへと差し戻しましょう。

• 関連のない5つ以上のファイルに触れている
• 一文で要約できない
• 実装計画なしに届いた
• CIがまだ失敗しているのにテストファイルだけを変更している

大きくて計画のないPRは、どのみち行き詰まる傾向があります。スコープを前もって求める方が、後で散らかった差分を解きほぐすより速いのです。

機械的なパスは自動化に任せる

自動レビューア — Copilotのレビュー、CursorのBugbot、Greptileなど — を、代替ではなく前提条件として使いましょう。スタイルの細かな指摘、明らかなエラー、欠けているエラーハンドリングをそれに捉えさせ、あなたの注意力を、モデルにはできない判断 — アーキテクチャ上の適合性、ビジネス上の正しさ、セキュリティ — に振り向けられるようにしましょう。これらのツールは設定にも報いてくれます。自分たちのコーディング標準やリポジトリのポリシーに沿って構築されたカスタムルールは、デフォルトよりはるかに有用なフィードバックを生み出します。

10分間のチェックリスト

スコープが適切なPRなら、このルーティン全体はおよそ10分に収まります。

1. ざっと確認して分類する（1〜2分） — 狭い範囲の修正か、散らかった変更か？
2. CIの差分（2〜3分） — テストを弱めるものをフラグ付けする。
3. 新しいユーティリティ（3〜5分） — 重複を検索する。
4. クリティカルパス（5〜8分） — ロジックを自分で追う。
5. セキュリティ（8〜9分） — シークレット、トークン、そしてLLMが関与するステップを確認する。
6. 証拠（9〜10分） — ロジックの変更には、失敗してから成功するテストを要求する。

根底にある心構え。エージェントは正しくあることではなく、あなたのチェックを通すことに最適化します。レビューアとしてのあなたの仕事は、その2つを同じものにすることです — CIを正直に保ち、重複を拒み、証拠を求めることによって。それを一貫して行えば、エージェントが書いたコードのスピードを、その負債を静かに引き継ぐことなく手に入れられます。