til/…/mcp-token-overhead
mcp-token-overhead.mdupdated 2026-08-034,190 chars

MCP 2026-07-28仕様と​ツール定義の​トークン負荷 —— ステートレス化は​提供側の​話で、​使う​側の​消費は​減っていない

MCP​（Model Context Protocol＝AIと​外部の​道具や​データを​つなぐ​共通規格）の​新しい​仕様が、​2026年7月28日に​公開された。​規格が​できて​以来、​最大規模の​改訂と​位置づけられている。​開発しているのは、​Linux Foundation傘下の​Agentic AI Foundationである。

結論から​書く。この​改訂は、​サーバーを​提供する​側が​大規模に​捌けるように​する​ための​変更が​中心で、​つなぐ​側が​消費する​トークン量には​手を​付けていない。そして、​使う​側の​費用を​実際に​支配しているのは​後者の​ほうである。​この​ノートは、​改訂で​何が​変わったのかを​整理したうえで、​扱われなかった​費用の​実測値と、​それを​減らす方​法が​規格の​外側で​どう​実証されているかを​見る。

2026-07-28改訂で​変わった​こと

セッションと​いう​考え方を​やめた

いちばん​大きい​変更は、​接続の​はじめに​一度だけ​行う​挨拶​（initialize）と、​やりとりを​識別する​番号​（Mcp-Session-Idヘッダー）を、​どちらも​廃止した​ことである。​これまでは、​最初の​挨拶で​決めた​内容を​サーバー側が​覚えている​前提で​会話が​続いていた。​改訂後は、​リクエスト1本ごとに​必要な​情報を​全部​持たせる​形に​なった。​プロトコルの​版と、​つなぎに​来た​側が​できる​ことは、​_metaと​いう​入れ物に​毎回​入れて​送る。

公式発表は、​この​結果と​して​「どの​リクエストも、​共有の​保存先を​持たない​普通の​振り分け装置の​後ろに​ある、​どの​サーバーに​でも​届く」と​書いている。​同じ​利用者を​同じ​サーバーに​固定し続ける​必要​（＝セッションアフィニティ）が​なくなるので、​台数を​増やして​捌く​運用が​やりやすくなる。​これは​提供する​側の​都合の​話であり、​規模を​大きくする​ための​変更である。

一覧の​結果を​キャッシュできるようになった

道具の​一覧​（tools/list）、​指示文の​一覧、​資料の​一覧と​読み出しに、​有効期間​（ttlMs）と、​どの​範囲で​使い回して​よいかの​指定​（cacheScope）が​加わった。​公式発表は、​これを​入れた​目的を​「つなぎに​来た​側が、​応答を​どう​保存して​使い回すかを​自分で​決められるようにし、​不要な​取り直しを​減ら​すため」と​書いている。

あわせて、​一覧の​中身が​接続ごとに​変わらなくなった。​以前は、​つないだ相手に​よって​見える​道具が​変わる​作りが​許されていた。​改訂後、​状態を​持ちたい​場合は、​サーバーが​発行した​控え番号を​普通の​引数と​して​渡す形に​する。

その​ほかに​決まった​こと

  • MRTR（Multi Round-Trip Requests） —— 途中で​利用者に​確認を​取る​仕組み。​サーバーが​resultTypeと​して​ input_required を​返し、​つなぎに​来た​側が​答えを​足して​送り直す。​状態を​持たないまま、​サーバー起点の​確認が​できる。
  • ヘッダーでの​振り分け —— Mcp-Methodと​Mcp-Nameを​必ず付ける​ことになった。​中身の​JSONを​開けずに、​入口の​装置​（ゲートウェイや​WAF＝不正な​通信を​遮る​仕組み）だけで​振り分けと​流量計測が​できる。
  • 認証の​厳格化 —— 発行元​（issuer）の​検証を​必須にし、​これまでの​動的な​クライアント登録を​やめて、​クライアントIDの​メタデータ文書を​使う方​式へ移す。
  • 拡張の​正式枠組み —— Tasks​（長時間処理）、​MCP Apps、​企業向けの​権限管理を​公式の​拡張と​して​組み込んだ。

古い​作りは、​少なくとも​12か月は​動き続けると​書かれている。​具体的な​廃止日は​明記されていない。

仕様が​扱っていない​費用

公式発表を​通して​読んだが、利用者側の​トークン消費に​触れた​記述は​無い。一覧を​キャッシュできるようになった​点は​取り直しを​減らすが、​AIに​毎回渡す道具の​説明​その​ものが​減るわけではない。​道具の​説明は​システムプロンプト​（＝AIに​最初に​渡す指示文）に​流し込まれ、​そのまま​コンテキストウィンドウ​（＝AIが​一度に​扱える​文章量の​上限）を​占める。

どれくらい​食っているのか

Anthropicが​2025年11月24日に​公開した​記事に​実測が​ある。

  • 5つの​サーバーを​つなぎ、​道具が​58個に​なった​構成で、​会話を​1度も​始めていない​時点で約55,000トークンが​消えている。
  • 内訳は、​GitHubが​35個で​約26,000トークン、​Slackが​11個で​約21,000トークン、​残り​3つで​約8,000トークン。
  • ここに​Jiraを​足すと​10万トークンを​超える。
  • 実際に、​道具の​説明だけで134,000トークンを​使っていた​例も​挙げられている。

規格を​作っている​側でも、​同じ​問題は​認識されていた。​仕様の​リポジトリには​「1つの​道具あたり103から​1,024トークンを​消費している。​20から​30個つなぐと、​指示文を​入れる​前に​15から​30キロバイトを​使い切る」と​いう​実測つきの​提起が、​2026年5月28日に​出ている​（Issue #2808）。​ただしこの​提起は​現在は​閉じられており、​開発側が​どう​回答し、​今回の​仕様に​反映されたのかは、​Issueの​ページからは​確認できない。

二次的な​費用も​ある。​中間結果も​コンテキストを​通る。​2時間の​会議録音を​道具の​あいだで​受け渡すと、​約50,000トークンの​追加処理が​発生すると​される。​大きな​資料は​コンテキストの​上限その​ものを​超えうる。

減らす方​法は、​規格の​外側で​実証されている

規格が​解いていない​一方で、​使う​側の​工夫では​大きく​減る​ことが​数字で​出ている。​3つ挙げる。

1. 道具を​探す道具を​先に​置く​（Tool Search Tool）

全部の​説明を​先に​読ませるのを​やめ、​道具を​探すための​道具だけを​置いて、​必要に​なった​時点で​探させる。​遅延読み込み​（＝必要に​なるまで​読み込まない​方​式）に​あたる。

Anthropicの​計測では、​約77,000トークンが​約8,700トークンに​なり、85%減に​なった。​コンテキストウィンドウの​95%を​空けたまま​使える。​注目すべきは、​減らしたのに​正しく​道具を​選べる​割合が​むしろ​上がっている​点である。​同社の​モデルで​49%から​74%、​上位モデルで79.5%から​88.1%に​なったと​書かれている。​説明を​全部​読ませる​ほうが​正確、と​いう​直感が​成り立たない。

2. 道具の​呼び出しを​プログラムから​行う​（Programmatic Tool Calling）

AIが​文章と​して​道具を​呼ぶのではなく、​プログラムの​コードから​呼ぶ。​平均43,588トークンが​27,297トークンに​なり、37%減。​ベンチマークの​正答率も​46.5%から​51.2%へ​上がっている。

3. MCPサーバーを​コードの​部品と​して​扱う​（Code execution with MCP）

サーバーを​ファイルツリーのような​形の​コードAPIと​して​提示し、​コードを​実行させる。​2025年11月4日の​記事では、​Google Driveから​Salesforceへ​議事録を​移す例で、​150,000トークンが​2,000トークンに​なったと​している。98.7%の​削減に​あたる。

な​ぜ​これが​調整ではなく​設計の​問題なのか

85%から​98%と​いう​削減幅は、​説明文を​短く​書き直して​出た​数字ではない。説明を​いつコンテキストに​入れるかを​変えて​出ている。これは​仕様の​外側に​ある、​つなぐ側と​サーバーを​作る​側が​下す設計判断に​なる。

効くのは​粒度​（granularity）である。​何を​1つの​道具とみな​すか、​1つの​道具が​どれだけの​スキーマ​（＝引数と​型の​定義）を​晒すか、​何を​返すか。​Issue #2808が​挙げた​3つの​案 —— 説明の​詳細度を​段階に​分ける、​スキーマに​版を​付ける、​名前​空間で​重複を​排除する​ —— は、​いずれも​粒度の​話である。

スキーマの​版付けは​キャッシュの​経済性に​直結する。​道具が​1つ変わると​キャッシュ済みの​先頭部​分が​まる​ごと​無効に​なる​ため、​版を​管理しない​変更は​全セッションに​費用と​して​跳ね返る。

資源の​制約と​いう​論点

半導体や​メモリが​資源と​して​潤沢に​作れないのであれば、​1つの​サーバーあたり、​あるいは​1エージェントあたりの​コンテキスト量に​実務上の​上限が​かかるのではないか、と​いう​見立てが​ある。​ただし、​この​点は​一次情報で​裏を​取れていない。​市況を​報じる​記事は​多数あるが、​いずれも​二次情報で、​数字の​出どころを​確認できない。

確かめられたのは​3つである。​道具の​説明が​実測で​数万トークン単位を​占める​こと。​それを​85%から​98%減らす方​法が​実在する​こと。​そして​今回の​規格改訂は​そこに​手を​付けていない​こと。資源の​制約が​あってもなくても、​無駄に​食う​構成が​不利に​なると​いう​方向は​変わらない。

ここから​導かれる​こと

MCP 2026-07-28は、​サーバーを​大規模に​運用しやすく​する​一方で、​使う​側の​主要な​費用には​触れていない。​解決策が​仕様の​外側に​ある以上、​トークン効率は​プロトコルの​性質ではなくサーバーの​設計の​良し悪しと​して​現れる。​つまり、​次の​改訂で​自動的に​平準化される​類の​ものではなく、​作り手の​差が​そのまま​残り続ける​領域に​なる。

AI検索最適化​（GEO）の​文脈に​引き寄せるなら、​自社の​情報を​AIエージェントへ渡す経路を​どれだけ軽く​作れるかは、​いずれ​「AIに​選ばれるか​どうか」と​同じ​問題に​なる。エージェント・コマースのように、​AIが​購買まで​担う​場面ではとくに​そうなる。

出典・参考

関連ノート

150 notestil