DockerでPlaywrightを実行する方法：3つのデプロイメントパターン

James Thompson

Scraping and Proxy Management Expert

20-Aug-2026

TL;DR:

DockerのPlaywrightには3つの実用的なデプロイメントパターンがあります。 公式イメージを使用する、制御されたブラウザーイメージを構築する、またはテストランナーをコンテナに保持し、ブラウザーをScrapeless Scraping Browserに移動させます。
Playwrightパッケージとブラウザーイメージはリリースラインで一致している必要があります。 パッケージ/イメージの不一致は、クライアントがイメージに含まれていないブラウザー実行可能ファイルを探すことになります。
Chromiumはコンテナ内で明示的なプロセスとメモリ管理が必要です。 初期プロセスを実行し、Chromiumに適切な共有メモリを与え、信頼できないページのためにサンドボックスを保護します。
カスタムイメージは、フォント、証明書、システムパッケージ、またはブラウザーポリシーをアーティファクト内で修正する必要があるときにのみ、そのメンテナンスコストを正当化します。そうでなければ、公式イメージがよりシンプルなベースラインです。
リモートクラウドブラウザーはアプリケーションイメージからブラウザーのバイナリを除去します。 PlaywrightコードはCIに残り、Scrapelessがクラウドブラウザーと地域のエグレスを操作します。
無料で始められます。 新しいScrapelessアカウントには無料のScraping Browserランタイムが含まれています — app.scrapeless.comでサインアップしてください。

はじめに: Playwrightのコンテナ化はブラウザーのコンテナ化を意味します

Playwrightコードは小さいNode.jsの依存関係であり、ブラウザーとそのLinuxライブラリが重い部分です。パッケージのみをインストールするコンテナは、成功裏にビルドできますが、Chromiumが起動するときに、実行可能ファイル、フォント、共有ライブラリ、サンドボックス権限、または共有メモリが不足しているために失敗する可能性があります。

したがって、デプロイメントの選択はアーキテクチャ的なものです。公式イメージはPlaywrightを準備されたブラウザー環境に結びつけます。カスタムイメージはオペレーティングシステムを制御します。リモートブラウザーはアプリケーションコンテナをテストや抽出コードに集中させ、ブラウザー操作を別のサービスに移動します。

このガイドでは、すべての3つのパターンをPlaywright 1.62.0と比較します。これは公式イメージに固定され、検証中に読み込まれたバージョンです。

なぜPlaywrightがコンテナ内で壊れるのか

Docker内のPlaywrightは通常、5つの境界のいずれかで失敗します。

境界	一般的な症状	設計応答
ブラウザー実行可能ファイル	“実行可能ファイルが存在しない”	パッケージとイメージを一緒に固定する
Linuxライブラリ	ブラウザーが起動中に終了する	ブラウザー準備済みのイメージから始める、または依存関係を明示的にインストールする
共有メモリ	ページの読み込み中にレンダラーが閉じる	Chromiumに適切なIPC/共有メモリ構成を提供する
プロセスライフサイクル	不良子プロセスが蓄積する	initプロセスをPID 1として実行する
サンドボックス/ユーザー	ブラウザーは隔離の弱化なしには起動しない	必要なカーネルポリシーを持つ非ルートユーザーとして実行する

公式のPlaywright Dockerガイダンスは、準備されたイメージ、バージョンの一致、--init、共有メモリ、信頼できないページのための別ユーザーモデルを文書化しています。

一目でわかる3つのデプロイメントパターン

パターン	ブラウザーの場所	イメージのメンテナンス	最適なフィット
公式Playwrightイメージ	ランナーと同じコンテナ	低	CIと制御されたテストターゲット
カスタムブラウザーイメージ	ランナーと同じコンテナ	高	固定されたフォント、証明書、パッケージ、またはポリシー
Scrapelessクラウドブラウザー	アプリケーションコンテナの外	ブラウザー層が別に管理される	動的なページ、地域のエグレス、独立したブラウザーのスケーリング

画像サイズだけで選ばないでください。ブラウザーのセキュリティ、アップグレードの所有権、同時実行性、ページの信頼、アーティファクトの再現性、ブラウザーがテストランナーとは異なるネットワークアクセスを必要とするかどうかを考慮してください。

前提条件

アプリケーションプロジェクト内のNode.js 20。
1.62.0のPlaywrightがpackage.jsonに。
最初の2つのパターンでのDocker。
リモートブラウザーパターン用のScrapelessアカウントとAPIキー。
承認されたテストターゲットまたは公開ページ。

注: 検証環境にはDockerがインストールされていないため、以下のDockerビルドとコンテナコマンドは前提条件のギャップです。正確なPlaywrightとScrapeless SDKパッケージがインストールされ、ローカルChromiumページが正常に読み込まれ、SDKのPlaywright.connectエクスポートが呼び出し可能であることが確認されました。

オプション1 — 公式Playwrightイメージを使用する

公式イメージは、コンテナが信頼されたエンドツーエンドテストを実行し、オペレーティングシステムのカスタマイズが不要な場合の最良のベースラインです。

パッケージとイメージを同じPlaywrightリリースラインに固定します：

dockerfile Copy

FROM mcr.microsoft.com/playwright:v1.62.0-noble

WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .

USER pwuser
CMD ["node", "check.mjs"]

初期プロセスと明示的なIPCポリシーでビルドして実行します：

bash Copy

docker build -t playwright-check:1.62.0 .
docker run --rm --init --ipc=host playwright-check:1.62.0

対象の信頼モデルを明示に保持します。サンドボックスなしのルート実行ブラウザーは、制御された内部テストには許容されるかもしれませんが、任意のページにはデフォルトではありません。NISTアプリケーションコンテナセキュリティガイドは、イメージの出所、ランタイム構成、ホスト制御、およびワークロードの隔離を別のレイヤーとして扱います。

オプション2 — 制御されたブラウザーイメージを構築する

カスタム画像は、ブラウザーが組織の証明書、言語フォント、メディアライブラリ、またはプラットフォームの残りと一致するベースディストリビューションを必要とする場合に便利です。

最小限のクリーンなDockerfileは、サポートされているDebianベースから始まり、Playwrightにブラウザーとそのオペレーティングシステムの依存関係をインストールするよう依頼します：

dockerfile Copy

FROM node:20-bookworm

WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
RUN npx playwright install --with-deps chromium

RUN useradd --create-home --shell /usr/sbin/nologin runner \
    && chown -R runner:runner /app
USER runner

COPY --chown=runner:runner . .
CMD ["node", "check.mjs"]

プロダクションでは、ダイジェストによってNodeベースを固定し、ブラウザーパッケージが変更されたときに再構築します。このイメージは今やあなたのチームに属しています：脆弱性スキャン、証明書、フォント、ブラウザーの更新、ベースイメージのリフレッシュはすべてリリースプロセスに組み込まれます。

共有メモリ、サンドボックス、フォント、およびPID 1

コンテナの安定性は、Chromiumの周りのランタイム契約に依存しています。

共有メモリ。 Chromiumはレンダラープロセスに共有メモリを使用します。レンダラーが負荷の下で終了する後に発見するのではなく、デプロイメント構成でIPCまたは/dev/shmポリシーを決定します。

サンドボックス。 信頼できないページを非ルートユーザーとして実行し、ブラウザーサンドボックスを保持します。Linuxのseccompはプロセスに利用可能なシステムコールを制限できます； Linux seccompフィルタの文書はそのカーネル境界を説明しています。

フォントとロケール。 ブラウザーは、間違った改行、欠落したグリフ、またはスクリーンショットの違いを生じさせながら、機能的には健康であることができます。テスト契約で必要とされる言語パックのみをインストールし、イメージ検証中に代表的なグリフを主張します。

PID 1。 Chromiumは子プロセスを作成します。initプロセスはシグナルを受け取り、子を回収する必要があります。 Open Container Initiativeランタイム構成は、準拠したコンテナランタイムが消費するプロセスおよびLinuxランタイムフィールドを定義しています。

Scrapelessでスクレイピングを開始

Scrapelessであなたのウェブスクレイピングと自動化ワークフローを強化しましょう！
今日サインアップして**$5の無料クレジット**をゲット — クレジットカード不要。

今すぐScrapelessダッシュボードで無料クレジットを請求しましょう。

オプション3 — ブラウザーをコンテナの外に移動

リモートクラウドブラウザーは、Playwrightクライアントをブラウザープロセスから分離します。CIイメージはNode.js、テストコード、およびクライアントライブラリを保持し、管理されたブラウザーはChromium、ブラウザー依存関係、セッションライフサイクル、および地域ブラウザーエグレスを所有します。

インターフェース検証中に使用されたパッケージと同じパッケージをインストールします：

bash Copy

npm install playwright@1.62.0 @scrapeless-ai/sdk@1.11.0

注：以下のコードはあなたのScrapeless APIキーを必要とします。パッケージインポートとPlaywright.connectインターフェースはローカルで実行されましたが、資格情報なしの環境はクラウドセッションを作成できませんでした。

javascript Copy

import { Playwright } from "@scrapeless-ai/sdk";

const browser = await Playwright.connect({
  sessionName: "container-runner",
  sessionTTL: 300,
  proxyCountry: "US",
});

const context = browser.contexts()[0];
const page = await context.newPage();
await page.goto("https://example.com", { waitUntil: "domcontentloaded" });
console.log(await page.title());
await browser.close();

アプリケーションイメージはもはやブラウザーバイナリやそのLinuxライブラリを必要としません。これは結合を減少させますが、ネットワーク境界を導入します：CI秘密ストアにAPIキーを保管し、外部アクセスを制限し、承認された地域を選択し、すべてのセッションを明示的に閉じてください。

スクレイピングブラウザーのクイックスタート、製品ページ、および価格を移行前にご覧ください。

CI/CDおよびスケーリングチェックリスト

Playwrightパッケージ、ブラウザーイメージ、およびロックファイルを一緒に固定してください。
パッケージ/イメージリリースラインが異なるとビルドを失敗させます。
フルスイートの前に1つのスモークナビゲーションを実行してください。
信頼できないページには非ルートブラウザーユーザーを使用します。
init、IPC、CPU、メモリ、およびエフェメラルストレージを意図的に構成してください。
資格情報はCI秘密ストアに保管し、レイヤーやビルドログには含めません。
所有者が別の上限を承認しない限り、ターゲットホストあたり3ワーカーまでの並列作業を制限します。
ジョブ結果とともにブラウザー、パッケージ、イメージ、地域、およびテストリビジョンを記録します。

Playwrightプロキシおよびクラウドブラウザーガイドは、プロキシポリシーとリモート実行への同様の分離を拡張します。

どのように選ぶ

公式のイメージを使用すると、再現可能なCIへの最短経路が得られ、ターゲットページが管理されます。ブラウザの依存関係がアプリケーションのテスト済みアーティファクトの一部である場合は、カスタムイメージをビルドします。ブラウザバイナリがアプリケーションイメージ内に存在してはならない場合や、ブラウザレイヤーが独立した地域および容量制御を必要とする場合は、Scrapeless Scraping Browserを使用します。

ハイブリッド構成が一般的です：決定論的な内部テストのために小さな公式イメージのジョブを保持し、承認されたパブリックウェブの旅を管理されたクラウドブラウザに送信します。重要な選択は、各作業クラスのブラウザライフサイクルを誰が所有するかです。

結論：ブラウザを明確な境界の内側に置く

Docker内のPlaywrightは、パッケージ、ブラウザ、オペレーティングシステム、およびランタイムポリシーが1つの契約として扱われると予測可能になります。公式イメージがその契約を提供します。カスタムイメージを使用すると、それを所有できます。リモートクラウドブラウザは、それをアプリケーションコンテナの外に移動します。

ページの信頼、保守能力、およびスケーリングのニーズに合った境界を選択し、各リリースの一部としてその境界を固定しテストします。

Playwrightインフラを簡素化する準備はできましたか？

私たちのコミュニティに参加して、無料プランを取得し、CIでブラウザ自動化を実行している開発者とつながりましょう：Discord · Telegram。

app.scrapeless.comにサインアップして、無料のScraping Browserランタイムをテストし、小さなCIランナーからリモートブラウザパターンを試してみてください。

FAQ

Q: 公式のPlaywrightイメージは本番CIに十分ですか？

公式のPlaywrightイメージは、そのリリースラインがプロジェクトパッケージと一致し、ランタイムポリシーがターゲットの信頼レベルに適合する場合、強力なベースラインです。本番環境には、イメージスキャン、シークレット管理、リソース制限、およびジョブレベルの証拠が依然として必要です。

Q: Playwrightはローカルでは動作しますが、Dockerでは失敗しますか？

コンテナに予期されたブラウザ実行ファイル、共有ライブラリ、フォント、共有メモリポリシー、サンドボックス権限、または子プロセス処理が不足している可能性があります。セレクターや待機を変更する前に、これらの境界を確認してください。

Q: PlaywrightコンテナはChromiumサンドボックスを無効にすべきですか？

信頼されていないページを訪問するコンテナは、ブラウザのサンドボックスを保持し、適切な非rootユーザーとして実行する必要があります。セキュリティチームが承認した制御された信頼モデルの場合のみ、弱化されたサンドボックスを使用してください。

Q: リモートPlaywrightは依然としてプロキシを必要としますか？

ブラウザレイヤーは、承認されたエグレスポリシーを依然として必要とします。Scrapeless Scraping Browserは、195ヶ国以上で住宅用プロキシを接続できます。テストまたはデータ契約で必要な国を指定してください。

Q: ターゲットDOMが変更された場合はどうなりますか？

スモークジャーニーを再実行し、役割に基づいたロケーター、ページ状態、およびレンダリングされた出力を確認します。コンテナの健康状態は、セレクターの安定性を保証しません。

Q: 1つのホストに対して何人のPlaywrightワーカーが実行されるべきですか？

サイト所有者が別の制限を承認しない限り、ホストごとに3人以上のワーカーを保持しないでください。ブラウザの容量は、ターゲットホストの同時接続とは独立してスケールします。

Q: このデプロイメントはAIエージェントなしで実行できますか？

はい。すべての3つのパターンは、標準のPlaywrightコードを直接実行します。AIエージェントはオプションであり、パッケージ、コンテナ、ブラウザ、または認証の境界を変更しません。

Scrapelessでは、適用される法律、規制、およびWebサイトのプライバシーポリシーを厳密に遵守しながら、公開されているデータのみにアクセスします。このブログのコンテンツは、デモンストレーションのみを目的としており、違法または侵害の活動は含まれません。このブログまたはサードパーティのリンクからの情報の使用に対するすべての責任を保証せず、放棄します。スクレイピング活動に従事する前に、法律顧問に相談し、ターゲットウェブサイトの利用規約を確認するか、必要な許可を取得してください。