解説マンガ1話分の法令リサーチを、エージェントに〈クエリ砕き → ハイブリッド検索 → MCPで一次資料〉まで遡らせる──プロンプト・DoD・補足調査の組み立て

ファクトチェックの裏話を 2 本書いた。同じ解説マンガ1話の制作で、もう1本だけ別の裏側を残しておきたい。法令リサーチ だ。

マンガの中で「JPYC は電子決済手段で、暗号資産じゃない」「契約箱を発行・配布するだけなら仲介業の登録対象にはならない方向」「NFT の有償・無償は規制軸ごとに効き方が違う」と言うには、要約サイトの孫引きで済ませてはいけない。条文・判例・行政解釈の原文まで遡って、出典付きで「足場のある枠組み」と「先例がなく解釈で埋める当てはめ」を分けて書く必要がある。これをエージェントにやらせた。

法令の領域でエージェントを動かすときの 最大の敵はハルシネーション だ。LLM は条文番号も判決日も事件番号もそれっぽく捏造する。ありもしない判例を「最高裁が同旨」と引用する。要約サイトの孫引きを信じて、改正前の条文で当てはめを書く。

これが現実に起きた事故として、米国の Mata v. Avianca (2023, NY 南部地区連邦地裁) がある。弁護士が ChatGPT で作った準備書面に 実在しない判例が複数引用 されていて、裁判所は弁護士に 5,000 ドルの制裁金を科し、「弁護士はゲートキーパーとして提出書面の正確性を確保する義務がある」と判示した。LLM の出力をそのまま一次資料として扱うと、こうなる。

ここでの誤りは、マンガに載った瞬間に読者を間違った行動に向かわせる から、検索・取得・引用・引き換えの全段で「LLM の知識を出典にしない」を貫く必要がある。本記事の設計は、つきつめると ハルシネーションを潰すための仕掛けの集合 だ。

成果物の現物は ステーブルコイン編 条文・判例の調べもの に置いてある。条文の原文引用、判決 PDF へのリンク、調査プロセスの記録までそのまま読める。本記事は その裏側でどう組んだか を、エージェントスタックの話として書く。

工程の地図

最初に全体像を貼る。法令リサーチは検索から始めない。クエリを砕くフェーズが先にある。

クエリ砕きは 2 段ある。Stage 1 (ループ外) で人間が prompt.md に静的に置く 戦略レベルの砕き ── 調査テーマと範囲、5 要素 (中心的問い / 要件 / 前提事実 / 隣接論点 / 結論の出し方) と完了条件をいったん全部書き出す。Stage 2 (ループ内) では、エージェントが毎イテレーション prompt.md と progress.md を読んで、戦術レベルの砕き をやる ── 「今回のラウンドは要件 #2 を、◯◯判例から攻める」のような具体化。DoD が FAIL なら Stage 2 (戦術砕き直し) から取り直す。さらに 前提崩壊が起きたら Stage 1 まで戻って prompt.md を書き直し、ループに再投下する (Yakusoku の定義を「組合型共同財布」から「請求書」に書き直したのが、これ)。

ハイブリッド検索を持った自律エージェントを置き、外側を ralph-loop 的なループ制御と終了条件 (DoD) で締める、というかたちになった。順に開く。

1. クエリを砕く ── ここを飛ばすと、何を出典にすべきか判断できない

素のテーマは粗い。たとえば「契約箱は合法か」「ステーブルコインを使うと税金はどうなる」。このまま検索しても、何百件のヒットの中から 何を出典にしてよいか が決まらない。

このフェーズで必ず確定させたのは 5 つ。

1. 中心的問い ── 「契約箱は合法か」ではなく「サービス提供者が、資産のカストディ・相手方マッチング・価格決定・約定に関与しない設計のとき、改正資金決済法の『電子決済手段・暗号資産サービス仲介業』の登録対象になるか」
2. 要件 ── 仲介業の構成要件は「委託を受けて」「媒介」「当該業者のために (所属性)」「業として」。各要件に対応する条文を最初に列挙する
3. 前提事実 ── Koukan の設計前提を 4 点で列挙 (非カストディ／atomic／提供者は秘密鍵なし／約定支援しない)。これがないと当てはめが空中戦になる
4. 隣接論点 ── 暗号資産交換業のカストディ要件、電子決済手段等取引業、集団投資スキーム持分、資金移動業 ── 切り分け対象を最初に書いておく
5. 結論の出し方 ── 「該当する／しない」を断定せず、要件ごとに形式的・実質的当てはめを並べ、グレーゾーン解消制度の利用可能性に触れる。「断定しない誠実さ」をプロンプトに書き込む

エージェントに渡したプロンプト本体はだいたい以下の構造で、調査範囲 セクションがそのままクエリ砕きの結果になる。

# 法令調査タスク
 
## 調査テーマ
契約箱 (Koukan = 条件付き交換 NFT) が、改正資金決済法の
「電子決済手段・暗号資産サービス仲介業」等の業規制に該当するか
 
## 調査範囲
中心的問い: ...
仲介業の定義の核心: 「委託を受けて」「媒介」の各要件を Koukan の設計に当てはめる
併せて切り分ける隣接規制: ①暗号資産交換業 (カストディ含む)
                          ②電子決済手段等取引業
                          ③Yakusoku の集団投資スキーム持分 / 資金移動業
Koukan の設計前提 (事実): NFT/ERC-6551 が資産を保有 / 同一 Tx で atomic /
                          提供者は秘密鍵なし / 約定支援なし
一次資料の取り方: 改正法は 2026/6/1 施行で e-Gov 未反映の可能性 → 金融庁 / 官報を当てる
結論の出し方: 要件ごとに形式的・実質的当てはめ、断定せず、グレーゾーン解消制度に触れる
 
## 完了条件
1. 適用条文を特定し要件・効果を整理
2. 争点となる要件を絞り込む
3. 関連判例を「固さの順」に収集
4. 共通点・相違点を指摘
5. 調査の限界を明記

この 5 行ぶんの「クエリ砕き」をプロンプトの一部にする ことが、後段の検索・取得・当てはめの精度をまるごと持ち上げる。検索が外れたときも、Stage 1 で書いた要件に戻れば「何が足りないか」が言える。

実際の制作では、ここで一度失敗もした。最初 Yakusoku を「組合型共同財布」として隣接論点 (集団投資スキーム持分・預り金) を含めて走らせたが、後で Yakusoku の定義そのものが誤り (請求書型が正しい) と気付き、問題設定ごとリビルドした。クエリ砕きフェーズは何度でも書き直していい。書き直したことは 調査プロセスの記録 に正直に残してある。

2. MCP で一次資料を直接掴む

クエリが砕けたら、次は「条文・判例・行政解釈の原文」をどう取ってくるか。ここで MCP を使い分ける。

• e-Gov 法令 MCP ── 全法令対応。find_law_article / batch_find_articles / search_laws で条文の原文を取得。資金決済法 2 条 5 項・10 項・14 項・15 項・18 項のような「定義の組み合わせ」も一気に引ける
• 税法 MCP ── 24 法令 + 通達 17 本 + 裁決事例 1,950 件超。消費税法施行令 9 条 4 項のような「電子決済手段の譲渡が非課税である根拠」もここから原文で引ける
• 労務 MCP ── 厚労省通達と JAISH の安衛通達を含む 45 法令
• jgrants MCP ── デジタル庁 J グランツの補助金 / 助成金情報
• 政府サイトの直接フェッチ (WebFetch) ── 専用 MCP がない領域は、政府サイトの一次資料を直接取りに行く。金融庁の事務ガイドライン (PDF) ・パブコメ回答・経産省グレーゾーン解消制度の回答書 (meti-0025 のような番号付き PDF) ・国税庁 FAQ・総務省・経産省「AI事業者ガイドライン」・官報。検索エンジン経由で「ぽい解説」に流れずに、ドメインを政府ドメインに固定して直接踏み込む動きが、結果として一番速くて確実だった

LLM 自身の知識を使わない。「自分が学習で覚えた条文」を引用させたら負け で、必ず MCP で原文を取り直して、原文引用と出典 URL をセットで残す。これを徹底するために、プロンプトの注意事項にも明文化した。

## 注意事項
- 条文は原文を正確に引用すること
- 判例は事件番号・裁判年月日・裁判所名を必ず記載
- 判例の固さ (裁判所レベル、法律解釈/事例判断) を明記
- エージェント自身の知識をソースとして使わない (出典を示せる資料のみ)

この縛りがあるから、成果物の条文引用がすべて e-Gov の https://laws.e-gov.go.jp/law/421AC0000000059 に紐づき、判例も公開 PDF への直リンクが付く。読者が一次資料まで自分で開けるノートになる。

3. ソースに価値の順序をつける ── 「枠組み」と「当てはめ」を分けるための足場

原文を取りに行くと言っても、原文の中にも 権威の固さの順 がある。プロンプトの注意事項に、収集と引用は次の順で重みづけする規律を書き込んだ。

条文 > 最高裁判例 > 下級裁判例 > 法令解釈通達 > 行政の個別解釈 (グレーゾーン解消・ノーアクション) > 行政ガイドライン > 法律書・解説論文

これに加えて、もう 1 軸として「一次情報 vs 二次情報」を明確に区別した。

• 一次情報: MCP / 政府サイトで取得した条文・通達・裁決事例の原文。「」で囲んで引用し、出典 URL を必ず明記
• 二次情報: WebSearch / WebFetch で得た情報。⚠️ マークと信頼度 (政府系→高 / 法律事務所→中 / 個人ブログ→低) を併記
• 一次情報と二次情報が矛盾する場合は、一次情報を正とする

この 2 つの順序があるから、成果物の中で 「枠組み (権威の固い順で足場あり)」と「当てはめ (足場の上に解釈で乗せた部分)」 を切り分けて書ける。「契約箱を発行・配布するだけなら仲介業の登録対象にならない方向」のような結論部分は当てはめで、根拠の条文 (資金決済法 2 条 18 項) と金融庁事務ガイドライン 18 章の着眼点が「枠組み」として下に敷かれる。読者は枠組みのリンクから条文 PDF まで辿れて、当てはめは「ここから先は未確定／要事前確認 (グレーゾーン解消制度・ノーアクションレター)」と注記される。

順序をつけずに全部一緒くたに引くと、最高裁判決と個人ブログ解説が同列で並ぶ調査ノートになる。読み手が結論の堅さを判断できない出力 は、調査の意味をなさない。

4. ハイブリッド検索は候補出しだけ ── 出典は MCP に橋渡し

MCP で一次資料を取りに行くには、先に「どの条文・どの判例・どの行政事例を取りに行くか」のあたり をつけないといけない。ここでハイブリッド検索を使う。

ハイブリッド検索の中身は、セマンティック検索とキーワード検索を束ねた kbsearch CLI で、事前に組んだ KB を 3 種つなぐ。

• 判例 KB (jlad) ── japanese-law-analysis/data_set 由来の公開判例 71,000件超 (CC0) に、専用の kbsearch を組んだ。事件番号・裁判所・裁判年月日・要旨 (gist) ・判決本文 (約 60%) ・参照条文・PDF リンクを構造化フィールドとして保持し、--caseno "令和1あ1751" / --reflaw "労働契約法" のような構造化クエリと、セマンティック + キーワードのハイブリッド検索が両方使える。判決 PDF への直リンクを KB が持つので、ここだけは検索結果がそのまま出典になりうる (KB 経由で判例にアクセスでき、サイト直接スクレイピングを避けられる)
• グレーゾーン解消制度 KB (grayzone) ── 経産省グレーゾーン解消制度の回答事例。事業名・担当課室・回答日・PDF URL を収録。本文は on-demand 取得。新規ビジネスの規制適合性調査・行政解釈の先例調査で効く。Koukan の整理で 金融庁の 2024/10/8 回答 (meti-0025) が「構造最接近の行政先例」として効いたのはこの KB のおかげ
• 法律書 KB (lawbooks) ── 法律書の OCR テキスト。条文解釈の 背景知識 として参考。出典にはしない

そして、ここが大事な縛り。「検索ヒットそのものは出典にしない」。kbsearch の結果はあくまで「次に当たるべき条文・事件番号・参照法令」のあたりをつけるためのもので、出典は必ず e-Gov の条文・判決 PDF・金融庁ガイドラインなどの一次資料に橋渡しする。プロンプトには次のように書いてある。

**重要**: kbsearch の検索結果 (メタデータ) は出典にならない。得られた情報
(caseno, subjects, reflaws) を手がかりに、e-Gov の条文・判決 PDF 等の
正式なソースで原文を取得すること。

これでハイブリッド検索が 広く拾うフェーズ に専念でき、MCP が 狭く深く取りに行くフェーズ に専念できる。両者が役割を侵食しない。

5. ハイブリッド検索を持った自律エージェント ── 固定パイプラインではない

ここで設計の分岐がある。Stage 1 → 2 → 3 → 4 を固定パイプラインとして組まなかった。 代わりに「ハイブリッド検索と MCP を全部スキルとして持った自律エージェント」を 1 体置いて、判断を任せた。

固定パイプラインで組むなら、典型的には Dify や LangChain で「embedding → vector search → reranker → context → LLM」を直列に繋ぐ。実際、この成果物を ChatGPT に見せて評価させたら「これは Dify + Flask + Vector DB + reranker の典型 RAG パイプラインですね」と読まれた。

実態は違う。

• 検索するかしないか、するならどの KB を引くか、何件か、を エージェントが判断する
• 検索結果を読んで「これは出典になる / これは候補にすぎない」を エージェントが判定する
• 一次資料を取りに行く先を選ぶ (e-Gov か判例 KB の PDF リンクか金融庁サイトか) のも エージェント側
• 取ってきた条文を読んで「もう 1 段深く別条文を引く必要があるか」を エージェントが決める

外側は「もう 1 周回すか / 完了か」の判定だけしている。これが ralph-loop の構造に乗っている。LangGraph 的なグラフ制御を入れたくなる境界線はあって、たとえばコスト制御 (判例検索回数のハード制約) や、複数エージェントの協調 (調査とレビューの分離) や、人間の承認ゲートが要るタイミングではグラフを書きたくなる。でも、今回の範囲では エージェント自身がツール選択・判断・実行する という前提で、外側は「もう 1 回やるか」だけで足りている。

固定パイプラインと自律エージェントの違いは、要件が動いたときに出る。クエリ砕きが書き直されたとき、固定パイプラインは段ごとに作り直しになる。自律エージェントは、プロンプトを差し替えるだけで対応できる。

6. プロンプトと 終了条件 (DoD = Definition of Done) ── 何を「完了」とみなすか

エージェントを自律に振ると、当然 完了判定 が必要になる。「もういいよ」を機械で言わせる。

DoD (Definition of Done) は 5 ファイル + 1 状態。research.md (本文)・statutes.md (条文)・cases.md (判例)・sources.md (出典)・research_gaps.md (未解決課題)。それぞれにシェルスクリプトで簡単な合格基準を書く。

case "${1:?Usage: $0 <research|statutes|cases|sources|gaps>}" in
  research)  [ -f "$OUT/research.md" ] && [ -s "$OUT/research.md" ] ;;
  statutes)  [ -f "$OUT/statutes.md" ] && grep -q "条" "$OUT/statutes.md" ;;
  cases)     [ -f "$OUT/cases.md" ] && [ -s "$OUT/cases.md" ] && grep -qE "(事件|判決|決定|判例|裁決)" "$OUT/cases.md" ;;
  sources)   [ -f "$OUT/sources.md" ] && [ "$(grep -cE '^- |^[0-9]+\.' "$OUT/sources.md" 2>/dev/null || echo 0)" -ge 2 ] ;;
  gaps)      if [ ! -f "$GAPS" ]; then true
             else [ "$(grep -c '^\- \[ \]' "$GAPS" 2>/dev/null || echo 0)" -eq 0 ]
             fi ;;
esac

特に gaps チェックが効いた。最初、DoD は research / statutes / cases / sources の 4 項目だけで、全部 PASS だと 85/85 ≧ 70 で「完了」と判定していた。ところが実際の成果物を読むと、research_gaps.md に未解決の - [ ] が残ったまま完了扱いになっていた局面があった。

つまり「成果物は揃っているが、エージェント自身が『まだ残っている』と認識している論点が放置されている」状態を、外側が拾えていなかった。エージェントの自己申告のうち「未解決」だけを別パスで拾う、というのが gaps チェックの役割になる。research_gaps.md に - [ ] が 1 行でも残っていたら FAIL を返し、閾値を 70 → 90 に上げた。これで「gaps が解消されないと完了にならない」を必要条件にできる。

DoD を機械可読にする利点はもう 1 つあって、ループの外側を厳密に書けば、内側のエージェントが暴れにくくなる。「とにかく書き散らして PASS を取りに行く」ような行動はスコアで弾かれる。statutes.md に「条」の文字が 1 つも入ってなければ FAIL、cases.md に判例キーワードが 1 つもなければ FAIL。これだけで「条文を引かずに本文だけ厚くする」逃げ道が塞がる。

7. タイムリミットと予算は、区切りすぎると逆効果

DoD と並ぶ歯止めとして、max_iterations ・ コスト上限 ・ サーキットブレーカー (連続エラー回数 / 進捗なし回数) がある。これを最初きつく切ったら、はっきり逆効果だった。

実際に踏んだ罠を書く。Koukan の業規制該当性を opus で走らせたとき、3 イテレーション連続で research.md が書けず progress なし、サーキットブレーカーで異常終了した。原因は単純で、ボトムアップで資料を集める段が重く、ターンを使い切って WRITE フェーズに到達しなかった。仲介業の改正条文 (2026/6/1 施行) は e-Gov 現行法令に未反映で、金融庁サイト・官報・JCBA ガイドラインを一次資料として取りに行く必要があり、収集だけで複数イテレーション消費する。

ここで学んだことは 2 つ。

学び 1: 収集の重い領域では、max_iterations は最初から余裕を持って大きく切る。 「コスト怖いから 5 で止めとこう」をやると、WRITE 前に終わって何も出ない (それでも料金は払う)。max_iterations は 完了スコアで早期完了する ことを前提に「未到達時のみ消費する上限」として置く。実際このときも 8 → 10 に上げて再投下した。タイトに区切るのは、短時間で終わる軽いタスク にだけ効く戦略で、調査系には向かない。

学び 2: サーキットブレーカーで異常終了しても、収集物は捨てない。 上の局面で、サーキットブレーカーが落としたのは「自分で書く」フェーズだった。一方、その手前で 狙っていた一次資料 (金融庁 2023 NFT パブコメ・JCBA NFT ガイドライン v3 等) はちゃんと PDF で取得済み だった。$LOG_DIR/output/references/ を読むと、ralph-loop が落ちただけで、収集物は永続化されている。ここから親エージェント (＝人間と対話しているこちら側) が直接精読して footing を確定すれば、リサーチは完結する。「失敗ログから拾う」運用 を前提に置けば、サーキットブレーカーは「先に進む方向性が間違っているサイン」として読めて、固執せずに方針を切れる。

結局、max_iterations ・ コスト上限 ・ サーキットブレーカーは 暴走を止めるためのもの であって、節約のためのもの ではない。節約を優先して切りすぎると、収集の途中でループが死に、料金だけ払って何も出ない。出力の重要度に対して余裕のある上限を置き、出てきた中間生成物を拾えるディレクトリ構造を作っておく方が、結果として安く済む。

8. パイプラインの結果を使った補足調査 ── スキル化して再利用

1次調査が DoD を通って完了する。ここで終わりではない。実際の制作では、1 次の成果物を読んで「ここをもう少し深掘りしたい」という論点が必ず出る。補足調査の発火源は 2 通り あった。

1. 1 次調査側から「未確認」として返ってきた gaps ── research_gaps.md に残された調査不足。エージェント自身が「ここは 2 次情報のままで、一次資料で裏が取れていない」と申告した項目をそのまま補足調査の入力にする
2. 1 次の結果を読んで人間に湧いた疑問 ── 「この論点はこっちの方向から崩したい」「ここに想定の引用元はあるのか」など、成果物を実際に読まないと出てこない問い

実際の動きで一番分かりやすかったのが JPYC の例だ。1 次調査は当初、二次情報 (プレスリリース等) に基づいて JPYC 社を「第一種資金移動業者」と書いていた。同時にエージェント自身が「これは二次情報なので一次確認が必要」と research_gaps.md に残していた。この gaps を補足調査の入力にして金融庁「金融事業者一括検索」の一次データで裏取りし、正しくは『第二種資金移動業者 (関東財務局長 第 00099 号／令和 7 年 8 月 18 日)』であると訂正できた。 1 次の自己申告のうち「未解決」だけが補足調査に流れて訂正される、という構造になっている。

人間側からの疑問起点でも 3 件深掘りした (NFT の暗号資産該当性／前払式支払手段の境界／決済手段に該当する経済的機能の判定基準)。どちらも、補足調査エージェントから見れば「テーマと 1 次成果物を渡されただけ」で、入力経路は同じ。

骨組みは 2 つ。

1 つめ: 1次成果物を読み取り専用コンテキストに。 補足調査エージェントには、1次調査の output/ を read-only で渡す。書き換えさせない。プロンプトに明記した。

## 1次調査の成果物 (読み取り専用 — 変更しないこと)
[ここに1次調査の出力ディレクトリを記入]
 
## 出力フォーマット
成果物は $LOG_DIR/output/supplements/$SUPPLEMENT_DIR/ に出力する。
1次調査の $LOG_DIR/output/ 配下のファイルは読み取り専用。
絶対に変更・上書きしないこと。

これで補足調査の失敗が 1 次成果物を壊さないし、補足の結果に応じて 1 次の論点リストを書き戻す動きも、明確に 人間が判断するワークフロー として分離できる。

2 つめ: 補足調査用のプロンプトテンプレートと ralph-loop 設定を別ファイルに分ける。 prompts/template.md と prompts/supplemental.md を分け、ralph-loop の TOML も ralph_loop.toml / ralph_loop_supplemental.toml を分けた。PROMPT_TEMPLATE=supplemental python run.py で補足調査側を起動できる。

RESEARCH_TOPIC="NFT の暗号資産該当性（金融庁2023パブコメ起点）" \
  LOG_DIR=~/legal-research-log/koukan-fsa-chukai \
  PROMPT_TEMPLATE=supplemental \
  python run.py

補足調査も「中心的問い → 要件 → 一次資料 → 当てはめ → DoD」の同じ構造を踏む。1次調査と補足調査で同じ規律を回せる のが、スキル化の効果だった。

9. 何を任せず、人間が握り続けるか

ここまで「エージェントに任せる」話を続けてきた。でも、任せていない部分もある。

「枠組み」と「当てはめ」の線引き は人間が握る。条文・行政解釈で足場のある「枠組み」と、先例がなく解釈で埋める「当てはめ」を分けて書く、という方針は、最初に人間が決めてプロンプトに書き込む。エージェントが当てはめを書きすぎると「ソースあるの」と人間が叩く局面が来る。実際に来た。これを正直に「ここから先は未確定／要事前確認 (グレーゾーン解消制度・ノーアクションレター)」と書き直す決定は、自動化していない。

デマ源の訂正 も人間が握る。今回は Yakusoku の定義が誤って global の CLAUDE.md に書かれていて、それが調査の問題設定をまるごと汚していた。エージェントが「定義から見て隣接論点はこれ」と引いてきても、定義が間違っていたら全体が崩れる。定義を直す決定はエージェントの外 で、人間がやる。直したら drama そのものを「クエリ砕きの書き直し」として 1 周目に戻す。

ソースファースト方針への切り替え も人間が握った。最初は抽象的な当てはめを上から積みがちで、ある時点で「資料のある NFT から遡って掘れ」と方針を切り替えた。抽象から具体へ降りる方向ではなく、実在資料から基準を抽出する方向 に切る判断は、エージェントの自走では出にくい。

そして、裏取りで自分の誤記を訂正する誠実さ は仕掛けで担保した。前節で書いた JPYC「第一種 → 第二種」の訂正は、エージェントが偶然気付いたわけではない。1 次調査側で「これは 2 次情報なので一次確認が必要」と research_gaps.md に残させ、補足調査スキルの DoD に「裏取り」を含めていたから、未解決のまま閉じることができなくなっていた。誠実さは性能ではなく仕掛けで出す のがエージェントスタックの設計思想に近い。

10. 本来やるべき出典の健全性チェック ── このパイプラインに足りていないもの

正直に書いておく。この法令リサーチパイプラインの DoD は、出典の健全性チェックが弱い。

現状の sources.md の合格基準は「箇条書きの項目が 2 件以上ある」だけ。本来やるべきチェックは 3 軸ある。

1. リンクの生存 ── 列挙した出典 URL が HTTP で生きているか。curl -sIL -o /dev/null -w "%{http_code}" --max-time 20 を並列で叩いて 200/3xx を確認し、403 (ボットブロックで実在) と 404 (消滅) を区別する。これは LLM に判定させず、決定論で叩くべき部分。実例として、ファクトチェックのセッションで出典 143 本を一括 HTTP 検査したとき、判決 PDF が 3 本 404 で死んでいた。公開元が URL 構造を変更し、旧形式が全滅していたのが原因 (新形式は /assets/hanrei/hanrei-pdf-{id}.pdf)。事件の同一性は別パスで取れていたから人間が読んでも気付かず、curl で叩いて初めて落ちた。「検証する」のが仕事の側が、未検証の死リンクを ✓ で通していた という、決定論を入れていないと止まらない種類の事故
2. ソースの実在 ── 引いている判例・条文・PDF が本当に存在するか。Mata v. Avianca の弁護士は、ChatGPT が捏造した「実在しない判例」をそのまま準備書面に貼って制裁を受けた。法令リサーチでも、エージェントが「最高裁判決 平成○年(あ)第○○号」とそれっぽく書いてしまえば、statutes.md のスコアは PASS してしまう。事件番号で kbsearch --kb jlad get --caseno "..." を叩いて 1 件返るかを別パスで確認する、くらいの実在チェックを DoD に入れるべき
3. ソースとの関連性 ── URL が生きていて、引用先のドキュメントが実在しても、その内容が当てている主張を実際に支えているか は別問題。「資金決済法 2 条 18 項を根拠に仲介業の構成要件は…」と書いたとき、条文の本文が本当にその要件を定めているか、本文を取り直して照合する工程が要る

この 3 つのうち #1 と #2 は決定論で書ける から、quality.sh に増やせる。sources.md の URL を抜いて並列 curl、cases.md の事件番号で jlad を叩いて 1 件返るかをチェック、で十分。閾値ではなく PASS/FAIL の必要条件にする。#3 (関連性) はもう一段高い ── 当てはめの抽象度を扱うので、LLM のサブエージェントに「この条文本文はこう書かれている。主張 X を直接支えるか?」と問い直すパスが要る。判定の二重化 (verify する verifier) を組み込む話で、ファクトチェックのセッションでやった「多視点 verify」と同じ作法で乗せられる。

ファクトチェックの裏話 2 本 で書いたのは、この #1〜#3 を マンガ全体の 320 件の事実 に対して 1 つのセッションで 回した話だ。並列ツール (curl ・ 検索) と多視点 verify サブエージェントを 1 つのコンテキストで束ねて、出典 143 本の生死・実在・関連性をその場で確かめた。法令リサーチの成果物の出典も、結果的にはこのセッションで網に拾われる構造になっている。

とはいえ、法令リサーチの DoD 内で同じ 3 軸を完結させた方が良い。理由は 2 つ。1 つは、補足調査の段階で「この出典は怪しい」を research_gaps.md に書き戻して、その場で深掘りに回せること。もう 1 つは、法令リサーチが単独で走るユースケース (マンガに紐づかない法令調査) でも、出典の健全性が担保されること。ファクトチェックセッションを下流に置く前提を外せる ことが、改良の意味だ。

まとめ

整理する。

• 最大の敵はハルシネーション。 すべての設計はそれを潰すためにある。LLM の知識を出典にしない
• クエリを砕くフェーズを最初に置く。 中心的問い・要件・前提事実・隣接論点・結論の出し方を確定させないと、検索しても出典が選べない
• MCP / 政府サイト直接で一次資料を掴む。 LLM の知識ではなく e-Gov / 判例 PDF / 金融庁 PDF から原文を引き、原文引用 + 出典 URL を残す
• ソースに権威の固さの順序をつける。 条文 > 最高裁 > 下級裁 > 通達 > 行政の個別解釈 > ガイドライン > 法律書。一次情報と二次情報を分け、矛盾したら一次情報を正にする
• ハイブリッド検索は候補出しだけ。 検索ヒットは出典にせず、必ず一次資料に橋渡しする。判例 KB (jlad) は専用 kbsearch で構造化検索が効く
• 固定パイプラインではなく、ツールを持った自律エージェント。 検索する／しない、どの KB を引くか、どの MCP を当てるか、をエージェントが判断する
• DoD は機械可読に。 5 ファイル + gaps チェック + 閾値で、「未解決を残したまま完了」を塞ぐ
• タイムリミットと予算は、区切りすぎない。 収集の重い領域で max_iterations を絞ると WRITE 前に死んで料金だけ払う。失敗ログから収集物を拾える運用の方が結果として安い
• 補足調査はスキル化。 1 次成果物を read-only にして、補足側で同じ規律を再帰する
• 出典の健全性は本来 DoD で 3 軸 (リンク生存・実在・関連性) チェックすべき。 現状ここは弱く、下流のファクトチェック pipeline に依存している。改良余地
• 「枠組み」と「当てはめ」の線引き、デマ源の訂正、ソースファースト方針への切り替えは、人間が握る。

エージェントを 「ハイブリッド検索を持った 1 体の自律エージェント」 として配置し、外側に 「クエリ砕き / DoD / 補足調査スキル」 を置く。それだけで、解説マンガ1話分の法令リサーチ ── JPYC・契約箱・NFT の有償/無償 ── を、一次資料まで遡らせて出典付きで書けた。派手な自律オーケストレーションは要らなかった。1 体の自律エージェントに、正しいスキル束と、正しい完了条件と、正しい撤退ルールを与える ことが効いた。

ここで仕上げた法令リサーチの現物は ステーブルコイン編 条文・判例の調べもの にある。条文の原文引用、判決 PDF、行政解釈、調査プロセスの記録、追加調査での自己訂正 (第一種 → 第二種資金移動業者) まで、そのまま開いて確かめられる。「枠組み」と「当てはめ」を分けて書く という方針が、読み物としてどう着地したかも、現物から読み取ってもらえると思う。