数MBのドキュメント群から必要な記述だけ取り出す — 分割委譲＋逐語照合の型

社内Wiki の書き出し、マニュアル、議事録アーカイブ、契約書の束。 **「全部で数MB あるが、欲しいのはそのうち数%」**という読み取り作業の手順書。

監督役のモデル（高価な大型モデル）の文脈に原文を載せずに済ませ、 かつ 「安いモデルに読ませたら要約が間違っていた」を検証で潰すところまでを型にしてある。

想定: ドキュメント10〜20本 × 各300KB〜1MB。1本あたり10万〜20万トークン相当。

---

1. なぜ素直にやると失敗するか

• 監督が自分で読むと文脈が溢れる。 6MB は大型モデルでも載らないか、載っても他の作業ができなくなる。
• 「全文検索で当たりを付ける」が効かない。 大きなファイルは検索インデックス自体が本文を拾い切っていない。 実測: あるキーワードが「検索でヒットしないファイル」の本文に確かに存在した。被覆確認に検索を使ってはいけない。
• 読み取りAPIが大きなファイルを末尾で黙って切る。 エラーも警告も出ない。 「該当なし」なのか「そこまで読めていない」のか、返ってきた文面からは区別がつかない。
• 安いモデルは要約で意味を変える。 とくにどのページに書いてあったかを取り違える。 数値は合っているのに出典が違う、という形で混ざるので気付きにくい。

---

2. 型

[監督]  ファイル一覧を取る（1回だけ・軽い）
   │
   ├─→ [抽出A] ファイル1 → 該当箇所だけ返す ┐
   ├─→ [抽出B] ファイル2 → 該当箇所だけ返す │ 安いモデルで並列
   ├─→ …                                    │ 1ファイル=1エージェント
   └─→ [抽出N] ファイルN → 該当箇所だけ返す ┘
   │
[監督]  届いた順にファイルへ落とす（文脈圧縮で失わないため）
   │
   ├─→ [検証1] 重要な主張だけ、原文へ差し戻して逐語照合 ┐ 抽出した本人にはやらせない
   └─→ [検証2] 〃                                       ┘
   │
[監督]  統合ドキュメント（食い違い一覧・被覆の穴・出典表）

1ファイル1エージェントにする。 2〜3ファイルまとめると文脈に載らず、載っても途中を飛ばす。

---

3. 抽出エージェントのプロンプト（これをそのまま使う）

<ファイル読み取りツール> を <ファイルID/パス> で呼び、
**<欲しいテーマ>に関する記述だけ**を抽出して返してください。

## 拾う観点（<テーマ>に関わるもののみ）
- <観点1: 具体的に。「料金・割引・手数料・最低価格・上限価格」のように語を並べる>
- <観点2>
- …

## 出力ルール（厳守）
- **原文にある数値・固有名詞・日付はそのまま写す。要約で丸めない。推測・補完は絶対にしない。**
- 各項目に `出典: <ファイル名> / <その箇所の見出しまたは前後の目印>` を必ず付ける。
- 該当が1件も無ければ `該当なし` とだけ書く（無理に絞り出さない）。
- **本文が途中で切れている疑い**（文が途中で終わる、明らかに尻切れ）があれば、
  冒頭に `⚠️切れている可能性: <どこで>` と書く。
- 無関係な内容は書かない。ただし「このファイルは主に○○の話だった」を1行だけ添える。
- 全体で 4000 字以内。マークダウンの箇条書きで。
- **パスワード・APIキー・口座番号・暗証番号・個人の連絡先は引用しないこと。**
  存在した事実と出典だけ書く。

あなたの最終テキストがそのまま呼び出し元への返り値になります。前置き・挨拶は書かないでください。

効いている指示はどれか

指示	無いとどうなるか
「切れている疑いを冒頭に書け」	**静かな取りこぼしが検出できない。**これが一番重要
「該当なしとだけ書け」	関係ない内容を無理に民泊風に言い換えて返してくる
「このファイルは主に○○だった」	「該当なし」が正しいのか読めていないのか判断できない
「数値をそのまま写せ」	「約4,500円」「4千円台」に丸められて突き合わせ不能になる
「認証情報は引用するな」	出力先がリポジトリなら平文の鍵が入る

---

4. 検証エージェントのプロンプト

抽出した本人に検証させない。 自分の要約を正しいと言うだけになる。

検証タスクです。**抽出済みの主張が原文どおりか、逐語で確かめてください。**

<ファイル読み取りツール> を <ファイルID/パス> で読み、下の N 件それぞれについて判定してください。

## 検証する主張
1. <主張を1文で。数値・向き・固有名詞を含める>
2. …

## 出力（各主張ごとに）
- `判定`: 一致 / 不一致 / 見つからない
- `原文`: 該当箇所を**一字一句そのまま**引用（前後1〜2文も含める）。見つからなければ「なし」
- `補足`: 抽出側が言い換え・要約で意味を変えていないか。数値・単位・向きがずれていないか。
  **その記述が「現行」なのか「過去情報」なのか**（本文に「旧版」「以下過去情報」等の
  但し書きが付いていないか）を必ず書く。

**推測で埋めないこと。見つからなければ「見つからない」と書く。**

「現行か過去か」を必ず聞く理由

実測でここが効いた。抽出結果には「週末は平日の1.5倍」と書かれていたが、 原文には 「【旧版（参照用）】過去マニュアル（YYYY/M/D時点）」 という見出しが付いていた。 抽出エージェントはこの但し書きを落としていた。 古い設計値を現行値だと思って設定を変えると事故になる。

同じ検証で「この記述はページAにある」が実はページBだった、という帰属ミスも1件出た。 内容が正しくても出典が違えば、次に読む人が原文へ戻れない。

---

5. 受け取り側（監督）の実装

• 届いた順にファイルへ落とす。 全部揃うまで文脈に溜めない。 長時間の並列作業中に文脈圧縮が入ると、数値の細部から先に失われる。
• エージェントの生ログ（トランスクリプト）を読み返さない。 原文がまるごと入っていて文脈が溢れる。 返り値だけを扱う。
• 統合ドキュメントには必ずこの4つを入れる:
  1. 食い違い一覧（ドキュメント間 / ドキュメントと現状）
  2. 被覆の穴（どのファイルの切れ申告があったか。どこが読めていないか）
  3. 出典表（ファイルID一覧。次の人が原文へ戻れるように）
  4. 転記しなかった情報の所在（認証情報など）
• 冒頭に一文入れる: 「ここに書いてあるのは『そう書いてある』であって『今もそう運用している』ではない」

---

6. コストと時間の実測

ドキュメント14本・計約5.9MB（各300〜470KB）を並列処理した実測値:

	値
抽出エージェント	14本並列・中位モデル
1本あたり	60,000〜160,000 tok / 2〜8分
検証エージェント	2本・重要主張7件 / 各50,000〜60,000 tok
監督が負担した文脈	各エージェントの返り値（2,000〜4,000字）のみ。原文は0
検出できた欠陥	末尾切れ3本 / 帰属ミス1件 / 「旧版」表記の落とし1件

監督が自分で読んだ場合との差: 6MB＝約200万トークンを大型モデルで通すことになる。 分割委譲なら中位モデルで約150万トークン、監督の負担は数万トークンに収まる。

---

7. チェックリスト

• 1ファイル=1エージェントになっているか（まとめていないか）
• 抽出プロンプトに「切れの自己申告」を入れたか
• 抽出プロンプトに「該当なしとだけ書け」を入れたか
• 抽出プロンプトに「認証情報を引用するな」を入れたか
• 結果を届いた順にファイルへ落としているか
• 重要な主張を別のエージェントで逐語照合したか
• 検証で「現行か過去か」を聞いたか
• 統合ドキュメントに被覆の穴を明記したか
• 「全文検索でヒットしなかった＝存在しない」と判断していないか