「Playwright vs Puppeteer」を扱う記事の多くは、どちらか一方がより優れたスクレイパーだという前提から入りがちです。でも、その見方自体がかなり大ざっぱです。私は両方のライブラリで、まったく同じページ群――静的なカタログ、JavaScript で描画されるカタログ、記事ページ、壊れた 500 エラー、簡単なクロールグラフ、そして公開されている練習サイト 2 つ――を使って検証しましたが、結果はほとんど見分けがつきませんでした。再現率も、レンダリングも、スクリーンショットも、取りこぼしも同じです。
つまり、これは勝者を決める話ではありません。ブラウザ自動化ツールがページをスクレイピングできるかどうかを見極める本質的なテストでは、どちらも抜け出せませんでした。この記事では、選定の決め手になる唯一の実質的な違い、どちらにも共通して足りないけれど結局あなたが自分で用意することになる部分、そして私が検証したバージョン差分について説明します（2026-07-09 時点）。
なぜこの比較はフェアなのか
比較記事には、各ツールを別々のページで試してから「勝者」を宣言する癖があります。ですが、それではツールよりページの違いが結果を左右してしまいます。私はその落とし穴を避けるため、Playwright と Puppeteer の両方を同じローカルの検証用サーバーと、同じ公開デモサイト Books to Scrape と Quotes to Scrape に対して実行しました。だから、数値は列ごとにきれいに揃っています。
「引き分け」を意味のあるものにできるのは、このやり方だけです。検証対象が違えば、引き分けはノイズでしかありません。バイト単位で同一の条件なら、同じ結果はツールそのものの性質を示すシグナルになります。
それぞれのツールは何者か
Puppeteer は、Chrome DevTools Protocol を介して Chrome を制御するための JavaScript API です。公式の位置づけもまさにその通りで、「Chrome（実験的に Firefox も）を制御する JavaScript API」と説明されています。成熟していて、Chrome 中心、Node ベースのライブラリです。
Playwright は少し違う形で説明されます。Chromium、Firefox、WebKit を 1 つの API で操作できる「Web テストおよび自動化のためのフレームワーク」であり、JavaScript、Python、Java、.NET の公式クライアントがあります。両者は系譜も近く、Playwright は Google の Puppeteer チームから生まれ、その後 Microsoft に移ったため、ライバルというよりは親戚のような関係に感じられます。
ただし、スクレイピング用途ではどちらも同じ動きをします。実ブラウザを起動し、ページを開き、スクリプトの実行を待ってから、描画後の DOM を読み取る。HTTP パーサーではなく、あえてこのどちらかを使う理由はそこにあります。ほしいのは JavaScript 実行後のページであって、実行前の空の外枠ではないからです。以下の内容はすべて、この共通の仕組みから導かれます。だからこそ、やっていることの多くが結局は互角に見えるのです。
結果を並べて見る
「どちらかが明らかに優れている」という話は、ここで静かに崩れます。検証条件は同じ、数値も同じ。すべて揃いました。
| テスト | Playwright | Puppeteer |
|---|---|---|
| 静的カタログ（12 商品） | 12/12、再現率 1.0 | 12/12、再現率 1.0 |
| 記事ページ（タイトル + 3 段落） | 3/3、定型部分を分離 | 3/3、定型部分を分離 |
| 動的 JS ページ（ネイティブ描画） | 8/8 + スクリーンショット | 8/8 + スクリーンショット |
| 動的 JSON API | 8/8、再現率 1.0 | 8/8、再現率 1.0 |
| HTTP 500 の処理 | 参照可能、例外なし | 参照可能、例外なし |
| クロールグラフ（手書き BFS） | 12 ページ、深さ {0,1,2} | 12 ページ、深さ {0,1,2} |
| Books to Scrape | 20 商品 | 20 商品 |
| Quotes JS（公開） | 10 件の引用 | 10 件の引用 |
どちらも特別な設定なしで JavaScript をネイティブにレンダリングし、フルページのスクリーンショットを取得できました。500 エラーに対しても、例外を投げずに参照可能なレスポンスオブジェクトを返しました。大量にスクレイピングする場面では、エラーを記録できて処理全体を止めずに済むので、この小さな違いは意外と重要です。
ここで一つ注意しておきます。これは 1 台のマシンで 1 回実行した観測結果であって、ベンチマークではありません。私が「片方がもう片方より何ミリ秒速い」と言っていないのは、ノート PC 1 台でのページ単位の計測は速度比較として成立しないからです。私が言えるのはもっと狭く、しかも根拠のある話です。8 種類のページで、抽出の再現率とレンダリングの挙動は一致していた、ということです。実ページでどちらかが大きく差をつけるのを期待していたなら、少なくともこの検証では起きませんでした。
選定を決める本当の違い
本当の分岐点は数値ではありません。スコープです。
Playwright は 1 つの API で Chromium、Firefox、WebKit の 3 エンジンを扱え、さらに JavaScript 以外に Python、Java、.NET の第一級クライアントを提供しています。これは公式に明記されている強みであり、ここで「明記されている」という言葉を正確に使いたいのですが、今回私は Chromium しか試していません。したがって、Playwright の 3 エンジン対応については、自分で独自検証した事実ではなく、あくまで公式に文書化された機能として述べています。Safari の WebKit で挙動が変わるサイトをスクレイピングしたい場合や、チームが Python を使っている場合、この幅の広さが Playwright を選ぶ理由になります。
Puppeteer は Chrome ファーストです。そして、よくある短い言い回しはここで不正確になります。もはや「Chrome 専用」ではありません。Puppeteer v23 以降は、WebDriver BiDi を通じて本番利用に耐える Firefox 対応が入り、Chrome では既存の自動化を壊さないよう CDP をデフォルトにしています。これは Chrome for Developers と Mozilla の両方が説明しています。私が試した 24.16.0 は v23 より十分新しいので、実際の違いは「Chrome 対 3 エンジン」ではありません。Puppeteer は Chrome（CDP）に加えて Firefox（BiDi）をカバーしますが、WebKit はありませんし、クロスエンジン対応の歴史は Playwright より新しい、というのが実態です。Playwright にはあって Puppeteer にはないエンジンが WebKit です。
要するに、判断材料はこれです。速度でも精度でもレンダリングの忠実度でもなく、そこは互角です。必要なのはスコープの判断です。WebKit が必要か、あるいは非 JavaScript 言語のクライアントが必要か。それとも Node から Chrome と Firefox を使えれば十分か。スクレイピング案件の多くでは、どちらも要求水準を満たします。つまり、能力差ではなくスタックとの相性で選ぶことになります。
どちらにもできないこと
この 2 つに共通して残される仕事があります。それはクロールのオーケストレーションです。どちらにも、リクエストキュー、データセットの書き出し、自動スロットリングはありません。私のクロールグラフのテスト――内部リンクをたどり、深さを追跡し、URL の再訪を避ける――では、どちらの場合も手書きの幅優先探索が必要でした。12 ページ、深さ {0,1,2}、どちらも自前の BFS です。
数ページ程度なら問題ありません。小さな BFS なら十数行で書けます。でも、数百から数千 URL を対象に、重複排除、リトライ、礼儀ある間隔制御まで含めて大規模にクロールするなら、その仕組みは自分で作るか、これらのエンジンを包んだ別のツールを使うことになります。Crawlee はまさにその役割を担い、Playwright と Puppeteer の両方の上に実際のクロール層を提供します。
これは欠陥ではありません。ここは正しく言い分ける必要があります。Playwright と Puppeteer はブラウザ自動化フレームワークであって、クロールフレームワークではありません。キューがないのはバグではなく、担当範囲の境界です。正しい理解は、これらのツールがスクレイパーの「ページを見る」側である、というものです。「サイトを巡る」側は別途持ち込む必要があります。自分で書くか、そういう機能を備えたラッパーを載せるか、のどちらかです。
セットアップとバージョン上の注意
インストール手順はかなり似ています。npm install でライブラリ本体とブラウザバイナリが入りますが、重いのはそのバイナリです。Puppeteer は Chrome のダウンロードを自動でバンドルし、今回のクリーンインストールでは脆弱性の報告もゼロでした。Playwright はブラウザビルド用に別途 npx playwright install を実行します。どちらも面倒ではありませんが、どちらにしてもダウンロード分のコストは見込んでおくべきです。レンダリングが必要な以上、HTTP だけのツールに比べてブラウザの容量とページ単位の処理コストは避けられない税金です。
ここで、私が開示すべき点をはっきり書きます。Playwright は 1.56.0 と 1.61.1 の最新リリースを比較し、Puppeteer は 24.16.0 と npm 上の最新 25.3.0 を比較しました。つまり、2026-07-09 時点では Puppeteer がメジャーバージョンで 1 つ遅れていました。私が使った API はその差分でも安定しているので、結果自体は有効です。ただし、これを読んでいるのが公開からしばらく後なら、正確な数値で判断する前に、必ず現行バージョンでもう一度試してください。そしてもう一度だけ強調します。Playwright では Chromium しか試していないため、Firefox や WebKit との同等性については、「公式に文書化されている」以上の主張はしていません。
Playwright と Puppeteer の長所と短所
引き分けだったので、長所・短所は「勝った負けた」よりも「何を選ぶか」の一覧になります。
Playwright
- 長所: 1 つの API で Chromium / Firefox / WebKit を扱えると公式に明記されている、Python / Java / .NET の公式クライアントがある、JavaScript レンダリングで再現率がフル、対応範囲が継続的に広がっている
- 短所: 組み込みのクロールキューがない、ブラウザの重量とページ単位コストがある、今回のテストでは Chromium しか使っていない、実行時のバージョンが最新より少し古かった
Puppeteer
- 長所: CDP ベースの Chrome 自動化として成熟していて安定している、JavaScript レンダリングで再現率がフル、500 エラー時に例外を投げずレスポンスオブジェクトを返せる、長く使われてきた強いエコシステムがある、v23 以降は WebDriver BiDi による Firefox 対応が文書化されている
- 短所: Chrome ファーストで Node ベース、WebKit エンジンがない、組み込みのクロールキューがない、ブラウザが重い、実行した版が npm の最新よりメジャー 1 つ古かった
どういう人がどちらを選ぶべきか
Node 環境で完結していて、対象サイトが Chrome で問題なく動き、成熟していて焦点の絞られたライブラリを使いたいなら Puppeteer を選びましょう。複雑さの軸を 1 つ減らせる、という意味でも扱いやすいです。Firefox を BiDi 経由で使う道も、必要になれば用意されています。
WebKit の対応が必要、Python か .NET でスクレイパーを書きたい、あるいはエンジン対応と言語対応の幅が広いプロジェクトを選びたいなら Playwright です。特に Python チームが Playwright を選ぶ理由としては、この言語適合性だけでも十分に明確です。
そして、比較記事があまり触れない第 3 の答えもあります。ページのデータ取得に JavaScript が必要ないなら、どちらも選ばなくていい、ということです。HTTP リクエストとパーサーで内容が取れるなら、ヘッドレスブラウザは高コストすぎる選択です。その場合は別カテゴリの HTTP ファーストなツールを使い、ブラウザの重さは最初から避けるべきです。
マネージド API が合う場面、Thunderbit を含めて
Playwright と Puppeteer はどちらも無料の open source ライブラリで、自分で動かして保守する形になります。ブラウザ環境も、更新対応も、上に載せるクロールコードも、ボット対策とのいたちごっこも、すべて自分の責任です。多くのプロジェクトではそれが正解であり、ここはそれを否定する話ではありません。
ただ、実際の web scraping 作業の多くが、これらのツールの外側にあることも見てください。ページをきれいにレンダリングすることはできますが、URL キューは持たず、ブロック回避のローテーションもしないし、構造化 JSON をそのまま返してくれるわけでもなく、ブラウザ群の運用も必要です。これは、管理された抽出サービスとは明らかに別のレイヤーです。自社で作るか買うかを検討する開発者にとって、そこをはっきり分けて考える価値があります。私たちの Thunderbit の開発者向けスタックは、その別レイヤーにあります。POST /distill はページをクリーンな LLM 向け Markdown に変換し、POST /extract はあなたが定義したスキーマに基づいて構造化 JSON を返します。JavaScript レンダリング、ボット対策、CAPTCHA はローカル PC ではなくサーバー側で処理されます。AI エージェントやコーディングアシスタント向けには Thunderbit MCP server があり、thunderbit_suggest_fields は何も課金する前に無料で実行できます。CI や cron には npx @thunderbit/thunderbit-cli から使える CLI もあります。
これが絶対に優れている、とは言いません。形の違うトレードオフです。Playwright や Puppeteer では、レンダリングも周辺機能もすべて自分で持ち、1 リクエストごとのコストはゼロです。管理 API では、レンダリング、ボット対策、クロールの配線を外部化でき、その代わりリクエスト単位で支払います（Thunderbit では、行単位ではなく、distill は 1 クレジット、extract は 20 クレジットの従量課金です）。小規模で、自前運用が好きで、ブラウザも自分で握りたいなら、この 2 つは正しい道具です。拡張したいが、ヘッドレス群とクロール機構とブロック回避層を全部自分で運用したくないなら、管理型の選択肢がその仕事を丸ごと消してくれます。
より広い視点では、私たちのチームは Crawlee の 2 エンジン構成 や HTTP ファーストの各種フレームワークも、同じ検証条件で試しています。フルブラウザは本当に必要なのか、それともページ要件を超えているのかを考えたとき、次に見るべき比較です。
結論
Playwright と Puppeteer、どちらを使うべきか。JavaScript ページのレンダリング用途なら、どちらでも構いません。ここで重要なテストはすべて引き分けだったので、他の理由で選んでも能力を失うわけではありません。Node から Chrome と Firefox を使えれば十分で、成熟度と用途の絞り込みを重視するなら Puppeteer。WebKit まで必要、または非 JavaScript クライアントが必要なら Playwright を選んでください。
比較記事でよく抜け落ちる 2 点だけは、ぜひ持ち帰ってください。1 つ目は、実際のスクレイピングではこの 2 つは本当に引き分けであり、8 種類のテストで出てこなかった性能差を気に病む必要はないということ。2 つ目は、どちらもクロールツールではないということです。ページをレンダリングするのが役割で、クロールはあなた自身か、Crawlee のようなラッパーが担う部分です。この 2 点を整理し、スコープをスタックに合わせれば、選択はかなり小さくなります。エンジン選びの重要度は、どちらのツールも代わりにやってくれない作業の半分よりずっと低いのです。
さらに詳しく
Web データ抽出に Thunderbit を試す Get Started Free
よくある質問
Web スクレイピングでは Playwright と Puppeteer のどちらが速いですか？ 同一条件の検証では、実質的に引き分けでした。静的ページ（12/12）、動的ページ（8/8）、JSON API 抽出で再現率は同じ、ネイティブレンダリングも同じ、500 エラーの処理も同じです。これは 1 台のマシンで 1 回ずつ行った観測であり、ベンチマークではないため、ページ単位の時間差は本当の速度比較にはなりません。速度差が出なかった以上、スコープと言語で選ぶべきです。
Playwright と Puppeteer の実際の違いは何ですか？ エンジン対応と対応言語の範囲です。Playwright は 1 つの API で Chromium、Firefox、WebKit を操作でき、Python、Java、.NET のクライアントがあります。Puppeteer は Chrome ファーストの CDP ベースで、v23 以降は WebDriver BiDi による Firefox 対応が文書化されていますが、WebKit はありません。また Node ベースです。どちらも JavaScript のネイティブレンダリングはできますが、クロールのオーケストレーションは標準では含まれていません。
Playwright や Puppeteer でサイト全体をクロールできますか？ そのままではできません。どちらにも、リクエストキュー、データセット書き出し、自動スロットリングはありません。私のクロールグラフのテストでは、両方とも手書きの BFS が必要でした。12 ページ、深さ {0,1,2} です。大規模にやるなら、Crawlee のようなクロール層を追加してください。これは両エンジンの上で本格的なクロール機構を提供します。
スクレイピングにブラウザツールは必須ですか？ ページのデータ取得に JavaScript が必要な場合だけです。HTTP リクエストとパーサーで欲しい内容が取れるなら、ヘッドレスブラウザは高コストすぎます。その場合は HTTP ファーストのツールを使い、ブラウザの重さは最初から避けましょう。
Python チームはどちらを選ぶべきですか？ Playwright です。第一級の Python クライアントがあるからです。Puppeteer は Node ベースなので、Python から使うには橋渡しの仕組みを作って保守する必要があります。言語の適合性は、Playwright を Puppeteer より選ぶ最もわかりやすい理由の 1 つです。
