一部のサードパーティ製スクレイパー比較では、Crawl4AI に「Adaptive Intelligence」——サイトを学習し、HTMLの構造が変わっても自動で追従するセレクター——があると説明されています。しかし、今回検証した API の範囲では、そのような挙動は確認できませんでした。Crawl4AI が実際に提供しているのは、ブラウザベースの Markdown 生成と CSS/XPath による抽出です。Scrapling には別個の適応型セレクター機能がありますが、こちらも自社レビューで示されている制約の範囲内に限られます。
私は Crawl4AI 0.9.0 を、既知の正解データがある5種類のページに対して実行しました。対象は、静的カタログ、JavaScript で描画されるカタログ、ボイラープレート付きの記事、意図的に返す 500 エラー、そしてリンクでつながった複数ページのグラフです。検証した Markdown 生成とスキーマ抽出の経路では、期待どおりの fixture コンテンツが返ってきました。生の Markdown にはボイラープレートが残り、深いクロールにはページごとの待機設定が必要で、通常の 500 エラーはアンチボット風のエラーメッセージとして表示されました。
Crawl4AI の正体
まず、インストール時に多くの人が見落としがちな点から始めます。Crawl4AI は軽量な Python パーサーではありません。最初の crawl4ai-setup は、Playwright と Patchright という2つのブラウザスタックを静かに丸ごとダウンロードします。これを理解すると、このツールの性格が一気に見えてきます。つまり、これは Markdown 変換機能を載せた制御可能なヘッドレスブラウザであり、見た目だけスクレイパーなのです。
公式には、RAG パイプライン、エージェント、データワークフロー向けに Web ページを Markdown に変換するための、Apache-2.0 ライセンスのオープンソースライブラリです。私が検証したのは v0.9.0 です。中核となるプリミティブには AsyncWebCrawler、BrowserConfig、CrawlerRunConfig、Markdown 生成、そして CSS/XPath または LLM ベースの抽出戦略が含まれます。詳細は 公式クイックスタート を参照してください。
ここで重要なのは、どう捉えるかです。多くのパーサーライブラリは HTTP リクエストを送り、返ってきたバイト列を解析しますが、Crawl4AI は実ブラウザを動かします。ブラウザレンダリングが標準搭載されているため、純粋な HTTP パーサーよりインストールは重くなりますが、非同期で描画される要素を確実に取得するには明示的な待機が必要になる場合があります。今回の検証では、再設計後にセレクターを自動書き換えするような動作は一切確認できませんでした。自己修復型だという主張は、具体的な公式ソースと再現可能な API が示されない限り、サードパーティ比較の誤記として扱うべきです。
主な機能と、その裏側の仕組み
シングルページの処理は、このツールの中心です。AsyncWebCrawler に URL を渡すと、ブラウザでページを読み込み、Markdown を返します。公式の example.com クイックスタートでは、この往復処理は 1.81秒 で完了し、きれいな 200 を返しました。派手さはありませんが、最小構成でほぼ設定不要という点は確認できます。スキーマも待機設定もブラウザ設定も不要です。
動画チュートリアル（1:02:38）：Crawl4AI Official Tutorial, Full 1hr with Quickstart Examples。
構造化抽出は第2の柱で、Crawl4AI に最も近い「ページを理解する」機能です。ただし実際には推論ではなく、こちらが書いたスキーマに従うだけです。Markdown を吐き出すだけでなく、JsonCssExtractionStrategy を使って CSS スキーマを渡すと、指定したフィールドだけを含む JSON オブジェクトが返ってきます。ローカルの静的カタログでは、6件の JSON レコード が正しく返り、商品名、カテゴリ、価格、評価、詳細 URL がすべて期待どおり一致しました。これは「ページをテキストとして見る」のではなく「行データとして取り出す」違いです。そして Crawl4AI は同じクロールからその両方を実現できます。ただし、セレクターは自分で定義する必要があります。ツールがスキーマを推測してくれるわけではありません。
ブラウザベースの強みがもっとも効くのが、動的レンダリングです。wait_for="css:.product-card" を指定して JavaScript レンダリングのカタログを対象にすると、クライアント側の描画が完了するまで待ってから抽出してくれます。ローカルの JS fixture では、Markdown 出力とスキーマ出力の両方で 8/8 件の商品を取得 でき、所要時間は約 1.56 秒でした。公開されている Quotes to Scrape JS page では、描画後の引用を取得し、実用的なスクリーンショットも保存できました。これは単純な HTTP リクエストでは見えない内容です。初期 HTML には解析できるデータがないからです。
さらに、スケールとクロールにも対応しています。arun_many() はローカルの詳細ページ6件を並列処理し、6/6 の再現率を 3.76 秒で達成しました。Crawl4AI には BFS、DFS、BestFirst といったディープクロール戦略も用意されており、深さ制限、ページ上限、フィルタリング、スコアリングを使ってリンクグラフをたどれます。BFS のディープクロールは、fixture のホームページ上のリンクグラフを辿って5ページを取得しました。ここから、宣伝文句と実際の挙動にズレが見え始めます。詳細はこの後で触れます。
セットアップ：README の冒頭にはまず書かれない部分
私の環境でのインストールは、ある意味では予想以上にスムーズでしたが、別の意味ではかなり重めでした。pip install -U crawl4ai とスモークテストは、macOS arm64 の Python 3.14.2 で成功しました。PyPI の >=3.10 指定には 3.14 も含まれるため、この結果が示しているのは、今回検証したインストールとワークフローが動いたということだけで、広範な互換性を保証するものではありません。
負荷が大きいのはセットアップ工程です。crawl4ai-setup は、Playwright と Patchright の両方に対応するブラウザ資産——Chrome for Testing、FFmpeg、Headless Shell——をダウンロードします。ディスク容量が限られているノートPCや、通信量制限のある回線では、これはかなり大きなコストです。しかも、ドキュメントでは前面に出さず、さらっと触れている程度です。その後の crawl4ai-doctor は通過し、crawl4ai.com を 14.65秒 でクロールしました。これは end-to-end のスモークテストとしては十分ですが、性能ベンチマークではありません。この数値から速度を判断するのは避けるべきです。
このセットアップ項目から得られる教訓は、pip のインストールだけでなくブラウザのダウンロード分も見積もることです。これは単にライブラリをスクリプトに入れるというより、ヘッドレスブラウザ環境を立ち上げる作業に近いです。実際のページを1つもクロールする前に2つのブラウザスタックがディスク上に展開されるため、その初期コストは一度は必ず支払うことになります。たとえワークロードで Patchright のステルス層が不要でも、です。
実践検証：安定した点と、注意が必要な点
4つの結果は丁寧に書き留める価値があります。というのも、マーケティングページではこうした細かな違いが丸められがちで、1つは実際に誤ったラベルが付いていたからです。
公開デモページ2つも正常に処理できました。 Books to Scrape のホームページでは、Crawl4AI が 2.43 秒で 13,476文字 の Markdown を生成しました。公開されている Quotes JS ページでは、描画済み Markdown 1,666文字を約 3.1 秒で取得しました。とはいえ、これはスケール性能、敵対的サイトへの耐性、長時間安定性、セッション管理、プロキシ、リトライ、メモリ挙動を示す証拠ではありません。
記事 fixture は Markdown 品質の注意点を示しています。 Crawl4AI はタイトルと本文の 3/3 段落 を取得しました。これは良い結果です。しかし生の Markdown には、ナビゲーションテキスト、関連リンク、購読案内、フッターの文言まで残っていました。これはバグではありません。コンテンツフィルタや対象セレクターを使わずに「このページを Markdown に変換する」と頼めば、文字通りページ全体が対象になるからです。ここで学ぶべきなのは、生の Markdown 変換と、きれいな記事抽出を分けて考えることです。後者が欲しいなら、PruningContentFilter のようなコンテンツフィルタ、あるいはターゲットセレクターを使います。ただし、そこまでの耐久検証はまだ行っていないので、清潔度を数値で断言することはしません。
壊れたページの結果が、いちばん示唆的でした。 私は意図的に小さな本文を持つ HTTP 500 を返すページを用意しました。Crawl4AI は success=false と status 500 を返しており、そこは正しいです。しかしエラーメッセージは "Blocked by anti-bot protection: Structural: minimal_text on small page." となっていました。実際にはアンチボット対策はありません。単なる小さなエラーページです。Crawl4AI の構造ヒューリスティックが表示テキストの少なさを見て、アンチボットの説明を当てはめてしまったのです。これを利用する側には重要です。ログ上の「anti-bot」というラベルをそのまま信じてはいけません。サイトが本当に妨害しているのかを判断する前に、ステータスコードと実際のレスポンスを確認してください。生の結果はベンチマーク repo の results/local_failure_500.json にあります。
ディープクロールには意図的な設定が必要です。 wait_for を指定した直接の動的クロールはきれいに動きましたが、BFS によるディープクロールは動的カタログを見つけたものの失敗しました。minimal-text という分類は、カードが描画される前に読みに行った場合の挙動と一致していますが、ディープクロールでは直接クロールで使った待機設定が適用されていませんでした。5ページ中、成功は3件、失敗は2件です。ただし、wait_for を付けて再実行した結果はここでは示していないため、この診断は確定ではなく推測の範囲にとどまります。
数値のまとめ
| テスト | 結果 | 観測された実行時間（単一の記録） |
|---|---|---|
クイックスタート（example.com） | 成功、200 | 1.81秒 |
| ローカル静的カタログ（Markdown） | 商品再現率 6/6 | 0.731秒 |
| ローカル静的 CSS スキーマ抽出 | JSON レコード 6件 | 0.740秒 |
ローカル動的カタログ（wait_for） | 商品再現率 8/8 | 1.559秒 |
| ローカル動的 CSS スキーマ抽出 | JSON レコード 8件 | 1.561秒 |
| 記事の Markdown | 段落 3/3（+ ボイラープレート） | 0.752秒 |
| 公開 Books to Scrape ホームページ | Markdown 13,476文字 | 2.425秒 |
| 公開 Quotes JS ページ | 描画済み Markdown 1,666文字 | 3.111秒 |
arun_many()（ローカル6ページ） | 再現率 6/6 | 3.760秒 |
| ローカル BFS ディープクロール | 5ページ検出、成功3 / 失敗2 | 3.239秒 |
| 意図的な 500 ページ | 失敗、500（誤って「anti-bot」と表示） | 0.745秒 |
これらはスモークテストの所要時間であって、性能ベンチマークではありません。記事には、ハードウェア、試行回数、ウォーム/コールド状態、キャッシュ状態、同時実行制御、ばらつきが記載されていません。ここで示しているのは、列挙したワークフローがこのマシンで完了したという事実です。全実行アーティファクトは benchmark repo のディレクトリ にあります。
意思決定に使える性能評価を行うなら、各ワークフローを新しいブラウザセッションと再利用セッションの両方で繰り返し、1つの小数ではなく分布を報告し、ブラウザのビルドを固定し、CPU・メモリ・キャッシュ状態・同時実行数を記録すべきです。そうすることで、ライブラリのオーバーヘッドと、ブラウザ起動やネットワーク変動を切り分けられます。
| 要件 | このレビューでの適合性 | 主な条件 |
|---|---|---|
| ページをレンダリングして Markdown を返す | 有力 | 出力をそのまま記事として扱う前にボイラープレートを除去すること |
| スキーマ型の JSON を抽出する | 有力 | CSS スキーマは自分で作成・保守する必要がある |
| 非同期で読み込まれるページ内容を待つ | 対応 | 対象ごとに明示的な wait_for 条件を設定すること |
| 動的ページを深くクロールする | 条件付き | 準備完了ルールを引き継ぐこと。今回のデフォルトでは一部失敗が発生した |
| 軽量な HTTP パーサーとして使う | 不向き | ブラウザ資産とその管理が運用に含まれる |
| 自己修復型セレクターを使う | 今回の検証では未対応 | 関連のない比較文からそう判断しないこと |
長所と短所
長所:
- 1つのライブラリで、生の Markdown と CSS スキーマの構造化 JSON の両方を扱える。2つのツールをつなぎ合わせる必要がない。
- ブラウザレンダリングが標準搭載されており、非同期で描画される対象には明示的な
wait_forが必要になることがある。 - 検証したシングルページ系のワークフローは、上記の時間で完了した。比較速度の優位性を主張しているわけではない。
- Apache-2.0 ライセンスで、商用利用しやすく、コピーレフトの心配がない。
- 直近のリリースがあり、活発で規模の大きいコミュニティを持つアクティブなプロジェクト。
短所:
- 初回セットアップが重い（2つのブラウザスタック）うえ、紹介文ではその負担が十分に伝わっていない。
- コンテンツフィルタを設定しないと、生の Markdown にはボイラープレートが混ざる。
- ディープクロールでは動的ページを自動待機しないため、クロールごとに設定しないと失敗する。
- エラーメッセージが単純なエラーを「anti-bot」と誤表示することがあり、ログ上わかりにくい。
- 一部の比較記事とは違い、自己適応型セレクターはない。スキーマは手書きで静的に管理する。
- ブラウザ環境の運用、更新、破損対応は自分で担う必要がある。
どんな人に向いているか、どんな人は避けるべきか
Crawl4AI は、RAG やエージェントのパイプラインを構築していて、ヘッドレスブラウザ環境を運用することに抵抗がなく、同じクロールから Markdown と構造化 JSON の両方を得たい開発者なら、評価する価値があります。今回のテストでは、敵対的サイトへの耐性、長時間安定性、メモリ、セッション、リトライ、プロキシ、本番導入は扱っていないため、ここでの推奨範囲は実施したワークフローに限定されます。
逆に、軽量な HTTP パーサーが欲しいなら（これはその正反対です）、ブラウザのダウンロードに使うディスク容量と帯域を確保できないなら、あるいは本番環境でブラウザスタックの保守を自分で持ちたくないなら、見送るべきです。特に、自己修復型セレクター目当てなら避けてください。このツールはそういう製品ではありませんし、その機能を前提にワークフローを組むと、後で必ず痛い目を見ます。ボイラープレートを除いた純粋な記事テキスト抽出が目的なら、その用途に特化した軽いツールのほうが向いているかもしれません。
代替案と、Thunderbit の位置づけ
率直に言えば、Crawl4AI は自分でホストして保守するオープンソースライブラリです。ベンダー利用料は不要で、完全な制御権が得られる一方、計算資源、帯域、ストレージ、ブラウザ更新、スキーマ、運用作業のコストは自分で負担します。
一方で、Thunderbit のようなマネージド型スクレイピングサービスでは、取得と抽出が API の向こう側で処理されます。Thunderbit は今回の fixture では実行していないため、レンダリング、アンチボット対策、CAPTCHA、精度、速度について、ここで同等比較を主張することはありません。比較のポイントは運用責任の所在です。ブラウザ駆動型ライブラリを自前で運用するか、その層をサービスに任せて利用料を払うか、という違いです。
違いを一言で言えば、ブラウザを誰が動かすかです。Crawl4AI では、レンダリング、待機、スキーマ、保守を自分で管理します。マネージド API では、呼び出しごとに料金を払い、運用責任の一部を提供側に移します。今回の検証では、両者の結果比較は行っていません。
関連するベンチマークレビュー：オープンソーススクレイパーの総合比較、Firecrawl のセルフホストレビュー、trafilatura の記事抽出レビュー。
結論
Crawl4AI は、Markdown とスキーマ型 JSON を生成するオープンソースのブラウザベース抽出を求め、かつブラウザ環境を自分で管理する覚悟があるなら、十分に有力な選択肢です。今回の fixture では、静的ページと wait_for を使った動的ページの両方が成功しました。Apache-2.0 は使いやすいライセンスですが、依存関係や配布の通常の確認は引き続き必要です。
ブラウザ資産の分も予算に入れてください。生の Markdown を記事品質にするにはフィルタが必要です。ディープクロールの待機は意図的に設定しなければならず、ログに「anti-bot」と出ても、実際のステータスコードとレスポンスは必ず確認すべきです。スキーマのセレクターは自分で書き、保守する必要があります。これらが今回の検証で確認できた判断基準です。本番規模での挙動や敵対的サイトでの耐性は、まだ未解決のままです。
Webデータ抽出に Thunderbit を試す Get Started Free
FAQ
Crawl4AI に適応型・自己修復型セレクターはありますか？ いいえ。いくつかの比較記事では「adaptive intelligence」があるとされていますが、Crawl4AI が一致させるのは、あなたが書いた CSS/XPath スキーマです。要素を fingerprint したり、HTML 構造の変化後に再探索したりはしません。今回の検証では、手書きしたスキーマで構造化抽出の再現率は 6/6 と 8/8 でした。サイトの class 名が変われば、スキーマは更新するまで壊れます。自己修復型の要素追跡は、別ライブラリの機能であって、このツールの機能ではありません。
なぜインストールサイズがこんなに大きいのですか？
crawl4ai-setup が、Playwright と Patchright の両方に対応したブラウザ資産——Chrome for Testing、FFmpeg、Headless Shell——を丸ごとダウンロードするからです。これは実ブラウザ描画を同梱するためのコストです。ディスクと帯域を確保してください。純粋な HTTP パーサーより重く、しかもワークロードでステルス層を一切使わなくても、このコストは発生します。
Crawl4AI は JavaScript レンダリングのページに対応していますか？
はい。実ブラウザのヘッドレスモードを動かしているからです。検証では、wait_for="css:.product-card" を指定した動的カタログが 8/8 の商品を取得し、公開 Quotes JS ページも問題なく描画されました。ただし、ディープクロールではその待機設定が見つかったページに自動適用されません。BFS クロールでは、待機しなかったために動的ページで失敗しました。待機条件はクロールごとに自分で設定する必要があります。
Crawl4AI はきれいな記事本文だけを返しますか、それともページ全体ですか？
デフォルトではページ全体です。今回の検証では本文の段落はすべて取得できた一方で、ナビゲーション、関連リンク、フッターも残っていました。きれいな記事抽出をしたいなら、生の Markdown に頼らず、コンテンツフィルタ（たとえば PruningContentFilter）やターゲットセレクターを使います。
Crawl4AI のエラーメッセージは信用できますか？ 少し疑って読むべきです。本文が小さい意図的な 500 エラーページが、可視テキストが少ないというヒューリスティックだけで「Blocked by anti-bot protection」とラベル付けされました。実際には anti-bot の壁はありませんでした。生の 結果 は benchmark repo にあります。サイトにブロックされていると結論づける前に、必ず HTTP ステータスコードとレスポンス本文を確認してください。
