Claude API（Anthropic が提供する大規模言語モデルの呼び出しインターフェース）を使ったテスト自動化基盤やエージェント型のQA支援ツールを運用している方に向けて、2026年9月に追加された会話圧縮機能を整理します。長時間実行のエージェントジョブをCI上で回している場合、コンテキスト管理の方式変更はテストの再現性やコスト計測に直結するため、確認しておいて損はありません。
2026年9月14日付の更新で、Messages API（Claude とのやり取りの本体となるAPIエンドポイント）に会話をオンデマンドで圧縮する機能がベータ提供されました。compact-2026-09-04 というベータヘッダーを付けてリクエストすると、トップレベルの compaction パラメータを送信できます。APIはそれまでのメッセージ履歴を要約した「署名付き圧縮ブロック」を返し、以降のリクエストではそのブロックを送信済みメッセージの代わりに先頭に置く仕組みです。
何が変わったのか、なぜ注目すべきか
LLM（大規模言語モデル）を使ったエージェントは、会話を続けるほどコンテキストウィンドウ（モデルが一度に読めるトークンの上限）を消費します。長時間のコーディングエージェントや、複数ステップのテストシナリオを自動実行するツールでは、この消費が無視できない問題になります。
これまでは開発者側で会話履歴を手動で要約したり、古いメッセージを切り捨てたりする自前の工夫が必要でした。今回のcompaction機能は、この要約処理をAPI側に委譲できる点が特徴です。圧縮のタイミングを開発者が選べること、処理をバックグラウンドで走らせられること、要約後も直近のやり取りは一字一句保持できることがポイントです。
思考過程を保持するモデル（extended thinkingやadaptive thinkingと呼ばれる機能を持つモデル）の場合、保持された直近ターンの思考ブロックも有効なまま維持されるとされています。これはエージェントが「なぜその判断をしたか」を追跡する必要があるテストシナリオで意味を持ちます。
段階的に見る技術的な仕組み
仕組みを分解すると、次の3ステップで動きます。
- リクエスト時に
compactionパラメータとベータヘッダーを付与する - APIがそれまでの会話を要約し「署名付き圧縮ブロック」として返す
- 次回以降のリクエストでは、元のメッセージ群の代わりにこのブロックを先頭に送る
この「署名付き」という点が地味に重要です。ブロックには改ざん検知の仕組みが含まれていると考えられ、途中でシステムプロンプトやツール定義が変わった場合に不整合を検出できる設計思想と整合します。実際、同じ更新群の中でClaude Fable 5.1向けに「システムプロンプトやツールが変更された後に古いthinkingブロックを再生すると400エラーを返す」という挙動が明記されており、圧縮ブロックについても同様に「何が変わったら無効になるか」を運用前に把握しておく価値があります。
既存のコンテキスト管理手法との比較
これまでコンテキスト長対策として使われてきた手法には、大きく3つの系統があります。
| 手法 | 仕組み | CI/CDでの弱点 |
|---|---|---|
| 手動要約 | 開発者が独自ロジックで古い履歴を要約 | 要約品質がテストごとにばらつく |
| スライディングウィンドウ | 直近N件のみ保持し古いものを破棄 | 初期の指示や制約条件を失いやすい |
| API側compaction | APIが要約し署名付きブロックを返す | ベータ機能のため仕様変更リスクがある |
プロンプトキャッシュ（同一プレフィックスの再計算を省略しコストを下げる仕組み）とは別軸の機能である点も整理しておく必要があります。プロンプトキャッシュは「同じ入力を繰り返す場合の高速化・低コスト化」、compactionは「入力そのものを短くする」ための機能です。同時期の更新でClaude Fable 5.1のキャッシュ読み取り価格が100万トークンあたり0.25ドルに引き下げられており、両者を組み合わせることで長時間エージェントのコストを多層的に抑えられる設計になっています。
テスト戦略への影響と今日確認できること
CI/CDパイプラインでClaude APIを使ったエージェントテストを組んでいる場合、確認すべき項目は次の通りです。
- 使用中のモデル名とAPIバージョンを確認する（コンソールのAPIキー管理画面、またはリクエストヘッダーの
anthropic-versionから確認可能） - 長時間セッションのテストで独自の要約・切り捨てロジックを実装していないか、テストコードとプロンプト生成部分を洗い出す
- ベータヘッダー
compact-2026-09-04を使う場合、ベータ機能特有の仕様変更に備えてバージョン固定と結果比較のテストケースを用意する - thinkingブロックを利用するテストでは、圧縮後も思考過程の検証アサーションが機能するか個別に確認する
品質メトリクスの観点では、圧縮を挟んだ会話とそうでない会話で、期待する出力の一致率（アサーションのパス率）に差が出ないかを継続的に計測する価値があります。要約が挟まることで文脈の細部が失われ、期待していたツール呼び出しの精度が落ちるリスクはゼロではありません。回帰テストのスイートに「圧縮あり／なし」の両条件を並べて比較するケースを追加しておくと、ベータ解除時の挙動変化にも早く気づけます。
また、compactionはあくまでベータ機能である点も踏まえ、本番のCIパイプラインに組み込む前にステージング環境で一定期間の並行稼働を確認する運用が現実的です。ベータヘッダーを使う機能は将来のGA（一般提供）時にパラメータ名や挙動が変わることも珍しくありません。
まとめ
会話コンパクト機能は、長時間エージェントのコンテキスト管理を自前実装からAPI側委譲へ移す選択肢を増やすものです。
- 圧縮タイミングを開発者側で制御でき、直近ターンの逐語保持や思考ブロックの有効性も維持できる
- 署名付きブロックのため、システムプロンプトやツール定義の変更検知と組み合わせて考える必要がある
- スライディングウィンドウや手動要約と比べ、要約品質のばらつきを減らせる可能性がある一方でベータゆえの仕様変動リスクも残る
- 導入判断の第一歩は、現在のテストコードでどんな独自コンテキスト管理をしているかを棚卸しすることから始まる
まずは自分のプロジェクトで使っているモデル名とAPIバージョンをコンソールで確認し、長時間セッションのテストケースに「圧縮あり／なし」の比較を1つ加えてみるのが現実的な着手点です。