コンテキスト管理と
信頼性（配点15%）

要約を重ねるのは伝言ゲームと同じだ。「注文番号A-1042、¥58,000のうち¥12,000の返金希望、期限は8/15」という話が、3回要約を通ると「返金の相談があった」になる。最初に崩れるのは雰囲気ではなく数字と日付——言い換えがきかず、1文字違えば別物になる情報からだ。だから対処は「要約を上手にやる」ではなく、硬い事実を要約のラインに乗せないこと。取引の事実だけを抜き出した「case factsブロック」を作り、要約された履歴の外側で毎回のプロンプトに固定添付する。伝言ゲームの列の横で、メモ用紙を直接回すイメージだ。

もう1つの敵がlost in the middle。長い入力の冒頭と末尾はよく読まれるが、真ん中は取りこぼされる——長い会議の議事録で、開始直後と締めの発言だけ妙に覚えているのと同じだ。重要な発見は冒頭にサマリーとして置き、詳細は明確な見出しで整理する。さらに、コンテキストを不釣り合いに食う筆頭がツール結果。注文照会1回で40以上のフィールドが返るのに、実際に要るのは5個ということが普通にある。納品書1枚あれば足りるのに商品カタログごと保管するようなもので、関連フィールドだけに刈り込んでから履歴に蓄積させる。

• 漸進的要約のリスク：数値・パーセンテージ・日付・顧客が明言した期待値が要約で失われる
• lost in the middle：長い入力の最初と最後は確実に処理されるが、真ん中の情報は取りこぼされうる→重要な発見は冒頭にサマリーとして置き、詳細は明確なセクション見出しで整理
• ツール結果はコンテキストを不釣り合いに食う（注文照会1回で40+フィールド、要るのは5個）→関連フィールドだけに刈り込んでから蓄積させる
• 対処の型：取引の事実（金額・日付・注文番号・ステータス）を「case factsブロック」として抽出し、要約された履歴の外側で毎プロンプトに含める
• 下流のエージェントのコンテキスト予算が限られているなら、上流には「冗長な本文と推論過程」でなく「キーファクト・引用・関連度スコア」の構造化データを返させる

窓口の新人に「困ったら上司を呼べ」とだけ教えると、呼びすぎるか、呼ばなすぎるかのどちらかになる。必要なのは呼ぶ条件の明文化だ。試験の立場では正当なトリガーは3つだけ：①相手が「人間に代わって」と明示的に言った（このときは調査を試みる前に即上げる）、②マニュアル（ポリシー）に書いていない事態に当たった（例：他社価格に合わせてほしいと言われたが、ポリシーには自社の価格調整しか書かれていない——ここで気を利かせて勝手に判断するのが一番危ない）、③手を尽くしたが前に進めなくなった。

逆に、直感的には良さそうで試験では誤答になるのが「顧客の感情がネガティブなら上げる」と「AIの自己申告の確信度が低ければ上げる」。怒っている客の用件が単純なことも、丁寧な客の用件が複雑なこともある（感情と複雑さは相関しない）。そしてLLMの「自信80%です」は答え合わせされていない自己申告で、難しい案件ほど誤って自信満々になる——「大丈夫です！」と言い切る新人の自信を鵜呑みにできないのと同じだ。もう1つの頻出場面が顧客照合の複数ヒット。同姓同名のカルテが2件出てきたら、「たぶんこっち」で1件選ばず、追加の識別子（生年月日・電話番号）を尋ねる。

• 正しいエスカレーショントリガー：顧客の明示的要求／ポリシーの例外・空白（単に複雑なだけの案件は含まない）／意味のある進展の不能
• 顧客が人間を明示要求したら調査を試みる前に即エスカレーション。ただし問題が簡単なら「解決を提案しつつ、重ねて求められたら上げる」の使い分け
• センチメント（感情分析）ベースのエスカレーションと自己申告の確信度スコアは、実際の案件の複雑さの代理指標として信頼できない——D4・D5を貫く頻出論点
• ポリシーが顧客の要望に対して沈黙・曖昧なら上げる（例：他社価格マッチはポリシーに自社価格調整しか書かれていない→勝手に判断しない）
• 顧客の照合結果が複数件ヒットしたら、ヒューリスティックで1件選ばず追加の識別子を尋ねる
• 実装は「明示的なエスカレーション基準＋few-shot例」をシステムプロンプトに（第3章で学んだD4.1/4.2の技法をここに適用）

現場から本部への報告を想像すると分かりやすい。調査チームの1人が業界データベースに接続できなかったとき、報告の仕方は3通りある。握りつぶし：「（何も見つからなかったことにして）調査完了です」——本部は穴があることすら知らないままレポートを出す。丸投げの全停止：「エラーが出たので調査全体を中止します」——他のメンバーの成果まで道連れにする。そして正解の構造化報告：「接続エラーで3回失敗（失敗の種類）。このクエリを試した（試したこと）。途中まで取れたデータはこれ（部分結果）。別のDBなら取れるかもしれない（代替案）」。この4点セットが揃って初めて、本部＝コーディネーターは「修正クエリで再試行する／別の手を打つ／部分結果で前進する」を賢く選べる。

報告の前にもう1つ規律がある。直せる失敗は現場で直してから上げること。タイムアウトのような一時的エラーは子エージェントの中でローカルにリトライし、解決できなかったものだけを4点セット付きで上げる（第4章のエラー4分類——transient / validation / permission——がここで効いてくる）。そして最終レポートにはカバレッジ注記を付ける：どの発見は裏付け十分で、どの領域はソースにアクセスできず穴のままか。穴を隠したレポートより、穴の場所が書いてあるレポートの方が信頼できる。

• 構造化エラーコンテキストの4点セット：failure type / attempted query / partial results / alternative approaches——これがあるとコーディネーターは「修正クエリで再試行／別アプローチ／部分結果で続行」を賢く選べる
• アクセス失敗（リトライ判断が要る）と正当な0件（成功・該当なし）の区別——第4章（D2.2）と共通の頻出論点
• 一時的な失敗は子の中でローカル回復を試み、解決できないものだけ「試したこと＋部分結果」付きで上げる
• 統合レポートにはカバレッジ注記を付ける：どの発見が十分に裏付けられ、どのトピック領域はソース不能で穴があるか

まず症状から。数百ファイルのコードベースを2時間調査しているとしよう。最初の1時間、AIは冴えている——「返金処理は PaymentService の refund() から始まり、RefundValidator を通る」と、実際に読んだファイルの固有名で答える。ところが後半、様子が変わる。「一般的な決済システムでは、返金処理はバリデーション層を経由することが多いです」——さっき自分で見つけた具体名を忘れ、研修で習ったような一般論を語り始める。これがコンテキスト劣化の典型症状だ。嘘をついているのではない。コンテキストが探索の途中経過（開いたファイルの中身、失敗した検索、無関係なコード片）で埋まり、肝心の発見が「真ん中に沈んで」参照できなくなっている。図書館に半日こもって調べ物をした夕方、メモを取らなかった人が「で、結局あの数字はどの本に書いてあったんだっけ……確か一般的には……」となるのと同じ現象だ。

対抗策の第一がスクラッチパッドファイル。調査で得たキーファインディング（「返金の入口は PaymentService.refund()」「テストは tests/payment/ 配下」）を、コンテキストの外＝外部ファイルに書き残し続け、後続の質問ではそのファイルを参照させる。研究者の研究ノートだ。頭（コンテキスト）は忘れても、ノートに書いた発見は消えない。第二が子エージェントへの隔離。「全テストファイルを探す」「返金フローの依存を全部追う」のような、大量のファイルを開いては捨てる冗長な探索は、コンテキストを最も汚す作業でもある。これを子エージェントに任せれば、何十ファイル分の探索ゴミは子のコンテキストの中だけで消費され、親には要点だけが返る。書庫の総当たりはアシスタントに頼み、自分は要約メモを受け取って全体の指揮に専念する分業だ。

第三がフェーズ要約の注入。「構造把握フェーズ」が終わったら要約を作り、次の「詳細調査フェーズ」を担当する子エージェントの初期コンテキストにそれを注入する。各フェーズが新鮮なコンテキストで始まりつつ、前フェーズの成果は引き継がれる。第四がマニフェストによるクラッシュ回復。長丁場の途中でセッションが落ちることはある。各エージェントが自分の状態（どこまで調べ、何を見つけたか）を既知の場所にエクスポートし続けていれば、コーディネーターは再開時にその一覧表（マニフェスト）を読み込んで積み上げを失わずに続きから始められる。停電に備えて工程表を壁に貼っておく現場の知恵と同じ。そして、冗長な発見でコンテキストが埋まってきたら /compact で圧縮する——ただし5.1で学んだ通り、圧縮で溶けて困るものは事前にスクラッチパッドや保持指示で外に出しておくこと。

• コンテキスト劣化の症状：回答が非一貫になり、実際に発見した固有名でなく一般論を参照し始める
• スクラッチパッドファイル：キーファインディングを外部ファイルに記録し続け、後続の質問で参照する→劣化への対抗
• 特定の調査（「全テストファイルを探す」「返金フローの依存を追う」）は子エージェントに出し、メインは高レベルの調整に専念
• フェーズ完了ごとに要約を作り、次フェーズの子エージェントの初期コンテキストに注入
• クラッシュ回復：各エージェントが状態を既知の場所にエクスポートし、コーディネーターが再開時にマニフェスト（一覧表）を読み込む
• 冗長な発見でコンテキストが埋まったら /compact で圧縮

「うちの学校の平均点は97点です」と聞いても、数学だけ全員赤点かもしれない——集計値は弱点セグメントを隠す。文書抽出パイプラインの「全体精度97%」も同じで、請求書は99%でも手書きの領収書は70%、金額欄は完璧でも日付欄が壊れている、ということが普通に起きる。だから「97%に達したので人間レビューを外す」の前に、文書タイプ別・フィールド別に精度を分解して一貫して高いことを確かめる。そして自動化した後も層化ランダムサンプリング——高確信度と判定された抽出からも無作為に抜き取って誤り率を測り続ける。工場の抜き打ち検査と同じで、「今まで良品だったライン」からも抜くのは、新種の不良は実績のあるラインにも出るからだ。

もう1つの柱が確信度の較正。モデルに項目ごとの確信度スコアを出させ、それを人間レビューの振り分けに使う——のは良い設計だが、1つ手前の工程が要る。正解ラベル付きの検証データと突き合わせて「スコア0.9のとき実際の正答率はいくつか」を確かめる（＝較正する）ことだ。5.2で見た通り、モデルの自己申告は素のままでは当てにならない。較正を経た閾値で「低確信度・曖昧・矛盾のある元文書」だけを人間に回せば、限られたレビュー能力を本当に危ないところへ集中配分できる。

• 集計精度の罠：全体97%でも、特定タイプ・特定フィールドでは大きく劣る可能性→セグメント別に検証してから人間レビューを減らす
• 層化ランダムサンプリング：高確信度の抽出からも無作為抽出して誤り率を測り続け、新種のエラーパターンを検出する
• 項目レベルの確信度スコアをモデルに出させ、ラベル付き検証セットで閾値を較正→低確信度・曖昧・矛盾のある元文書だけを人間レビューへルーティング（限られたレビュー能力を優先配分）

論文から脚注を消してしまえば、どの主張も「誰かがどこかで言っていた話」になる。マルチエージェント調査で起きるのがまさにこれで、検索係の結果を要約→統合係がさらに要約、と重ねるうちに出典の帰属が溶ける。防ぐには、要約とは別に主張↔出典の対応表（主張・根拠の抜粋・出典URL/文書名・日付のセット）を構造化データとして持ち回り、統合エージェントには「保存してマージする」ことを仕事として課す。第1章の1.3で「親から子へ渡すデータは本文とメタ情報を構造化して分離する」と学んだのは、この保全の入口だった。

統合で必ず出会うのが数字の食い違いだ。信頼できる2つのソースが市場規模を$4.2Bと$5.1Bと書いている——ここで「新しい方」「権威がありそうな方」を統合エージェントが勝手に選ぶのは、2紙の新聞の数字が違うときに記者が好みで片方を採用するのと同じで、誤答。矛盾として注記し、両方を出典付きで併記して、判断できる立場（コーディネーターや人間）に上げる。そして食い違いの多くは実は矛盾ではなく時点の違い（2023年調査と2025年調査）なので、公開日・データ収集日を構造化出力の必須項目にしておく。仕上げのレポートでは「確立された発見」と「争いのある発見」をセクションで分け、元ソースの表現とメソドロジーの文脈を保存する。最後にもう1つ：財務データは表、ニュースは散文、技術的発見は構造化リスト——データの性質に合った形で統合し、見やすさのために全部を一様のフォーマットへ潰さない。

• 要約ステップで出典の帰属が失われるメカニズムと、claim-source mapping（主張・根拠の抜粋・出典URL/文書名・日付）を統合まで保全する設計
• 矛盾する統計値の扱い：恣意的に1つ選ばない。矛盾として注記し、出典を付けて併記（コーディネーターが判断できる形で上げる）
• 時間データ：公開日・データ収集日を構造化出力に必須で入れる→時点の違いを「矛盾」と誤読しない
• レポートは「確立された発見」と「争いのある発見」をセクションで分け、元ソースの表現とメソドロジーの文脈を保存する
• コンテンツタイプに合った表現で統合する：財務データは表、ニュースは散文、技術的発見は構造化リスト——全部を一様のフォーマットに潰さない