多くの人が Crawlee に出会うきっかけは、実は別の問いからです。「どのヘッドレスブラウザを使うべきか？」──でも、そもそもその問いの立て方が違います。そして、そのズレをはっきり示しているのが Crawlee です。Crawlee 自体はブラウザではありません。必要なときだけブラウザを包み込み、いらないときは使わない、Node/TypeScript 向けのフレームワークです。
私は Node v22.22.3 と macOS 上で、管理されたフィクスチャといくつかの公開デモサイトを使い、Crawlee 3.17.0 を数日かけて検証しました。今回いちばん確かめたかったのは、「1つのライブラリ、1つのAPI、内部はHTTPクローラでも本物のブラウザでもよい」という売り文句です。というのも、この主張こそが、Crawlee を自分のスタックに入れる価値があるのか、それとも Playwright をそのまま使えばいいのかを分けるポイントだからです。先に結論を言うと、この“2エンジン”という考え方はかなり筋が通っていました。もちろん、いくつか補足はありますが、それはあとで触れます。
Crawlee は実際には何で、何ではないのか
Crawlee は、自分自身を Node.js 向けの Web Scraping とブラウザ自動化ライブラリだと説明しており、信頼性の高いクローラーを作るための設計になっています。 公式の説明 もかなり広く、AI、LLM、RAG、GPT 向けのデータ抽出、HTML・PDF・JPG・PNG などのファイル取得、Puppeteer / Playwright / Cheerio / JSDOM / 生のHTTP への対応、ヘッドあり・ヘッドレス両対応、プロキシローテーション込み、となっています。かなり守備範囲が広いので、まずは「Crawlee が何ではないのか」をはっきりさせたほうが理解しやすいです。
Crawlee はレンダリングエンジンではありません。独自のブラウザも持っていません。JavaScript の実行が必要なときは、Crawlee が Playwright または Puppeteer を動かし、その先で Chromium などのブラウザが動きます。また、ネットワーク越しに呼ぶホスト型サービスでもありません。自分でインストールして、自分の環境で動かす依存パッケージです。では何かというと、Crawlee は取得処理の上に乗るレイヤー、つまりクローラーのクラス群、リクエストキュー、ストレージ、リンク追跡ロジックです。要するに、下に差し替え可能なエンジンを持つ「クロール用フレームワーク」と考えるのが近いです。
参考までに、今回テストしたバージョンは 3.17.0（2026-06-04 リリース）で、TypeScript 製、ライセンスは Apache-2.0。2026-07-09 時点で apify/crawlee のスター数は約 24.6k でした。スター数は変動しますし、私が見ていた2日間でも 53 増えていたので、この数字は固定値ではなくスナップショットとして見てください。
2つのエンジン：CheerioCrawler と PlaywrightCrawler
ここが設計の価値がいちばんはっきり出るところで、私が最も時間をかけた部分でもあります。
CheerioCrawler はHTTP経由でHTMLを取得するルートです。取ってきた生HTMLを Cheerio で解析します。ブラウザは使わず、JavaScript も実行せず、レンダリングもしません。高速で軽量です。PlaywrightCrawler はブラウザ側のルートです。実際の Chromium を起動し、JavaScript が生成した DOM まで含めてページを描画し、スクリーンショットも取れます。
この2つは、できることが本質的に違う別エンジンです。Crawlee が言いたいのは、違うエンジンでも“見た目”は同じだということです。どちらも requestHandler を持ち、どちらも run() を実行し、どちらも enqueueLinks でリンクをたどれます。あるエンジンから別のエンジンへの切り替えは、書き換えではなくクラスの差し替えです。私は抽出ロジックを一字一句同じに保ち、外側を包むクローラのクラスだけ変えることで、それを確認しました。
ただし、完全に同じではない境界もあります。内容の扱い方が違うからです。CheerioCrawler のハンドラ内では $ が渡され、これはあらかじめ解析済みの静的DOMを jQuery 風に扱えます。一方、ブラウザ系のハンドラでは page オブジェクトが渡され、ライブなページに対して操作します。つまり、キュー、ルーティング、「このデータを送って、あのリンクをたどる」という仕組みは共通ですが、実際にページ内容を読む部分だけ形が変わります。Crawlee のドキュメントも同じ趣旨で、共通インターフェースはクロール操作に限定され、コンテンツアクセスの部分はエンジンごとに違うと説明しています。
| エンジン | 取得方法 | JavaScript 実行 | 私の実測（動的ページ1件） | 向いている用途 |
|---|---|---|---|---|
CheerioCrawler | 生HTTP + Cheerio 解析 | いいえ | 約0.035秒 | 静的HTML、JSON API、高速処理 |
PlaywrightCrawler | Playwright 経由の実ブラウザ | はい | 約4.967秒 | JS描画ページ、スクリーンショット |
この計測値は単一マシンでの単回実行なので、ベンチマークではなく、あくまでコスト差の形を見るためのものです。同じURLでも、ブラウザ経由はおよそ2桁近く時間がかかりました。これがレンダリングのコストであり、だからこそ最初からブラウザを選ぶべきではないのです。
検証：同じURLで 0 件から 8/8 件へ
主張はシンプルに言えます。2エンジンの話を信用できる理由は、私はそれを一度失敗させて、クラスを1つ差し替えるだけで直せたからです。
まず、ローカルに動的フィクスチャを作りました。商品カードがロード後に JavaScript で注入される、今どきのWebでは珍しくないタイプのカタログページです。そこに CheerioCrawler を向けると、商品カードは 0 件でした。これはバグではなく当然です。Cheerio は JavaScript を実行しないので、解析対象のHTMLにカードが存在しないからです。そこで、まったく同じURLに PlaywrightCrawler を向け、他は何も変えずに実行すると、8/8 件の商品をレンダリングし、証拠としてスクリーンショットまで取得できました。
自作フィクスチャだけの偶然ではないことを確かめるため、公開サイトでも同じパターンを試しました。JavaScript で引用文をクライアント側で生成する Quotes to Scrape のデモページです。結果は同じ方向でした。CheerioCrawler は 0 件、PlaywrightCrawler は 10 件を取得しました。
ここで何が証明されたのかは、少し丁寧に言いたいです。これは Crawlee がすでに ドキュメント で説明している主張の、きれいな再現です。つまり、バージョン 3.0 以降、各クローラーは同じベースクラスと共通インターフェースを共有しています。これは新発見ではなく検証です。でも、それがまさに価値です。「1つのインターフェースで、HTTPでもブラウザでも」という宣伝文句が本当に成立していることを、自分で管理するフィクスチャでも、外部サイトでも、0件から完全取得まで確認できたのです。
HTTP ルートが勝つ場面
ここまで読むと、「じゃあ常にブラウザを使えばいいのでは？」と思うかもしれません。そうではありません。2エンジン設計の本質は、ブラウザが“標準”ではなく“高コストな代替手段”だという点にあります。
静的コンテンツでは、CheerioCrawler は正確で速かったです。静的カタログのフィクスチャでは、enqueueLinks({ selector: '.next-page' }) でページ送りしながら、12/12 件の商品を完全に取得し、約0.155秒でした。記事ページでは、タイトルと本文の 3/3 段落を取得しつつ、ログイン・購読・著作権表記の定型文はきれいに本文から切り分けられました。
特に覚えておきたいのは、JavaScript でデータが読み込まれるページの裏には、だいたい JSON API があるということです。私の動的フィクスチャのデータもエンドポイントにあり、そこへ CheerioCrawler を直接向けたところ、8/8 件の商品を取得できました。ブラウザを使わず、約0.035秒です。ブラウザ経由では表示にほぼ5秒かかった同じデータです。古典的ですが、今でも有効な教訓です。裏側のリクエストを再現できるなら、Chromium を起動するよりそちらを使うべきです。Crawlee なら、その判断をフレームワークを変えずにクローラー単位で切り替えられます。
クロール用フレームワークとしての価値（単なるブラウザライブラリよりCrawleeを選ぶ理由）
もし必要なのが1ページの描画だけなら、Crawlee は不要です。Playwright や Puppeteer を単体で使えばいいからです。素のブラウザライブラリにないのは、クロール機能です。キュー、重複排除、深さ制御、再試行。そこが Crawlee の本体で、エンジンとは別の価値です。
私はフィクスチャのルートから、深さを追跡しながら enqueueLinks で同一ホストのクロールを実行しました。Crawlee は深さ {0:1, 1:3, 2:7} で 11ページ を巡回しました。つまり、ルートが1ページ、その1階層先が3ページ、2階層先が7ページです。さらに maxRequestsPerCrawl も停止条件として機能しました。RequestQueue が管理を担い、HTTP 500 を返すページにリクエストを送ると、Crawlee は再試行したうえで、失敗をなかったことにしたり実行を落としたりせず、failedRequestHandler 経由で失敗を表に出しました。
これは、Crawlee を単体のブラウザツールより選ぶいちばん強い理由です。クロールのオーケストレーションが最初から組み込まれていて、しかも内部エンジンがHTTPでもブラウザでも、そのオーケストレーションは同じです。キューを作ってリンクを追うロジックは一度書けばよく、各クローラーが JavaScript を描画するかどうかは個別に決められます。
セットアップと、見落としやすいブラウザのダウンロード
インストール自体はおおむね問題ありませんでしたが、初回ユーザーがつまずきやすいポイントが1つあります。
npm install crawlee playwright は問題なく通り、脆弱性も 0 件でした。ただし PlaywrightCrawler を動かすには、別途 npx playwright install chromium を実行して Chromium バイナリを入れる必要があります。サイズは約 81.7 MiB です。crawlee を入れただけではブラウザは取得されません。この手順を飛ばしてブラウザ系クローラーをいきなり使うと、起動エラーになります。Playwright のパッケージ設計を知らないと、少し分かりにくい落とし穴です。これは Crawlee の欠陥ではなく Playwright の仕様ですが、初回セットアップでの摩擦としてはきちんと知っておくべきです。
運用面でもう1点。Crawlee はデフォルトでローカルの storage/ ディレクトリに書き込みます。今回のテストハーネスでは、整理のために一時ディレクトリへ向けて永続化を無効化しましたが、普通に実行するとプロジェクト内に storage/ フォルダができます。問題ではありませんが、git status に出る前に知っておくと安心です。
3つ目のエンジンについて少しだけ
Crawlee の“同等性”の話は、Cheerio と Playwright だけではありません。PuppeteerCrawler もあります。そこで「同じインターフェース」という主張がどこまで通じるのか、ライブクロールではなくクラス/API の面から確認しました。
3つのクローラーはすべて同じ BasicCrawler を起点にしています。CheerioCrawler は HttpCrawler 経由、PlaywrightCrawler と PuppeteerCrawler は共通の BrowserCrawler 経由です。インストール済みパッケージを introspect すると、run、addRequests、pushData、getData、getDataset、exportData、getRequestQueue、useState、stop など、キューとストレージに関する設計の中核を含めて、24個の公開メソッドが3エンジンで共通でした。実は PuppeteerCrawler と PlaywrightCrawler の公開メソッドセットは完全に一致しています。エンジン間の差はHTTPとブラウザの境界にだけあり、まさにそこに差があるのは自然です。
ただし、はっきり言っておくべき境界もあります。PuppeteerCrawler のライブクロールは実行していません。私のテスト環境では puppeteer の peer dependency を入れておらず、検証するには別のブラウザダウンロードも必要だったからです。なので、ここで確認できた Puppeteer の同等性は、構造上の同等性です。つまり、同じベースクラス、同じ共有メソッド、同じハンドラの形は確認できましたが、実行結果としての検証ではありません。しかも、インターフェースが同じでも内部挙動が完全に同じとは限りません。Crawlee の 公式ガイダンス でも、Playwright は要素の待機を自動で行う一方、Puppeteer は明示的に待機させる必要があると説明されています。これは Crawlee の問題ではなくエンジン側の特性ですが、「同じAPI」＝「どのハンドラでも同じコード」という意味ではない、ということです。
今回あえて試していないこと
今回の結果を過大評価しないよう、あえて手を付けなかった項目を挙げておきます。
- スケール。すべて小さなフィクスチャと短い公開クロールで実行しました。100〜1,000ページ規模の長時間ランはしていないので、実負荷でのオートスケーリングや安定性は評価できていません。
- キューの永続化と再開。クロール途中で止めて、
RequestQueueがクラッシュ後にきれいに再開できるかは試していません。長期ジョブでは大事な機能ですが、今回は未検証です。 - Dataset と KeyValueStore のエクスポート。JSON/CSV の書き出しはハーネス側で手作業にしました。Crawlee の
Dataset/KeyValueStoreによる標準エクスポートの使い勝手は試していません。これはフレームワークを使ううまみの一部ですが、未確認です。 - プロキシとセッションプール。Crawlee にはプロキシローテーションやフィンガープリント関連の機能があります。私はそれを「アンチボット回避」の売りではなく、あくまでコンプライアンスと運用の話として見ていますが、今回いずれの方向でもストレステストはしていません。
また、ここまでの計測値はすべて単一マシンでの単回実行です。HTTP とブラウザのコスト差の“形”は示していますが、ベンチマークではありません。その前提で読んでください。
長所と短所
長所
- HTTP とブラウザの両方を1つのAPIで扱える。エンジン切り替えは本当にクラス差し替えだけで、ローカルフィクスチャでも公開サイトでも 0 件から完全取得まで確認できた。
- 本物のクロールフレームワーク。
RequestQueue、深さ制御付きenqueueLinks、再試行、failedRequestHandlerが揃っており、単なるページレンダラーではない。 - JavaScript の邪魔がない静的ページでは、HTTP抽出が正確で高速だった（静的 12/12、記事 3/3、JSON API 経由で 8/8）。
- ブラウザルートは、HTTP では物理的に見えない内容を回収でき、スクリーンショットも取得できる。
- Apache-2.0、TypeScript、現在もアクティブにメンテナンスされている。
短所
- ブラウザ系クローラーは、
npm install crawleeだけでは入らない別途のnpx playwright install chromium（約81.7 MiB）が必要で、見落としやすい。 - ブラウザレンダリングには、1ページあたりの実コストがかかる（今回の1ページ検証では約5秒、HTTPはサブ秒）。
- 素の実行では
storage/ディレクトリができる。 - スケール、キューの永続化/再開、Dataset エクスポートの使い勝手は、今回のテストでは未確認。
- プロキシやフィンガープリント機能は、サイトの利用規約と法令の範囲内で使う必要がある。頼るべき機能ではなく、責任を伴う機能です。
Crawlee を選ぶべきか、それともマネージドAPIか
Crawlee は自分で組み立てるタイプのツールです。そして、それが多くのチームには正解です。自分の Node コードベースの中でクローラーを所有したい、1つのプロジェクト内でHTTPクロールとブラウザクロールをフレームワークを変えずに混在させたい、キューとストレージを自分で制御したい、という場合に向いています。ブラウザ群を運用し、将来的にはスケールさせることにも抵抗がないなら、Crawlee はその土台としてとてもきれいで、よく設計されています。
もう1つの選択肢は、それらを一切運用しないことです。Chromium インスタンスの管理、プロキシローテーション、アンチボット対策にエンジニアリング時間を割きたくないなら、マネージドAPIが代替になります。そして、それが Thunderbit の開発者向けスタックの立ち位置です。技術者向けに言うと、Thunderbit は Chrome 拡張ではなく、AI スクレイピング用の API、MCP サーバー、CLI です。POST /distill を呼べばページをきれいな LLM 向け Markdown に変換でき、POST /extract に JSON Schema を渡せば構造化データを返せます。renderMode は none、basic、full から選べるので、フルブラウザ描画が必要な場面だけ判断して使えます。MCP サーバー を使えば、Claude や Cursor などの MCP クライアントを含む AI エージェントが、作業の途中でスクレイピングできます。CLI はターミナルや CI から実行可能です。
npx -y @thunderbit/thunderbit-cli distill "<url>" -f markdown > out.md
開発者にとって大事な違いはここです。Crawlee は、レンダリング済みHTMLや解析済みノードといった“素材”を渡してくれて、パイプラインは自分で持ちます。一方、マネージドAPIは、JavaScriptレンダリング、CAPTCHA、アンチボット処理までサーバー側で済ませたうえで、スキーマに合った構造化JSONを返します。役割が違うのです。最大限の制御が欲しく、運用負荷を受け入れられるなら Crawlee。ブラウザ群を自前で回さずにデータだけ欲しいならマネージドAPIです。実際には、独自のクロールには Crawlee を、単純に「構造化データだけ欲しい」ケースには別の手段を使う、というように両方を併用するチームも多いです。コスト面の比較は Thunderbit の料金ページ で確認できます。
結論
Crawlee は使うべきでしょうか？ はい。特に、HTTP とブラウザクロールを1つのフレームワークで扱いたい Node/TypeScript 開発者なら、かなり有力です。2エンジンであることが採用理由であり、今回のフィクスチャではその強みがきれいに確認できました。同じURLがクラス1つの差し替えで 0 件から完全取得に変わり、静的抽出は速くて正確で、キューと深さを使ったクロールもドキュメント通りに動きました。
ただし、2つだけ最初に覚えておくとよいです。PlaywrightCrawler を初めて使うときは、見えにくいブラウザのダウンロードを予算に入れておくこと。そして、今回試していない部分──スケール、クラッシュ後の再開、組み込みエクスポート──が、自分のワークロードでも同じように優秀だと決めつけないことです。自前クローラーを組むための土台として、Crawlee は非常に強く、設計も優れています。ですが、完成された“放っておけるデータパイプライン”として見るなら、Crawlee は出発点であって到着点ではありません。
Thunderbit で Web データ抽出を試す Get Started Free
FAQ
Crawlee は無料ですか？ ライセンスは何ですか？
はい。Crawlee は Apache-2.0 ライセンスのオープンソースで、npm からインストールできます（npm install crawlee）。今回テストしたバージョンは 3.17.0 でした。ブラウザ系クローラーを使うには、Playwright 経由で別途 Chromium をダウンロードする必要があります。これも無料ですが、セットアップに約 81.7 MiB 追加されます。
CheerioCrawler と PlaywrightCrawler はどちらを使うべきですか？
データが生HTMLや裏側の JSON API にあるなら CheerioCrawler を使ってください。ずっと速く、ブラウザも起動しません。コンテンツが JavaScript で描画されるなら PlaywrightCrawler を使います。HTTP ルートで空結果になるときがその見分けどころです。私のテストでは、JS描画ページで HTTP エンジンは 0 件、ブラウザエンジンは全件を返しました。API が共通なので、切り替えは書き換えではなくクラス変更で済みます。
Crawlee を動かすのにブラウザは必要ですか？
ブラウザ系クローラーを使う場合だけ必要です。CheerioCrawler にはブラウザは不要です。PlaywrightCrawler（および PuppeteerCrawler）にはブラウザバイナリが必要で、npx playwright install chromium で入れます。なお、npm install crawlee だけではブラウザは取得されません。ここが初回のつまずきポイントとしていちばん多いです。
Crawlee はページ送りや複数ページのクロールに対応していますか？
はい。むしろ、それが単体のブラウザライブラリより Crawlee を選ぶ大きな理由の1つです。enqueueLinks はリンク追跡を行い、.next-page のようなページ送りセレクタにも対応します。RequestQueue は重複排除とクロール管理を担い、深さ制御と maxRequestsPerCrawl による制限も使えます。テストでは、同一ホスト内を深さ 0〜2 で 11ページ巡回し、失敗リクエストは failedRequestHandler に流れました。
Crawlee はホスト型スクレイピングAPIとどう違いますか？
Crawlee はセルフホスト型です。クローラーを自分で書き、自分で動かし、スケール、プロキシ、アンチボット対応も自分で持ちます。Thunderbit の distill / extract のようなマネージドAPIは、レンダリングやアンチボット処理をサーバー側で済ませたうえで、きれいな Markdown またはスキーマ一致の構造化JSONを返し、API、MCPサーバー、CLI から利用できます。自分のパイプラインを最大限コントロールしたいなら Crawlee。ブラウザ基盤の運用やスケールを自分で抱えたくないなら、マネージドAPIを選ぶのがよいでしょう。
