Claude Codeで複数AIを対立させ判断ミスを潰す｜マルチエージェント検証
AI は自信たっぷりに間違える。ひとつの AI に任せきると、その AI が持つ思い込みごと結論を受け取ってしまう。当社は学習源の違う AI を意図的に対立させ、反証し合わせる検証を実運用しています。
Radineer 編集部 ・ 自社の Claude Code 本番運用に基づく解説（2026 年 5 月時点）
マルチエージェント検証とは、複数の AI エージェントに役割を割り当てて互いの主張を反証させ、単一 AI では見抜けない事実誤認やハルシネーションを検出する手法を指す。学習源の異なる AI を意図的に対立させることで、ひとつのモデルに共通する思い込みを突き崩す。
なぜ単一 AI の判断は危険か
AI は、間違っているときでも文体は正しいときと変わらない。だから単一の AI に判断を任せると、その AI が事実を取り違えていても、もっともらしい結論として受け取ってしまう。
さらに厄介なのは、同じモデルに「本当に合ってる?」と聞き直しても、同じ思い込みの上で「合っています」と返しがちなことだ。自己点検は、自分の死角を点検できない。
だから当社は、検証を「同じ AI に聞き直す」のではなく「別の AI にぶつける」設計にしている。
Solver-Proposer-Checker 型
当社は /debate という自作の検証スキルを運用している。中核にあるのが Solver / Proposer / Checker の 3 エージェント構成だ。
ざっくり言えば、解を出す役・別案や反論を出す役・整合性を突く役に分かれ、互いの主張を反証し合う。ひとつの結論をそのまま通すのではなく、別の役割の AI が「ここが弱い」と突くことで、通る結論は反証をくぐり抜けたものだけになる。
この構成は MARCH / Microsoft CORE といったマルチエージェント検証の研究に基づいて実装しており、誤って「問題あり」と騒ぐ false positive(誤検出)の低減が期待できる設計になっている。
- Solver：まず解・結論を出す
- Proposer：別案や対立する主張を立てる
- Checker：整合性・事実関係を突く
学習源の違う AI を当てる
反証の効きは、ぶつける AI の「出自」が違うほど高まる。同じ学習データ・同じ系統のモデル同士では、同じ間違いを共有しているからだ。
当社は Claude / Gemini / Codex という学習源の異なる AI を意図的に対立させている。さらに Web 検索を併用して、各 AI の主張を外部の一次情報に突き合わせる。AI 同士の議論を AI の中だけで閉じさせない、というのがポイントだ。
異なる出自の AI が同じ結論に達したなら確度は高い。割れたなら、そこが検証すべき論点だと分かる。
実例：事業判断を多 AI で反証
当社はこの方式を、コードだけでなく事業判断そのものに使っている。新規事業をやるべきか、価格設定をどうするか、といった意思決定を、複数 AI に反証させてから決める。
単一 AI に「この事業はいけますか」と聞けば、たいてい前向きな答えが返る。だが Solver / Proposer / Checker に学習源の違う AI を当て、Web 検索で裏を取りながら反証させると、見落としていた前提や弱い根拠が表に出てくる。
結論を「やる/やらない」で受け取るのではなく、「どの論点で意見が割れたか」を意思決定の材料にしている。
forecast(将来予測)モード
事実関係の検証とは別に、将来予測系の主張には forecast モードを使う。
「この市場はこう伸びる」「この施策はこう効く」といった未来の話は、反証だけでは詰めきれない。そこで、関係するステークホルダーをそれぞれエージェント化し、多ラウンドのシミュレーションを回して、起こりうるシナリオの分布を出す。ひとつの予測値ではなく、幅として将来を見る。
断定的な単一シナリオを鵜呑みにせず、楽観・保守も含めた分布で判断するための仕組みだ。
検証モードの使い分け
「事実を確かめたい」のか「未来を見積もりたい」のかで使うモードが変わる。下表で整理する。
| 検証したいもの | 使うモード | 出てくるもの |
|---|---|---|
| 主張・実装・事実関係 | Solver-Proposer-Checker(反証) | 反証をくぐり抜けた結論と弱い論点 |
| 事業判断(やる/やらない・価格) | 多 AI 反証 ＋ Web 検索 | 割れた論点＝意思決定の材料 |
| 将来予測系の主張 | forecast(エージェント・シミュレーション) | 単一値でなくシナリオの分布 |
よくある落とし穴
- 同じ AI に聞き直して検証した気になる：自分の死角は点検できない。学習源の違う AI をぶつける。
- Critic の AI が出す数字を鵜呑みにする：反証側 AI の計算も間違う。保守・楽観・固定費の整合は自分で再計算して確かめる。
- Gemini のクォータ枯渇を見落とす：特定ベンダーの利用上限に当たると検証が片肺になる。枯渇時は別ベンダーに振り替える。
- forecast の単一シナリオだけ見る：分布で見るための仕組みなので、幅で判断する。
よくある質問
なぜ同じ AI に聞き直すのではダメなのですか？
同じモデルは同じ思い込みを共有しているため、自己点検で死角を見つけられない。当社は学習源の異なる Claude / Gemini / Codex を意図的に対立させ、外部の Web 検索も併用して反証させている。
Solver / Proposer / Checker とは何ですか？
解を出す役・別案や反論を出す役・整合性を突く役に分かれた 3 エージェント構成。互いに反証し合うことで、反証をくぐり抜けた結論だけが残る。MARCH / Microsoft CORE の研究に基づく実装で、誤検出の低減が期待できる。
事業判断にも使えますか？
当社は新規事業の是非や価格設定といった意思決定をこの方式で検証している。結論を鵜呑みにするのではなく、AI 同士で意見が割れた論点を意思決定の材料にしている。
将来予測はどう検証しますか？
forecast モードで、関係するステークホルダーをエージェント化し多ラウンドのシミュレーションを回してシナリオの分布を出す。単一の予測値ではなく幅で判断する。ただし反証側 AI が出す数字も鵜呑みにせず自分で再計算する。