ブラウザ自動化にPuppeteerが選ばれる理由とPlaywright・Seleniumとの違い

「動的に生成されるページからデータを取りたい」「ヘッドレスブラウザで帳票PDFを出力したい」「CI上でUIテストを自動化したい」——こうした要件が出てきたとき、最初の壁になるのが「どのブラウザ自動化ツールを選ぶか」という判断です。候補として名前が挙がるのが Puppeteer、Playwright、Selenium の3つですが、それぞれの守備範囲や得意分野は意外と知られていません。

特に初めてブラウザ自動化を導入するエンジニアにとっては、「Puppeteer は Chrome 専用なのでは？」「メンテナンスは続いているのか？」「自分の要件に本当に合うのか？」といった疑問が次々と湧いてきます。選定を誤ると、後からツールを乗り換える手戻りが発生しかねません。

本記事では、Puppeteer が何をするライブラリなのか、内部でブラウザとどう通信しているのか、どんなユースケースに使えるのかを、公式ドキュメントの記述を基に整理します。そのうえで Playwright・Selenium との違いを比較し、「どんなプロジェクトに Puppeteer が向くのか／向かないのか」という採用判断の軸を提示します。

なお本記事はインストールや動作検証を行ったうえでの解説ではなく、Puppeteer の README・公式ドキュメント（pptr.dev）および公開されている二次情報を出典付きで整理したものです。コード例はすべて公式 README からの抜粋であり、改変は加えていません。

Puppeteerとは｜ブラウザ自動化ライブラリの基本

Puppeteer は、Chrome または Firefox を高レベル API で制御する JavaScript ライブラリです。公式ドキュメントでは「a JavaScript library which provides a high-level API to control Chrome or Firefox over the DevTools Protocol or WebDriver BiDi」と定義されています（出典: What is Puppeteer - pptr.dev）。開発元は Google で、Chrome の開発チームが中心となってメンテナンスを続けています。

「高レベル API」というのは、ブラウザに「このURLを開いて」「このボタンをクリックして」「PDFとして保存して」といった操作を、JavaScript/TypeScript のメソッド呼び出しで指示できるという意味です。ブラウザの内部プロトコルを直接叩く必要がなく、Node.js エンジニアが普段書いているコードの延長で自動化を記述できます。

プロジェクトの基本情報と健全性

ツールを長期的に採用するうえで気になるのが「このプロジェクトは活発に開発されているか」という点です。GitHub リポジトリ（puppeteer/puppeteer）のメタデータは以下のとおりです。

スター数は9万を超える著名な OSS であり、最終 push の日時からも開発が活発に継続していることが確認できます。ライセンスは商用利用にも対応しやすい Apache-2.0 です。リポジトリはアーカイブ（開発終了）されておらず、フォーク（他リポジトリの派生）でもない、本家として独立してメンテナンスされているプロジェクトです。長期的に依存しても安心材料が多いといえます。

headless と headful の違い

Puppeteer はデフォルトで headless（画面表示なし）モードで動作します。公式ドキュメントでは「runs in the headless (no visible UI) by default but can be configured to run in a visible ("headful") browser」と記載されています（出典: What is Puppeteer - pptr.dev）。

headless モードは画面描画を伴わないため、CI 環境やサーバー上での実行に適しています。一方、デバッグ時など実際の画面を見ながら確認したい場合は headful（UI 表示あり）モードに切り替えることもできます。この2つを設定で切り替えられる点が、テスト用途・本番運用の双方で扱いやすい理由のひとつです。

Puppeteerの仕組み｜CDPとWebDriver BiDiの2系統

Puppeteer を理解するうえで重要なのが、ブラウザとの通信方式が2系統あるという点です。先述のとおり、Puppeteer は DevTools Protocol（CDP）または WebDriver BiDi を経由してブラウザを制御します。

DevTools Protocol（CDP）は、Chrome の DevTools（開発者ツール）が内部で使っているプロトコルです。Puppeteer はこの CDP を通じて Chrome を細かく制御します。Puppeteer が Chrome に対して高速かつきめ細かい操作を行えるのは、この CDP 直結のアーキテクチャによるものです。

一方の WebDriver BiDi は、ブラウザ自動化のための新しい双方向プロトコル標準です。Puppeteer はこの WebDriver BiDi にも対応しており、これによって Chrome 以外のブラウザ（Firefox）も制御できるようになっています。詳細は公式の WebDriver BiDi ガイド で解説されています。

ここで初見エンジニアが誤解しやすいのが「Puppeteer = Chrome 専用」という認識です。日本語の解説記事の中にはこの古い理解のまま書かれたものも残っていますが、現在の Puppeteer の公式説明（リポジトリの説明文も「JavaScript API for Chrome and Firefox」）が示すとおり、Firefox も対象に含まれています。比較検討の段階で「Chrome しか動かせないなら採用できない」と早合点する必要はありません。

ただし後述するとおり、対応ブラウザの「広さ」という観点では Playwright や Selenium のほうが範囲は広く、Puppeteer は Chrome を中心としたツールである、という位置づけは押さえておくべきです。

Puppeteerの主なユースケース｜テスト・スクレイピング・PDF生成

Puppeteer が「自分の要件に使えるか」を判断するために、公式ドキュメントが挙げる主なユースケースを見ていきます。公式の What is Puppeteer では、以下のような用途が示されています。

• フォーム送信・キーボード入力などのブラウザ操作の自動化
• モダンな JavaScript やブラウザ機能を使った自動テスト環境の構築（UI テスト）
• パフォーマンスのタイムライントレースの取得
• Chrome 拡張機能のテスト
• ページのスクリーンショット・PDF の生成
• SPA（シングルページアプリケーション）をクロールしてサーバーサイドレンダリングを行う

これらは抽象的に見えますが、実際の開発現場では次のような場面に対応します。

テスト自動化・スクレイピング

E2E（エンドツーエンド）テストでは、ボタンクリック・フォーム入力・画面遷移といったユーザー操作をプログラムで再現し、アプリが期待どおり動くかを検証します。Puppeteer はこうしたユーザー操作のシミュレーションに使われます。

スクレイピングの文脈では、React や Vue.js などで構築された動的ページからのデータ取得に有効です。通常の HTTP リクエストではページの初期 HTML しか取得できず、JavaScript の実行後に生成されるコンテンツは取れません。Puppeteer は実際にブラウザでページを描画したうえでデータを抽出できるため、動的に生成される内容も取得できます（出典: プログラミングのススメ、bug-fix.org）。

公式 README には、ページを開いてキーボード操作・要素のクリック・テキスト抽出までを行う例が掲載されています。以下は README からの抜粋です（改変なし。出典: puppeteer/puppeteer README）。

import puppeteer from 'puppeteer';
// Or import puppeteer from 'puppeteer-core';

// Launch the browser and open a new blank page.
const browser = await puppeteer.launch();
const page = await browser.newPage();

// Navigate the page to a URL.
await page.goto('https://developer.chrome.com/');

// Set the screen size.
await page.setViewport({width: 1080, height: 1024});

// Open the search menu using the keyboard.
await page.keyboard.press('/');

// Type into search box using accessible input name.
await page.locator('::-p-aria(Search)').fill('automate beyond recorder');

// Wait and click on first result.
await page.locator('.devsite-result-item-link').click();

// Locate the full title with a unique string.
const textSelector = await page
  .locator('::-p-text(Customize and automate)')
  .waitHandle();
const fullTitle = await textSelector?.evaluate(el => el.textContent);

// Print the full title.
console.log('The title of this blog post is "%s".', fullTitle);

await browser.close();

この例の ::-p-aria(...) や ::-p-text(...) は、Puppeteer 独自のセレクタ構文（locator API）です。アクセシビリティ名や表示テキストを手がかりに要素を指定できる点が特徴で、API の詳細は公式の API リファレンス で確認できます。

PDF生成・スクリーンショット

帳票や請求書などを Web ページとして組み立て、それをそのまま PDF として出力する用途にも使われます。スクリーンショットを撮ってから画像変換するのではなく、ページから直接 PDF を生成できる点が利点として挙げられています（出典: Zenn - ganezasan）。CSS でレイアウトを組める分、HTML/CSS に慣れたエンジニアにとっては馴染みやすいアプローチです。

導入手順やインストール方法など、より具体的な使い方は公式の Get started ドキュメント にまとまっています。

MCP連携など最近のトピック

近年の動向として、Puppeteer をベースにした MCP（Model Context Protocol）サーバー chrome-devtools-mcp（ChromeDevTools/chrome-devtools-mcp）が提供されている点も README で言及されています。これは AI エージェントなどからブラウザ操作・デバッグを行うための仕組みです。加えて、実験的な WebMCP API もサポートされています。AI 連携を視野に入れたブラウザ自動化を検討している場合は、こうしたエコシステムの広がりも判断材料になります。

puppeteerとpuppeteer-coreの違いと導入時の注意点

採用を決めたあとの「最初のつまずき」を先回りして押さえておきます。Puppeteer には2つのインストール方法があり、それぞれ挙動が異なります（出典: puppeteer/puppeteer README）。

npm i puppeteer # Downloads compatible Chrome during installation.
npm i puppeteer-core # Alternatively, install as a library, without downloading Chrome.

• puppeteer: インストール時に互換性のある Chrome を自動でダウンロードします。すぐに使い始めたい場合はこちらです。
• puppeteer-core: Chrome をダウンロードせず、ライブラリとしてのみインストールします。ブラウザのバイナリは自分で管理する前提で、すでに環境にある Chrome を使いたい場合や、ダウンロードサイズを抑えたい場合に選びます。

ここで初見エンジニアがつまずきやすいのが「ブラウザがダウンロードされない」問題です。README には、モダンなパッケージマネージャ（npm・pnpm・Yarn・Bun・Deno）がデフォルトで依存パッケージの install スクリプトをブロックする、という注意が記載されています。このブロックが効くと Puppeteer がブラウザを自動ダウンロードできず、実行時にエラーになります。

その場合は、以下のコマンドで手動ダウンロードを行うか、パッケージマネージャ側で install スクリプトを許可する設定（npm なら package.json の allowScripts に puppeteer を追加する等）を行います（出典: puppeteer/puppeteer README）。

npx puppeteer browsers install

この挙動を知らないと「インストールしたのに動かない」という入り口で時間を取られがちです。導入前にこの注意点を把握しておくだけで、初期のハマりを回避できます。

Playwright・Seleniumとの違いとPuppeteerの選定軸

ここからが採用判断の核心です。ブラウザ自動化ツールの代表格である Playwright・Selenium と Puppeteer を比較し、どんな場面でどれを選ぶべきかを整理します。

比較表（対応ブラウザ・言語・ライセンス）

各リポジトリのメタデータと特徴を横並びにすると以下のようになります。スター数等の数値は各 GitHub リポジトリの取得値です。

Playwright は Chromium・Firefox に加えて WebKit（Safari 系）も単一 API で扱える点が大きな違いで、テストランナーや自動待機（auto-wait）機能を同梱し、Python・Java・.NET など多言語のバインディングを持ちます。Playwright は Puppeteer の元開発メンバーが関わった後発プロジェクトという経緯があります（出典: Zenn - datajournal1）。

Selenium は2004年から続く老舗で、WebDriver という業界標準に準拠し、IE を含むレガシーブラウザへの対応や、Grid による分散実行が強みです。多言語・多ブラウザ対応の幅広さで群を抜きます。

速度面の二次情報として、コールドスタート（起動からの初動）は Puppeteer / Playwright が 100〜300ミリ秒程度、Selenium が 1〜2秒程度とされています。クロスブラウザ対応の広さは Selenium > Playwright > Puppeteer の順とされています（出典: Octo Browser Blog、IPFoxy Blog）。

Puppeteerが向くプロジェクト／向かないプロジェクト

以上を踏まえると、選定の判断軸は次のように整理できます。

Puppeteer が向くケース

• Chrome（および Firefox）を中心に自動化できれば十分で、Safari/WebKit までの互換性は不要
• Node.js / TypeScript で完結させたく、起動の速さ・軽量さを重視する
• スクリーンショット・PDF 生成・動的ページのスクレイピングなど、Chrome の機能を直接活かしたい
• Google 製で活発にメンテされている、依存しやすい OSS を求めている

Puppeteer が向かないケース（他ツールが有力）

• Safari/WebKit を含む複数ブラウザでの互換性検証が必須 → Playwright が有力
• テストランナーや自動待機を最初から統合した E2E テスト基盤がほしい → Playwright が有力
• IE を含むレガシーブラウザ対応、Python/Java 等の多言語、Grid による大規模分散実行が必要 → Selenium が有力

ひと言でまとめると、「Chrome 中心で軽量・高速に自動化したいなら Puppeteer、複数ブラウザ互換が必須なら Playwright、レガシー含む幅広い環境なら Selenium」という棲み分けになります。

まとめ｜Puppeteerを採用すべきか

最後に、Puppeteer の採用判断のポイントを整理します。

• 何をするツールか: Chrome / Firefox を CDP・WebDriver BiDi 経由で制御する Google 製の JavaScript ライブラリ。headless 動作がデフォルトで、CI・サーバー運用に向く。
• 健全性: スター数95,095・Apache-2.0・直近も活発に push されており（アーカイブ・フォークではない本家）、長期採用の安心材料が揃っている。
• 得意分野: 動的ページのスクレイピング、UI テスト、スクリーンショット・PDF 生成。Chrome 中心で軽量・高速。
• 選定の軸: 複数ブラウザ互換が必須なら Playwright、レガシー含む幅広い環境なら Selenium。Chrome 中心で速さと軽さを取るなら Puppeteer。

「自分のプロジェクトは Chrome 中心でよく、Node.js で完結させたい」という条件に当てはまるなら、Puppeteer は有力な選択肢です。逆にブラウザ互換性の幅やテスト基盤の統合を重視するなら、Playwright・Selenium も含めて比較する価値があります。

次の一歩として、導入手順は公式の Get started ドキュメント、つまずきやすい点や挙動の疑問は公式の FAQ を確認すると、採用検討から実装着手までスムーズに進められます。