Anthropic は、オンデマンドの会話圧縮とコンテキスト編集という 2 つの密接に関連したベータ機能を Claude Messages API に追加しました。どちらも、アシスタントやエージェントを構築する開発者にとってよくある問題を対象としています。つまり、有用な会話は、特にツール呼び出し、取得されたドキュメント、および複数ターンの命令が蓄積する場合に、モデルの実際的なコンテキスト予算よりも長く実行されることがよくあります。
重要な変更点は、Anthropic が開発者に古いメッセージを自分で要約するように指示するだけではないことです。 9 月 14 日のプラットフォーム リリース ノートでは、compact-2026-09-04 ベータ ヘッダーによって有効になり、署名付き圧縮ブロックを返す API レベルの圧縮パスについて説明しています。このブロックは、最近のターンをそのまま残したまま、後のリクエストで以前の会話履歴を置き換えることができます。 Anthropic はベータ版でコンテキスト編集も導入しました。当初は、会話がトークンの制限に近づくと、古いツールの結果とツール呼び出しを自動的にクリアすることに重点が置かれていました。
アプリケーション チームにとって、これはユーザビリティ機能です。ゲートウェイ オペレーター、可観測性ベンダー、プロバイダー間のトラフィックを正規化する企業にとって、これはプロトコルの変更です。圧縮されたクロードの会話は、単なる短いプロンプトではなくなりました。これには、プロバイダーが作成した、以前のコンテキストの署名付き表現が含まれており、そのまま保持する必要があります。
Claude Messages API の変更点
従来の長時間実行されるチャット統合では、コンテキスト ウィンドウがいっぱいになったときに、開発者には通常 3 つの不完全なオプションがあります。古いターンを削除したり、独自の概要を生成したり、ユーザーに再起動を要求したりできます。それぞれの選択により、連続性が損なわれたり、重要な命令が隠されたり、デバッグが困難になったりする可能性があります。
Anthropic の新しい圧縮ベータ版では、その作業の一部が API に移動されます。 API は、以前の会話コンテンツに対して署名付き圧縮ブロックを生成できます。その後のリクエストでは、古いメッセージの代わりにそのブロックを送信することができ、新しい会話はそのまま維持されます。デザインが重要なのは、圧縮された歴史と通常のアシスタントが作成した要約テキストを区別するためです。ブロックを文字列に平坦化したり、未知のフィールドを削除したり、通常のユーザー メッセージとして扱ったりするゲートウェイは、意図したセマンティクスを壊す可能性があります。
コンテキスト編集は、関連するトークン増大のソースであるツール トラフィックを攻撃します。エージェント アプリケーションは、大規模なツール出力、中間呼び出し、古い観測結果を蓄積する可能性があります。 Anthropic 氏によると、ベータ版では当初、会話がトークンの制限に近づくと、古いツールの結果と呼び出しの自動クリアがサポートされます。これは多くのワークフローにとって理にかなっていますが、後のモデルの応答が、プロバイダー側のルールによって意図的に取り除かれた会話状態に依存する可能性があることも意味します。
これは、複数のモデル プロバイダーの上に AI ガバナンス レイヤーを構築しているチームに特に関係します。ガバナンス システムは、どのプロンプトが送信されたかだけでなく、以前のコンテキストのどの部分が保持、圧縮、または削除されたかを知る必要があります。
ゲートウェイがこれを一般的な要約として扱えない理由
当面の実装リスクは互換性です。多くの API ゲートウェイと SDK ラッパーは、既知のスキーマに対してリクエスト ペイロードを検証します。不明なトップレベルパラメータが削除される可能性があります。不明なコンテンツ ブロックが強制的にテキストに変換される可能性があります。ロギング パイプラインは、認識できないフィールドを編集または変換する場合があります。これらは通常のメタデータの妥当なデフォルトですが、不明なオブジェクトがモデル プロバイダーのコンテキスト管理コントラクトの一部である場合は危険です。
クロード対応ゲートウェイは、新しい圧縮パラメータと署名付きブロックを書き換えずに保存する必要があります。また、元のメッセージ、圧縮されたコンテキスト、および最近の未変更のターンの間のトレースを明確に区別する必要があります。その区別は学術的なものではありません。顧客がエージェントが決定を下した理由を尋ねた場合、監査証跡は、モデルが元のツールの結果、圧縮された表現、またはどちらにもアクセスできなかったのかを示す必要があります。
OpenAI 互換のゲートウェイ製品は、さらなる設計上の問題に直面しています。 OpenAI スタイルのチャットと応答のエコシステムには、ホストされたエージェントの状態やプロバイダー固有のセッション処理など、独自のコンテキスト管理パターンがあります。 Anthropic の署名付き圧縮ブロックは、別のセマンティック オブジェクトです。システムがプロバイダーの保証と動作の再生を保持する必要がある場合、「summary」または「memory」と呼ばれる単一の汎用フィールドでは十分ではありません。
したがって、OpenAI 互換のルーティングと Anthropic スタイルの API の両方をサポートする Model Gate スタイルのプラットフォームには、プロバイダー固有のコンテキスト アダプターが必要になる場合があります。だからといって、すべての顧客がその複雑さを認識しているわけではありません。これは、ゲートウェイが Anthropic のコンパクション セマンティクスを内部的にはそのままに保ちながら、安定した外部エクスペリエンスを公開する必要があることを意味します。
分析、請求、監査証跡がより複雑になる
リリース ノートには、署名付きコンパクション ブロックが通常のメッセージ テキストと異なる請求をされるかどうかについては記載されていません。その未解決の点が重要です。圧縮されたブロックが他の入力と同様にカウントされる場合、課金システムはそれを別のトークンを含むリクエスト コンポーネントとして扱うことができます。 Anthropic が異なる会計を適用する場合、ゲートウェイは顧客の請求書と使用状況のエクスポートでその違いを明確に表現する必要があります。
特別な価格設定がなくても、コンパクションによって分析の説明方法が変わります。会話はメッセージ レベルでは短く見えても、以前のはるかに長いやり取りの影響が残っていることがあります。基本的なトークン グラフでは、元のコンテキストがどの程度圧縮されたか、最新のコンテキストがそのまま残されているかどうか、圧縮が呼び出された頻度、失敗が自動的にクリアされたツールの出力と相関関係があるかどうかなどの質問には答えられません。
これらの質問は、生のログに埋もれるのではなく、AI API 使用状況分析ダッシュボードに含まれます。企業顧客は、コスト、モデルの動作、ツールの使用状況を同じ運用ビューで確認することをますます期待しています。会話の圧縮により、そのビューに別の状態遷移が追加されます。
コンプライアンス アングルもあります。規制対象の顧客が、特定の時点でアシスタントにどのような情報が利用可能だったかを尋ねた場合、オペレーターは圧縮チェーンを理解していない限り、最終リクエスト本体からのみに答えることはできません。署名付きブロックは整合性を維持するのに役立ちますが、注意深い保持ルール、顧客に表示されるトレース、および内部デバッグ ツールの必要性がなくなるわけではありません。
今すぐ行動すべき人
Claude を直接使用している開発者は、SDK、プロキシ、またはロギング ミドルウェアがベータ ヘッダー、トップレベルの圧縮パラメータ、および返された圧縮ブロックを変更せずに渡しているかどうかを確認する必要があります。また、デプロイメント、リージョン間、またはリクエスト変換間で圧縮ブロックが再実行されるときの障害動作もテストする必要があります。
ゲートウェイ チームは、顧客がサイレント機能低下に遭遇する前に、スキーマ カバレッジを追加する必要があります。最低限の実際的な作業は、新しいフィールドの削除や書き換えをやめる事です。より良いバージョンは、ログ、トレース、および使用記録で圧縮されたコンテキストに個別にラベルを付けることです。すでに 統合 AI API 請求を提供しているチームの場合、サポート チームがトークンの使用状況を調整し、長時間セッションの動作を説明できるように、コンパクション イベントが十分に可視化されている必要があります。
サポート エージェント、コーディング アシスタント、リサーチ ツール、またはセールス コパイロットを運用している企業は、これをガバナンスに影響を与える信頼性機能として扱う必要があります。圧縮により、長い会話の耐久性が向上しますが、表示されるチャットのトランスクリプトとモデルの実際の入力状態の間に別の隠れ層も導入されます。
未解決の質問は依然として重要です。 Anthropic は、コンパクション ブロックによって請求されるトークンの会計が変更されるかどうかについては言及していません。ベータヘッダーの長期安定性も保証されていません。また、コンテキスト編集は最初は古いツールの呼び出しと結果に焦点を当てているため、開発者は、古いツールの証拠が法的または運用上重要なままであるワークフローにデフォルトがどの程度適合しているかを検証する必要があります。
ただし、より大きな方向性は明らかです。ロングコンテキストの管理は、アプリケーションのグルー コードからプロバイダー API に移行しています。顧客とモデル プロバイダーの間に確実に存在したいゲートウェイは、短いプロンプトを転送するだけでなく、プロトコル レベルでその動きをサポートする必要があります。