Context Compaction（文脈圧縮）

長時間・多ステップの実行でコンテキストウィンドウに蓄積する会話履歴・ツール出力・中間結果を、閾値到達時に要約・削除・外部退避で圧縮し、圧縮後の文脈でループを継続する。ウィンドウ上限への到達と、情報過多による品質劣化（context rot）の両方を、モデルの賢さではなく構造で防ぐ。

別名

呼称	出典
Compaction	Anthropic「Effective context engineering」/ Claude Code の /compact
Conversation Summarization / History Summarization	LangChain 等の各種FW（要約メモリ）
Context / Message Compaction	OpenAI Agents SDK（OpenAIResponsesCompactionSession）

問題

自律ループや長い対話では、毎ターンの会話履歴・ツール実行結果・思考過程がコンテキストへ単調に蓄積する。これは3つの形で破綻する。

1. ウィンドウ上限への到達 — 履歴がウィンドウを超え、古い情報（初期の指示やタスク目標）が暗黙に切り捨てられる。
2. 情報過多による品質劣化 — 上限手前でも、無関係な詳細が増えるほどモデルの注意が拡散し、中盤の重要情報を見落とす（"lost in the middle" / context rot）。
3. コストの膨張 — ステートレスなAPIでは毎ターン全履歴を再送するため、トークン課金が反復回数に対して二次関数的に増える。

いずれも「もっと大きなウィンドウ」では解けない。ウィンドウを倍にしても、蓄積が続く限り同じ壁に当たり、注意の拡散はむしろ悪化する。

コンテキスト

適用する:

• 長いホライズンの自律ループ（ReAct、Orchestrator-Workers）や長時間の対話セッション
• ツールの出力が大きいタスク（大きなファイル・API応答・検索結果をループで扱う）

適用しない（不要な）ケース:

• 単発呼出や短いワークフロー（Prompt Chaining の数段程度）——蓄積が上限に届かない
• 要約による情報損失が許されない監査・法務用途——この場合は圧縮せず、全文を外部ストアへ退避して参照する（Memory / Checkpoint & Resume）

解決

コンテキスト長を監視し、閾値（例: ウィンドウの70%）に達したら、残す部分と圧縮する部分を役割で仕分けて圧縮する。恒久的な指示（システムプロンプト・タスク目標）と直近のやり取りは原文で保持し、中盤の冗長なツール出力・思考過程を要約または要点へ置換する。

圧縮は不可逆な情報損失を伴うため、圧縮の前に生ログを外部へ永続化してから行う（Checkpoint & Resume）。後で詳細が必要になったら退避先から参照して回復できるようにする。

THRESHOLD = 0.7 * WINDOW

def step(state):
    if token_count(state.history) > THRESHOLD:   # 閾値監視（Budget Guardと同じ発想）
        archive.save(state.history)               # 生ログを外部退避（不可逆損失を防ぐ）
        state.history = compact(state.history)    # 指示・直近は原文、中盤を要約へ置換
    action = llm(state.system + state.history)
    return apply(action, tools)

def compact(history):
    keep = history.system + history.recent(n=RECENT)   # 恒久指示＋直近は保持
    digest = summarize(history.middle())               # 中盤の詳細を要約
    return keep.with_summary(digest)

実装の要点:

• トークン閾値で発火させる。 ターン数ベースは、1ターンが巨大なツール出力を持つ場合の膨張を防げない（Budget Guard と同じ理由）
• 役割で残す／捨てるを決める。 一律に古い順で切ると、初期のタスク目標という最重要情報を失う。恒久的な指示と直近の文脈は保持し、中盤の詳細を圧縮対象にする
• 圧縮前に生ログを外部退避する。 要約は損失。後で必要になった詳細を回復できるよう、圧縮とセットで永続化する
• 圧縮自体のコストを意識する。 要約もLLM呼出であり、頻度と粒度でコスト・レイテンシが変わる。閾値と要約範囲は計測で調整する

トレードオフ

• ✅ 長時間タスクでもウィンドウ上限に当たらず継続でき、トークンコストが反復回数に対して線形に近づく
• ✅ 情報密度が上がり、"lost in the middle" による品質劣化を抑えられる
• ⚠️ 要約は不可逆な情報損失。何を捨てるかの判断を誤ると、後続で必要な詳細が消える。生ログの外部退避が前提になる
• ⚠️ 圧縮の発火頻度・粒度の調整が要る。過剰な圧縮は文脈の断絶を、過小な圧縮は上限到達を招く

クラウドパターンとの対応

クラウドパターン	本パターンでの再定義
Claim-Check	「大きなペイロードを外部ストアへ預け、メッセージには取得用の参照だけを載せる」から「大きなツール出力や古い履歴を外部へ退避し、コンテキストには要約と参照だけを残す」へ。運ぶ対象がメッセージ本文からLLMの文脈になった

関連パターン

• Memory — 圧縮で文脈から外す情報の恒久的な退避先。直近の作業文脈は Compaction で畳み、後で使う事実は Memory へ移す
• Context Triage — 入口で入れる情報を絞るのが Triage、蓄積した後に減らすのが Compaction。上流と下流の関係にある
• Checkpoint & Resume — 圧縮前の生ログを永続化する土台。要約による損失を回復可能にする
• Budget Guard — トークン量の監視と上限制御を共有する。Compaction は「上限に当てない」ための能動策

出典・参考

• Anthropic — Effective context engineering for AI agents（compaction による長ホライズン文脈の維持）
• OpenAI Agents SDK — Sessions（OpenAIResponsesCompactionSession によるターンごとの自動圧縮）
• Azure Architecture Center — Claim-Check pattern（系譜元のクラウドパターン）