MCP のトークン消費問題 — スキーマ注入で 55,000 トークン、CLI は 35 倍効率的

Claude Code や OpenClaw で MCP（Model Context Protocol）を使っている方に知ってほしい事実があります。MCP はスキーマ注入だけで数万トークンを消費しており、同じタスクを CLI 経由で実行すると 35 倍効率的 になるケースがあるのです。

@SuguruKun_ai さんのポストと @shinzizm2 さんのポストでこの問題が指摘され、大きな反響を呼びました。

MCP のトークン消費問題とは

スキーマ注入の仕組み

MCP サーバーを接続すると、ツール定義（スキーマ）がシステムプロンプトに注入されます。これは AI が「どんなツールを使えるか」を理解するために必要な情報ですが、この定義自体が大量のトークンを消費します。

MCP サーバー接続時の処理:
1. tools/list でツール一覧を取得
2. 各ツールの名前、説明、パラメータ定義を取得
3. 全てのスキーマをプロンプトに注入 ← ここで大量消費
4. ユーザーの質問に回答

あなたが何も入力する前に、スキーマだけでトークンが消費されているのです。

具体的な数値

MCP サーバー	ツール数	トークン消費量
GitHub MCP サーバー	93 ツール	約 55,000 トークン
Notion サーバー	15+ ツール	約 8,000 トークン
ファイルシステム	10 ツール	約 4,000 トークン
平均的なツール定義	1 ツール	300〜600 トークン

GitHub MCP サーバーの場合、93 ツール分のスキーマには owner、repo、title 等のプロパティ定義、required フィールド、入出力スキーマが全て含まれます。

パワーユーザーの実態

典型的な開発者が 10 サーバーを接続した場合：

10 サーバー × 15 ツール平均 × 500 トークン = 75,000 トークン

Claude の 200,000 トークンのコンテキストウィンドウの 3 分の 1 以上がスキーマで埋まります。ユーザーの質問やコードを処理する前にです。

MCP vs CLI：35 倍の効率差

@SuguruKun_ai さんが指摘した海外の検証データでは、同じタスクの実行で MCP 経由 145,000 トークン、CLI 経由 4,150 トークンという結果が報告されています。

実測比較：デバイスコンプライアンス確認タスク

MCP 方式の内訳：

処理	トークン消費
ツールスキーマ注入	約 28,000
エージェント推論	約 3,200
API 呼び出し	約 1,800
レスポンス解析	約 4,500

CLI 方式の内訳：

処理	トークン消費
スキーマ注入	0
エージェント推論	約 800
コマンド実行	約 150
出力解析	約 3,200

CLI にはスキーマ注入が不要なため、コンテキストウィンドウのほぼ全てを問題解決に使えます。

トークン効率スコア

方式	効率スコア	コンテキスト利用可能量（128K 中）
CLI	202	121,300 トークン
MCP	152	82,300 トークン

CLI が 33% 高い効率スコアを記録しています。

なぜ CLI が効率的なのか

1. スキーマ注入が不要

CLI ツールは AI が直接コマンドを実行するため、事前のスキーマ注入が不要です。git、gh、docker といったコマンドの使い方は、AI が学習データから既に理解しています。

2. AI の学習データとの親和性

AI モデルは Stack Overflow、GitHub リポジトリなど、数十億行のターミナル操作データで訓練されています。gh issue list や git log の出力形式は、AI にとって馴染み深いものです。

3. パイプラインの合成が可能

CLI ツールは組み合わせが自由です：

1
gh issue list --json number,title | jq '.[] | select(.title | contains("bug"))'

MCP では各ツールを個別に呼び出す必要がありますが、CLI はパイプで繋げて一度に処理できます。

@shinzizm2 さんの指摘：「だから CLI を作っていた」

@shinzizm2 さんは「なので、私は CLI を作ってたのでした」とコメントしています。MCP のトークン消費問題を認識した上で、効率的な CLI ベースのアプローチを選択していたということです。

これは個人の判断に留まらず、業界全体で CLI ファーストのアプローチが再評価されている動きと一致します。

それでも MCP が有利なケース

MCP が全てダメというわけではありません。以下のケースでは MCP に優位性があります：

ケース	理由
本番環境の厳密制御	入力検証、OAuth 認証、監査ログが組み込み
マルチテナント権限分離	きめ細かい権限スコープが必要な場合
CLI 非対応ツール	Figma、Notion などコマンドライン代替がないサービス
動的ツール発見	エージェントが利用可能な機能を構造的に発見する必要がある場合

対策：トークン消費を減らす方法

1. 必要な MCP サーバーだけを接続する

「とりあえず全部入れておく」は最悪のパターンです。使うツールが限られているなら、そのサーバーだけを有効にしましょう。

2. CLI で代替できるものは CLI を使う

GitHub の操作なら gh CLI、ファイル操作なら標準コマンドで十分です。Claude Code は元々これらのコマンドを直接実行できます。

# MCP 経由（55,000 トークンのスキーマ注入あり）
GitHub MCP → create_issue ツール

# CLI 経由（スキーマ注入なし）
gh issue create --title "Bug fix" --body "Description"

3. 階層的ルーティングの導入

MCP のツール定義を 2 つのメタツールに集約する手法が提案されています：

discover_mcp_tools(query) — 必要なツールを検索
execute_mcp_tool(tool_path, args) — ツールを実行

この方法で スキーマ消費量を 98% 削減（75,000 → 1,400 トークン）できるという報告があります。

4. 経済的な影響も考慮する

5 人チームでの試算：

方式	月額コスト
MCP（対策なし）	$375
MCP（階層ルーティング）	$7
削減額	$368/月

Claude Code に自己判断させることは可能か？

「MCP を事前ロードすべきか、CLI を使うべきか」を Claude Code 自身に判断させることは可能でしょうか。調査の結果、既にいくつかの仕組みが存在し、さらに CLAUDE.md でのルール定義で補強できることが分かりました。

1. Tool Search（公式機能・デフォルト有効）

Claude Code 2.1.7 で導入された MCP Tool Search が、まさにこの問題を自動的に解決します。

動作の仕組み：

ツール定義の合計が 10,000 トークンを超えるか検出
超過した MCP サーバーのツールに defer_loading: true を付与
全スキーマの代わりに軽量な検索インデックスを注入
タスク実行時にキーワードで必要なツールをオンデマンド検索
クエリごとに 3〜5 個の関連ツール（約 3K トークン）だけをロード

効果：

指標	従来方式	Tool Search
トークン消費	約 77K	約 8.7K
削減率	—	85% 削減
Opus 4 精度	49%	74%
Opus 4.5 精度	79.5%	88.1%

トークン消費を減らすだけでなく、タスクの精度も向上しています。不要なスキーマが推論を邪魔しなくなるためです。

Tool Search はデフォルト有効なので、設定不要で既に動いています。/context コマンドで現在のトークン消費状況を確認できます。

2. MCP-CLI Experimental Mode（実験的機能）

さらに踏み込んだアプローチとして、MCP ツールを CLI コマンド経由でオンデマンド実行する実験的モードがあります。

1
2
# 有効化
export ENABLE_EXPERIMENTAL_MCP_CLI=true

効果：

指標	変更前	変更後
セッション開始時の使用率	63%（126K/200K）	11%（21K/200K）
MCP ツール関連消費	43.8K	0（必要時のみ）
実務利用可能領域	37%	89%

MCP ツールの呼び出しを mcp-cli info / mcp-cli call コマンド経由で行うため、スキーマの事前注入が完全に不要になります。

3. CLAUDE.md でルールを定義する（カスタム対応）

Tool Search や MCP-CLI に加えて、CLAUDE.md にトークン効率ルールを記述することで、Claude Code の判断をさらに最適化できます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
# ツール選択ルール

## CLI 優先の原則
以下の操作は MCP ではなく CLI で実行すること：
- GitHub 操作: `gh` CLI を使用（gh issue, gh pr, gh api 等）
- Git 操作: `git` コマンドを直接使用
- ファイル操作: 標準コマンド（ls, cat, mkdir 等）を使用
- Docker 操作: `docker` / `docker compose` CLI を使用
- AWS 操作: `aws` CLI を使用

## MCP を使用するケース
CLI で代替できない場合のみ MCP を使用：
- Figma、Notion など CLI が存在しないサービス
- OAuth 認証フローが必要なサービス
- 構造化された権限制御が必要な操作

## トークン効率の確認
大きなタスクの開始前に `/context` でトークン消費状況を確認し、
MCP スキーマが過大な場合は不要なサーバーの無効化を提案すること

この CLAUDE.md ルールにより、Claude Code はタスクごとに「CLI で十分か、MCP が必要か」を判断するようになります。

4. 自己診断の実現方法

Claude Code に自身の利用状況を分析させるには、以下の組み合わせが効果的です：

┌─────────────────────────────────────────────┐
│  レイヤー 1: Tool Search（自動・デフォルト有効）    │
│  → 10K トークン超のスキーマを自動的に遅延ロード      │
├─────────────────────────────────────────────┤
│  レイヤー 2: CLAUDE.md ルール（手動設定）          │
│  → 「CLI 優先」の判断基準を明示的に指示             │
├─────────────────────────────────────────────┤
│  レイヤー 3: /context コマンド（随時確認）          │
│  → トークン消費状況を可視化し、最適化を提案           │
├─────────────────────────────────────────────┤
│  レイヤー 4: MCP-CLI Mode（実験的・任意）          │
│  → MCP を完全に CLI 経由に置き換え                │
└─────────────────────────────────────────────┘

まとめ

MCP はツール統合の標準プロトコルとして価値がありますが、トークン消費という隠れたコストを理解した上で使う必要があります。

GitHub MCP サーバーだけで 55,000 トークンがスキーマ注入で消費される
同じタスクで CLI は MCP の 35 倍効率的なケースがある
コンテキストウィンドウの 3 分の 1 以上がスキーマで埋まる可能性
CLI で代替できるなら CLI を使うのが現時点でのベストプラクティス
MCP が真に必要なのは、認証制御・権限管理・CLI 非対応サービスの場合

「MCP を使えば便利」と無条件に考えるのではなく、トークン効率を意識したツール選択が、AI エージェント活用の次のステージです。

MCP のトークン消費問題 — スキーマ注入で 55,000 トークン、CLI は 35 倍効率的#

MCP のトークン消費問題とは#

スキーマ注入の仕組み#

具体的な数値#

パワーユーザーの実態#

MCP vs CLI：35 倍の効率差#

実測比較：デバイスコンプライアンス確認タスク#

トークン効率スコア#

なぜ CLI が効率的なのか#

1. スキーマ注入が不要#

2. AI の学習データとの親和性#

3. パイプラインの合成が可能#

@shinzizm2 さんの指摘：「だから CLI を作っていた」#

それでも MCP が有利なケース#

対策：トークン消費を減らす方法#

1. 必要な MCP サーバーだけを接続する#

2. CLI で代替できるものは CLI を使う#

3. 階層的ルーティングの導入#

4. 経済的な影響も考慮する#

Claude Code に自己判断させることは可能か？#

1. Tool Search（公式機能・デフォルト有効）#

2. MCP-CLI Experimental Mode（実験的機能）#

3. CLAUDE.md でルールを定義する（カスタム対応）#

4. 自己診断の実現方法#

まとめ#

参考#