TrueForgeにおけるコンテキスト圧縮の解説:エージェントが忘れるものとセッションが保持するもの

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
圧縮(Compaction)を使用すると、古い作業履歴を構造化されたサマリーに置き換えることで、長期間実行されるエージェントの処理を継続できます。これは情報損失を伴うからこそ有用である反面、アーカイブされた事実として扱うと危険です。
圧縮はセッションの履歴記録ではなく、エージェントの作業メモリを変更する
長い会話では、ユーザーメッセージ、アシスタントメッセージ、ツール呼び出し、ツールの結果、サブエージェントの出力が蓄積されます。最終的に、すべての項目を保持し続けることはコストがかかるか、不可能になります。TrueForgeのコンテキスト圧縮は、古い履歴を要約し、その後のモデルステップで元のメッセージの代わりにサマリーを使用することで、このランタイムの問題に対処します。
極めて重要な違いは、2つのビューの間にあります。永続化されたセッションはイベント履歴を保持します。圧縮後のモデルの有効なコンテキストには、それまでの作業の構造化された、情報損失を伴う表現が含まれます。これらのビューは異なる問題に対応します。イベントログは記録された内容の復元をサポートし、圧縮されたコンテキストは有限のトークンバジェット内での推論の継続をサポートします。
したがって、圧縮は削除、アーカイブ、または証明ではありません。これは、エージェントの作業表現における状態遷移です。詳細は永続化されたイベントに残っている可能性がありますが、モデルが使用するサマリーにおいては、もはや顕著ではないか、存在しないことさえあります。

この図は、耐久性のあるセッション記録と、その後の推論に使用される表現を分離して示しています。イベントログに存在するからといって、圧縮された作業コンテキストにおいて顕著であるとは限らないため、デバッグには両方が必要です。
ドキュメント化されているトリガーモデル
TrueForgeのドキュメントでは、圧縮はデフォルトで有効になっていると記載されています。入力コンテキストがモデルのコンテキスト長の80%に達したときに実行されます。その長さが利用できない場合、ハーネスは50,000入力トークンのフォールバックを使用します。エージェントは明示的な入力トークン閾値を設定することもできます。
これらはトリガーのセマンティクスであり、品質を保証するものではありません。閾値は要約がいつ実行されるかを決定するものであり、生成されたサマリーが後で必要なすべての事実を保持していることを証明するものではありません。モデルのメタデータが不確実な場合、タスクに通常よりも大きな予約出力ニーズがある場合、またはツールスキーマや添付ファイルによって実効バジェットが公称モデルウィンドウよりも小さくなる場合は、チームは明示的な閾値を選択する必要があります。
次のモデルの応答、ツールの引数、承認ペイロード、およびハーネスによって挿入されるシステムマテリアルのために余白を残してください。圧縮リクエスト自体と次の推論ステップもコンテキストを消費するため、最後の1トークンでトリガーすることは運用上リスクが高くなります。

トリガーは、予約された余白を伴うリソース管理上の決定として示されています。ドキュメント化されたデフォルトがタイミングを決定しますが、ワークロード固有の閾値と品質検証の管理責任は引き続きチームにあります。
サマリーに保持されることが期待される内容
TrueForgeでは、本来の目的、主な決定事項、ファイルとアーティファクト、エラーと修正、および次のステップをカバーする構造化サマリーについて説明しています。その構造が価値を持つのは、会話の一般的な概要を作成するのではなく、タスクの状態を保存するようコンパクターに求めるためです。
本番用のエージェントは、クリティカルな状態を要約しやすくする必要があります。安定した識別子、型付けされたステータスフィールド、明示的な決定記録、およびアーティファクトダイジェストは、会話形式の文章に埋もれた事実よりも圧縮を生き残りやすくなります。不可逆的なアクションが値に依存している場合は、生成されたサマリー内でその値が逐語的に維持されることを信頼するのではなく、その値を信頼できるシステムまたは型付けされたチェックポイントに保存してください。
情報損失はエラーバジェットを伴う機能である
有用なサマリーは、意図的に詳細を削除します。すべての情報を保持した場合、コンテキストの問題を解決できません。エンジニアリング上の課題は、どの不利益が許容可能かを決定することです。繰り返される言い回し、生のツールペイロード、放棄された検討過程は、通常破棄しても影響はありません。承認スコープ、数値閾値、セキュリティ制約、未解決の不確実性は破棄できません。
圧縮により、省略、短縮、または再解釈が発生する可能性があります。数値の単位が失われることや、仮の観察が決定事項に変わる可能性、似た名前の2つのファイルが統合される可能性、未解決のエラーが最終的な回避策の背後に消える可能性があります。これらはTrueForgeの特定の欠陥についての主張ではありません。これらは情報損失を伴うモデル生成サマリーの障害モードであり、テストの設計に反映されるべきものです。
すべての圧縮境界を評価可能なチェックポイントとして扱います。アプリケーションは、生成されたサマリーを、有効な目的、必要な承認、未完了の操作、アーティファクトダイジェスト、セキュリティ制約、次回許可される遷移などの型付けされた不変条件と比較できます。不変条件が欠落しているか、矛盾している場合は、そのまま実行を継続しないでください。

クリティカルな状態が不変条件として表現されている場合、圧縮境界はテスト可能になります。不変条件が不完全な場合、情報損失を伴うサマリーが安全でないアクションにつながる前に、処理の継続を停止できます。
圧縮と検索は異なるツールである
圧縮は、コンパクトな作業ナラティブを作成します。検索(Retrieval)は、必要な時に関連するソース素材を選択します。長期間実行されるシステムには、多くの場合両方が必要です。サマリーによってマイグレーションプランが存在することを示し、そのダイジェスト名を特定できます。検索では、実行前に正確なプランを読み込むことができます。エージェントはターンごとに20ページのアーティファクトを保持すべきではありませんが、正確な内容が重要な場合に、言い換えに基づいて実行すべきでもありません。
このパターンにより、サマリーが完璧なアーカイブでなければならないという負荷が軽減されます。サマリーはポインター、状態、および決定境界を保持する必要があります。正確な根拠はファイル、データベース、またはセッションイベントに残り、リスクの高いステップのために再ロードされます。
圧縮と永続化されたイベントは異なるデバッグの問いをサポートする
圧縮後の回答が誤っている場合、調査担当者は圧縮前の記録と圧縮された表現の両方を必要とします。イベント履歴はどのような情報が存在したかを示すことができます。サマリーは、モデルが実際に引き継いだ情報を示すことができます。これらを比較することで、障害が圧縮前に発生したのか、要約中に発生したのか、あるいはサマリーが消費された後に発生したのかを特定できます。
圧縮トリガー、使用されたモデルと構成、入力イベント範囲、サマリーイベント、前後でのトークン数、検証結果を記録します。アプリケーションレベルの圧縮プロンプトや不変条件チェッカーはバージョン管理してください。これらのプロベナンスがないと、サマリーの再現が困難になり、回帰の原因特定が困難になります。
繰り返される圧縮は損失を増大させる可能性がある
長いセッションでは、複数回圧縮が行われる場合があります。以降のサマリーが、関連する完全な記録からではなく、以前のサマリーから生成される場合、作業コンテキスト内で省略が恒久的なものになる可能性があります。些細な曖昧さが確実な記述に変換され、あたかも元の根拠であるかのように引き継がれる可能性があります。
圧縮の世代と、各サマリーが表すイベント範囲を追跡します。重要な節目では、前回のサマリーのみを要約するのではなく、耐久性のある型付けされたチェックポイントと選択されたソースイベントから次の作業状態を構築します。これは、承認、外部での変更、インシデントの引き継ぎ、またはユーザーの目的の重要な変更の後に特に役立ちます。
蓄積された解釈リスクが重要となるワークフローに対して、最大セッション期間または最大圧縮回数を設定します。新しいセッションを開始することは失敗ではなく、検証済みの状態のみをインポートする計画的なリセットになります。引き継ぎでは、前のセッション、承認されたアーティファクト、未解決の操作、リセットの理由を指定する必要があります。
圧縮は保持制御やプライバシー制御ではない
モデルの作業コンテキストから詳細を削除しても、基礎となるイベント履歴が削除されたことを意味するわけではありません。TrueForgeは、圧縮されたコンテキストと永続化されたセッションイベントを明確に区別します。したがって、データ保持、削除、リーガルホールド、アクセス、およびエクスポートポリシーは、モデルが現在コンテンツを認識しているかどうかではなく、永続化されたストアおよびアタッチされたアーティファクトに対して適用する必要があります。
その逆も重要です。圧縮されたサマリーは、元の詳細がタスクに不要になった後でも、機密情報を保持できます。サマリー自体にデータの最小化を適用し、セッション状態を読み取ることができるユーザーを制御し、シークレットや生の個人データを耐久性のあるナラティブフィールドにコピーしないようにします。削除と保持は、モデルの入力、サマリー、イベント記録、ファイル、トレース、ダウンストリームシステムなど、あらゆるコピーで設計する必要があります。
人間の修正は境界を越えて維持されなければならない
ユーザーが以前の事実を修正した場合、圧縮された状態は修正を保持し、破棄された値を廃棄する必要があります。「後のテキストが優先される」ことに依存するのではなく、修正を明示的な状態遷移として表現します。サマリーが現在の値を保持し、必要に応じて重要なプロベナンスを記録し、別の圧縮後に古い値を復活させないことをテストします。
係争中または規制対象の決定については、元の発言、修正、決定所有者、および発効日時を信頼できる記録に保持します。作業サマリーは現在の指示を保持できますが、耐久性のある記録は監査と不服申し立てに必要な履歴を保存します。
Exactly-onceまたは決定論的な継続を推定しない
永続化された状態と圧縮されたサマリーは、エージェントが処理を継続するのに役立ちます。これらは外部の副作用を決定論的にするものではありません。データベース変更の処理中にツール呼び出しがタイムアウトした場合、サマリーには「ステータス不明」と正確に記載される可能性がありますが、アプリケーションは再試行する前に信頼できるシステムに問い合わせる必要があります。圧縮では操作識別子と曖昧さを保持する必要があります。調整によってそれを解決します。
同様に、サマリーは新状態に対して古い承認決定を通知なく引き継ぐべきではありません。承認およびビジネス権限付与は、リソースが変更された後に期限切れになるか、古いものになる可能性があります。実行時に再評価します。
圧縮のテスト方法
- 重要な事実を長いセッションの初期に配置し、圧縮後も明示されたままであることを確認します。
- 類似したファイル名、単位、識別子を含め、意図しない統合が発生しないかテストします。
- 承認、外部操作、またはエラーが未解決のまま圧縮を実行します。
- 破棄された仮説が決定に昇格しないことを確認します。
- 圧縮後のアクションを、履歴全体を保持するコントロール実行と比較します。
- モデルまたは圧縮構成の変更後に、代表的なセッションを再実行します。
- 作業コンテキストが短くなった場合でも、永続化されたイベント履歴が利用可能なままであることを確認します。
長いセッションの運用モデル
現在の目的、決定事項、ポインター、次のステップには作業コンテキストを使用します。順序付けられたランタイム記録にはセッションイベントを使用します。バージョン管理されたアーティファクトにはファイルとレジストリを使用します。コミットされたビジネス状態にはSoR(System of Record)を使用します。これにより、アプリケーションが重要な事実を記憶する唯一の場所になることなく、圧縮によって会話の増大を軽減できます。
圧縮の頻度、圧縮率、圧縮後のエラー率、不変条件の違反、再開された質問、繰り返されるツール呼び出しを監視します。繰り返し圧縮を行うセッションでは、より適切なツール結果のオフロード、タスクスコープの縮小、またはより過密なサマリーを作成するのではなく、意図的に新しいセッションを作成することが必要な場合があります。
運用ルール
TrueForgeコンテキスト圧縮は、歴史的な詳細を構造化された作業サマリーと交換することにより、エージェントセッションの有効期間を延長します。安全なメンタルモデルは「完璧な記憶」ではなく、「耐久性のある記録に対する情報損失を伴う継続」です。
安定したポインターと型付けされた不変条件を保持し、重要な場合は正確な根拠を再ロードし、信頼できるシステムに対して外部影響を調整し、境界を明示的にテストします。サマリーがどの事実を圧縮してよいか、そしてどの事実を作り出したり忘れたりしてはならないかをシステムが認識している場合、圧縮は信頼性の高いものになります。
参考文献
編集情報の開示。 この記事は、2026年9月19日時点で引用された公開資料に対するTrueFoundryのエンジニアリング上の解釈を反映しています。製品機能はリンクされたドキュメントの範囲に限定されます。例および運用のデフォルトは例示目的であり、法的アドバイス、監査意見、独立したベンチマーク、またはセキュリティ、安全性、コンプライアンスを保証するものではありません。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.













.webp)

.webp)
.webp)
.webp)
.png)

.png)
.png)
.png)
.png)
.png)
.webp)
.webp)

.png)
.png)





