結局、Playwrightは消すべきですか？

いいえ。Playwright 公式は『削除しないで』と明言し、バズった主張を誤解としています。重要な事実は、Playwright の npm パッケージ自体はブラウザを同梱していないことです。Playwright MCP や CLI のエージェントは、あなたのマシンにある安定版の Chrome / Edge を使うので、通常の Chrome セキュリティ更新を受け取り、サンドボックスも有効です（設定変更は不要）。一方、主張の『芯』も無視はできません。テストランナーやライブラリの既定が使う“ピン留めされたブラウザ”は Chrome 安定版のセキュリティ修正に遅れうること、そして既定でサンドボックスがオフなことは事実で、これは“開いたウェブを触るエージェント”では現実的な露出になります。『消す』ではなく『用途に合わせて守る』が正解です。

サンドボックスが『既定でオフ』とはどういうことですか？

Playwright の launch オプション chromiumSandbox の既定は false です（公式ドキュメント）。サンドボックスは、ブラウザのバグとあなたのマシンの間の壁です。これが無いと、悪用に成功した悪意あるページが『あなた自身』として実行され、ファイル・.env・SSH鍵・ログイン済みトークンにアクセスできてしまいます。自分の信頼できるアプリを localhost でテストするだけなら、触るのは自分のサイトなのでリスクは小さい。問題は、タスクや検索結果やプロンプトインジェクションで“任意のサイト”を開くエージェントです。そこでは、壁が無いことの意味が大きく変わります。

なぜ『ピン留めされたブラウザ』が問題になるのですか？

npx playwright install や既定の chromium.launch() は、そのリリースでテストされたビルドにブラウザを固定します。これはテストの再現性のための意図的な設計で、ブラウザの突然の更新でスイートが壊れないという利点があります。半面、そのビルドは次の Playwright リリースまで Chrome 安定版のセキュリティ修正を取り込まない可能性があります。信頼できるアプリの e2e テストなら許容できるトレードオフですが、敵対的なウェブを開く用途には向きません。公式も『敵対的なウェブでは使わないで』としています。

Docker を使っていれば安全ですか？

とは限りません。主張側が指摘するとおり、Playwright の Docker イメージは既定で root として実行され、それにより Chromium のサンドボックスが無効になります。公式ドキュメントも、信頼できないウェブサイトには推奨されないとしています。コンテナに入れること自体は良い隔離ですが、root で動かすとサンドボックスが切れる点、そして本物の認証情報やホームディレクトリをマウントしていないかは別途確認が必要です。非root・使い捨てプロファイルで動かすのが安全側です。

AI AGENTAIエージェント

Playwrightを消すな｜古いChromiumとサンドボックスOFF論争の正しい読み方

Don't delete Playwright: making sense of the bundled-Chromium and sandbox-off debate for agents

2026.11.04更新 2026.11.04 約10分で読めます執筆: AI Heartland 編集部

Playwrightを消すな｜古いChromiumとサンドボックスOFF論争の正しい読み方

WHY READ

『Playwrightを消せ』論争を中立に整理。パッケージはブラウザ非同梱という公式の事実と、ピン留めブラウザ＋サンドボックスOFFが“開いたウェブを触るエージェント”で効く理由、本物のChrome＋サンドボックス＋隔離という対策をまとめる。

「最新の Playwright でも CVE 入りの古い Chromium を同梱していて、サンドボックスも既定でオフだから今すぐ消せ」——という投稿がバズり、Playwright 公式（@playwrightweb）が「削除しないで。それは誤解です」と反論した。どちらが正しいのか。結論を先に言うと、「消せ」は言い過ぎだが、主張の芯（ピン留めブラウザの遅れ＋サンドボックスOFF）は本物で、それが効くのは“開いたウェブを触るエージェント”だ。この記事は、Playwright 公式ドキュメントと両者のポストを一次に、Playwright サンドボックスの既定と対策を中立に整理する。攻撃の再現手順（PoC）は扱わない。まず確かめることは、自分の使い方が「信頼アプリのテスト」か「任意サイトを開くエージェント」かだ。

THE DEBATE削除しろ vs 削除するな

『Playwrightを消せ』は言い過ぎ、でも芯はある

バズった主張（nisten）

Playwright公式の反論

バズった主張（nisten）: 最新1.64.1でも古いChromium 156を同梱しCVEが残る

Playwright公式の反論: Playwrightパッケージはブラウザを同梱していない

バズった主張（nisten）: サンドボックスは既定でOFF＝危険、今すぐ削除を

Playwright公式の反論: MCP/CLIのエージェントはあなたの安定版Chromeを使い更新もサンドボックスも効く

バズった主張（nisten）: （本人も）信頼アプリのlocalhostテストはリスク低いと認める

Playwright公式の反論: 削除しないで。仕組みと対処法はある、という立場

出典: @nisten と @playwrightweb の公開ポスト（ユーザー提供・2026-11-04 確認）。どちらも対策はほぼ一致

30秒でわかる（2026-11-04確認）

・Playwrightのnpmパッケージはブラウザを同梱していない（公式）。MCP/CLIが『あなたのChrome』を使う構成なら更新もサンドボックスも効く。
・ただし既定は危うい：test runner/libraryの chromium.launch() はピン留めブラウザ＋サンドボックスOFF。Chromeの修正に遅れ、壁も無い。
・効くのは“開いたウェブを触るエージェント”。信頼アプリ/localhostのe2eならリスクは低い。分かれ目は「何を訪れるか」。
・対策は本物のChrome＋サンドボックスON＋隔離。MCPは0.0.40以降（CVE-2025-9611修正）。削除はしない。

基盤ソフトの脆弱性がどう広がるかはサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめている。盗まれた認証情報の悪用経路はCursor 改ざん拡張のSSHバックドアやVOLTA（AIで被害者を値付けする情報窃取）が参考になる。今回は「エージェントが使うブラウザ自体」の安全性だ。

そもそもこの話がこれほど刺さったのは、コーディングエージェントが開発者のノートPC上で“開いたウェブ”を自分で開くことが、ここ数か月で一気に当たり前になったからだ。元の投稿も「コンテナなしでラップトップの上で裸でバイブコーディングしている人へ」と呼びかけている。テスト自動化の道具だった Playwright が、いまはエージェントの“手足”としてインターネット全体に向けられている——その文脈の変化が、同じ既定値（ピン留めブラウザ＋サンドボックスOFF）の意味を変えた、というのが要点だ。

誤解と事実：パッケージはブラウザを同梱していない

まず、バズった主張のうち事実と違う部分を公式が正している。Playwright の npm パッケージは、それ自体がブラウザを同梱しているわけではない。ブラウザは別途取得する。そして Playwright MCP や CLI のエージェントは、あなたのマシンにある安定版の Chrome / Edge を実行する。だから通常の Chrome セキュリティ更新を受け取り、サンドボックスも有効で、設定の編集は要らない——というのが公式の説明だ。この構成で使っている限り、「古い Chromium が刺さったまま」という前提は当てはまらない。

つまり「Playwright＝危険なブラウザを抱え込む」という単純化は正確ではない。ここは主張側も、落ち着いて見れば否定していない部分だ。

本当の懸念：ピン留めブラウザ＋サンドボックスOFF

WHERE THE RISK IS本当に効くのはどこか

“開いたウェブを触るエージェント”で効く

1.パッケージ自体はブラウザ非同梱
ブラウザは別途ダウンロード。MCP/CLIで『あなたのChrome』を使う構成なら更新もサンドボックスも効き、設定変更も不要（公式）
2.①ピン留めブラウザが遅れる
test runnerやlibraryの chromium.launch() は、テスト済みビルドに固定＝Chrome安定版のセキュリティ修正に次のPlaywrightリリースまで遅れうる
3.②既定でサンドボックスOFF
chromiumSandbox の既定は false。壁が無いと、悪用に成功した悪意ページが『あなた』として走り、.env・SSH鍵・ログイン済みトークンに届く
4.分かれ目は“何を訪れるか”
自分の信頼アプリ/localhostのe2eならリスクは低い。タスクや検索やプロンプト注入で任意のサイトを開くエージェントは別。ここが芯

出典: Playwright公式ドキュメント(chromiumSandbox 既定false)＋両ポスト（2026-11-04 確認）

一方で、主張の芯は本物だ。2つある。

①ピン留めされたブラウザ。 npx playwright install や既定の chromium.launch() は、そのリリースでテストされたビルドにブラウザを固定する。これはテストの再現性のための意図的な設計で、ブラウザの突然の更新でスイートが壊れない利点がある。半面、そのビルドは次の Playwright リリースまで、Chrome 安定版のセキュリティ修正を取り込まないことがある。主張側は、同梱 Chromium と Chrome 安定版の版を比べ、直近で修正されたいくつかの Chrome の脆弱性（FileSystem・FileAPI・Skia・Layout・MediaStream などの重大バグ）がまだ開いている可能性が高いとしている。ただし本人も「これは版番号の比較で、各 CVE を個別に検証したわけではない」と明記している——ここは“可能性の指摘”として読むのが正確だ。

②既定でサンドボックスOFF。 chromiumSandbox の既定は false だ（公式ドキュメント）。サンドボックスは、ブラウザのバグとあなたのマシンの間の壁である。これが無いと、悪用に成功した悪意あるページがあなた自身として実行され、ファイル・.env・SSH鍵・ログイン済みトークンにアクセスできてしまう。この2つが重なると、「古いかもしれないブラウザを、壁なしで動かす」ことになる。

なぜエージェントだと悪化するのか

ここが分かれ目だ。自分の信頼できるアプリを localhost でテストするだけなら、ブラウザが触るのは自分のサイトなので、上の2点のリスクは小さい。主張側ですら「信頼できるコンテンツで自分の localhost に対するテストはリスクがはるかに低い」と認めている。

問題は、タスク・検索結果・プロンプトインジェクションによって“任意のサイト”を開くエージェントだ。古いかもしれないブラウザで、壁なしで、しかも日常のマシン上で開いたウェブに触れる——これは露出の形がまるで違う。さらに Playwright は、自身の MCP サーバーについて「セキュリティ境界ではない」と述べており、--allowed-origins の既定はすべてを許可する。実際、Playwright MCP には DNS リバインドの脆弱性（CVE-2025-9611・GHSA-6fg3-hvw7-2fwq）があり、ウェブサイトがローカルの MCP ツールを呼び出せる問題として修正されている（0.0.40 以降）。「Docker だから大丈夫」も必ずしも正しくない。Playwright の Docker イメージは既定で root 実行で、それにより Chromium のサンドボックスが無効になる。

対策：本物のChrome＋サンドボックス＋隔離

面白いことに、対策については主張側と公式がほぼ一致している。要は「開いたウェブを触るなら、ちゃんと守れ」だ。

WHAT TO DO対策（両者ほぼ合意）

本物のChrome＋サンドボックスと隔離

1.開いたウェブ/エージェントは本物Chrome＋サンドボックス
chromium.launch({ channel: 'chrome', chromiumSandbox: true })。Chrome/Edgeを常に更新。Playwrightも最新へ
2.隔離して走らせる
ブラウジングするエージェントはVMか非rootコンテナで。本物の認証情報を使わず、homeをマウントせず、使い捨てプロファイルで
3.ツールを固定し、MCPを上げる
@latestで無検証に最新を掴まない。Playwright MCP 0.0.40以降でDNSリバインド(CVE-2025-9611)修正。--allowed-origins の既定は全許可に注意
4.削除はしない・自己確認する
信頼テスト用途には優れた道具。ls ~/.cache/ms-playwright と npx --no-install playwright --version で自分の版を確認

出典: 両ポストの対処法（概ね一致・2026-11-04 確認）。MCPは『セキュリティ境界ではない』と公式も明記

まず、開いたウェブやエージェント用途では、ピン留めビルドではなく本物の Chrome をサンドボックス付きで使う。これが一番効く。

// 開いたウェブ/エージェント向け：本物のChrome＋サンドボックスON
chromium.launch({ channel: 'chrome', chromiumSandbox: true })

そのうえで、隔離する。ブラウジングするエージェントは VM か非rootのコンテナで動かし、本物の認証情報を使わず、ホームディレクトリをマウントせず、使い捨てのプロファイルを使う。ツールは固定し（@latest で無検証に最新を掴まない）、Playwright MCP は 0.0.40 以降にして CVE-2025-9611 を塞ぐ。Chrome / Edge は常に更新する（サンドボックスを抜けるバグもあるため、箱だけに頼らない）。自分の状態は、何もダウンロードせずに確認できる。

# 自分のPlaywrightとブラウザ・版を確認（ダウンロードしない）
ls ~/.cache/ms-playwright ~/Library/Caches/ms-playwright 2>/dev/null
npx --no-install playwright --version

ここで出る chromium-<番号> が、ピン留めされているビルドだ。番号が新しいほど新しく、古い番号なら古い（主張側は、ある時点で chromium-1248 が 1.64.1 のビルドだと例示している）。なお --no-install を付けるのは、パッケージが無いときに npx が勝手にダウンロードして実行してしまうのを避けるためだ。確認の時点で余計なものを取ってこない、という小さな用心でもある。注意したいのは、たとえ「最新」を入れていても、Playwright のブラウザは Playwright が新バージョンを出したときにしか更新されないため、Chrome 安定版との間に時間差が残りうる点だ。だからこそ、開いたウェブ用途では channel:'chrome' で“自分が更新している実物の Chrome”を指す意味がある。

用途ごとの既定を、表で整理しておく。

使い方	使うブラウザ	サンドボックス	向く用途
MCP / CLI（channel 指定）	あなたの安定版 Chrome/Edge	有効	更新が効く。設定変更不要（公式推奨の形）
test runner / `chromium.launch()` 既定	ピン留めビルド	無効	自分の信頼アプリの e2e（再現性重視）
開いたウェブ・エージェント	`channel:'chrome'`＋`chromiumSandbox:true`	有効	任意サイトを触る用途はこれ＋隔離

この記事の結論

・「Playwrightを消せ」は言い過ぎ。パッケージはブラウザ非同梱で、MCP/CLIが『あなたのChrome』を使う構成なら更新もサンドボックスも効く（公式）。
・ただし芯は本物：既定の chromium.launch() はピン留めブラウザ＋サンドボックスOFF。Chromeの修正に遅れ、壁も無い。
・効くのは“開いたウェブを触るエージェント”。信頼アプリ/localhostのe2eならリスクは低い。分かれ目は「何を訪れるか」。
・対策（両者ほぼ合意）：本物のChrome＋chromiumSandbox:true、VM/非rootコンテナ＋使い捨てプロファイル、ツール固定、MCP 0.0.40以降、Chrome常時更新。削除はしない。

参照ソース

Playwright 公式（@playwrightweb）の反論ポスト（削除するな・パッケージはブラウザ非同梱・MCP/CLIは安定版Chromeを使う。本記事はユーザー提供のスクリーンショットを一次とした）
Playwright 公式ドキュメント（chromiumSandbox の既定・channel 指定）
GHSA-6fg3-hvw7-2fwq / CVE-2025-9611（Playwright MCP の DNS リバインド・High。0.0.40 以降で修正とされる）

FAQよくある質問

結局、Playwrightは消すべきですか？: いいえ。Playwright 公式は『削除しないで』と明言し、バズった主張を誤解としています。重要な事実は、Playwright の npm パッケージ自体はブラウザを同梱していないことです。Playwright MCP や CLI のエージェントは、あなたのマシンにある安定版の Chrome / Edge を使うので、通常の Chrome セキュリティ更新を受け取り、サンドボックスも有効です（設定変更は不要）。一方、主張の『芯』も無視はできません。テストランナーやライブラリの既定が使う“ピン留めされたブラウザ”は Chrome 安定版のセキュリティ修正に遅れうること、そして既定でサンドボックスがオフなことは事実で、これは“開いたウェブを触るエージェント”では現実的な露出になります。『消す』ではなく『用途に合わせて守る』が正解です。
サンドボックスが『既定でオフ』とはどういうことですか？: Playwright の launch オプション chromiumSandbox の既定は false です（公式ドキュメント）。サンドボックスは、ブラウザのバグとあなたのマシンの間の壁です。これが無いと、悪用に成功した悪意あるページが『あなた自身』として実行され、ファイル・.env・SSH鍵・ログイン済みトークンにアクセスできてしまいます。自分の信頼できるアプリを localhost でテストするだけなら、触るのは自分のサイトなのでリスクは小さい。問題は、タスクや検索結果やプロンプトインジェクションで“任意のサイト”を開くエージェントです。そこでは、壁が無いことの意味が大きく変わります。
なぜ『ピン留めされたブラウザ』が問題になるのですか？: npx playwright install や既定の chromium.launch() は、そのリリースでテストされたビルドにブラウザを固定します。これはテストの再現性のための意図的な設計で、ブラウザの突然の更新でスイートが壊れないという利点があります。半面、そのビルドは次の Playwright リリースまで Chrome 安定版のセキュリティ修正を取り込まない可能性があります。信頼できるアプリの e2e テストなら許容できるトレードオフですが、敵対的なウェブを開く用途には向きません。公式も『敵対的なウェブでは使わないで』としています。
Docker を使っていれば安全ですか？: とは限りません。主張側が指摘するとおり、Playwright の Docker イメージは既定で root として実行され、それにより Chromium のサンドボックスが無効になります。公式ドキュメントも、信頼できないウェブサイトには推奨されないとしています。コンテナに入れること自体は良い隔離ですが、root で動かすとサンドボックスが切れる点、そして本物の認証情報やホームディレクトリをマウントしていないかは別途確認が必要です。非root・使い捨てプロファイルで動かすのが安全側です。