Claude Compaction APIで実現する無限コンテキスト会話 — 仕組み・実装パターン・トークン削減の実測まで

チャットボットを開発していると、必ずぶつかる「コンテキストウィンドウの壁」。会話が長くなるほどトークンは膨れ上がり、コストは跳ね上がり、最悪の場合APIエラーで会話が途切れる。Claude Opus 4.6で追加されたCompaction API（Beta）は、この課題をたった1つのパラメータで解決する。本記事では、内部メカニズムの技術解剖から、ユースケース別の実装パターン、そしてトークン消費量の実測比較まで、「コンテキストの壁」を突破するための実践ガイドをお届けする。

Compaction APIとは何か — 1パラメータで変わるコンテキスト管理

従来のコンテキスト管理の課題

これまで長い会話セッションを扱うには、開発者が自前でメッセージのトリムや要約を実装する必要があった。トークン数の計算、要約プロンプトの設計、重要な文脈の取捨選択——これらをすべて手作業で行うのは、正直かなりの負担だった。

Compaction APIの基本動作

Compaction APIは、既存の /v1/messages エンドポイントに context_management パラメータを追加するだけで利用できる。専用エンドポイントは不要だ。

会話がトークン閾値を超えると、Claudeが自動的に過去の会話を要約し、圧縮されたコンテキストで応答を継続する。対応モデルはClaude Opus 4.6（claude-opus-4-6）とSonnet 4.6（claude-sonnet-4-6）のみ。利用にはベータヘッダー compact-2026-01-12 が必要になる。

最小構成の呼び出し例を見てみよう。

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

const response = await client.beta.messages.create({
  betas: ["compact-2026-01-12"],
  model: "claude-opus-4-6",
  max_tokens: 4096,
  messages: [{ role: "user", content: "Webサイトの構築を手伝ってください" }],
  context_management: {
    edits: [{
      type: "compact_20260112",
      trigger: { type: "input_tokens", value: 10000 },
    }],
  },
});

たったこれだけで、入力トークンが10,000を超えた時点で自動的に圧縮が走る。

内部メカニズムを技術解剖する

圧縮が発動するタイミングと処理フロー

triggerで指定した閾値（最低50,000トークン、デフォルト150,000トークン）を超えた時点でCompactionが自動発動する。レスポンスのcontentに compaction タイプのブロックが含まれ、次回リクエストではそのブロックを含むメッセージ配列をそのまま送信すればよい。APIは compaction ブロックより前のメッセージをすべて無視するため、古いメッセージを手動で削除する必要はない。

pause_after_compaction: true を指定すると、圧縮のみ実行して応答生成を中断できる。このとき stop_reason が "compaction" になる。圧縮結果を確認・加工してから再送信したい場面で有効だ。

const response = await client.beta.messages.create({
  betas: ["compact-2026-01-12"],
  model: "claude-opus-4-6",
  max_tokens: 4096,
  messages,
  context_management: {
    edits: [{ type: "compact_20260112", pause_after_compaction: true }],
  },
});

if (response.stop_reason === "compaction") {
  // 圧縮済みメッセージを会話履歴に追加
  messages.push({ role: "assistant", content: response.content });
  // 必要に応じて追加の指示を挟み、再度リクエスト
}

なお、圧縮はシステムプロンプトを保持し、会話メッセージのみを要約対象とする。

Claude Code内部のCompactionとの違い

混同されがちだが、Claude Codeには3層のCompaction機構がある——Microcompaction（ツール出力の即時圧縮）、Auto-Compaction（コンテキスト80%到達時の自動圧縮）、Manual /compact（手動実行）。APIのCompaction APIはこのうちAuto-Compactionに相当する。Claude Codeの実測では87%のトークン削減（14,280→1,820トークン）が報告されている。

ユースケース別・実装パターン3選

パターン1: カスタマーサポートBot（高圧縮・コスト重視）

FAQの繰り返しが多く圧縮効率が高いため、閾値は低めに設定する。公式Cookbookでは37ターンのサポートシナリオで58.6%のトークン削減を実証している。

// カスタマーサポート: 低閾値で積極圧縮
context_management: {
  edits: [{
    type: "compact_20260112",
    trigger: { type: "input_tokens", value: 5000 },
    instructions: "顧客の問い合わせ内容、提示した解決策、未解決の問題を必ず保持してください",
  }],
}

パターン2: AIエージェント（精度重視・段階的圧縮）

ツール呼び出し結果やステップバイステップの推論を保持する必要があるため、閾値は高めに設定する。pause_after_compaction で圧縮品質を検証するパターンが有効だ。

// AIエージェント: 高閾値 + 圧縮品質検証
context_management: {
  edits: [{
    type: "compact_20260112",
    trigger: { type: "input_tokens", value: 80000 },
    pause_after_compaction: true,
    instructions: "ツール実行結果、エラー情報、次のステップの計画を必ず保持してください",
  }],
}

パターン3: 対話型チャットアプリ（バランス型）

自然な会話の流れを維持しつつ、超長期会話に対応する構成。

// 対話型チャット: バランス重視
context_management: {
  edits: [{
    type: "compact_20260112",
    trigger: { type: "input_tokens", value: 120000 },
    instructions: "ユーザーの名前、好み、過去に話した重要なトピックを必ず保持してください",
  }],
}

閾値チューニングとトークン消費の実測比較

閾値選択の判断フレームワーク

閾値が低いほど圧縮頻度が上がりコスト削減効果は大きいが、要約品質とレイテンシにトレードオフがある。公式Cookbookのガイドラインをまとめると以下の通りだ。

Compactionあり/なしのコスト比較

公式Cookbookの実測データが明快だ。37ターンのカスタマーサポートシナリオで、Compactionなしの合計208,838トークンが、閾値5,000トークンのCompactionありで86,446トークンまで削減された。58.6%の削減だ。

ただし、複数回の圧縮が連続する長時間セッションでは品質劣化リスクがある。「圧縮後の最初のタスクは動くが、後続の参照で問題が顕在化する」という実務報告もある。対策としては、instructions パラメータで絶対保持すべき情報を明示するのが有効だ。

また、トークン消費の正確な計算には注意が必要だ。レスポンスのトップレベル usage にはCompaction自体のトークン消費が含まれない。usage.iterations 配列を全件合算する必要がある。

実装時のハマりポイントと対策

実際に導入する際、確実に踏みがちな地雷をまとめておく。

ベータヘッダーの付け忘れ。betas: ["compact-2026-01-12"] を指定しないと通常のAPIとして動作し、圧縮は一切発生しない。エラーにもならないため気づきにくい。

圧縮後のメッセージ更新漏れ。レスポンスの content に含まれる compaction ブロックを次回リクエストのメッセージ配列に反映し忘れると、圧縮の恩恵を受けられない。会話ループ内で messages.push({ role: "assistant", content: response.content }) を確実に行うこと。

対応モデルの制約。Opus 4.5以前やHaikuでは使用不可。モデル移行時に見落としやすい。

ストリーミング時の挙動。compaction ブロックは content_block_delta の compaction_delta として一括送信される（テキストのように段階的にストリームされない）。イベントハンドラの実装に注意が必要だ。

これらを踏まえた堅牢なラッパー関数の例を示す。

async function sendWithCompaction(
  client: Anthropic,
  messages: Anthropic.Beta.Messages.BetaMessageParam[],
  triggerTokens = 150000
) {
  try {
    const response = await client.beta.messages.create({
      betas: ["compact-2026-01-12"],
      model: "claude-opus-4-6",
      max_tokens: 4096,
      messages,
      context_management: {
        edits: [{
          type: "compact_20260112",
          trigger: { type: "input_tokens", value: triggerTokens },
        }],
      },
    });

    // 圧縮ブロック含むレスポンスを会話履歴に追加
    messages.push({ role: "assistant", content: response.content });
    return response;
  } catch (error) {
    // Compaction失敗時: 古いメッセージを手動トリムしてフォールバック
    console.warn("Compaction failed, falling back to manual trim");
    const trimmed = messages.slice(-10);
    return client.messages.create({
      model: "claude-opus-4-6",
      max_tokens: 4096,
      messages: trimmed,
    });
  }
}

Compaction APIは、これまで開発者が手作業で対処してきた「コンテキストウィンドウの壁」を、context_management パラメータひとつで突破する仕組みだ。まだBeta段階ではあるが、58〜87%のトークン削減という実測値は、コスト最適化とUX改善の両面で大きなインパクトがある。

まずはカスタマーサポートBotなど圧縮耐性の高いユースケースから導入し、閾値チューニングと圧縮品質の検証サイクルを回していくのが現実的な第一歩だ。長期会話が当たり前になるAIプロダクトにおいて、Compaction APIは必須の武器になるだろう。