Claude Codeに噂の『98%トークン削減』context-modeを導入して実測した結果

こんにちは。梅雨で外に出る気が起きない日は、気になっていた道具を机の上で落ち着いて測るのにちょうどいいですね。今回は「コンテキスト窓を98%削減する」と謳う MCP プラグイン（Claude Code に後から機能を足す拡張）の context-mode を、使い捨ての隔離環境で ON と OFF に切り替えて測りました。

結論から書きます。Claude Code では、削減どころかコンテキストが増えました。あるタスクでは +50.6%、プラグインが本来得意とするはずの巨大データ取得でも +46% で、しかも約2倍遅くなっています。原因は、Claude Code に最初から入っている純正ツールが元から賢く、節約する余地がそもそも無いことです。「98%削減」は嘘ではありませんが、賢い純正ツールを持たない前提の数字だと私は見ています。なので、これから入れる人は一旦待ち、既に入れている人は自分の環境で測ってみるのがよい、というのが今回の結論です。

検証日は2026年6月11日（2026-06-11）、対象は context-mode v1.0.162 と Claude Code 2.1.173 です。本文の比較数値はすべて当環境での実測値です。

AIコーディングを毎日していると、いちばん欲しくなるのは「コンテキスト窓（AI が一度に覚えておける作業メモの量）」の余裕です。長い作業をしていると、いつの間にか窓がいっぱいになって、要約が走って、文脈が薄まる。あの感覚、わかってくれる人は多いはずです。

そんな折に見つけたのが「コンテキスト窓を98%削減するMCPプラグイン」という触れ込みのツールでした。仕組みとしては、Web取得やファイル読み込み・API応答といった「重い生データ」を別プロセスで処理して、要約や検索ヒット部分だけを本体（LLMLLM（大規模言語モデル）大量の文章で学習し、人のように文章を読み書きできる大きな AI のモデル。詳しく →）に返す、というもの。315KB → 5.4KB のような劇的な削減例も掲げられています。効くなら今すぐ入れたい、というのが正直な気持ちでした。

でも、homelab を運用していると痛感するのですが、謳い文句と実機の挙動は別物です。だから今回も、飛びつく前にきちんと測ることにしました。この「クレームを鵜呑みにせず、自分の経路で測る」という姿勢は、以前 トークン60〜95%削減を謳う Headroom とは何者か を整理したときと同じです。削減率を大きく掲げるツールは、まず「どんな前提の数字なのか」を疑うところから始めると、損をしにくくなります。

効果を測る前の段階で、私はこのプラグインを本番環境に入れたくありませんでした。理由はセキュリティです。

このプラグインは「sandboxed code execution（サンドボックス化されたコード実行）」を謳っていますが、ソースを読むと、その「サンドボックス」の実体は一時フォルダを作業場所にして、環境変数を少し掃除するだけでした。OSレベルの隔離（seccomp・名前空間分離・権限降格など）は一切なく、実行されるコードはこちらの権限そのままで動きます。さらに、URL取得機能に「社内LANのアドレスにもアクセスできてしまう」穴（外部から内部ネットワークを叩ける、いわゆるSSRF）があることも分かりました。

この見立ては自分ひとりの判断にせず、3つのAI（Claude / GPT-5.5系 / Gemini系）に独立してソースをレビューさせ、全員が「高価値な資産がある環境への常時導入は非推奨」で一致しました。未監査のLLMツールを評価するときに、まず隔離環境で安全性から確かめるという進め方は、Claude Code 公式セキュリティプラグインを実機検証 したときと同じ流儀です。なお、安全面の指摘は対象バージョン時点のソース監査に基づくもので、今後のバージョンで設計が変わる可能性はあります。攻撃の具体的な再現手順は、原理と結果だけに留めて意図的に書いていません。

そこで、効果測定は AIサーバー上に用意した次のような使い捨ての隔離環境で行いました。

• 使い捨てDockerコンテナ（Node 22ベース）。非rootユーザー・使い捨てのホームディレクトリで動かし、ホスト側の本物のホームは一切マウントしない。
• ネットワークの檻（egress制限）：コンテナ専用のサブネットから「社内LAN（プライベートIP帯）宛の通信を遮断、インターネットだけ許可」というルールを、ホスト側のファイアウォールに置きました。コンテナの中に置くと、信用していないコード自身が檻を壊せてしまうからです。プラグイン側の厳格モード（fetchを内部に向けさせない設定）も併用。
• 檻の実証：実際にコンテナから社内サービスへ接続を試みてタイムアウト（＝遮断）、外部APIには到達することを事前確認してから測定に入りました。
• 認証：Claude Code を自分のサブスク経由のトークンで接続。トークンはファイル経由で受け渡し、値がログやコマンド履歴に残らないようにし、検証後に無効化しました。

ポイントは、安全性をプラグインの設定に頼らず、外側のOS隔離で担保したことです。ここを丁寧にやったので、安心して数字に集中できました。

比較の物差しはシンプルにしました。Claude Code を非対話モード（人が操作せず、指示を渡して最後まで走らせる使い方）で動かし、出力のJSONから「モデルに入力されたトークンの総量＝入力 + キャッシュ生成 + キャッシュ読み出し」を取り出します。これが「コンテキスト窓をどれだけ使ったか」の実量です。

そのうえで、まったく同じタスクを context-mode の ON と OFF で1回ずつ走らせ、トークン量・ターン数・所要時間・（名目）コストを並べました。モデルは同一（Claude 系の標準モデル）、プロンプトも同一です。

最初のタスクは「約1.6MBのJSON（2万件のレコード）の中から、特定のフィールドが既定値でないたった1件を見つけて答える」。どちらの設定でも正解（同じレコード）にたどり着きました。

ONの方が約50%多くコンテキストを使いました。 削減どころか増加です。

理由はシンプルでした。context-mode を入れると、そのツール群の定義やセッション開始時の指示注入が固定の「税」として乗ります（今回は約23,000トークン増）。一方、素のClaude Code はそもそも grep で2万件から一発で目的の1件を見つけ、生データを窓に流し込んでいません。つまり「節約する余地」が最初から無く、税だけが残ったわけです。

「いやいや、それはプラグインの得意分野じゃない」という声が聞こえてきそうなので、context-mode が本来狙っている使い方でもう一度測りました。題材は「1MBを超える巨大なJSON（あるパッケージの全バージョン履歴）をネットから取得し、必要な情報を答える」。OFFはClaude Code純正の取得ツール、ONはプラグインの取得＋索引化ツールを使わせました。どちらも正解です。

本命の場面でも、ONは約46%多くコンテキストを使い、しかも所要時間は約2倍でした（コストだけは僅かに低い）。

Claude Code の純正取得ツールはもともと賢く、1MBの生データを丸ごと窓に入れず、必要な部分に絞って返してくれます。つまり「窓が氾濫する」問題は純正ツールが既に解決済み。そこにプラグインの「取得＋索引化＋ツールの往復」を重ねるので、むしろ純増した、というわけです。

この「純正ツールが既に窓を節約しているから、外付けの削減ツールが効かない」という構図は、別のコンテキスト圧縮ツールでも同じでした。Claude CodeにHeadroomは効くのか？6条件潰した実測の結論 でも、透過プロキシ経由では6条件すべてで削減0%。違うツールで独立に測って同じ結論に至ったので、これは context-mode 固有の話ではなく、賢いエージェントに外付け削減を足す構図そのものの問題だと考えています。

ここは公平に書きます。「98%削減」が嘘とは思いません。 その数字は、おそらく「賢い純正ツールを持たないクライアント」や、「生データを cat や curl で丸ごとLLMに流し込んでしまう非効率なワークフロー」を前提にした比較です。そういう環境なら、間に挟んで生データを窓から追い出す効果は本物でしょう。

逆に言えば、Claude Code のように元から窓を節約してくれる相手には、その前提が成立しない。だから私の環境では「効果が出る余地がなく、オーバーヘッドだけが残った」。これが今回の実測の正体です。

ですので、「自作スクリプトで大量データをそのままLLMに渡している」「賢いツールを持たない別のクライアントで使っている」といったケースでは、結果が変わる可能性は十分にあります。私が測っていないだけです。

今回の数値は「context-mode v1.0.162 を Claude Code 2.1.173 の上で ON/OFF した、当環境・特定2タスクでの実測」で、各設定1回ずつの比較です。ツールやモデル、ワークロードが変われば挙動は変わり得ます。

また、「削減が一切起きない」と主張するものではありません。生データを丸ごとLLMに渡す自作スクリプトや、賢いツールを持たない別クライアントでは、削減が効く可能性が残ります（未検証）。減るかどうかは、使っているクライアントが「生データをそのまま窓に流し込んでいるか」に強く依存する、というのが私の見立てです。

私の環境・使い方では、context-mode の導入は不要という結論になりました。安全面（名ばかりのサンドボックス・LAN内SSRFの穴）でも常時導入は避けたい、というのが3AI一致の見立てです。

そのうえで、立場別に2つだけ提案させてください。

• これから入れようか迷っている方へ → 導入は一旦待ってください。 少なくとも「自分の典型タスクで効くのか」を確かめてからで遅くありません。賢いツール（Claude Code等）を使っているなら、効かない可能性が高いです。
• 既に入れている方へ → 一度、自分の環境で実測してみてください。 ON/OFF で同じタスクを走らせ、入力＋キャッシュ生成＋キャッシュ読み出しのトークン量を比べるだけです。非対話モードのJSON出力から拾えます。「入れているから安心」が、実は毎セッション数万トークンの税になっているかもしれません。知らずに損していないか、数字で確認する価値はあります。

謳い文句は出発点であって、答えではありません。最後はいつも、自分の環境の数字が決めてくれます。今回もそれを再確認できた、いい検証でした。

出典

• 対象プラグイン: context-mode（MCPプラグイン、v1.0.162）。「コンテキスト窓98%削減」を公称。
• 検証ツール: Claude Code 2.1.173 / 接続モデルは Claude 系の標準モデル。
• Claude Code 公式ドキュメント（純正ツールの設計）: docs.claude.com/en/docs/claude-code/overview
• Claude Code の MCP プラグインの仕組み（公式）: docs.claude.com/en/docs/claude-code/mcp
• 検証日: 2026年6月11日（2026-06-11）

同じ「削減を謳うツール」の話は、トークン60〜95%削減を謳う Headroom とは何者か と、その実測編の Claude CodeにHeadroomは効くのか？6条件潰した実測の結論 にまとめています。あわせて、失敗から学ぶClaude Code Sonnet 4.6 1M context：$15と$5の分岐点 も読むと、コンテキスト窓の使い方と費用のつながりが見えやすくなります。

この記事は、実務で AI ツールを活用している開発者・技術者向けに書いています。

• META-MARK

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です！エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします！