コンパクションとは、コンテキストウィンドウの上限に近づいた会話を取り上げてその内容を要約し、その要約を使って新しい コンテキストウィンドウを始め直す実践である。Anthropic はこれを、長期的な一貫性を高めるための コンテキストエンジニアリング において通常まず最初に使う手段だと説明している。その核心は、コンテキストウィンドウの 内容を高い忠実度で蒸留し、エージェントが性能の劣化を最小限に抑えながら作業を続けられるようにすることにある。
用法
Claude Code では、Anthropic はメッセージ履歴をモデルに渡し、最も重要な詳細を要約・圧縮させる ことでコンパクションを実装している。モデルはアーキテクチャ上の決定、未解決のバグ、実装の詳細を保持し、冗長なツール 出力やメッセージは破棄する。エージェントはその後、この圧縮されたコンテキストに直近にアクセスした五つのファイルを 加えた状態で作業を続けるため、ユーザーはコンテキストウィンドウの制約を気にすることなく連続性を得られる。
Anthropic は、ツール呼び出しとその結果の消去を、手を付けやすい余分な内容として挙げている——メッセージ履歴の奥深くで 一度ツールが呼び出されてしまえば、その生の結果を再び見る必要は一般にない——そして、ツール結果のクリアを最も安全で 最も軽い部類のコンパクションの一つと呼んでいる。同社はこれを Claude Developer Platform の機能としてリリースしたと 説明している。
Claude Code のユーザー向けドキュメントは、同じ振る舞いをユーザーの側から説明している。それによれば、コンテキストの
上限が近づくと、Claude Code はまず古いツール出力を消去し、必要に応じて会話を要約する。ユーザーの依頼と重要な
コードスニペットは保持されるが、会話の初期に与えた詳細な指示は失われることがあり、そのため永続的なルールは会話履歴に
頼らず CLAUDE.md に置くよう勧めている。何を残すかは、CLAUDE.md に「Compact Instructions」セクションを
加えるか、焦点を指定して /compact を実行することで誘導できる。ドキュメントは失敗事例も記録している。単一のファイルや
ツール出力が大きすぎて、要約のたびにすぐにコンテキストが再び埋まってしまう場合、Claude Code は数回試みた後に自動
コンパクションを止め、ループする代わりにエラーを表示する。
Anthropic の API はコンパクションをサーバーサイドの機能として提供しており、
コンテキストエンジニアリング：メモリ、コンパクション、ツール結果のクリア はこれを compact_20260112 というコンテキスト
編集として順を追って解説している。これはトークン数のしきい値（最小 50K、デフォルト 150K）で自動的に発動し、
アプリケーションがそれ以前の会話の代わりに送り返す、型付きのコンパクションブロックを返し、要約の境界をまたぐ
ツール利用のペアリングを処理する。このノートブックは、コンパクションがトランスクリプト全体に対する操作である
——ユーザーとアシスタントのメッセージ、ツール呼び出し、ツール結果、さらには以前のコンパクションブロックまでが
すべて要約へと平坦化される——ことを強調しており、それが古いツール結果だけを削除するトランスクリプトの一部に対する
編集である ツール結果のクリア との違いだとしている。カスタムの instructions パラメータは
デフォルトの要約プロンプトを補うのではなく完全に置き換えるため、それを指定する呼び出し側は枠組み全体を引き受ける
ことになる。ノートブックの例では、そのリサーチエージェントが保持を必要とする具体的な詳細、たとえばすべての定量的な
数値とその出典や、どの文書がまだ読まれていないかを指定している。自分のエージェントが生成した要約を調べたところ、
タスクの中心となる大まかな事実は残る傾向にあった一方、付録の表の一つのセルのような細かな具体的事項は残らない傾向に
あったとノートブックは報告している。コンパクションは実質を圧縮した形で保持するが、逐語的な詳細は失うのである。
要約のパスは必ずしも一段階ではない。Dive into Claude Code：現在および将来の AI エージェントシステムの設計空間 は v2.1.88 時点の Claude Code の ソースを読み、そこでのコンパクションを、各モデル呼び出しの前に順に実行される五つのシェイパーからなるパイプラインとして 記述している。後段ほど強力になり、順に、過大な出力をコンテンツ参照に置き換えるツール結果ごとの予算、古い履歴セグメントの 軽量な切り詰め、きめ細かなキャッシュを意識した圧縮、保存された履歴には手を付けずに折りたたんだビューを提示する 読み取り時の射影、そして最後に、他の四つが実行された後もなおコンテキストが圧力のしきい値を超えている場合にのみ発動する、 モデルが生成する完全な要約である。著者らはこれを遅延劣化の原則——最も混乱の少ない圧縮を先に適用し、より安価な戦略が 不十分だと判明したときにのみ段階を上げる——と説明し、コンパクションの出力は以前のトランスクリプトの行を上書きするのでは なく追記されるため、以前の内容は再構成に利用できる状態で残ると指摘している。
同じ研究は、この段階的な設計が何を代償とするかについても明示的である。五つの層が相互作用し、そのいくつかがフィーチャー フラグで制御されているため、ユーザーにとって予測しにくい振る舞いが生じる。また圧縮はほとんど目に見えない。予算による 置き換え、切り詰め、折りたたみが何を取り除いたかをユーザーが確認する簡単な方法はなく、キャッシュを意識した振る舞いに よって、圧縮の判断がユーザーには示されない形でプロンプトキャッシュに依存するようになる。著者らはさらに、要約に基づく コンパクションのさらなる二つのコストを報告する外部の研究を紹介している——要約の段階が推論をブロックする停止を 引き起こすこと、そしてそれが非決定的で、同一の入力でも実行ごとに保持される内容が揺れ動くことである。著者らはこの手法 全体を、より単純な代替策、すなわち一回きりの切り捨てや一段階の要約と対比している。これらは情報を犠牲にするが、 理解しやすい。
日常的な使用でコンパクションが実際にどれくらいの頻度で発動するかは、セッションログから測定されている。 TraceLab：LLM サービングのためのコーディングエージェントのワークロード特性評価 は、Claude Code と OpenAI Codex の 約 4,300 件の実際のセッションを分析し、セッションのコンテキストのピーク付近で起こり、その後ゆっくりと再増加する、 一ステップで少なくとも 64K 入力トークンの減少をコンパクションとして識別している。この定義により、コンパクションは 「まれではないが支配的でもない」ことを見いだしている。セッションの 9.7% が少なくとも一回コンパクションを経験し、 経験したセッションでは平均 3.7 回で、長い裾を持つ。それは圧倒的にツール側から開始される——ユーザーのターンではなく ループの途中で起こる——もので、Claude Code（4.5%）よりも Codex（セッションの 18.4%）ではるかに多く、著者らはこれを Codex のより短いコンテキスト長と関連付けている。
適用される場面
-
トークン数がコンテキストウィンドウを超える長期タスク、とりわけ多くのやり取りを要する作業に適用される。Anthropic は、 そうしたタスクではコンパクションが会話の流れを維持すると述べ、明確なマイルストーンを伴う反復的な開発で優れている と同社が言うノートテイキングと対比している。
-
メッセージ履歴をモデルで要約できること、そしてコンパクションのプロンプトが対象となるトレース向けに調整されている ことを前提とする。Anthropic は、複雑なエージェントのトレースでそのプロンプトを慎重に調整することを推奨している。 まず再現率を最大化してトレースから関連するあらゆる情報を捉えるようにし、その後、余分な内容を取り除いて適合率を 高めるよう反復する。
-
過度に積極的に適用すると失敗する。Anthropic は、コンパクションの要諦は何を残し何を捨てるかの選択にあり、過度に 積極的なコンパクションは、後になって初めて重要性が明らかになる微妙だが決定的なコンテキストを失いかねないと述べて いる。
-
Claude Code における Anthropic 自身の実装済みの実践として、また出荷済みのプラットフォーム機能として確立しており、 測定結果としてではなく同社のエンジニアリング経験から説明されている。上記の五層の説明は、単一バージョンのソースを 読んだ一つの研究に依拠しており、その著者らはフィーチャーフラグによってビルドごとに違いが生じると注意を促している。
-
長時間稼働エージェントに関するある投稿は、Anthropic が、要約によるコンパクションだけでは非常に長いジョブには 不十分だと明言していると説明している。通常のコンパクションに加えて、Anthropic のハーネスは完全なコンテキスト リセットも行い、そこではハーネスがセッションを破棄し、構造化されたハンドオフファイルからそれを再構築する——これは 本質的に、人間が新しいエンジニアをオンボーディングするやり方だと説明されている。
-
Anthropic は同じ限界を 長時間稼働エージェントのための効果的なハーネス で直接述べ、その背後にある 仕組みを名指ししている。コンパクションは次のエージェントに完全に明確な指示を必ずしも渡すとは限らないのである。 同社が報告する根拠は、Claude Agent SDK 上で複数のコンテキストウィンドウにまたがって ループで動作するフロンティアモデルが、コンパクションを利用できたにもかかわらず、高レベルのプロンプトから本番品質の Web アプリを構築するには至らなかったこと、そして結果として生じた実装途中で文書化されていない機能のせいで、次の セッションが何が起きたのかを推測する羽目になったことである。同社が説明する対策はより良いコンパクションではなく、 コンテキストウィンドウの外にある永続的な成果物、すなわち進捗ログ、git の履歴、構造化された機能リストである （イニシャライザーエージェント を参照）。
-
その後の Anthropic のエンジニアリング投稿 長時間稼働するアプリケーション開発のためのハーネス設計 は、コンパクションと完全な コンテキストリセット との境界を、それぞれが何をもたらすかという観点から引いている。コンパクションは会話の 以前の部分をその場で要約し、同じエージェントが短縮された履歴の上で作業を続けられるようにするもので、連続性は保つが エージェントに白紙の状態を与えるものではない。リセットはウィンドウを完全に消去して新しいエージェントを始動させるが、 作業を滞りなく引き継げるだけの状態をハンドオフの成果物が担わねばならないという代償を伴う。
-
この区別は、とりわけ一つの失敗モードにとって決定的な意味を持つ。同じ投稿は、コンパクションでは同じエージェントが 走り続けるため、コンテキスト不安——モデルが自身のコンテキストの上限だと思い込んでいるものに近づくと、 作業を早々に切り上げてしまうこと——がコンパクションを経ても持続しうると報告している。Claude Sonnet 4.5 はこれを 強く示したため、コンパクションだけでは長いタスクで高い性能を出すのに不十分であり、そのハーネスの設計にはコンテキスト リセットが不可欠になったこと、そして Claude Opus 4.5 はこの振る舞いをほぼ自力で解消し、後のハーネスではリセットを 完全に取り払って、Claude Agent SDK の自動コンパクションにコンテキストの増大を処理させる 一つの連続したセッションとして実行できるようになったことを述べている。したがって、コンパクションが十分かどうかは、 技法だけでなくモデルに依存すると報告されていることになる。
-
コンテキストエンジニアリングのプリミティブに関する Claude Cookbook のノートブックは、対話が主要なコンテキストである 場合にはまずコンパクションを、そして一時的な API やアップロードのようにツール結果を容易に再取得できない場合には ツール結果のクリアよりもコンパクションを推奨している。セッションがコンテキストの上限を十分に下回ったままであれば コンパクションを省くよう勧めており、その理由は、コンパクションは損失を伴うため、余裕を確保する必要がなければ何の 見返りもなく忠実度を支払うことになるからだという。また、コンパクションはモデルが要約を書かなければならないため推論の コストがかかること、そしてセッションをまたいだ永続性は提供しないことを指摘している。
-
コンパクションはいくつかある設計上の選択肢の一つであり、スキャフォールドの内側：コーディングエージェントアーキテクチャのソースコードレベルの分類体系 はそれを、 状態管理やマルチモデルのルーティングと並んで、オープンソースのコーディングエージェントが分岐する次元の一つに数えて いる。同論文が分析した 13 のスキャフォールドにわたって七つの異なる戦略があり、まったく管理しないものから、モデル 自身が要求するコンパクションまでに及ぶ。同論文はこれらを二つの思想に分類している。 予防型のエージェントは、作業単位ごとにメッセージの範囲を限定する、検索のラウンド数に上限を設けて結果を切り詰める、 あるいは軌跡の深さを制限するといった形で、コンテキストの増大を構造的に抑える。治療型のエージェントはコンテキストを 増大させるに任せ、トークンのしきい値に達したときに圧縮する。予防は要約のコストと情報の損失を避けるが、コンテキストが どう増大するかをスキャフォールドが予測しておく必要がある。
-
同論文がこの両極の間で区別している戦略は、ルールに基づく切り捨て（最初と最後の N 個の観測を残し、残りを省略する）、 構造的な分離、予算内でのトークンに基づく選択的な取り込み、スキャフォールドが起動するモデルによる要約、重要な情報が 失われていないかを確認する検証ターンを後続させる要約、そしてスキャフォールドではなくモデルがいつコンパクションするかを ツールによって決めるモデル起動のコンパクションである。同論文は、あるエージェントがすべてのモデル呼び出しを会話履歴の ない単一ターンにすることで問題そのものを回避しており、その結果、作業をコンテキストに収めることは実行時の問題ではなく プロンプト構築の問題になっていると指摘している。
-
同じ論文は、コンパクションを収束している次元ではなく分岐している次元の中に位置付け、その分岐をノイズではなく 真の不確実性と読んでいる。情報の保持とトークンのコストの釣り合いには、タスクの長さ、モデルの能力、コストの許容度に 依存する最適点があり、単一の戦略ではそれを解決できないというのである。