Nodeflare
記事一覧
MCPトークン

どのMCPサーバーがトークンを食っている？MCP Token使用量をサーバー・ツール別に計測する方法【2026年版】

どのMCPサーバー・ツールがトークンを使っているかを突き止める方法。Claude Codeの/context・/usage・OpenTelemetryで分かること、Claude APIのusageとツール呼び出しの突き合わせ方、再送分まで数えるツール別コスト式、実測したバイト→トークン換算、キャッシュで順位が逆転する40リクエストの計算例をまとめました。

最終更新：2026年10月27日 ／ 対象：Claude Codeの/context・/usage・OpenTelemetry出力、Claude APIのusageとトークンカウント、OpenTelemetryのMCPセマンティック規約（Development段階）、Claude Sonnet 5.5の料金

MCPのトークン消費（MCP Token）については「どう減らすか」の記事がたくさんあります。この記事が扱うのは、その手前の問いです。実際にトークンを使っているのはどのMCPサーバーの、どのツールなのか。この数字をそのまま見せてくれる画面はありません。モデルのAPIはリクエスト単位でトークンを数え、MCP側の仕組みはツール単位で呼び出しを数えるからです。この記事では、それぞれのデータがどこにあるか、どう突き合わせるかを説明し、多くのレポートが見落とす「後のリクエストで毎回送り直されるツール結果」まで数えるツール別のコスト式を紹介します。

なお、ここでの「トークン」はLLMのトークン（コンテキストと課金の単位）のことで、APIキーやOAuthのアクセストークンのことではありません。

結論（30秒で読める要約）

  • MCPツール単位でトークンを請求するAPIはありません。Claude APIはリクエスト単位でトークンを返し、MCPのスパンやゲートウェイのログはツール単位で呼び出し回数とバイト数を記録します。ツール別のMCP Token使用量は、この2つを突き合わせて自分で計算するものです。
  • ツールのトークンは2か所で発生します。定義（読み込まれている間は毎リクエスト）と結果（追加されたリクエストと、消去・要約されるまでの以降すべてのリクエスト）です。ツール別コストはおおよそ「定義トークン × リクエスト数 ＋ Σ 結果トークン × 残りリクエスト数」です。
  • Claude Codeはこの一部をすでに出してくれます。/contextは現在のコンテキストを種類別に、Pro・Max・Team・Enterpriseプランの/usageはMCPサーバーごとの使用割合を表示します。OpenTelemetry出力ではトークン数にmcp_server.nameとmcp_tool.nameが付きます（実名になるのはOTEL_LOG_TOOL_DETAILS=1のときだけ）。
  • 呼び出し回数での順位付けは当てになりません。筆者の40リクエストの計算例では、序盤に3回呼ばれたツールの方が、終盤に4回呼ばれ結果が2倍大きいツールより、キャッシュなしでは高くつきました。キャッシュありでは順位が元に戻ります。
  • バイト数はトークン数ではありません。筆者がo200k_baseトークナイザーで測ったところ、ログ・JSON・日本語で1トークンあたり2.68〜4.80バイトと開きがありました。ログのバイト数を換算する前に、ツールごとにClaudeのトークンカウントAPIで比率を測っておきます。

目次

  1. MCPトークンの帰属（アトリビューション）とは
  2. データはどこにあるか（それぞれ何が欠けているか）
  3. ツール別コストの計算式
  4. 計算例：40リクエストのセッションで3つのツールを比べる
  5. Claude Code：/context、/usage、OpenTelemetry
  6. Claude APIで自作したエージェント：ツール別の台帳を作る
  7. サーバー・ゲートウェイ側：バイト数からトークン数へ
  8. チェックリスト
  9. よくあるハマりどころ
  10. NodeFlareならこう解決できる
  11. FAQ

1. MCPトークンの帰属（アトリビューション）とは

MCPトークンの帰属とは、エージェントが使ったLLMのトークンを、その原因になったMCPサーバーとツールに割り当てることです。「最初にどのサーバーを削る・絞る・サブエージェントへ移すべきか」に、勘ではなく数字で答えるために行います。

これが必要なのは、モデルが課金するのはリクエストであってツールではないからです。1回のリクエストに50個のツール定義と過去10回分の呼び出し結果が載っていても、レスポンスのusageは合計しか返しません。帰属は、この合計を各ツールが載せた分に分け直す作業です。

2. データはどこにあるか（それぞれ何が欠けているか）

どのデータ源も問いの一部にしか答えません。全部に答えるものはありません。

データ源 単位 トークン数 サーバー名・ツール名
Claude APIのレスポンスのusage モデルへのリクエストごと あり（input_tokens、cache_creation_input_tokens、cache_read_input_tokens、output_tokens） なし
Claude APIのトークンカウント（/v1/messages/count_tokens） 送った内容ごと あり（送信前の見積もり） 何を数えるかは自分で決める
Claude Codeの/context 現在のコンテキスト（種類別） あり 種類別。改善の提案つき
Claude Codeの/usage セッション合計。プランではMCPサーバーごとの最近の使用割合 合計と割合（%） MCPサーバー単位であり
Claude CodeのOpenTelemetry claude_code.token.usage リクエストごと あり（type別） mcp_server.name、mcp_tool.name（OTEL_LOG_TOOL_DETAILS=1でないと伏せ字）
Claude CodeのOpenTelemetry claude_code.tool_resultイベント ツール呼び出しごと バイト数のみ（tool_input_size_bytes、tool_result_size_bytes） tool_name。フラグ有効時はtool_parametersにMCPサーバー名とツール名
OpenTelemetryのMCPスパン（セマンティック規約、Development段階） MCP呼び出しごと MCPスパンにはなし。トークン数はLLM呼び出しのスパン側 mcp.method.name、gen_ai.tool.name
サーバー・ゲートウェイのログ 呼び出しごと たいていバイト数 ツール名

出典：Claude Codeドキュメント（Manage costs、Monitoring）、Claude APIドキュメント（料金、トークンカウント）、OpenTelemetryのGenAI・MCPセマンティック規約。

ここから言えることは2つです。

  • モデルの側にあるものはトークンを知っていて、MCPサーバーの側にあるものはツールを知っています。両側から1件ずつ記録を取るか、Claude Codeのように自分のリクエストにツール名を付けてくれるクライアントを使う必要があります。
  • サーバー側のバイト数はトークン数に換算しなければならず、その比率はツールによって違います（7章）。

3. ツール別コストの計算式

1セッションでのあるツールのMCP Tokenコストは、定義のコストと、そのツールが返したすべての結果の「居座りコスト」の合計です。

記号の定義（筆者の式）：

  • N：セッション内のモデルへのリクエスト数
  • D：ツールが読み込まれている間の定義トークン（名前・説明・inputSchema）
  • 呼び出しiごとに、Rᵢ：結果のトークン数、kᵢ：その呼び出しを出したリクエストの番号。結果はリクエストkᵢ＋1で初めて送られ、残りN − kᵢ回のリクエストで履歴に残ります。

ツール1つに帰属するトークン：

tokens(tool) = D × 読み込まれていたリクエスト数 + Σᵢ Rᵢ × (N − kᵢ)

プロンプトキャッシュが効いている場合、各結果は1回キャッシュに書き込まれ、以降のリクエストでは毎回読み出されます。

cost_cached(tool)   = Σᵢ [ Rᵢ × 書き込み単価 + Rᵢ × (N − kᵢ − 1) × 読み出し単価 ]  (+ 定義のコスト)
cost_uncached(tool) = Σᵢ Rᵢ × (N − kᵢ) × 入力単価                                (+ 定義のコスト)

補正：

  • コンテキスト編集でリクエストcのときに結果が消された場合や、要約（コンパクション）で消えた場合は、その結果についてNをcに置き換えます。
  • ツール検索（Claude Codeの既定）を使っている場合、ツールが見つかるまでDはほぼゼロで、見つかった後は定義全体が残ります。「読み込まれていたリクエスト数」はそこから数えます。
  • ツール呼び出し自体の出力トークン（モデルが書く引数）は小さいので、ここでは省いています。

同じツールでもセッションによって安かったり高かったりするのは、2つ目の項があるからです。40回中5回目に返った結果は、そのあと35回送り直されます。

4. 計算例：40リクエストのセッションで3つのツールを比べる

この例では、結果のトークン数が一番多いツールは、キャッシュなしでは一番高いツールになりません。キャッシュありにすると、順位がまた入れ替わります。

前提（筆者の計算で、実測ではありません）：

  • Claude Sonnet 5.5で、N＝40リクエストのセッション1回分。100万トークンあたり入力2ドル、5分キャッシュの書き込み2.50ドル、キャッシュ読み出し0.10ドル（Anthropic料金ページ、2026年10月時点）。
  • search_logs：3回呼び出し、結果は各8,000トークン。リクエスト5・12・20で呼び出し。
  • get_ticket：10回呼び出し、結果は各600トークン。リクエスト3・6・9…30で呼び出し。
  • browser_snapshot：4回呼び出し、結果は各12,000トークン。リクエスト30・32・34・36で呼び出し。
  • 消去や要約はなし。定義のコストは後で別に計算します。
ツール 呼び出し回数 結果のトークン数 送り直されたトークン数 Σ R × (N − k) キャッシュなし キャッシュあり
search_logs 3 24,000 664,000 1.328ドル 0.124ドル
browser_snapshot 4 48,000 336,000 0.672ドル 0.149ドル
get_ticket 10 6,000 141,000 0.282ドル 0.029ドル

1行だけ手で確かめます。search_logsは35＋28＋20＝83回送られるので、83 × 8,000＝664,000トークン、664,000 × 2ドル ÷ 100万＝1.328ドルです。キャッシュありなら、書き込みが24,000 × 2.50ドル ÷ 100万＝0.060ドル、読み出しが8,000 × (34＋27＋19) × 0.10ドル ÷ 100万＝0.064ドルです。

読み方：

  • 呼び出し回数で見ればget_ticket、結果の大きさで見ればbrowser_snapshot、キャッシュなしの請求額で見ればsearch_logsが1位です。序盤に返った結果は、セッションの最後まで乗り続けます。
  • キャッシュありでは、1位がbrowser_snapshotに戻ります。この料金ではキャッシュ読み出しが入力の20分の1なので、結果の大きさで決まる1回目の書き込みが効いてくるからです。ツールの順位は、実際のキャッシュの効き方で計算します。
  • 呼び出すタイミングだけでもコストは大きく変わります。同じ8,000トークンの結果でも、リクエスト5で返れば（35回送られる）キャッシュなしで0.56ドル、リクエスト35なら（5回）0.08ドルです。

定義も同じレポートに入れます。Anthropicのツール検索の記事では、GitHubのMCPサーバーは35ツールで約26Kトークンとされています。これを40リクエストすべてに最初から載せると1,040,000トークンで、キャッシュなしなら2.08ドル、キャッシュありなら約0.166ドル（書き込み1回2.50ドル＋読み出し39回0.10ドル、いずれも100万トークンあたり）です。ツールを最初から全部読み込むクライアントでは、サーバー1つの定義が、上の3ツールの結果の合計（送り直し1,141,000トークン）とほぼ同じになります。ツール検索が有効なら、この行は実際に見つかったツールの分だけに縮みます。

5. Claude Code：/context、/usage、OpenTelemetry

Claude Codeでは3段階の細かさで確認できます。手軽なものから順に使います。

機能 MCPについて分かること 使う場面
/context 現在のコンテキストの種類別の内訳（改善の提案つき） 「いま何がコンテキストに載っているか」
/usage（Sessionブロック） モデル別のトークン数と推定コスト、プロンプトキャッシュの状況（メインの会話のみ） 「このセッションはいくらかかったか」
/usage（プランの内訳） スキル・サブエージェント・プラグイン・MCPサーバーごとの最近の使用割合。直近24時間か7日間 「どのMCPサーバーが一番使っているか」
OpenTelemetry出力 MCPサーバー名とツール名が付いたリクエストごとのトークン数・コスト、呼び出しごとのtool_resultイベント（バイト数） チーム全体のツール別レポートを自社の監視基盤で作る

数字の読み方に関わる、ドキュメント上の注意点：

  • /usageでのMCPサーバーの割合は「そのサーバーのツール結果を使ったリクエストだけを数える」ものです。Claude Code v2.1.222より前は、一度そのサーバーを呼ぶと以降のリクエストがすべてそのサーバーに計上され、割合が大きく出ていました。古いスクリーンショットを信じる前にアップデートしてください。
  • プランの内訳は、そのマシン上のセッション履歴から計算されます。ほかの端末やclaude.aiでの使用分は含まれません。
  • OpenTelemetryのトークン数のうち、inputにはキャッシュの読み出しと書き込みが含まれず、それぞれcacheReadとcacheCreationとして数えられます。入力側の総量は3つを足して見ます。
  • カウンターに付くMCPサーバー名・ツール名は、既定では"custom"や"third-party"のような伏せ字になります。実名を出すにはOTEL_LOG_TOOL_DETAILS=1を設定します。このフラグはツールの引数も記録するので、ログの方針と照らしてから有効にしてください。何を記録してはいけないかはMCP監査ログのガイドにまとめています。

最小限のOpenTelemetry設定（最初の3つはClaude Codeの監視ドキュメントにある変数で、エンドポイントはコレクター向けの標準的なOTLP変数です）：

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_ENDPOINT=http://your-collector:4317
export OTEL_LOG_TOOL_DETAILS=1   # MCPサーバー名・ツール名を実名で出す（ツールの入力も記録される）

あとはclaude_code.token.usageをmcp_server.nameとmcp_tool.nameで集計し、claude_code.tool_resultイベントのtool_result_size_bytesで、大きな結果を返した呼び出しを探します。

6. Claude APIで自作したエージェント：ツール別の台帳を作る

自分でエージェントのループを書いているなら、ツール結果1件ごとに1行記録し、セッションの終わりに居座りコストを計算します。APIはやってくれませんが、ループの中ではツール名もリクエスト番号もすでに分かっています。

手順1：各結果をトークン数で測ります。ClaudeのトークンカウントAPIを使えば、実際のリクエストを送らずに数えられます。下の関数は結果をただのテキストとして数え、1文字だけのメッセージを基準として差し引きます。tool_resultの小さな枠の分は含まれません。

手順2：3章の式でレポートを作ります。

import anthropic

client = anthropic.Anthropic()
MODEL = "claude-sonnet-5-5"

def text_tokens(text: str) -> int:
    """ツール結果のテキストが、Claudeのトークナイザーで何トークンかを近似する。"""
    base = client.messages.count_tokens(
        model=MODEL, messages=[{"role": "user", "content": "x"}]).input_tokens
    full = client.messages.count_tokens(
        model=MODEL, messages=[{"role": "user", "content": text}]).input_tokens
    return full - base

ledger = []  # (ツール名, リクエスト番号, 結果のトークン数)
# エージェントのループで、リクエストkで出たツール呼び出しを実行した後に：
#   ledger.append((tool_use.name, k, text_tokens(result_text)))

def residency_report(ledger, n_requests, price_in=2.0, price_write=2.5, price_read=0.10):
    """単価は100万トークンあたりのドル（既定値はClaude Sonnet 5.5）。"""
    report = {}
    for name, k, r in ledger:
        row = report.setdefault(name, {"calls": 0, "result_tokens": 0, "resent_tokens": 0,
                                       "usd_uncached": 0.0, "usd_cached": 0.0})
        remaining = n_requests - k
        row["calls"] += 1
        row["result_tokens"] += r
        row["resent_tokens"] += r * remaining
        row["usd_uncached"] += r * remaining * price_in / 1e6
        row["usd_cached"] += (r * price_write + r * max(remaining - 1, 0) * price_read) / 1e6
    return dict(sorted(report.items(), key=lambda kv: -kv[1]["usd_cached"]))

4章の例をこの関数に入れると、表と同じ数字が返ります。運用上のポイント：

  • 結果を毎回数えると、トークンカウントAPIへの呼び出しが増えます。ツールごとに数回分だけ測って平均を出し、それを使い回せば十分です。
  • 台帳と一緒に、各リクエスト自体のusageも保存しておきます。ツール別の見積もりの合計が実際の入力とかけ離れていたら、ほかの何か（大きくなっていくシステムプロンプト、思考、画像など）がコンテキストに入っています。
  • コンテキスト編集や要約を使っているなら、それが起きたリクエスト番号も記録し、該当する結果のremainingをそこで打ち切ります。

7. サーバー・ゲートウェイ側：バイト数からトークン数へ

サーバー側で見えるのはたいていバイト数で、トークン数ではありません。換算の比率は中身によって変わります。

筆者は4種類のデータをo200k_baseトークナイザー（npmのgpt-tokenizerパッケージ）で測りました。Claudeのトークナイザーではないので、比率そのものより「どれくらいばらつくか」の目安として見てください。

データ（筆者のテストデータ） バイト数 トークン数（o200k_base） 1トークンあたりのバイト数
ログ200行（タイムスタンプ、ID入り） 21,999 8,199 2.68
GitHub風のissue 30件、整形済みJSON 11,724 3,602 3.25
同じissue、圧縮したJSON 9,533 2,642 3.61
日本語の文章（UTF-8） 5,999 1,250 4.80

帰属の計算にとっての意味：

  • 「バイト数 ÷ 4」で一律に換算すると、ログの多いツールは約3分の1少なく見積もられ（4 ÷ 2.68 ≒ 1.49倍のトークンがある）、日本語の文章は多く見積もられます。
  • ツールごとに1回だけ較正します。実際のレスポンスをいくつかClaudeのトークンカウントAPIで数えて比率を保存し、ログのres_bytesやtool_result_size_bytesをツールごとに換算します。
  • OpenTelemetryのMCPセマンティック規約が記述するのは呼び出しそのもの（mcp.method.name、gen_ai.tool.name、mcp.session.id、mcp.protocol.version）です。トークン数（gen_ai.usage.input_tokens、gen_ai.usage.output_tokens）はLLM呼び出しのスパンに付きます。両方を同じトレースに入れて、トレースで結合します。MCPの規約はまだDevelopment段階なので、使うバージョンを固定しておきます。

重いツールが分かったら、元から直します。項目の絞り込み、ページング、resource_linkについては、MCPツールのレスポンスを小さくするガイドで解説しています。長いセッションで古い結果がかさんでいるなら、古いツール結果を消すガイドを参照してください。

8. チェックリスト

  • [ ] ワークフローごとに、1セッションの平均リクエスト数（N）を把握している
  • [ ] MCPツールごとに、バイト→トークンの比率か、結果の平均トークン数を測ってある
  • [ ] ツール別レポートに、初回の結果サイズだけでなく送り直し分のトークンが入っている
  • [ ] 定義のトークンをサーバー単位で数え、クライアントが最初に全部読み込むのかツール検索を使うのかを把握している
  • [ ] トークンの合計に、input_tokensだけでなくキャッシュの読み出しと書き込みも入っている
  • [ ] 順位を、実際のキャッシュの効き方（/usageのヒット率やcache_read_input_tokens）で計算している
  • [ ] Claude CodeのOTEL_LOG_TOOL_DETAILS=1は、ツールの入力を記録してよい環境でだけ有効にしている
  • [ ] メインの会話だけでなく、サブエージェントやチームメイトのリクエストも数えている
  • [ ] 対策（削る、絞る、コード実行）のたびに、同じレポートで前後を比べている

9. よくあるハマりどころ

症状 原因 対処
呼び出し回数1位のツールが実は安い 結果が小さく、呼ばれるのが終盤 回数ではなくΣ R × (N − k)で順位を付ける
ツール別の合計が請求額よりずっと小さい 初回の結果トークンしか数えていない 3章の送り直しの項を足す
OpenTelemetryにcustomやthird-partyと出る 既定で名前が伏せられている OTEL_LOG_TOOL_DETAILS=1を設定する（記録内容も確認する）
古いバージョンで、1つのMCPサーバーが/usageの大半を占める v2.1.222より前は、以降のリクエストがすべてそのサーバーに計上されていた Claude Codeを更新して見直す
トークンの合計が少なすぎる cacheReadとcacheCreationを足さずにinputだけ見ている 入力側の種類をすべて足す
バイト数からの見積もりが30〜50%ずれる 全ツールに同じ比率を使っている ツールごとにトークンカウントで較正する
メインの会話の数字は普通なのに請求が高い サブエージェントやチームメイトが別にリクエストを送っている。/usageのキャッシュ行はメインの会話のみ サブエージェント分もレポートに入れる
一番重いツールを直してもコストが変わらない ツールを最初に全部読み込むクライアントで、結果より定義が大きい 定義もサーバー単位で数える

10. NodeFlareならこう解決できる

NodeFlareは、GitHubリポジトリのMCPサーバーをプロキシの裏で動かし、すべてのリクエストを記録したうえで、サーバーごとにトークン関連の設定を用意しています。以下の設定は、どれもサーバーのコード変更が不要です。

課題1：どのツールが大きな結果を返しているか見えない（7章）。NodeFlareのリクエストごとのログには、tool_name、req_bytes、res_bytes、duration_ms、outcome、session_id、caller_kindが記録されます。引数は名前（arg_keys）だけで、値は残りません。ツールで絞り込み、res_bytesに較正した比率を掛ければ、計算式のRが手に入ります。ログの表示期間は1時間・24時間・7日・30日（Freeは1時間固定）、保存期間はFreeが7日、ProとTeamが30日です。

課題2：重いツールの結果が、セッションの最後まで送り直される（3〜4章）。Code Execution（tool_code_mode）を有効にします。サーバーはrun_codeとsearch_toolsを公開し、モデルはtools.*を呼ぶJavaScriptを書きます。NodeFlareがそれをサンドボックスで実行するので、複数のツール呼び出しが1回の実行にまとまり、会話に入るのは実行の最終結果だけになります。既定ではタイムアウト600秒、1回の実行で最大50回のツール呼び出し、V8ヒープ128MBです。例（4章のモデルでの筆者の計算で、NodeFlareの計測値ではありません）：コードでsearch_logsの結果を1回8,000トークンから800トークンに絞れれば、このツールの送り直しは664,000から66,400トークンに減り、コストはキャッシュなしで1.328ドルから0.133ドル、キャッシュありで0.124ドルから約0.012ドルになります。

課題3：クライアントがツールを最初に全部読み込むため、定義が大半を占める（4章）。tool_search_modeを有効にします。ツール一覧がsearch_toolsとcall_toolの2つのメタツールに置き換わります。GEMINI_API_KEYを設定すれば意味検索、なければキーワード検索で探します。

課題4：エージェントが、使わないツールまで読み込んで呼んでしまう。tool_list_filter_by_scopeを有効にし、エージェントごとにtools:call:get_ticketのようなスコープ付きのAPIキーを渡します。tools/listには、そのキーで呼べるツールだけが、スキーマはそのままで表示されます。

課題5：残したツールの説明文が長い。tool_schema_slimを有効にします。500文字を超える説明文が切り詰められ（UTF-8の文字境界で安全に）、名前と入力スキーマはそのまま残ります。

NodeFlareは決まった削減率を公表していません。設定を変えるたびに、6章のレポートで前後を比べてください。

最小の始め方：

  1. nodeflare.techにサインインし、MCPサーバーのGitHub URLを入れます。ランタイム、通信方式、起動コマンドは自動で検出・入力されます。
  2. デプロイしたら、サーバー設定でtool_code_mode（必要ならtool_search_modeも）を有効にします。
  3. サーバーのURLとAPIキーをClaude、Cursor、自作のエージェントに登録し、ログを見ます。

MCPサーバー1つまでは無料で試せます（Freeプラン：1サーバー、月30 GB時間のコンピュート）。→ nodeflare.techで始める

11. FAQ

MCPサーバーごとのトークン使用量はどう確認する？

Pro・Max・Team・EnterpriseプランのClaude Codeなら/usageを実行します。内訳にMCPサーバーごとの最近の使用割合が出ます。チーム全体の数字が欲しいなら、OpenTelemetry出力を有効にしてclaude_code.token.usageをmcp_server.nameで集計します。自作のエージェントなら、リクエストごとにツール名を記録し、この記事の式で割合を出します。

一番トークンを使っているMCPツールはどれ？

「結果のトークン数 × 残りのリクエスト数」の合計が一番大きいツールに、読み込まれている間の定義のコストを足したものが一番大きいツールです。呼び出し回数だけでは判断できません。筆者の40リクエストの例では、序盤に3回呼ばれたツールが、結果が2倍大きく終盤に呼ばれたツールよりキャッシュなしで高くつきました。

Claude CodeでMCPのトークン使用量は見られる？

見られます。3段階あり、/contextは現在のコンテキストを種類別に、/usageはセッションの合計と（プランでは）MCPサーバーごとの最近の使用割合を表示します。OpenTelemetry出力では、トークン数にMCPサーバー名とツール名が付きます。

OpenTelemetryでMCPのトークン使用量を追跡するには？

Claude CodeならCLAUDE_CODE_ENABLE_TELEMETRY=1を設定し、メトリクスとログの出力先をOTLPにし、実名を出すためにOTEL_LOG_TOOL_DETAILS=1を設定します。自作のエージェントなら、gen_ai.usage.input_tokensを持つLLM呼び出しのスパンと、gen_ai.tool.nameを持つMCPスパンを同じトレースに記録し、結合します。

OpenTelemetryでMCPサーバー名が「custom」や「third-party」になるのはなぜ？

Claude Codeは、コストとトークンのカウンターに付くエージェント・スキル・プラグイン・MCPサーバー・MCPツールの名前を、既定で伏せ字にするからです。OTEL_LOG_TOOL_DETAILS=1を設定すると実名になります。ただしツールの引数も記録されるので、それが許される環境でだけ有効にしてください。

MCPのレスポンスのバイト数をトークン数に換算するには？

ツールごとに比率を測ります。筆者がo200k_baseトークナイザーで試したところ、ログは1トークンあたり2.68バイト、日本語の文章は4.80バイトでした。実際のレスポンスをいくつかClaudeのトークンカウントAPIで数え、その比率でツールのログのバイト数を換算します。

Claude APIはツールごとのトークン数を返す？

返しません。usageはリクエスト全体（入力、キャッシュ書き込み、キャッシュ読み出し、出力）の数字です。ツールに割り当てるには、各リクエストにどのツール結果が載っていたかを記録し、トークンカウントAPIなどで測る必要があります。

MCPツールの結果は、呼び出しの後もトークンを使う？

使います。結果は会話に残り、消去か要約されるまで、以降のリクエストで毎回送り直されます。プロンプトキャッシュが効けば、送り直し分は入力の2ドルではなくキャッシュ読み出しの単価（Claude Sonnet 5.5で100万トークンあたり0.10ドル）になりますが、数には入ります。

プロンプトキャッシュで、一番高いMCPツールは変わる？

変わることがあります。キャッシュなしでは、早い段階で返り何度も送り直される結果が効きます。キャッシュありでは、Sonnet 5.5の読み出しが入力の20分の1なので、結果の大きさで決まる1回目の書き込みが効きます。筆者の例でも、キャッシュの有無で一番高いツールが入れ替わりました。

ここでいう「MCP Token」はAPIトークンのこと？

違います。この記事は、MCPのツール定義と結果が消費するLLMのトークンの話です。MCPサーバーのAPIキーやOAuthのアクセストークンは、セキュリティの話題として別に扱っています。

まとめ

ツール別のMCP Token使用量は、どのシステムもそのままは出してくれません。モデルのAPIはリクエスト単位でトークンを、MCP側はツール単位で呼び出しを数えるからです。この記事の式で両者を突き合わせます。式は、ツールの定義に、そのツールが返したすべての結果 ×「それを送り直したリクエスト数」を足したものです。Claude Codeならまず/contextと/usageを見て、チーム全体のレポートには実名付きのOpenTelemetryを使います。自作のエージェントならツール別の台帳を付けます。サーバー側では、ツールごとに較正した比率でバイト数をトークン数に換算します。実際のキャッシュの効き方で順位を付け、1位のツールを直し、もう一度測る。この繰り返しです。

参考資料

NodeFlare

MCP専用ホスティングサービス

GitHubにあるMCPを簡単デプロイ・簡単運用で最適化
無料で始める

他の記事

MCPセキュリティ2026年10月27日

MCPセキュリティテストの実践：自社MCPサーバーを検証する34項目のテスト計画とプローブ【MCP Security 2026-07-28版】

自社のMCPサーバーをリリース前とCIで検証するためのMCPセキュリティテスト。2026-07-28版仕様にもとづく期待応答（401、insufficient_scopeの403、Originの403、-32020）付きの34項目、仕込んだ4つのバグを誤検出なしで見つけたプローブ、ツール比較、CI設定、実際の事例。

MCPホスティング2026年10月27日

MCPサーバーのヘルスチェックと死活監視：pingが廃止された2026-07-28仕様で何を確認すべきか【MCP Hosting】

MCPサーバーのヘルスチェックは何を叩けばいいのか。2026-07-28仕様でpingは廃止され、GETは400を返すため、一般的な死活監視はそのままでは誤検知します。正常なサーバーと上流APIキーが切れたサーバーに10種類のプローブを実際に送った結果、3層のチェック設計、Docker・Kubernetes・Cloud Runの設定例、アラート設計、スケールゼロとの費用計算までまとめました。

MCPトークン2026年10月26日

MCP Tokenを減らす「ツールにしない」設計：ResourcesとPromptsの使い分けと費用計算【2026年版】

MCPサーバーのデータや手順は、ツール・リソース・プロンプトのどれで出すとトークンが少ないのか。省ける1往復、定義のコスト、プロンプトとサーバー説明文の比較をClaude Sonnet 5.5の料金で計算し、Claude Code・VS Code・Cursor・Claude APIの対応状況と2026-07-28版仕様の変更点をまとめました。

他の記事を読む
どのMCPサーバーがトークンを食っている？MCP Token使用量をサーバー・ツール別に計測する方法【2026年版】 | Blog | Nodeflare