大規模なツールレスポンスの解説:コンテキストを溢れさせずにペイロードにアクセスし続ける方法

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
ツールが返すデータが、モデルの推論に適した形式ではない場合があります。大規模レスポンスの処理では、ペイロードの保持と、その全データへの即時的な処理を分離します。
1. 正しいデータでも運用上の障害になる可能性がある
MCPツールは正常に回答しても、実行プロセスに悪影響を及ぼすことがあります。リポジトリAPIが長い説明文を含む数百件のプルリクエストを返す場合や、メトリクスツールがすべての時系列データを出力する場合、あるいはCRM検索が各アカウントにネストされた履歴を付与する場合などが該当します。ペイロード自体は原則として重要ですが、モデルが必要とするのはそのうちの3つのフィールドだけかもしれません。
全結果がコンテキストに入ると、入力サイズの増大、後続の推論への負荷、重要な事実と無関係なフィールドの混在といった問題が同時に発生し、後続の呼び出しによってモデルの制限に達する可能性があります。APIがプロジェクション、ページネーション、フィルタリングをサポートしている場合は、ツールから取得する量を減らすのが望ましいですが、多くのツールには適切な制御機能がないため、ランタイム側でのフォールバックが必要です。
TrueForgeのレスポンス処理では、サイズが大きすぎる結果をサンドボックスファイルに書き込み、コンテキストには短いプレビューとファイルパスのみを配置します。これにより、エージェントはペイロード全体を処理することなく、必要に応じてデータにアクセスできます。

2. 単一レスポンスのしきい値
最初のルールは、1つのツール結果に適用されます。推定レスポンスが設定された呼び出しごとのしきい値を超えると、TrueForgeは結果全体をサンドボックスに書き込みます。コンテキストには通知、ファイルパス、および制限付きのプレビューが送信されます。現在のデフォルトしきい値は6,000トークンで、デフォルトのプレビューには先頭と末尾の100文字が含まれます。
プレビューは要約ではなく、ナビゲーションのためのものです。境界部分の文字からオブジェクト型、トップレベルのキー、合計数、最終的なメタデータなどが判明することもありますが、タスクに必要な正確なレコードが省略される可能性もあります。適切な次のステップは、構造の調査、ターゲットの検索、または小規模なパーサーの実行であり、プレビューから全内容を推測することではありません。
3. 並列呼び出しによる集約的な障害モード
エージェントがツールを同時に実行する場合、呼び出しごとの制限だけでは不十分です。4,000トークンの結果が4つある場合、それぞれは6,000トークンのチェックを通過しますが、合計すると1回のモデルステップに16,000トークンが注入されることになります。
そのため、TrueForgeでは同時に返されるツール呼び出しコンテンツの合計に対して、2つ目のしきい値を設定しています。現在のデフォルトは10,000トークンです。合計がこの制限を超えると、ハーネスは残りのインラインコンテンツがしきい値を下回るまで、最も大きいレスポンスから順にオフロードします。
この「最大のものから順に」というポリシーは、小さな結果をインラインに残しつつ、大きな負荷要因を迅速に排除します。これは関連性の判断ではなく、コンテキストを最適化するためのヒューリスティックです。最大のレスポンスに最も重要な証拠が含まれている可能性もありますが、ファイルパスによっていつでも取得可能です。

4. なぜオフロードにサンドボックスが必要なのか
完全なペイロードには、エージェントが調査可能な永続的な実行環境が必要です。TrueForgeのこの機能はデフォルトで有効になっていますが、オフロードされた結果はサンドボックスファイルとして保存されるため、エージェントのサンドボックス機能が有効である必要があります。
サンドボックスは、エージェントのループ全体が実行される場所ではありません。TrueForgeのドキュメントでは、サンドボックスはコード、ファイル、シェル作業のために必要に応じてプロビジョニングされる隔離環境であると定義されています。モデルはパスを受け取り、サンドボックスの操作を通じてファイルの調査や変換を行うことができます。
この設計には、ハーネスが実行と認証情報を制御し、サンドボックスがペイロード処理を担うという有用な分離があります。同時に、これはライフサイクルに関する課題も生じさせます。タスク、ユーザー、または保持ポリシーが機密性の高いものである場合、チームはファイルの保持期間、ダウンロード権限、参照するテレメトリ、および削除がどのように伝播されるかを把握しておく必要があります。
5. 適切なリカバリー動作は段階的な調査である
レスポンスをオフロードした後は、エージェントは意図的に範囲を絞り込むべきです。
- 先頭の小さな部分を調査するか、スキーマを推論する。
- 期待されるトップレベルの形状とレコード数を確認する。
- リクエストに関連する特定のエンティティやフィールドを検索する。
- フィルタリング、グループ化、結合には決定論的なコードを使用する。
- 次の推論ステップに必要な証拠や要約のみを出力する。
- ポリシーで許可されている場合は、デバッグ用にソースファイルへの参照を保持する。
TrueForgeのドキュメントでは、このパターンが「コードモード」に直接関連付けられています。スクリプトはオフロードされたファイルを読み取り、結果を計算し、出力された行のみをモデルのコンテキストに返すことができます。

6. オフロード、切り捨て、要約、検索はそれぞれ異なる
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)


.png)
.png)
.png)
.png)
.png)
.png)
.png)

.png)
.png)
.png)
.png)







