# コンテキスト圧縮の設計——AIエージェントの長期セッション管理

> 長期エージェントセッションでコンテキストウィンドウが逼迫すると品質が劣化します。Anthropic Compaction APIと3層管理設計（ホット・ウォーム・コールド）を組み合わせたコンテキスト圧縮の実装パターンを解説します。

- Canonical: https://kuucorp.com/blog/agent-context-compression-session-management/
- Date: 2026-06-30
- Last modified: 2026-06-30
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
数十ターンに及ぶエージェントセッションでは、コンテキストウィンドウが逼迫するにつれて応答品質が劣化します。モデルが「会話の中央で言ったこと」を見落とす「中央失念問題（Lost in the Middle）」は、コンテキスト長が増えるほど顕在化します。2025年のエンタープライズ障害分析では、AIエージェントの障害の65%がコンテキストドリフトまたはメモリ喪失に起因すると報告されています。

コンテキストウィンドウの拡張は根本解決ではありません。1億トークン超のウィンドウでも、全履歴を詰め込む設計はコストが線形に増加し、推論レイテンシが悪化します。本記事は[AIエージェントガバナンス](/ai-governance/)ピラーの一部です。[メモリアーキテクチャの設計](/blog/agent-memory-architecture-short-term-long-term/)と[コンテキストエンジニアリング](/blog/context-engineering-token-budget-design/)と合わせて参照してください。

## コンテキスト圧縮が必要な理由は何か

> コンテキストウィンドウへの全履歴詰め込みはコスト線形増加と「中央失念問題」を引き起こし、65%の長期エージェント障害の根本原因となっています。

Anthropicのコンテキストエンジニアリングガイドは「目的の成果を最大化する最小限の高信号トークンのセットを特定する」ことを根本原則として示しています。「最小限」と「高信号」が同時に求められるのは、コンテキストが長くなるほどモデルが重要な情報を見落とすためです。

長期セッションで発生する具体的な問題：

- **中央失念問題**: コンテキストウィンドウの中央部に置いた情報は、先頭や末尾に比べてモデルが参照しにくい
- **ツール結果の冗長蓄積**: 過去のツール実行結果が生の形でコンテキストに残り、後段のLLM呼び出しのノイズになる
- **コスト線形増加**: 入力トークンが増えるほど推論コストが直線的に上昇し、1日数百セッションのエージェントでは月次コストに直結する
- **レイテンシ悪化**: 大規模コンテキストはプレフィルフェーズが長くなり、最初のトークン生成までの時間（TTFT）が延びる

## 3層コンテキスト管理アーキテクチャ

> ホット層（直近10ターン・無圧縮）・ウォーム層（11〜40ターン・詳細要約）・コールド層（41ターン以降・大局要約）の3層でコストと品質を両立します。

2026年の本番エージェント設計における標準アーキテクチャは3層の階層的コンテキスト管理です。

| 層 | 対象範囲 | 処理 | 目的 |
|---|---|---|---|
| ホット（Hot） | 直近10ターン | 無圧縮・完全保持 | 直前の文脈を正確に参照 |
| ウォーム（Warm） | 11〜40ターン | 詳細要約（ローリング） | 重要な決定・ツール出力を保持 |
| コールド（Cold） | 41ターン以降 | 大局要約 | 目標・制約・文脈の骨格 |

### ホット層：無圧縮の最近ターン

直近のやり取りはそのまま保持します。「今まさに何をしているか」の文脈を正確に持つことで、モデルが直前の指示を誤解するリスクを最小化します。圧縮コストをかけず、鮮度の高い情報をそのまま使う設計です。

### ウォーム層：詳細ローリング要約

11〜40ターン前の会話は、詳細なローリング要約として維持します。新しいターンが加わるたびに要約を更新しますが、**新要約を毎回再生成（フル再構築）するのではなく、既存要約にマージする「アンカード反復要約」**が精度・完全性・タスク継続性で優れています。

保持すべき情報の優先順位：
1. エージェントが下した設計上の決定と根拠
2. ツール実行の主要な結果（生データではなく要点）
3. ユーザーが明示した制約や好み
4. 未解決の問題や次のステップ

### コールド層：大局サマリー

41ターン以降の古い会話は、プロジェクト全体の目標・制約・前提条件のみを含む大局要約に圧縮します。ここでは詳細よりも「なぜこのプロジェクトをしているか」の骨格を保持することが重要です。

## Anthropic Compaction APIの実装パターン

> Anthropic Compaction APIはbetaヘッダー `compact-2026-01-12` で有効化し、入力トークンが設定閾値（デフォルト150,000）を超えると自動的に会話を圧縮します。

Anthropicは2026年1月にContext Compaction APIをリリースしました。Claude Opus 4.6以降およびSonnet 4.6でサポートされ、会話が指定トークン数に達すると透過的に圧縮を実行します。

### 基本的な有効化

```python
import anthropic

client = anthropic.Anthropic()

response = client.beta.messages.create(
    betas=["compact-2026-01-12"],
    model="claude-sonnet-4-6",
    max_tokens=4096,
    messages=messages,
    context_management={
        "edits": [{
            "type": "compact_20260112",
            "trigger": {
                "type": "input_tokens",
                "value": 100000   # 閾値（最小50,000）
            }
        }]
    },
)
```

### Compactionブロックの処理

圧縮が発生すると、レスポンスに `compaction` コンテンツブロックが含まれます。このブロックを次回リクエストのmessagesに含めることで、APIが自動的に圧縮前の全コンテンツを削除し、要約から継続します。

```python
# compactionブロックが返された場合はmessagesに追加して継続
if response.stop_reason == "compaction":
    messages.append({
        "role": "assistant",
        "content": response.content   # compactionブロックを含む
    })
```

### `pause_after_compaction` による精密制御

`pause_after_compaction: true` を設定すると、圧縮直後に停止し制御を返してきます。圧縮後に追加コンテキストを注入したり、圧縮カウンターでトークン予算を追跡する場合に有効です。

```python
context_management={
    "edits": [{
        "type": "compact_20260112",
        "trigger": {"type": "input_tokens", "value": 100000},
        "pause_after_compaction": True,
        "instructions": "コード実装の詳細・設計上の決定・未解決のバグを必ず保持すること"
    }]
}
```

### トークン計測の注意点

Compaction APIは**追加のサンプリング**（圧縮のためのLLM呼び出し）を行うため、請求対象トークンが増加します。レスポンスのトップレベル `input_tokens` / `output_tokens` は圧縮イテレーションを含まないため、総コストを把握するには `usage.iterations` を合計する必要があります。

```python
# 総コストの計算
total_input = sum(it["input_tokens"] for it in response.usage.iterations)
total_output = sum(it["output_tokens"] for it in response.usage.iterations)
```

## コンテキスト管理の3アプローチ比較

> Anthropicが推奨する3アプローチ（コンパクション・構造化ノート・サブエージェント）はユースケースの特性で選択します。

Anthropicのガイドでは、長期セッション向けに3つのアプローチを整理しています。

| アプローチ | 特性 | 適したユースケース |
|---|---|---|
| **コンパクション** | API1回で透過的に圧縮 | 長い対話型セッション・カスタマーサポート |
| **構造化ノート** | エージェントがメモファイルを自律管理 | 反復的な開発・明確なマイルストーン |
| **サブエージェント** | 専門化した子エージェントに委譲 | 並行調査・複雑な多工程タスク |

**コンパクション**は API コールが最もシンプルで、会話の継続性が重要なユースケースに向いています。

**構造化ノート**はエージェントが `NOTES.md` 等のメモファイルを自律的に更新し、セッション開始時に読み込む設計です。ツールとしてメモを読み書きする実装が一般的です。

**サブエージェント**は、親エージェントが子エージェントにクリーンなコンテキストウィンドウでサブタスクを委譲し、1,000〜2,000トークンの凝縮サマリーのみを受け取る設計です。[サブエージェント設計パターン](/blog/subagent-orchestration-design-patterns/)と組み合わせると、各エージェントのコンテキストを小さく保てます。

### ツール結果のクリア

Anthropicはコンテキスト管理のベストプラクティスとして「深い会話履歴のツール呼び出し結果を削除する」ことを推奨しています。ツールが返した生のJSONやHTMLが何十ターンも前のメッセージに残っているなら、そこから有用な情報はほぼ抽出済みのはずです。生データをウォーム・コールド層に残すことはコストとノイズの両方を増やすだけです。

### 規模別の留意点（SMB / エンタープライズ）

**SMBの場合**: Anthropic Compaction APIの `compact_20260112` を有効にするだけで、ほとんどのユースケースは対応できます。デフォルト閾値の150,000トークン（約10〜20万文字）はほとんどの中小企業のセッション長をカバーします。追加インフラは不要で、APIキーさえあれば即日導入可能です。[Kuuの運用管理サービス（AI-Ops）](/services/ai-ops/)では、コンパクション設計とコスト計測の設定支援を行っています。

**エンタープライズの場合**: 大規模運用ではコンパクション発生時のトークンコスト計測・部門配賦が重要です。`usage.iterations` から圧縮イテレーションのコストを分離し、[AI FinOps設計](/blog/ai-finops-token-cost-instrumentation/)に組み込んでください。カスタム `instructions` で業務固有の保持ルール（コード実装・規制情報・承認フロー記録等）を設定すると、圧縮後の品質が向上します。Kuuの[大規模AI基盤支援（RDE）](/services/rde/)では、マルチチームのコンテキスト管理ポリシーと圧縮パイプラインの設計を担当します。

## 参考

- [Compaction – Claude Platform Docs](https://platform.claude.com/docs/en/build-with-claude/compaction)
- [Effective Context Engineering for AI Agents – Anthropic Engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)

## まとめ

長期エージェントセッションの品質維持には、コンテキストウィンドウの拡張ではなく、圧縮・管理の設計が必要です。3層管理アーキテクチャ（ホット・ウォーム・コールド）とAnthropicのCompaction APIを組み合わせることで、セッションの連続性を保ちながらコストと品質のバランスを取れます。

AIエージェントの長期セッション設計・コンテキスト管理の実装については、[Kuu株式会社のAIエージェント運用管理サービス（AI-Ops）](/services/ai-ops/)にご相談ください。