Prompt Compression

プロンプト圧縮が必要なのはいつですか？通常の会話では不要ですか？

1回または短い会話なら通常は不要です。必要性は「蓄積」から生じます：会話が多くのラウンドを経た後、または最初から大量の背景文書を読み込んだ場合、または複数ステップのエージェントタスクを実行している場合、以前のすべてのメッセージをコンテキストに保持すると二つの問題が生じます：コンテキストウィンドウ上限に達すること、達しなくても不要な古いメッセージのトークンコストを払い続け遅延が増えること。

シンプルな基準：プロンプトがすでに30〜50Kトークンを超えているか、エージェントタスクが多くのラウンドを想定しているなら、圧縮戦略を考える価値があります。1つの質問または2ターンのやり取りなら、圧縮の限界収益はほぼゼロです。

圧縮要約を書く際、重要な情報を失わないようにするにはどうすればよいですか？

いくつかの実践的な原則があります。第一に、決定と結論を保持し、導出過程は省略します。PostgreSQLかMongoDBかを長く議論してPostgreSQLに決めたなら、「理由XでPostgreSQLに決定」は保持し、比較全体のスレッドは不要です。第二に、制約と限定を保持します。以前Claudeに伝えた「1000字以内」「JSON形式で出力」といったものは、その後すべての出力に影響するため、原文のままか要約に完全に含める必要があります。

第三に、削除を後悔するかもしれないかを自問します：セクションを圧縮する前に「このセクションの元の詳細が後で必要になるかもしれないか」と問いかけます。答えが「確信なし」なら保持します。圧縮の目標は確実に不要なものを除去することであり、すべてを可能な限り短くすることではありません。

毎回手動でやらなくても済む、プロンプト圧縮のツールや自動化方法はありますか？

いくつかの一般的な自動化アプローチがあります。最もシンプルなのはスライディングウィンドウ：直近のNターンのみ完全に保持し、それ以前はすべて切り捨てます。最も粗い方法ですが、文脈の連続性をそれほど必要としないタスクには十分です。

一段進んだのはAI支援による要約：コンテキストが特定の長さに達したら、以前の部分を自動的にClaude（または軽量なモデル）に送って数行の要点に凝縮させ、そのセクションを要約に置き換えます。効果は高いですが、要約ごとに追加のAPIコールが必要でコストが発生します。より複雑なシステムはベクターデータベース（RARアーキテクチャ）を導入します：会話履歴と文書をベクターとして埋め込み、必要なときに関連チャンクだけを取得します。

上級：エージェントシステムでのプロンプト圧縮戦略は、通常の会話とどう違いますか？

エージェントシステムの圧縮は通常の会話よりはるかに複雑です。なぜならエージェントは実行中に大量のツール呼び出しログ・中間結果・エラー・再試行記録を蓄積するからです。

エージェント特有の考慮事項：第一に、ツール出力の選択的保持——エージェントがデータベースを照会して500行を受け取り、最終的に意思決定に10行を使った場合、圧縮後の表現は「意思決定に使った10行+決定の結論」であり、500行の生データではありません。第二に、解決済み・未解決エラーの区別：解決済みのエラーは「Xを試みて失敗、Yを使って成功」に圧縮可能。未解決のエラーは後続ステップ計画に影響するため原文のままにしておく必要があります。第三に、長期間動くエージェントには設計段階から定期的な圧縮メカニズムを組み込む必要があります。