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

関連記事としては Blog失敗から学ぶClaude Code Sonnet 4.6 1M context：$15と$5の分岐点Claude Code MAXプランで1M contextが突然使えなくなった原因を実機で調査。extra usageの正体と、最小コストで戻す判断材料を整理します。→ もあわせて読むと、今回の論点とのつながりを把握しやすくなります。

関連記事：

• BlogClaude CodeにHeadroomは効くのか？6条件潰した実測の結論Claude Codeの前にHeadroomを透過プロキシで挟んでも、6条件すべてで削減0%。本番Opus実測から、効く経路と無駄な経路を切り分けます。→
• Blogトークン60〜95%削減を謳う Headroom とは何者か——仕組み・公式ベンチ・導入判断を一次情報で整理するHeadroomの仕組み、公式ベンチ、RTKとの違い、実測との差を一次情報で整理。導入判断の材料をまとめます。→

「コンテキスト窓を98%削減する」と謳うMCPプラグイン context-mode を、安全に隔離した使い捨てDocker環境で 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。本文の比較数値はすべて当環境での実測値です。

• 「コンテキスト98%削減」という殺し文句
• なぜ「使い捨ての隔離環境」でテストしたのか
• 計測のやり方（再現できるように）
• 検証結果①：2万件のデータから1件を探す
• 検証結果②：本命の「巨大データ取得」でフェア勝負
• では「98%削減」は嘘なのか？ — 効くかもしれない場面
• 結論と、あなたへの2つの提案
• よくある質問
  • context-mode を入れれば、どんな環境でもコンテキストは減りますか？
  • 「98%削減」という公称値は誇大広告ですか？
  • 自分の環境で効くか確かめる、いちばん簡単な方法は？
• 注意点・制約
• どのように検証したか
• 参考リンク
• 関連記事
• この記事を書いた人

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

そんな折に「コンテキスト窓を98%削減するMCPプラグイン」という触れ込みのツールを見つけました。これは気になる、効くなら今すぐ入れたい——そう思ったのが出発点です。仕組みとしては、Web取得やファイル読み込み・API応答といった「重い生データ」を別プロセスで処理して、要約や検索ヒット部分だけを本体（LLM）に返す、というもの。315KB → 5.4KB のような劇的な削減例も掲げられています。

正直、心が動きました。でも、homelab を運用していると痛感するのですが、謳い文句と実機の挙動は別物です。だから今回も、飛びつく前にきちんと測ることにしました。結論から言うと——私の環境では「削減」どころか、むしろコンテキストが増えました。その一部始終を、データと一緒に共有します。

この「クレームを鵜呑みにせず、自分の経路で測る」という姿勢は、以前 Blogトークン60〜95%削減を謳う Headroom とは何者か——仕組み・公式ベンチ・導入判断を一次情報で整理するHeadroomの仕組み、公式ベンチ、RTKとの違い、実測との差を一次情報で整理。導入判断の材料をまとめます。→ を整理したときと同じです。削減率を大きく掲げるツールは、まず「どんな前提の数字なのか」を疑うところから始めると、損をしにくくなります。

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

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

この見立ては自分ひとりの判断にせず、3つのAI（Claude / GPT-5.5系 / Gemini系）に独立してソースをレビューさせ、全員が「高価値な資産がある環境への常時導入は非推奨」で一致しました。未監査のLLMツールを評価するときに、まず隔離環境で安全性から確かめるという進め方は、BlogAIが書いたコードの穴を、AI自身に3層で見張らせる——Claude Code 公式セキュリティプラグインを実機検証した正直な結論AIが生成したコードの脆弱性を、Anthropic公式の無料プラグイン security-guidance はどこまで防げるのか。わざと危険なコードを書かせて3層チェックが鳴るか実機検証し、限界も正直にまとめました。→ したときと同じ流儀です。

そこで、効果測定は次のような使い捨ての隔離環境で行いました。

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

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

比較指標はシンプルにしました。Claude Code を非対話モードで動かし、出力のJSONから「モデルに入力されたトークンの総量＝入力 + キャッシュ生成 + キャッシュ読み出し」を取り出します。これが「コンテキスト窓をどれだけ使ったか」の実量です。

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

最初のタスクは「約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の生データを丸ごと窓に入れず、必要な部分に絞って返してくれます。つまり「窓が氾濫する」問題は純正ツールが既に解決済み。そこにプラグインの「取得＋索引化＋ツールの往復」を重ねるので、むしろ純増した、というわけです。

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

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

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

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

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

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

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

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

context-mode を入れれば、どんな環境でもコンテキストは減りますか？

いいえ。今回の実測では、Claude Code のように賢い純正ツール（grep・WebFetch）を持つ環境では、削減の余地が最初から無く、むしろツール定義とフック注入の固定オーバーヘッド（今回は約+23,000トークン）が乗って増えました。減るかどうかは、あなたが使っているクライアントが「生データをそのまま窓に流し込んでいるか」に強く依存します。

「98%削減」という公称値は誇大広告ですか？

そうとは言い切れません。賢いツールを持たないクライアントや、cat／curl で生データを丸ごとLLMに渡す非効率なワークフローが前提なら、間に挟んで生データを追い出す効果は本物のはずです。問題は、その前提が Claude Code には当てはまらないこと。クレーム自体ではなく「どの前提の数字か」を確認するのが大切です。

自分の環境で効くか確かめる、いちばん簡単な方法は？

同じタスクを context-mode の ON と OFF で1回ずつ走らせ、入力＋キャッシュ生成＋キャッシュ読み出しのトークン量を比べるだけです。非対話モードのJSON出力から拾えます。1回測れば、自分の典型タスクで税になっているか効いているかが一目で分かります。

• 今回の数値は「context-mode v1.0.162 を Claude Code 2.1.173 の上で ON/OFF した、当環境・特定2タスクでの実測」です。ツールやモデル、ワークロードが変われば挙動は変わり得ます。
• 「削減が一切起きない」と主張するものではありません。生データを丸ごとLLMに渡す自作スクリプトや、賢いツールを持たない別クライアントでは削減が効く可能性が残ります（未検証）。
• 安全面の指摘（名ばかりサンドボックス・LAN内SSRF）は対象バージョン時点のソース監査に基づくものです。今後のバージョンで設計が変わる可能性があります。攻撃の具体的な再現手順は、原理と結果のみに留め、意図的に記載していません。

• AIサーバー上の使い捨てDockerコンテナ（Node 22ベース・非root・ホストのホーム非マウント）で実施しました。ネットワークはホスト側ファイアウォールで社内LAN宛を遮断し、インターネットのみ許可（egress制限）。プラグインの厳格fetchモードも併用しています。
• Claude Code を非対話モードで動かし、JSON出力から「入力＋キャッシュ生成＋キャッシュ読み出し」トークンを抽出。まったく同じタスク・同一モデル・同一プロンプトで context-mode の ON と OFF を1回ずつ走らせて比較しました。
• ソースの安全性評価は、Claude / GPT-5.5系 / Gemini系の3つのAIに独立してレビューさせ、結論の一致を確認しています。

出典

• 対象プラグイン: 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）

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

• META-MARK

• Blog失敗から学ぶClaude Code Sonnet 4.6 1M context：$15と$5の分岐点Claude Code MAXプランで1M contextが突然使えなくなった原因を実機で調査。extra usageの正体と、最小コストで戻す判断材料を整理します。→
• BlogClaude Code の新effortモード徹底解説｜max・ultracode・autoと『呪文ultrathink』の正体Claude Code の /effort に増えた max・ultracode・auto と、プロンプトに紛れ込ませる呪文 ultrathink を、公式が明言した『ultracode は API の effort レベルではない』を起点に解剖。overthinking・自律ワークフロー・永続性と優先順位の罠まで、誤解されやすい論点を一次情報で正します。→
• BlogClaude Code の /effort 完全ガイド｜low〜maxの使い分けと『コストが増える本当の理由』Claude Code の /effort（low〜max・ultracode・auto）は「賢さ」ではなく「トークンの気前よさ」のレバー。モデル別の推奨スタートと、Opus 4.8 でコストが増えた気がする原因を『トークナイザ』と『effort』の2軸に切り分ける考え方を、公式一次情報と v2.1.156 の実機確認で解説します。→

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