スクリーンショットとスナップショット、安いのはどっち？ブラウザ操作MCPのトークン消費を実測【Playwright MCP・2026年版】
ブラウザ系MCPのスクリーンショットとアクセシビリティスナップショットは実際に何トークン使うのか。Playwright MCP v0.0.83での3ページの実測値、Claudeの28pxパッチ式と標準・高解像度ティア、78倍になるbase64テキスト化の落とし穴、Claude Sonnet 5.5での30ステップのコスト表、節約に効く設定をまとめました。
最終更新：2026年10月29日 ／ 対象：MCP仕様 2026-07-28（ツール結果の画像コンテンツ）、Claudeの画像トークン計算（標準・高解像度ティア）、Playwright MCP v0.0.83、Chrome DevTools MCP、Claude CodeのMCP出力上限、Claude Sonnet 5.5の料金
MCPのトークン消費（MCP Token）が一番読みにくいのが、ブラウザ操作です。ブラウザ系のMCPサーバーは、操作のたびにページの「見た目」をモデルに渡します。中身はアクセシビリティスナップショット（テキスト）か、スクリーンショット（画像）か、その両方です。どちらが安いかは、ページの中身、ビューポートの大きさ、モデルの画像ティア、そしてクライアントが画像をどう渡すかで変わります。この記事では、Playwright MCP v0.0.83で実際に測った数字をもとに、画像トークンの数え方、30ステップのブラウザ操作にかかるコスト、消費量を左右する設定をまとめます。
なお、ここでの「トークン」はLLMのトークン（コンテキストと課金の単位）のことで、APIキーやOAuthのアクセストークンのことではありません。
結論（30秒で読める要約）
- Claudeでは、スクリーンショットのトークン数はファイルサイズではなくピクセル数で決まります。式は ⌈幅 ÷ 28⌉ × ⌈高さ ÷ 28⌉ です。1280×720のスクリーンショットは、30KBのPNGでも200KBのJPEGでも1,196トークンです。
- アクセシビリティスナップショットがいつも安いわけではありません。筆者の計測では、50行の注文一覧のスナップショットは6,583トークン（o200k_baseで計数）で、同じページのスクリーンショット1,196トークンより大きくなりました。ただしスクリーンショットに写るのは画面内の行だけで、操作に使う要素の参照（ref）も含まれません。
- 一番安いのは、必要な部分だけを読む方法です。Playwright MCPの
browser_findは指定した1行を178トークンで返し、browser_snapshotにdepth: 3を付けると同じページで347トークンでした。 - フルページのスクリーンショットは新しいモデルほど高くなります。Claude 4.7以降は高解像度ティア（1枚あたり最大2,576px・4,784トークン）で処理されます。筆者の1280×2573のフルページ画像は、高解像度ティアで4,232トークン、標準ティアでは約1,568トークンです。
- 最悪なのは、画像がテキストとして渡るケースです。同じ1280×720のPNGをbase64文字列のまま数えると93,893トークン（o200k_base）で、画像として渡した場合の約78倍です。Claude Codeでは、画像の結果がテキストとしてモデルに届く不具合が報告されています（issue #31208、#9152）。
- 返した結果は履歴に残り続けます。30ステップの操作で毎回フルスナップショットを取ると、送信される入力は合計286万トークン（Claude Sonnet 5.5でキャッシュなし5.73ドル、キャッシュあり0.745ドル）。毎回ビューポートのスクリーンショットなら合計57万トークン（1.13ドル、0.147ドル）です。
目次
- ブラウザ操作でのMCPトークン消費とは
- スクリーンショットがトークンになる仕組み
- 実測：Playwright MCPのスナップショットとスクリーンショット
- 計測から分かる5つのこと
- 30ステップのブラウザ操作のコスト
- ブラウザ系MCPのトークン消費を左右する設定
- サーバーを自作する場合：画像を安く返す方法
- チェックリスト
- よくあるハマりどころ
- NodeFlareならこう解決できる
- FAQ
1. ブラウザ操作でのMCPトークン消費とは
ブラウザ操作でのMCPトークン消費とは、ブラウザ系MCPサーバーが返すページの状態（テキストのアクセシビリティスナップショット、画像のスクリーンショット）と、そのサーバー自身のツール定義が使うLLMの入力トークンのことです。エージェントはほぼ毎回の操作のあとにページを確認するので、ブラウザエージェントのコンテキストの中で一番大きな割合を占めがちです。
Playwright MCPやChrome DevTools MCPのようなサーバーには、ページを見る方法が2つあります。
| 見方 | モデルが受け取るもの | それを使って操作できるか | トークン数を決めるもの |
|---|---|---|---|
| アクセシビリティスナップショット | ロール・名前・要素の参照（ref）を並べたテキストのツリー | できる（refを使う） | ページ上の要素の量（行数、リンク数、本文） |
| スクリーンショット | 画像 | refで操作するツールには使えない（Playwright MCPのスクリーンショットツールの説明にも明記）。座標で操作するツールが必要 | 画像のピクセル数とモデルの画像ティア |
Playwright公式ドキュメントは、たいていのWebアプリではスナップショット方式の方が「信頼性が高く、トークン効率もよい」としており、スクリーンショットと座標ツールはcanvas、WebGL、地図などに限ってすすめています。基本方針としては正しいのですが、3章で見るように例外もあります。
2. スクリーンショットがトークンになる仕組み
スクリーンショットは2段階でモデルに届きます。MCPサーバーが画像コンテンツとして返し、クライアントがそれをモデルAPIの画像ブロックに変換します。
1段目はMCPの画像コンテンツです。MCP仕様（2026-07-28）では、ツール結果の画像はbase64データとMIMEタイプで表します。
{
"type": "image",
"data": "base64-encoded-data",
"mimeType": "image/png",
"annotations": { "audience": ["user"], "priority": 0.9 }
}
base64はあくまで運ぶための形式です。クライアントが画像として渡せば画像として課金されます。途中でテキストに変わってしまうと、base64の1文字1文字がテキストとして課金されます（4章）。
2段目はClaudeの画像トークンです。Anthropicのビジョンのドキュメントでは、画像を28×28ピクセルのパッチ単位で数え、⌈幅 ÷ 28⌉ × ⌈高さ ÷ 28⌉ トークンになります。大きすぎる画像は、縦横比を保ったままモデルのティアの上限に収まるまで縮小されます。
| ティア | 対象モデル（Anthropicのドキュメント） | 長辺の上限 | 1枚あたりの上限トークン |
|---|---|---|---|
| 高解像度 | Claude 4.7以降 | 2,576px | 4,784 |
| 標準 | それ以外のモデル | 1,568px | 1,568 |
ブラウザでよく使うサイズをこの式で計算すると次のとおりです（1920×1080はAnthropicの表と一致。ほかは筆者の計算）。
| 画像サイズ | 標準ティア | 高解像度ティア |
|---|---|---|
| 1024×768のビューポート | 1,036 | 1,036 |
| 1280×720のビューポート | 1,196 | 1,196 |
| 1366×768のビューポート | 1,372 | 1,372 |
| 1920×1080のビューポート | 1,560 | 2,691 |
| 2560×1440（1280×720をデバイス倍率2で撮影） | 1,560 | 4,784 |
| 1280×2573のフルページ画像 | 約1,568 | 4,232 |
ここから言えることは2つです。
- 画像形式や圧縮率はトークン数を変えません。同じサイズならPNG・JPEG・WebPのどれでも同じです。変わるのはデータ量で、これはClaude APIの1枚10MBの上限や転送時間に効きます。
- ビューポートとデバイス倍率はトークン数を変えます。高解像度ティアのモデルでは、1920×1080は1280×720の2.25倍です。
他社のモデルは数え方が違います。OpenAIのビジョンのガイドでは detail（モデルにより low・high・original・auto）で解像度を選び、1枚あたり30,000パッチが上限で、「low が high より常に少ないとは限らない」と書かれています。上の表はClaude用なので、ほかのモデルでは各社の計算ツールで確認してください。
3. 実測：Playwright MCPのスナップショットとスクリーンショット
Playwright MCP v0.0.83（ヘッドレスChromium。ビューポートは指定なしで1280×720）をMCP TypeScript SDKのクライアントから動かし、ローカルに用意した3種類のテストページで結果をすべて記録しました。会員登録フォーム（入力欄7つ）、注文一覧ダッシュボード（ボタン付きの50行の表）、ドキュメントページ（リンク40本のサイドバーと8節の本文）です。
計測方法：テキストの結果はo200k_baseトークナイザー（npmの gpt-tokenizer）で数えました。Claudeのトークナイザーではないので、テキストの数値は目安として見てください。画像のトークン数は、実際の画像のピクセル数からClaudeの式で計算しています。
| 結果 | 会員登録フォーム | 注文一覧 | ドキュメント |
|---|---|---|---|
browser_snapshot（全体） |
526 | 6,583 | 3,222 |
browser_snapshot（depth: 3） |
343 | 347 | 2,102 |
browser_find（注文IDを1件検索） |
— | 178 | — |
| ビューポートのスクリーンショット（PNG、1280×720） | 画像1,196＋テキスト108 | 1,196＋108 | 1,196＋108 |
| PNGのファイルサイズ | 30KB | 106KB | 199KB |
| 同じ画面をJPEGで | 38KB、トークンは同じ1,196 | 136KB、同じ1,196 | 216KB、同じ1,196 |
| フルページのスクリーンショット | 1280×720（画面に収まる） | 1280×1923：標準 約1,568／高解像度 3,174 | 1280×2573：標準 約1,568／高解像度 4,232 |
ファイルに保存（filename 指定） |
テキスト59 | テキスト59 | テキスト59 |
| ビューポートのPNGをbase64テキストとして数えた場合（o200k_base） | 25,416 | 93,893 | 134,000超 |
| ツール定義25個（o200k_base、JSON） | 読み込まれている間、毎リクエスト3,747 |
バージョンによる違いに注意してください。v0.0.83では browser_navigate はスナップショットを結果に含めず、.yml ファイルに書き出してリンクだけを返しました（86〜136トークン）。一方 browser_snapshot はツリーをそのまま返しました。前後のバージョンでは挙動が違う可能性があるので、数字を使う前に手元のバージョンの返り値を確認してください。
4. 計測から分かる5つのこと
1つ目：画像のトークン数はファイルサイズと連動しません。ドキュメントページのPNGは会員登録フォームの6.6倍の大きさですが、トークン数はどちらも1,196です。今回のような平坦なUIでは、JPEGの方がPNGより大きくなりました。圧縮は転送量のためにするもので、トークンのためではありません。
2つ目：要素が多いページでは「スナップショットの方が安い」が逆転します。表、フィード、長い一覧はすべての行がスナップショットに入るからです。注文一覧ではフルスナップショットがスクリーンショットの約5.5倍になり、要素の少ないフォームではその逆でした。ただし、スクリーンショットに写るのは画面内（今回は先頭15行ほど）だけで、refを使ったクリックにも使えません。安く「眺める」手段であって、スナップショットの代わりにはなりません。
3つ目：必要な部分だけを読むのが一番安くなります。browser_find（スナップショットをテキストか正規表現で検索するツール）は、該当行とそのrefを178トークンで返しました。フルスナップショットの37分の1です。depth は入れ子の深いレイアウトによく効きます（注文一覧で6,583→347）が、平坦な文章ページではあまり減りません（ドキュメントで3,222→2,102）。
4つ目：高解像度ティアで差が出るのはフルページ画像です。標準ティアでは縦長の画像が約1,568トークンまで縮小されますが、Claude 4.7以降では同じ画像がより多くのピクセルを保ったまま処理され、3,174〜4,232トークンになります。Anthropicのドキュメントにも、高解像度の画像は「最大でおよそ3倍のトークンを使うことがある」とあります。
5つ目：base64がテキストのまま渡ると高くつきます。画像が文字列としてモデルに渡ると、コストはピクセル数ではなくファイルサイズで決まり、今回の計測では画像として渡す場合の21倍から100倍以上になりました。Claude Codeでも2件報告されています。スクリーンショットが「137411 tokens」と数えられて上限25,000を超えたとして拒否された件（issue #9152、Claude Code v2.0.10、2025年）と、ツールが structuredContent も返すと画像がbase64テキストとして届く件（issue #31208、not plannedでクローズ。報告された回避策は、そのツールで構造化出力を返さないこと）です。
5. 30ステップのブラウザ操作のコスト
1ステップあたりのサイズが一番効くのは、結果がすべて会話に残り、以降のリクエストで毎回送り直されるからです。
前提（筆者の計算で、計測値ではありません）：
- ブラウザ操作1回をN＝30リクエストとし、2回目以降のリクエストごとにRトークンのページ情報が1つ増える。
- 送信されるページ情報の合計 ＝ R × N(N − 1) ÷ 2 ＝ R × 435。
- キャッシュありの場合、各結果は1回書き込まれ、以降は毎回読み出される。書き込みはR × 29、読み出しはR × 406。
- Claude Sonnet 5.5の料金（Anthropicの料金ページ、2026年10月）：入力2ドル、5分キャッシュ書き込み2.50ドル、キャッシュ読み出し0.10ドル（いずれも100万トークンあたり）。
- Rは3章の注文一覧の列の値。システムプロンプト、ツール定義、モデルの出力は含めない。
| 毎ステップ取得するもの | R（トークン） | 送信合計 | 30ステップ目のコンテキスト | キャッシュなし | キャッシュあり |
|---|---|---|---|---|---|
browser_snapshot（全体） |
6,583 | 2,863,605 | 190,907 | 5.727ドル | 0.745ドル |
| フルページのスクリーンショット（高解像度ティア） | 3,290 | 1,431,150 | 95,410 | 2.862ドル | 0.372ドル |
| ビューポートのスクリーンショット | 1,304 | 567,240 | 37,816 | 1.134ドル | 0.147ドル |
browser_find の結果 |
178 | 77,430 | 5,162 | 0.155ドル | 0.020ドル |
1行を手計算で確かめます。6,583 × 435 ＝ 2,863,605トークンで、× 2ドル ÷ 100万 ＝ 5.727ドル。キャッシュありは、書き込みが6,583 × 29 × 2.50ドル ÷ 100万 ＝ 0.477ドル、読み出しが6,583 × 406 × 0.10ドル ÷ 100万 ＝ 0.267ドルです。
読み方：
- 本当の制約はコンテキストの大きさで、料金はその次です。毎ステップフルスナップショットを取ると、30ステップ目にはページ情報だけで190,907トークンになり、ほかの内容を数える前に200Kのウィンドウに迫ります。
- キャッシュで減るのは料金で、大きさは減りません。キャッシュありの列は7〜8分の1ですが、コンテキストは同じ速さで増えます。
- スクリーンショットの多い操作では「20枚ルール」に当たります。Anthropicのドキュメントによると、1リクエストに画像が20枚を超えて含まれると（過去の
tool_result内の画像も数える）、1枚ごとのサイズ制限が厳しくなります。安全なのは縦横とも2,000px以下に抑えることです。1280×720のビューポートは問題ありませんが、1280×2573のフルページ画像は21ステップ目から引っかかります。
古いページ情報がたまり続けるのを止める方法は、長いセッションで古いツール結果を消去する方法で解説しています。
6. ブラウザ系MCPのトークン消費を左右する設定
節約の大半は、今日からコードを変えずに使えるサーバーのオプションで実現できます。
Playwright MCP（v0.0.83のREADME）
| 設定 | 値 | トークンへの効果 |
|---|---|---|
--image-responses／imageResponses |
allow（既定）、omit、only |
omit にするとスクリーンショットがモデルのコンテキストに入らない。画像は出力ディレクトリに保存される |
browser_take_screenshot の filename |
パス | ディスクに保存し、短いテキストだけを返す（今回の計測で59トークン） |
browser_take_screenshot の fullPage |
true／false | 縦長のページでは高解像度ティアで最大4,784トークン |
browser_take_screenshot の scale |
css（既定）、device |
device はデバイスピクセル比のぶんピクセル数が増える |
--viewport-size |
例：1280x720 |
ビューポートのスクリーンショットのピクセル数、つまりトークン数が決まる |
browser_snapshot の depth／target |
数値／要素のref | ツリー全体ではなく一部だけを返す |
browser_snapshot の filename |
パス | スナップショットを結果ではなくファイルに保存する |
browser_find |
テキストか正規表現 | 一致したノードを前後の文脈つきで返す。READMEいわく「スナップショット全体を取るより安い」 |
--snapshot-mode |
full（既定）、none |
結果に付くスナップショットを制御する |
--caps vision |
機能フラグ | 座標で操作するツールが増え、そのぶんツール定義も増える |
Chrome DevTools MCP（ツールリファレンス）
take_snapshotの説明には「スクリーンショットよりスナップショットを優先する」とあります。verbose（既定はfalse）を有効にするとアクセシビリティツリーの全情報が入るので、必要なとき以外はオフのままにします。take_screenshotとtake_snapshotはどちらもfilePathを受け取り、結果に添付する代わりにファイルへ保存できます。take_screenshotには要素1つだけを撮るuidとfullPageもあります。
クライアント側（Claude Code）
Claude Codeは、MCPツールの出力が10,000トークンを超えると警告し、既定では25,000トークンで打ち切ります（MAX_MCP_OUTPUT_TOKENS で変更可）。50,000文字を超える成功したテキスト結果はファイルに保存されます。この上限は巨大なスナップショット1つからコンテキストを守ってくれますが、中くらいの結果が30個たまるのは防げません。ツール結果全般を小さくする方法は、MCPツールのレスポンスを小さくする方法にまとめています。
7. サーバーを自作する場合：画像を安く返す方法
ブラウザやスクリーンショットのツールを自分で作るなら、トークン数を決めるのは3点です。本物の画像として返すこと、サイズを意図して決めること、呼び出し側が画像を受け取らない選択肢を用意することです。
次のTypeScriptの例（MCP TypeScript SDKの書き方と画像ライブラリ sharp を使用。正確なAPIはお使いのSDKのバージョンで確認してください）は、長辺を制限し、保存だけするモードも用意しています。
import sharp from "sharp";
import { z } from "zod";
server.registerTool(
"screenshot",
{
description: "Viewport screenshot. To read text or find elements, use page_text instead.",
inputSchema: { saveOnly: z.boolean().optional() },
},
async ({ saveOnly }) => {
const png = await page.screenshot({ type: "png" });
if (saveOnly) {
const uri = await saveScreenshot(png); // 保存先は自前で用意し、URIを返す
return { content: [{ type: "resource_link", uri, name: "screenshot.png", mimeType: "image/png" }] };
}
// 長辺1092px：16:9のページは1092x614になり、Claudeで858トークン
const small = await sharp(png)
.resize({ width: 1092, height: 1092, fit: "inside", withoutEnlargement: true })
.png()
.toBuffer();
return { content: [{ type: "image", data: small.toString("base64"), mimeType: "image/png" }] };
}
);
考え方：
type: "image"で返し、base64をtextに入れないこと。ツールにoutputSchemaもある場合は、対象のクライアントで画像が画像のまま届くかを試してください（issue #31208）。- サイズはトークンの式で決めること。1092×614は858トークンで、1280×720の1,196、高解像度ティアでの1920×1080の2,691より少なくなります。モデルが必要な文字を読める範囲で、一番小さいサイズを選びます。
- Claudeのcomputer use・browser useのツールセットに返す画像は、事前に縮小すること。Anthropicのドキュメントによると、そこでは上限を超えた
tool_resultの画像は縮小されず、検証エラーで拒否されます。 - テキストで返す手段も用意すること。抽出したテキストや、要素1つのアクセシブルネームを返すツールで足りることは多く、スクリーンショットやフルスナップショットのごく一部のコストで済みます。
8. チェックリスト
- [ ] エージェントはフルスナップショットの前に
browser_find、depth、targetを使っている - [ ] スクリーンショットは見た目が必要な作業（グラフ、canvas、表示崩れの確認）に限っている
- [ ] 証跡としてのスクリーンショット（QAの記録、報告用）は
filename・filePathで保存するか、--image-responses omitにしている - [ ] ビューポートと
scaleを意図して設定し、使うモデルが高解像度ティアかどうかを把握している - [ ] 画像が20枚を超える操作では、フルページ画像を避けるか2,000px以下に収めている
- [ ] クライアントがMCPの画像を画像として渡していることを確認した（
/contextやトークン数が100倍に跳ねていないか） - [ ] 画像と
structuredContentの両方を返すツールを、対象のクライアントごとに試した - [ ] 長い操作では古いページ情報を消去・要約している
- [ ] この記事の数字だけでなく、自分の実際のページでRを測った
9. よくあるハマりどころ
| 症状 | 原因 | 対処 |
|---|---|---|
| スクリーンショット1枚で「maximum allowed tokens」を超えたと言われる | クライアントがbase64をテキストとして数えている | クライアントを更新する。ファイルに保存するか縮小する。type: "image" で返す |
| 画像の結果が長い文字列になる | ツールが structuredContent を返し、クライアントがそちらを優先している |
画像ツールは outputSchema なしで試す（#31208で報告された回避策） |
| 新しいモデルに変えたら画像のコストが上がった | 高解像度ティアでは大きい画像のピクセルがより多く残る | ビューポートやデバイス倍率を下げる。fullPage を避ける |
| JPEGにしてもトークンが減らない | トークンはバイト数ではなくピクセル数で決まる | 圧縮ではなく縮小する |
| 表やフィードでスナップショットが膨らむ | すべての行がアクセシビリティツリーに入る | browser_find、depth、target を使う |
| スクリーンショットの多い操作が後半で失敗する | 1リクエストに20枚を超える画像があり、サイズ制限が厳しくなった | 画像を2,000px以下にする。古い画像を消去する |
| スクリーンショットを撮ったのにクリックできない | スクリーンショットには要素のrefがない | 操作にはスナップショット、見た目の確認にはスクリーンショットと使い分ける |
| 小さいスクリーンショットでもコンテキストが埋まる | 画像はすべて履歴に残る | 古い結果を消去するか、ブラウザ作業をサブエージェントで行う |
10. NodeFlareならこう解決できる
NodeFlareは、GitHubリポジトリのMCPサーバーをプロキシの後ろでホストし、サーバーごとにトークン節約の設定を提供しています。どの設定もサーバーのコード変更は不要です。モデルに届くものに対して働くので、6章のサーバー側オプションと組み合わせて使えます。
課題1：ステップごとにページ情報がたまっていく（5章）。Code Execution（tool_code_mode）を有効にします。サーバーは run_code と search_tools を公開し、モデルは tools.* を呼ぶJavaScriptを書き、NodeFlareがそれをサンドボックスで実行します。スクリプトの中でページを開き、スナップショットを読み、必要な値を3つだけ取り出して返せば、フルスナップショットは実行の中にとどまり、会話には入りません。各実行は隔離されたDenoのサブプロセスで動き、ファイルシステム・環境変数・プロセス起動は使えず、ネットワークはプロキシのコールバック先に限られます。既定値はタイムアウト600秒、1回の実行あたり最大50回のツール呼び出し、V8ヒープ128MBです。計算例（5章のモデルを使った筆者の計算で、NodeFlareの計測値ではありません）：毎ステップ6,583トークンのスナップショットの代わりに200トークンの抽出結果を返すと、30ステップの操作はキャッシュなしで5.727ドルから0.174ドルに、キャッシュありで0.745ドルから約0.023ドルになります。
課題2：ブラウザ系サーバーのツール一覧が毎リクエスト読み込まれる（3章）。筆者の計数ではPlaywright MCPの既定の25ツールで3,747トークンあり、--caps を足すとさらに増えます。tool_search_mode を有効にすると、ツール一覧が search_tools(query) と call_tool(name, args) の2つのメタツールに置き換わります。検索は既定では語句の一致で、GEMINI_API_KEY を設定すると意味検索になり、埋め込みに失敗した場合は語句検索に戻ります。
課題3：ページを読むだけのエージェントにも、すべてのブラウザツールが見えている。tool_list_filter_by_scope を有効にし、そのエージェントには tools:call:browser_navigate、tools:call:browser_find、tools:call:browser_snapshot のようなスコープのAPIキーを渡します。tools/list にはそのキーで呼べるツールだけが表示され、それ以外の呼び出しはサーバーに届く前にプロキシが拒否します。
課題4：残したサーバーのツール説明文が長い。tool_schema_slim を有効にすると、500文字を超える説明文がUTF-8を壊さない位置で切り詰められます。名前と入力スキーマはそのままです。Playwright MCP自体の説明文は短いものが多いので、効果が大きいのは説明文の長いサーバーです。
NodeFlareのリクエストログには tool_name と res_bytes が記録されるので、どのブラウザツールが一番重い結果を返しているかも確認できます。決まった削減率は公表されていないので、設定の前後で測ってください。
最小の始め方：
- nodeflare.tech にサインインし、MCPサーバーのGitHub URLを入力します。ランタイム、通信方式、起動コマンドは自動で入力されます。
- デプロイしたら、サーバー設定で
tool_code_modeを有効にします（クライアントがツールを最初に全部読み込む場合はtool_search_modeも）。 - サーバーのURLとAPIキーをClaude、Cursor、自作のエージェントに設定します。
MCPサーバー1つまでなら無料で試せます（Freeプラン：サーバー1つ、月30GB時間のコンピュート）。→ nodeflare.techで始める
11. FAQ
Claudeでスクリーンショット1枚は何トークン？
Claudeは、モデルのティアに合わせて縮小したあとの画像を ⌈幅 ÷ 28⌉ × ⌈高さ ÷ 28⌉ トークンとして数えます。1280×720なら1,196トークンです。1920×1080は標準ティアで1,560トークン、高解像度ティアを使うClaude 4.7以降のモデルでは2,691トークンです。
MCPのスクリーンショットとアクセシビリティスナップショットはどちらがトークンを使う？
ページによります。筆者の計測では、会員登録フォームのスナップショット（526トークン）は1280×720のスクリーンショット（1,196）より小さく、50行の表のスナップショット（6,583）は約5.5倍の大きさでした。スクリーンショットはrefを使ったクリックに使えないので、操作には絞り込んだスナップショットか browser_find がたいてい最適です。
PNGとJPEGでMCPのトークン消費は変わる？
Claudeでは変わりません。画像のトークン数はピクセル数だけで決まるので、同じスクリーンショットならPNG・JPEG・WebPのどれでも同じです。形式で変わるのはファイルサイズで、アップロードの上限や転送時間に影響します。
MCPのスクリーンショット1枚で10万トークンも使うのはなぜ？
画像が画像ブロックではなく、base64のテキストとしてモデルに届いている可能性が高いです。筆者の計測では、1280×720のPNGはテキストとして93,893トークン、画像として1,196トークンでした。MCPの画像コンテンツ（type: "image"）で返し、クライアントを更新し、structuredContent も返す画像ツールは個別に試してください。
Playwright MCPがスクリーンショットをモデルに送らないようにするには？
--image-responses omit を付けて起動するか、browser_take_screenshot に filename を渡します。画像はディスクに保存され、モデルには短いテキストだけが返ります。人が確認するための画像は出力ディレクトリに残ります。
Playwright MCPのスナップショットのトークンを減らすには？
browser_find でスナップショットをテキストや正規表現で検索するか、browser_snapshot に depth や target を渡します。筆者の50行のダッシュボードでは、フルスナップショットの6,583トークンに対し、browser_find は178トークン、depth: 3 は347トークンでした。
フルページのスクリーンショットはトークンを多く使う？
高解像度ティアのモデルでは使います。1280×2573のフルページ画像はClaude 4.7以降で4,232トークンですが、標準ティアでは縮小されて約1,568トークンです。2,000pxを超える画像は、1リクエストの画像が20枚を超えたときに厳しい制限にも当たります。
スクリーンショットはツール呼び出しのあともコンテキストに残る？
残ります。ほかのツール結果と同じく、消去か要約されるまで、以降のリクエストで毎回送り直されます。プロンプトキャッシュが効けば送り直しはキャッシュ読み出しの単価になりますが、コンテキストウィンドウは埋まっていきます。
Claude APIの「20枚」の制限とは？
1リクエストに含まれる画像が20枚を超えると（過去のツール結果の中の画像も数える）、すべての画像に1枚ごとの厳しいサイズ制限がかかります。Anthropicのドキュメントは、縦横とも2,000px以下にするか、画像とドキュメントのブロックを20個以下に抑えることをすすめています。
Chrome DevTools MCPにも同じような節約の設定はある？
あります。take_snapshot の説明はスクリーンショットよりスナップショットを優先するよう求めており、verbose は既定でオフです。take_snapshot と take_screenshot はどちらも filePath で、結果に添付せずファイルに保存できます。
ここでいう「MCP Token」はAPIトークンのこと？
違います。この記事が扱うのは、MCPのツール結果やツール定義が消費するLLMのトークンです。MCPサーバーのAPIキーやOAuthのアクセストークンはセキュリティの話題です。
まとめ
ブラウザ系のMCPサーバーは、ほぼ毎ステップでページの状態を返すため、MCPのトークン消費が特に大きくなりやすいサーバーです。Claudeではスクリーンショットのコストはピクセル数で決まるので、効くのはビューポート、デバイス倍率、フルページかどうか、モデルの画像ティアで、画像形式は関係ありません。アクセシビリティスナップショットは単純なページでは安く、要素の多いページでは高くなります。browser_find や depth のような絞り込みはどちらよりも安く済みます。画像は画像として届くようにし、証跡のスクリーンショットはファイルに保存し、取得したページ情報は操作が終わるまで履歴に残り続けることを前提に設計してください。
参考資料
- MCP仕様 2026-07-28：Tools（ツール結果の画像コンテンツ）
- Claude Docs：Vision
- Claude Docs：Pricing
- Claude Code Docs：Connect Claude Code to tools via MCP
- Playwright MCP（GitHub、README v0.0.83）
- Playwright MCP：Vision mode ・ Configuration options
- Chrome DevTools MCP：Tool reference
- OpenAI Docs：Images and vision
- Claude Code issue #31208：MCPのImageContentがテキストとして返る ・ issue #9152：画像レスポンスが25000トークンを超える
- gpt-tokenizer（npm）：テキストのトークン数の計測に使用
関連記事：MCPツールのレスポンスを小さくする方法 ・ 長いセッションで古いツール結果を消去する方法 ・ Playwright MCPをリモートでホストする方法
