MCP接続で消えるトークン 4サーバー5構成の実測
Claude Codeのセッションが妙に重い。まだ何も頼んでいないのに、トークン消費が跳ね上がっている。消費先を確認したら、原因はMCPサーバーのツール定義でした。
何が起きているのか
MCPサーバーに接続すると、最初に tools/list というリクエストが走ります。これはサーバーが「私はこんなツールを持っています」と自己紹介する仕組みです。ツール名、説明文、パラメータ定義。これらがすべてLLMのコンテキストウィンドウに読み込まれます。
ここが直感に反するポイントです。使わなくても読み込まれる。
従来のAPI呼び出しなら、使いたいAPIだけを叩けばよかった。RESTful APIを10個知っていても、GETリクエストを送らなければ帯域もコストもゼロです。
MCPは違います。図書館に例えると「1冊の本を読みたいだけなのに、全蔵書のカタログを先に読まされる」。しかもその図書館に入るたびに、毎回カタログを最初から読み直します。
4サービスの実測データ
書籍『MCP実践セキュリティ』第4章では、4つのMCPサーバーについてツール定義のトークン消費量が実測されています。以下は同書の実測表から数値を引用したものです(GitHubは構成違いで2行に分けて紹介します)。
| MCPサーバー | ツール数 | 推定トークン数 | 月10回のコスト |
|---|---|---|---|
| PostgreSQL | 1 | ~35 | ~$0.0005 |
| Google Maps | 7 | ~704 | ~$0.009 |
| GitHub | 26 | ~4,242 | ~$0.06 |
| GitHub (full) | 93 | ~55,000 | ~$0.74 |
| freee※ | 270 | ~17,500 | ~$0.24 |
※ freeeの値は、2026年3月時点で使っていた @him0/freee-mcp(当時約270ツールを個別公開する構成)のものです。同パッケージは2026-02-24にfreee社のGitHub Orgへ移管されて freee-mcp として公式化され、現行の公式版(書籍執筆時点 v0.30.3)は汎用APIラッパー6+管理系9の計15ツール構成に整理されているため、同じトークン数は再現されないと想定されます。
PostgreSQLとGitHub fullの差は約1,500倍です。GitHubは26ツール構成の約4,242トークンから、full構成の93ツール・約55,000トークンまで膨らみます。同じサーバーでも、バージョンと構成次第でコストが一桁変わります。
同じ「MCPサーバー」という名前がついているのに、接続のコスト特性がまったく違う。これは正直、数字を見るまで想像できませんでした。PostgreSQLは「コンビニで水を買う」くらいの感覚ですが、GitHub fullやfreeeは「コンビニに入ったら全商品の成分表を読まされる」に近い。

なぜfreeeは270ツールもあるのか
当時の @him0/freee-mcp は5つのAPIをカバーしていました。
| API | 主な機能 | ツール数の目安 |
|---|---|---|
| 会計 | 取引、勘定科目、試算表 | ~80 |
| HR | 従業員、部署、給与 | ~60 |
| 請求書 | 請求書作成、送付 | ~40 |
| 勤怠 | 打刻、残業、有給 | ~50 |
| 販売管理 | 見積、受注、売上 | ~40 |
freeeは会計だけでなくHR、勤怠、給与、販売管理まで一気通貫で提供するプラットフォームです。MCPサーバーが全APIをカバーしているのは、フル活用するユーザーにとっては合理的な設計です。
ただし、確定申告の経費処理だけが目的なら、必要なのは会計APIの一部(10~20ツール程度)。270ツール全部の定義が読み込まれるのは、蕎麦屋に入ったらフルコースのメニューを端から端まで音読させられるようなものです。
年間コストを計算してみる
確定申告での経費処理を想定して、上の表の「月10回あたり約$0.24」から年間コストを出します。
利用頻度別の年間コスト:
月10回(個人事業主の経費処理) → 約$2.9/年
毎日利用(中小企業の経理) → 約$8.6/年
月50回(フル活用) → 約$14.4/年
freeeの月額料金(スタンダードプラン: ¥2,980/月・税抜 = ¥35,760/年)と比較すれば小さな金額です。
しかし重要なのは、これがツール定義の読み込みだけのコストだということ。実際のツール呼び出し(取引の作成、勘定科目の検索など)のトークン消費は別途かかります。「サブスクの月額は安いけど、オプション料金が地味にかさむ」パターン。家計簿をつけるためのツールが、見えないところで家計を圧迫している。皮肉な話です。
業界の反応: PerplexityがMCPから距離を置いた
このトークンコスト問題は、私の個人的な発見ではありません。業界全体で認識されつつあります。
2026年3月、Perplexity CTOのDenis Yarats氏はAsk 2026カンファレンスで、社内でMCPから離れてAPIとCLIに戻すと発表しました。理由はコンテキストウィンドウの消費と認証フローの煩雑さ。『MCP実践セキュリティ』第4章でも、重いサーバーを3つ並べた構成で、200Kトークンの文脈のうち143K(71%)がスキーマ定義だけで埋まった観測例を挙げています(構成やバージョンで増減する値です)。
PerplexityはMCPサーバーの提供自体はやめていませんが、自社プロダクトの内部ではMCPを使わない方向にシフトしています。「プロトコルとしては支持するが、コスト構造が現実的でない」という判断です。
コスト最適化の3つの戦略
戦略1: 必要なツールだけ公開する
freeeの270ツールのうち、確定申告に必要なのは10ツール程度。クライアントによっては allowedTools で使うツールを絞れます(この記法はすべてのMCPクライアントがサポートしているわけではないので、使うクライアントで事前に確認してください)。
{
"mcpServers": {
"freee": {
"allowedTools": [
"create_deal",
"list_deals",
"get_deal",
"update_deal",
"get_trial_balance",
"list_account_items",
"list_partners",
"list_taxes",
"list_walletables",
"get_company"
]
}
}
}
10ツールなら約650トークン。17,500トークンから96%の削減です。
最も手軽で効果の大きい対策ですが、意外と知られていません。MCPの導入記事は「接続できた」で終わるものが多く、「接続後にツールを絞る」ステップまで書いてある記事はほとんど見かけません。
戦略2: 遅延読み込み(Lazy Loading)
2026年に入って、MCPのトークン問題に対する技術的な解決策が出てきました。
Claude CodeのTool Search機能(2026年1月発表)は、MCPツールが多すぎる場合にツール定義をコンテキストに直接読み込まず、必要なときだけ動的に検索・読み込みます。50以上のツールがある環境で特に有効です。
lazy-mcpというOSSプロキシも登場しています。MCPサーバーの前段に置いて、ツール定義をオンデマンドで読み込む仕組みです。READMEでは、常用しない2つのMCPツールを隠すことでClaude Codeのコンテキストの17%(約34,000トークン)を削減したという事例が報告されています。
戦略3: 接続のタイミングを制御する
最もローテクで確実な方法です。常時接続ではなく、必要な時だけMCPサーバーに接続する。「freeeの作業が終わったら接続を切る」。それだけで、他のタスクでのトークン消費をゼロにできます。
年に数回しか使わないツールを365日接続しておく理由はありません。
MCPサーバー選定時のチェックリスト
MCPサーバーを本番導入する際、機能面だけでなくコスト面も評価すべきです。
| 評価基準 | 良い例 | 要注意 |
|---|---|---|
| ツール数 | 必要最小限に絞られている | 全機能がフラットに公開 |
| 説明文 | 簡潔・構造化されている | API仕様書そのまま |
| 権限制御 | ツール単位で制御可能 | 全ツールが常に有効 |
| ドキュメント | トークン消費量の記載あり | 記載なし |
MCPサーバーを自作する場合は、ツール説明文の長さがトークンに直結することを意識してください。API仕様書のような冗長な説明文(約80トークン)を簡潔な説明文(約20トークン)にするだけで、ツールあたり75%のトークン削減になります。
まとめ
- MCPに接続するだけで、ツール定義のトークンが消費される
- PostgreSQL(35トークン) vs GitHub full(55,000トークン): 約1,500倍の差。同じサーバーでも構成で一桁変わる
- freee(当時の
@him0/freee-mcp)の年間コストは約$2.9(月10回利用)。見えないが確実にかかるコスト allowedToolsでツールを絞れば96%削減できる。最初にやるべき対策- 2026年はLazy LoadingやTool Searchなど、エコシステム側の対策も進んでいる
- PerplexityのMCP離脱は、この問題が個人の些事ではなく業界の構造的課題であることを示している
MCPは便利です。私も日常的に使っています。ただ、「接続した瞬間に何が起きているか」を理解した上で使うのと、知らずに使うのとでは、年間のコストと快適さがまるで違います。
冷蔵庫のドアを開けっぱなしにしても、すぐには食材は腐りません。でも電気代は確実に上がります。MCPのトークンコストも同じです。気づいたときに閉めればいい。
参考リンク
- MCP公式仕様 — Model Context Protocol specification
- lazy-mcp — 遅延読み込みプロキシ
- Perplexity CTOのMCP離脱発言 — Denis Yarats, Ask 2026
- MCP Token Counter — トークン消費の可視化ツール
さらに深掘りしたい方へ
MCP を本番導入する前に必読 — OWASP MCP Top 10、トークンコスト実測、ファイルアップロード問題の7サービス検証を扱う MCP実践セキュリティ(インプレス) を参考にしてください。
関連書籍 MCP実践セキュリティ MCP セキュリティの実践書 | OWASP MCP Top 10・攻撃の実演・認証認可・本番ワークアラウンド 書籍ページを見る → この記事は役に立ちましたか?