Nodeflare
記事一覧
MCPホスティング

Playwright MCPをリモートでホスティングする：Docker設定・クライアントごとのメモリ・3つのブラウザモードを実測【MCP Hosting 2026】

Playwright MCPをClaude・Cursor・自作エージェントからリモートで使うには？@playwright/mcp 0.0.83をHTTPモードで実測し、root実行時のサンドボックスエラー、独自ドメインで出る403、--isolatedなしで2人目が失敗する理由、クライアントごとのメモリ（1人413MB、4人586MB）、idle-timeout、サーバーに残るスナップショットファイル、Docker・Cloudflare Browser Run・CDP接続・ホスト型ブラウザMCPの比較を解説します。

最終更新：2026年10月21日 ／ 対象：@playwright/mcp 0.0.83（npmの最新版。2026年9月28日公開。Playwright 1.64.0-alpha と Chrome for Testing 155 を同梱）、Playwright公式のDockerドキュメント（v1.64.0）、2026年10月時点のCloudflare Browser Runの制限と料金。計測は2026年10月21日、2 vCPU・メモリ8GBのLinuxコンテナで、Node.js 22.22.0、クライアントにMCP TypeScript SDK 1.32.1を使用

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

Playwright MCPをリモートでホスティングするとは、Microsoftのブラウザ操作用MCPサーバーをHTTPモード（--port）でChromium入りのマシンに常駐させ、Claude・Cursor・自作エージェントからURLで使えるようにすることです。手元でstdio起動する代わりにサーバー側で動かします。MCP Hostingの中でも、セッションごとに本物のブラウザが動く点で、普通のMCPサーバーとは勝手が違います。実際に動かして分かったことは次のとおりです。

  • 動くかどうかは4つのフラグで決まります。--headless（サーバーには画面がない）、--port と --host 0.0.0.0、--allowed-hosts（付けないと、独自ドメインの Host ヘッダーで来たリクエストが 403 Access is only allowed at localhost:<port> になる）、そしてroot実行時の --no-sandbox（付けないと最初のツール呼び出しが「Chromium sandboxing failed!」で失敗する）です。
  • 既定のプロファイルモードで使えるのは1クライアントだけです。同時に接続した2つ目のクライアントは「Browser is already in use … use --isolated to run multiple instances」で失敗しました。--isolated では、1つのブラウザの中にクライアントごとの独立したコンテキストができ、全員が動きました。--shared-browser-context ではクライアント同士がぶつかり、一方のページ移動がもう一方の操作で net::ERR_ABORTED になりました。
  • サイズを決めるのはメモリです。サーバー単体は約120MB（PSS）、1クライアントがページを開いた状態で9プロセス合計413〜439MB、isolatedの2クライアントで479MB、4クライアントで586MBでした。今回の検証ページでは、軽いセッションが1つ増えるごとに約55〜65MB増えます。
  • ブラウザはクライアントが去っても残ります。全員が切断したあともメモリは435MBのままで、--idle-timeout（headlessの既定は1時間）まで解放されません。--idle-timeout 5000 にすると5秒後に143MBまで下がり、次の呼び出しではブラウザが約0.5秒で再起動しました。
  • 出力の一部はサーバーに残ります。browser_navigate はページのスナップショットを、サーバーのディスク上の .playwright-mcp/page-….yml へのリンクとして返しました。リモートのクライアントからは開けません。browser_snapshot を呼ぶと本文に含めて返ります（200行の表があるページで43,653バイト）。

フラグの一覧は3章、モードの検証は4章、メモリの数値は5章にあります。

目次

  1. Playwright MCPをリモートでホスティングするとは
  2. ブラウザ系MCPサーバーのホスティング方法の比較
  3. 動く最小コマンドとフラグの意味
  4. プロファイルの3モード：既定・--isolated・--shared-browser-context（実測）
  5. クライアントごとのメモリと速度（実測）
  6. Docker：公式イメージとバージョン固定のDockerfile
  7. 費用の考え方
  8. Claude・Cursor・自作エージェントからの接続
  9. チェックリスト
  10. よくあるハマりどころ（症状→原因→対処）
  11. NodeFlareならこう解決できる
  12. FAQ

1. Playwright MCPをリモートでホスティングするとは

Playwright MCPをリモートでホスティングするとは、@playwright/mcp サーバーを専用のブラウザごとHTTPサービスとして常駐させ、利用者のPC以外の場所で動かすことです。手元で使う場合は、Claude Codeなどのクライアントが npx @playwright/mcp@latest をstdioで起動し、Chromeのウィンドウが開きます。リモートでは画面がないのでブラウザはheadlessで動き、1台のサーバーを複数のクライアントで共有することもあります。

リモートで動かしたくなる理由は主に3つです。

  • クラウド側のクライアントはローカルのプロセスを起動できません。Claudeのカスタムコネクタ、ChatGPT、Claude APIやOpenAI Responses APIで作ったエージェントが呼べるのはURLだけです。
  • チームでブラウザの設定を1つにまとめられます。フォント、プロキシ、許可するオリジン、テスト用のログイン状態を一度だけ設定すれば済みます。
  • サーバー上で動くエージェントにはサーバー上のブラウザが必要です。CIのジョブや定期実行のエージェントは、ノートPCのブラウザを使えません。

Playwright MCPは基本はstdioのサーバーですが、HTTPモードも内蔵しています。READMEには「HTTPトランスポートを有効にするには --port を渡す」とあり、起動すると旧方式のSSEが /sse で使えることも表示されます。そのため、GitHubにある多くのstdio専用サーバーと違い、stdioをHTTPに変換するブリッジは要りません。ブリッジが必要なサーバーの場合は stdioのMCPサーバーをリモートで動かす方法 を参照してください。

2. ブラウザ系MCPサーバーのホスティング方法の比較

リモートのエージェントにMCP経由でブラウザを使わせる方法は、主に5つあります。違いは、ブラウザがどこで動くか、どのバージョンのPlaywright MCPになるか、何に課金されるかです。

方法 ブラウザが動く場所 Playwright MCPのバージョン 複数クライアント 課金の単位 主な注意点
公式Dockerイメージ mcr.microsoft.com/playwright/mcp をVPSやコンテナ基盤で動かす サーバーと同じコンテナ 本家（最新） --isolated で可 VMやコンテナの料金 「現時点ではheadlessのChromiumのみ対応」。例では --no-sandbox 付き
自前イメージ（Node.js＋バージョン固定の @playwright/mcp＋Chromium） 同じコンテナ 固定した任意のバージョン --isolated で可 VMやコンテナの料金 ブラウザのリビジョンを自分で合わせる必要がある（6章）
Cloudflare Workers＋@cloudflare/playwright-mcp＋Browser Run Cloudflareのブラウザ基盤 「本家Playwright MCP v0.0.30と同期」したフォーク セッションごとにDurable Object ブラウザ時間と同時ブラウザ数（7章） 本家より古い（0.0.30対0.0.83）。アイドル中のブラウザは既定60秒で閉じる
Playwright MCPの --cdp-endpoint で外部のブラウザサービスにつなぐ ブラウザサービス側 本家 サービスしだい MCPサーバー＋ブラウザサービス 動かして守る対象が2つになる。認証は --cdp-header
ホスト型のブラウザMCP（例：Browserbaseの https://mcp.browserbase.com/mcp） ベンダーのブラウザ Playwright MCPではない（Stagehandベースのツール） 可 ベンダーのプラン ツールの構成が違う。操作は既定で google/gemini-2.5-flash-lite が判断する

選び方の目安です。

  • 手元と同じツール（browser_navigate、browser_snapshot、browser_click など、0.0.83で数えると25個）をそのまま使いたいなら、本家のPlaywright MCPをDockerかMCPホスティングで自分で動かします。
  • すでにCloudflare Workersを使っていて、古いツール構成でも困らないなら、Cloudflareのフォークを使うとブラウザの運用を手放せます。
  • 同時に多数のブラウザを使う、あるいはブラウザの指紋対策などが必要なら、--cdp-endpoint でブラウザをMCPサーバーから切り離すか、ホスト型のブラウザMCPを使います。

3. 動く最小コマンドとフラグの意味

検証で複数のリモートクライアントを捌けた最小のコマンドは次のとおりです。

npx @playwright/mcp@0.0.83 \
  --headless \
  --isolated \
  --port 8931 --host 0.0.0.0 \
  --allowed-hosts mcp.example.com \
  --output-dir /tmp/playwright-mcp \
  --idle-timeout 600000
# rootで動かす場合だけ --no-sandbox を追加（下記参照）

各フラグの役割と、付けなかったときに起きたことです。

フラグ 既定値 ホスティングで必要な理由 付けなかったときの結果
--headless 画面あり サーバーには画面がない READMEによると、画面ありのブラウザには DISPLAY のある環境が必要
--port 8931 stdio HTTPを有効にする。クライアントは /mcp（Streamable HTTP）か /sse（旧方式）につなぐ stdioでしか通信しない
--host 0.0.0.0 localhost コンテナの外からの接続を受け付ける 他のホストから届かない
--allowed-hosts <ドメイン> バインドしたホスト サーバーが Host ヘッダーを検査する Host: mcp.example.com のリクエストが 403 Access is only allowed at localhost:8934。--allowed-hosts mcp.example.com を足すと 200
--isolated ディスク上の永続プロファイル 複数のクライアントを同時に受け付ける 2つ目のクライアントが「Browser is already in use」（4章）
--no-sandbox サンドボックス有効 rootではChromiumのサンドボックスが使えない 最初のツール呼び出しが「Chromium sandboxing failed!」で失敗
--output-dir 作業ディレクトリの .playwright-mcp スナップショット・スクリーンショット・コンソールログをアプリのディレクトリに置かない 短いテストを10回ほどで876KBのファイルがたまった
--idle-timeout <ミリ秒> headlessは1時間 利用の合間にブラウザのメモリを解放する 全クライアントが去ったあとも435MBのまま

補足が2つあります。

  • 信頼できないサイトを開くなら、--no-sandbox よりroot以外のユーザーで動かす方が安全です。PlaywrightのDockerドキュメントは、rootで動かすと「Chromiumのサンドボックスが無効になる」と説明し、「信頼できないサイト」やクローリング、スクレイピングでは別ユーザー（--user pwuser）とseccompプロファイルを使うよう勧めています。信頼できるテスト対象だけなら --no-sandbox で問題ありません。
  • ホストの検査は認証ではありません。想定外の Host ヘッダーを弾くだけです。READMEには「Playwright MCPはセキュリティ境界ではない」と明記されているので、インターネットから届く場所に置くなら前段に認証が必要です。認証の詳細はセキュリティカテゴリの記事で扱い、この記事ではサーバーを動かすことに絞ります。

ほかにホスティングで効くオプションとして、--timeout-navigation（既定60,000ms）、--timeout-action（5,000ms）、--output-max-size（指定したバイト数を超えたら古い出力ファイルを消す）、--storage-state（isolatedセッションにCookieを読み込む）、--cdp-endpoint と --cdp-header（外部のブラウザを使う）、--secrets（dotenv形式のファイルの値をツールの応答で伏せ字にする）があります。

4. プロファイルの3モード：既定・--isolated・--shared-browser-context（実測）

Playwright MCPには、HTTPのクライアントとブラウザの状態を対応させる方法が3つあり、独立した複数のクライアントを捌けるのは1つだけです。MCP TypeScript SDKで2つのクライアントを同時に接続し、それぞれ browser_navigate を2回呼んで確かめました。

モード フラグ ブラウザの状態 同時に2クライアントでの結果 向いている用途
永続プロファイル （既定） ディスク上の1つのプロファイルを使い続ける 1つ目は成功。2つ目は「Browser is already in use for /root/.cache/ms-playwright-mcp/mcp-chrome-ae9083d, use --isolated to run multiple instances of the same browser」で失敗 ログイン状態を残したい1人用
isolated --isolated 1つのブラウザの中に、クライアントごとのメモリ上のコンテキスト。何も保存しない 両方成功し、ページも別々 共有サーバー、エージェント、CI
共有コンテキスト --shared-browser-context 1つのコンテキストとタブを全クライアントで共有 1つ目は成功。2つ目のページ移動は、1つ目が同じタブを移動したため net::ERR_ABORTED で失敗 意図して1つのセッションを協調操作するエージェント群

見落としやすい点が2つあります。

  • プロファイルの場所がREADMEと違います。READMEにはLinuxで ~/.cache/ms-playwright/mcp-{channel}-{workspace-hash} とありますが、0.0.83では /root/.cache/ms-playwright-mcp/mcp-chrome-ae9083d が使われていました。プロファイルを残すためにボリュームをマウントするなら、実際のパスを確認するか、--user-data-dir で明示してください。
  • isolatedでもログイン済みの状態から始められます。Cookieを一度書き出して --storage-state state.json を渡せば、新しいisolatedセッションはすべてその状態から始まり、ファイルには書き戻されません。

ログインを残したいうえに利用者が複数いる場合は、1つのプロファイルを共有せず、利用者ごとにサーバー（とプロファイル）を分けます。

5. クライアントごとのメモリと速度（実測）

ホスティングしたPlaywright MCPには、最初の1クライアントで約400〜450MB、軽いisolatedクライアントが1つ増えるごとに約55〜65MBのメモリが要りました。計測したのは、サーバーとすべてのChromiumプロセスのPSS（共有ページを公平に按分したメモリ量）の合計です。ページは見出し、検索フォーム、200行の表を置いたローカルの検証用ページを使いました。

状態 メモリ（PSS） プロセス数
サーバー起動直後（ブラウザなし） 118〜124MB 1
1クライアントがページを表示中 413〜439MB 9
isolatedで2クライアント 479MB 10
isolatedで4クライアント 586MB 12
全クライアント切断後（既定のidle-timeout） 435〜597MB（変わらず） 9〜12
--idle-timeout 5000 で切断から5秒後 143MB 1

browser_navigate 1回にかかった時間です（同じマシン上のクライアントから計測したので、ネットワークの時間は含みません）。

同時クライアント数 1回目（ブラウザ起動を含む） 2回目
1 526〜979ms 135〜192ms
2 793〜797ms 308〜313ms
4 1,183〜1,427ms 416〜631ms

サイズを決めるときの目安です。

  • 512MBで足りるのは軽いセッション1つまでです。1クライアントですでに最大439MBを使いました。JavaScriptや画像の多い実際のサイトや、タブを複数開く使い方ではもっと要ります。
  • 小さな共有サーバーなら1GBから始めるのが妥当です。軽いセッション4つで586MBだったので、重いページの余裕が残ります。これより小さくするなら、自分の対象サイトで計測してからにします。
  • CPU不足はエラーではなく遅さとして出ます。2 vCPUで4セッションを並列に動かすと、2回目のページ移動が2〜4倍遅くなりました。同時セッションが多いならCPUかレプリカを増やします。
  • idle-timeoutは利用のパターンに合わせます。既定の1時間だと、利用が集中したあとも数百MBが残り続けます。稼働中のメモリに課金される基盤なら、--idle-timeout を短くしても失うのは1秒未満のブラウザ再起動だけです。
  • 基盤側のタイムアウトも忘れないでください。遅いページの読み込みは、Playwrightのページ移動のタイムアウト（60秒）だけでなく、クライアントやプロキシの制限時間も消費します。経路ごとの一覧は MCPツール呼び出しのタイムアウト予算 にまとめています。

今回の数値は単純なページと2 vCPUのコンテナでの結果なので、下限として扱ってください。自分のサイトで、エージェントの典型的な作業を1・2・4クライアントで実行し、Node.jsのプロセスだけでなくプロセスツリー全体のメモリを測るのが確実です。

応答のサイズにも注意が要ります。検証ページでは browser_snapshot が43,653バイト、browser_take_screenshot がテキストに加えて107,140文字のbase64画像を返しました。大きな応答は帯域よりもトークンの問題になりやすいので、減らし方は MCPツールの応答によるトークン消費 を参照してください。

6. Docker：公式イメージとバージョン固定のDockerfile

Playwright MCPのREADMEには、常駐コンテナ用として次のコマンドが載っています。

docker run -d -i --rm --init --pull=always \
  --entrypoint node \
  --name playwright \
  -p 8931:8931 \
  mcr.microsoft.com/playwright/mcp \
  /app/cli.js --headless --browser chromium --no-sandbox --port 8931 --host 0.0.0.0

本番で使う前に、3か所を変えます。

  1. イメージのバージョンを固定します。タグなしのイメージに --pull=always を付けると、コンテナが再起動するたびにサーバーが更新され、ツール一覧も変わります。バージョンのタグかダイジェストで固定し、更新は意図して行います。
  2. 3章の --isolated、--allowed-hosts、--output-dir を加えます。
  3. --init は残します。PlaywrightのDockerドキュメントは「PID=1のプロセスが特別扱いされるのを避けるため」に推奨しており、Chromiumのゾンビプロセスがたまる原因の定番です。また、Chromiumには --ipc=host も推奨されていて、「付けないとChromiumがメモリ不足でクラッシュすることがある」と説明されています。

自前でイメージを作る場合は、同じ node_modules にあるPlaywrightのCLIでブラウザを入れ、@playwright/mcp が期待するリビジョンと合わせます。0.0.83は playwright-core 1.64.0-alphaに依存しており、Chrome for Testing 155（Playwrightのリビジョン1247）を前提にしています。検証環境にはリビジョン1194が入っていたため、--executable-path を指定する必要がありました。たたき台は次のとおりです。

FROM node:22-bookworm-slim
WORKDIR /app
RUN npm install @playwright/mcp@0.0.83 \
 && npx playwright install --with-deps chromium
RUN useradd -m pw && mkdir -p /tmp/playwright-mcp && chown pw /tmp/playwright-mcp
USER pw
EXPOSE 8931
CMD ["npx", "playwright-mcp", "--headless", "--browser", "chromium", "--isolated", \
     "--port", "8931", "--host", "0.0.0.0", "--allowed-hosts", "mcp.example.com", \
     "--output-dir", "/tmp/playwright-mcp", "--idle-timeout", "600000"]

この node_modules で npx playwright install --dry-run chromium を実行し、リビジョン1247が選ばれることを確認しました。なお、rootで playwright install を実行するとブラウザはrootのキャッシュに入ります。途中でユーザーを切り替えるなら、そのユーザーでインストールするか、両方の手順で PLAYWRIGHT_BROWSERS_PATH に共通のディレクトリを指定してください。root以外で動かせばChromiumのサンドボックスを残せますが、コンテナの実行環境によってはPlaywrightのDockerドキュメントにあるseccompプロファイルが必要です。

7. 費用の考え方

自分でホスティングするPlaywright MCPの費用は、稼働中のメモリの費用で決まり、そのメモリを決めるのはサーバーではなくブラウザです。5章の数値から、共有サーバーなら現実的な下限は1GBで、1か月動かし続けると1GB × 730時間 = 730GB時間です。スケールtoゼロと短い --idle-timeout を組み合わせれば、実際に使った時間分まで減らせます。

Cloudflareのフォークが使うCloudflare Browser Runは、メモリではなくブラウザに課金されます。

Cloudflare Browser Run Workers Free Workers Paid
ブラウザの利用時間 1日10分 月10時間まで込み、超過は1ブラウザ時間あたり0.09ドル
同時ブラウザ数 3 10まで込み（日ごとのピークの月平均）、超過は1ブラウザあたり2.00ドル。アカウントあたり既定200
新規ブラウザの起動 20秒に1つ 毎秒3つ
アイドル中のブラウザのタイムアウト 60秒 既定60秒、keep_alive で最大20分

エージェントでは既定の60秒が効いてきます。モデルがツール呼び出しの合間に1分以上考えると、keep_alive を延ばしていない限り、戻ったときにはブラウザが閉じています。

8. Claude・Cursor・自作エージェントからの接続

クライアントは /mcp のパスにStreamable HTTPで接続します。URLを仮のものにした例です。

# Claude Code
claude mcp add --transport http playwright https://mcp.example.com/mcp

// Cursor (~/.cursor/mcp.json)
{
  "mcpServers": {
    "playwright": { "url": "https://mcp.example.com/mcp" }
  }
}

MCP TypeScript SDKで作るエージェントは StreamableHTTPClientTransport で接続し、1つの作業の間は同じクライアントを使い続けます。そうすれば、その作業専用のisolatedなブラウザコンテキストが保たれます。手順の途中でクライアントを閉じて開き直すと、次の手順は新しいコンテキストで始まり、開いていたページは失われます。APIキーのヘッダーを含む9種類のクライアントの設定は リモートMCPクライアント設定チートシート にあります。

9. チェックリスト

  • [ ] --headless、--port、--host 0.0.0.0 を指定した
  • [ ] --allowed-hosts にクライアントが使うドメインを入れた（入れないと403になる）
  • [ ] 1人用の永続プロファイルでない限り --isolated を付けた
  • [ ] root以外のユーザーで動かしている。または、信頼できる対象に限ると分かったうえで --no-sandbox を付けた
  • [ ] @playwright/mcp とイメージのバージョンを固定し、ブラウザは同じ node_modules からインストールした
  • [ ] --output-dir を一時ディレクトリにした。ディスクが永続なら --output-max-size も付けた
  • [ ] --idle-timeout を利用のパターンに合わせた
  • [ ] 自分のページで1・2・4クライアントを計測し、メモリを決めた
  • [ ] クライアントは1つの作業の間、同じMCPクライアントを使い続け、ブラウザのコンテキストを保っている
  • [ ] Playwright MCPはセキュリティ境界ではないので、エンドポイントの前段に認証を置いた

10. よくあるハマりどころ（症状→原因→対処）

症状 原因 対処
403 Access is only allowed at localhost:<port> ホストの検査で、自分のドメインが許可されていない --allowed-hosts 自分のドメイン（ホストを検査するプロキシの後ろなら '*'）
最初のツール呼び出しで「Chromium sandboxing failed!」 rootでサンドボックス有効のまま動かしている root以外のユーザーで動かす。信頼できる対象だけなら --no-sandbox
「Browser is already in use … use --isolated」 既定の永続プロファイルに2つ目のクライアントが来た --isolated にする。または利用者ごとにサーバーを分ける
あるクライアントのページ移動が net::ERR_ABORTED で失敗 --shared-browser-context で、別のクライアントが同じタブを動かした 共有が目的でなければ --isolated
「Executable doesn't exist」やブラウザのダウンロードを求められる ブラウザのリビジョンが同梱のPlaywrightと合っていない 同じ node_modules から npx playwright install chromium。または --executable-path
最後の呼び出しから時間がたってもメモリが高いまま 既定の1時間のidle-timeoutでブラウザが残っている --idle-timeout を短くする
負荷をかけるとChromiumが落ちる 共有メモリかメモリの上限が足りない Dockerでは --ipc=host。メモリの上限を上げる
Chromiumのゾンビプロセスがたまる サーバーがPID 1で動いている docker run --init
モデルが開けない .playwright-mcp/page-….yml へのリンクを受け取る スナップショットがサーバーのディスクに保存された エージェントに browser_snapshot を呼ばせる。本文に含めて返る
永続ボリュームのディスクが埋まる スナップショット・スクリーンショット・コンソールログがたまる --output-dir を一時ディレクトリに。--output-max-size
セッションのたびにログインが消える --isolated は状態をメモリにしか持たない --storage-state で初期状態を読み込む
Cloudflareで手順の合間にブラウザが閉じる Browser Runのアイドルタイムアウト（60秒） keep_alive を延ばす（最大20分）
送信ログに、開いていないGoogleのホストへの通信が出る Chromium自身のバックグラウンド通信（検証では content-autofill.googleapis.com と accounts.google.com） 想定どおりの動作。送信ルールで許可するか無視する

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

NodeFlareは、GitHubのリポジトリからMCPサーバー（stdio専用のものを含む）を認証付きのHTTPSエンドポイントとしてデプロイするMCP Hostingサービスです。この記事で挙げた課題には、次のように対応しています。

この記事の課題 NodeFlareでの対応
Chromiumを正しいリビジョンでイメージに入れる必要がある Managed Browser（Pro以上）が、VM内のheadless Chromeを環境変数 BROWSER_URL 経由で提供します。イメージにChromeを入れる必要はありません。ブラウザへの依存を検出すると自動で提案され、別料金はかかりません。Freeでも、Playwrightのブラウザ取得のような依存パッケージのpostinstallはビルド中に実行されます
システムのツール不足によるビルド失敗 ビルド出力から不足しているツールを検出し、承認済みのaptリストから安全なものを入れて、最大3回までビルドをやり直します
--headless --isolated などのフラグを起動コマンドに付けたい 明示した起動コマンドとビルドコマンドが自動検出より優先されるので、コマンドラインをそのまま指定できます
stdio専用のブラウザ系サーバー 同梱のstdio→HTTPアダプターがサーバーを子プロセスとして起動します。落ちたときは1秒から最大30秒の間隔で再起動します
セッション数に応じて1台400〜600MB メモリは256MB・512MB・1GB・2GBから選べます。約1か月の実際の使用量から適切な容量を提案し、小さくしてメモリ不足が起きたら自動で元に戻します
利用の合間もブラウザがメモリに残る アイドル状態が数分続くとスナップショットを取って停止し、次のリクエストで1秒未満で復元します。計算資源は1GB時間あたり5円で、課金は稼働中だけです
1プロセスしか開けない永続のログインプロファイル オプションの永続ディスク（月額1GBあたり15円）はスケールtoゼロ・再デプロイ・再起動のあとも残ります。永続ディスク付きのサーバーは1台のVMで動き、同時にフォークしません
出力ファイルがディスクを埋める 既定のファイルシステムは一時的で、スケールtoゼロ・再デプロイ・再起動でリセットされます
「セキュリティ境界ではない」エンドポイントの公開 プロキシがすべてのリクエストを mcp_* のAPIキーかOAuthで認証してからVMに渡します。送信元IPを絞るネットワーク許可リストも使えます
どのブラウザ操作が遅い・失敗しているか分からない リクエストごとのログに、ツール名、所要時間（ms）、HTTPステータス、結果が残ります。保存期間はFreeが7日、ProとTeamが30日です

ドキュメントに書かれていないこと：NodeFlareのドキュメントには、BROWSER_URL の形式やPlaywright MCPでの使用例は載っていません。--cdp-endpoint などのフラグに渡す前に、サーバーの環境変数で実際の値を確認してください。

料金：Freeは0円で、MCPサーバー1台、毎月30GB時間の計算資源が使えます。Proは月額2,980円で、サーバー数は無制限、計算資源300GB時間とストレージ10GBが含まれ、Managed Browserと永続ディスクも使えます。1GBのサーバーを1日2時間動かすと、月に約60GB時間です。

最小の始め方：

  1. バージョンを固定した @playwright/mcp に依存する package.json をGitHubのリポジトリに置き、起動コマンドを playwright-mcp --headless --isolated にします。
  2. nodeflare.techでリポジトリを選び、メモリを1GBにしてデプロイします。NodeFlareは本物のMCPの initialize が通ってから公開します。
  3. 発行されたHTTPSのURLとAPIキーを、Claude・Cursor・自作エージェントに設定します。

1サーバーまで無料で試せます → nodeflare.tech

12. FAQ

Playwright MCPはリモートサーバーとして動かせますか？

動かせます。HTTPを有効にする --port、外部からの接続を受ける --host 0.0.0.0、画面のないサーバー向けの --headless を付けて起動します。クライアントは /mcp にStreamable HTTPで、古いクライアントは /sse に接続します。複数のクライアントが使うなら --isolated も付けます。

Playwright MCPで403「Access is only allowed at localhost」が出るのはなぜ？

サーバーが Host ヘッダーを検査していて、既定ではバインドしたホストしか受け付けないためです。独自ドメインやリバースプロキシの後ろでは、すべてのリクエストに自分のドメインが入るので拒否されます。--allowed-hosts にドメインを指定すると、検証では403が200になりました。

Dockerで「Chromium sandboxing failed」を直すには？

Chromiumをrootで動かすと、rootではサンドボックスが使えないためこのエラーになります。root以外のユーザーで動かす（PlaywrightのDockerドキュメントにあるseccompプロファイルを使う）か、信頼できるサイトしか開かないなら --no-sandbox を付けます。

1台のPlaywright MCPサーバーを複数人で共有できますか？

--isolated を付ければできます。HTTPのクライアントごとに、1つのブラウザの中に独立したメモリ上のコンテキストが作られます。既定の永続プロファイルのままだと、同時に接続した2つ目のクライアントは「Browser is already in use」で失敗します。

--shared-browser-contextは何をするオプションですか？

接続しているすべてのHTTPクライアントに、同じブラウザコンテキストとタブを使わせるオプションです。複数のエージェントが意図して1つのセッションを協調操作する場合にだけ役立ちます。検証では独立した2つのクライアントが干渉し、一方のページ移動がもう一方の操作で net::ERR_ABORTED になりました。

ホスティングしたPlaywright MCPにはどのくらいのメモリが必要ですか？

検証では、サーバー単体で約120MB、1クライアントがページを開いた状態で413〜439MB、isolatedの4クライアントで586MBでした。軽いセッション1つなら最低512MB、小さな共有サーバーなら1GB前後から始め、実際のサイトで計測してください。実際のサイトはたいてい検証ページより重くなります。

全員が切断してもメモリが下がらないのはなぜ？

Playwright MCPは、--idle-timeout が切れるまでブラウザを開いたままにします。headlessの既定は1時間です。短くすれば早く解放されます。検証では --idle-timeout 5000 で約440MBから143MBまで下がり、次の呼び出しではブラウザが約0.5秒で再起動しました。

ホスティングしたPlaywright MCPでログイン状態を保てますか？

方法は2つです。既定の永続プロファイルを1クライアントずつ使うか、--isolated と --storage-state を組み合わせて、保存したCookieとローカルストレージから毎回始めます。永続プロファイルには再起動後も残るディスクが必要で、同時に開けるブラウザは1つだけです。

CloudflareのPlaywright MCPはMicrosoftのものと同じですか？

同じではありません。@cloudflare/playwright-mcp はWorkersとBrowser Runで動くフォークです。Cloudflareのドキュメントでは本家のv0.0.30と同期しているとされ、本家は0.0.83まで進んでいるので、新しいツールやオプションがない場合があります。また、Browser Runはアイドル中のブラウザを既定で60秒後に閉じます。

Playwright MCPにはmcp-remoteやブリッジが必要ですか？

サーバー側にブリッジは不要です。Playwright MCPはHTTPモードを内蔵しています。クライアント側も、Claude CodeやCursorなど現在の主要なクライアントはリモートのURLに直接つなげるので、mcp-remoteが要るのはstdioにしか対応していないクライアントだけです。

まとめ

Playwright MCPは、HTTPを内蔵しているのでリモートでのホスティングが比較的簡単な一方、セッションごとに本物のブラウザが動くので重いMCPサーバーでもあります。--headless、--port、--host 0.0.0.0、--allowed-hosts を付けて起動し、共有するなら --isolated を使い、root以外で動かすか、分かったうえで --no-sandbox を付けます。メモリはサーバーではなくブラウザから見積もります。今回の検証では、最初のセッションで約400〜450MB、軽いセッションが増えるごとに約55〜65MBでした。--idle-timeout と --output-dir を設定してアイドル中のブラウザや出力ファイルがたまらないようにし、パッケージとブラウザのリビジョンは両方固定します。MCPサーバーをどこで動かすかを広く比べたい場合は MCPサーバーのホスティング基盤ランキング を参照してください。

参考資料

NodeFlare

MCP専用ホスティングサービス

GitHubにあるMCPを簡単デプロイ・簡単運用で最適化
無料で始める

他の記事

MCPトークン2026年10月21日

長いエージェントセッションのMCPトークン消費：古いツール結果をcontext editing・compaction・サブエージェントで片付ける方法【2026年コスト試算】

長いエージェントセッションでMCPのトークン消費が毎ターン増える理由と抑え方。Claude Sonnet 5.5で40リクエストを試算し、context editing（clear_tool_uses）の設定、Claude API・OpenAIのcompaction、Claude Codeの/compact・/clear・サブエージェント、消すと逆に高くつく条件を解説します。

MCPセキュリティ2026年10月21日

MCPのEnterprise-Managed Authorization・Client Credentials・通常OAuthの使い分け：呼び出し元別の選び方とID-JAG検証【MCPセキュリティ 2026】

MCP公式の認可拡張であるEnterprise-Managed Authorization（ID-JAG／Cross-App Access）とOAuth Client Credentialsの仕組み、社員・CI・サービスごとの方式の選び方、テスト済みのID-JAG検証コード（不正な許可証14件中11件を拒否）、2026年10月時点の対応クライアント、共有APIキーからの移行手順を解説します。

MCPトークン2026年10月20日

MCP・CLI・Skillsのトークン消費を比較：ツール検索が標準になった2026年の選び方とコスト計算

「MCPはCLIの4〜32倍トークンを使う」は本当か。ScalekitとChecklyのベンチマークが測った条件、Claude Codeのツール検索（デフォルト有効）で変わる計算、Agent Skillsの待機コスト約100トークン、Sonnet 5.5での1セッションあたりのコスト計算、MCP・CLI・Skillsの選び方の判断表まで。

他の記事を読む
Playwright MCPをリモートでホスティングする：Docker設定・クライアントごとのメモリ・3つのブラウザモードを実測【MCP Hosting 2026】 | Blog | Nodeflare