一度も呼び出さないツールにかかるトークン税

Model Context Protocol サーバーをエージェントに接続すると、エージェントが何か作業を始める前に、あることが起きます。ほとんどのクライアントは、そのサーバーが公開するすべてのツールを取り込み、その定義をモデルのコンテキストにロードします。名前、説明、そして引数を記述する JSON Schema です。そのペイロードはコンテキストに居座り、エージェントがそのツールを一度呼んでも一度も呼ばなくても、あなたはその分を払います。

私たちはツールの一覧を、レストランのメニューを読むように読みがちです。選択肢が多いほど能力が高そうに見えますし、レストランでは注文するまで選択肢は本当に無料です。ここではそうではありません。どの項目も、モデルが何かを判断する途中で読む、コンテキストに常駐するテキストです。そして課金は、誰かが注文する前、それがメニューに載った瞬間から始まります。

仕様書から取った、定義ひとつの形はこうです。

{
  "name": "get_weather",
  "description": "Get current weather information for a location",
  "inputSchema": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "City name or zip code"
      }
    },
    "required": ["location"]
  }
}

ツールひとつなら何でもありません。問題は、コストがタスクの大きさではなくカタログの大きさに応じて増えることです。ツールを 2 つ必要とする仕事でも、すべてのスキーマを抱えたままです。Anthropic は、5 つのサーバーからなる典型的な構成が、エージェントが何かをする前に定義だけでおよそ 55,000 トークンを費やすと報告し、ほとんどの要求が実際に必要とするのはそのうち 3 つから 5 つのツールだと指摘しています。カタログを数千のツールへ押し上げれば、エージェントは要求を読む前に数十万トークンを処理します。彼らのもっとも劇的な数字は別のケースから来ています。Google Drive から Salesforce へデータを動かすワークフローが 150,000 トークンから 2,000 へ下がった、というものです。ただしこれは 2 つの節約を束ねています。ロードする定義を減らすことと、動かしたデータをコンテキストの外に保つことです。ですからこれは、自分のツール一覧に当てはめられる割合ではなく、曲線のいちばん端として読んでください。

トークンは税の目に見える半分にすぎません。もう半分の静かな部分は、選択の質です。コンテキストにあるツールが 1 つ増えるたびに、モデルは判断の間、それを他のツールと区別して保つべきものが 1 つ増えます。そしておよそ 30 から 50 のツールを超えると、正しいものを選ぶ精度が落ち始めます。定義がいつも役立つとは限りません。いくつかのサーバーを集約すると、仕様書が指摘する衝突にぶつかります。2 つの異なるサーバーがそれぞれ search ツールを公開していて、モデルが間違ったほうに手を伸ばさないよう、区別のための接頭辞が要る、というものです。大きなメニューは注文するのも難しいのです。

もっともな反論が、この半分のうち一方を鈍らせます。ツールのブロックはプロンプトの先頭、もっともキャッシュしやすい領域に置かれるので、最初のターンのあとはエージェントが安く読み直します。そのとおりです。ですがキャッシュが割り引くのはドルであって、定義が占めるコンテキストウィンドウでも、それらがかける精度でもありません。読み直しは払い戻しますが、本当に効く 2 つのことはそのまま残します。

ここで、コマンドラインツールを呼び出すことが、後退にはあまり見えなくなってきます。エージェントが呼び出す CLI は、そのスキーマを常時オンのコンテキストの外に保ちます。インターフェースは --help の中にあり、エージェントはそれを使うと決めたときにだけ読みます。私は自分の環境でこれに頼っています。内部ダッシュボードに対する日常の作業では、エージェントは生の API を手で組み立てるのではなく、ラップされたコマンドを 1 つ呼びます。とはいえスキーマのコストが消えたわけではなく、移っただけです。コンテキストに残るのはポインタ、つまりそのコマンドが存在することといつ手を伸ばすべきかをエージェントに伝える、どこかの 1 行です。そして引数の全リストは呼び出しのときに初めて現れます。これがトリックのすべてで、そう、--help もエージェントが読んだ時点でやはりトークンです。

誘惑的な教訓は「CLI は MCP サーバーに勝つ」ですが、これは誤りです。CLI が勝つのは、それが CLI だからではありません。勝つのは、仕事がツールに手を伸ばすまでスキーマのコストを先送りするからで、サーバーも同じように先送りできます。トークン問題への Anthropic 自身の答えは、MCP を捨てません。定義がいつロードされるかを変えるのです。そして Claude API はこれを設定として提供するようになりました。ツールに defer_loading を付けると、それは検索ツールが表に出すまでプロンプトの外にとどまり、そのときにスキーマが会話に追記されて届きます。この最後の詳細こそが重要です。オンデマンドのロードは追記でなければなりません。ツールのブロックはキャッシュのあるプロンプトの先頭にあるからです。発見したスキーマを結果として届ければ、そのキャッシュされた接頭部分は無傷のまま残りますが、登録済みのツールセットをその場で書き換えれば接頭部分を書き直し、その代償を払うことになります。追記で先送りすれば、1 部屋を使うために建物全体を借りるのをやめられます。

だから生き残る枠組みは、そもそもプロトコル戦争ではありません。ツールの面はトークン予算であり、あなたはそれを予算のように値付けすべきです。オンのままにしておくすべての機能は、エージェントが下すあらゆる判断に持ち込むコンテキストです。次のツールを足す前に、コストを本当に予測する問いを立ててください。エージェントは目の前の仕事でこれに手を伸ばすか、プロンプトの先頭の席に値するほど頻繁に、と。

この問いには、税という枠組みが隠しがちな裏面があります。常駐するツールが正解のこともある、ということです。Anthropic 自身の経験則は、ほぼすべての要求で使われるひと握りのツールをロードしたままにし、ロングテールは先送りします。エージェントが絶えず手を伸ばすツールは、毎回検索するより、常駐で一度払ってキャッシュされるほうが安いからです。そして、まったく先送りできないツールもあります。以上のどれも、サーバーを作ることへの反論ではありませんし、私は 1 つ出荷しています。clipboard-mcp は小さな Rust のバイナリで、それが恒久的な席を得る理由は好みではなく形です。3 つのツールのうち 1 つがクリップボードの変化を監視しますが、これはセッションに紐づいた生きたプロセスを要し、一度きりのシェル呼び出しではありえないものです。agent-recall は私が保守しているメモリライブラリで、出力の側で逆の選択をします。クエリは、背後にある生の行ではなく、要約されたブリーフィングを返します。行はコンテキストに着地し、そのセッションの残りの間ずっと居座るからです。そのコストはターンごとではなく呼び出しごとにかかりますが、同じ注意深さに報います。

見るべき数字は、エージェントが見られるツールの数ではありません。定義に費やすトークンが、仕事が動いたときに動くかどうかです。タスクを変えれば、正しく値付けされた面は違う使い方をします。この仕事が必要とするものを運んでいるからです。カタログで値付けされた面は、仕事が何であれ毎回同じだけ使います。そしてそれが、満額で届く税です。あなたは一度も呼び出さないツールに払っているのです。