Compaction

コンパクションとは何ですか？古いメッセージを単純に削除することとどう違いますか？

コンパクションとは、長く続いた会話やタスクの履歴を自動的に簡潔な要約にまとめ、逐語的な元の内容を置き換えることで、コンテキストウィンドウの空きを確保する処理を指す。これは単純な削除とは異なる——削除は情報をそのまま捨てるが、コンパクションは重要な結論、合意済みの点、未解決の課題を保持しようとし、より簡潔な形で表現するだけである。

ユーザーにとって、理想的なコンパクションはほとんど気づかれないものであるべきだ——会話は継続でき、モデルは以前議論した重要な方向性を覚えているが、すべての文を逐語的に保持しているわけではない。

コンパクションはなぜ登場したのですか？どんな問題を解決しますか？

コンテキストウィンドウがどんどん大きくなっても、長時間実行されるタスク（複数ターンのデバッグ、長編のリサーチ協働、エージェントが数十のステップを連続実行するなど）は依然としてウィンドウを埋め尽くす可能性があり、たとえ埋め尽くさなくても、内容量が過大になるとコンテキストロットを引き起こし、モデルの要点抽出精度を低下させる。コンパクション機能は、「タスクを中断させない」という前提のもとで、会話やタスクが継続して動作できる時間を延ばすために登場した。

長時間稼働するエージェントアプリケーションにとって、これは特に重要である。ウィンドウの上限に近づくたびに会話全体を再起動しなければならないなら、ユーザー体験もタスクの連続性も損なわれる。自動コンパクションにより、システムはユーザーのワークフローを中断することなく、この処理をバックグラウンドで静かに行うことができる。

コンパクションは実務上どのように機能しますか？よくある手法は？

一般的な実装方法には以下がある。1つ目は「ローリング要約」——会話が一定のトークン閾値に近づくと、最も古いセグメントを数文に要約し、元の文章に代えてコンテキストに戻す。会話が進むにつれ、この要約範囲は継続的に前進する。2つ目は「選択的保持」——ユーザーが明示的に重要とマークした内容や、システムが重要な意思決定ポイントと判断した内容を優先的に保持し、それ以外の背景的情報を優先的に圧縮する。3つ目は「ツール結果の簡略化」——エージェントがタスクを実行する際に生成する大量の中間出力（コード実行結果や検索結果など）は、タスク完了後に結論的な要約に圧縮されることが多く、完全な生の出力を保持する必要はない。

これらの手法に共通する課題は、圧縮の判断基準を完全に自動化するのが難しいことである。要約が後で必要になる詳細を漏らしてしまうと、元の問題を解決するどころか新たな問題を生み出してしまう。

コンパクションは私にとってどんな意味があり、実務上何に注意すべきですか？

長時間のタスク（長編の共同執筆、複数ステップのエージェントワークフロー）でClaudeを使っているなら、コンパクション機能が存在することを理解しておくと、「モデルが以前の詳細を忘れたようだ」という現象が、モデルのエラーではなくコンパクションによる正常な副作用かどうかを判断する助けになる。初期に確立した重要な制約条件（例えば「この文書では受動態を使わない」）が会話の後半で無視されている場合、その詳細がコンパクション時に要約で失われた可能性が高い。その場合、原因を追及するより、直接もう一度明確に伝え直す方が通常は効率的だ。

本当に重要でコンパクションで失われてはならないルールや制約については、会話の中で定期的に再確認するか、それらを独立した短いリストにまとめて繰り返し貼り付けることを実務上おすすめする。システムが何を保持すべきかを自動判断することに完全に頼らないことが重要である。