サブエージェントで調査を並列化して、報告を構造化して、きれいに集計できるようになった——その次にぶつかるのが「その中身、本当に合ってるの？」という壁です。この記事は、AIの出力に混じる“もっともらしい嘘”を、独立した検証エージェントで機械的にふるい落とす型の話です。

これは「サブエージェントの報告を構造化して並列調査をそのまま集計する」話の続編です。前回は形を揃える話でしたが、形が揃っても中身が正しいとは限りません。

Claude Code（Anthropicの公式CLI）で「読む・調べる・要約する」をエージェントに任せると、ほとんどは正しく返ってきます。ところが時々、実在しないファイルパス・存在しない設定項目・読み違えた数値を、堂々とそれっぽい文章で混ぜてきます。いわゆるハルシネーションです。

やっかいなのは、間違いほど自信たっぷりに書かれることです。10件の調査結果のうち1件が静かに間違っていると、その1件を信じて動いた先で事故になります。並列調査を自動化するほど、人間が全部を読み返すのは現実的でなくなり、「どれを信じていいか」が新しいボトルネックになります。

この記事では、筆者が横断調査をエージェントに任せるなかで効いた、「出力を別のエージェントに疑わせて裏取りする」型を紹介します。コードを書かせる用途ではなく、調査・要約・棚卸しの結果をどう信頼するか、の話です。

まず：同じAIに「これ合ってる?」と聞いても意味が薄い

最初にやりがちなのが、出力を返したそのエージェントに「本当に正しい?」と聞き返すことです。これはほぼ効きません。

同じモデルが同じ文脈の続きで自分の出力を見直すと、さっき自分が書いたものを正当化する方向に流れやすいからです。人間でも、自分の書いた文章の誤字を自分で見つけにくいのと似ています。「合ってますか?」と聞けば「合っています」と返ってくる確率が上がるだけで、裏取りにはなりません。

ポイントは2つです。

検証は別のエージェント（独立した文脈）にやらせる
「正しいか確認して」ではなく「間違っていることを証明してみて」と疑わせる方向に倒す

解決：独立した検証エージェントに「疑ってかかれ」と渡す

検証エージェントへの指示を、肯定前提から反証前提に変えるだけで、拾える誤りが変わります。

Before（肯定前提・素通りしやすい）

次の調査結果が正しいか確認してください。
- 「設定ファイル config/app.yml の timeout は 30 と書かれている」

→ 「はい、正しいです」で素通りしがち。確認した気になって終わる。

After（反証前提・裏取りになる）

次の主張が「本当に成立するか」を、疑ってかかって検証してください。
あなたの仕事は主張を擁護することではなく、間違いを見つけることです。
根拠が実ファイル・実データで確認できないものは「判断不能」にしてください。

- claim: 設定ファイル config/app.yml の timeout は 30 と書かれている
- 検証手順: 実際に該当ファイルを開いて、その行が存在するか確認する
- 返す形式:
  - verdict: 成立 / 不成立 / 判断不能
  - evidence: 根拠（どのファイルのどの記述か。確認できなければ「確認できず」）

「擁護するな、間違いを探せ」「確認できなければ判断不能と書け」——この2文を入れるだけで、検証エージェントは推測で「成立」と言わなくなります。前回の記事で触れた 「分からないものは unknown と明示させる」 のと同じ発想を、検証フェーズにも効かせるわけです。

一段上：1体ではなく「多数決」で安定させる

検証エージェントも結局は同じLLMなので、1体だとたまに検証側が間違える（成立を不成立と取り違える、その逆も）ことがあります。そこで、重要な主張については 独立した検証を複数体に並行で投げて、多数決を取ると安定します。

（同じ claim を、独立した検証エージェント3体にそれぞれ渡す）

この主張が成立するか、疑ってかかって検証してください。
擁護せず、間違いを探す立場で。確認できなければ「判断不能」。
- verdict: 成立 / 不成立 / 判断不能
- evidence: 根拠

3体中2体以上が「不成立」なら、その指摘は機械的に落とす。割れたら（成立2/不成立1など）人間に上げる。こうすると、1体のブレに全体が引きずられにくくなります。

実務での使い分けはこの程度の割り切りで十分でした。

状況	検証のかけ方
大量の軽い項目をざっと見たい	検証は省く or 1体だけ
後の判断に効く重要な主張	独立3体で多数決
致命的に効く1件（消す・送る・公開する系）	多数決で機械的にふるった上で、最後は人間が確認

入力も出力も「構造化」しておくと、検証が部品になる

前回の「報告を決まった型で返させる」が効いてくるのはここです。調査結果が claim / verdict / evidence のような同じ型で揃っていれば、検証フェーズはその型をそのまま入力にできます。

1回目の調査エージェント → claim の一覧を構造化して返す
2回目の検証エージェント（独立・複数体）→ 各 claim に verdict と evidence を付けて返す
親（人間）→ verdict が「不成立」「判断不能」のものだけ見ればいい

全部を読み返すのではなく、機械が弱い指摘をふるい落とした後の“怪しい残り”だけを人間が見る。これで「並列調査 → 集計 → 裏取り」が一本の流れになります。

落とし穴：検証は「保証」ではなく「ふるい」

ここを勘違いすると逆に危ないので明記します。

検証エージェントも同じLLMで、絶対ではありません。 多数決でも全員が同じ誤りに倒れることはあり得ます。これは「正しさの保証」ではなく「明らかに弱い・怪しい指摘を機械的にふるい落とす」仕組みです。
最終判断は人間が握る前提で使ってください。特に「消す・送る・公開する・課金する」など取り返しのつかない操作の前は、ふるった後に人間が確認する一段を必ず残します。
コストは増えます。 1件を3体で検証すれば単純に呼び出しが増えます。だから全項目ではなく「後の判断に効く主張」だけに絞るのが現実的です。
検証手順を具体的に指定する。 「確認して」だけだと検証側も推測で答えます。「該当ファイルを実際に開いて確認」のように、何を見れば裏が取れるかまで指示に書くと精度が上がります。

まとめ

型	要点
別エージェントに検証させる	出力した本人に聞かない。独立した文脈で裏取りする
反証前提で渡す	「正しいか確認」ではなく「間違いを探せ・擁護するな」
判断不能を許可する	確認できないものを推測で「成立」と言わせない
重要なものは多数決	独立3体などで投げ、過半数でふるう。割れたら人間へ
検証は保証でなくふるい	最終判断は人間。取り返しのつかない操作の前は必ず人手で確認

並列調査は「速く集める」だけでは半分です。集めた中身をどう疑うかまで設計して、はじめて自動化した調査を実務で信頼できるようになります。

まず1つだけ試すなら

仕組みを丸ごと組む必要はありません。次にAIに何かを調べさせたとき、その結果を別のチャット／別のエージェントに、この一文を付けて渡すだけで十分です。

次の内容について、擁護せず「間違いを探す」立場で検証してください。
実データで確認できないものは「判断不能」と書き、推測で「正しい」と言わないこと。
- verdict: 成立 / 不成立 / 判断不能
- evidence: 根拠（確認できなければ「確認できず」）

これだけで、「たぶん合ってる」で流していた出力に、機械的なふるいが1枚かかります。まずは大事な1件の裏取りから試してみてください。

補足：試すための無料リポジトリ

サブエージェント運用の土台になるCLAUDE.md設計や、各サブエージェントに渡す計画・検証の型を、そのまま使えるスキルとして無料リポで公開しています（個人事業主・StreamSoltyとして運営しています）。

無料スターター（GitHub・CC BY 4.0）:
https://github.com/noguso245-jpg/claude-code-skills-starter

クローンして自分のプロジェクトにコピーすればそのまま使えます。役に立ったら GitHub で ⭐ Star をいただけると、新しい無料スキルを追加する励みになります。

最新のTipsはXでも発信しています: @k___n___t_1125