Claudeのツール利用で増えるトークン数をモデル別に見る

ツール利用のたびに増える「見えないトークン」の正体

ツール利用のコストは、書いたコードの分量では見積もれません。表に出ない加算分が積み重なる構造そのものを知っておくことが出発点です。

toolsパラメータを1つでも渡すと、モデルへ送られるシステムプロンプトに、ツール利用を有効化するための専用の指示文が自動で追加されます。このトークン数は書いたツール定義や会話本文とは別に、リクエストのたびに固定コストとして加算されます。見積もりの段階でこの固定分を見落としていると、実際の請求額が想定より数百トークン分、規模が大きければ一気に膨らんで見えることになります。

見積もりの精度を上げるには、この加算を「気にしなくていい誤差」ではなく「モデルとtool_choiceの選び方で動く変数」として扱います。入力側に乗る追加分は3種類あり、削る場所もそれぞれ違います。

内訳

ツール利用で入力に加わる3種類

• tools パラメータ

  ツール名・description・input_schemaの合計です。ツールの本数に比例します。

• 会話中のブロック

  tool_useとtool_resultが、ターンのたびに履歴へ積み上がります。

• 固定のsystem prompt

  ツール利用を有効にする専用の指示文です。開発者の目に触れず、モデルとtool_choiceで数百トークン単位に動きます。この記事の実測表が対象です。

モデル別トークン数の実測表

Anthropicの公式ドキュメントは、toolsを少なくとも1つ渡した場合の固定トークン数を、モデルとtool_choiceの組み合わせ別に公開しています。toolsを渡さずtool_choiceが実質noneのときは、この加算はゼロです。

強制呼び出しのany / toolは、使えないモデルがあります。右列が空欄または「対象外」の行はこれに当たります。

くらべる

any / tool が通るかどうか

auto / none だけ

400エラーになる

Opus 5.5・Sonnet 5.5・Fable 5.1・Mythos 5.1では、anyとtoolが400で返ります。手動の拡張思考(thinking: {type: "enabled"})を付けた場合も、モデルを問わずエラーです。

追加は+92〜+129

通る

上の表で右列に数字がある行です。適応型の思考(adaptive thinking)を有効にしても、Opus 5では強制呼び出しができます。

400になる側の代替は、autoにstrict: true(strict tool use)を組み合わせてスキーマに合う入力を保証するか、固定のJSON形で返したいときの構造化出力(structured outputs)です。固定コストの表にFable 5.1とMythos 5.1の行はなく、この表には数字がありません。

同じ「最新モデル」でも、Opus 5とOpus 4.7で675トークンから286トークンまで開きがあります。モデル世代が新しくなったからといって固定コストが単調に下がるわけではありません。公式表はこの差の理由を説明していないため、見積もりは世代ごとに表を引き直します。

なぜany/toolのほうがトークンを多く消費するのか

anyやtoolを指定すると、モデルへの指示文にツールを強制呼び出しするための追加テンプレートが加わります。増分は現行モデルでおおむね100トークン前後です。モデルごとの差は次のとおりです。

数字

any / tool に切り替えたときの増分

• Opus 5・Opus 4.8・Sonnet 5

  +120

  Opus 5は286→406、Sonnet 5は354→474

• Opus 4.5〜4.6・Sonnet 4.5〜4.6・Haiku 4.5

  +92

  497→589、496→588

• Opus 4.7

  +129

  675→804。表の中で最大

autoのまま多くのリクエストを回している場合、anyやtoolへ切り替えるコスト試算はこの増分だけで足ります。逆に、ツール呼び出しを確実に起こしたいという理由だけでany/toolを使っているなら、100トークン前後を払ってでも強制する価値があるかを見直す余地があります。

ツールの数と会話の長さが本体側のコストを決める

上の表の数値は「ツール利用を有効化する」ための固定コストで、ツールの数を増やすほど積み増しされる分は含みません。実際のリクエストでは、冒頭の3種類のうち上の2つ、つまりtools配列そのものとtool_use/tool_resultブロックのトークンが加算されます。

GitHub・Slack・Sentry・Grafana・Splunkのような複数のMCPサーバーを一度に接続する典型的な構成では、ツール定義だけで5万5,000トークン前後をClaudeが作業を始める前に消費すると報告されています。固定コストの数百トークンより、こちらの定義本体のほうが規模としては支配的になりやすい点を覚えておきましょう。この仕組みとTool Searchが解決する範囲はMCPのツール定義はなぜコンテキストを圧迫するのかで扱っています。Anthropic自身が提供するBrowser Use Toolも、ツールセット定義だけで約6,600トークンを消費します(Browser Use Toolの料金とトークン消費を実測値で読む)。

ツールが増えるほど効いてくる圧縮策

ツールが数十〜数百本規模になると、固定コストと定義本体のトークンが無視できなくなります。個々のツール定義にdefer_loading: trueを付けると、そのツールはシステムプロンプトのプレフィックスから除外され、Claudeが検索で見つけたときだけ会話の中にインラインで展開されます。

Tool Searchは、先述の5万5,000トークン規模の定義コストを通常85%以上削減し、1リクエストで読み込まれるツールを3〜5本に絞るとされています。defer_loadingはプロンプトキャッシュのプレフィックスから外れる形で処理されるため、キャッシュヒット率を落とさずに導入できる点も実務では重要です。詳しい仕組みはAdvanced Tool Useでも扱っています。

ツール定義を変えるとキャッシュ全体が道連れになる

プロンプトキャッシュはtools→system→messagesという階層(プレフィックス)で構成されます。上位の階層を変更すると、それより後ろのキャッシュはすべて無効になります。

もっとも影響が大きいのはツール定義の変更です。ツールを1つ追加・削除しただけでも、定義自体だけでなくその後段のsystemプロンプトとmessages全体のキャッシュが道連れで無効になります。開発中にdescriptionを頻繁に書き換えていると、意図せずキャッシュミスのコストを積み上げることになります(モデルのフォールバック切り替えでも同種のキャッシュ書き直しが起き、fallback_credit_tokenで二重課金を防ぐで相殺の仕組みを扱っています)。

defer_loading: trueで登録したツールはこの階層の外(システムプロンプトのプレフィックス外)に置かれます。Tool Searchで新しいツールが動的に見つかってもtoolsプレフィックス自体は変わらないため、上表の「ツール定義の変更」には該当しません。開発中に増減させたいツールはdefer_loading: trueで登録しておくと、キャッシュを保持したまま追加・削除を試せます。

公式のトラブルシューティングガイドは「毎回キャッシュミスになる」症状の原因として、tool_choice・拡張思考の設定・output_config.effortがリクエストごとに変わっていることを筆頭に挙げています。もう一つの典型例が「会話の途中でツールを追加するとキャッシュが壊れる」ケースです。原因は新しいツールをtools配列の先頭側に挿入していることで、対処はdefer_loading: trueとTool Searchを使い、配列の先頭を変えずにツールをインラインで追加する形に切り替えることです。ツールを後から増やす設計にするなら、最初からdefer_loading前提で組んだほうが、キャッシュ由来の再処理コストを踏みにくくなります。

サーバーツールにはトークン以外の課金軸もある

ここまでの数値はすべてトークンベースの課金です。しかしサーバー側で実行されるツールの一部には、トークンとは別の課金軸が乗ります。

Web検索ツールは検索1,000件あたり10ドルの従量課金に加え、検索結果として取り込まれた内容が通常の入力トークンとして加算されます。会話の中で複数回検索が実行されれば、その分だけ検索課金とトークン課金の両方が積み上がります。

コード実行ツールは、Web検索かWeb取得と同時に使う場合は無料です(標準の入出力トークン費用のみ)。単独で使う場合は実行時間で課金され、最低5分単位・組織ごとに月1,550時間の無料枠があり、超過分はコンテナ1台あたり時間0.05ドルです。ファイルをリクエストに含めると、ツールを実際に呼び出さなくてもコンテナへのプリロードが発生するため実行時間として課金される点も見落としやすいポイントです。

「見えないトークン消費」を試算するときは、この2種類の従量課金が視野の外に置かれがちです。Web検索やコード実行を組み込むアプリケーションでは、トークン単価の試算とは別に、この従量課金分を予算に足しておく必要があります。

Tool Runnerでの積み上がり方

Tool Runnerのようにツール呼び出しループを自動化する実装では、ターンが増えるたびにtool_useとtool_resultのブロックが会話履歴に積み上がり、上表の固定コストとは別に本体側のトークンも累積します。同じツール群を使い回すセッションでは、定義部分の再送コストをキャッシュで抑えられます。

見積もりと請求を突き合わせる方法

事前の見積もりには、トークン数を数えるエンドポイント(/v1/messages/count_tokens)が使えます。利用は無料で、1分あたりのリクエスト数の上限は、メッセージ作成の上限とは別に管理されます。toolsを付けたリクエストも数えられるので、定義を変えるたびに入力トークンの変化を見られます。

ただし、数えられないものがあります。サーバーツール(Web検索・Web取得・コード実行・Tool Search)とMCPコネクタを含むリクエストはinvalid_request_errorになり、数えられるのはクライアントツールとアドバイザーツールだけです。サーバーツールやMCPコネクタを使う構成では、Messages APIのレスポンスに含まれるusageの値が頼りになります。

固定コストの表を見積もりに使うときは、2つのページの書き方の差に注意が要ります。ツール利用のページは、表の数値を「入力・出力トークンに加えて請求額に反映される」と書いています。一方、トークン数のページは、数えた値にシステム最適化のための自動追加分が含まれることがあり、その分は課金されないと書いています。

手順

コストに敏感な構成での突き合わせ

1. 1

   count_tokensで事前に数える

   使うモデルのIDで、変更前後の定義をそれぞれ数えて差を取ります。

2. 2

   本番のusageを記録する

   見積もりの数字が請求と1対1で対応するとは限らないため、最終的な基準はレスポンスのusageのinput_tokens・output_tokensです。定期的に保存し、事前の数字との差を追います。

3. 3

   モデルを替えるときは再計測する

   Claude Opus 4.7以降は新しいトークナイザーを使い、同じテキストでも従来モデルより約30%多いトークンになります。トークン数のページは、モデルを移るときに以前の数字を使い回さず数え直すよう求めています。

まとめ

どこから手を付けるかは、構成で決まります。ツールが数十本に届かないなら、効くのはモデルの選択とtool_choiceの使い分けです。本数が増えて定義本体が支配的になったら、そちらの圧縮が先になります。Web検索やコード実行を組み込むなら、トークン単価とは別に従量課金を予算へ入れます。発生源別の使い分けは圧迫の発生源別に4つの対処法を使い分ける基準にあります。