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

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

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

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

見積もりの精度を上げるには、この加算を「気にしなくていい誤差」ではなく「モデルとtool_choiceの選び方で動く変数」として扱います。金額に直結する追加コストは3種類です。

1. toolsパラメータそのもの(ツール名・description・input_schemaの合計)
2. 会話に登場するtool_useブロックとtool_resultブロック
3. ツール利用を有効化するための固定のsystem promptトークン(このページの実測表が対象)

この3つを分けて把握しておくと、請求額が想定より増えたときに、どこを削れば効果的かを切り分けやすくなります。

このうち3つ目は開発者の目に触れにくく、モデルとtool_choiceの設定だけで数百トークン単位で変動します。

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

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

同じ「最新モデル」でも、Opus 5とOpus 4.7で675トークンから286トークンまで開きがあります。モデル世代が新しくなったからといって固定コストが単調に下がるわけではなく、system promptの実装が世代ごとに作り直されている結果と見るのが妥当です。

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

anyやtoolを指定すると、モデルへの指示文にツールを強制呼び出しするための追加テンプレートが加わります。この差は現行モデルではおおむね100トークン前後で、Claude Opus 5では286→406(+120)、Claude Sonnet 5では354→474(+120)、Claude Opus 4.6・Claude Sonnet 4.6では497→589(+92)、Claude Opus 4.7では675→804(+129)と、絶対値は違っても増分の水準はそろっています。

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

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

上の表の数値は「ツール利用を有効化する」ための固定コストで、ツールの数を増やすほど積み増しされる分は含みません。実際のリクエストでは、ここにtools配列そのもの(ツール名・description・input_schemaの合計)と、会話が進むごとに増えるtool_use/tool_resultブロックのトークンが加算されます。

GitHub・Slack・Sentry・Grafana・Splunkのような複数のMCPサーバーを一度に接続する典型的な構成では、ツール定義だけで5万5,000トークン前後をClaudeが作業を始める前に消費すると報告されています。固定コストの数百トークンより、こちらの定義本体のほうが規模としては支配的になりやすい点を覚えておきましょう。

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

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

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

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

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

もっとも影響が大きいのはツール定義の変更です。ツールを1つ追加・削除しただけでも、定義自体だけでなくその後段のsystemプロンプトとmessages全体のキャッシュが道連れで無効になります。開発中にdescriptionを頻繁に書き換えていると、意図せずキャッシュミスのコストを積み上げることになります。

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のブロックが会話履歴に積み上がり、上表の固定コストとは別に本体側のトークンも累積します。同じツール群を使い回すセッションでは定義部分の再送コストをキャッシュで抑えられますが、tool_choiceの値をリクエストごとに切り替える運用では、メッセージ側のキャッシュが無効になる点には注意が必要です。

実測値はusageフィールドで確認できる

上表はあくまで公式ドキュメントが公開した基準値です。実際の消費量は、レスポンスに含まれるusageオブジェクトのinput_tokens・output_tokensで確認できます。同じツール定義でも、モデルのバージョンアップやAPI内部実装の変更でsystem prompt側の固定コストが変わることがあるため、コストに敏感なアプリケーションでは公式表の数値を鵜呑みにせず、usageを定期的に記録して実測値との差分を追っておくと安全です。

まとめ

toolsを渡すだけで、モデルとtool_choiceの組み合わせに応じて286〜804トークンがシステムプロンプトに自動加算されます。この固定コストに加えて、ツール定義本体と会話中のtool_use/tool_resultブロックが積み上がるため、ツールの数が多いアプリケーションほど「見えないトークン消費」は無視できない規模になります。

数十本を超えるツールを扱うなら、defer_loadingとTool Search Toolによる圧縮を検討する価値があります。トークン単価だけでなく、Web検索やコード実行のような従量課金が乗っていないかも合わせて確認しておくと、実際の請求額とのズレを小さくできます。