「AIにテストを書かせれば無料でしょ」と言われることについて
「AIにPlaywrightのテストを書かせているので、テスト作成の工数はもうほぼゼロです」と言うと、たまに「じゃあタダみたいなものですね」と返ってくることがあります。私はここで毎回同じことを思います。タダではありません。モデルを動かすたびに、トークン代というちゃんとした請求が発生しています。
私自身、Claude Codeを使う時は設計だけFableにやらせて実作業とテストはSonnetに任せる、というように普段からトークンの使い方を意識しています。だからこそ「AIにブラウザ操作をさせる」という工程も、裏でどれだけトークンを使っているかが気になっていました。調べてみると、同じ「AIにPlaywrightを触らせる」でも、経路によってトークン消費がかなり違うようです。
MCP経由とCLI経由、何が違うのか
以前Playwright MCP入門の記事で紹介した通り、Playwright MCPはブラウザを常時起動したまま、ページのアクセシビリティツリーをモデルのコンテキストに渡し続ける仕組みです。モデルは会話の中でページの状態を直接見ながら、次の操作を考えられます。
一方でPlaywright CLIは、1つ1つの操作をシェルコマンドとして実行し、結果はファイルとしてディスクに書き出す方式です。スナップショットはYAML、スクリーンショットはPNGとしてローカルに保存され、モデルはそれを「読みたい時だけ読む」形になります。複数の情報源を照らし合わせると、この「常にコンテキストに流し込む」か「必要な時だけファイルを読む」かの違いが、トークン消費の差を生んでいるようです。
実際どれくらい違うのか：114,000トークン対27,000トークン
気になる数字ですが、2026年に出た複数の記事(TestDino・Bug0・Medium等)が同じ数値を引用しています。1つのタスクをこなすのに、MCP経由ではおよそ114,000トークン、CLI経由ではおよそ27,000トークンを消費したという内容です。だいたい4倍の差になります。
金額換算も併記されていて、Claude Sonnetで計算すると1タスクあたりMCP経由が約0.34ドル、CLI経由が約0.08ドルという記載でした。1タスクだけ見ると数十円の差ですが、CIで何十本ものテストを毎日回すことを考えると、積み重なる金額はばかになりません。これ、意外と見落としがちなコストだと思います。
正直に書いておくと、この数値は複数の記事が同じベンチマーク(元はMicrosoft側の計測とされています)を引用している形で、私自身の手元でMCPとCLIを同条件で計測し直せたわけではありません（このあたりは自分で再現できていないので、断定はできません）。出典をたどると根っこは1つの計測に見えるので、「複数の独立した計測結果が一致した」というより「1つの数字が広く引用されている」と捉えた方が正確だと思います。数値そのものよりも、「MCP経由はコンテキストに状態を流し込む分だけ高くつく」という構造の話として読んでもらうのがよさそうです。
なぜMCP経由はそんなに高くつくのか
理由はシンプルで、MCPはページの中身が複雑になるほど、アクセシビリティツリーやコンソール出力を毎回まるごとモデルに渡してしまうからです。コンテンツの多いページだと、1回のやり取りだけで数千トークンを食うこともあるようです。
対してCLIは、コマンドを叩いた結果として返ってくるのは「ファイルパス」や「短いステータス行」だけです。実際に何が起きたかを知りたければ、モデルが自分でファイルを開きにいく必要があります。この「言われるまで見に行かない」設計が、トークンを溜め込まない一番の理由のようです。
スナップショットが毎ターン積み上がる、という構造の話
以前AIはスクリーンショットでなくアクセシビリティツリーを見ているという記事で書いた通り、AIエージェントはページを画像として見ているわけではなく、ボタンやリンクの役割・名前・状態がテキストで並んだツリーを読んで判断しています。MCP経由の会話では、この一覧をだいたい1手ごとに丸ごと会話履歴に積み増していきます。
会話が長くなるほど、履歴には過去のツリーがどんどん溜まっていきます。10手進めれば10回分のツリーが積み上がった状態で、モデルは次の判断のたびにその全部を読み直すことになります。ページが複雑な業務アプリだとツリー1回分だけで数千トークンになることもあるので、手数が増えるほど後半のやり取りほど重くなっていく感覚です。CLI経由だとこの「積み上げ」がそもそも発生せず、直近の実行結果だけを都度読みにいく形になるので、手数が増えてもコストの伸び方が緩やかです。ここが4倍という数字の裏側にある、地味だけど効いてくる仕組みだと思います。
作業別に見る使い分け
「じゃあ全部CLIでいいのでは」と思いたくなりますよね。ですが、そう単純でもありません。複数の記事の意見が一致していたのは、次のような住み分けです。実際の開発の作業単位に落とすと、こんな感覚になります。
- テスト作成(最初の1本): 画面を触りながらセレクタが本当に取れるか探る段階なので、その場でページの状態を見ながら考えさせたいMCPが向いています。
- デバッグ: 「なぜこの要素が見つからないのか」を1手ずつ確認しながら追う作業も、状態を見ながらの対話が要るのでMCP寄りです。
- テストの量産(2本目以降): 1本目で決まった型を横展開するだけなら、探索は不要です。決まった手順を流すだけなのでCLIの方が圧倒的に安く済みます。
- CIでの実行: 人が見ていない自動実行なので、そもそも会話的なやり取り自体が不要です。CLIとファイル出力の組み合わせが素直に向いています。
つまり「モデルにその場でページを見て考えさせたいか」「事前に決まった手順をこなさせたいか」で使い分ける、というわけです。以前Test Agentsの記事で紹介したPlanner/Generator/Healerのような役割分担も、この構造に沿って考えると腑に落ちます。探索が要るPlannerの段階はMCP寄り、決まった手順を流すGeneratorの段階はCLI寄り、というイメージです。
自分のワークフローに置き換えて考えてみる
私は普段、Claude Codeで設計をFable、実作業とテストをSonnetに任せています。この記事の内容を知ってから、「テストの作成」と「テストの実行結果の確認」を同じ経路でやらなくていいのでは、と思うようになりました。
具体的には、最初の画面調査や「このセレクタで本当に要素が取れるか」を探る段階はMCPで会話しながら進めて、テストの本数を増やす段階やCIでの実行はCLIとファイル読み込みに寄せる、という切り替えです。以前紹介したtrace CLIの記事でも触れましたが、ブラウザを開かずファイルベースで完結させる流れは、この文脈でもそのままトークン節約につながります。
自分のコスト、実際に見てみましょう
ここまで他人の計測数値の話をしてきましたが、一番確実なのは自分の手元で確認することです。Claude Codeを使っているなら、セッション中に/costと打ってみてください。これは/usageのエイリアスで、今のセッションでどれだけトークンを使ったかと、その概算コストを教えてくれます。
私のようにPro契約の場合はドル建ての請求というより、割り当てに対してどれだけ消費したかという見え方になりますが(Max/APIの契約だとモデルごとの内訳とドル換算が出ます)、それでも「このタスクは思ったより重かった」という肌感覚を掴むには十分です。MCP経由でブラウザを触らせた回とCLI経由で済ませた回で、この数字を見比べてみると、記事中の4倍という数字が自分の環境でもそれっぽく再現されるか分かります(さすがにここまで自分で試すまでは半信半疑でした)。
今日からやること
長々と書きましたが、今日から変えられることは実はそれほど多くありません。次の3つくらいで十分だと思います。
- テストの1本目・デバッグ・画面調査はMCPのままで構いません。ここを無理にCLIに寄せなくて大丈夫です。
- 2本目以降の量産とCIでの実行だけ、CLI(またはCLIベースのSkill)に寄せてみましょう。ここが一番差が出る場所です。
- 作業の節目で
/costを見る癖をつけましょう。数字を見て初めて「あ、この作業重かったんだ」と気づけます。
まとめ
というわけで、「AIに任せればタダ」という感覚は、少なくともPlaywrightのテスト生成に関しては正しくありません。経路によって数倍のトークン差が出るという話は、私自身にとっても「なんとなく便利だから使う」から「どの場面でどちらを使うか」を意識するきっかけになりました。
数値そのものは1つの計測が広く引用されている状態なので、断定はできません。ただ「常にコンテキストに流し込むMCP」と「必要な時だけ読みに行くCLI」という設計思想の違いは、今後もコスト差を生み続けると思います。これからテスト自動化にAIを組み込む方は、まず自分の環境で使用トークン数を一度確認してみることをおすすめします。
Playwright MCPの基本はPlaywright MCP入門の記事、AIにブラウザを触らせる際の注意点はプロンプトインジェクションの記事で書いているので、合わせて読んでみてください。
コメント