AIエージェント

Playwright CLIとMCPの違い：コンテキストの消費と権限の境界

2026/9/24 （更新: 2026/10/11）

🤖 AIを使用して執筆

CLIとスキルが後から出荷され、READMEはコーディングエージェントにそちらを勧めた

Playwright チームは、MCP サーバーの次に CLI とスキルを出荷し、コーディングエージェントにはそちらを勧める文を README に置いた。CLI の README は「モダンなコーディングエージェントは、MCP よりも SKILL として公開された CLI ベースのワークフローを好むようになりつつある」と書き、理由を、大きなツールスキーマと冗長なアクセシビリティツリーをモデルのコンテキストへ読み込まずに済むトークン効率に置く¹。README はこの文に続けて、CLI とスキルの組み合わせは、大きなコードベースとテストと限られたコンテキストでの推論をブラウザ自動化と両立させねばならないコーディングエージェントに向く、と書く¹。同じ文は MCP 側の README にもある²。

Playwright MCP と Playwright CLI は土台を共有する。Playwright MCP は Microsoft の Playwright チームが2025年3月21日にリポジトリを作った MCP サーバーである。スターは2026年9月22日時点で37,440である²。Playwright CLI は同じ Playwright チームのコマンドラインツールである。リポジトリは旧 playwright-cli のもので、作成日は2020年6月である。npm の @playwright/cli は2026年1月26日に公開が始まった。2026年9月22日時点で直近の版は2026年9月18日の v0.1.21、スターは13,477である¹。どちらも、Microsoft が2020年から保守するブラウザ自動化ライブラリ Playwright の上に載る。エージェント向けのブラウザ CLI を出しているのは Playwright チームだけではない。Vercel Labs の agent-browser は自らを「AI エージェント向けのブラウザ自動化 CLI」と名乗り、refs つきのアクセシビリティツリーを返す³。CLI をエージェントへ渡す形式の Agent Skills は、Anthropic が開発し、2025年12月18日に open standard として公開した。仕様のサイトは、増えつつあるエージェント製品がこの形式を採用したと書く⁴。

Playwright チームは MCP を捨てていない。CLI の README は、MCP が残る場所を「持続状態、豊かな内省、ページ構造に対する反復推論から利益を得る専門的なエージェントループ」と書き、探索的な自動化、自己修復するテスト、長時間の自律ワークフローを例に挙げる¹。ブラウザのコンテキストを保ち続ける利益がトークン費用を上回る場面が MCP の居場所で、コーディングエージェントには CLI のほうが適する、という切り分けである。二つを分けたのは、同じアクセシビリティツリーをコンテキストへ入れる経路である。ツリーの中身も削られており、2026年7月9日の両者の版はどちらもスナップショットを簡潔にしてトークンを減らしたと書く¹²。

既定で全体を応答に付けるMCPと、ファイルへ書いて取りに行かせるCLIは、それぞれ何を狙ったか

README は Playwright MCP の狙いを、LLM に「構造化されたアクセシビリティスナップショット」を通じてウェブページを操作させることだと書く²。画面の絵ではなく構造を読ませる選択であり、そのおかげでツールの適用が決定的になり、スクリーンショットに基づく方式のあいまいさを避けられる²。本稿が見る弱みはその先にある。構造を渡す経路が、コンテキストへの押し込みになっている。--snapshot-mode は、応答にスナップショットを付けるかどうかを決める。値は “full” か “none”、既定は “full” で、操作のたびにページ全体のツリーが応答としてコンテキストへ入る²。ツール定義については、Anthropic の記事が「MCP クライアントの多くはツール定義を全件、前もって直接コンテキストへ読み込む」と書く⁵。README は既定を “full” にした理由を書いていない。

Playwright CLI が狙うのは、README の言葉で言えば「トークン効率が良い。ページのデータを LLM に押し込まない」ことである¹。強みは、コンテキストに入る量をエージェントの側が決められることである。操作のたびにページ全体がコンテキストへ入る問題を解くために、各コマンドのあとの応答は、ページの URL と題、生成された Playwright コード、そしてスナップショットを書き出したファイルへのリンクという短い節からなり、ページ全体のツリーは応答に入らない¹⁶。深いツリーでコンテキストに入る量を抑えるために、snapshot --depth=N は深さを限って取る。README の注釈は「効率のためにスナップショットの深さを制限する」である¹。特定の要素の下だけが要るときは snapshot <ref> がその範囲を取り、大きなスナップショットを丸ごと取る代わりに検索したいときは find <text> が合致した節を前後3行の文脈つきで返す¹。弱みは、コンテキストの外に置いたものは、エージェントが取りに行くまで見えないことである。ページの状態を見落とすかどうかは、エージェントが深さや検索語を正しく選べるかにかかる。

CLI をエージェントへ渡す側のスキルも、同じ方向の機構を持つ。Agent Skills の仕様は「エージェントはスキルを段階的に読み込み、作業が求めるときにだけ詳細を取り込む」と書く⁴。読み込みは三段になっている。起動時には全スキルの名前と説明だけを読み込み、このメタデータは1本につき約100トークン。発動したときに SKILL.md の本文を読み込み、推奨は5,000トークン未満。資料は必要になったときだけ読む⁴。playwright-cli のスキルは、二段目にコマンドの使い方と応答の形を置き、テストの実行や録画などの手順は三段目の references/ 配下に分けて必要なときだけ読ませる⁶。

Anthropic が2025年11月4日に公開した記事は、「MCP クライアントの多くはツール定義を全件、前もって直接コンテキストへ読み込む」問題に対し、モデルがツールを呼び出すコードを書いて実行環境で走らせる解を示す。例として挙げる場面では150,000トークンが2,000トークンに減り、記事はこれを「98.7%の時間と費用の削減」と書く⁵。記事自身も「段階的開示」の節で、ツールをファイルシステム上のコードとして置けばモデルは定義を必要なときに読める、代わりに検索用のツールをサーバーへ足してもよい、と二つの経路を並べる⁵。本稿の見立てでは、Playwright CLI とスキルの組み合わせは、前者の経路をシェルとファイルシステムで実現したものに当たる。

ツールごとの型が、playwright-cliを任意の引数で呼ぶシェルの許可に置き換わり、境界の作り直しが残る

失うのはツールごとの区切りである。MCP ではツールごとに型付きのスキーマがあり、ホストはツールごとに確認を挟める。CLI とスキルでは、この区切りがシェルの許可に置き換わる。Agent Skills の仕様は allowed-tools を「実行を事前承認するツールの一覧」と定義し、実験的な項目で対応は実装により異なると注記する⁴。playwright-cli のスキルの frontmatter は allowed-tools: Bash(playwright-cli:*) Bash(npx playwright:*) Bash(npx --no-install playwright:*) と書く⁶。事前承認するのは playwright-cli と npx playwright を任意の引数で呼ぶシェルの許可で、ツールごとの型は無い。SKILL.md はこの範囲を選んだ理由を書いていない。ただし MCP 側の型も、それだけでは守りにならない。Playwright MCP の README は自らを「セキュリティ境界ではない」と書き、既定のツールに任意の JavaScript を走らせる browser_run_code_unsafe を置いて「RCE 相当」と注記する²。差は既定の許可の細かさにあり、Bash(playwright-cli:*) は run-code と eval も、ほかのコマンドと同じ一つの許可で事前承認する⁶。シェルの許可も細かく切れる。Claude Code の文書は Bash(git log *) が git log だけを許すと書き、確認を求める規則は事前承認より先に効く⁷。

この置き換えの負担は、Anthropic 自身が code execution について書く。「エージェントが生成したコードを走らせるには、適切なサンドボックス、資源制限、監視を備えた安全な実行環境が要る。こうした基盤の要件は、直接のツール呼び出しには無い運用負荷と安全上の考慮を加える」⁵。コンテキストから押し出したものは消えるのではなく、シェルの外側へ移る。

スキルの側の境界については、Li らが2026年4月3日に arXiv へ投稿した論文が、Agent Skills の構造そのものに由来する脅威を「データと命令の境界の欠如」「一回の承認で持続する信頼モデル」「マーケットプレイスの必須審査の欠如」の三つに挙げ、「漸進的な緩和だけでは対処できない」と結論する⁸。同じ論文は MCP との違いを、自然言語の命令担体、型付きインターフェース契約の欠如、一回の承認で持続する信頼モデルの三つに置き、MCP クライアントが課しうる操作ごとの確認が無いと書く⁸。論文が言う一回の承認はスキルを導入するときの承認である。導入時の一回の承認が以後の操作を覆うというその構図は、Bash(playwright-cli:*) という許可の形と重なる。ただし Claude Code では、スキルの allowed-tools の許可はそのスキルを呼んだターンだけ効き、次のメッセージで消える⁷。

代償がどれだけ続くかはここから読める。ツールごとの型付きスキーマをシェルの許可へ置き換えたのは設計上の選択である。サンドボックスと承認で境界を作り直す仕事は、この設計を使う限り残る。

MCP の側にも、既定を変えれば取りに行く機構はある。--snapshot-mode none を指定すれば応答へのスナップショットの押し込みは止まり、browser_snapshot は depth で深さを限り、target で要素の下だけを取り、filename で応答に返す代わりにファイルへ保存できる。browser_find は、要素とその ref を見つけるだけでよいときは「スナップショット全体を取るより安い」と自ら書く²。違いは機構の有無ではなく既定にあり、MCP は既定で応答にツリーを付け、CLI は既定でファイルへ書く。ツール定義のほうは、Playwright MCP が設定や DevTools などのツール群を --caps で足す opt-in にしている²。有効にしたツールの定義を前もって読み込まない設定は、後で見る tool search として API の側にあり、MCP サーバー丸ごとにも指定できる⁹。

tool searchとbrowser_findで、MCPの側も取りに行く方式へ寄った

MCP の側も取りに行く方向へ動いている。Playwright MCP 自身が browser_snapshot の filename を2025年12月11日の版で足し、作り手はその理由を「大きなスナップショットを inline にするのを避け、MCP の payload を小さく保つ」と書いた²。browser_find は2026年7月9日の版で足され、CLI の find と同じ日に同じ変更から出ている²¹。API の側では Anthropic の tool search が、ツールの数が増えると定義がコンテキストを埋め、選択の精度も落ちる問題を解くために、「ツール定義を全件、前もってコンテキストへ読み込む代わりに、Claude がツールのカタログを検索し、必要なツールだけを読み込む」と文書は書く⁹。機構は、前もって読み込まないツールに defer_loading: true を付けることである。文書は、ツールが10個以上あるときやツール定義が10kトークンを超えるときに使うよう勧める。5つのサーバーを束ねた典型的な構成ではツール定義が約55kトークンを占め、tool search がそれを「85パーセント超」減らして「3〜5個のツールだけ」を読み込むと書く⁹。code execution with MCP も同じ向きにある⁵。

方向は両側で一致している。残る差は既定の許可の細かさで、MCP はツールごとにホストの確認を挟め、playwright-cli のスキルはコマンド全体を一つのシェルの許可で事前承認する。API の側に tool search が用意され、クライアントの側にも同じ検索を自作できる以上、取りに行く方式は CLI 固有の優位ではない⁹。 必要なときに取りに行く形は、この二つのほかに、実行環境でコードを書かせてツールを呼び出す方式と、API の側でツール定義を遅延読込する方式にもある⁵⁹。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。