技術要約：エージェントシステムにおける「信頼性のロンダリング（Confidence Laundering）」

1. 問題提起：インターフェースのボトルネックと信頼性のロンダリング

現代のマルチステップ・エージェントシステム、特に大規模言語モデル（LLM）を動力源とするものは、複雑なタスクを、ツール呼び出し、検索、および中間的な推論を含むサブタスクへと分解する。近年の研究は、個々のステップにおける不確実性の推定や、軌跡全体にわたる不確実性の集計に焦点を当ててきたが、決定的な構造的欠陥が依然として存在する。それは、コンポーネント間でいかに不確実性が伝播するかという点である。

本論文は、「信頼性のロンダリング（confidence laundering）」と名付けられた現象を特定している。標準的なエージェント・アーキテクチャにおいて、上流のコンポーネントは、不確実性、曖昧さ、または希薄な証拠の下で中間的な決定（例：ツール呼び出し、検索クエリ、検索された一節、構造化されたフィールド）を下す。しかし、標準的なインターフェースは、コミットされたアーティファクト（成果物）——すなわち、離散的で実行可能な出力のみ——を転送し、その出力を生み出したエピステミックな状態（認識論的な状態）（躊躇、競合する仮説、あるいは脆弱性）を破棄してしまう。

これにより、インターフェースのボトルネックが生じる：

• 多対一の投影（Many-to-One Projection）: 非常に異なる不確実性プロファイルを持つ様々な内部状態（例：自信のある決定 vs. 複数の選択肢の間での僅差の判断）が、同じ離散的なアーティファクト（例：同じ検索クエリやAPIコール）へと投影される。
• 脆弱性の喪失（Loss of Fragility）: 下流のコンポーネントは、プロシージャルに有効で実行可能に見える「クリーンな」オブジェクトを受け取る。彼らは決定自体は継承するが、その背後にある不確実性は継承しない。
• システムレベルのエラー増幅: 下流のエージェントは、これらの脆弱な上流の決定を安定した前提条件として扱うため、過信を招く。注意、明確化、またはルーティングの変更を促すべき不確実性が、流暢なテキストや有効なJSONの背後に隠されてしまい、局所的な較正（キャリブレーション）の失敗がシステムレベルの失敗へと連鎖する。

著者らは、不確実性の伝播とは単なる軌跡レベルの推定問題ではなく、インターフェース設計の問題であると主張している。不確実性は、上流の決定の「脆さ」が次のコンポーネントへの受け渡しにおいて生存するかどうかにかかっている。

2. 方法論と核となる概念

2.1 不確実な意思決定の受け渡し（Uncertain Decision Handoff）

本論文では、不確実な意思決定の受け渡しを、「不確実性の下で行われた中間的な決定を、上流コンポーネントから下流コンポーネントへ転送すること」と定義する。単純な通信とは異なり、受け渡しは運用の責任を転送する。下流のコンポーネントは、そのアーティファクトを計算、ツール実行、または回答生成のための前提として使用する。もし受け渡しによって「脆さ」の文脈が剥ぎ取られてしまうと、下流のコンポーネントはその前提の信頼性を判断できなくなる。

2.2 潜在的な不確実性（Latent Uncertainty）としてのキャリア

信頼性のロンダリングに対処するため、著者らは**潜在的な不確実性（latent uncertainty）**を提案している。

• 定義: 潜在的な不確実性とは、エージェントの内部的な連続状態（例：隠れ状態、活性化、またはKVトレース）から導出され、意思決定の受け渡しに付随する、不確実性を保持した表現である。
• スカラー値やテキスト信号との違い: スカラー値による信頼度スコア（多次元的なエピステミック状態を単一の数値に崩壊させるもの）や、テキストによる根拠（言い回しに依存し、不確実性の構造を圧縮してしまう可能性があるもの）とは異なり、潜在的な不確釈性は**表現レベルのキャリア（運び手）**として機能する。それは、自然言語によるコミュニケーションを必ずしも置き換えることなく、下流のコンポーネントが利用可能な形で「コミット前の脆さ」を保持する。
• 目的: 目的は、テキストを隠れ状態で置き換えることではなく、インターフェースの崩壊を経ても「疑念」が生存するようにし、下流のエージェントが適切なリカバリ・アクション（例：明確化、再試行、検証、またはルーティングの変更）をトリガーできるようにすることである。

2.3 実験設定

著者らは、Qwen-1.5Bを用い、HotpotQAデータセットをウェブ検索ツール使用の設定に変換して、自説を検証している。

• タスク: 上流のエージェントは、マルチホップの質問を受け取り、検索クエリを策定し、Tavilyウェブ検索APIを呼び出し、返されたスニペットを処理し、最終的な回答を生成する。
• 不確実性のラベル付け: データセットの難易度ラベル（Easy/Medium/Hard）に頼るのではなく、行動ベースで不確実性ラベルを導出する。モデルは質問ごとに複数の軌跡（$K=20$）をサンプリングする。得られた回答クラスターの**セマンティック・エントロピー（意味論的エントロピー）**が、不確実性のグラウンドトゥルース（高エントロピー ＝ 高不確実性）として機能する。
• 受け渡し条件: 研究では、以下の4つの受け渡し条件における下流の不確実性回復可能性を比較する：
  1. 回答のみ（Answer-only）: 標準的なインターフェース（最終回答のみ）。
  2. スカラー・スコア（Scalar Score）: 最終回答 ＋ スカラー値の不確実性スコア。
  3. テキストによる不確実性（Textual Uncertainty）: 最終回答 ＋ 不確実性に関する自然言語による記述。
  4. 潜在的な不確実性（Latent Uncertainty）: 最終回答 ＋ 上流の隠れ状態から導出されたキャリア（軽量な線形/MLP分類器を通じてプローブされたもの）。

3. 主な結果

実験的な観察結果は、「標準的なインターフェースは上流の不確実性を消去しており、潜在的な不確実性がより優れたキャリアとして機能する」という仮説を支持している。

1. 難易度ラベルの不十分さ: HotpotQAの難易度ラベル（Easy/Medium/Hard）は、モデルの不確実性を明確に予測しない。セマンティック・クラスターの分布は難易度レベル間で大きく重なっており、これは不確実性がタスクの難易度そのものではなく、モデル固有のものであり、ツール使用プロセス（例：クエリ策定、証拠の網羅性）に依存していることを示している。
2. 隠れ状態には回復可能な不確実性が含まれている: 隠れ状態（具体的にはトランスフォーマーの第7、14、28層）に対して訓練された軽量なプローブは、強いAUROCをもってセマンティック・エントロピーに基づく不確実性ラベルを回収できる。性能はモデルの深さとともに向上し、不確実性が最終的なテキスト出力へと圧縮される前に、潜在表現の中にエンコードされていることが確認された。
3. 潜在的な不確実性は他のキャリアよりも優れている: 下流の不確実性検出タスクにおいて、潜在的な不確実性の受け渡し条件は、AUROCおよび精度（Accuracy）の両方において、Answer-only、Scalar Score、およびTextual Uncertaintyの条件を大幅に上回った。
   • Answer-only AUROC: ~0.618
   • Scalar Score AUROC: ~0.667
   • Textual Uncertainty AUROC: ~0.785
   • Latent Uncertainty AUROC: ~0.874
     これは、コミットされたテキストによるアーティファクトや圧縮された注釈は、上流の脆さの源泉と構造に関する重要な情報を失う一方で、潜在的な表現はそれらを保持できることを示唆している。

4. 貢献

本論文の主な貢献は以下の4点である：

1. 不確実性伝播の再定義: 不確実性を「ステップごとの推定」の問題から、**「インターフェースの問題」**へと視点を転換し、インターフェースがコミットされたアーティファクトのみを露出する場合に不確実性の伝播が失敗することを論じた。
2. 失敗モードの定義: 脆弱な上流の状態が、信頼できる下流の前提として再パッケージ化されるメカニズムとして、**「不確実な意思決定の受け渡し」と「信頼性のロンダリング」**を正式に定義した。
3. 潜在的な不確実性の導入: 潜在的な不確実性を、コミット前の脆さを、下流で使用可能な形で保持するように設計された表現レベルのキャリアとして提案した。
4. 実証的検証: 標準的なインターフェースが上流の不確実性を隠蔽すること、および潜在的な不確実性キャリアが、スカラー値やテキストによる信号よりも効果的な下流のリカバリ動作を可能にすることを実験的証拠によって示した。

5. 意義と主張

本論文は、エージェントシステムがより堅牢で回復可能（recoverable）になるためには、不確実性の伝播を単なるモデル出力の特性としてではなく、インターフェースの設計制約として扱う必要があると主張している。

• インターフェースの契約: 不確実性はコンポーネント間の「契約」の一部であるべきである。下流のエージェントは、適切な決定（例：検証するか、あるいはルートを変更するか）を下すために、そのアーティファクトが自信を持って作成されたのか、曖昧さの中で作られたのか、あるいは希薄な証拠に基づいているのかを知る必要がある。
• 最終的な正確性を超えて: エージェントシステムの評価は、最終回答の正確性や較正（キャリブレーション）を超え、「受け渡しの信頼性（handoff reliability）」、すなわち、下流のコンポーネントが脆弱な上流の決定を過度に信頼することを避け、適切なリカバリ・アクションをトリガーできているかどうかを評価する指標へと移行すべきである。
• 回復可能なシステム: エージェント・アーキテクチャの目標は、「クリーンなアーティファクト」を生成することから、エラーが連鎖する前に検知・緩和できるよう、疑念が十分に保持される「回復可能なシステム」を構築することへとシフトすべきである。

著者らは、潜在的な不確実性はスカラー値やテキストによる信号の普遍的な代替物ではなく、特に、コミットされたアーティファクトだけからは回復が困難な「脆さ」が下流の挙動に影響を与える場合に極めて重要であると述べ、謙虚な姿勢を維持している。また、モデルの内部へのアクセスや、ヘテロジニアス（異種混合）なコンポーネント間の互換性といった実用的な制約についても認めている。