- 外部ツール呼び出し時に発生する大量の生データがコンテキストウィンドウを急速に消費する問題を解決
- Claude Codeとツール出力の間に配置され、データを圧縮・フィルタリングして315KBを5.4KBに縮小（98%削減）
- サンドボックス構造により各実行を分離し、stdoutのみをコンテキストに含めることでログ・スナップショットなどの元データ流出を遮断
- SQLite FTS5ベースのナレッジベースでMarkdownコンテンツをインデックス化し、BM25ランキングとPorter stemmingを適用して正確なコードブロック検索を支援
- 同じ200Kトークン上限でセッション継続時間が30分から3時間に伸び、AIエージェントの効率的なコンテキスト管理が可能
問題点
- Claude CodeのMCPツール呼び出しは、各呼び出しごとに生データを200Kコンテキストウィンドウへ直接ダンプする
- Playwrightスナップショット56KB、GitHub Issue 20件で59KB、アクセスログ45KBなど
- 約30分の使用で全コンテキストの40%が消費される
- MCPは外部ツール利用の標準となったが、入力定義と出力データの両方がコンテキストを埋める構造的な限界がある
- 81個以上のツールが有効な状態では、最初のメッセージ前にすでに72%（143Kトークン）が消費されている
Context Modeの構造
- Claude Codeとツール出力の間に位置するMCPサーバーとして、生データを最小化して転送
- 各
execute呼び出しは分離されたサブプロセスで実行され、メモリや状態を共有せず独立して動作
- stdoutのみがコンテキストに含まれ、ログ・APIレスポンス・スナップショットなどはサンドボックス内に保持される
- 10言語ランタイムをサポート: JavaScript, TypeScript, Python, Shell, Ruby, Go, Rust, PHP, Perl, R
- Bunの自動検出によりJS/TS実行速度が3〜5倍向上
- 認証済みCLI（
gh, aws, gcloud, kubectl, docker）は環境変数継承方式で資格情報を安全に受け渡す
ナレッジベース（knowledge base）
indexツールがMarkdownを見出し単位に分割し、コードブロックをそのまま保持したままSQLite FTS5仮想テーブルに保存- 検索時にはBM25ランキングアルゴリズムを使い、単語頻度、逆文書頻度、文書長の正規化に基づいて関連性を計算
- Porter stemmingの適用により、“running”、“runs”、“ran”を同一語幹としてマッチ
search呼び出しでは要約ではなく正確なコードブロックと見出し階層を返すfetch_and_indexはURLを取得してHTMLをMarkdownに変換した後にインデックス化し、元ページはコンテキストに含まれない
パフォーマンス指標
- 11件の実シナリオ（テストトリアージ、TypeScriptエラー診断、git diffレビューなど）すべてで出力を1KB以下に維持
- Playwrightスナップショット: 56KB → 299B
- GitHub Issue（20件）: 59KB → 1.1KB
- アクセスログ（500件）: 45KB → 155B
- CSV分析（500行）: 85KB → 222B
- Gitログ（153コミット）: 11.6KB → 107B
- リポジトリ調査（subagent）: 986KB → 62KB（5回呼び出し vs 37回）
- セッション全体では315KB → 5.4KBに縮小し、セッション継続時間は30分 → 3時間
- 45分後に残るコンテキスト: 従来60% → 99%
インストールと利用方法
- Plugin Marketplace経由で自動ルーティングフックとスラッシュコマンドをサポート
- MCP専用インストールも可能
- Claude Codeを再起動後、すぐに利用可能
実際の変化
- 利用方法を変更せずにPreToolUseフックが自動で出力をルーティング
- サブエージェントは
batch_executeを基本ツールとして使用
- Bashサブエージェントは
general-purposeにアップグレードされ、MCPツールにアクセス可能
- 結果としてコンテキストウィンドウがもはや急速に埋まらず、同じトークンでより長いセッションを維持できる
開発の背景
- MCP Directory & Hubの運営中に、すべてのMCPサーバーが生データをコンテキストにダンプする共通パターンを発見
- CloudflareのCode Modeがツール定義を圧縮したことに着想を得て、出力データ圧縮の方向へ拡張
- Claude Codeセッションで6倍長く作業できることを確認後、MITライセンスでオープンソース公開
- GitHub: mksglu/claude-context-mode
1件のコメント
Hacker Newsのコメント
ここで提案されている FTS5インデックス手法 は正しいが、さらに一歩進めるべきだと思う
ツール出力には構造化データ（JSON、テーブル、設定）と自然言語（注釈、エラーメッセージ、docstring）が混在しているので、純粋なBM25 では性能が落ちる
私は似た問題を解くために、Model2Vec + sqlite-vec + FTS5 を組み合わせたハイブリッド検索器を作った。2つの検索結果を Reciprocal Rank Fusion(RRF) で統合することで、BM25の正確なキーワード一致とベクトル検索の意味ベース一致の両方を得られる
増分インデキシングも重要だ。私のインデクサは
--incrementalフラグで変更されたチャンクだけを再埋め込みする。15,800ファイル全体の再インデックスは4分、日次の増分更新は10秒未満だキャッシュの面でもこの方式は有利だ。同じクエリに対して圧縮された出力が 決定的(deterministic) なので、プロンプトキャッシュが安定して機能する
Context Modeのアーキテクチャに付け加えるなら、同じ検索器をPostToolUseフックとして実行し、出力が会話に入る前に圧縮されるようにすることだ
記事の著者です。数日前に GitHubリポジトリ を共有したところ、良いフィードバックをもらった。今回の記事はその アーキテクチャ説明 だ
核心のアイデアは、MCPツール呼び出しが吐き出す生データを200Kコンテキストウィンドウに入れる代わりに、Context Modeが 隔離されたサブプロセス を生成し、stdoutだけをコンテキストに渡すことだ。LLM呼び出しなしの純粋なアルゴリズムベースで、SQLite FTS5 + BM25 + Porter stemmingを使っている
最近は228スターと実際の利用データを得て、サブエージェントルーティング がどれほど重要かを実感した。Bashサブエージェントを汎用型へ自動アップグレードしてbatch_executeを使えば、生出力でコンテキストを埋め尽くさずに済む
なぜ mcp-cliモード を使わないのかわからない。私は wener-mcp-cli でクローン版を作ってある
すばらしい仕事だ。コンテキストウィンドウ管理 にはまだ改善の余地が大きいと思う。たとえばモデルが何度か試行した末に正解にたどり着いたなら、失敗した試行をコンテキストから取り除く バックトラッキング のような手法が有用そうだ
“Success!”で終わるなら最後の行だけ見ればよい。失敗時はエラーメッセージだけ読む。ローカルモデルでログを要約してクラウドモデルに渡す実験もしている。最新技術ではないかもしれないが、自分の環境ではうまく動いているこの記事を見て、自分が Claude Codeのトークン使用量 をまったく把握していないと気づき、今朝 claude-trace というCLIを作った
~/.claude/projects/*/*.jsonlを解析して、セッション、ツール、プロジェクト、タイムラインごとの使用量とコスト（キャッシュ読み取り/生成を含む）を分析するContext Modeが出力圧縮をうまく解決するなら、これは 計測レイヤー として変更前後の消費を可視化する
MCPではなく CLIアプリ を使えば、多くのトークン消費は減らせる。たとえば GitHub CLI はMCPよりはるかに少ないトークンで同じことができる
フックが攻撃的すぎるように感じる。すべてのcurl/wget/WebFetchを遮断してサンドボックスで56KBスナップショットを作るのはよいが、単なる
curl api.example.com/healthのように200バイトしか必要ない場合にはやりすぎだ153個のgitコミットを107バイトに圧縮すると、モデルは完璧な抽出スクリプトを書けない限りデータを見られない。誤ったコマンドを書けば必要な情報が失われる
ベンチマークはモデルが常に正しい要約コードを書くと仮定しているが、実際にはそうではない
悪くはないが、精度低下 と ハルシネーションのリスク がある。不完全なデータや誤った抽出ロジックのせいで、Claudeが間違った結論を出す可能性がある。MCPが優れた抽出スクリプトと検索クエリの両方を書けるほど賢いことを前提にしている。情報保持は実際かなり大きな問題だと思う
圧縮率は印象的だが、圧縮されたコンテキスト でもモデルが同等品質の出力を出せるのか気になる。セッションを30分から3時間に延ばせても、2時間時点での推論品質が維持されてこそ意味がある
esafakが言う キャッシュの経済性 も重要だ。プロンプトキャッシュがうまく効けば、冗長なコンテキストも事実上無料になる。しかし圧縮がキャッシュの連続性を壊すなら、かえってコストが増える可能性もある
さらに根本的な問題は、ほとんどのMCPツールがSELECT *で全データを取ってくることだ。要約とドリルダウンをサポートする プロトコル設計の問題 である
80個以上のツールをコンテキストに入れる必要があるのか疑問だ。コンテキストは金のように貴重で、問題と無関係なものを多く入れるほど結果は悪くなる。データ圧縮より サブエージェントの分離 のほうがよいアプローチだ