Crawlee とは何ですか？

Scrapeless Agent Browser は、動的なウェブページをレンダリングし、対話する必要がある自動化クライアント向けに、マネージドなブラウザー実行環境を提供します。

Crawlee は、JavaScript と Python の実装を備えたオープンソースの Web クローリングおよびスクレイピングフレームワークです。Crawlee は、リクエスト、クローラーハンドラー、実行リソース、結果の保存を中心に作業を整理します。フレームワークは、どのページを処理し、どのようにレコードを保存するかを調整する役割を持ち、ページをレンダリングするブラウザーエンジンやブラウザーをホストするサービスとは異なります。

その違いは、1ページのスクリプトがクロール規模に成長したときに価値を持ちます。課題は、もはや要素を読み取ることだけではありません。限られた作業リスト、追加のURLを発見する方法、重複したリクエストに対する明確なルール、そしてブラウザを閉じた後でも有用であり続ける記録フォーマットが必要になります。Crawlee はこれらの作業のためのコンポーネントを提供し、アプリケーション側はクロールの目的と許容される結果を定義します。

Crawlee がページスクリプトに追加するもの

Crawlee は、ページを取得してデータを抽出するコードの周囲にオーケストレーションを追加します。 Crawlee クローリングフレームワーク HTTP とブラウザのクロール、リクエストの保存、結果の保存、リソースを意識した実行、およびライフサイクルのカスタマイズを提供します。

通常のページスクリプトは、ある URL で始まり、いくつかの観察結果で終わります。クロール処理では、発見されたもののまだ完了していない作業であるフロンティアも追跡する必要があります。ハンドラーがカテゴリーページ、詳細ページ、あるいはページネーションリンクを見つけるにつれて、そのフロンティアは拡大していきます。永続的なリクエストキューを用いることで、増え続けるブラウザタブの集合の中に作業を隠してしまうのではなく、その作業を見える化できます。

ハンドラーは依然としてアプリケーションコードです。フレームワークは、価格が税込みかどうか、あるタイトルが現在の商品に属するかどうか、あるいは空のリストが「結果なし」を意味するかどうかを判断できません。そうした区別は明示的に定義する必要があります。キューに入れられたすべての URL を処理したクロール処理であっても、ハンドラーが不完全または不一致なレコードを受け入れてしまえば、役に立たないデータセットしか生成できません。

HTTP クローラーとブラウザー クローラーは異なる問題を解決する

HTTP クローラーは解析のためにレスポンスを取得する一方、ブラウザークローラーはページスクリプトを実行し、レンダリングされたドキュメントと対話できます。どちらが適切かは、必要なコンテンツがどの段階で利用可能になるかによって決まります。

ダウンロードされたHTML内に公開記事のテキストが存在する場合、そのレスポンスをパースするだけで十分な場合があります。完全なブラウザを起動すると、必ずしも情報が増えるわけではないのに実行時間の負荷が増えます。ページが有用なコンテンツをJavaScript実行後に生成する場合には、ブラウザ経路が必要になることがあります。インタラクティブなフィルターやクライアントサイドのページネーション制御は、その違いを見分ける手がかりになることがあります。

サイトの見た目だけで判断しないでください。見た目が複雑なページでも、最初のレスポンスにレコードが含まれている場合がありますし、シンプルなインターフェイスでも、すべてが後から読み込まれることがあります。実際のレスポンスと、タスクに必要なフィールドがどのようにレンダリングされているかを確認してください。

ブラウザは、ドキュメントのアドレス指定の方法も変えます。埋め込みフレーム内の価格ウィジェットは、親ドキュメント内のより深いノードというだけではありません。 HTML 文書とブラウジングコンテキストモデル クローラーが対象を含むドキュメントを抽出前に特定しなければならない理由を説明します。

リクエストの識別情報が処理対象を決定する

リクエストアイデンティティは、見つかった 2 つのリンクが同じクロール作業単位を表しているかどうかを判定します。URL の重複排除は、アイデンティティルールがアプリケーションと一致している場合にのみ有用です。

トラッキングパラメータは商品ページを変更しない場合がありますが、言語やページネーションのパラメータは異なるコンテンツを選択することがあります。すべてのクエリ文字列を削除すると、別個の結果が一つにまとまってしまう可能性があります。すべてのパラメータを保持すると、重複した処理が発生することがあります。対象にとって意味を持つURLコンポーネントを定義し、代表的なリンクでそのルールをテストしてください。

リクエストの識別子は、レコードの識別子とも異なります。カタログページには多くの商品が含まれる場合があり、1つの商品が複数のカタログページに掲載されることもあります。ページ単位のリクエストを重複排除するだけでは、商品ごとに1つのレコードだけを持つデータセットを保証することはできません。

信頼できる識別子がソースから提供されている場合は、それをソース URL と関連するコレクションのコンテキストとともに保持してください。ソースに信頼できる識別子がない場合は、下流で使用される照合ルールを文書化してください。推測による同一性ルールは、類似したタイトルを持つ異なるバリアントや異なる製品を暗黙のうちにマージしてしまう可能性があります。

設計例としての境界付きカタログクロール

制限付きカタログクロールは、承認されたシードURLから開始し、想定されるカタログに属するリンクのみを許可します。これは概念的な設計例であり、実行例の報告でも、特定のパッケージに依存したコードレシピでもありません。

まず、ディスカバリーページと詳細ページを分けることから始めます。カテゴリハンドラーは、対象となる詳細ページへのリンクとページネーションパスを特定します。詳細ハンドラーは、1つのアイテムに属するフィールドを抽出します。この分離により、すべてのページを互換的に扱う単一のハンドラーよりも、スコープと完全性を確認しやすくなります。

キューに追加するリンクを発見する前に、ホストとパスのルールを指定してください。ナビゲーションメニューには、アカウントページ、外部プロモーション、および無関係なセクションが含まれる場合があります。すべてのアンカーをたどると、閲覧している人の対応する判断なしに、ジョブのスコープが変更されてしまいます。

データセットにおける「完了」を定義します。商品レコードには、安定した識別子とタイトルが必要であり、在庫状況フィールドは null 可能とします。必須フィールドが欠落している場合は、明確に区別された未完了の結果を生成する必要があります。空のカテゴリは、そのページが意図されたカテゴリを実際に表しており、かつ完成された空状態を表示している場合にのみ有効とみなされます。

結果の形状に一致したストレージが必要

Crawlee はキューに入った作業と保存された出力を区別するため、クロールは実行と結果をそれぞれ独立して整理できます。下流のアプリケーションがデータをどのように読み取るかに応じてストレージを選択してください。

データセットはレコードの集合に適しています。キーバリューストアは名前付きの値や成果物に適しています。どちらのストレージ選択もレコードの正しさを定義するものではありません。フィールド名、NULL 許可の有無、テキスト正規化、および結果を解釈するのに必要なソースコンテキストを含むスキーマを定義してください。

たとえば、通貨がない表示価格はあいまいになる可能性があります。場所を指定せずに在庫状況だけを示すと誤解を招くかもしれません。レコードは構造的には有効な JSON であっても、ビジネス判断に必要なコンテキストを欠いていることがあります。それらの入力は後から再構成しようとするのではなく、保持してください。

成果物は通常のレコードとは別に扱ってください。スクリーンショットは欠落フィールドを説明できますが、関係のないページ情報も写し取ってしまいます。本当に必要なときだけ保存し、アクセスを保護し、タスクに見合った保持ポリシーを適用してください。診断用の成果物は、それが説明しているリクエストまたはレコードとの関係が明確であるべきです。

セッションはクロールの入力である

ターゲット URL が変わらなくても、セッションはクローラーが見るものに影響します。Cookie、アカウント状態、言語設定、ブラウザーストレージなどによって、返されるページやレンダリングされるアプリケーションは変化します。

この HTTP cookie mechanism は、サーバーがリクエストを保存されたブラウザ状態と関連付ける 1 つの方法を説明しています。ブラウザーストレージには追加の規則があります。 Web Storage isolation and lifetime によって、オリジン単位のデータとタブに結びついたセッションストレージが区別されます。

独立しているべきワークフローにはクリーンな状態を使ってください。継続性が明示的な要件である場合にのみ、認可済みの状態を再利用します。関係のないジョブ同士で 1 つの可変なブラウザープロファイルを共有すると、あるタスクの出力が、別のタスクが以前にクリックした内容に依存してしまう可能性があります。

フレームワークのセッション機能であるブラウザーコンテキスト、ウェブサイトセッション、リモートブラウザー割り当ては、互換のあるものとして扱うべきではありません。どのコンポーネントがどの境界を所有しているのかを明確にしてください。そうすることで、障害がキュー処理、ブラウザーの利用可否、ウェブサイト認証、あるいはページ状態の変化のどれに関係するのかを判断できるようになります。

Crawlee プロジェクトの評価方法

Crawlee を評価する際は、どのような作業を整理しているかと、生成されたデータセットがどのような証拠を含んでいるかに注目してください。キューに入った URL の数を数えるよりも、小規模だが代表性のあるクロールの方が情報量は多くなります。

任意データが欠落しているページと、スコープ外のページもテストしてください。これらのケースにより、ハンドラーが意図したポリシーを実装しているかどうかが明らかになります。レコードが存在しないことを「何も見つからなかった証拠」とみなすのではなく、ジョブサマリーの中にエラー結果を見える形で残してください。

このアーキテクチャにおける Scrapeless の位置付け

Scrapeless Agent Browser はブラウザー実行レイヤーに属し、Crawlee はクロールのオーケストレーションに属します。 Agent Browser Puppeteer connection はサポートされているクライアントインターフェースを説明するものであり、任意の Crawlee のブラウザープール構成がそのまま動作するという証明と解釈すべきではありません。

The Agent Browser platform は、ワークフローに管理された動的ページ実行が必要な場合に関係してきます。関連する議論である Crawlee for Python and crawl design は、オーケストレーションの選択肢を整理するのに役立ちます。概念をメソッドや設定に落とし込む前に、言語固有のドキュメントを確認してください。

次の観点から Scrapeless pricing を評価してください。これは、最も単純で十分な取得パスを選んだ後に残るブラウザー作業に対するものです。この定義は、Crawlee から Scrapeless への統合が実際に実行・ベンチマークされたと主張するものではありません。

結論

Crawlee は一連のページ操作を、整理されたクロールに変換します。まずリクエストスコープから始め、必要なコンテンツに応じて HTTP かブラウザー実行かを選び、レコードはページリクエストとは独立して定義してください。有用なクロールとは、単にキューを使い果たすだけでなく、説明可能なデータと可視化された不完了な結果で完了するものです。