MCPのトークン消費とは？コンテキストを圧迫する仕組みと削減方法7つ【2026年版】
MCPがLLMのトークンを消費する仕組みを、公開計測値（58ツールで約5万5千トークン）とClaude 5.5の料金での計算例で解説。ツール検索、Code Execution、権限による絞り込み、説明文の短縮、レスポンス縮小、キャッシュの7つの削減方法と、Claude Code・Cursorの設定をまとめました。
最終更新：2026年10月13日 ／ 対象：MCP仕様 2026-07-28、Anthropic API（Claude 5.5系）、Claude Code、Cursor
MCPサーバーをつなぐほど、会話を始める前からコンテキストが埋まり、APIの請求も増えていきます。この記事では、MCPのトークン消費（MCP Token） がどこで発生するのかを分解し、実際の料金で計算したうえで、ツール検索やCode Executionなど7つの削減方法を整理します。
結論（30秒で読める要約）
- MCPのトークン消費とは、MCPツールのために使われるLLMのトークンのことです。ツール定義、ツール呼び出しの引数、ツールの結果の3つが主な内訳です。
- いちばん大きい固定費はツール定義です。Anthropicの計測では、よく使われる5つのサーバー（計58ツール）だけで約5万5千トークンを、会話の前に消費していました。
- いちばん大きい変動費は途中の結果です。AnthropicのGoogle Drive→Salesforceの例では、2時間の会議の文字起こしがモデルを2回通るため、約5万トークンが余分にかかります。
- 効果が大きいのはツール検索（遅延読み込み）とCode Execution（コード実行）です。Anthropicはツール検索でツール定義のトークンが85%減ったと報告しています。また、コード実行の例では15万トークンが2千トークンになりました。
- 手軽な対策として、権限によるツール一覧の絞り込み、説明文の短縮、レスポンスの縮小、ツールの並び順を固定してプロンプトキャッシュを効かせる方法があります。
目次
- MCPのトークン消費とは
- トークンはどこで使われるか（4つの内訳）
- MCPツールは何トークン使うのか（公開されている計測値）
- MCPのトークンコストを計算する
- MCPのトークン消費を減らす7つの方法
- クライアント別の設定（Claude API・Claude Code・Cursor）
- チェックリスト
- よくあるハマりどころ
- NodeFlareならこう解決できる
- よくある質問（FAQ）
1. MCPのトークン消費とは
MCPのトークン消費とは、LLMの入出力トークンのうち、会話そのものではなくMCP（Model Context Protocol）のツールのために使われる分のことです。 MCPサーバーは tools/list でツールを公開します。多くのクライアントは、各ツールの name・description・inputSchema をモデルのツール一覧に変換し、リクエストのたびに送ります。
Anthropicの料金ドキュメントには、ツール使用時は「tools パラメータを含む、モデルに送られた入力トークンの合計」で課金されると書かれています。つまり、ツールを1つも呼ばないターンでも、ツール定義の分だけ料金とコンテキストを使います。
なお、この記事の「トークン」はLLMのトークン（コンテキストと課金の単位）のことです。APIキーやOAuthのアクセストークンの話ではありません。
2. トークンはどこで使われるか（4つの内訳）
MCPのトークン消費は、次の4か所で発生します。最初の2つはリクエストのたびにかかり、後の2つはツールを呼ぶたびに増えます。
| 内訳 | いつかかるか | 何で増えるか |
|---|---|---|
| ツール使用のシステムプロンプト | ツールを渡すリクエストごと | モデルごとに固定。Claude 5.5系で tool_choice: auto の場合は 286 トークン |
| ツール定義 | リクエストごと（遅延読み込みしない場合） | ツール数 × 説明文とJSON Schemaの長さ |
| ツール呼び出しの引数 | 呼び出しごと（出力トークン） | モデルが引数に書き写すデータ。たとえば文書を丸ごと別のツールに渡す場合 |
| ツールの結果 | 呼び出しごと（次のターンの入力トークン） | レスポンスの大きさ。全件のレコード、生のHTML、長いログなど |
MCP仕様（2026-07-28版）では、ツールは name、任意の title、description、inputSchema、任意の outputSchema、annotations で定義されます。長い説明文と深くネストしたスキーマが、トークンを増やす主な原因です。
3. MCPツールは何トークン使うのか（公開されている計測値）
複数のサーバーをつなぐと、ユーザーが何も入力しないうちに数万トークンが埋まります。 Anthropicが2025年11月に公開したサーバー別の数値は次のとおりです。
| MCPサーバー | ツール数 | トークン数（概算） |
|---|---|---|
| GitHub | 35 | 約2万6千 |
| Slack | 11 | 約2万1千 |
| Sentry | 5 | 約3千 |
| Grafana | 5 | 約3千 |
| Splunk | 2 | 約2千 |
| 合計 | 58 | 約5万5千 |
ツール数だけで決まるわけではありません。Slackは11ツールしかないのに、35ツールのGitHubに近いトークンを使っています。説明文とスキーマが長いためです。また、Anthropicのツール検索のドキュメントによれば、ツールが30〜50個を超えるあたりから、モデルが正しいツールを選ぶ精度も落ちていきます。ツールが増えると、料金が上がるだけでなく、選び間違いも起きやすくなります。
数値は環境によって変わります。自分の環境で測るには、Anthropicのトークン計測API（/v1/messages/count_tokens）に、tools ありとなしで同じリクエストを送って差を見ます。
4. MCPのトークンコストを計算する
計算式：1リクエストあたりのコスト ＝ ツール定義のトークン数 ÷ 100万 × 100万トークンあたりの入力単価。 単価は2026年10月時点のAnthropic公式料金ページの値です。計算は筆者によるもので、前の章の約5万5千トークンを例にしています。
| モデル | 入力単価（100万トークンあたり） | 5万5千トークン／1リクエスト | 1,000リクエストあたり |
|---|---|---|---|
| Claude Opus 5.5 | 4ドル | 0.22ドル | 220ドル |
| Claude Sonnet 5.5 | 2ドル | 0.11ドル | 110ドル |
| Claude Haiku 5.5（10万トークン以下） | 0.10ドル | 0.0055ドル | 5.50ドル |
計算方法：55,000 ÷ 1,000,000 × 2ドル ＝ 0.11ドル（Sonnet 5.5）。これを1,000倍したものが右の列です。会話本文、286トークンのツール用システムプロンプト、出力トークンは含めていません。
結果を大きく変える要素が2つあります。
- プロンプトキャッシュ。 Sonnet 5.5のキャッシュ読み込みは100万トークンあたり0.10ドル（通常の0.05倍）です。5万5千トークンのツール定義がキャッシュに当たれば、55,000 ÷ 1,000,000 × 0.10ドル ＝ 0.0055ドル／リクエスト、1,000リクエストで5.50ドルになります。キャッシュの書き込み料金は別にかかり、ここには含めていません。
- ツール検索。 Anthropicは、ツール検索を使うと作業開始前のコンテキストが約7万7千トークンから約8,700トークンに減ったと報告しています。Sonnet 5.5で計算すると、77,000 × 2ドル ÷ 100万 ＝ 0.154ドルに対し、8,700 × 2ドル ÷ 100万 ＝ 0.0174ドル／リクエストです（筆者の計算）。
料金と同じくらい大事なのがコンテキストです。コンテキストウィンドウが20万トークンなら、5万5千トークンは27.5%にあたり、最初のメッセージの前にそれだけ埋まります。
5. MCPのトークン消費を減らす7つの方法
方法の一覧を先に示し、そのあと1つずつ説明します。
| 方法 | 減るもの | 手間 | 誰が何を変えるか |
|---|---|---|---|
| 1. 使わないサーバー・ツールを外す | ツール定義 | 小 | クライアントの設定 |
| 2. ツール検索（遅延読み込み） | ツール定義 | 小〜中 | クライアントまたはプロキシ |
| 3. Code Execution（コード実行） | 結果・引数・ツール定義 | 中 | クライアントまたはプロキシ＋サンドボックス |
| 4. 権限でツール一覧を絞る | ツール定義 | 小 | サーバーまたはプロキシ |
| 5. 説明文・スキーマを短くする | ツール定義 | 小 | サーバーまたはプロキシ |
| 6. レスポンスを小さくする | 結果 | 中 | サーバー |
| 7. プロンプトキャッシュを効かせる | 繰り返しの入力コスト | 小 | サーバー側の並び順＋APIのキャッシュ |
5.1 使わないサーバーとツールを外す
読み込まないツールはトークンを使いません。 特定のプロジェクトでしか使わないサーバーは、そのプロジェクトでだけ有効にします。Cursorのドキュメントにも、無効にしたサーバーは「読み込まれず、チャットにも表示されない」とあります。もっとも簡単な方法です。
5.2 ツール検索（遅延読み込み）を使う
ツール検索は、モデルが必要とするまでツール定義をコンテキストに載せない仕組みです。 モデルは最初に検索用のツール（クライアントによってはツール名の一覧も）だけを見て、必要な数個の定義だけを読み込みます。
- Anthropic APIでは、ツールに
defer_loading: trueを付け、tool_search_tool_regex_20251119またはtool_search_tool_bm25_20251119を追加します。遅延読み込みできるツールは最大1万個で、1回の検索で返るのは既定で5件です。Anthropicは、ツールが10個以上ある場合や、ツール定義が1万トークンを超える場合にツール検索を勧めています。 - よく使う3〜5個のツールは遅延させずに残します。すべてのツールを遅延させるとAPIがエラーを返します。
- 遅延させたツールはキャッシュの対象となる先頭部分から外されるため、プロンプトキャッシュはそのまま効きます。
5.3 Code Executionで複数のツール呼び出しをまとめる
Code Executionは、モデルが複数のツールを呼ぶ短いプログラムを書き、最終結果だけを受け取る方式です。 途中のデータはサンドボックスの中にとどまり、コンテキストに入りません。Anthropicは、1万行のスプレッドシートをコードで絞り込んでモデルには5行だけ見せる例や、文字起こしをモデルに読ませずにGoogle DriveからSalesforceへ渡す例を紹介しています。
// モデルとの往復3回を、1回のコード実行にまとめる
const rows = await tools.sheets_get_rows({ sheetId: "abc" });
const pending = rows.filter(r => r.status === "pending");
return pending.slice(0, 5).map(r => ({ id: r.id, owner: r.owner }));
注意点もあります。モデルが書いたコードを動かすには、サンドボックス、リソース制限、監視が必要です。Anthropicもこの運用負荷を指摘しています。なお、AnthropicのProgrammatic Tool Callingでは、複雑な調査タスクの平均トークンが43,588から27,297に減りました（37%減）。
5.4 権限でツール一覧を絞る
呼び出せないツールは、モデルに見せる必要がありません。 MCP仕様の2026-07-28版では、tools/list の結果は「リクエストで提示された認可によって変わってよい（MAY）」とされ、例として「呼び出し元に許可されたスコープで使えるツールだけを返す」ことが挙げられています。読み取り専用のエージェントに読み取り系のツールだけを見せれば、トークンが減るうえ、許可されていない書き込み操作を試すこともなくなります。
5.5 説明文とスキーマを短くする
説明文には「いつ使うか」を書き、ドキュメントの内容を繰り返さないようにします。 Claude Codeは、ツールの説明文とサーバーの説明（instructions）を既定で2,048文字で切り詰めます（CLAUDE_CODE_MAX_MCP_DESCRIPTION_LENGTH で変更可能）。大事な情報を最初の1文に置き、ドキュメントに載せるべき例は削り、inputSchema の不要なネストをなくします。
5.6 ツールのレスポンスを小さくする
モデルに必要な項目と行だけを返します。 limit・fields・絞り込み用のパラメータを用意し、ページングします。大きなデータはファイルを丸ごと埋め込まず、resource_link で返します。Claude Codeは、MCPツールの出力が1万トークンを超えると警告を出し、既定で2万5千トークンまでに制限します（MAX_MCP_OUTPUT_TOKENS）。Cursorは長い出力をファイルに書き出し、エージェントが必要な部分だけ読むようにしています。
5.7 ツール一覧を固定してキャッシュを効かせる
プロンプトキャッシュは、ツール定義の部分がリクエスト間で完全に一致しないと効きません。 MCP仕様の2026-07-28版は、ツールを毎回同じ順序で返すべき（SHOULD）としており、その理由に「LLMのプロンプトキャッシュのヒット率が上がる」ことを挙げています。また、tools/list のレスポンスに ttlMs と cacheScope を付けて、クライアントの再取得を減らせます。
6. クライアント別の設定（Claude API・Claude Code・Cursor）
| クライアント | トークン削減のための主な機能（2026年10月時点） |
|---|---|
| Anthropic API | defer_loading とツール検索ツール、Programmatic Tool Calling、プロンプトキャッシュ、count_tokens |
| Claude Code | ツール検索が既定で有効。ENABLE_TOOL_SEARCH（true・auto・auto:N・false）、サーバー単位の alwaysLoad、MAX_MCP_OUTPUT_TOKENS |
| Cursor | 動的なコンテキスト探索（ツールの説明をフォルダーに同期し、必要なときに読み込む）、長い出力のファイル化、サーバー単位の有効・無効 |
Claude Code：ツール検索が既定で有効なので、起動時に読み込まれるのはツール名とサーバーの説明だけです。ENABLE_TOOL_SEARCH=auto にすると、ツール定義がコンテキストウィンドウの10%に達するまでは最初から読み込みます。auto:5 ならしきい値は5%です。注意したいのは、ANTHROPIC_BASE_URL に自社のゲートウェイなど公式以外のホストを指定すると、ツール検索が自動で無効になる点です。ゲートウェイ経由でトークンが急に増えたら、まずここを確認してください。
Cursor：2026年1月にMCPツールの説明を必要なときだけ読み込む方式に変えたところ、MCPツールを呼んだ実行についてのA/Bテストで、エージェント全体のトークンが46.9%減ったと報告しています。ただし、インストールしているMCPサーバーの数によって結果のばらつきは大きいとしています。
その他のクライアント：すべてのツールを最初から読み込み、検索機能もない場合は、4〜6の方法をサーバー側で実施するか、それを代わりに行うプロキシを前に置きます。
7. チェックリスト
- [ ]
count_tokensで、ツール定義のトークン数を測った（toolsありとなしで比較） - [ ] このプロジェクトで使わないサーバーを外した
- [ ] ツールが10個以上、またはツール定義が1万トークンを超えるなら、ツール検索を有効にした
- [ ] データ量の多い、複数ステップの処理をCode Executionに移した
- [ ] 資格情報ごとに、呼べるツールだけが見えるようにした
- [ ] 説明文を500文字程度に収め、要点を最初に書いた
- [ ] レスポンスをページングし、項目を絞り、大きなデータはリンクで返すようにした
- [ ] ツールの並び順を固定し、プロンプトキャッシュを有効にした
8. よくあるハマりどころ
| 症状 | 原因 | 対処 |
|---|---|---|
| 最初のターンでコンテキストが2〜3割埋まっている | すべてのツールを最初から読み込んでいる | ツール検索を有効にし、使わないサーバーを外す |
| ゲートウェイ経由にしたらツール検索が効かない | ANTHROPIC_BASE_URL が公式以外だとClaude Codeが無効にする |
プロキシが tool_reference ブロックを転送できるなら ENABLE_TOOL_SEARCH=true を設定する |
defer_loading を付けたらAPIが400を返す |
全ツールを遅延させた、または遅延ツールに cache_control を付けた |
3〜5個は遅延させない。キャッシュの区切りは遅延していないツールに置く |
| キャッシュのヒット率が低い | ツールの順序や説明文がリクエストごとに変わる | 順序を固定し、説明文に日時などを入れない |
| 1回のツール呼び出しでコンテキストが埋まる | レスポンスに上限がない（全件、生のHTMLなど） | limit・fields を用意し、ページングし、resource_link で返す |
| モデルが違うツールを選ぶ | 似たツールが多すぎる（30〜50個以上） | ツール検索、権限による絞り込み、わかりやすい名前 |
MCPサーバーをHTTPで公開する仕組み（プロキシやゲートウェイにも関わります）は、MCP Streamable HTTPの解説記事で詳しくまとめています。
9. NodeFlareならこう解決できる
NodeFlareはMCPサーバーのホスティングサービスで、プロキシ側でトークン削減のための4つの設定をサーバーごとに切り替えられます。どれもサーバーのコードを変える必要はありません。 ここまでの課題に対応させると、次のようになります。
課題：複数ステップの処理で、途中のデータがモデルを通ってしまう（2章・5.3）
Code Execution（tool_code_mode）を有効にします。サーバーは run_code と search_tools を公開するようになります。モデルは tools.* を呼ぶJavaScriptを書き、NodeFlareがそれをサンドボックスで実行します。複数のツール呼び出しが1回の実行にまとまり、モデルに戻るのは最後の戻り値だけです。サンドボックスはファイルシステムや環境変数にアクセスできない独立したDenoサービスで、通信先はプロキシへのコールバック1か所に限られます。ツールを呼ぶたびにサーバー側でスコープを確認します。既定値はタイムアウト600秒、1回の実行で最大50回のツール呼び出し、V8ヒープ128MBです。Anthropicが指摘していたサンドボックスの運用負荷を、自分で抱えずに済みます。
課題：ツールが多く、作業前からコンテキストが埋まる（3章・5.2）
ツール検索（tool_search_mode）を有効にします。tools/list が search_tools(query) と call_tool(name, args) の2つのメタツールにまとまり、ツールが増えても最初にかかるトークンはほぼ一定です。GEMINI_API_KEY を設定すると、検索がキーワード一致から埋め込みによる意味検索になり、失敗したときはキーワード検索に戻ります。ツール検索を持たないクライアントでも使えます。
課題：使えないツールまでエージェントに見えている（5.4）
tool_list_filter_by_scope を有効にします。tools/list が、呼び出し元の資格情報で実際に呼べるツールだけに絞られます。tools:call:<name> のようなAPIキーのスコープと組み合わせれば、エージェントごとに必要なツールだけの短い一覧を渡せます。
課題：ツールの説明文が長い（5.5）
tool_schema_slim を有効にします。500文字を超える説明文が（UTF-8を壊さずに）切り詰められます。ツール名と入力スキーマはそのまま残ります。たとえば2,000文字の説明文を持つツールが10個あれば、1リクエストあたり1,500 × 10 ＝ 15,000文字が減ります（筆者の計算）。トークンへの影響は count_tokens で測ってください。
最小の始め方：
- nodeflare.techにログインし、GitHubのリポジトリを選びます。ランタイム、トランスポート、起動コマンドは自動で検出されます。
- デプロイしたら、サーバーの設定で
tool_code_modeまたはtool_search_modeを有効にします。 - 発行された
https://<your-server>.nodeflare.tech/mcpのURLとAPIキーをMCPクライアントに登録します。
MCPサーバー1つまでは無料で試せます（Freeプラン：サーバー1つ、月30GB時間のコンピュート）。→ nodeflare.techで始める
10. よくある質問（FAQ）
MCPはなぜトークンを多く消費するのですか？
多くのMCPクライアントが、接続したすべてのツールの名前・説明文・JSON Schemaを、リクエストのたびにモデルへ送るためです。Anthropicの計測では、よく使われる5つのサーバーで約5万5千トークンでした。さらに、ツールの結果がモデルに戻るたびにトークンが増えます。
MCPのツール定義は入力トークンとして課金されますか？
はい。Anthropicは「tools パラメータを含む」すべての入力トークンに課金します。これとは別に、Claude 5.5系で tool_choice: auto の場合、286トークンのツール用システムプロンプトが加わります。
MCPツールが何トークン使っているか確認する方法は？
Anthropicの /v1/messages/count_tokens に、同じメッセージを tools ありとなしで送り、差を取ります。その差が、1リクエストあたりのツール定義の負担です。
MCPツールはいくつまでなら問題ありませんか？
プロトコル上の上限はありません。Anthropicのドキュメントによれば、30〜50個を超えるあたりからツール選択の精度が落ちます。ツールが10個以上、またはツール定義が1万トークンを超えるならツール検索が推奨されています。
MCPのツール検索とは何ですか？
ツール定義をコンテキストに載せず、検索用のツールで必要なものだけを読み込む仕組みです。Anthropicはツール定義のトークンが85%減ったと報告しています。Claude Codeでは既定で有効です。
MCPのCode Execution（コードモード）とは何ですか？
モデルがMCPツールを呼ぶ短いプログラムを書き、サンドボックスで実行して、結果だけを受け取る方式です。途中のデータはコンテキストに入りません。Anthropicの例では15万トークンが2千トークンになりました。
プロンプトキャッシュでMCPのコストは下がりますか？
ツール定義の部分がリクエスト間で同じなら下がります。Sonnet 5.5では、キャッシュ読み込みは100万トークンあたり2ドルではなく0.10ドルです。MCP仕様2026-07-28版の推奨どおり、ツールの並び順を固定しておきましょう。
Claude CodeでMCPのトークン消費を減らすには？
ツール検索を有効のまま（既定）にし、alwaysLoad は本当に毎回必要な数個のツールだけにします。大きな出力には MAX_MCP_OUTPUT_TOKENS を調整します。独自の ANTHROPIC_BASE_URL を使っている場合は、ツール検索が無効になっていないか確認してください。
CursorでMCPのトークン消費を減らすには？
今のプロジェクトで使わないサーバーを無効にします。Cursorはすでに、MCPツールの説明を必要なときだけ読み込み、長い出力はファイルに書き出す仕組みになっています。
「MCPトークン」とMCPのアクセストークンは同じものですか？
違います。この記事で扱っているのは、MCPが消費するLLMのトークンです。MCPサーバーの認証に使うAPIキーやOAuthのアクセストークンは、セキュリティの話題になります。
まとめ
MCPのトークン消費は、ツール定義（毎ターンかかる）、ツール使用の固定分、呼び出しの引数、ツールの結果から成り立っています。まず count_tokens で測り、使わないものを外し、残りはツール検索で遅延読み込みにし、データの多い複数ステップの処理はCode Executionに移します。そのうえで、権限による絞り込み、説明文の短縮、レスポンスの縮小、ツール一覧の固定によるキャッシュの活用を進めると、コンテキストと料金の両方を抑えられます。
参考資料
- Anthropic：Code execution with MCP（2025年11月4日）
- Anthropic：Introducing advanced tool use（2025年11月24日）
- Claude Docs：Tool use overview（料金）
- Claude Docs：Tool search tool
- Claude Docs：Pricing
- Claude Code Docs：Connect Claude Code to tools via MCP
- MCP仕様 2026-07-28：Tools
- Cursor：Dynamic context discovery（2026年1月6日）
- NodeFlare：ドキュメント ・ 料金
