コードエージェントにおける「コンパクション」の仕組みと Pi の実装

長時間にわたるコーディングセッションを行う際、文脈ウィンドウの制限により対話が続けられなくなる経験がある方も多いでしょう。本稿では、その解決策である**コンパクション（要約）**の仕組みと、特に Pi がそれをどのように実行すべき時機を見極めているかについて解説します。

1. LLM 対話における文脈の制約

大規模言語モデル（LLM）には処理可能な情報量の上限、すなわち文脈ウィンドウが存在します。コードエージェントのセッションは、会話履歴やツール呼び出しが増えるにつれて膨らみ、この容量を超えるとリクエストが却下されます。

対話の拡大とエラー

エージェントと LLM のやり取り（ターン）が進むごとに、以下の構成要素が文脈に追加されます。

• Request 1

  • 構成要素：

    [system][tools][user]

  • 結果：LLM がアシスタントメッセージ（ツール呼び出しを含む）を返すか、ターンの開始となる。

• After Request 1

  [system][tools][user][assistant: tool call][tool result][assistant]
  

• Request 2

  • ユーザーが新たなメッセージを送信し、対話がさらに拡大する。
  • 構成要素：

    [system][tools][user][assistant: tool call][tool result][assistant][user]

このようにターンを重ねることで、やがて文脈ウィンドウの容量を超える状態になります。

• Context Window を超過

  [system][tools][user][assistant][....][tool result][user]
                                                 ^
                                      exceeds context window
  

  • エラーメッセージ例：

    "Request size exceeds maximum"

2. 文脈オーバーフローへの対応策

履歴が破棄されても対話を継続したい場合、以下の二つの選択肢があります。

1. 新しい空の対話を開始する

   • 蓄積されたコンテキストを持たないため、過去の決定や未解決作業は失われます。
   • ただし、LLM の出力性能は文脈が長くなるにつれて低下するため、合理的な場合もあります。

2. 対話コンテキストを要約する（コンパクション）

   • 履歴の一部を圧縮された表現で置き換え、新しいメッセージやツール呼び出しのための余地を残す手法です。

3. コンパクションの仕組み

理論的には決定論的な関数で一部データを保存・破棄することも可能ですが、実用上はLLM を使用して要約する方法が一般的です。

圧縮後の構造

コンパクションにより、膨大な履歴が短い**サマリー（要約）**に集約されます。

• After Compaction

  [system][tools][compaction result][user]
                              ^
                     new message space available
  

4. Pi におけるコンパクションの実装

Pi は、対話が長くなりすぎた際に自動的または手動でコンパクションをトリガーします。

トリガーのタイミング

• 文脈ウィンドウの容量に近づいた際
  • Pi は自動的に古い内容を要約し、最新の作業は保持します。
• 手動実行
  • ユーザーが

    /compact

    コマンドを実行する場合もあります。
• エラー発生時
  • ターン中に文脈オーバーフローエラーが発生した場合にも処理されます。

保持するメッセージ数の目安

• Pi は構成可能なトークン予算に応じて、要約対象の範囲（カットポイント）を調整します。
  • デフォルト設定（2 万トークン）では、およそ 5〜20 回のターンに相当する内容を抽出・要約します。
• カットポイント以前のメッセージはすべてシリアライズされ、要約対象となります。

プロンプトの工夫

Pi のコンパクションプロンプトは「交代制勤務の引き継ぎブリーフィング」のような役割を果たします。

• システムプロンプトの変更
  • 通常：「あなたは優秀なコードアシスタントです」
  • コンパクション時：「あなたは文脈要約アシスタントです」
• ユーザーメッセージの内容
  • 「後で戻った際に利用する文脈として、この対話ブランチの構造化された要約を作成してください」と指示します。

プロンプトの特徴

プロンプトは以下のセクションを指定して実行されます：

1. 目標
2. 進捗状況
3. 重要な決定

• これらの要約はスタンドアロン（既存履歴なし）で生成されるため、不要なコストを増やさずに別の LLM モデルを使用可能です。
• 結果はセッション内の圧縮されたコンテキストエントリとして追加され、読みやすく、モデル切り替え時에도使用可能なプレーンテキストとして保存されます。

5. コンパクションとプロンプトキャッシング

LLM 提供者は、同一セッション内でのプレフィックス一致を検出し、コスト削減のためにプロンプトキャッシングを利用しています。

カッチングの有効性

• Compaction 前
  • 既存の履歴（

    [older history]

    ）と最新のターンが一致するため、キャッシュが有効化されます。

  [system][tools][older history][recent retained turns]
  <-------------------- cached prefix -------------------->
  

• Compaction 後
  • 「older history」部分が「summary」に置換されるため、プレフィックスが変化します。
  • キャッシュは無効化され、新しいリクエストからはキャッシュの恩恵を受けません。

コストへの影響

[system][tools][summary][recent retained turns][new user message]
<-- reusable -->^
                |
        first changed token
                |
                +-- この時点以降は全て再計算が必要

• 保持されたターン（

  recent retained turns

  ）のトークンは同じですが、それ以前のプロンプト構造が変化するため、キャッシュ再利用は不可能です。
• ただし、コンパクション後からの新しい対話開始からは、再びプロンプトキャッシングの恩恵を受けることが可能です。

6. 実験と拡張性

Pi のコンパクション機構は柔軟にカスタマイズ可能です。

• 異なる要約メカニズムをテストするには、Pi にカスタムコンパクションプロンプトを持つ拡張機能を作成することで検証できます。