サブエージェントで調査を並列化して、報告を構造化して、きれいに集計できるようになった——その次にぶつかるのが「その中身、本当に合ってるの？」という壁です。この記事は、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