長いエージェントセッションのMCPトークン消費：古いツール結果をcontext editing・compaction・サブエージェントで片付ける方法【2026年コスト試算】
長いエージェントセッションでMCPのトークン消費が毎ターン増える理由と抑え方。Claude Sonnet 5.5で40リクエストを試算し、context editing（clear_tool_uses）の設定、Claude API・OpenAIのcompaction、Claude Codeの/compact・/clear・サブエージェント、消すと逆に高くつく条件を解説します。
最終更新：2026年10月21日 ／ 対象：Claude APIのcontext editing（
clear_tool_uses_20250919）、Claude APIのcompaction（しきい値型compact_20260112・オンデマンド型compact-2026-09-04のベータ）、Claude Codeの自動compaction・/compact・/clear・/rewind・サブエージェント、OpenAI Responses APIのcompaction、Claude Sonnet 5.5の料金
長時間のエージェントセッションで、いちばん速く増えていくMCPのトークン消費（MCP token usage）はツール一覧ではありません。前のターンのツール結果です。結果は会話履歴に残り、その後のリクエストのたびに毎回送り直されます。この記事では、このコストがどう増えるかを式で示し、Claude Sonnet 5.5で40リクエストのセッションを5つのやり方で試算します。そのうえで、古いツール結果を「消す」（context editing）、「要約する」（compaction）、「分ける」（サブエージェント）の使い分けと、消すとかえって高くつく条件を整理します。
結論（30秒で読める要約）
- 古いツール結果はリクエストのたびに送り直されます。Claude Codeのドキュメントにも「会話全体を毎回送り、ツールを使うたびにそのツール結果を載せたリクエストをもう一度送る」と書かれています。
- 増え方は2乗です。セッション全体の入力は、おおよそ N × B + R × N(N−1) ÷ 2（N：リクエスト数、B：固定部分のトークン、R：1回のツール結果のトークン）です。筆者の試算では、5,000トークンの結果が返る40リクエストで入力は合計430万トークン、そのうち390万トークンが古いツール結果でした。
- プロンプトキャッシュで「安く」はなりますが「小さく」はなりません。同じセッションはキャッシュなしで8.60ドル、ありで0.922ドルですが、コンテキストは205,000トークンまで膨らみます。
- context editingはコンテキストの上限を抑えますが、キャッシュが効いていると金額はあまり下がりません。
clear_tool_uses_20250919をしきい値50Kで使うと、最大コンテキストは50,000トークンに収まり、費用は0.778ドル（−16%）でした。しきい値30Kでは18回消去が走り、1.030ドルと何もしないより高くなりました。消すたびにキャッシュが作り直されるためです。 - 何を残したいかで選びます。取り直せる結果は消す、判断の経緯が大事なら要約する、出力の多い作業はサブエージェントに任せる、無関係な作業に移るときは
/clearで始め直す、が基本です。 - いちばん安いのは、そもそも履歴に入らないトークンです。結果を小さく返すか、モデルに渡す前にコードで処理します。筆者の試算では、結果を5,000トークンから500トークンにすると、キャッシュありのセッション費用は0.150ドルになりました。
目次
- ツール結果の蓄積とは
- MCPのツール結果はターンごとにどう積み上がるか
- コスト試算：40リクエストのセッションを5通りで比較
- 古いツール結果の4つの扱い方
- Claude APIのcontext editing（clear_tool_uses）
- Claude APIとOpenAIのcompaction
- Claude Code：自動compaction・/compact・/clear・/rewind・サブエージェント
- 消去・要約で何トークン減ったかの測り方
- チェックリスト
- よくあるハマりどころ
- NodeFlareならこう解決できる
- よくある質問
1. ツール結果の蓄積とは
ツール結果の蓄積とは、前のターンで受け取ったMCPのツール結果が会話履歴に残り、その後のリクエストのたびにモデルへ送り直されることで、エージェントのコンテキストが膨らんでいく現象です。ツール定義が「1リクエストあたりの固定費」なのに対して、こちらはセッションが長くなるほど増えるMCPトークン消費です。
LLMのAPIは状態を持ちません。Claude Codeのプロンプトキャッシュのドキュメントには、モデルはリクエスト間で何も覚えていないので、システムプロンプト、プロジェクトの情報、それまでのすべてのメッセージとツール結果、新しいメッセージを毎回送り直す、とはっきり書かれています。つまり3ターン目に受け取った5,000トークンの結果は、何かが取り除くまで、4ターン目にも5ターン目にもその後のすべてのターンにも課金されます。
注：この記事の「トークン」はLLMのトークン（コンテキストと課金の単位）のことで、APIキーやOAuthのアクセストークンではありません。
2. MCPのツール結果はターンごとにどう積み上がるか
1回のリクエストは3つの層でできていて、増え続けるのは最後の層だけです。
| 層 | 中身の例 | セッション中に増えるか | 詳しい記事 |
|---|---|---|---|
| 固定部分 | システムプロンプト、ツール定義 | 増えない（ツールが変わらない限り） | プロンプトキャッシュの記事 |
| 今回のツール結果 | このターンで呼んだツールの結果 | 呼ぶたびに1回分 | ツールの返り値を小さくする記事 |
| 履歴 | それまでのメッセージとツール結果すべて | 毎ターン増える | この記事 |
計算式（筆者による）：固定部分をBトークン、2回目以降のリクエストごとにRトークンのツール結果が1つ増えるとすると、k回目のリクエストは B + (k−1) × R トークンになり、N回のセッション全体では N × B + R × N(N−1) ÷ 2 トークンを送ります。
効いてくるのは後ろの項です。セッションの長さを2倍にすると、固定部分のコストは2倍ですが、履歴のコストはほぼ4倍になります。長いエージェントループ、ブラウザ操作、ログ検索、ページ送りのあるAPI取得が、1回分の数字から想像するよりずっと高くつくのはこのためです。
ドキュメントから分かる前提が2つあります。
- Claude Codeが制限するのは「1回分」の結果で、合計ではありません。MCPの出力が10,000トークンを超えると警告し、デフォルトでは25,000トークンで打ち切ります（
MAX_MCP_OUTPUT_TOKENS）。それより大きい結果はファイルに保存され、会話にはファイルのパスが入ります。上限以下の結果でも、40個集まれば数十万トークンになります。 - 大きなコンテキストウィンドウは問題を先送りするだけです。Claude APIでは、Haiku 5.5を除くClaude 4.6以降のモデルは100万トークンのウィンドウを通常料金で使えます（Anthropicの料金ページ）。上限に届かないまま、送り直すトークンにはすべて課金され続けることがあります。
3. コスト試算：40リクエストのセッションを5通りで比較
プロンプトキャッシュが効いているとき、古いツール結果の消去は主にコンテキストの大きさを抑える手段です。金額はわずかしか下がらず、消しすぎると何もしないより高くなります。
前提（筆者による計算。再計算できるように条件をすべて書きます）：
- Claude Sonnet 5.5で40リクエスト。B＝10,000トークン（システムプロンプトとツール定義）。2回目以降のリクエストごとに5,000トークンのツール結果が1つ増える。
- 料金はAnthropicの料金ページより：入力2ドル、5分キャッシュの書き込み2.50ドル、キャッシュの読み込み0.10ドル、出力10ドル（いずれも100万トークンあたり）。
- キャッシュありの場合、各リクエストは前回の内容をキャッシュから読み、増えた分だけを書き込む。消去や要約のあとは固定部分Bだけがキャッシュに残り、それ以降は書き直しになる。
- context editing：プロンプトがしきい値を超えたら、直近3件（
keepのデフォルト）を除くツール結果を消す。消した跡に入るプレースホルダーは0トークンとみなす。 - compaction：プロンプトが50,000トークン（指定できる最小値）を超えたら、追加の処理でコンテキストを読み、3,000トークンの要約を書く（出力として課金）。
- モデルの出力と思考（thinking）はどの行にも含めない。
| やり方（40リクエスト、結果5Kトークン） | 入力トークン合計 | 最大コンテキスト | 消去・要約の回数 | Sonnet 5.5での費用 |
|---|---|---|---|---|
| 何もしない、キャッシュなし | 4,300,000 | 205,000 | 0 | 8.600ドル |
| 何もしない、キャッシュあり | 4,300,000 | 205,000 | 0 | 0.922ドル |
| context editing、しきい値100K、直近3件を残す | 2,220,000 | 100,000 | 2 | 0.762ドル |
| context editing、しきい値50K、直近3件を残す | 1,420,000 | 50,000 | 6 | 0.778ドル |
| context editing、しきい値30K、直近3件を残す | 1,060,000 | 30,000 | 18 | 1.030ドル |
| compaction、しきい値50K、要約3Kトークン | 1,412,000（要約処理分を含む） | 50,000 | 4 | 0.772ドル |
上の2行は手計算で確かめられます。40 × 10,000 + 5,000 × (40 × 39 ÷ 2) = 400,000 + 3,900,000 = 4,300,000トークン、430万 × 2ドル ÷ 100万 = 8.60ドルです。キャッシュありでは、39回のリクエストが履歴を0.10ドルで読み（4,095,000トークン＝約0.41ドル）、新しい5,000トークンを2.50ドルで書き込みます（39 × 5,000＝約0.49ドル）。これに最初の10,000トークンの書き込み（0.025ドル）が加わります。
読み方：
- お金に一番効くのはキャッシュです。それだけでこのセッションは89%安くなります。
- 消去と要約が効くのはコンテキストの大きさです。最大値は205,000から50,000トークンに下がります。200Kウィンドウのクライアントでも作業を続けられ、モデルが古い情報をかき分ける量も減ります。
- 消去のたびにキャッシュが作り直されます。しきい値30Kでは18回消去が走り、そのたびに残した結果を書き込み料金で書き直しました。Anthropicのドキュメントもこの点を注意していて、消去はキャッシュされたプレフィックスを無効にするので、
clear_at_leastで「無効にする価値があるだけの量」をまとめて消すよう勧めています。 - キャッシュが効いていないなら話は逆です。クライアントやゲートウェイがキャッシュしない場合（たとえば
cache_controlの指定を取り除いてしまうゲートウェイ）は、送り直すトークンがすべて2ドルで課金されるので、消去で入力費用の大半を減らせます。
Anthropic自身の計測も、長いタスクについて同じ方向を示しています。100ターンのWeb検索の評価で、context editingはコンテキスト不足で失敗するはずだったワークフローを完了させ、トークン消費を84%減らしました（Anthropic、2025年9月29日）。
4. 古いツール結果の4つの扱い方
新しい機能かどうかではなく、古い結果について何を覚えておく必要があるかで選びます。
| 方法 | 古い結果はどうなるか | 残るもの | キャッシュへの影響 | 向いている場面 |
|---|---|---|---|---|
| context editing（ツール結果の消去） | プレースホルダーに置き換わる | ツール呼び出し（デフォルト）、直近N件の結果、推論の文章すべて | 最初に消した位置からキャッシュが外れる | 取り直せる結果：検索結果、ページのスナップショット、ファイルの読み込み |
| compaction（要約） | 履歴ごと要約される | 会話全体の要約 | 要約1回ごとに会話部分のキャッシュが外れる | 生データより判断や経緯が大事な長いタスク |
| サブエージェントで分ける | そもそもメインのコンテキストに入らない | サブエージェントの要約だけ | メインのキャッシュは無傷 | 出力が多く、単体で完結する作業：テスト実行、ログ解析、調査 |
始め直す（/clear、新しいセッション） |
捨てる | 先にメモを書かない限り何も残らない | 新しいキャッシュ | 無関係な作業に移るとき |
消す必要そのものを減らす方法も2つあります。結果を元から小さくすること（ツールの返り値を小さくする記事を参照）と、モデルに渡す前にコードで結果を処理するコード実行です。
5. Claude APIのcontext editing（clear_tool_uses）
context editingは、プロンプトがClaudeに届く前にAnthropic側で古いツール結果を消す機能です。アプリケーション側には完全な履歴が残ります。ドキュメントには、context editingはサーバー側で適用され、クライアントアプリケーションは変更されていない会話履歴をそのまま保持する、とあります。
context-management-2025-06-27 のベータヘッダーと、clear_tool_uses_20250919 の指定で有効になります。
curl https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: context-management-2025-06-27" \
-H "content-type: application/json" \
-d '{
"model": "claude-sonnet-5-5",
"max_tokens": 2048,
"tools": [ ... MCPのツール ... ],
"messages": [ ... ],
"context_management": {
"edits": [{
"type": "clear_tool_uses_20250919",
"trigger": { "type": "input_tokens", "value": 50000 },
"keep": { "type": "tool_uses", "value": 3 },
"clear_at_least": { "type": "input_tokens", "value": 20000 },
"exclude_tools": ["get_project_config"]
}]
}
}'
| パラメーター | デフォルト | 役割 |
|---|---|---|
trigger |
入力100,000トークン | プロンプトがこれを超えると消去を始める。input_tokens か tool_uses で数える |
keep |
ツール使用3件 | 消さずに残す直近のツール呼び出しと結果の組 |
clear_at_least |
なし | この量以上消せないときは消去しない。キャッシュの作り直しに見合うかの歯止め |
exclude_tools |
なし | 呼び出しも結果も絶対に消さないツール |
clear_tool_inputs |
false |
結果だけでなく、ツール呼び出しの引数も消す |
出典：Claude Docs「Context editing」。各パラメーターの正確な書き方は、使っているSDKのバージョンのドキュメントで確認してください。
実務での決まりごと：
- キャッシュを使うなら
clear_at_leastを必ず指定します。3章のしきい値30Kの行のようにならないための歯止めです。 - 小さくて大事な結果は除外します。後の手順がすべて頼る200トークンの設定取得を、消して取り直す意味はありません。
clear_tool_inputsは最初はオフのままにします。呼び出しが見えていれば、モデルは何を試したかが分かり、必要ならもう一度呼べます。- 古い発見を残したいならメモリツールと組み合わせます。メモリツール（
memory_20250818）を有効にすると、コンテキストが消去のしきい値に近づいたときに、大事な情報を保存するよう自動で警告が届く、とドキュメントにあります。 - 思考ブロックには別の方法
clear_thinking_20251015があります。組み合わせるときはeditsの先頭に置く必要があります。
6. Claude APIとOpenAIのcompaction
compactionは、ツール結果を含む古い履歴を、モデルが書いた要約に置き換えます。すべての要点が残る代わりに、要約1回ごとにモデルの呼び出しが1回増えます。
| Claude API（しきい値型） | Claude API（オンデマンド型） | OpenAI Responses API | |
|---|---|---|---|
| 有効にする方法 | compact-2026-01-12 ベータ、context_management.edits に compact_20260112 |
compact-2026-09-04 ベータ、トップレベルの compaction パラメーター |
context_management に compact_threshold、または /responses/compact エンドポイント |
| いつ動くか | プロンプトがしきい値を超えたとき（デフォルト150,000、最小50,000入力トークン） | 呼び出したとき | しきい値を超えたとき、またはエンドポイントを呼んだとき |
| 返ってくるもの | compaction ブロック。以降のリクエストではそれより前の内容が無視される |
署名つきのcompactionブロック1つ、stop_reason: compaction |
暗号化されたcompactionアイテム（人が読むことを想定していない） |
| 課金の注意 | 追加の処理が走る。実際の合計は usage.iterations を足して求める |
同じ | OpenAIのガイドを参照 |
出典：Claude Docs（Compactionの概要・しきい値型・オンデマンド型）、OpenAI Docs（Compaction）。Claudeの2つの方法は混ぜられず、compaction と context_management は同じリクエストで送れません。
MCPのツールを使うときに効いてくる点：
- トップレベルの使用量には要約の処理が入っていません。ドキュメントにも、トップレベルの
input_tokensとoutput_tokensにはcompactionの処理分が含まれないとあります。費用を比べる前にusage.iterationsの全項目を足してください。 - 要約中にモデルがツールを呼ぶことがあります。リクエストにツールがあると、内部の要約処理中にまれにツールを呼び、
content: nullのcompactionブロックが返ります。ドキュメントにある対処は、要約中はツールを呼ばないよう指示するinstructionsを指定することです。 instructionsはデフォルトの指示に「追加」ではなく「置き換え」です。ツール結果に含まれるIDやファイルパスなど、残したいものはすべて書きます。- 要約をキャッシュします。システムプロンプトの末尾に
cache_controlを置けば、新しく書き込むのは要約だけで済む、とドキュメントにあります。
7. Claude Code：自動compaction・/compact・/clear・/rewind・サブエージェント
Claude Codeは履歴を自動で管理してくれますが、デフォルトは「作業を止めない」ための調整で、「コストを下げる」ための調整ではありません。
| コマンド・機能 | 古いツール結果がどうなるか | コストの注意（Claude Codeのドキュメントより） |
|---|---|---|
| 自動compaction | 自動compactionのウィンドウに近づくと履歴を要約 | ウィンドウは /autocompact 500k、autoCompactWindow、CLAUDE_CODE_AUTO_COMPACT_WINDOW で設定（100K〜1M） |
/compact focus on ... |
今すぐ要約し、指定したものを残す | キャッシュが温かければ履歴をキャッシュから読む。時間が空くとキャッシュなしで処理し直す |
/clear |
すべて捨てる | コストはかからない。後で /resume できるよう先に /rename しておく |
/rewind |
前のターンまで巻き戻す | 新しく作らず、以前のキャッシュに当たる |
| サブエージェント | 出力の多い作業をサブエージェント側のコンテキストに閉じ込める | メインの会話には要約だけが戻る |
| ツール結果の消去 | Claude Code自身が古いツール結果を消す | /usage では、これによるキャッシュミスを「想定内の作り直し（expected rebuild）」として数える |
MCPを多用するセッションでは、compactionで何が残るかが大事です。Claude Codeはプロジェクト直下のCLAUDE.md、自動メモリ、Skillの説明を入れ直し、最近変更したファイルを最大5つ読み直し、呼び出したSkillの本文を1つ5,000トークン・合計25,000トークンまで入れ直します。MCPのツール結果はこの一覧に入っていません。ほかの会話と一緒に要約されて消えるので、IDやURLなどまだ必要なものは、ファイルに書き出すか /compact の指示で名指ししておきます。
大きな結果を返すMCPサーバーには、サブエージェントがいちばんきれいな解決策です。Claude Codeでは、サブエージェントの mcpServers に直接書いたサーバーはそのサブエージェントが動いている間だけ接続されるので、ツール定義も結果もメインのコンテキストに入りません。書き方はクライアント別のツール上限の記事にあります。サブエージェント自身のリクエストにもトークンはかかるので、簡単な作業には小さいモデルを割り当てます。
8. 消去・要約で何トークン減ったかの測り方
しきい値を調整する前に測ります。適切な値は、結果の大きさとキャッシュの当たり方によって変わります。
| どこで | 何を見るか | 分かること |
|---|---|---|
| Claude APIのレスポンス | context_management.applied_edits[].cleared_tool_uses、cleared_input_tokens |
消去で消えた結果の件数とトークン数 |
Claude APIの count_tokens |
input_tokens と context_management.original_input_tokens |
消去後と消去前のプロンプトの大きさ（実際に送らずに確認できる） |
| compactionを使うClaude API | usage.iterations の合計 |
要約処理を含めた、実際に課金される合計 |
| Claude API全般 | cache_creation_input_tokens と cache_read_input_tokens |
消去でキャッシュを作り直しすぎていないか |
| Claude Code | /context |
何がコンテキストを使っているかの内訳 |
| Claude Code | /usage |
セッションの費用、Prompt cache (main) のヒット率・ミス・想定内の作り直し。プランによってはMCPサーバーごとの使用割合も出る |
目安（筆者による）：消去のあとの cache_creation_input_tokens が、その消去で減ったトークン数より大きいなら、clear_at_least かしきい値を上げます。
9. チェックリスト
- [ ] 自分の作業でのMCPツール結果の平均サイズ（R）とセッションあたりのリクエスト数（N）を測った
- [ ] プロンプトキャッシュが効いていることを確認した（2回目以降のリクエストでキャッシュ読み込みが出る）
- [ ] 消去か要約のしきい値を、クライアントの実際のウィンドウより下に、大きな結果1回分の余裕を持って設定した
- [ ]
clear_at_leastを設定し、1回の消去で減る量がキャッシュの作り直しより大きくなるようにした - [ ] 後の手順が頼る小さな結果を
exclude_toolsに入れた - [ ] compactionの指示に、残すべきID・パス・判断を書き、ツールを呼ばないよう指示した
- [ ] compactionの費用をトップレベルの使用量ではなく
usage.iterationsで測った - [ ] クライアントが対応していれば、出力の多いMCPサーバーをサブエージェントで動かしている
- [ ] 無関係な作業の間で
/clear（または新しいセッション）を使っている - [ ] 大きすぎる結果は、後で消すだけでなく元のサーバー側で直した
10. よくあるハマりどころ
| 症状 | 原因 | 対処 |
|---|---|---|
| context editingを入れたら請求が増えた | しきい値が低く、ほとんどのリクエストでキャッシュが作り直されている | しきい値を上げ、clear_at_least を設定する |
| エージェントが同じデータを何度も取り直す | まだ必要な結果まで消されている | keep を増やすか、そのツールを exclude_tools に入れる |
| ダッシュボードではcompactionが安く見える | トップレベルの使用量に要約処理が入っていない | usage.iterations を足す |
compactionブロックが content: null になる |
要約中にモデルがツールを呼んだ | 「ツールを呼ばず文章だけで答える」よう指示する |
/compact のあとにIDを忘れる |
ツール結果は要約され、そのままは残らない | /compact の指示で名指しするか、ファイルに書き出す |
| 放置しているだけなのに長いセッションの消費が増える | 定期実行タスク、チェックイン、メッセージが会話全体を送り直す | 離れる前に要約するか、クリアする |
| 上限に届かないのに高い | 100万トークンのウィンドウでcompactionが先送りされている | 自動compactionのウィンドウを小さくする |
| メインのコンテキストがブラウザのスナップショットで埋まる | 大きな結果を返すMCPサーバーをメインの会話で動かしている | サブエージェントに移す |
11. NodeFlareならこう解決できる
NodeFlareはMCPサーバーをホストし、プロキシでサーバーごとのトークン設定を追加できます。どれもサーバーのコード変更は不要で、どのMCPクライアントでも使えます。結果が履歴に入る前に効くので、後から消したり要約したりする量そのものが減ります。
課題：生のツール結果が履歴に積み上がり、毎ターン送り直される（2〜3章）。
Code Execution（tool_code_mode）を有効にします。サーバーは個々のツールの代わりに run_code と search_tools を公開します。モデルは tools.* を呼ぶJavaScriptを書き、NodeFlareがそれをサンドボックスで実行します。複数のツール呼び出しが1回の実行にまとまり、会話に入るのは最終的な値だけで、途中の結果は実行の中に残ります。実行は独立したDenoのサブプロセスで行われ、ファイルシステム・環境変数・別プロセスの起動は使えず、ネットワークはプロキシのツール呼び出し用エンドポイントにしかつながりません。デフォルトはタイムアウト600秒、1回の実行で最大50回のツール呼び出し、V8ヒープ128MBです。
例（3章のモデルで筆者が計算したもので、NodeFlareの計測値ではありません）：コードで処理して各ターンの結果を5,000トークンから500トークンにできれば、キャッシュありの40リクエストのセッションは0.922ドルから0.150ドルに、最大コンテキストは205,000トークンから29,500トークンになり、消去は一度も必要ありません。
課題：固定部分はN回のリクエストすべてで読み直され、消去のたびにセッションの一部が書き直しになる（3章・5章）。
tool_search_mode を有効にします。tools/list 全体が search_tools(query) と call_tool(name, args) の2つのメタツールに置き換わり、ツールがいくつあっても最初のトークンコストはほぼ一定です。検索はデフォルトでは語句の一致で行い、GEMINI_API_KEY を設定すると埋め込みベースの意味検索になります。キーがない場合や呼び出しに失敗した場合は、リクエストを止めずに語句検索に戻ります。
課題：サブエージェントや作業用エージェントに全ツールが見え、不要なツールまで呼んでしまう（7章）。
tool_list_filter_by_scope を有効にし、エージェントごとに tools:call:<name> のようなスコープを持つAPIキーを渡します。tools/list にはその認証情報で呼べるツールだけが同じスキーマで表示され、それ以外の呼び出しはサーバーに届く前にプロキシが拒否します。
課題：長いツール説明文が、すべてのリクエストに載る固定部分を大きくしている。
tool_schema_slim を有効にします。500文字を超える説明文がUTF-8の文字境界で切り詰められます。ツール名と入力スキーマはそのまま残ります。
NodeFlareは決まった削減率を公表していません。自分のRとNで3章のモデルを、導入前と導入後で計算し直してください。
最小の始め方：
- nodeflare.tech にサインインし、MCPサーバーのGitHub URLを入力します。ランタイム・トランスポート・起動コマンドは自動で入力され、Dockerfileは不要です。
- デプロイしたら、サーバー設定で
tool_code_mode（またはtool_search_mode）をオンにします。 - サーバーのURLとAPIキーを、Claude・Cursor・自作のエージェントに追加します。
1サーバーまで無料で試せます（Freeプラン：サーバー1台、月30GB時間のコンピュート）。→ nodeflare.techで始める
12. よくある質問
MCPのトークン消費がセッション中に増え続けるのはなぜ？
前のツール結果がすべて会話に残り、新しいリクエストのたびに送り直されるからです。入力の合計はリクエスト数のほぼ2乗で増えます。筆者の40リクエストの例では、入力430万トークンのうち390万トークンが古いツール結果でした。
古いMCPのツール結果は毎ターン入力トークンとして数えられる？
はい。APIは状態を持たないので、クライアントは過去のツール結果を含む履歴全体を毎回送り直します。プロンプトキャッシュが効けば、Claude Sonnet 5.5では100万トークンあたり2ドルではなく0.10ドルで課金されますが、コンテキストは同じだけ埋まります。
Claude APIで古いツール結果を消すには？
context editingを使います。context-management-2025-06-27 のベータヘッダーを付け、context_management.edits に clear_tool_uses_20250919 を指定します。デフォルトでは入力が100,000トークンを超えると消去を始め、直近3件のツール使用を残します。
context editingを使うとプロンプトキャッシュは効かなくなる？
消去するたびに外れます。Anthropicのドキュメントでも、消去はキャッシュされたプレフィックスを無効にするとされているので、clear_at_least で1回の消去量を作り直しに見合う大きさにします。筆者の試算では、しきい値30Kで消去すると、何もしないより高くなりました。
context editingとcompactionの違いは？
context editingは古いツール結果だけを消し、それ以外はそのまま残します。compactionはそれまでの履歴全体を要約に置き換えます。取り直せるデータには消去が、判断の経緯を残す必要がある長いタスクには要約が向いています。
compactionは追加でトークンを使う？
使います。Claude APIでは、コンテキストを読んで要約を書く処理が1回増え、その分はトップレベルの input_tokens と output_tokens に含まれません。課金される合計は usage.iterations の項目を足して求めます。
Claude Codeの長いセッションでMCPのトークン消費を減らすには？
無関係な作業の間で /clear、区切りのよいところで指示つきの /compact、行き止まりを捨てるなら /rewind、大きな結果を返すMCPサーバーにはサブエージェントを使います。何がコンテキストを埋めているかは /context と /usage で確認できます。
Claude Codeの /compact のあとにMCPのツール結果は残る？
そのままは残りません。ほかの会話と一緒に要約されます。Claude CodeはCLAUDE.md、自動メモリ、Skillの説明、最近のファイル最大5つ、呼び出したSkillを入れ直しますが、古いMCPのツール結果は入れ直さないので、必要なものは /compact の指示で名指ししておきます。
1つの長いセッションよりサブエージェントのほうが安い？
出力の多い作業なら、メインのコンテキストについてはたいてい安くなります。サブエージェントのツール結果はそちらのウィンドウにとどまり、戻るのは要約だけだからです。ただしサブエージェント自身のリクエストにもトークンがかかるので、全体の節約は、戻る要約が置き換えた結果よりどれだけ小さいかで決まります。
ツール結果は消すべき？小さくするべき？
まず小さくし、それでも残る分を消します。最初から大きくない結果は、消す必要もキャッシュを壊すこともありません。消去は、ページのスナップショットやサードパーティのサーバーの出力など、小さくできない結果のための最後の手段です。
ここでいう「MCPトークン」はAPIトークンのこと？
違います。この記事は、MCPのツール結果がコンテキストウィンドウで消費するLLMのトークンについての記事です。MCPサーバーのAPIキーやOAuthのアクセストークンはセキュリティの話題です。
まとめ
長いエージェントセッションでは、履歴に残って毎回送り直されるツール結果がMCPのトークン消費を押し上げ、コストはセッションの長さのほぼ2乗で増えます。プロンプトキャッシュで支払いは抑えられますが、コンテキストは小さくなりません。context editingとcompactionはコンテキストに上限をかけますが、キャッシュが効いていると金額はあまり変わらず、消しすぎると逆に高くつくので、clear_at_least と妥当なしきい値を使います。出力の多いサーバーはサブエージェントへ、無関係な作業の間は /clear を使い、そもそも履歴に入る量を元から減らすのがいちばん効きます。MCPゲートウェイやプロキシの位置づけはMCPゲートウェイの比較記事も参考にしてください。
参考資料
- Claude Docs: Context editing
- Claude Docs: Compaction（しきい値型）
- Claude Docs: Compaction（オンデマンド型）
- Claude Docs: Compaction（概要）
- Claude Docs: Pricing
- Claude Code Docs: Manage costs effectively
- Claude Code Docs: How Claude Code uses prompt caching
- Claude Code Docs: Explore the context window
- Claude Code Docs: Model configuration（自動compactionのウィンドウ）
- OpenAI Docs: Compaction
- Anthropic: Managing context on the Claude Developer Platform（2025年9月29日）
- NodeFlare Docs ・ NodeFlare 料金
