■ 1. セルフレビューの限界
- セルフレビュー導入の成果:
- PR提出前にAIでセルフレビューを済ませる仕組みは複数の中堅企業で効果を出している
- ある卸売業のクライアントではベテランエンジニアのレビュー時間が約3割短縮された
- 残る懸念:
- 実装したAIエージェント自身に自分のコードをレビューさせている点が問題
- 自分の答案を自分で採点するのと同じ構図
- 「たぶん合っている」という前提がレビュー側にも引き継がれてしまう
- 問題提起のきっかけ:
- あるエンジニアリングマネージャーは、セルフレビューは効くがそれだけで安心してよいかは分からないと述べた
- 人間のチームでいえば、実装者と承認者を同一人物にしてよいかという問題に近い
■ 2. レビュー観点の分離
- 観点の詰め込みによる弊害:
- Qiita記事は「観点を全部詰め込むと、どれも浅くなる」と指摘している
- コードがきれいだと要求充足の判定まで甘くなる
- VerificationとValidationの分離:
- code-verifier:「正しく作ったか」を見る役割
- 差分を読み、バグやエッジケースを内側から確認する
- requirement-validator:「正しいものを作ったか」を見る役割
- 要件から読み始め、利用者にとっての価値を外側から確認する
- 両者は必要な情報も判断基準も別物
- 完璧に動くが見当違いな成果物を捕まえるにはrequirement-validatorが不可欠
- 1エージェント1役割の原則:
- 技術的な正しさと求められているものであることは別の軸で判断すべき
- AIコードレビューの精度向上はエージェントごとの役割を1つに絞ることから始めるべき
- 役割を欲張るほどレビューの網は広く浅くなる
■ 3. 「レビュー」と「敵対的検証」の違い
- 指示による出力の違い:
- 「レビューして」は指摘を返す
- 「敵対的検証して」は課題がある前提で反証を試み、判定と根拠まで返す
- 技術ブログでの実例:
- 切り口案の検証で3体のスケプティック（懐疑者）が並列で起動された
- 「読者視点」「主張の正しさ」「記事としての成立性」に分けて判定と根拠を返した
- 判断理由まで示されることで採否を決めやすくなった
- 根拠の有無の重要性:
- 根拠まで返ってくるかどうかの差は、実際に運用するまで伝わりにくい
■ 4. 公式に推奨される懐疑者の役割
- Anthropic公式の位置づけ:
- 敵対的検証（Adversarial verification）は公式ドキュメントで名前付きのパターンとして定義されている
- 「レビューステップを敵対的にする」という専用セクションがベストプラクティスとして存在する
- 具体的な実装例:
- 深い調査を行うスキルに「懐疑的であれ。この主張を反証せよ」という指示が埋め込まれている
- コードレビュー機能では複数エージェントの検出結果を別のエージェントが再検証する
- 設計上の要点:
- 作業したエージェント自身には採点させない
- まっさらな文脈を持つ別のモデルに採点を委ねる
- これにより流れに合わせて甘く採点する迎合を排除する
- 役割分離が必要な理由:
- AIエージェントは会話の文脈に強く影響される
- 同じ会話の続きでレビューを頼むと、無意識に自分の実装を弁護する方向に寄る
- 人間が自分のコードを見直すときにも同様の心理が働く
- 会話ごとリセットした「まっさらな懐疑者」を立てることに意味がある
- クライアントワークでも実装担当とレビュー担当のエージェント間に意識して距離を置いている
■ 5. 異なる系統のAIによるクロスレビュー事例
- 事例の概要:
- Claude CodeとOpenAI Codexという異なる系統のAIで同じ成果物をレビューさせた
- Slack通知のスレッド化機能:
- 認証トークンが画面上でマスクされずに表示される設計をCodexが指摘した
- リトライ処理がSlack固有の処理をバイパスする構造もCodexが指摘した
- 実装したClaudeの自己レビューではどちらも検出されなかった
- AWS Config v2への移行:
- 比較ロジックがあるオプション項目を暗黙に「未設定」と前提していた
- テストはすべて合格していた
- Codexが実際のAPIレスポンスでは値が返る可能性を指摘し、実機検証で問題が確認された
- テストが通ることと実際の挙動が正しいことは別の話
- 事例からの教訓:
- 著者は自己レビューだけなら認証トークンが露出する設計のまま実装に進んでいたと振り返っている
- 見落とされたのは高度なロジックの誤りではなく前提の確認漏れ
- 系統の異なる目を通すことで初めて疑いの余地が浮かび上がった
■ 6. 敵対的検証の3段階
- 検証プロセスの型:
- ①検出: 問題の候補を何らかの方法で検出する
- ②懐疑的な再検証: 候補を疑ってかかる別のエージェントが再検証する
- ③除外: 根拠が弱いものを除外する
- fresh contextの必要性:
- ②の再検証エージェントにはfresh contextを持たせることが肝心
- 検出側の文脈を引き継ぐと、同じ思い込みを共有したまま追認するだけになる
- サブエージェントは役割ごとに別の会話として起動し、前提知識を渡しすぎないようにしている
- 別会話での起動の確認:
- マルチエージェントレビューでは①と②が本当に別の会話として起動されているかを必ず確認する
- 同じ会話内で役割名だけ変えて懐疑者を頼んでも、直前の発言に引きずられる
- この設計を怠ると、名前だけ敵対的検証で実質はセルフレビューと変わらない仕組みになる
■ 7. 敵対的検証の限界と人間の役割
- Anthropicが認める4つの限界:
- 敵対的なレビュアーは健全な成果物にも指摘を出してしまう
- 本来指摘すべき問題を見逃す手抜き判定という逆方向の失敗のほうがむしろ危険
- コストがかかる
- 同じモデルを使えば盲点も共有してしまう
- 人間が握るゲート:
- クロスレビュー記事ではソースコード変更前とgit push前は人間がレビューすると明言している
- 責任が移る地点で当事者性を保つための設計判断
- エージェントにはpush権限そのものを与えず、構造と運用ルールの両面で人間がゲートを握る
- 「AIは壁打ち相手であり、判断は人間がする」という姿勢と同じ方向性
■ 8. コストの現実と適用範囲
- トークン消費の増加:
- Anthropicの内部テストではマルチエージェント構成でトークン消費が単発レビューの3〜10倍に増える
- クロスレビュー記事でも2ヘッド分割は単発レビューの数倍のトークンを見込むべきと開示している
- 適用範囲の絞り込み:
- すべてのPRへの適用は現実的ではない
- 設計変更を伴う重要なPRに絞って適用する
- 認証・決済など失敗時の影響が大きい領域に絞って適用する
- どこで疑うコストをかけるかの設計が、今後のエンジニアリングマネジメントの仕事になる
■ 9. 中堅企業における検証コストの判断
- 中堅企業の事情:
- レビューできる人間が社内に1〜2人しかいないケースが珍しくない
- トークン消費が数倍になる仕組みには経営側から費用対効果への疑問が出る
- 判断基準:
- 適用判断は工数の大小ではなく失敗時の影響範囲の大小で決めるべき
- 社内管理画面の表示崩れと顧客の決済処理では見落としの重さがまったく違う
- 導入の進め方:
- 新しい仕組みの提案は「壊れたら誰がどれだけ困るか」の洗い出しから始める
- 影響の大きい領域に絞ると、コスト増加分をクライアントに具体的に説明しやすくなる
- 絞り込みを飛ばして全体に適用すると、コストばかり目立ち定着せず形骸化しやすい
■ 10. 「信用」と「信頼」の区別
- 信用と信頼の違い:
- 信用は「信じて用いる」、信頼は「信じて頼る」
- 信用は実際に使って確かめることでしか積み上がらない
- 敵対的検証の位置づけ:
- 「信じて用いる」態度をAIエージェントとの向き合い方に当てはめたもの
- AIの指摘を無条件に信頼せず、まず疑い、根拠を確かめてから信用する
- この順番を仕組みとして固定化したものが敵対的検証
- セルフレビューとの二段構え:
- セルフレビューと敵対的検証は対立する選択肢ではない
- セルフレビューで軽微な指摘の大半を潰し、残る重要な判断だけを敵対的検証に回す
- これによりコストを抑えながら精度を上げられる
- すべてを疑い続けるのは非効率だが、一段階も疑わなければいずれ大きな見落としにつながる
- AIとの対話としての検証:
- AIは信用するのではなく、考えをぶつけ前提情報や意図を渡し続けることで深い対話が生まれる
- 敵対的検証はこの対話をレビュー工程に持ち込む試み
- AI同士に前提をぶつけ合わせ、その応酬から根拠を引き出す
- エージェントを増やすほど疲弊するという逆説を乗り越えるには、量より疑う仕組みの設計が欠かせない
■ 11. よくある質問
- 敵対的検証で人間のレビューは不要になるか:
- 不要にはならず、むしろ逆
- 敵対的検証は指摘の候補を精度高く絞り込む仕組みであり、採用を決めるのは人間
- ソースコード変更前とpush前の判断は人間が担う運用を維持している
- セルフレビューと敵対的検証の両方が必要か:
- 多くの場合は両方の組み合わせが現実的
- 日常的な指摘はセルフレビューで処理し、重要なPRや影響範囲の大きい変更に限り敵対的検証を追加する
- 個人開発での意味:
- 意味はあるが優先度は下がる
- トークンコストに見合うのは、レビュー担当者が限られる中堅企業のチーム開発や失敗時の影響が大きい機能
- 個人開発ではまずセルフレビューの型を固めることを優先する
- AIの組み合わせの選び方:
- 異なる系統のモデルを組み合わせるほど盲点が重なりにくい
- 同じモデルの2インスタンスでも役割分担の効果はある
- ただし学習データや癖が近い分、同じ見落としを共有しやすい
- まずは手元のツールから性質の異なる組み合わせを試すのが現実的
■ 12. 最初に試すべきこと
- 性質の異なる2つのサブエージェント:
- 1つの重要なPRだけでcode-verifier役とrequirement-validator役を試す
- fresh contextでの再検証:
- 一方の指摘をfresh contextを持つ別のエージェントに「本当にそうか」と再検証させる工程を加える