オープンソースクローラーの選び方：4つの役割と4つの評価軸

GitHubでクローラーを検索すると、数百から数千ものリポジトリが見つかります。スター数を見て、最も人気のあるプロジェクトをそのまま選ぶ人も少なくありません。

しかし、人気と自分の用途への適合性は別の話です。どれほど人気があっても、プロジェクトの目的が自分のシナリオと合わなければ運用負担は増えます。まず役割を分けて考えるほうが簡単です。長期間安定して動く収集システムは、もともと異なる責務を持つ複数の部品を組み合わせて作られます。それぞれが何を担当するかを理解すれば、具体的な実装の比較もしやすくなります。

汎用クローラーフレームワーク：構造が安定したページ向け

この種のフレームワークは、リクエストのスケジューリング、並列取得、データパイプラインを担当します。複数のURLを入力として受け取り、構造化された結果を出力します。成熟したエコシステムとミドルウェア機構により独自ロジックを組み込めるため、大規模な長期タスクにも対応しやすいのが特徴です。

一方、JavaScriptの実行後に初めて内容が表示されるページは単独では処理できません。最初に取得できるのは空の殻だけなので、別途レンダリングエンジンが必要です。リストページ、詳細ページ、公開APIなど、構造が安定した対象に向いています。

ブラウザ自動化フレームワーク：レンダリングや操作が必要なページ向け

実際のレンダリング、ログイン状態、数回のクリック後に表示される内容が必要なページは、ブラウザ自動化に任せる必要があります。複数のブラウザエンジンで動作でき、待機機構も成熟しており、ページ内のリクエストやレスポンスを直接扱えるものもあります。

ただし、単純なHTTPリクエストよりもリソース消費は大幅に増えます。同時実行数の上限は、主にローカルのメモリとCPUで決まります。また、自動化には検出可能な特徴が残るため、検知が厳しいサイトでは識別される可能性があります。

スケジューリングとキュー：タスク数が増えてから必要になる

対象が少ないうちは単純なループでも十分です。タスクが数千件になり、頻度制御や再試行も必要になると、独立したスケジューリング層が必要です。タスクの並べ方、同時実行数、失敗後の再試行までの待ち時間、打ち切るタスクの条件などを管理します。こうしたロジックをすべてクローラーフレームワークに詰め込むと、コードはすぐ複雑になります。

この層を自作するときの典型的な失敗は、プロセス内だけのキューで済ませることです。プロセスが再起動すると、待機中のタスクはすべて消えます。少なくとも、キューには永続性があり、状態を確認できる必要があります。

解析と保存：データをそのまま使えるかを左右する

取得できるのはHTMLですが、実際に必要なのはフィールドです。解析層では、抽出ルールの管理、フィールド検証、重複排除、保存処理を行います。構造変更が多いサイトでは、固定セレクターではなくページの特徴からデータ位置を特定する適応型の抽出方式を検討すると、保守負担を減らせる場合があります。

保存側では冪等性にも注意が必要です。タスクの再試行は普通に発生するため、一意な識別子で重複を排除して書き込まないと、重複データが後段の分析まで影響します。

組み合わせた後に起こりやすい問題

各コンポーネントを個別に見ると難しくありません。問題は主に接続部分で発生します。

• スケジューリング層が再試行したのに解析層が重複排除せず、同じ行が増える
• ブラウザ層に同時実行数の上限がなく、ローカル資源を使い切ってバッチ全体が失敗する
• 解析ルールをコードに固定しており、サイトの変更ごとに再リリースが必要になる
• コンポーネントごとに同じタスクの識別子が統一されておらず、状態が一致せず途中再開もできない

4つの評価軸

必要なカテゴリを決めたら、次の4項目で具体的なプロジェクトを絞り込みます。

保守の活発さは、総スター数ではなく、直近数か月のコミット頻度とissueへの応答速度を確認します。保守が止まったプロジェクトは、対象サイトの変更後にそのまま使えなくなる可能性があります。

ドキュメントとサンプルは導入コストを左右します。説明が曖昧だったり、最も簡単な例しかなかったりすると、学習時間は想定より長くなりがちです。

拡張性では、どの部分を差し替えられるかを確認します。プロキシを変更できるか、自前のレンダリングエンジンを接続できるか、保存先を置き換えられるかがポイントです。明確な拡張ポイントがあれば、後の改修でソースコードを直接変更せずに済みます。

ライセンスとコンプライアンスのリスクは見落とされがちです。商用利用前にライセンス種別を確認し、用途と合わない制約のあるライセンスは避けます。収集範囲、リクエスト頻度、対象サイトの利用条件も合わせて評価する必要があり、これはフレームワーク自体の技術的な良し悪しとは別の問題です。

環境レイヤーは別の階層の問題

フレームワークが解決するのは「どう取得するか」であり、アイデンティティや規模の問題ではありません。ログインが必要、地域を分ける必要がある、複数アカウントを並列で動かす必要がある場合、すべてを同じブラウザ環境で実行すると2つの問題が起きます。Cookieやローカルストレージが重なってセッション同士が影響し、さらに対象サイトから、本来無関係なタスクが同じ一連のアクセスとして見える可能性があります。

成熟した構成では、ブラウザ環境を独立したリソース層として扱います。タスクは環境プールから環境を取得し、使用後に解放します。このようなアーキテクチャでは、PurpleMarkがそのレイヤーを担い、一括作成、独立したネットワーク出口への紐付け、状態確認が可能な環境リソースを提供します。

コンプライアンス上の境界

対象サイトのrobotsルールと利用規約に従い、個人情報を収集せず、技術的な保護措置を回避せず、相手の通常サービスに影響しないようリクエスト頻度を制御します。プロジェクト選定は効率の問題を解決しますが、これらの判断は、そもそも収集を実施してよいかどうかを決める問題です。