ファクトチェックの典型手順と、工程ごとのエージェントの使い分け——事実320件の裏取りから（セッション編）

ファクトチェックは「事実を1件ずつ確かめる」単純作業に見えて、実際は決まった工程を踏む。そして工程ごとに、向いているエージェントの使い方が違う。並列ツールで足りるところ、サブエージェントを立てるべきところ、そもそも LLM に渡してはいけないところがある。

この記事は、解説マンガ1話ぶんの事実320件を裏取りして出典ページに仕立てた1セッションを題材に、ファクトチェックの典型手順と、各工程でのエージェント活用を地図にしたものだ。パターンの物差しには Anthropic の5分類（Prompt Chaining / Routing / Parallelization / Orchestrator-Workers / Evaluator-Optimizer）を使う。

典型手順は7工程

どの題材でも、ファクトチェックはだいたいこの順で進む。

1. 主張の抽出 — 原稿から検証できる事実主張を1件ずつ取り出す
2. 分類・優先度付け（triage） — 種類で仕分け、誤ると致命的なものを先に
3. 証拠収集（fan-out） — 各主張を一次・準一次ソースに当てる
4. 照合・判定 — ソースと突き合わせ、確信度つきで判定する
5. 訂正 — 誤り・不正確を正しい記述へ直す
6. 出典の実在・健全性チェック — リンクが生きているか、内容が主張を支えるか
7. 合成 — 出典つきの成果物に組む

エージェントの使い分けは、この工程ごとに見ていくのが一番わかりやすい。

1. 主張の抽出 ── 決定論に寄せる

確定原稿から「年号・金額・人物・条文・技術仕様」など検証できる主張を抜き出す。今回は約320件。

活用：ここは LLM の自由作文に任せない。 「全部ていねいに抜き出して」と頼むと、件数も粒度もぶれて再現できない。確定原稿が構造化されているなら、抽出はスクリプトで決定論的にやる。割り方に裁量が要る（曖昧な原稿から論点を立てる）ときだけ LLM を使い、その出力も件数とIDを固定して扱う。抽出が安定しないと、以降の並列化の単位が定まらない。

2. 分類・優先度付け ── Routing で濃淡をつける

抽出した主張を種類で仕分ける。数値・日付・固有名詞・条文・技術仕様……。そして「誤ると致命的」なものに重みを置く。今回なら第3部（事件・金額・規制条文が最密）が最優先で、ここは94件を別ファイルに切って濃く当てた。

活用：Routing。 カテゴリごとに当てる先（レンズ）を変える。数値・事件は一次報道と公的統計、法令は条文原文（要約サイトを孫引きしない）、技術仕様は規格そのもの（EIP/ERC）。優先度に応じて fan-out の濃さ（当てるソース数・多視点の数）を変える。全主張を同じ強さで当てるのは無駄が多い。

3. 証拠収集 ── Parallelization が主役、深掘りはサブエージェント

各主張を Web の一次・準一次ソースに当てる。検索して、取得して、読む。ここがファクトチェックの体力勝負だ。

活用：まず Parallelization。 独立な主張・URLは並列ツール（WebSearch / WebFetch）で同時に当てる。今回、死んだリンクの正URLを探すときは検索を9本同時に投げた。ここで大事な線引きが1つ——並列ツール呼び出しはサブエージェントの群れではない。投げて返りを1つのコンテキストで読むだけなら、エージェントを立てる必要はない。

サブエージェントが効くのは3か所だけ。 ①深掘り——1つの論点に大量の資料を読み込ませ、結論だけ持ち帰らせる（ファイルの山ではなく地図が欲しいとき）。今回はサイト構造の調査に Explore を1体使った。②コンテキスト分離——本筋を汚さずに別系統の調査を回す。③多視点の verify（後述）。「速くしたい」だけなら並列ツール、「文脈を分けたい・別の人格で見たい」ならサブエージェント、と割る。

法令のように一次資料への到達自体が難しい領域は、専用の調査パイプラインをサブエージェントとして切るのが向く。今回の日本法パートは、判例KB・グレーゾーンKB・e-Gov・Web を束ねるハイブリッド検索で、検索ヒットを出典にせず条文・判例の原文へ橋渡しする調査を別建てにした。

4. 照合・判定 ── Evaluator、確信度を必ず出させる

ソースと突き合わせて判定する。今回は5段にした。

✓ 正しい / △ 不正確 / ⚠ 断定リスク / ❓ 検証不能 / ❌ 誤り
＋ 確信度（高・中・低）＋ 根拠URL ＋ 修正案

活用：Evaluator パターン。 ポイントは2つ。確信度を必ず出させること（「✓」だけだと後で効かない。低確信を可視化しておくと、次工程で追加検証に回せる）。そして根拠URLを判定とセットで残すこと——これが工程6・7の素材になる。重い主張は多視点 verifyにする。同じ主張を「数値の正確さ」「時系列」「一次性」など別レンズのサブエージェントに当て、割れたら人間が裁く。ここが multi-subagent が一番素直に効く工程だ。

320件の内訳は ✓ 約272・△ 約30・⚠ 9・❓ 4・❌ 2。骨格の誤りは2件で、大半は例示・引用・単純化の精度。判定はこの「ほぼ正だが細部を直す」分布に向いたループになる。

5. 訂正 ── Optimizer ループ

❌ と要訂正の △ を、正しい記述に直す。判定とセットで「修正案」を持っているので、訂正は機械的に近い。

活用：Evaluator → Optimizer の閉ループ。 直したら、その記述をもう一度判定に通す（直した結果が別の不正確を生んでいないか）。出力ページ側では、訂正を生成スクリプトの上書きマップに持たせて、元データを再生成しても訂正が残るようにした。訂正を手で本文に書き込むと、再生成で消える。

6. 出典の実在・健全性チェック ── verifier を verify する

ここが抜けやすい。判定が ✓ でも、そのURLが本当に生きていて、内容が主張を支えているかは別問題だ。

今回、出来上がった後で出典143本をHTTP検査したら、200が122本、403が14本、404が4本。そのうち3本が判例PDFで、courts.go.jp がURL構造を変えていて旧URLが全滅していた（正しくは /assets/hanrei/hanrei-pdf-{id}.pdf）。「検証する」のが仕事のファクトチェックが、未検証の死リンクを ✓ で通していたわけだ。

# 出典URLを並列でHTTPステータス検査（エージェントではなく素のツール）
cat urls.txt | xargs -P 12 -I{} sh -c \
  'echo "$(curl -sIL -o /dev/null -w "%{http_code}" --max-time 20 "{}")  {}"'

活用：決定論（HTTP叩き）＋ Parallelization（正URLの再検索）。 リンクの生死は LLM に判定させず curl で確かめる。死んでいたものだけ並列検索で正URLを特定する。403（ボットブロックで実在）と404（消滅）を取り違えないのも大事で、403は検索インデックスで実在と内容を別途確認した。ファクトチェックは自分の出力を疑えない。実在チェックは独立した第二のパスとして必ず回す。

7. 合成 ── 決定論で組む

判定済みの主張と出典を、読める成果物（出典ページ）に組み直す。

活用：ここも決定論。 パイプ区切りの検証ファイルをパースして TypeScript のデータに落とし、ページが描画する。LLM は介在させない（件数・リンクがぶれるだけ）。元データ（検証結果）を直して再生成すれば、ページが追従する。

工程 × エージェント活用 早見表

使い分けの原則

工程をひと通り回して残った、実用的な勘どころ。

• 決定論にできる工程は LLM に渡さない。 抽出・合成・リンク生死は、スクリプトの方が速くて再現でき、幻覚が混ざらない。
• 並列化の単位は1主張・1URL。 割り方に裁量が要らないなら Parallelization で足り、Orchestrator-Workers は要らない。
• サブエージェントは数より配置。 「深掘り」「コンテキスト分離」「多視点verify」の3か所に効かせる。速くしたいだけなら並列ツール。
• 判定には確信度を、判定には根拠URLを。 低確信の可視化と、出典の保存が、後工程を生かす。
• verifier を verify する。 出典の実在チェックを独立パスで回す。「もっともらしい」で止めず、URLは叩き、PDFは開き、条文は原文に当たる。

派手な自律オーケストレーションは、ファクトチェックではあまり前に出ない。効くのは、工程ごとに正しい道具を当てること——決定論・並列ツール・サブエージェントを、それぞれの居場所に置くことだった。

この手順で仕上げた出典ページの実物は ステーブルコイン編 出典・裏取り にある。320件の検証リストと、一次資料（条文・判例）への当たり方を、そのまま開いて確かめられる。