AIエージェント時代のコンテキスト圧縮ゲートウェイ設計

エージェント開発を本番運用に載せると、最初に破綻しやすいのは精度ではなく経済性です。ツール数、参照ドキュメント、会話履歴が増えるほど、推論品質より先にトークンコストとレイテンシが悪化します。

今週のHacker Newsでも「Context Gateway」が話題になりましたが、現場で有効なのは、検索層とモデル実行層の間にコンテキスト圧縮ゲートウェイを置く設計です。これはプロンプト小細工ではなく、運用境界を明示するための制御プレーンです。

なぜ“そのままRAG”が続かないのか

よくある構成は次の流れです。

top-k検索でチャンクを取得
会話履歴を付与
ツールスキーマを付与
全文をLLMへ投入

この構成は検証段階では速いのですが、本番では以下の問題が顕在化します。

トークン増加が非線形：ツールやメモリ源が増えると、文脈量が掛け算で膨らむ
重要情報の埋没：類似した説明や重複段落が本質的な証拠を押し流す
説明責任の欠如：なぜその文書を採用し、なぜ除外したかを後から示せない

ここを分離しない限り、品質最適化とコスト最適化が常に衝突します。

実装すべき5段階パイプライン

1. 受け入れ正規化（Intake normalization）

投入コンテキストを共通エンベロープへ変換します。

source_type（doc/chat/tool/log）
risk_class（public/internal/restricted）
freshness（更新時刻）
owner と lineage

この時点で後続のポリシー判定が可能になります。

2. 関連度＋新規性スコア

類似度だけでなく、**新規性（novelty）**を加えます。既選択チャンクと同内容ならスコアを下げ、冗長な再掲を抑制します。

3. 圧縮変換

順序を固定した決定的変換を適用します。

定型ヘッダ・重複文の除去
長大ログのイベント要約化
表のキー値化（精度を落とさない範囲）
法務/規約などは原文保持

パイプラインをバージョン管理し、回帰時に再実行できるようにします。

4. ポリシーゲート

ハードルールを必ず機械判定します。

リスク階層別の最大トークン上限
PII/機密識別子の投入禁止
高影響タスクの引用必須

違反時は黙って切り詰めず、機械可読な拒否レスポンスを返すことが重要です。

5. 監査イベント出力

最低限、次を記録します。

採用/除外チャンクID
圧縮前後トークン数
ポリシー判定結果
最終モデルルーティング

この「フライトレコーダー」が障害解析の土台になります。

予算配分の初期値

1リクエストあたりの目安配分：

システム/ポリシー: 10〜15%
タスク入力: 15〜20%
取得コンテキスト: 35〜45%
ツール定義・例: 15〜20%
応答余白: 10〜15%

多くのチームは取得コンテキストに寄せすぎ、応答余白不足で回答品質を落とします。

30日導入チェックリスト

RetrieverとLLM Routerの間にGatewayを挿入
チャンクlineage IDを永続化
用途別圧縮プロファイル（analysis/codegen/support）を定義
上限超過をハードエラー化
圧縮率・拒否率・成功タスク単価を可視化
1週間はシャドー運用（判定のみ記録）
チーム単位で段階的に強制化

失敗パターン

「全部まとめて要約」：出典と責任境界が消える
「コンテキスト窓が広いから不要」：負債を先送りするだけ
「コスト最適化だけ重視」：必要根拠まで圧縮し、もっともらしい誤答を増やす

観測すべきKPI

用途別トークン削減率
p50/p95レイテンシ改善
高リスクタスクでの引用充足率
圧縮導入後の誤答修正率
採用された成果物1件あたりの推論コスト

まとめ

コンテキスト圧縮ゲートウェイは、API Gatewayと同じく“後から足すほど高くつく基盤”です。要点は一つ、コンテキスト選別とモデル実行を分離し、その境界を可観測にすること。これができると、コスト・速度・統制が同時に改善し始めます。