研究解説 · 小互解読

会話をやり直すか、履歴を圧縮するか?Pi がモデルのコンテキスト自動圧縮をどう解決するか

長いタスクは、モデルの「記憶力」が良いから続くわけではありません。Pi は過去を次々と次のリクエストに詰め込み、収まらなくなると、自分の作業記憶を書き直します。

1分で要点
  • コンテキストの圧縮(Compacting context)は、以前の作業をより短い状態要約に書き換え、長いタスクのためにコンテキスト領域を確保することです。
  • Pi はデフォルトで直近の約 20k トークンを保持し、次の応答のために 16384 トークンを確保します。これらの数値は Pi の実装であり、業界の一般則ではありません。
  • 圧縮は損失を伴う移行です。作業の継続性は保たれますが、詳細は失われ、以前のプロンプトキャッシュは一時的に無効になります。

Pi、Claude Code、Codex にコードの修正、ログの調査、テストの実行などを連続して頼み、タスクが十分に長くなると、compacting context のような表示を目にすることがよくあります。

これはコードを圧縮しているのでも、ファイルを削除しているのでもありません。現在のセッションが、モデルが一度に読み取れる情報量の上限に近づいており、コーディングエージェントが以前の作業記録をより短いバージョンに書き換えて、タスクを続行できるようにしていることを示しています。

この限られた領域は、context window(コンテキストウィンドウ)と呼ばれます。モデルは応答のたびに、このウィンドウに入っている内容だけを参照できます。長いタスクでは、新しいメッセージ、コード、ログ、ツール呼び出し、実行結果が次々と追加され、ウィンドウはどんどん満たされていきます。compacting context が表示されるのは、エージェントが容量の上限に達する前に、今後の作業のための領域を確保する必要があるからです。

Earendil Engineering は、Pi の処理方法を詳しく説明した「How Compaction Works in Pi」という記事を公開しています。Pi はターミナルで動作するコーディングエージェントです。以下では、その具体的な実装について説明します。他のコーディングエージェントも同じ一般的な問題に直面しますが、トリガーとなるしきい値、保持量、要約方法は異なる場合があります。

モデルに記憶はなく、コンテキストを再生しているだけ

エージェントに決済障害の修正を依頼し、最初に「checkout がなぜ 502 を返すのか調べて」とだけ伝えたとします。しかし、モデルが実際に受け取るのは、その言葉だけではありません。system prompt、ツール定義、プロジェクト内のルールファイルも含まれます。ログツールを呼び出すと、そのツールの結果も履歴に追加されます。さらに情報を追加すると、次のリクエストには以前のすべての内容が再び含まれます。

エージェントが隠れた脳内領域に作業を永続的に記憶しているわけではありません。毎回のリクエストで、現在の作業現場をモデルの前に再現しているのです。