Claude Codeは、MCPサーバーを何個つないでも、それだけでは文脈コストを払わない。ツールのスキーマは接続時やセッション開始時に一括取得されるのではなく、そのツールが実際に呼ばれた瞬間まで取得が遅延される設計になっている（検証済みバージョン: Claude Code 2.1.204）。だがコストが消えているわけではない——同じターンで複数のMCPサーバーを実際に呼び出した瞬間、遅延されていた全スキーマ分のコストが一気に乗る。しかもそのスキーマの重さはサーバーごとに30倍以上ばらつき、同じ24個のツールでもNotionはPlaywrightの4倍重い。セッション起動時の体感コストがほぼゼロに見えても、それは消えたのではなく先送りされているだけだ——エージェントに何個のMCPサーバーを常時アタッチし、同じターンでいくつを実際に呼ばせるかという設計判断が、そのままレイテンシとトークンコストの実額になって跳ね返ってくる。

何が起きたか

MCP（Model Context Protocol）を使ったエージェント開発において、「サーバーをいくつ繋ぐとどれだけ文脈コストがかかるか」を実測ベースで分析した第三者の研究記事が公開された。著者は、自サイトが以前公開した「AIコーディングのコスト」研究の姉妹編と位置づけており、前者がモデル利用そのものの値段を検証したのに対し、今回はエージェントを支える「配管（plumbing）」側の値段を検証したと説明している。

分析の中心的な結論は次の2点である。

  1. Claude Codeは、ツールのスキーマをセッション開始時に一括取得するのではなく、そのツールが実際に呼ばれた時点で初めて取得する「遅延評価（deferral）」を採用している。この挙動はClaude Code 2.1.204で確認されており、MCPサーバーをアタッチしただけではセッション開始時のサイズは測定可能な範囲で増加しない。
  2. ユーザーが全スキーマ分のコストを実際に支払うのは、(a) 遅延評価を持たないクライアントやモードを使っている場合、または (b) 同一ターンで実際に複数のサーバーを使った場合、のいずれかに限られる。

この記事はAnthropic公式の発表ではない。Anthropicの発信（"Anthropic's engineering post"等）は本文中で第三者として引用されており、okaneland.comという独立系サイトによる実測分析である点には注意が必要だ。

仕組み・詳細

「文脈税」という発想は、MCPサーバーを接続すると、そのサーバーが持つ全ツールの定義（名前・説明・引数スキーマ）がプロンプトに読み込まれ、その分だけコンテキストウィンドウとトークン代を消費する、という前提に基づく。素朴に考えれば、サーバーを繋いだ瞬間、あるいは最初のプロンプトを送る前にこのコストが発生していそうに思える。

しかし実際には、Claude Codeのようなクライアントはツール定義の読み込みそのものを遅らせる設計を取っている。セッション開始時にクライアント側が保持するのはツールの「名前」程度で、引数スキーマを含むフルの定義は、そのツールが会話の中で実際に呼び出されるまで読み込まれない。分析記事はこれを"The cost is deferred, not deleted."（コストは消えているのではなく、先送りされているだけだ）と表現している。

この設計のもとでコストが顕在化する条件は2つに絞られる。1つは、クライアントやモードそのものが遅延評価を持たない場合——この場合はセッション開始時から全スキーマ分を払うことになる。もう1つは、遅延評価を持つクライアントであっても、同じターンの中で実際に複数のサーバーのツールを呼び出した瞬間だ。この瞬間には、呼び出した全サーバー分のスキーマがまとめて文脈に載る。

数字で見る

分析はスキーマの「重さ」がサーバーによって大きく異なることも示している。人気MCPサーバー間でツール定義の重さは30倍以上ばらつくとされ、具体例として、同じ24個のツールを持つNotionとPlaywrightを比較すると、Notionのツール定義はPlaywrightの4倍重いという。つまりコストの実質的な大きさは、いくつのサーバーを同時に呼ぶかだけでなく、どのサーバーを呼ぶかによっても大きく変わる。

背景

著者は記事冒頭で、自サイトが以前公開した「AIコーディングのコスト」研究の"sibling"（姉妹編）だと位置づけている。記事内でAnthropicの発信は他者の見解として引用されており、Anthropic自身が今回の分析結果を公式に発表したわけではない。著者名・運営組織・発行日はページ本文から特定できず、独立系の技術ブログによる実測分析として扱うべき内容である。

なぜ重要か

MCPサーバーを何個・どれだけアタッチするかという判断は、これまで主に機能面（どんなツールが使えるか）で語られがちだった。しかし遅延評価という仕組みの存在は、コストが「繋いだ瞬間」ではなく「実際に同時に使った瞬間」に発生するという、より運用に近い判断軸を持ち込む。エージェントに大量のMCPサーバーを常時アタッチしておくこと自体は起動コストをほぼ増やさない一方、複数サーバーを同じターンで実際に稼働させるワークフロー（マルチツール連携が必要なタスク）を設計した瞬間、先送りされていたコストが一括で顕在化する。しかもサーバーごとの重さが30倍以上も違うのであれば、「何個繋ぐか」だけでなく「どのサーバーを、どのタイミングで、いくつ同時に呼ばせるか」までが設計対象になる——見えないコストは、見えないままでは制御できない。