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

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

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

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

それぞれのステップは合理的ですが、累積した結果はただ一つ、履歴は一方的に増え続け、タスクはまだ完了していない可能性があります。コンテキストに収まらなくなると、エージェントは過去をそのまま持ち続けることはできず、どの内容を残す価値があるかを判断する必要があります。

会話をやり直すか、履歴を圧縮するか

現在のセッションをそのまま続行できない場合、エージェントには二つの基本的な選択肢があります。新しいセッションを開始すれば、すぐにすべての領域を確保できますが、目標、完了した作業、重要な決定、未解決の問題も一緒になくなります。あるいは、compaction（圧縮）を行うこともできます。つまり、古い履歴の一部をより短い表現に置き換えて、現在のタスクを続行します。

Pi は二番目の道を選びます。ここでの「圧縮」は、圧縮ファイルのように後で無劣化で復元できるものではありません。Pi は通常、モデルに古い履歴の要約を作成させます。領域は取捨選択によって確保されます。詳細は失われ、表現は要約され、一度だけ出現した情報は徐々に薄れていく可能性があります。

したがって、compaction のより正確な名前は損失を伴う作業状態の移行です。すべての文を保持することではなく、次回のモデルが次のことを把握できるようにすることです。目標は何か、何が行われたか、覆せない決定は何か、現在どこで行き詰まっているか、次に何をすべきか。

Pi が新旧コンテキストをどのように切り分けるか

Pi は会話全体を一度に要約するのではありません。まず最新のメッセージから遡って、切れ目となる線を引きます。現在の公式ドキュメントと固定されたソースコードのバージョンによると、contextTokens > contextWindow - reserveTokens のときに自動圧縮がトリガーされます。デフォルトでは、生成される応答のために 16,384 トークンを確保し、直近の 20,000 トークンを可能な限りそのまま保持します。

20k は予算であり、固定されたメッセージ数ではありません。直近の数ラウンドに大量のログやコードが含まれている場合、保持できるラウンド数は少なくなります。原文ではこれを大まかに5〜20ラウンドと換算していますが、これは保証ではありません。

切れ目より前の内容は抽出、シリアライズされ、要約されます。切れ目より後は、元の順序のまま新しいリクエストに含まれます。Pi は通常、一ラウンドが終了した後に自動圧縮をチェックします。モデルがラウンドの途中で制限超過エラーを返した場合のみ、その場で圧縮して再試行することがあります。

ユーザーは /compact [instructions] を実行して、必要なときに早期に圧縮し、追加の指示で要約者に特定の情報を保持するよう促すこともできます。このエントリポイントはタイミングと重点を変えることができますが、それでも損失を伴う要約を無限の記憶に変えることはできません。

要約は作業の引き継ぎ

通常の要約は「何について話したか」に関心があります。作業の引き継ぎが関心を持つのは、次の担当者がすぐに作業を開始できるかどうかです。

Pi は独立したモデルリクエストを開始し、ロールを context summarization assistant に変更し、現在の会話を続行するのではなく、構造化されたチェックポイントを出力するよう要求します。現在のプロンプトでは、六つのカテゴリの情報を保持するよう要求しています。

• Goal：ユーザーが最終的に達成したいこと。
• Constraints & Preferences：違反できない制約と好み。
• Progress：完了済み、進行中、妨げられている項目。
• Key Decisions：重要な選択とその理由。
• Next Steps：次にどの順序で進めるか。
• Critical Context：パス、関数、エラーメッセージ、その他の正確な情報。

生成された結果は、プレーンテキストの CompactionEntry としてセッションに書き戻されます。新しいリクエストは次のようになります。

[system] [tools] [summary] [recent turns] [new user]

プレーンテキストの利点はシンプルです。人間は要約に重要な決定が漏れていないか確認でき、Pi もモデルを切り替えた後もそれを使用し続けることができます。移行されるのは可視の作業状態であり、特定のモデル内部の検査できない記憶ではありません。

ただし、この引き継ぎ書は要約者が認識できたものだけを保持できます。重要な制約が非常に早い段階で一度だけ出現した場合、繰り返しの圧縮によって薄れる可能性があります。本当に失いたくないプロジェクトのルールは、AGENTS.md、タスクの状態、コード、その他の永続的な記録に書き込むのが最善です。

プレフィックスが変わると、古いキャッシュは無効になる

Compaction は領域を確保する一方で、毎回のリクエストで最も敏感な部分であるプレフィックス（前置部分）も変更します。

モデルプロバイダーのプロンプトキャッシュは通常、正確なプレフィックス一致に依存しています。圧縮前は、次のリクエストはほとんどの場合、古い履歴にそのまま追記されるだけです。圧縮後は、古い履歴が新しい要約に置き換えられます。直近の数ラウンドが一字も変わっていなくても、それらの前にある内容が異なるため、古いキャッシュは元の位置から再利用できません。

これはキャッシュを永久に失うことを意味するわけではありません。圧縮後の構造が新しい安定したプレフィックスになり、後続のリクエストはその上にキャッシュを蓄積し続けることができます。これはまた、Pi が可能な限りラウンド終了後に圧縮する理由も説明しています。まずこのラウンドの連続するリクエストが古いプレフィックスのキャッシュの利点を享受してから、コンテキストを書き換えるのです。

圧縮後、すぐに作業を開始できるか

Pi のトレードオフはこれで完全になります。すべての履歴を保持するとコンテキストの上限に達し、履歴を圧縮すると詳細が失われ、キャッシュの再計算というコストが発生します。完全に新しいセッションを開始すると、作業の継続性も放棄することになります。

compaction が良いかどうかを判断するには、四つの質問をするとよいでしょう。直近の作業はどのくらいそのまま保持されているか？要約は目標、決定、進捗、次のステップを保持しているか？結果は人間が確認でき、モデル間で移行できるか？トリガーのタイミングは、残り領域、オーバーフローリスク、キャッシュコストの間で合理的なバランスを取っているか？

優れた compaction は「すべての過去を記憶すること」ではありません。忘却が避けられないことを受け入れ、その上で、本当に次のステップに影響を与える作業状態を次の担当者に引き渡すことです。