※ gemini-cliの場合はツール使用のためにmcpサーバを立てる必要があります
AIとのチャット履歴の一部だけを要約してクリーンな状態にしたり、特定のターンからチャットを再開したいと思ったことはありませんか？
- ノイズの蓄積: 結論が出た設計過程や、試行錯誤の履歴がノイズとなり、現在のフェーズ（例：実装）に必要な「重要なコンテキスト」を埋もれさせます。
- コストとレイテンシの増大: 履歴全体をプロンプトに含めることで、トークンコストが増加し、応答速度が低下します。
この課題を解決するため、我々は、ユーザーが要約方針を決定し、エージェントがその安全性を検証する新しい機能「会話履歴の部分圧縮」を開発しました。本記事では、この機能の設計思想と、マルチエージェントによる検証付きフローを解説します。
🏗️ 会話履歴の部分圧縮：設計思想
このシステムの核心は、「ユーザー主導の柔軟性」と「エージェントによる安全性の担保」を両立させるハイブリッドモデルです。
従来の課題：コントロールの欠如とリスク
従来の要約ツールでは、要約の方針（例：「特定の制約だけは残す」）や文字数をユーザーが細かく指示・決定することができませんでした。その結果、システムが機械的に要約した際に、後続のタスクに不可欠な情報が欠落するリスクがあり、生成された要約の信頼性が低いという問題がありました。
解決策：ユーザー主導とエージェント検証の導入
pipeは、この課題を解決するため、以下の役割分担を確立しました。
- ユーザーによる主導権の回復: ユーザーは、圧縮したい履歴の範囲を指定するだけでなく、要約に含めるべき重要事項や、除外したいノイズに関する具体的な方針をCompresser Agentに指示できます。
- マルチエージェントによる検証: Compresser Agentがユーザーの方針に基づいてドラフトを生成した後、Verifier Agentが起動します。Verifier Agentは、元の会話履歴全体を参照し、ユーザーの指示を尊重しつつも、「後続の対話に不可欠なクリティカルな情報が欠落していないか」を客観的にチェックすることで、要約の安全性を保証します。
このプロセスにより、ユーザーは自分の意図を反映させた品質保証付きのクリーンなコンテキストを作成できます。
⚙️ 実装フロー：Compresser と Verifier の協調動作
部分圧縮機能は、以下のフローチャートに示す通り、Compresser AgentとVerifier Agentが連携して要約の品質を担保する「検証ループ」によって成り立っています。
圧縮プロセスをフローチャートにするとこの様な形になります。
バックアップは残しますが、事前にフォークしてから実行することで元の会話を見直すことが容易になります。開発での用途よりも長編小説でのブレストの圧縮と継続の様な使い方の方が向いている気もしています。
QiitaではUnsupported markdown: listが出てしまうので、[こちら](Unsupported markdown: list)で見てください。
1. 設計フェーズの完了 (ターン 1-50)
ユーザーは設計に関する長い会話（潜在的なノイズを含む）を完了し、圧縮ゲートに移行します。ユーザーは、設計フェーズの結論を圧縮し、実装フェーズへ移行することを要求します。
2. Compresser Agentによるドラフト作成 (D, E, F)
Compresser Agentは、ユーザーの要求を受け、まず Tool: read_session_turns(1-50) で対象履歴を読み込みます。この際、ユーザーから受けた要約の方針を最大限に考慮し、要約ドラフトを生成します。
3. Verifier Agentによる品質保証と検証ループ (G, H, I)
このステップが、安全性を担保する中核です。
-
検証依頼: Compresser Agentは、生成した要約ドラフトを
Tool: create_verified_summary(Summary Draft)を通じて Verifier Agent に渡します。 - 自律的検証: Verifier Agentは、元の全履歴を参照し、ドラフトが「重要な情報を見落としていないか」をチェックします。これは、後続のタスクを安全に実行するために必要な最小限のコンテキストを自律的に判断し、品質を保証するプロセスです。
- ループ: 検証の結果、重要な情報欠落 (NO) が見つかった場合、フィードバックとともに Compresser Agent に戻り、ドラフトの再生成が行われます。検証が OK (YES) になるまで、この検証ループが繰り返されます。
4. ユーザー承認と履歴の置換 (J, K, L, N)
Verifier Agentから返却されたVerified Summaryを、Compresser Agentはユーザーに提示し、承認を求めます。
-
ユーザー承認:
Tool: replace_session_turns(1-50, Verified Summary)を呼び出し、長い履歴を短い要約に置換します。これにより、トークンコストを抑え、クリーンなコンテキストで実装フェーズへ移行します。 - ユーザー拒否 (M): 圧縮プロセスは終了し、履歴は維持されます。
🛣️ 関連機能：ターン指定のフォーク機能
部分圧縮機能が「過去を整理する」機能であるのに対し、同時に実装されたターン指定のフォーク機能は「未来を分岐させる」機能です。
これは、Gitのブランチ機能と同様の柔軟性を提供します。例えば、「ターン 30で決めた設計Aに懸念があるため、ターン 20 の時点から会話をやり直して設計Bを検討したい」といった要望に対し、現在の履歴を維持したまま、過去の任意のターンから新しい会話ブランチを作成できます。これにより、試行錯誤や設計のロールバックが容易になります。
まとめ
「会話履歴の部分圧縮」と「ターン指定フォーク機能」は、長期対話セッションにおけるコンテキスト管理の信頼性、効率性、そして柔軟性を劇的に向上させます。
| 機能 | 目的 | 効果 |
|---|---|---|
| 部分圧縮 | ユーザー主導による履歴のクリーンアップと安全性の確保 | トークンコスト削減、ノイズ除去、推論精度の維持 |
| ターン指定フォーク | 過去の意思決定に戻る柔軟な試行錯誤を可能にする | 設計のロールバック、複数案の同時検討の容易化 |
今日はこの言葉で締めましょう
生殺与奪の権を他人に握らせるな