「セルフレビューさせて終わり」で本当に大丈夫か——AIエージェント時代に効く『敵対的検証』という一段深い仕組み

セルフレビューを導入したチームが、次にぶつかった壁

前回の記事で紹介した、PRを提出する前にAIで一度セルフレビューを済ませておく仕組みは、複数の中堅企業で実際に効果を出しています。ある卸売業のクライアントでは、この型を導入してからベテランエンジニアのレビュー時間が3割ほど短縮されました。

ただ、正直に言えば、この仕組みには一つ気になる点が残っていました。実装したAIエージェント自身に、自分のコードをレビューさせている、という点です。自分で書いた答案を、自分で採点しているようなものです。よほど注意深く設計しない限り、「たぶん合っている」という前提そのものが、レビューする側にも引き継がれてしまいます。

私たちがクライアントの現場でこの違和感を口にしたとき、あるエンジニアリングマネージャーがこう返してくれました。「セルフレビューは効きます。でも、それだけで安心していいのかは、正直まだ分かりません」。この一言が、今回の記事のきっかけになっています。同じ実装を担当したエージェントに、そのままレビューまで任せてよいのか。この問いは、人間のチームで例えるなら、実装者と承認者を同一人物にしてよいかという話に近いものです。

「観点を全部詰め込むと、どれも浅くなる」

疑問を抱えたまま調べていくと、同じ問題意識を持つエンジニアの記事に行き当たりました。単一のAIレビュアーに複数の観点を持たせる設計について、あるエンジニアのQiita記事は「観点を全部詰め込むと、どれも浅くなる」と指摘しています。コードがきれいに書けていると、要求を満たしているかどうかの判定まで甘くなってしまう、というのです。

この記事では、レビューを「正しく作ったか(Verification)」を見るcode-verifierと、「正しいものを作ったか(Validation)」を見るrequirement-validatorという2つの役割に分けています。前者は差分を読み、バグやエッジケースを内側から確認します。後者は要件から読み始め、利用者にとっての価値を外側から確認します。著者は「必要な情報も判断基準も別物」だと述べ、完璧に動くのに見当違いという成果物を捕まえるには、後者が欠かせないと説明しています。

これは私たちの実感とも一致します。技術的に正しいことと、求められているものであることは、別の軸で判断しなければなりません。AIコードレビューの精度を上げたいなら、まず「何を見る役割なのか」を1つのエージェントにつき1つだけに絞ることから始めるべきだ、と私たちは考えています。役割を欲張るほど、レビューの網は広く浅くなっていくからです。

「レビューして」と「敵対的検証して」は何が違うのか

もう一つ、興味深い指摘をしている記事がありました。ある技術ブログの記事は、「レビューして」という指示と「敵対的検証して」という指示の違いを、明確に言語化しています。前者は指摘を返しますが、後者は「課題がある」という前提に立って反証を試み、判定と根拠まで返す、というのです。

著者が実際に切り口案の検証を依頼したところ、敵対的検証は3体のスケプティック(懐疑者)を並列で起動し、「読者視点」「主張の正しさ」「記事としての成立性」に分けて判定と根拠を返してきたといいます。単に「良い」「悪い」ではなく、なぜそう判断したのかまで示されることで、採否の判断がしやすくなったそうです。私たちがクライアントに導入を提案するときも、この「根拠まで返ってくるかどうか」の差は、実際に運用してみるまで伝わりにくい部分だと感じています。

Claude Code公式も名前付きで推奨する「懐疑者」という役割

ここまで読んで、「一部の熱心なエンジニアの工夫では」と思われた方もいるかもしれません。ですが、これは個人の工夫にとどまりません。Anthropicの公式ドキュメントには、敵対的検証(Adversarial verification)が名前付きのパターンとして定義されており、「レビューステップを敵対的にする」という専用のセクションがベストプラクティスとして存在します。

具体的には、深い調査を行うスキルの中で「懐疑的であれ。この主張を反証せよ」という指示がプロンプトに埋め込まれている例や、コードレビュー機能で複数のエージェントが検出した後、別のエージェントが再検証する仕組みが確認できます。重要な設計上の選択は、作業をしたエージェント自身には採点させず、まっさらな文脈を持つ別のモデルに委ねる点です。これにより、「流れに合わせて甘く採点してしまう」という迎合を排除しています。

なぜここまで丁寧に役割を分ける必要があるのでしょうか。理由は、AIエージェントが会話の文脈に強く影響される性質を持っているからです。実装を担当したエージェントと同じ会話の続きでレビューを頼むと、そのエージェントは無意識のうちに自分の実装を弁護する方向に寄っていきます。人間でも、自分が書いたコードを自分で見直すときには、同じような心理が働きます。だからこそ、会話ごとリセットした「まっさらな懐疑者」を立てることに意味があるのです。私たちのクライアントワークでも、実装を担当したエージェントとレビューを担当するエージェントの間には、意識して距離を置くようにしています。

実例——一方が見落とし、もう一方が拾った指摘

抽象的な話だけでは実感が湧きにくいので、具体的な例を紹介します。あるエンジニアブログの記事では、Claude CodeとOpenAI Codexという異なる系統のAIで同じ成果物をレビューさせた事例が紹介されています。

Slack通知のスレッド化機能を設計した際、認証トークンが画面上でマスクされずに表示されてしまう設計と、リトライ処理がSlack固有の処理をバイパスしてしまう構造という2つの重大な問題を、Codexが指摘しました。実装した側のClaudeの自己レビューでは、どちらも検出されなかったといいます。

別のケースでは、AWS Config v2への移行時、比較ロジックがあるオプション項目を「未設定」と暗黙のうちに前提していた箇所がありました。テストはすべて合格していたにもかかわらず、Codexが「実際のAPIレスポンスでは値が返る可能性がある」と指摘し、実機検証で問題が確認されたそうです。テストが通っていることと、実際の挙動が正しいことは、別の話だということがよく分かる例です。著者はこの記事で「自己レビューだけで進めていたら、認証トークンがマスクされず画面に出る設計のまま実装に進んでいたでしょう」と率直に振り返っています。ここで見落とされていたのは高度なロジックの誤りではなく、「そのAPIは本当にその値を返さないのか」という前提の確認漏れでした。系統の異なる目を通すことで、初めて疑いの余地として浮かび上がってきたのです。

検証の型は「検出→懐疑的な再検証→除外」の3段階

これらの事例に共通する型を整理すると、検証のプロセスは「検出」「懐疑的な再検証」「除外」の3段階に分けられます。まず何らかの方法で問題の候補を検出し、次にその候補を疑ってかかる別のエージェントが再検証し、根拠が弱いものは除外していく、という流れです。

ここで肝心なのは、②の懐疑的な再検証を担うエージェントに、fresh contextを持たせることです。検出を行ったエージェントと同じ文脈を引き継いでしまうと、同じ思い込みを共有したまま「たしかにそうですね」と追認するだけになりかねません。私たちがクライアントの現場でサブエージェントを設計するときも、役割ごとに別々の会話として起動し、あえて前提知識を渡しすぎないようにしています。

Claude Codeのマルチエージェントによるレビューを組むときに私たちが欠かさず確認するのは、①検出を担うエージェントと②再検証を担うエージェントが、本当に別の会話として起動されているかどうかです。同じ会話の中で役割名だけを変えて「では次に懐疑者として見てください」と頼んでも、直前までの発言に引きずられてしまい、本当の意味での再検証にはなりません。地味な確認ですが、この設計を怠ると、敵対的検証という名前だけを借りた、実質的にはセルフレビューと変わらない仕組みになってしまいます。

それでも「AIの指摘は正解ではない」——人間が握るべき一線

ここまで敵対的検証の効果を紹介してきましたが、誤解のないように言えば、これは万能な仕組みではありません。Anthropic自身が、この手法には4つの限界があると認めています。敵対的なレビュアーは健全な成果物にも指摘を出してしまうこと、逆方向の失敗(本来指摘すべき問題を見逃す手抜き判定)のほうがむしろ危険であること、コストがかかること、そして同じモデルを使えば盲点も共有してしまうこと、の4つです。

先ほど紹介したクロスレビューの記事でも、「ソースコードを変更する前と、git pushする前だけは、人間がレビューする。ここは譲りません」と明言されています。理由として挙げられているのは、責任が移る地点で当事者性を保つための設計判断だという点です。エージェント側にはpushの権限そのものを与えず、構造と運用ルールの両面で人間がゲートを握る。この考え方は、私たちが前回の記事でお伝えした「AIは壁打ち相手であり、判断は人間がする」という姿勢と、まったく同じ方向を向いています。

コストという現実——トークンは3〜10倍に増える

率直に申し上げると、敵対的検証にはコストという現実の壁があります。マルチエージェント構成では、単発のレビューに比べてトークン消費が3〜10倍に増えるという計測結果が、Anthropicの内部テストで示されています。クロスレビューの記事でも、「2ヘッドに分割すると単発レビューの数倍のトークンを見ておくと安全」と、著者は正直にコストを開示しています。

つまり、すべてのPRにこの仕組みを適用するのは現実的ではありません。私たちがクライアントに提案する際も、設計変更を伴う重要なPRや、認証・決済のように失敗した際の影響が大きい領域に絞って適用することを勧めています。すべてを疑い続けるのではなく、どこで疑うコストをかけるかを設計すること自体が、これからのエンジニアリングマネジメントの仕事になっていくと考えています。

私たちが中堅企業の現場で見た「検証コスト」の壁

この「どこまでコストをかけるか」という判断は、実際にはかなり悩ましいものです。前回の記事でも触れたように、中堅企業ではレビューできる人間が社内に1〜2人しかいない、というケースが珍しくありません。そこにトークン消費が数倍になる仕組みを追加するとなると、経営側からは「そのコストに見合う成果が出るのか」という当然の疑問が出てきます。

私たちがFDEとして中堅企業の内製化を支援する中で見えてきたのは、この判断を工数の大小ではなく、失敗した場合の影響範囲の大小で決めるべきだ、という考え方です。社内向けの管理画面の細かい表示崩れと、顧客の決済情報を扱う処理では、見落としたときの重さがまったく違います。私たちは新しい仕組みを提案するとき、まず「壊れたら誰がどれだけ困るか」を一緒に洗い出すところから始めています。その上で、影響の大きい領域だけに敵対的検証を絞って適用すると、コストの増加分をクライアントに具体的な言葉で説明しやすくなります。逆に言えば、この絞り込みを飛ばしていきなり全体に適用しようとすると、コストばかりが目立ち、現場に定着しないまま形骸化してしまうことが多いというのが、私たちの実感です。

AI-Pathの見解——「信用」と「信頼」を分けて考える

私がクライアントとの対話でよく口にする言葉に、「信用(信じて用いる)」と「信頼(信じて頼る)」を区別する、という考え方があります。信用は、実際に使ってみて確かめることでしか積み上がりません。敵対的検証という仕組みは、この「信じて用いる」という態度を、AIエージェントとの向き合い方にそのまま当てはめたものだと私たちは捉えています。AIの指摘を無条件に信頼するのではなく、まず疑い、根拠を確かめてから、初めて信用する。この順番を仕組みとして固定化したものが、敵対的検証なのだと思います。

もう一つ付け加えると、私たちがクライアントの内製化を支援する中で見えてきたのは、セルフレビューと敵対的検証は対立する選択肢ではない、ということです。セルフレビューで軽微な指摘の大半を潰し、それでも残る重要な判断だけを敵対的検証に回す。この二段構えにすることで、コストを抑えながら精度を上げることができます。すべての工程を疑い続けるのは非効率ですが、どこか一段階も疑わないままでは、いずれ大きな見落としにつながります。

私は、AIエージェントとの向き合い方について「AIは信用するのではなく、こちらの考えをぶつけ、前提情報や意図を渡し続けることで深い対話が生まれる」とも常々考えています。敵対的検証は、この対話をレビューの工程に持ち込む試みだと私たちは考えています。一方的に指摘を受け取るのではなく、AI同士に前提をぶつけ合わせ、その応酬から根拠を引き出す。エージェントの台数を増やすほど便利になるはずが、かえって疲弊する——前回の記事で紹介したこの逆説を乗り越えるには、量を増やすことよりも、疑う仕組みをどこにどう組み込むかを設計する側の視点が欠かせないというのが、私たちの結論です。

よくある質問

Q1. 敵対的検証を導入すれば、人間のレビューは不要になりますか？

いいえ。むしろ逆です。敵対的検証は指摘の「候補」を精度高く絞り込む仕組みであり、最終的にどの指摘を採用するかを決めるのは人間です。私たちの現場でも、ソースコードの変更前とpush前の判断は、人間が担う運用を崩さないようにしています。

Q2. セルフレビューと敵対的検証、両方とも必要ですか？

多くの場合は両方を組み合わせるのが現実的です。セルフレビューで日常的な指摘の大半を処理し、設計変更を伴う重要なPRや影響範囲の大きい変更に限って敵対的検証を追加する、という二段構えを私たちは勧めています。

Q3. 個人開発でも意味がありますか？

意味はありますが、優先度は下がります。トークンコストに見合うのは、レビュー担当者が限られている中堅企業のチーム開発や、失敗時の影響が大きい機能です。個人開発ではまずセルフレビューの型を固めることを先に勧めます。

Q4. どのAIの組み合わせを選べばよいですか？

異なる系統のモデルを組み合わせるほど、盲点が重なりにくくなります。同じモデルの2インスタンスでも役割分担の効果は得られますが、学習データや癖が近い分、同じ見落としを共有しやすくなります。まずは手元で使えるツールの中から、性質の異なる組み合わせを試すところから始めるのが現実的です。

まず試すなら

1. まず1つの重要なPRだけで、code-verifier役とrequirement-validator役のように、性質の異なる2つのサブエージェントを試してみる
2. 一方のエージェントの指摘を、fresh contextを持つ別のエージェントに「本当にそうか」と再検証させる工程を1つ加えてみる
3. 自社のレビュー体制のどこにボトルネックがあり、どこまでAIに任せられるかを、無償の業務プロセス診断(BPR)で一緒に洗い出す

参考リンク

• AIに「レビューして」はもう古い？「敵対的検証」のすすめ
• AIが速くなるほどレビューが詰まる ─ Claude Codeで「正しく作ったか」と「正しいものを作ったか」を別エージェントに分ける
• [Claude Code] OpenAI Codexとのクロスレビュー運用 - 自己レビューの盲点を別系統のAIで埋める
• レビューが開発の壁になる時代——AIエージェント企業が始めるべき『セルフレビュー』という仕組み