すべてのLLMにはコンテキストウィンドウ — 一度に処理できるトークンの固定数があります。GPT-4oは128Kが上限です。Claudeは200K。Geminiは1M。これらの数字は大きく聞こえますが、実際にはツール呼び出し、コードブロック、詳細な指示を含む忙しい会話では、30-40回の交換で200Kトークンを使い果たす可能性があります。
壁にぶつかると、ほとんどのプラットフォームは単に失敗します。会話が停止します。1時間かけて構築したコンテキストを再説明しながらやり直します。これは会話型AIで最もフラストレーションのたまる体験です。
JieGouはこれを反復的会話コンパクションで解決します。
数字で見る問題
典型的なパワーユーザーセッションを考えてみましょう：
- システムプロンプト：約2,000トークン
- 各ユーザーメッセージ：約200トークン
- 各アシスタントレスポンス：約800トークン
- ツール呼び出しと結果：ラウンドあたり約500トークン
40回の交換後、おおよそ60,000トークンになります。128Kモデルでは、既にキャパシティの50%に近づいています。長いドキュメントやコードファイルをいくつか追加すると、会話が「終わった」と感じるずっと前に制限に達します。
素朴な解決策 — 古いメッセージの切り捨てや単に継続を拒否すること — はどちらも貴重なコンテキストを失います。
反復コンパクションの仕組み
JieGouはすべての会話のトークン数をリアルタイムで監視します。使用量が**モデルのコンテキストウィンドウの80%**を超えると、コンパクションシステムが起動します。
プロセスは以下の通りです：
1. すべてのメッセージの合計トークン使用量を測定
2. 使用量 > 80%しきい値 → コンパクションをトリガー
3. 古いメッセージを選択（最新のN回の交換以外すべて）
4. 選択されたメッセージの構造化サマリーを生成
5. 選択されたメッセージをサマリーで置き換え
6. サマリーをシステムメッセージとして注入
7. サマリー + 最近のメッセージで会話を継続サマリーは曖昧な段落ではありません。明確に定義されたセクションを持つ構造化されたドキュメントです：
サマリー構造
## 主要な決定
- ユーザーストアにMongoDBではなくPostgreSQLを使用することに決定
- パブリックAPIにGraphQLではなくRESTで合意
## 未解決の質問
- 検索結果のキャッシュ戦略をまだ決定する必要がある
- モバイルクライアントの認証フローは未定
## アクションアイテム
- [ ] 合意されたERDに基づいてデータベーススキーマを作成
- [ ] 新しいテストフレームワークでCIパイプラインをセットアップ
## コンテキスト
- 在庫管理のためのB2B SaaSプラットフォームを構築中
- ターゲットローンチ日はQ3 2026
- チームは4人のエンジニア、全体でTypeScriptを使用この構造により、モデルは何が議論されたかの曖昧な記憶ではなく、決定と意図を保持します。
コンパクション中に何が起こるか
コンパクションがトリガーされると、システムは：
-
境界を特定します。 最新のメッセージ（通常、最後の4-6回の交換）はそのまま保持されます。その境界より前のすべてがコンパクションの対象です。
-
サマリーを生成します。 コンパクションプロンプトがモデルに決定、未解決の質問、アクションアイテム、文脈的事実を抽出するよう指示します。モデルは古いメッセージを読み、構造化サマリーを生成します。
-
古いメッセージを置き換えます。 元のメッセージはアクティブコンテキストから削除され、サマリーを含む単一のシステムメッセージに置き換えられます。
-
参照を保持します。 以前のメッセージで言及されたファイル名、変数名、URL、その他の具体的な参照はサマリーにそのまま保持されます。これにより、モデルが20メッセージ前に議論された特定のファイルパスやエンドポイントを「忘れる」という一般的な障害モードを防ぎます。
-
必要に応じて反復します。 会話がさらに成長し続ける場合、後続のコンパクションはゼロから新しいサマリーを作成するのではなく、既存のサマリーを更新します。これにより「サマリーのサマリー」の劣化問題を回避します。
ユーザー体験
ユーザーの視点からは、コンパクションはほぼ見えません。発生時：
- 会話タイムラインに小さな**「コンテキストがコンパクションされました」**インジケーターが表示されます
- 会話は中断なしに継続します
- モデルのレスポンスは一貫してコンテキストを認識し続けます
- 以前のメッセージは参照のためにUIに表示されたままです（LLMコンテキストから削除されますが、表示からは削除されません）
ユーザーからのアクションは不要です。「新しい会話を開始してください」プロンプトも手動の要約もありません。
なぜ80%か？
80%のしきい値は意図的です。以下のための十分な余裕を残します：
- コンパクションサマリー自体（トークンを消費します）
- ユーザーの次のメッセージとモデルのレスポンス
- 次の交換でのツール呼び出しや関数出力
早すぎるトリガーはコンテキスト容量を無駄にします。遅すぎるトリガーはモデルがスペース不足になった時に生成途中で失敗するリスクがあります。80%はこれらの懸念のバランスを取ります。
すべてのモデルで動作
コンパクションはモデルのコンテキストウィンドウに自動的に適応します。会話の途中でClaude Sonnet（200Kコンテキスト）からGPT-4o-mini（128Kコンテキスト）に切り替えると、システムはしきい値を再計算し、より小さいウィンドウに収めるために即座のコンパクションをトリガーする場合があります。
これにより以下が可能です：
- 複雑な探索のために大きなコンテキストのモデルで会話を開始
- 迅速なフォローアップのためにより小さく高速なモデルに切り替え
- 手動介入なしに会話が継続
コンパクション + Coding Agent
Coding Agentワークフローステップは同じコンパクションシステムを使用します。30ターン以上のファイル読み取り、編集、テストを必要とする複雑なコーディングタスクは、コンパクションから大きな恩恵を受けます — エージェントは会話がモデルの生のコンテキスト制限を大幅に超えても、目標と進捗を保持します。
コンパクション + セッションブランチ
会話をブランチすると、ブランチは現在のコンパクション状態を継承します。これにより、深くコンパクションされた会話からブランチでき、両方のブランチが同じコンテキスト基盤で開始します。
利用可能性
反復的会話コンパクションは無料ティアを含むすべてのプランで利用可能です。サポートされているすべてのLLMプロバイダー — Anthropic、OpenAI、Google、任意のBYOK設定で動作します。
設定は不要です。必要な時に自動的に起動します。
お試しください
長い会話を始めてみてください。ドキュメントを貼り付けてください。フォローアップの質問をしてください。通常1つのセッションで試みる限界を押し広げてください。JieGouがスレッドを生かし続けます。