latent-briefing

潜在ブリーフィングと KV キャッシュのメモリ共有

階層型マルチエージェントシステムでは、同じコンテキストに対して二重にコストがかかることがよくあります。オーケストレーターは長い推論の軌跡を蓄積しますが、各ワーカーに渡されるのは通常、サブタスクのプロンプトと生のドキュメント断片など、範囲の限られたテキストの引き継ぎ情報だけです。軌跡全体を渡せば情報の網羅性は高まりますが、ワーカーを呼び出すたびにトークンコストが増加します。要約では遅延と情報損失が生じます。検索はドキュメントへのアクセスには役立ちますが、変化し続けるオーケストレーターの推論状態は保持できません。

Latent Briefing は、テキストレベルではなく表現レベルでメモリを共有することで、この問題に対処します。中心となる考え方は、オーケストレーターの軌跡をワーカーモデルの KV キャッシュ内で圧縮し、現在のワーカータスクに最も関連する位置を保持することです。この手法は Attention Matching（AM） による KV キャッシュの圧縮を基盤とし、タスクに基づくクエリ、ヘッド間で共有するトークンマスク、堅牢な閾値処理を用いて、推論時のマルチエージェント間の引き継ぎに適用します。

有効化するタイミング

次の場合にこのスキルを有効にしてください。

• ワーカーがオーケストレーターの状態全体をテキストとして再送せずに、過去の状態にアクセスする必要がある、オーケストレーターとワーカー、またはスーパーバイザーとスペシャリストのシステムを設計するとき
• エージェント間の状態転送において、LLM による要約や RAG の代替手段を評価するとき
• KV キャッシュ圧縮を、同一のプロンプトを対象とするプレフィックスキャッシュだけでなく、推論の基本機能として実装または研究するとき
• 再帰型、階層型、またはツールを多用するエージェントグラフにおけるトークンの急増をデバッグするとき
• ワーカートークンの削減量、総トークンの削減量、圧縮のオーバーヘッド、精度を合わせて報告するベンチマークを解釈するとき

ほかのスキルが担当する関連作業では、このスキルを有効にしないでください。

• 内部の KV テンソルにアクセスできない API のみのスタック：context-compression、memory-systems、または multi-agent-patterns を使用してください。
• 通常の永続メモリ、エンティティ追跡、またはグラフ検索：memory-systems を使用してください。
• 表現レベルの状態共有を伴わない、一般的なマルチエージェントのトポロジー：multi-agent-patterns を使用してください。
• KV 状態を変換しないプレフィックスキャッシュ、マスキング、または予算ポリシー：context-optimization を使用してください。

中心概念

トークン急増のパターン。 再帰型や REPL スタイルのシステムでは、オーケストレーターが証拠の調査、仮説の検証、サブ質問への回答のために、ワーカーを繰り返し呼び出します。部分的な結論、行き詰まった試行、ツールの出力、過去のワーカー応答によって、オーケストレーターの軌跡は長くなります。ワーカーを呼び出すたびにその軌跡全体を渡すと、コストは急速に膨らみます。

表現レベルでの共有。 軌跡を自然言語に要約する代わりに、システムはワーカーモデルの KV キャッシュを操作します。現在のタスクでワーカーが注目する位置を保持し、それ以外を破棄します。これは通常のプレフィックスキャッシュよりも選択的です。プレフィックスキャッシュは同一のプレフィックスを再利用しますが、Latent Briefing では再利用する軌跡の内部でタスク条件付きの選択的保持も行います。

圧縮エンジンとしての Attention Matching。 AM は、完全なキャッシュに近いアテンション出力を得られる、より小さなキャッシュを目指します。Latent Briefing は、スコアリング信号とバッチ処理の戦略を変更し、AM をマルチエージェント推論に適用します。

1. 現在のワーカープロンプトから導出したタスクに基づくクエリベクトルを使用します。
2. ヘッドごとに独立したサブセットを作成する代わりに、スコアを共有グローバルマスクに集約します。
3. ヘッドごとに固定の top-k を適用する代わりに、median + tau * MAD などの堅牢な閾値を使用します。

参考となる結果の目安。 公開資料では、長文書の QA ワークロードにおいて、ワーカートークンが大幅に削減され、総トークンも相当量削減され、圧縮のオーバーヘッドが数秒以内に収まると報告されています（claim-latent-briefing-public-results）。これらの数値は特定のワークロードにおける根拠として扱い、一般的な保証とはみなさないでください。

詳細トピック

テキストのみの軽減策では不十分な理由

アプローチ	主な弱点
LLM による要約	レイテンシが高く、情報が失われる抽象化であり、次のサブタスクで必要な情報が要約に保持される保証もありません
検索／RAG	チャンク分割と埋め込みに依存するため、チャンク間やステップ間の依存関係を見落とすことがあります
全軌跡の受け渡し	コストがワーカー呼び出しのたびに増加し、無関係なコンテキストによってワーカーの品質が低下することがあります

ボトルネックが文書検索そのものではなく、オーケストレーターの状態をワーカーに効率的かつ正確に渡す方法にある場合、Latent Briefing が役立ちます。

再帰的なオーケストレーターとワーカーの構成

Recursive Language Models などのフレームワークは、長いコンテキストを環境として扱い、その上で再帰的に処理します。オーケストレーターが作業を分解し、ワーカーに委任します。オーケストレーターがすでにタスク固有の状態を構築しており、それをワーカーに反映させたい一方、その状態をテキストとして再シリアライズするとコストが高すぎる、またはノイズが多くなりすぎる場合に、Latent Briefing がこのギャップを埋めます。

理想的な構成では、ワーカーはオーケストレーターの軌跡に対応する永続的な KV 状態を保持します。新しい軌跡トークンによってその状態を拡張し、現在のサブタスクの生成直前に圧縮を実行します。

推論時の 3 つの変更点

1. タスク誘導型クエリベクトル。 コンテキストから汎用的なサンプルを使うのではなく、現在のワーカータスクのプロンプトからクエリを使用します。軌跡と現在のタスクをワーカーモデルに順伝播させ、タスクが各位置にどれだけ強く注意を向けているかに基づいて、軌跡の位置をスコアリングします。

2. トークン選択の共有。 レイヤーとヘッド全体のスコアを集約し、位置ごとのスコアを 1 つ作成します。共有マスクを 1 つ使うことでバッチ処理が可能になり、互換性のない数百通りのヘッドごとの最適化を避けられます。

3. MAD によるしきい値設定。 median + tau * MAD などのロバストな外れ値しきい値を超える位置を保持します。tau が高いほど、より積極的に圧縮します。最適な設定は、タスクの種類、軌跡の品質、文書の長さによって異なります。

インフラストラクチャの前提条件

Latent Briefing が実用的なのは、KV 状態を確認または変換できる程度に、システムがワーカーの推論ランタイムを厳密に制御できる場合に限られます。内部の KV テンソルにアクセスできない API のみのスタックでは、デフォルトの選択肢として適していません。また、オーケストレーターの軌跡をワーカーのモデル空間で表現できることも前提とします。オーケストレーターとワーカーでトークナイザー、アーキテクチャ、アテンションのレイアウトが大きく異なる場合、表現を直接共有できない可能性があります。

判断の枠組み

ボトルネックに合った仕組みを選びます。

ニーズ	推奨	理由
ロジックの変更を最小限に抑えた安定した繰り返しプレフィックス	プレフィックスキャッシュ	最も低コストな最適化で、情報損失がありません
ステップ間の状態を人が読める形で監査可能にする	構造化メモまたは要約	確認と保存が容易です
大規模な外部コーパスを対象とした疎な検索	検索／RAG	文書を効率的に見つけられます
ワーカーがオーケストレーターの状態のうちタスク固有の部分を必要とし、ランタイムへのアクセスも可能	Latent Briefing	すべてのテキストを再処理せず、関連する潜在状態を転送できます

Latent Briefing は、要約や検索に取って代わる汎用的な手法ではありません。制御可能なオーケストレーターとワーカーのスタックをすでに実行しているシステム向けの、専門的な最適化です。

しきい値の設定

長文書の QA に関する報告済みの結果から、次のことが示唆されています。

• 文書が長い場合： より軽い圧縮により、トークンを節約しながら、より広範なエビデンスを保持できます。
• 質問が難しい場合： オーケストレーターの軌跡に推測的な分岐や価値の低い分岐が含まれる場合、より積極的な圧縮が役立つことがあります。
• コンテキストが短く、簡単な場合： 適度な圧縮で、必要なエビデンスを落とさずに冗長性を除去できることがあります。

これらは調整のための仮説であり、どこでも通用する法則ではありません。対象のワークロードで再測定してください。

実践的なガイダンス

• まず共有メモリの境界を定義します。 何を軌跡キャッシュに含めるかを正確に決めます。以前のワーカーの応答、ツールの出力、思考の連鎖、または選択した成果物のみを対象にするかを決めてください。圧縮の品質は、そもそもキャッシュに何を含めるかによって左右されます。
• 逸話ではなく、検証データで調整します。 タスクの精度、ワーカーのトークン数、合計トークン数、保持率、圧縮のオーバーヘッドをまとめて追跡します。
• エンドツーエンドのレイテンシを測定します。 同じ品質目標において、圧縮と生成を合わせた処理時間が最適なテキスト層の代替手段を上回る場合にのみ、圧縮の効果があります。
• 強力なベースラインを使います。 「すべて送信」と比較するだけでなく、プレフィックスキャッシュ、構造化メモ、検索、選択的なテキスト引き継ぎとも比較します。
• オーケストレーターのばらつきを考慮します。 分解戦略が実行ごとに変わる場合は、圧縮の影響とオーケストレーターのノイズを区別できるよう、十分な回数の試行で平均を取ります。

例

シナリオ：オーケストレーターの軌跡がワーカー呼び出しのたびに増加する

Call 1: trajectory T1 -> worker answers subquestion A
Call 2: trajectory T2 = T1 + new reasoning + reply A
        compact KV(T2) using the task prompt for B
        worker answers subquestion B

B のタスクプロンプトによって、圧縮されたワーカーの状態に T2 のどの部分が残るかが決まります。

悪い例：API のみを使うワーカー

ワーカーが KV テンソルを公開しないホスト型テキスト生成 API の背後で動作する場合、Latent Briefing を直接実装することはできません。代わりに context-compression による構造化テキストの引き継ぎを使うか、memory-systems から状態を取得してください。

ガイドライン

1. 主な無駄がソース文書の取得ではなく、ワーカーへのオーケストレーター状態の再送にある場合は、Latent Briefing を優先します。
2. トークン効率よりも監査可能性、移植性、クローズドモデルの API を重視する場合は、プレーンテキストでの引き継ぎを優先します。
3. 圧縮を評価と共同で設計します。品質のわずかな低下でも、大幅なトークン削減の効果が失われる場合があります。
4. 圧縮の強さは、隠れた定数ではなく、制御可能なパラメーターとして公開します。

注意点

1. 最初の関門はインフラへのアクセスです。 ランタイムからワーカーの KV 状態を検査して書き換えられない場合、Latent Briefing は研究上のアイデアにとどまり、デプロイ可能な手法ではありません。
2. モデル空間の共有が重要です。 KV 圧縮は特定のモデルのアテンション空間で定義されます。関連性のないモデルファミリー間でも潜在状態の引き継ぎが問題なく機能すると想定しないでください。
3. 閾値はワークロードに依存します。 長いコンテキストと短いコンテキスト、簡単なタスクと難しいタスクのすべてで機能する単一のグローバルな tau は、ほとんどありません。圧縮を強くしすぎると、精度が急激に低下することがあります。
4. ベンチマークの対象範囲は狭いものです。 公開されている結果は、長文書の QA が中心です。コード生成、数学、複数文書の統合では、挙動が異なる可能性があります。
5. オーケストレーターのばらつきによって、シグナルが見えにくくなることがあります。 確率的なオーケストレーターは軌跡を大きく変化させるため、わずかな圧縮の利得や損失が埋もれる可能性があります。
6. 弱いベースラインは、見かけ上の効果を大きくします。 システム全体で優位だと主張する前に、強力なテキストレベルの代替手段と比較してください。

統合

• context-optimization - プレフィックスキャッシュと観測のマスキングを、引き続き最初に検討する標準的な手法とします。Latent Briefing は、互換性のあるオーケストレーターとワーカーの構成に特化した最適化です。
• multi-agent-patterns - マルチエージェントのトークンコストが、調整のオーバーヘッドだけでなく、スーパーバイザーの軌跡の再送によって生じている場合に適用します。
• context-compression - 人が読める状態、移植性、監査ログが重要な場合は、テキスト層での要約を引き続き優先します。
• memory-systems - 複数ステップにまたがる状態を外部メモリに保持するか、ワーカーの潜在状態に保持するかの判断に役立ちます。
• tool-design - ワーカーの呼び出し形式とタスクプロンプトによって、圧縮時にどのトークンが高く評価されるかが決まります。

参考資料

内部資料：

• Attention Matching の定式化とタスク誘導型スコアリング - 以下の場合にお読みください：AM の目的、タスク誘導型スコアリングによってクエリの参照元がどのように変わるか、またはバッチ処理で共有グローバルマスクが重要な理由を確認したい場合

このコレクション内の関連スキル：

• context-optimization - 以下の場合にお読みください：ワーカーの KV 操作ではなく、プレフィックスキャッシュ、観測のマスキング、またはテキストレイヤーの圧縮が主な目的である場合
• multi-agent-patterns - 以下の場合にお読みください：そもそもアーキテクチャをオーケストレーターとワーカーの構成にすべきか判断する場合
• context-compression - 以下の場合にお読みください：潜在表現の転送よりも、人が読める要約のほうが適している可能性がある場合
• memory-systems - 以下の場合にお読みください：モデル内の潜在状態と外部の永続メモリを比較する場合

外部リソース：

• Ramp Labs の発表：Latent Briefing：KV キャッシュの圧縮によるマルチエージェントシステムの効率的なメモリー共有
• Attention Matching（AM）：Attention Matching による高速 KV 圧縮
• Recursive Language Models：Recursive Language Models

---

スキルのメタデータ

作成日：2026-04-14 最終更新日：2026-05-15 作成者：Agent Skills for Context Engineering のコントリビューター。主な技術資料は Ramp Labs（公開投稿） バージョン：1.2.0