ハクソク

世界を動かす技術を、日本語で。

コンテキストウィンドウの無駄遣いをやめよう – Claude CodeにおけるMCP出力を98%削減した方法

2026年2月28日原文(mksg.lu)

概要

  • Claude CodeのMCPツール利用時、 生データ出力がコンテキストを急速に消費
  • Context Modeで 出力データを最大98%圧縮 し、長時間セッションが可能
  • サンドボックス実行で 安全かつ効率的な外部ツール連携
  • 知識ベースはBM25検索・コードブロック保持 で高精度検索
  • 導入・運用も簡単、オープンソースで公開中

Claude CodeのMCPツールとContext Modeの課題

  • MCP（Multi-Component Protocol）ツール はAIエージェントが外部ツールを利用する標準手段
  • ツール呼び出しごとに 生データがコンテキストウィンドウを圧迫
    • 例：Playwrightスナップショット 56KB
    • GitHub Issueリスト 20件で59KB
    • アクセスログ 45KB
  • 30分の作業で 40%のコンテキストが消費
  • ツール定義と出力の両方がコンテキストを埋める構造
    • 81以上のツール有効時、 最初のメッセージ前に143Kトークン（72%）消費
  • Cloudflareは Code Modeでツール定義99.9%圧縮 を実現
  • しかし 出力側の圧縮問題は未解決 だった

Context Modeの仕組み

  • Context ModeはClaude CodeとMCPツール出力の間に立つサーバ
  • 出力データをサンドボックスで最小限に圧縮
    • 例： 315KB→5.4KB（98%削減）
  • 各ツール実行は 独立したサブプロセス で実行
    • プロセス境界で 他スクリプトの情報漏洩リスクなし
    • サブプロセスは stdoutのみを会話コンテキストに投入
    • 生ログ・APIレスポンス・スナップショットは外部に漏れない
  • 10言語ランタイム （JavaScript, TypeScript, Python, Shell, Ruby, Go, Rust, PHP, Perl, R）対応
    • Bunによる JS/TS高速実行（3-5倍）
    • 認証CLI対応 （gh, aws, gcloud, kubectl, docker）も安全

知識ベースの仕組み

  • インデックスツール でMarkdownコンテンツを見出し単位で分割・コードブロック保持
  • SQLite FTS5仮想テーブル で全文検索
  • BM25ランキング で関連度スコア付け
    • 単語頻度・逆文書頻度・文書長正規化を考慮
    • Porterステミング で活用語も同一扱い
  • 検索時は 実データ（コードブロック＋見出し階層）を返却
  • fetch_and_index でURLのHTMLもMarkdown化・分割・インデックス
    • 生ページはコンテキストに入らない

圧縮効果・パフォーマンス

  • 11の実シナリオで検証
    • テストトリアージ、TypeScriptエラー診断、git diffレビュー、依存監査、APIレスポンス処理、CSV分析など
    • 各出力1KB未満
  • 圧縮例
    • Playwrightスナップショット： 56KB→299B
    • GitHub Issues（20件）： 59KB→1.1KB
    • アクセスログ（500件）： 45KB→155B
    • CSV（500行）： 85KB→222B
    • Gitログ（153コミット）： 11.6KB→107B
    • リポジトリ調査（サブエージェント）： 986KB→62KB（5回呼出し）
  • 1セッションで315KB→5.4KB
  • セッション持続時間： 30分→3時間
  • 45分後の残コンテキスト： 99% （従来は60%）

導入方法

  • 2通りの導入方式
    • Plugin Marketplace経由： 自動ルーティング・スラッシュコマンド対応
      • /plugin marketplace add mksglu/claude-context-mode
      • /plugin install context-mode@claude-context-mode
    • MCPツール単体導入
      • claude mcp add context-mode -- npx -y context-mode
      • Claude Code再起動で完了

実際に変わること

  • 作業フロー自体は変わらない
    • Context Modeが PreToolUseフックで自動的にツール出力をサンドボックス経由化
    • サブエージェントは batch_executeをメインツールとして学習
    • Bashサブエージェントは 汎用型にアップグレード、他MCPツール利用可能
  • 実質的な違い：コンテキスト枯渇が起きなくなる
    • 30分で詰まっていたセッションが 3時間継続可能
    • 200Kトークンを効率的に活用

開発背景・オープンソース情報

  • MCP Directory & Hub運営者による開発
    • 1日10万件超のリクエスト を監視
    • 全てのMCPサーバで生データがコンテキストに流入するパターン を確認
    • CloudflareのCode Mode記事 で定義圧縮の発想を得る
    • 出力圧縮の必要性を痛感し自分用に開発→オープンソース化
    • 6倍長く作業継続できる効果を実感
  • MITライセンス、GitHubで公開
    • https://github.com/mksglu/claude-context-mode
  • 作者：Mert Köseoğlu（Senior Software Engineer, AI consultant）
    • x.com/mksglu
    • linkedin.com/in/mksglu
    • mksg.lu

Hackerたちの意見

ここで作者です。数日前にGitHubのリポジトリを共有したんだけど（https://news.ycombinator.com/item?id=47148025）、すごく良いフィードバックをもらったよ。これがアーキテクチャを説明するための文書です。核心的なアイデアは、すべてのMCPツールコールが生データを200Kのコンテキストウィンドウにダンプすること。コンテキストモードは孤立したサブプロセスを生成して、stdoutだけがコンテキストに入るようになってる。LLMコールはなしで、純粋にアルゴリズム的なアプローチ：SQLiteのFTS5を使ってBM25ランキングとポーターステミングを行ってる。前回の投稿から228スターを獲得して、実際の使用データも見えてきた。最も驚いたのは、サブエージェントのルーティングがどれだけ重要かってこと。Bashサブエージェントを自動で一般的なものにアップグレードして、raw outputでコンテキストを埋めるのではなく、batch_executeを使えるようにすること。ソースはこちら：https://github.com/mksglu/claude-context-mode アーキテクチャに関する質問があれば、喜んで答えるよ。

└

本当に興味深いし、絶対に試してみるよ、ありがとう！点をつなげると（ちゃんとつながってるか確認してほしいんだけど）、コンテキストモードはMCPのコンテキスト使用には全く関係ないってことだよね？代わりに、MCPツールをリファクタリングしたり排除したり、可能な限りMCPにコンテキストモードに似た概念を適用することを提案してるのかな？コンテキストモードは「いいえ」だとしても、非常に価値があると思うし、理解できてるか確認したい。上記についての考えも聞きたいな。私はすべてのClaudeの表面で動作するいくつかのMCPを書いてるから、通常の「CLI！」はあまり有効な答えではないんだ（ただし、コード実行があるときは時々そうなるけど）... 編集：タイプミス

└

あなたのテクニックはキャッシュを壊すの？ 編集：ありがとう。

これを試すのが楽しみ！これは実質的に「事前圧縮」みたいなもので、あらかじめ何が関連性があるかを決めてるってこと？それとも、すべてをダンプしたときに偶然拾ったユーティリティ関数みたいなエッジケースがあるのかな？

└

そうだね、基本的にはプレ圧縮だよ。重要な違いは、何も捨てられないこと。フル出力が検索可能なFTS5インデックスに保存されるから、モデルが要約で見逃した詳細が必要だと気づいたら、それを検索できるんだ。最初から「何が関連してるかを決める」んじゃなくて、「今は要約をくれ、後で具体的なことを聞きに戻るから」って感じだね。

いい仕事してるね。コンテキストウィンドウ管理に関しては、もっと簡単にできることがある気がする。バックトラッキングも、コンテキストの膨張や圧縮を避けるための有望な方向性だと思う（つまり、モデルが正しいことをするのに何度か試行錯誤する場合、一度正しいことをしたら、失敗した試行をコンテキストから削除する）。

└

90年代後半を思い出すけど、htmlやsqlの代わりにコーディングエージェントが登場した感じ。今回は、多くの人がソフトウェアエンジニアリングに慣れてるから、claudeのコードを使って最適化を見つけるのが簡単なんだよね。アイデアが浮かんだら、AIと一緒に詳細な設計を作ってもらって、それを開発させるって感じ。

└

同意する。コンテキストと圧縮の細かい制御がもっと欲しいな。セッションの途中でデバッグに時間をかけたら、バグを修正した後は、それに関連するものをコンテキストから削除して、以前のように続けられるべきだよね。（今のところ、IDEによっては手動でやるのがかなり面倒だし、その後他のタスクでエージェントと作業した場合にそれを切り取ることができるものは知らない。）エージェント自身も自分のコンテキストを管理すべきだと思う。例えば、たくさんのログ情報をコンテキストにダンプするツールを使っている場合、そのログは1、2回のプロンプトの後に削除されるべきだよね。コンテキストは自由に操作できるものとして考えるべきで、単にスタックのように追加や削除しかできないものではないと思う。

└

もしかしたら「両方ともあり」ってのが正しい答えかもしれないけど、サブエージェントもその問題に使えるよね。つまり、何かが予想通りに進まないときに、サブエージェントをフォークして問題を解決し、答えを持って戻ってくるって感じ。自分自身のメモリを消去して、過去のバージョンに戻るモデルを想像するのは面白いけど、その時には厄介な問題の答えも持ってるっていう。

└

完全に同意する。正しい道が見つかれば、失敗した試みはただのノイズだよね。リトライパターンを自動検出して、最終的な動作バージョンに絞り込むのは、特にlintやコンパイルの修正みたいな明確なケースでは、かなり実現可能に感じる。

これを使っててすごく満足してるし、チームにもインストールを勧めたよ。トークンの使用量がかなり減った。

└

ありがとう、そう言ってもらえると嬉しいよ！君のチームにうまくいってるみたいでよかった。

Hacker Newsで議論の続きを見る