情報来歴と不確実性

マルチソース合成における情報来歴（information provenance）と不確実性処理は、Claude Certified Architect — Foundations（CCA-F）試験の Domain 5「コンテキスト管理と信頼性」（試験全体の15%）の中でも最もアーキテクチャ的要求が高いタスク5.6「マルチソース合成における情報来歴の保全と不確実性処理」を扱う章節である。複数の subagent が独立してデータを取得し、どの出典がどのクレームを生んだかを追跡し、出典間の矛盾を認識し、不確実性を埋め合わせることなく適切に表面化する——このマルチエージェント研究システムのパターンが、Domain 5 で最難度のタスクとして位置づけられる。コミュニティの合格レポートは、「Claude が自動的に出典を追跡または不確実性をマーキングするわけではない」という事実を見落とすことが最多の失点要因であると一貫して指摘する。望む来歴保証はすべて、プロンプト・スキーマ・オーケストレーションロジックに明示的に設計しなければならない。

本章節では CCA-F 受験者がシステムレベルで設計できることを期待されるすべての項目を順に解説する。来歴問題そのもの、構造化されたクレームとソースのマッピング、引用を行動可能にする識別フィールド、マルチソース競合解決、出力スキーマにおける不確実性表現、モデル確信度と出典信頼性の区別、ヘッジ言語パターン、ソース品質重み付け、クロスソース三角検証、来歴監査証跡、そして不確実性駆動のエスカレーション——以上を網羅する。試験で頻出のマルチエージェント研究システムシナリオと構造化データ抽出シナリオの両方から実例を引用しながら各パターンを固める。5つの試験トラップと7問のFAQで章節を締めくくる。

来歴問題 — どの出典がどのクレームを生んだかを見失う失敗モード

情報来歴（information provenance）とは、合成された出力内のすべてのクレームが、それを生成した具体的な出典ドキュメント・チャンク・取得ステップまで遡れるという性質である。来歴問題とは、素朴なマルチソース合成パイプラインに典型的な失敗モードだ。Claude が5つのドキュメントを読んで自信に満ちたパラグラフを書いた後、どの文がどの PDF から来ているのかを機械的に判断する手段がなくなる。情報来歴がなければ、ハルシネーションを監査できず、出典レベルのアクセス制御を遵守できず、規制分野で正確な引用ができず、下流の紛争が生じても合成全体を再実行せずに修正できない。

素朴な合成が来歴を失う理由

典型的な素朴なパターンはこうだ。ベクトルインデックスから5つのパッセージを取得し、「ソース：」という見出しの下に連結してプロンプトに入れ、「関連情報を要約してください」と Claude に依頼する。Claude はきれいなサマリーを生成するが、それは混合物だ。新しいパラグラフを書き始めた瞬間に帰属情報は失われる。これが情報来歴の失敗の典型的な形であり、「研究システム」「合成」「マルチソース」に言及する CCA-F シナリオはすべて、これを回避する設計を知っているかを試している。

来歴をファーストクラスの設計目標として扱う

情報来歴は後付けで追加できる機能ではない。パイプラインのすべての段階を再形成する制約である。取得ステップでは各チャンクとともに出典 ID を保存し、プロンプトでは Claude に散文ではなくクレームを出力させ、出力スキーマではすべてのクレームに引用フィールドを強制し、下流バリデーションは出典 ID を欠くクレームを含む出力を拒否する。情報来歴をパイプラインレベルの性質として扱う受験者が CCA-F で評価される。

構造化されたクレームとソースのマッピング — 各抽出クレームへの出典引用の付与

情報来歴の機械的中核は、構造化されたクレームとソースのマッピングである。合成された出力内のすべての原子的クレームを、それを支持する出典識別子とペアにするレコードだ。このパターンにより、「脚注付き散文」（検証不可能）が「出典配列を各クレームに明示的に付けたクレーム配列」（検証可能・機械チェック可能）に置き換わる。

原子的単位としてのクレーム

情報来歴設計では、合成された出力をパラグラフではなく原子的クレーム——単一の検証可能な主張——に分解する。「Acme社は2026年Q2に42億ドルの収益を報告した」はクレームだ。「Acme社は今年好調で、収益が強く利益率も改善している」は3つのクレームを内包したパラグラフだ。情報来歴を強制できる単位はクレームであり、パラグラフではない。

出力スキーマによる情報来歴の強制

情報来歴は、strict tool use に渡す出力スキーマで強制する。典型的なスキーマは以下の通りだ。

{
  "claims": [
    {
      "claim_id": "c-001",
      "text": "Acme社は2026年Q2に42億ドルの収益を報告した。",
      "sources": [
        {"source_id": "doc-acme-10Q-2026Q2", "chunk_index": 14}
      ],
      "uncertainty": "low"
    }
  ]
}

tool 定義で strict: true を設定すると、Claude API はいずれかのクレームの sources 配列が欠落した出力の返却を拒否する。情報来歴の保証は機械的であり、礼儀的なものではない。

構造化マッピングがインライン引用より優れる理由

散文中のインライン引用（「Acme社は42億ドルを報告した [1]」）は合理的に見えるが脆弱だ。Claude がマーカーを忘れたり、重複させたり、誤った番号を付けたりする可能性がある。JSON スキーマによる構造化されたクレームとソースのマッピングは機械的に検証可能だ——バリデーターは、すべてのクレームに1つ以上の出典があること、すべての出典 ID が取得ログに存在すること、ハルシネートされた ID が混入していないことをプログラム的に確認できる。このレベルの厳密な情報来歴が、研究グレードのパイプラインをおもちゃのデモと区別する。

出典識別フィールド — URL・ドキュメント ID・チャンクインデックス・取得タイムスタンプ

「Acme 10-Q」だけの出典 ID では情報来歴の要件を満たさない。本番品質の出典参照は、クレームを支持する正確なテキストスパンを一意に特定し、合成時点でその証拠が存在したことを証明するのに十分なフィールドを持つ。

最小限の出典参照

CCA-F の目的では、情報来歴の出典参照に必須のフィールドは以下の通りだ。

• URL またはドキュメント URI — 出典の正規ロケーター。
• ドキュメント ID — 安定した内部識別子（ハッシュ、UUID、外部主キー）。
• チャンクインデックスまたはページ番号 — サブドキュメントのスパン識別子。
• 取得タイムスタンプ — コンテンツが出典から取得された時刻。
• 出典種別 — 列挙型（web、internal-wiki、CRM、knowledge-base、uploaded-pdf など）。

各フィールドが重要な理由

URL は人間の監査担当者が出典を解決できるようにする。ドキュメント ID は重複排除と取得ログへの結合を可能にする。チャンクインデックスは証拠を特定のスパンに絞り込む。取得タイムスタンプは、合成時点でその証拠が出典に存在したことを証明する——これは、出典が変化する（wiki、ウェブページ、チケットシステム）場合に、後の読者がどのバージョンが引用されたかを知る上で重要だ。取得タイムスタンプのない情報来歴は弱い。

マルチエージェント研究システムにおける出典参照

CCA-F のマルチエージェント研究システムシナリオでは、複数の subagent が独立して重複するコンテンツを取得する場合がある。情報来歴スキーマは、2つの subagent が同じチャンクを引用している場合（クロスソース三角検証の候補）と、同じドキュメントから異なるチャンクを引用している場合を区別するのに十分な識別子を持たなければならない。チャンクインデックスがその区別を可能にするフィールドだ。

マルチソース競合解決 — 出典が同一の事実について意見が異なる場合

マルチソース合成では、矛盾する出典が日常的に引き込まれる。古い CRM ノートは顧客が Basic プランだと言い、請求 API は Pro と言い、先週のサポートケース記録は「今アップグレードした」と言っている。情報来歴で競合を可視化し、競合解決ポリシーで合成出力の内容を決める。

4つの競合解決ポリシー

1. 最新優先（most-recent-wins） — retrieved_at または出典公開日で決着。変化する事実（プランの階層、住所、ステータス）に適切。
2. 権威出典優先（authoritative-source-wins） — 出典種別で決着（請求 API > CRM ノート > フリーテキストの記録）。一方の出典が record of truth である場合に適切。
3. 両方報告（report-both） — 両方の値とその出典を提示。下流の人間が判断すべき事実が真に解決できない場合に適切。
4. エスカレート（escalate） — 合成を拒否し、ヒューマンレビュアーに競合を返す。高リスクの事実（法的、医療的、財務的）に適切。

プロンプトへのポリシーエンコード

競合解決ポリシーはシステムプロンプトに明示しなければならない。「請求 API が CRM ノートと異なる場合は請求 API を信頼し、CRM の値をクレームの conflicting_sources フィールドに記録する。」この指示がなければ、Claude はサイレントに適当な値を選ぶ——競合を隠して情報来歴を損なう。

conflicting_sources フィールド

成熟した情報来歴スキーマでは、解決された競合が出力に残るよう、各クレームを conflicting_sources 配列で拡張する。解決された値は sources に、負けた値は conflicting_sources に入る。下流の監査担当者は conflicting_sources リストを検査して、ポリシーが正しく適用されたかを確認できる。

不確実性表現 — 構造化出力への明示的な不確実性フラグの付与

情報来歴はクレームの出所を教えてくれる。不確実性表現はそのクレームをどの程度信頼すべきかを教えてくれる。CCA-F グレードの合成パイプラインは、「おそらく」や「伝えられるところでは」などの散文の中に不確実性を埋めるのではなく、出力内のすべてのクレームに明示的な不確実性フラグを付与する。

列挙型フィールドとしての不確実性

最もクリーンな表現は、少数の明確に定義された値を持つ列挙型の uncertainty フィールドを各クレームに持たせることだ。

• high — 出典カバレッジが低い、出典が競合している、またはクレームが複数チャンクからの推論を必要とした。
• medium — 単一の権威出典。裏付けなし。
• low — 複数の裏付ける権威出典あり。競合なし。
• unverified — いずれの出典も直接的な証拠を提供していない。クレームは Claude の推論または外挿。

列挙型がフリーフォームより優れる理由

列挙型の不確実性フィールドは機械的にフィルタリング可能だ——「high および unverified クレームのみ表示」が下流クエリとして成立する——が、フリーフォームの不確実性文字列はそうではない。CCA-F シナリオは構造化された列挙型が散文アノテーションより優れていると一貫して評価する。構造化は検証・ルーティング・自動エスカレーションを可能にするからだ。

Claude の確信度と出典の信頼性は同じではない

微妙だが試験にとって重要な区別がある。Claude がソーステキストから正しい値を抽出したという内部確信度は、出典そのものの信頼性と同じではない。信頼性の低い出典から高い確信度でクレームを抽出できる。情報来歴スキーマはこの2軸を分離しなければならない。典型的には source_quality: authoritative | reputable | user-generated | unverified のような第2の列挙型フィールドで分ける。

確信度と不確実性 — モデル確信度と出典信頼性の区別

確信度と不確実性の区別には独自の H2 を割り当てる価値がある。Domain 5 のコミュニティ合格レポートで単一の最多見落とし概念として挙げられているからだ。これらを同義語として扱う CCA-F 受験者は、少なくとも1問のスコア問題を失う。

モデル確信度

モデル確信度は、抽出品質についての Claude 内部シグナルだ。「この 10-Q の収益数値が42億ドルである確信は95%だ。」これは合成ステップそのものについての発言だ。モデル確信度は 10-Q が正しいかどうかについては何も語らない。Claude が 10-Q を正しく読んだかどうかを伝えるだけだ。

出典信頼性

出典信頼性はモデルではなく出典の属性だ。「10-Q は SEC 監督下の上場企業が作成した規制対象の財務申告書だ。」規制対象の申告書は信頼性が高く、精選された wiki は中程度、未検証のユーザー生成コンテンツは低い。同じ抽出タスクで、信頼性の低い出典に対して高いモデル確信度を得ることができる（Claude が Reddit コメントを明確に読んだ。そのコメントが間違っている可能性はある）。

出力不確実性は結合

最終出力の不確実性が下流消費者に報告するものだ。それはモデル確信度と出典信頼性の結合であり、クロスソース裏付けによってさらに調整される。クレームが low 不確実性に達するのは、高いモデル確信度・権威ある出典・少なくとも1つの裏付け出典——3条件がすべて満たされる場合のみだ。

この区別における試験のトラップ

典型的なディストラクターはこう言う。「Claude のログ確率が高いため、合成されたクレームは信頼できる。」誤り。高いログ確率は Claude が抽出に自信があることを意味し、出典についての自信ではない。別のディストラクター：「出典が SEC であるため、Claude が正しく要約したかにかかわらずクレームは信頼できる。」これも誤り——出典信頼性は必要条件だが十分条件ではない。正解は両軸を処理する。

ヘッジ言語パターン — 生成テキストにおける不確実性の言語マーカー

出力スキーマが構造化された不確実性フィールドを強制している場合でも、各クレームの text フィールドは自然言語を含んでおり、Claude がその散文で選ぶヘッジングは意味を持つ。よく設計されたプロンプトは、Claude にヘッジ言語を構造化された不確実性値と整合させるよう指示する。

正典的なヘッジマーカー

• "according to [source]"（[出典]によると）— 中立的な帰属。ヘッジなし。
• "reportedly" / "reported to"（伝えられるところでは）— 中程度のヘッジ。クレームが出典に存在するが独立検証されていないことを示唆。
• "may" / "might" / "could"（かもしれない）— 強いヘッジ。相当な不確実性または推論を示唆。
• "appears to" / "is likely"（〜と思われる / おそらく）— 強いヘッジ。Claude が推論を行っている。
• "inferred from"（〜から推論）— 外挿の明示マーカー。常に unverified または high 不確実性とペアにすべき。

散文のヘッジと構造化不確実性の整合

よくある失敗モードは、構造化の uncertainty フィールドが low である一方、散文が積極的にヘッジングしている、またはその逆だ。このミスマッチは、散文を読む下流の人間と構造を読む自動システムを混乱させる。システムプロンプトは整合を明示的に要求すべきだ。「text フィールドのヘッジ言語を uncertainty レベルと一致させること。low のクレームには直接的な主張を使用し、medium 以上には明示的なヘッジマーカーを使用すること。」

カスタマーサポートシナリオにおけるヘッジング

カスタマーサポート合成において、「顧客のプランは Pro だ」（ヘッジなし、不確実性 low）と「最新チケットに基づき顧客のプランは Pro と思われる」（ヘッジあり、不確実性 medium）は全く異なる。この違いが、エージェントが自律的な請求アクションを実行できるか、人間にエスカレートしなければならないかを決定する。情報来歴がこの区別を機械的に可視化する。

ソース品質重み付け — 権威ある出典を高い確信度として扱う

すべての出典が等しい重みに値するわけではない。本番の情報来歴パイプラインは、各クレームの最終的な不確実性を決定する前に、設定された権威階層によって出典を重み付けする。

階層化された出典ヒエラルキー

エンタープライズのマルチエージェント研究システムの典型的な階層：

1. Tier 1 — Record of truth のシステム（請求 API、HRIS、ソース管理リポジトリ）。管轄する事実に対して権威的。
2. Tier 2 — 精選された内部知識（エンジニアリング wiki、承認済みランブック）。信頼できるが時々古い。
3. Tier 3 — トランザクションログ（サポートチケット履歴、チャット記録）。過去の出来事には正確だが現在の状態には必ずしも正確でない。
4. Tier 4 — 外部公開ソース（ベンダードキュメント、ニュース、ウェブ検索結果）。背景として使用。可能な場合は上位 tier と照合。
5. Tier 5 — ユーザー生成（フォーラム投稿、コミュニティ回答）。最低重み。主張する前に裏付けが必要。

実践における重み付け

重み付けはシステムプロンプトにエンコードし、出力スキーマで強制する。「Tier 1 の出典が Tier 3 の出典と異なる場合は Tier 1 を信頼し、Tier 3 の値を conflicting_sources に記録する。Tier 4 または Tier 5 の出典のみに支持されるクレームは、少なくとも1つの Tier 1-3 の出典が裏付けない限り uncertainty: medium 以上にしなければならない。」

重み付けが情報来歴にとって重要な理由

明示的な重み付けがなければ、Claude はパイプライン所有者が監査できない暗黙の不安定な順序付けを適用する。明示的な重み付けにより、情報来歴は決定論的になる——同じ入力は常に同じ信頼決定を生成し、人間の監査担当者がポリシーが適用されたかを検証できる。

クロスソース三角検証 — 高い確信度を主張する前に裏付けを求める

三角検証とは、クレームを low 不確実性に昇格させる前に複数の独立した出典が一致することを求める情報来歴の手法だ。ハルシネーションと「Reddit の1コメントを事実として引用する」という失敗モードの両方に対する最強の防衛手段である。

三角検証ルール

典型的な三角検証ポリシー：「クレームが uncertainty: low で出力されるのは、異なるドキュメント（理想的には異なる出典 tier）の少なくとも2つの出典がクレームを裏付ける場合に限る。出典の権威にかかわらず、1つの出典しかないクレームはデフォルトで uncertainty: medium とする。」

異なるチャンクではなく異なるドキュメントが必要な理由

三角検証は異なるドキュメント（理想的には異なる出典種別）を必要とし、同じドキュメントの異なるチャンクでは不十分だ。同じ 10-Q から取得した2つのチャンクは独立した証拠ではない——単一の著者と単一の編集プロセスを共有している。文書内のチャンクが一致することを三角検証と数える情報来歴は典型的な素朴なバグだ。CCA-F シナリオ問題は、文書内一致（三角検証でない）と文書間一致（三角検証）を区別できるかを試している。

マルチエージェント研究システムにおける三角検証

マルチエージェント研究システムシナリオでは、coordinator が特に三角検証を可能にするために複数の subagent を独立した出典プールに派遣できる。Subagent A は会社の wiki を検索し、Subagent B はチケットシステムを検索し、Subagent C は外部ウェブ結果を検索する。3つすべてが同じ事実を返したとき、coordinator はその事実を low 不確実性に昇格させる。これは CCA-F 練習問題に頻繁に現れる情報来歴アーキテクチャの直接的な応用だ。

来歴監査証跡 — 追跡可能性のための取得・合成ステップのログ記録

出力における情報来歴は価値がある。パイプラインログにおける情報来歴は、出力を数週間または数ヶ月後に監査可能にするものだ。監査証跡は完全な取得と合成の履歴をキャプチャするため、最終的なクレームを再現または反証できる。

来歴監査証跡が記録するもの

最小限の情報来歴監査証跡は、すべての合成実行についてログに記録する：

• 実行 ID — 合成呼び出しの一意識別子。
• 取得イベント — クエリテキスト、ベクトルインデックスバージョン、ID と取得タイムスタンプを持つ返却チャンク。
• ツール呼び出し — Claude が発行したすべての tool_use ブロック、返された各 tool_result。
• Subagent 派遣 — どの subagent がどのサブタスクを処理したか（独自の実行サブ ID を含む）。
• 競合解決 — 検出されたすべてのマルチソース競合と解決したポリシー。
• 最終合成出力 — 不確実性フラグと conflicting_sources を含む完全な構造化クレーム配列。
• セッション ID — 合成を会話に結びつける Agent SDK のセッション識別子。

監査証跡がコンテキストウィンドウを超える理由

監査証跡は Claude のコンテキストウィンドウの外——外部ログストア（オブジェクトストレージ、耐久キュー、SIEM）——に置かなければならない。コンテキストウィンドウは長時間稼働する合成が蓄積するもののほんの一部しか保持できず、刈り込まれたコンテキストは回復不可能だ。情報来歴では、取得と合成のイベントが一時的なものではなく耐久性のあるものであることが必要だ。

セッション ID と監査証跡の結びつき

Agent SDK のセッション ID は合成実行と監査証跡を結ぶリンクのプリミティブだ。セッションをフォークすれば監査証跡はフォークポイントを記録し、セッションを再開すれば監査証跡は再開したログを親に結びつけなければならない。このリンクが、情報来歴がセッション境界を越えて生き残ることを可能にする——長時間稼働の研究ワークフローでの一般的なパターンだ。

不確実性エスカレーション — 低来歴のアサーションのヒューマン検証へのルーティング

情報来歴はエスカレーション時に力を発揮する。すべてのクレームに明示的な不確実性タグを付ける合成パイプラインは、人間が出力全体を読むことなく、高不確実性クレームを自動的にヒューマン検証にルーティングできる。

エスカレーションルーティングルール

典型的な情報来歴エスカレーションポリシー：「uncertainty: high または unverified のクレーム、または未解決ポリシー下で conflicting_sources が空でないクレーム、または支持する出典がすべて Tier 4 / Tier 5 であるクレームは、最終出力が下流消費者にリリースされる前に人間のレビュアーにルーティングする。」

カスタマーサポートシナリオにおけるエスカレーション

カスタマーサポート解決エージェントシナリオでは、情報来歴パイプラインが顧客チケットを取り込み、CRM・請求・知識ベースから取得し、クレームごとの出典を持つ提案解決策を合成する。顧客のプラン階層に関するクレーム（Tier 1、請求 API）は low 不確実性であり、エージェントは自律的に行動できる。以前のチケットから推論された顧客の感情に関するクレーム（Tier 3、トランザクション）は medium または high 不確実性であり、トーンに敏感な返信を送信する前に人間に表面化させなければならない。情報来歴がこのルーティングを機械的にする。

エスカレーションと拒否の区別

エスカレーションは合成を拒否することと同じではない。よく設計されたパイプラインは、クレームごとの不確実性を持つ完全な合成を生成し、高不確実性サブセットのみをエスカレートする。1つのクレームが不確かだからといって合成全体を拒否することは、信頼できるクレームに対してすでに行われた作業を無駄にする。

やさしい解説: 情報来歴の抽象的な仕組みは、具体的な物理的システムに固定することで直感的になる。3つの全く異なる類比でprovenance と不確実性の全領域をカバーする。

Analogy 1: 図書館の目録カード — 来歴とチャンクインデックス

伝統的な研究図書館の目録カードを思い浮かべてほしい。すべてのカードには特定の本の請求番号、棚の場所、著者、出版日、版が記載されている。司書が利用者の質問に答えるとき、「どこかにそれを述べた本がある」とは言わない——請求番号を引用する。利用者は棚に行き、正確な版を取り出し、引用されたページのパラグラフを読める。それが情報来歴だ。

今度は、3冊の本をパラグラフに要約し、どの事実がどの本から来ているか言わない司書を想像してほしい。利用者は何も検証できない。それが来歴なしのマルチソース合成だ。CCA-F グレードのパイプラインは Claude に司書の目録カードの規律を与える——合成された出力内のすべてのクレームが、出典ドキュメント・チャンクインデックス・取得タイムスタンプを持つ。これは請求番号・ページ・版の日付に相当する。2冊の本が矛盾する場合、司書はサイレントに一方を選ばない——利用者が判断できるようカードに不一致を書き留める。それが conflicting_sources を使ったマルチソース競合解決だ。

Analogy 2: 損害保険の示談担当者のクレームファイル — 不確実性フラグと競合解決

損失を調査する損害保険の示談担当者は、クレームを額面通りに受け入れない。証拠——警察の報告書、目撃者の証言、写真、修理見積り——を収集し、各証拠に日付・出典・来歴ノートのスタンプを押す。担当者が最終決定を書くとき、すべての事実的主張は証拠ファイルの項目を指し示す。2人の目撃者が異なる証言をする場合、担当者は両方の証言を記録し、どちらをより重く扱ったかとその理由を説明する。不確かな項目——「申請者が主張するが裏付け証拠なし」——は散文に混合させるのではなく明示的にフラグが立てられる。

クレームファイルが監査証跡であり、最終決定書が合成出力であり、証拠スタンプが出典参照フィールドだ。裏付け証拠なしにわかりやすいサマリーを書く担当者は雇用されない。Claude のマルチソースパイプラインにおける情報来歴は同じ規律を課す。列挙型の uncertainty フィールドが担当者の「申請されたが未裏付け」スタンプだ。三角検証が「1人の目撃者は争いのある事実には不十分」という担当者のルールだ。

Analogy 3: ツーソース確認ルールのあるニュースルーム — 三角検証と出典品質重み付け

伝統的なニュースルームは明示的なツーソースルールで運用する。争いのある事実を公開する前に、記者は第2の出典から独立した裏付けを得なければならない。単一の匿名情報提供者では不十分。単一のリーク文書では不十分。独立性が重要だ——同じプレスリリースを引用する同じ媒体の2人の記者は、1回読まれた1つの出典に過ぎない。

ツーソースルールを満たせない場合、記者は情報の構造化された不確実性を反映するヘッジ言語を使う（「消息筋によると」「伝えられるところでは」「とされている」）。出典が矛盾する場合、記事は両方の立場を記録し、それぞれを帰属させる。ニュースルームのスタンダードデスクは公開前にファクトチェックノートを確認する——これが不確実性エスカレーションの高不確実性クレームをヒューマンレビューにルーティングすることに相当する。

CCA-F 情報来歴アーキテクチャは、プロンプトとスキーマで実装されたニュースルームだ。三角検証がツーソースルールであり、出典品質重み付けがニュースルームの階層（通信社 > プレスリリース > 匿名情報提供者）であり、ヘッジ言語が記者の散文であり、ファクトチェックファイルが監査証跡だ。

どの類比がどの試験問題に合うか

• 出典識別フィールドと監査証跡についての問題 → 図書館目録カードの類比。
• 不確実性フラグと競合解決についての問題 → 損害保険示談担当者の類比。
• 三角検証と出典品質重み付けについての問題 → ニュースルームのツーソース類比。

よくある試験のトラップ

CCA-F タスク5.6 は5つの繰り返し発生する情報来歴トラップパターンを一貫して利用する。5つすべてがコミュニティの合格レポートに記録されており、もっともらしいディストラクターとして現れる。

トラップ 1: Claude が自然に出典を引用すると想定する

タスク5.6 の最多引用ミスは、プロンプトにソースドキュメントを含めれば Claude が自動的に出力でそれらを引用すると想定することだ。そうはならない。マルチソース Claude パイプラインの情報来歴は、strict tool use によって強制されたクレームごとの必須 sources 配列を持つ明示的な出力スキーマを必要とする。構造的強制なしに「Claude に散文で出典を引用させる」と提案する解答は誤りだ。

トラップ 2: モデル確信度と出典信頼性を混同する

信頼性の低い出典から高いモデル確信度でクレームを抽出できる。ディストラクターは「Claude が自信を持っている」を「クレームが信頼できる」と同等に組み立てる。正しいメンタルモデルは、モデル確信度（抽出品質）と出典信頼性（出典の権威）を分離し、クロスソース裏付けが存在し両軸が満たされる場合にのみクレームを低不確実性と見なす。

トラップ 3: 監査証跡をコンテキストウィンドウに保存する

素朴なアプローチは、「Claude が後で参照できるよう」会話履歴内に取得と合成のログを蓄積することだ。コンテキストウィンドウは監査証跡が役立つ前に刈り込まれ、コンパクト化され、またはキャップされる。情報来歴の監査証跡はセッション ID をキーとする耐久外部ストレージに置かなければならない。インコンテキスト監査証跡を提案する解答はアーキテクチャ的に不健全だ。

トラップ 4: 文書内チャンクを三角検証としてカウントする

同じドキュメントの2つのチャンクは独立した証拠ではない。ディストラクターは「10-Q からの複数のチャンクが一致するため、クレームは三角検証された」と提示する。誤り。三角検証は独立性が裏付けを意味のあるものにするため、異なるドキュメント（理想的には異なる出典 tier）を必要とする。CCA-F シナリオ問題はこの区別を具体的にテストする。

トラップ 5: フラグが立てられたサブセットではなく合成全体をエスカレートする

一部のクレームで不確実性が検出されたとき、正しい対応は部分リリースだ——完全な構造化出力を出力し、不確かなサブセットにフラグを立て、フラグが立てられたサブセットのみをヒューマンレビューにルーティングする。「いずれかのクレームが不確かな場合は何も返さない」や「すべてのクレームが自信を持てるまで最初から再合成する」と提案するディストラクターはどちらも、すでに行われた信頼できる作業を無駄にし、構造化された不確実性表現の目的を損なう。

実践アンカー

情報来歴と不確実性は6つの CCA-F シナリオのうち2つに最も強く現れる。以下をタスク5.6 のシナリオクラスター問題のアーキテクチャの骨格として扱う。

マルチエージェント研究システムシナリオ

このシナリオでは、coordinator エージェントが複数の subagent を独立した出典プールに派遣する——会社 wiki、チケットシステム、外部ウェブ、内部 CRM——それぞれが自身の証拠ベースから同じ研究質問に答えるタスクを持つ。subagent は構造化されたクレーム配列を返し、coordinator はフルの情報来歴を持つ最終回答を合成する。クロスソース三角検証（coordinator がいつクレームを low 不確実性に昇格させられるか？）、競合解決ポリシー（subagent が意見を異にする場合どの subagent が勝つかを誰が決めるか？）、監査証跡の外部化（取得ログはどこに置くか？）、不確実性エスカレーション（どのクレームが人間にルーティングされるか？）をテストする問題を予期する。

構造化データ抽出シナリオ

このシナリオでは、Claude が1つ以上のソースドキュメントから構造化レコード（契約条件、請求書フィールド、コンプライアンス属性）を抽出するよう求められる。ここでの情報来歴は、マルチエージェントオーケストレーションよりも、フィールドごとの出典帰属——すべての抽出フィールドがドキュメント URI・ページまたはチャンク・不確実性フラグを持つ——についてだ。フィールドごとの出典スキーマの strict tool use 強制、欠落した証拠の処理（出典が要求されたフィールドを含まない場合にどの uncertainty 値を出力するか？）、構造化フィールドと散文サマリーの間のヘッジ言語整合、出力内の出典 ID が取得ログに実際に存在することのバリデーションをテストする問題を予期する。

FAQ — 情報来歴と不確実性 上位7問

Claude のマルチソースパイプラインにおける情報来歴とは正確に何か？

情報来歴とは、Claude の合成された出力内のすべての原子的クレームが、特定の出典ドキュメント・チャンク・取得タイムスタンプ、そして（マルチエージェントシステムでは）それを生成した subagent まで遡れるという性質だ。Claude は情報来歴を自動的に生成しない——クレームごとの必須出典フィールドを持つ構造化出力スキーマ、スキーマ違反を拒否する strict tool use、そして引用された出典 ID が取得ログに実際に存在することを確認する合成後バリデーションを通じて設計によって実現しなければならない。情報来歴は CCA-F タスク5.6 でテストされる中心的コンピテンシーであり、コミュニティの合格レポートは「Claude が自然に引用すると想定した」を Domain 5 で最高頻度のミスの一つとして挙げる。

すべてのクレームに少なくとも1つの出典があることを強制するにはどうすればよいか？

各クレームオブジェクトに必須の空でない sources 配列を持つ（tool use による）構造化出力スキーマを定義し、tool 定義に strict: true を設定し、クレームの sources 配列が空または取得ログに存在しない ID を含む出力を拒否する合成後バリデーションを追加する。Strict tool use はスキーマレベルの強制を与え、事後バリデーションは意味的強制（ハルシネートされた出典 ID なし）を与える。本番の情報来歴には両方が必要だ——スキーマ強制だけでは、整形式だが捏造された出典 ID を捕まえられない。

モデル確信度と出典信頼性の違いは何か？

モデル確信度は、抽出品質についての Claude の内部シグナルだ——Claude が出典を正しく読んだかについての確実性。出典信頼性は出典そのものの属性だ——著作者と編集プロセスがどれほど信頼できるか。それらは直交する。Claude は信頼性の低い出典から高い確信度で抽出できる（信頼性の低い Reddit コメントを正確に読んだ；その Reddit コメントが間違っている可能性がある）し、信頼性の高い出典から低い確信度で抽出できる（SEC 申告書への部分的なアクセス）。最終出力の不確実性は両軸プラスクロスソース裏付けの結合であるべきで、Claude の確信度だけではない。これらを混同することは CCA-F Domain 5 のトップ5のトラップだ。

競合する出典をどう処理するか？

競合解決ポリシー——最新優先・権威出典優先・両方報告・エスカレート——をシステムプロンプトで指定し、各クレームの出力スキーマを conflicting_sources 配列で拡張して負けた値が監査可能であるようにする。解決された値は sources に、負けた値は独自の ID と取得タイムスタンプとともに conflicting_sources に置く。明示的なポリシーなしに Claude がサイレントに値を選ぶことを許してはならない。CCA-F の問題は「Claude に決めさせる」と提案する解答を明示的な競合解決ルールなしで一貫して減点する。

文書内の裏付けがなぜ三角検証としてカウントされないのか？

三角検証は、テキストの繰り返しではなく、編集プロセスの独立性についてだ。同じ 10-Q 申告書からの2つのチャンクは、単一の著者・単一の法的審査サイクル・単一の公開イベントを共有する。申告書がある事実について誤っていれば、すべてのチャンクがその事実について誤っている。クロスソース三角検証は、単一の編集上の失敗が単一ポイントを生き残れるため、異なるドキュメント、理想的には異なる出典 tier（請求 API レコード + CRM ノート + チケット記録）を必要とする。CCA-F シナリオ問題は、ディストラクターとして「同じ出典からの複数のチャンク」を具体的に提示し、受験者がそれを low 不確実性の主張に不十分として拒否することを期待する。

来歴監査証跡はどこに置くべきか？

耐久外部ストレージ——オブジェクトストレージ（S3 / R2）、専用監査データベース、または SIEM——に、Agent SDK のセッション ID（および各合成呼び出しの実行 ID）をキーとして置く。Claude のコンテキストウィンドウは実行可能な場所ではない。監査が重要になるずっと前に刈り込まれ、要約され、またはコンパクト化される。監査証跡は取得イベント（クエリ、インデックスバージョン、返却チャンク）、すべての tool_use と tool_result、すべての subagent 派遣、すべての競合解決、そして最終構造化出力をキャプチャしなければならない。情報来歴は耐久性の性質であり、耐久性とはセッション識別子でリンクされた帯域外ストレージを意味する。

不確実性はヒューマンエスカレーションとヘッジのどちらをトリガーすべきか？

設定可能な不確実性しきい値（通常 high または unverified）を超えるクレーム、未解決ポリシー下で conflicting_sources が空でないクレーム、または支持する出典がすべて最低 tier（ユーザー生成、未検証の外部）であるクレームの場合はエスカレートする。単一の権威出典に支持されており矛盾する証拠がないクレームの場合は、medium 構造化不確実性に整合したヘッジ（「伝えられるところでは」や「〜と思われる」などの散文マーカー）を使う。判断ルールは次の通りだ——不確実性を考えると下流の自律的なアクションが危険である場合はエスカレートし、人間の読者に注意を促すべきだがシステムは続行できる場合はヘッジする。常にクレームのフラグが立てられたサブセットのみをエスカレートし、合成全体はエスカレートしない——部分リリースはすでに行われた信頼できる作業を保持する。

さらなる読み物

• Session management — Agent SDK: https://docs.anthropic.com/en/docs/claude-code/sdk/sdk-sessions
• Long context prompting tips: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/long-context-tips
• Context windows — Claude API Docs: https://docs.anthropic.com/en/docs/build-with-claude/context-windows
• Increase output consistency — structured outputs: https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/increase-consistency
• Strict tool use — schema-guaranteed output: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/strict-tool-use
• Building effective agents — escalation and human-in-the-loop: https://docs.anthropic.com/en/docs/build-with-claude/agentic-loop

関連 ExamLab 章節：長期インタラクションにわたる会話コンテキスト、ヒューマンレビューワークフローと確信度キャリブレーション、マルチエージェントオーケストレーション、エスカレーションと曖昧さの解決。