MCPツールのレスポンスでトークンを浪費しない8つの設計｜実測で見る結果サイズの削り方【2026年版】

最終更新：2026年10月15日／対象：MCP仕様 2026-07-28（ツール結果）、Claude CodeのMCP出力上限、Cursor、Claude 5.5の料金

MCPのトークン消費というと、ツール定義（ツール一覧）の話になりがちです。しかし実際には、ツールが返す1回のレスポンスが、ツール一覧全体より多くのトークンを使うこともあります。この記事はMCPサーバーを作る人・運用する人向けに、レスポンスの大きさの実測、大きすぎる結果をクライアントがどう扱うか、そしてツール結果のトークン消費を抑える8つの設計パターンをまとめたものです。

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

ツールの結果は1回では済まず、会話に残っている間、毎ターン入力として送り直されます。Claude Sonnet 5.5で試算すると、2万トークンの結果がその後5ターン残ると1タスクあたり0.24ドル、2,000トークンに絞れば0.024ドルです。
大きくなる主な原因は、APIのレスポンスをそのまま返すことです。50件の課題一覧を実測したところ、APIのオブジェクトをそのまま返すと86,085バイト（JSON圧縮済み）、必要な7項目だけなら8,650バイト（10%）、最初の10件だけなら1,759バイト（2%）でした。
クライアントも上限や退避の仕組みを持っていますが、サーバー側では制御できません。Claude Codeは1万トークン超で警告し、既定で2万5,000トークンに制限し、5万文字を超えるテキスト結果はファイルに保存します。Cursorも長い出力をファイルに書き出します。そのぶん、モデルが読みに行くターンが増えます。
対策はサーバー側で行うのが基本です。必要な項目だけ返す、小さな既定値でページングする、response_format を用意する、同じデータを2回送らない（structuredContent とテキスト）、大きなデータは resource_link で返す、意味のない内部IDより名前を返す、切り詰めたときは次にどうすればよいかを書く、の8つです。
サーバーのコードを変えられない場合は、Code Executionでサンドボックス内で絞り込み、最終結果だけをモデルに渡します。

ツールのレスポンスがMCPのトークン消費を増やす理由
MCPツールのレスポンスはどれくらい大きいのか（実測）
大きすぎる結果をクライアントはどう扱うか
MCPツールのレスポンスを小さくする8つのパターン
実装例（TypeScript）
レスポンスのトークン数を測る方法
チェックリスト
よくあるハマりどころ
NodeFlareならこう解決できる
よくある質問

1. ツールのレスポンスがMCPのトークン消費を増やす理由

ツール結果のトークンとは、MCPツールが tools/call で返した内容に使われるLLMの入力トークンのことです。ツール一覧を読み込むための固定費（ツール定義のトークン）とは別物です。トークン消費の4つの内訳はMCPのトークン消費の解説記事にまとめています。

ツールの結果が高くつく理由は2つあります。

読み直しが発生する。ツールを直接呼ぶ場合、クライアントは結果を会話履歴に追加します。その後のターンでは履歴全体が毎回入力として送られるため、結果は残っているターンの数だけ課金されます。
既定では上限がない。MCPの仕様には、ツール結果のサイズ上限はありません。REST APIを中継するだけの list_* ツールは、上流のレスポンスをそのまま返すと数百KBになることもあります。

計算例（筆者の試算）です。前提は、Claude Sonnet 5.5の入力単価が100万トークンあたり2ドル（Anthropic料金ページ、2026年10月時点）、プロンプトキャッシュなし、結果を読むターンとその後5ターンの合計6回送られる、とします。

結果のサイズ	結果ぶんの課金対象入力トークン	1タスクあたり	1,000タスクあたり
20,000トークン	20,000 × 6 = 120,000	0.24ドル	240ドル
2,000トークン	2,000 × 6 = 12,000	0.024ドル	24ドル

計算式は「トークン数 × 6 ÷ 1,000,000 × 2ドル」です。プロンプトキャッシュを使えば下がりますが、ゼロにはなりません。後半5回の読み直しがキャッシュヒット（Sonnet 5.5のキャッシュ読み取りは100万トークンあたり0.10ドル）だった場合、2万トークンの結果は 20,000 × 2 ÷ 100万 + 100,000 × 0.10 ÷ 100万 = 0.04 + 0.01 = 0.05ドルです（キャッシュ書き込みの割増は含みません）。お金だけでなく、結果が小さければコンテキストウィンドウにも余裕が残ります。

データを計算にしか使わないなら、Code Executionでそもそもコンテキストに載せない方法もあります。どんなときに得をするかはCode Executionの損益分岐の記事で試算しました。この記事では、より手軽な最初の一歩として、レスポンスそのものを小さくする方法を扱います。

2. MCPツールのレスポンスはどれくらい大きいのか（実測）

一般的な課題管理サービスのREST APIを模した課題データを50件作り（URL、数値IDとノードID、ネストしたユーザー情報、ラベル、リアクション、日時、約300文字の本文）、5通りの返し方でUTF-8のサイズを測りました。数値は筆者が測ったバイト数で、トークン数ではありません。トークン数はモデルのトークナイザーによって変わるため、実際のペイロードはトークン数計測APIで確かめてください（6章）。

返し方	サイズ（バイト）	圧縮済みの全項目との比
A. 全項目、整形済みJSON（インデント2）	109,036	127%
B. 全項目、圧縮JSON	86,085	100%
Bを2回送る（`structuredContent` とテキスト）	172,170	200%
C. 必要な7項目だけ、圧縮JSON	8,650	10.0%
D. 同じ7項目をパイプ区切りの表で	4,698	5.5%
E. 7項目、最初の10件とカーソル	1,759	2.0%

7項目は number、title、state、author、labels（名前のみ）、comments、updated（日付のみ）です。

表から分かることは次のとおりです。

いちばん効くのは項目の選別です。URL、内部ID、アバター画像のリンク、空の項目を外すだけで90%減りました。
ページングがさらに効きます。50件を10件にすると、項目を絞った後のサイズがさらに80%減りました。
空白の削除も効きますが、効果は小さめです。整形をやめると21%減りました（1 − 86,085 ÷ 109,036）。
二重送信はすべてを2倍にします。クライアントが structuredContent とそのテキスト版の両方をモデルに渡すと、コストは倍になります。実際にどうなるかはクライアント次第です（4.4節）。
Aは10万文字を超えるため、Claude Codeではコンテキストに入れずファイルに保存されます（3章）。

3. 大きすぎる結果をクライアントはどう扱うか

クライアントはそれぞれのやり方でコンテキストを守っていますが、データを小さくしてくれるわけではありません。切り捨てるか、ファイルに逃がして後でモデルに読ませるかのどちらかです。

クライアント	大きなMCPツール結果の扱い（2026年10月時点）	出典
Claude Code	出力が1万トークンを超えると警告。既定で2万5,000トークンに制限（`MAX_MCP_OUTPUT_TOKENS`）。5万文字を超える成功時のテキスト結果はファイルに保存し、モデルにはパスを渡す。ツールは `anthropic/maxResultSizeChars` で独自のテキスト上限を宣言できる	Claude Code公式ドキュメント（MCP）
Cursor	長いツール出力は切り捨てずにファイルへ書き出し、エージェントが `tail` などで必要な部分を読む	Cursorブログ（2026年1月6日）
Anthropicのツール設計ガイド	「Claude Codeでは、ツールのレスポンスを既定で2万5,000トークンに制限している」。ページング、範囲指定、絞り込み、切り詰めを妥当な既定値で実装するよう推奨	Writing effective tools for agents

ファイルに逃がせばコンテキストはあふれませんが、モデルはファイルを読むためにターンを追加で使い、読むたびにトークンが増えます。最初から必要な2,000トークンだけを返すサーバーのほうが、安くて速く済みます。

4. MCPツールのレスポンスを小さくする8つのパターン

#	パターン	効果の目安	変更する場所
1	モデルが使う項目だけ返す	大（2章では90%減）	サーバー
2	小さな既定 `limit` とカーソルでページングする	一覧・検索系で大	サーバーと説明文
3	`response_format`（concise / detailed）を用意する	Anthropicの例で約3分の1	サーバーとスキーマ
4	同じデータを2回送らない	二重送信時は最大50%減	サーバー
5	大きなデータは `resource_link` で返す	本体を結果から外せる	サーバー（とresources）
6	意味のないIDやURLより名前を返す	トークン減と精度向上	サーバー
7	JSONを圧縮する。単純な一覧は表形式にする	2章では21〜46%減	サーバー
8	切り詰めやエラーで次の行動を示す	無駄な再試行を防ぐ	サーバー

4.1 モデルが使う項目だけ返す

上流のオブジェクトは、返す前に用途に合わせた小さな形へ変換します。REST APIのレスポンスをそのまま流さないことが基本です。Anthropicのツール設計ガイドでも、uuid、256px_image_url、mime_type のような低レベルの識別子は避け、name、image_url、file_type のような項目を返すよう勧めています。タスクによって必要な項目が違うなら、選べる値を列挙した fields パラメーターを任意で用意します。

4.2 小さな既定値とカーソルでページングする

一覧・検索系のツールには必ず limit を設け、既定値は小さく（10〜20件）、上限も決めます。結果には next_cursor と total を含めます。説明文の最初の1文で「結果はページ単位で返る」と書いておくと、モデルは続きを取りに行けると分かります。Anthropicのガイドはこれを「妥当な既定値（sensible default parameter values）」と呼んでいます。

4.3 response_format パラメーターを用意する

Anthropicは、response_format という列挙型のパラメーターを用意し、エージェントが concise（簡潔）と detailed（詳細）を選べるようにする方法を紹介しています。Slackの例では、詳細版が206トークン、簡潔版が72トークンで、約3分の1でした。既定は concise にしておきます。

4.4 同じデータを2回送らない

MCP仕様（2026-07-28）では、structuredContent を返すツールは、後方互換のためにシリアライズしたJSONをテキストブロックでも返すべき（SHOULD）とされています。クライアントが両方をモデルのコンテキストに入れる場合、結果は毎回2倍課金されます（2章の「Bを2回送る」）。

現実的な選択肢は次のとおりです。

outputSchema が不要なら、JSONはテキストブロック1つだけで返す。
outputSchema を使うなら、クライアントが何をモデルに渡しているか確認する。構造化データ自体を小さくしておけば、二重になっても影響は小さい。
仕様の配列の例では、テキストブロックに人が読む1行の要約（「Found 2 users: Alice … and Bob …」）を入れ、structuredContent に全データを入れています。ただしこれは「シリアライズしたJSONを入れる」という推奨とは異なるため、使うクライアントで動作を確認してください。

4.5 大きなデータは resource_link で返す

ファイル、エクスポート、ログなどは、中身を埋め込まずに resource_link（uri、name、description、mimeType）で返せます。クライアントは必要なときだけ取得すればよくなります。モデルが全文を読むべきか判断できるよう、サイズ、行数、先頭数行といった短い要約をテキストブロックで添えます。

4.6 意味のないIDやURLより名前を返す

意味のないIDはトークンを使うわりに、モデルにとって情報がほとんどありません。Anthropicによると、英数字のUUIDを意味の分かる言葉に置き換えるだけで、検索タスクでのClaudeの精度が大きく上がりました。IDは、課題番号のように次の呼び出しで必要なものだけ残します。

4.7 JSONを圧縮する。単純な一覧は表形式にする

整形のための空白はモデルには不要です。2章では、整形をやめるだけで21%減り、同じ項目をパイプ区切りの表にすると圧縮JSONからさらに46%減りました（1 − 4,698 ÷ 8,650）。表形式は値が単純なフラットなデータに限り、ネストしたデータは圧縮JSONのままのほうが分かりやすくなります。

4.8 切り詰めやエラーで次の行動を示す

結果を切り詰めたときは、そのことと続きの取り方を書きます。例：Showing 10 of 342. Pass cursor="c_10" or narrow with state/label. エラーについては、仕様上クライアントはツール実行エラー（isError: true）をモデルに渡すべき（SHOULD）とされており、モデルはそれを見て修正できます。Anthropicも、分かりにくいエラーコードやスタックトレースではなく、具体的に何を直せばよいかを伝えるメッセージを勧めています。1行の具体的なエラーはスタックトレースより安く、闇雲な再試行も防げます。

5. 実装例（TypeScript）

list_issues ツールにパターン1・2・3・6・7・8を適用した例です。MCPのTypeScript SDKの registerTool とzodのスキーマを使っています。APIの細部はSDKのバージョンによって異なるため、お使いの版で確認してください。api.listIssues は自分のバックエンド呼び出しに置き換えます。

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({ name: "issues", version: "1.0.0" });

const FIELDS = ["number", "title", "state", "author", "labels", "comments", "updated"] as const;

// パターン1・6：上流のオブジェクトを小さく読みやすい形に変換
const toConcise = (i: any) => ({
  number: i.number,
  title: i.title,
  state: i.state,
  author: i.user.login,
  labels: i.labels.map((l: any) => l.name),
  comments: i.comments,
  updated: i.updated_at.slice(0, 10),
});

server.registerTool(
  "list_issues",
  {
    description:
      "List issues, newest first. Paged: 10 per page by default; pass next_cursor to continue. " +
      "Use fields to return only what you need. response_format=detailed adds the first 2,000 characters of each body.",
    inputSchema: {
      state: z.enum(["open", "closed", "all"]).default("open"),
      limit: z.number().int().min(1).max(50).default(10),          // パターン2
      cursor: z.string().optional(),
      fields: z.array(z.enum(FIELDS)).optional(),                  // パターン1
      response_format: z.enum(["concise", "detailed"]).default("concise"), // パターン3
    },
  },
  async ({ state, limit, cursor, fields, response_format }) => {
    const page = await api.listIssues({ state, limit, cursor });
    const pick = fields ?? [...FIELDS];
    const items = page.items.map((raw: any) => {
      const c = toConcise(raw);
      const row = Object.fromEntries(pick.map((f) => [f, c[f]]));
      return response_format === "detailed" ? { ...row, body: raw.body.slice(0, 2000) } : row;
    });
    const result = {
      items,
      total: page.total,
      next_cursor: page.nextCursor ?? null,
      note: page.nextCursor ? `Showing ${items.length} of ${page.total}. Pass cursor to see more.` : undefined, // パターン8
    };
    // パターン7：圧縮JSONをテキストブロック1つで返す（structuredContentとの二重送信なし）
    return { content: [{ type: "text", text: JSON.stringify(result) }] };
  }
);

ページングや fields の使い方は、説明文の最初の1〜2文に書いておきます。クライアントやプロキシによっては長い説明文を切り詰めるため、モデルが効率よく使うための情報は前に置くのが安全です。

6. レスポンスのトークン数を測る方法

変更の前後で必ず測ります。手軽な順に3つあります。

ツールごとのレスポンスのバイト数を記録する。サーバーかゲートウェイで tools/call のレスポンスサイズを記録し、p95の大きい順に並べます。上位のツールから手を付けます。
APIでトークン数を数える。代表的な結果をメッセージとしてAnthropicの /v1/messages/count_tokens に送り、変更前後の input_tokens を比べます。
クライアントの警告を見る。Claude Codeで1万トークン超の警告が出たり、結果がファイルに保存されたりしたら、そのツールは見直しが必要です。

サイズと一緒にタスクの成功率も見ます。削った項目を集めるためにモデルが同じツールを何度も呼ぶようになったら、既定の項目を絞りすぎています。

7. チェックリスト

[ ] 一覧・検索系のツールすべてに、小さな既定値と上限つきの limit がある
[ ] 結果に next_cursor と total があり、説明文にページングのことが書いてある
[ ] 上流のオブジェクトを用途別の形に変換し、URL・アバター・空の項目を外している
[ ] 使い方が複数あるツールには、任意の fields か response_format がある
[ ] 同じデータをモデルに2回送っていない（structuredContent とテキスト）
[ ] 大きなファイル・エクスポート・ログは resource_link と短い要約で返している
[ ] JSONを圧縮している
[ ] 切り詰めの注記とエラーに、次にすべきことが1行で書いてある
[ ] ツールごとのp95レスポンスサイズを記録し、見直している
[ ] 変更前後のトークン数を count_tokens で測った

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

症状	原因	対処
Claude Codeで「出力が1万トークンを超えた」と警告される	ページングや絞り込みなしでデータを返している	`limit`、`fields`、ページングを追加する
モデルが結果ではなくファイルを読みに行く	5万文字かトークン上限を超え、ファイルに退避された	既定のレスポンスを小さくする。全データが本当に必要なときだけ `anthropic/maxResultSizeChars` を上げる
`outputSchema` を追加したらトークンが倍になった	クライアントが `structuredContent` とテキスト版の両方を渡している	クライアントが何を渡すか確認する。構造化データを小さくするか、不要なら `outputSchema` を外す
モデルが同じツールを何度も続けて呼ぶ	既定の項目が少なすぎる、または説明文にページングや絞り込みの説明がない	足りない項目を既定に加え、`fields` と `cursor` を説明文の冒頭に書く
失敗した呼び出しを同じ内容で再試行する	エラーがスタックトレースや意味の分からないコード	`isError: true` と、何を直せばよいかの1行メッセージを返す
複数ステップのタスク中にコンテキストが埋まる	大きな途中結果が毎ターン読み直されている	Code Executionで絞り込み、最終結果だけ返す

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

NodeFlareはMCPサーバーをホスティングし、プロキシ側でトークン削減の設定を提供しています。どれもサーバーのコードを変更せずに使えるため、手を入れにくいサードパーティ製のサーバーにも適用できます。この記事で挙げた課題ごとに対応を整理します。

課題：大きな結果や大量の結果がコンテキストを埋めるが、サーバーのコードは変えられない（1〜2章）。 → Code Execution（tool_code_mode）を有効にします。サーバーは run_code と search_tools を公開するようになり、モデルは tools.* を呼ぶJavaScriptを書いて、サンドボックス内で結果の絞り込みや結合をし、最終的な値だけを返します。複数のツール呼び出しとその生のレスポンスが1回の実行にまとまり、モデルに届くのは返り値だけです。サンドボックスはプロキシとは別のDenoサービスで、ファイルシステム・環境変数・子プロセスはなく、ネットワークはプロキシへのコールバックだけです。各ツール呼び出しはサーバー側でスコープを再チェックされます。既定値は、タイムアウト600秒、1回の実行あたり最大50回のツール呼び出し、V8ヒープ128MBです。

課題：どのツールのレスポンスが大きいか分からない（6章）。 → NodeFlareのリクエストログには、リクエストごとに req_bytes と res_bytes が記録されます。ドキュメントにも、大きな res_bytes は呼び出し側のLLMのコンテキスト消費に直結すると書かれています。res_bytes の大きい順に並べ、どのサーバーからコードモードにするか決められます。

課題：長い説明文の中で、ページングや項目指定のヒントが埋もれる（5章）。 → tool_schema_slim を有効にすると、500文字を超えるツール説明をUTF-8を壊さずに切り詰めます。ツール名と入力スキーマはそのままです。「ページ単位で返る」「fields で項目を選べる」といったヒントは、最初の500文字以内に書いておきます。

課題：使うべきでない広範な一覧系ツールをモデルが呼んでしまう。 → tool_list_filter_by_scope を有効にすると、tools/list には呼び出し元の認証情報で実際に呼べるツールだけが表示されます。tools:call:<name> のようなAPIキーのスコープと組み合わせて使います。ツールが多い場合は tool_search_mode で一覧を search_tools(query) と call_tool(name, args) の2つのメタツールに置き換えると、ツールが増えても初期のトークンコストはほぼ一定になります。

NodeFlareは固定の削減率を公表していません。効果は res_bytes と count_tokens で、自分のトラフィックを使って測ってください。

最小の始め方：

nodeflare.tech にサインインし、MCPサーバーのGitHub URLを入力します。ランタイム・トランスポート・起動コマンドは自動で入力されます。
デプロイしたら、サーバー設定で tool_code_mode を有効にします。
発行されたサーバーURLとAPIキーをMCPクライアントに設定します。

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

10. よくある質問

MCPツールの結果は入力トークンとして課金されますか？

はい。クライアントがツールの結果をモデルに渡すと、会話の一部になり入力として課金されます。会話に残っている間は、その後のターンでも毎回課金されます。プロンプトキャッシュで読み直しの単価は下がりますが、なくなりはしません。

MCPツールのレスポンスはどれくらいの大きさが目安ですか？

プロトコル上の上限はありませんが、クライアントには実用上の上限があります。Claude Codeは1万トークンを超えると警告し、既定で2万5,000トークンに制限します。目安としては、モデルが使う項目だけで最初の10〜20件を返す程度です。

Claude CodeでMCPツールの出力がファイルに保存されるのはなぜですか？

Claude Codeは、成功時のテキスト結果がトークン上限（既定2万5,000）か5万文字を超えると、ファイルに保存してモデルにパスを渡します。既定のレスポンスを小さくするか、本当に大きな上限が必要なツールだけ anthropic/maxResultSizeChars を宣言してください。

MAX_MCP_OUTPUT_TOKENSとは何ですか？

Claude Codeの環境変数で、MCPツールの出力の上限をトークン数で指定します。既定は2万5,000です。独自の上限を宣言していないツールに適用され、5万文字でファイルに保存する閾値は変わりません。

MCPツールの結果はstructuredContentとテキストのどちらで返すべきですか？

クライアントやコードで結果を検証・パースする必要があるなら、outputSchema とあわせて structuredContent を使います。その場合、仕様ではシリアライズしたJSONをテキストでも返すべきとされており、クライアントが両方を渡すとトークンが倍になります。スキーマが不要なら、圧縮JSONのテキストブロック1つがいちばん小さくなります。

MCPのresource_linkとは何ですか？

resource_link は、中身を埋め込む代わりにURIでリソースを指すツール結果の型です。クライアントは必要なときだけリソースを取得できます。ファイル、エクスポート、ログなどに向いています。

MCPツールの結果をページングするには？

ツールの入力スキーマに limit（小さな既定値と上限つき）と cursor を追加し、結果に next_cursor と total を含めます。説明文にもページングのことを書き、モデルが続きを取れると分かるようにします。これは tools/list 自体のページングとは別の話です。

JSONを圧縮するとMCPのトークン消費は減りますか？

減りますが、項目の選別やページングほどではありません。筆者の50件の実測では、圧縮で21%、7項目に絞ると90%減りました。バイト数とトークン数は同じではないため、効果はトークン数計測APIで確かめてください。

レスポンスを削る代わりにCode Executionを使うべきなのはどんなときですか？

数千行の絞り込みや、複数ツールの結果の結合など、大きなデータを計算に使うときです。結果そのものをモデルが読む必要があるなら、レスポンスを削るほうが向いています。両者は併用できます。

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

いいえ。この記事で扱うのは、MCPツールの結果が消費するLLMのトークンです。APIキーやOAuthのアクセストークンはセキュリティの話題で、MCPセキュリティのチェックリストで扱っています。

まとめ

ツールの結果は、会話に残っている間毎ターン送り直されるため、MCPのトークン消費の中で最も大きく変動する部分になりがちです。上流のデータを小さな形に変換し、小さな既定値でページングし、簡潔モードを用意し、同じデータを二重に送らず、大きな中身は埋め込まずにリンクで返し、切り詰めたときは次の行動を示しましょう。ツールごとのレスポンスサイズを記録して count_tokens で確かめ、計算が中心の処理はCode Executionに任せるのが効率的です。