AIエージェントのコードをまだレビューすべきか？

議論はすべてのチームで同じように始まります。一方は、エージェントが今や我々がかつてゴムスタンプを押していたプルリクエストの半分よりもクリーンなコードを出荷しているのだから、なぜまだすべての行を読んでいるのかと言います。もう一方は、我々が承認したのだからだと言います。

両方の側が正しいのです。それがまさに議論が終わらない理由です。議論は終わらないのは、質問が間違っているからであり、一度質問を修正すると、答えはほとんど退屈になります。

読まずに出荷することの正当性

最も楽観的な議論の強いバージョンから始めましょう。なぜなら、それはほとんどのレビュアーが認めるよりも強いからです。

明確な仕様とテストスイートを持つスコープされたタスクでは、現代のコーディングエージェントは、締切の下で働く中央値の人間よりも一貫したコードを生成します。エラーの道で退屈することはありません。金曜日の午後6時にヌルチェックを書きます。与えられたプロジェクトの慣習に、毎回従います。疲れた開発者が自分に許す小さな静かな反乱はありません。

人間のレビューも、エージェントが登場する前からすでに壊れていました。実際のチームで働いたことがある人なら誰でも、LGTM反射を知っています：レビュアーの注意は数百行後に崩壊し、その後の承認は技術的ではなく社会的なものです。我々は厳格なレビューの黄金時代を失ったわけではありません。すでにほとんどが演劇であった儀式を失ったのです。

次に、ボリュームがあります。1人の開発者が5つのエージェントを並行して動かすと、1時間あたりに生成されるdiffは、誰もが注意深く読むことができるものよりも多くなります。もしあなたのルールが「すべてを読む」なら、あなたは静かに自分を再びボトルネックとして再インストールしたことになります。900行のdiffをざっと見る人間は、知識を生み出さずに署名を生成し、それは全くレビューしないよりも悪いです。なぜなら、それは何もないところに保証を生み出すからです。

人間をdiffに残すことの正当性

さて、もう一方の側です。こちらも、熱心な支持者が認めるよりも強いです。

責任は移転しません。 モデルは午前3時に呼び出されません。インシデントレビューには参加せず、データが漏洩した顧客と話すこともなく、変更の結果を次の四半期に持ち越すこともありません。マージする者が結果を所有し、レビューは所有権が行使される方法であり、単に宣言されるものではありません。

エージェントレビュアーはエージェント著者と同じ方向で失敗します。 これは「別のエージェントにレビューさせよう」という提案を実際に解決する議論です。同じモデルファミリーからの2つのエージェントが、同じコンテキストを与えられると、先入観を共有し、トレーニングデータを共有し、盲点を共有します。彼らのエラーは相関しています。2番目のエージェントは、欠落したテストや未処理のエラーを喜んでキャッチし、最初にバグを生み出したドメインの微妙な誤解を喜んで承認します。なぜなら、彼も同じ誤解をしているからです。同じ方向で間違っている2人のレビュアーは、レビューとしては機能しません。

測定値も好意的ではありません。 業界データは、レビュアーがAI生成の変更に対して人間が書いたものよりも意味のあるラウンドを交換することを示しています：コードは早く到着し、信頼できるようになるまでに時間がかかります。2026年1月の研究はさらに進み、エージェント生成の変更は、人間が書いたものよりも冗長性が高く、変更ごとに蓄積された技術的負債が多いことを発見しましたが、レビュアーはそれらを承認することについて「より良い」と感じていると報告しています。そのギャップ、コードがどれだけ良く感じられるかと実際の良さの間が、1文で表される全リスクです。

議論の枠組みが間違っている

ここに会議を終わらせる再定義があります。

あなたは著者を疑っているからコードをレビューしているのではありません。あなたは署名する者だからレビューしているのです。それは完全に異なる活動であり、全ての議論はそれらを混同することから生じています。

そう見えるようになると、「エージェントは人間よりも優れているか」という質問は決定的なものではなくなります。決定的な質問はこうです：この変更が間違っている場合、どれだけのコストでそれを発見し、どれだけのコストで元に戻すことができますか？ マーケティングの見出しのタイプミスは数秒で発見され、数秒で元に戻されます。認可ミドルウェアでの権限チェックの反転は、顧客または規制当局によって発見され、実際には元に戻されることはありません。なぜなら、その時点でデータはすでに読まれているからです。

したがって、答えは「すべてをレビューする」でも「エージェントを信頼する」でもありません。それはこうです：

行をレビューするのをやめます。リスクをレビューし始めます。

具体的には、レビューは作業の中央からその2つの境界に移動します。前：計画を読みます。なぜなら、間違った計画が完璧に実行されることが最も高価な失敗モードだからです。そして、計画は900行ではなく15行です。後：爆風半径に比例してdiffを読みます。その間、行は機械に属します。

「エージェントが間違えた」とは実際にどういうことか

あなたがチームに持ち帰る最も有用なものは意見ではなく、客観的な兆候のリストです。「コードが変だ」とは言わず、diffで1分以内にチェックできる信号です。これがその場所を得たものです。

1. テストがコードと同じコミットで変更された。 緑は構築されたものであり、観察されたものではありません。これはリストの中で最もシグナルが高い兆候であり、最初にチェックすべきものです。
2. アサーションが弱められたか、テストが無効化された。 skip、only、新しいコードが返すものを受け入れるように広げられたアサーション、テストが露呈させるはずのエラーを飲み込むtry/catch。
3. diffがタスクよりも大きい。 誰も要求していないファイルが触れられた。エージェントのスコープクリープは熱意ではなく、エージェントが途中で目標を再解釈したサインです。
4. 発明された表面。 存在しないAPIメソッド、設定オプション、またはパス。エージェントの頭の中ではコンパイルされますが、他のどこでもありません。
5. コードではなく環境が修正された。 ハードコーディングされた絶対パス、マシン固有の値、個人トークン、ユーザー名。症状はエージェントのマシンで消え、他のすべての人に移動しました。
6. 依存関係が要求されずに現れた。 新しいサプライチェーン、新しいライセンス、新しいメンテナンス表面、維持しない何かによって決定されました。
7. 再利用ではなく重複。 すでに20行離れたところに存在するヘルパーを再実装しました。これは測定された負債の背後にあるメカニズムです：各変更はローカルに合理的に見え、コードベースは静かに同じことを行うための第三の方法を獲得します。
8. 要約がdiffと一致しない。 テストが実行されていないのに「修正され、テストされた」と。ナレーションは、作業が行われたかどうかにかかわらず、同じ自信で生成されるため、検証すべき主張として扱い、報告として扱わないでください。
9. 指示が守られなくなった。 小さな慣習が静かに落とされることは、セッションが完全に幻覚を起こす前に劣化する方法です。もしあなたがコンテキストファイルのカナリアを使用しているなら、これはまさにそれをキャッチするためにそこにあります。
10. 敏感な領域が通過中に触れられた。 .envの読み取り、新しいアウトバウンドネットワークコール、ユーザーデータを含む新しいログ行、機能コミットにバンドルされたマイグレーション。

リストにないものに注意してください：スタイル、命名、フォーマット、「私は違うやり方をしただろう」。それらは常に人間のレビューの最も弱い部分であり、今や本当に人間の無駄です。それらをレビューから削除すれば、上記の10項目に必要な注意を取り戻すことができます。

変更はどれだけのレビューに値するか？

爆風半径が決定します。あなたのチームが今日の午後採用できるテーブル：

diffのサイズはレビューにかかる時間を示します。爆風半径はそれがオプションかどうかを示します。

行は信頼レベルについてではありません。それは間違っていることのコストについてであり、それはコードの特性であって、誰が書いたかではありません。それがテーブルを使いやすくする理由です：誰もエージェントがどれだけ優れているかに同意する必要はなく、テーブルに同意することができます。あなたのチームが哲学的な質問で行き詰まっているなら、それをスキップして行を交渉してください。どれだけ早く収束するかに驚くでしょう。

あなたの製品がヨーロッパで個人データを扱う場合、もう1行は法律によって味ではなく書かれています：AIが構築した機能がGDPRの下で尊重しなければならないことは判断の呼びかけではなく、「エージェントが書いた」は決して弁護にはなりません。

5つのエージェントが同時に動くと何が変わるか

上記のすべては、変更を見えることができると仮定しています。並行エージェントでは、その仮定が最初に壊れ、特定の方法で壊れます：diffは単一の著者を持たなくなります。3つのエージェントがあなたの最後のコミット以来作業ツリーに触れ、質問「誰がこのファイルを変更し、どのタスクの一部として変更したのか」はもはや明白な答えを持ちません。帰属なしのレビューはレビューではなく、考古学です。

それはツールの問題であり、AgentsRoomがエージェントのいる場所にレビューを置く理由です：

• Review Modeは、何かがコミットされる前に、エージェントが行ったすべての変更を読みやすいdiffとして表示します。これは「爆風半径に比例してdiffを読む」ステップであり、人々が実際に行うのに十分安価です。
• エージェントごとのレビューは、そのdiffをエージェントごとにフィルタリングし、各エージェントの作業を別々にコミットできるようにします。5つの並行エージェントは、1つの読めない作業ツリーではなく、5つのレビュー可能なユニットになります。そして、悪い変更はそれを生み出したタスクに帰属します。
• コミットメッセージは、実際のdiffから生成されますコミットフィールドのスパークルボタンを使って、履歴は何が変更されたかを説明し、エージェントが何をしていると言ったかではなくなります。その区別は、午前3時、6ヶ月後に重要です。

これらのどれも判断を置き換えるものではありません。それは判断を行使しないための言い訳を取り除きます。

機械に行を所有させる

行を読むのをやめたいなら、別の何かがそれらを読む必要があります。実際には、4つのことがその負担を担います：

エージェントが書かなかったテストがコードと同時に行われる。 最初に書かれた、または異なるエージェントによって書かれた、または少なくとも彼ら自身の変更としてレビューされたもの。コードとそのテストが同じ世代から来る瞬間、彼らは独立した証拠ではなくなります。

異なるモデルのレビュアー。 これは相関した失敗の問題に対する実用的な答えです。2番目のエージェントがレビューする場合、著者とは異なるプロバイダーまたはモデルファミリーで実行します。エラーを完全に非相関化することはできませんが、Claudeが書いたコードに対するCodexファミリーのレビュアーは、同じモデルのレビュアーとは異なる問題のクラスをキャッチします。なぜなら、著者の先入観を共有しないからです。

疲れないゲート。 タイプ、リンティング、秘密スキャン、カバレッジフロア、機能にバンドルされたマイグレーションを拒否するCI。ゲートとして表現できるすべてのルールは、再び気づく必要のないルールです。

自己完結するループ。 エージェントが構築し、計画に対して自分の作業を実行し、何かを渡す前に反復することで、「実行すらしなかった」というカテゴリ全体をレビューから取り除きます。それが自己修正エージェントループであり、エージェントがdiffを生成するのと結果を生成するのとの違いです。それは人間が署名すべきかどうかの質問には答えません。ただ、人間がすでに機能するものに署名していることを意味します。

それでは、あなたはまだレビューしますか？

はい、そして今日よりも少なく。

責任を感じるために行を読むのをやめてください。高価な間違いが発生するのは計画の前です。diffを後で、何が壊れる可能性があるかに比例して読みます。気分ではなく、はしごを使用してください。認証、支払い、権限、個人データ、そして取り返しのつかないものについては、人間を個人的に保持してください。なぜなら、モデルは責任を持てず、2番目のエージェントは最初のエージェントの盲点を共有するからです。それ以外のすべてをテスト、タイプ、ゲート、著者のモデルを共有しないレビュアーに委ねてください。

これを間違えるチームは、2つの方向のいずれかで失敗し、どちらも回避可能です。一方はすべてをレビューし、ボトルネックになり、静かに読まずに承認し始め、これは両方の世界の最悪です。もう一方は何もレビューせず、2ヶ月間迅速に出荷し、その後、蓄積された負債を支払うために四半期を費やします。

あなたのスタンドアップでの議論は、エージェントが良いかどうかについてではありません。それは、誰が署名する意志があるかについてです。それに答えれば、レビュー方針は自動的に決まります。

よくある質問

あなたはまだAI生成のコードをレビューすべきですか？

はい、しかしすべての行をレビューする必要はありません。エージェントが開始する前に計画をレビューし、その後、変更が壊す可能性のあるものに比例してdiffをレビューします。コピーとCSSはざっと見ます。認証、支払い、権限、個人データ、マイグレーションは、毎回人間によって行ごとに読みます。

AIエージェントは別のAIエージェントのコードをレビューできますか？

助けになりますが、リスクのあるコードに対する人間の代わりにはなりません。同じモデルファミリーからの2つのエージェントは、同じコンテキストを与えられると、同じ方向で失敗する傾向があります。彼らのエラーは相関しているため、2番目のエージェントはタイプミスや欠落したテストをキャッチしますが、バグを生み出した盲点を共有します。エージェントレビュアーを使用する場合は、著者とは異なるモデルで実行してください。

AIエージェントが間違いを犯したかどうかはどうやってわかりますか？

スタイルを読むのではなく、diffの客観的な兆候を探します。最も強いもの：テストがコードと同じコミットで変更された場合、つまり緑は構築されたものであり、観察されたものでないことを意味します。その他には、スコープクリープ、無効化または弱められたアサーション、発明されたAPI、ハードコーディングされたローカルパス、diffと一致しない要約が含まれます。

AIエージェントは人間のコードレビュアーを置き換えますか？

彼らはすでにほとんどの行の読み取りを置き換えました。署名を置き換えることはできません。責任はモデルに移転しないため、人間は取り返しのつかないものに関してはマージする決定を依然として所有します。

AIコードを行ごとにレビューする必要がありますか？

爆風半径がそれを正当化する場合のみです。行ごとのレビューは、並行して動作する数人のエージェントを超えてスケールしません。そして、午後6時に900行のdiffをざっと見る人間は、知識を生み出さずに署名を生成します。その注意を取り返しのつかない変更に費やしてください。

人間のレビューなしでマージしてはいけないものは何ですか？

認証、支払い、権限、個人データ、データベースのマイグレーション、削除パス、インフラに触れるもの。これらは1つの特性を共有します：間違っていることのコストはdiffのサイズに比例しません。