AIエージェントが実行する操作には、すべてトークンという単位のコストがかかる。Scalekitが75回のベンチマーク実行で得た結果は、その前提を揺さぶるものだった。同一のGitHubタスクを比較したところ、CLIエージェントはMCPエージェントより10〜32倍安く、成功率は100%。一方でMCPの成功率は72%に留まり、4件に1件以上でタスクが失敗していた。
この数値をどう読み解くか。まずMCPとCLIそれぞれの仕組みを整理しておく。MCP（Model Context Protocol）は、AnthropicがAIエージェントと外部ツールを標準化された形で接続するために策定したプロトコルだ。GitHubやSlack、データベースなどのサービスをMCPサーバとして立ち上げ、AIエージェントがそこに問い合わせる形で動作する。一方のCLIとはコマンドラインインタフェースのことで、エージェントが直接シェルコマンドを発行して処理を行う方式を指す。
スキーマオーバーヘッドという隠れたコスト
MCPを使う際に見落とされがちなのが「スキーマオーバーヘッド」だ。MCPサーバは自身が提供するツールの定義情報（ツール名・説明・入力パラメータのJSONスキーマ）をすべてコンテキストに注入する。エージェントが実際にそのツールを呼び出すかどうかにかかわらず、定義情報はリクエストのたびに送られる。
PolicyLayerが3,875件のMCPサーバを計測したデータによると、ツール定義のオーバーヘッドは1サーバあたり中央値で2,064トークンだった。GitHubのMCPサーバ単体では14,406トークン、GitHub・Linear・Supabaseを同時接続すると合計24,116トークンとなり、これだけで200Kコンテキストウィンドウの12%が埋まる。エージェントが最初の一言を返す前の段階でだ。また、PerplexityのCTOが報告したケースでは、MCPツールの説明文がコンテキストウィンドウ全体の72%を消費していたという。
3パターンのトークン消費量を比較する
具体的な数値でパターンを整理すると、次のようになる。
- MCPツール呼び出し: 入力50トークン＋出力100トークン＋フレーミング20トークン ＝ 約170トークン
- CLIコマンド（RTKフィルタあり）: 入力30トークン＋出力350トークン＋ラッパー80トークン ＝ 約460トークン
- CLIコマンド（フィルタなし）: 入力30トークン＋出力3,000トークン＋ラッパー80トークン ＝ 約3,110トークン
RTKフィルタリングとは、コマンドのraw出力（生の標準出力）から必要なフィールドだけを抽出してトークン数を圧縮する処理のことだ。たとえば `npm view` を素のまま実行すると2,100行を超えるパッケージメタデータが返ってくるが、バージョン番号1つが欲しいだけなら残りはすべてノイズになる。フィルタなしのCLIがMCPの18倍のトークンを消費する一方、フィルタありのCLIは2.7倍に収まる。
この差はスケールすると無視できなくなる。93個のツールを持つGitHub MCPサーバのスキーマだけで55,000トークンに達するという事例もある。Claude Sonnetの入力トークン単価$3/Mで換算すると、1リクエストあたり$0.17がスキーマの読み込みだけに消える。1日1万リクエストなら月$51,000のスキーマ税だ。
G/N比という判断軸
ただし、MCPが常に非効率というわけではない。判断の軸になるのが「G/N比（ツール使用頻度）」だ。20回のプロンプトのうちそのツールを実際に呼ぶ割合を指す。
使用頻度が低い（5%未満）場合、ネイティブMCPはCLIの137倍のトークンを消費する。中程度（5〜40%）になると、ゲートウェイ型のMCPを使えばCLIの約2倍まで抑えられる。使用頻度が高い（40%超）場合には差はほぼ無視できる水準になる。要するに、頻繁に呼ばれるツールほどMCPのスキーマオーバーヘッドの割合は薄まり、構造化されたインタフェースのメリットが前面に出てくる。
ここで逆の視点も考慮する必要がある。CLIのraw出力をそのまま流すとトークンが爆発するため、フィルタ処理を実装・維持するコストがかかる。MCPツールは「書いて、テストして、APIが変わるたびに更新する」必要があるが、出力が構造化されているため後段の処理が安定しやすい。
実際の開発ワークフローでこの選択に向き合うとすれば、まずエージェントが1セッションで使うMCPサーバの数を確認し、ツールの定義トークン合計を見積もることから始められる。接続サーバが5つで平均2,064トークンなら、1リクエストごとに10,320トークンがスキーマ維持に消える計算になる。使用頻度の低いツールはCLI経由＋RTKフィルタで代替し、頻繁に呼ぶ構造化ツールのみMCPに残す、という設計判断が現実的な着地点になる。
MCPとCLIの優劣は一律には決まらない。「どのツールをどの頻度で呼ぶか」という使用パターンを計測してから設計を選ぶ、それがトークンコストを現実的にコントロールする出発点となる。