第15回 疑う役を組織する（敵対的検証という発明）

作った本人に、自分の仕事の欠陥は見つけさせられない。

前回、Claudeが別のClaudeを起動する3つの仕組みを見た。数が増えるほど、扱える仕事の規模は大きくなる。だが数を増やしただけでは、間違いも同じ比率で増える。

品質管理の現場は、この問題をずっと前から知っていた。同じ人が出した指示を、同じ人がもう一度確認しても、同じ見落としを繰り返す。だからダブルチェックがある。だから査読がある。見る人を分けることそのものに意味がある。

エージェントの世界でも、構造は同じだ。第14回で見たAgent TeamsやDynamic Workflowsが規模を出せるのは事実だが、規模を安全に使うための鍵は、疑う役を独立させることにある。今回はその組み立て方を扱う。

なぜ本人チェックは効かないのか

同じ文脈にいる限り、本人チェックは同じ見落としを繰り返す。

ある指示を出したClaudeは、その指示が正しいという前提で仕事を進める。だから、その前提そのものが間違っていたときに気づきにくい。これは怠慢ではなく、同じ文脈の中にいる者の構造的な限界だ。

Anthropicのブログは、スキルという別の文脈で似た区別を語っている。

「動きそうに見える」と「動くと分かっている」の間にある溝。これを埋めるのが検証で、検証を担う人格を作った本人と分けるのが敵対的検証だ。第0回で見た「あなた自身が検証ループになってしまう」という罠は、実はここにもつながっている。人間がその溝を毎回埋めているうちは、疲れる。疲れれば見落とす。だから溝を埋める役目を、別のエージェントに持たせる。

この見落としは、エージェントだけの話ではない。Flask・Jinjaの作者であるArmin Ronacherは、LLMによる自動化そのものに潜む別のリスクを指摘している。

つまり、疑う役が要るのはエージェント側の構造的な限界だけが理由ではない。任せる人間の側も、考えることをやめた瞬間に同じ見落としを重ねる。だからこそ疑う役は、「気をつける」という心構えではなく、別の人格として組織に組み込む必要がある。

作る役と疑う役を分ける

この2つの役は、同じ人格に持たせてはいけない。

ここで重要なのは、疑う役に作る役と同じ情報だけを渡し、同じ結論に誘導しないことだ。作る役の作業ログをそのまま読ませると、疑う役もその文脈に引きずられて同じ見落としをする。独立したコンテキストで、独立に確かめさせて初めて意味がある。

見る人を変えるという発想は、エージェントの役割設計だけの話ではない。Django共同創業者のSimon Willisonは、AIでソフトウェアを作る態度そのものを2つに分けている。

Willisonはこれを「バイブコーディング」と呼び、その対極を「バイブエンジニアリング」と名付けた。経験を積んだプロがLLMで仕事を加速させながらも、自分が生み出すコードに説明責任を持ち続けるあり方だ。両者を分けるのは使うツールの違いではない。作った結果を、自分自身で疑う構えを持っているかどうかだ。疑う役を組織することは、この構えを一人の裁量に頼らず、仕組みとして持たせる試みでもある。

規模が増えるほど効く理由

疑う役を立てるコストは、仕事の件数が増えるほど割に合うようになる。

疑う役を分けるコストは、仕事が1件しかないときはあまり割に合わない。1件のために独立したレビュアーを立てるのは、確かに手間がかかる。

だが仕事が10件、100件になると話が変わる。間違いの絶対数は仕事の件数に比例して増えるが、疑う役を立てるコストは1回の設計で済む。第14回で見たDynamic Workflowsのように、独立エージェント同士が発見を敵対的にレビューしてから報告する構成が公式にも言及されているのは、この非対称性があるからだ。件数が少ないうちは効果を実感しにくく、件数が増えたときに初めて効いてくる仕組みだと理解しておく。

Thariq Shihiparは、複雑さを足すこと自体には慎重であるべきだと語っている。

疑う役を組織することも例外ではない。1件の仕事に3人の疑う役を立てるのは、たいてい過剰だ。件数と重大度に見合った疑う役の数を選ぶ。ここでも「増やせば安全」という発想は罠になる。

現場で起きたケース

実際にあった例を見ると、この効果がわかりやすい。

実際の組み方

独立したコンテキストを、今度はレビューのためだけに使う。

$
-p
"実装内容には触れず、要件定義書だけを見て、このテストスイートに抜けている条件分岐を指摘して"
Spawning independent review agent (no prior context)... Found 2 uncovered
branches: null-safety check, boundary value at max order quantity.

-p フラグや別セッションでの起動は、第8回で「2体目を立てる」ときにすでに触れている。疑う役の組織化は、その延長にある新しい使い方だと捉えるとつながりやすい。

独立したエージェントを立てるだけが、疑う役の組み方ではない。TDD（テスト駆動開発）の考案者であるKent Beckは、テストそのものを疑う役として使う手応えを語っている。

先に書いたテストは、実装より先に存在する独立した基準になる。実装したエージェントがどれだけ「動いている」と主張しても、テストが通らなければ疑う役の役目を果たす。ただしBeckは同じインタビューで、もう一つ手を焼いている問題も明かしている。エージェントがテストを通すために、テストの条件そのものを緩めたり削除したりしようとする挙動だ。テストという疑う役自体を作る役が書き換えてしまえば、検証は成立しない。

よくある誤解と罠

• 作る役に「もう一度確認して」と頼むだけで満足する: 同じ文脈にいる限り、同じ見落としを繰り返しやすい。独立させることそのものに意味がある
• 疑う役に作業ログをそのまま渡してしまう: それでは作る役の思い込みごと引き継いでしまう。要件や仕様など、独立した基準だけを渡す
• すべての仕事に疑う役を立てようとする: 複雑さは働きに見合って初めて許される。件数と重大度から逆算して、疑う役を立てる仕事を選ぶ
• テストが通ったことだけで安心する: 作る役がテストを通すために、テストの条件自体を緩めたり削除したりすることがある。テストが疑う役として機能しているか、要件に照らして時々確かめる

今日のまとめ

• 作った本人によるチェックは、同じ文脈の限界を持つ。だから疑う役を独立させる
• ダブルチェック・査読・指差呼称は、見る人を変えることで効いてきた発明。敵対的検証も同じ原理
• 疑う役を組織するコストは、仕事の件数が増えるほど割に合うようになる