Collyレビュー：静的HTML、直接JSON、そしてブラウザの境界

ページ数や速度の評判だけではわからないColly の挙動を確かめるため、検証用の固定サイトを用意した。確認したかったのは、コールバックが期待どおりのレコードを抽出できるか、HTTPエラーを適切に振り分けられるか、深さ制限付きのグラフをたどれるか、そしてレンダリング済みHTMLの外で提供されるコンテンツまで取得できるか、という点だ。これはスループットのベンチマークではなく、正確性と境界条件を確かめるレビューである。

制御されたフィクスチャでは、期待していた静的レコードをすべて抽出でき、500応答1件をOnErrorに振り分け、設定した深さ制限グラフでは17件のURLを巡回した。一方、要素がJavaScript実行後にのみ現れる2ページでは、対象要素は0件だった。直接アクセス可能なJSONエンドポイントはブラウザなしでも利用でき、これはクライアントUIをレンダリングする場合との重要な違いだ。

Collyとは何か

Collyは自らを「Golang向けの洗練されたスクレイパー兼クローラーフレームワーク」と説明しているが、この一文は見た目以上の意味を持つ。これはGo言語のライブラリで、GitHubスター数は約25,300、フォーク数は1,850、ライセンスはApache-2.0だ。URLを渡すだけで動くCLIではない。Goのコードの中でColly をimportし、いくつかのコールバックを登録したうえで、ひとつの実行ファイルにコンパイルする。

考え方はイベント駆動だ。Collectorにハンドラを紐づけていく。OnHTMLはCSSセレクタに一致した要素に対して抽出処理を実行し、OnResponseは生のレスポンス本文をそのまま渡し、OnErrorはリクエスト失敗を処理する。見つかったURLにはVisit()を呼んでリンクをたどり、MaxDepthで巡回の深さを制限する。HTTPのみで完結する経路であれば、対象ホスト側にGoランタイムやブラウザを別途用意する必要はない。ただし生成される実行ファイルが完全に静的リンクされているかどうかはビルドフラグやCGOの使用有無次第であり、今回の検証ではそこまでは記録していない。

主な機能と、その裏側の動き

理解すべきはコールバックの仕組みだ。Collyが一般的な「リクエストしてパースする」スクリプトと違って感じられるのは、この仕組みのおかげである。今回のテストは、すべて3つのコールバックだけで完結した。

OnHTML(selector, handler)が中心的な役割を担う。.productやarticle pに対して登録すると、Collyは DOM を解析しながら一致した要素ごとにハンドラを1回ずつ呼び出す。構造化抽出はここで行う。パース処理を自分でループさせる代わりに「何を取り出すか」を記述するだけでよく、コードが読みやすくなる。

OnResponse(handler)はもう一段低いレイヤーにあり、生のバイト列を渡してくれる。対象がHTMLではなくJSONを返す場合は、DOMをまったく使わずに本文を自分でunmarshalすればよい。今回のテストでColly がHTMLパースなしにJSON APIをきれいに扱えたのは、まさにこの単一のコールバックのおかげだ。

OnError(handler)はリクエスト失敗を処理し、呼び出し元にレスポンスのステータスを渡すことができる。今回のテストでは、ステータス500のフィクスチャレスポンス1件が登録済みのコールバックに届いた。リトライ、タイムアウト、DNS障害、接続リセット、コールバック内のパニック、永続化、アラート通知はテストしていない。

これらのコールバックの上に、2つの運用面の機能がある。MaxDepthはColly の深さの定義に従ってリンク巡回を制限する。またコンパイル済みのGo実行ファイルであれば、対象ホストに別途言語ランタイムを用意する必要がない。今回の実行ではビルドフラグやCGOの状態を記録していないため、生成された実行ファイルがすべて完全に静的だと断定はしない。

セットアップ: 必要なGoツールチェーン

依存関係の話は短いが実際に存在するので、何かをインストールする前に触れておく。今回検証したマシンにはGoが入っておらず、Colly はGoのライブラリなので、最初の一歩はマシンにGoツールチェーンを用意することだった(HomebrewでGo 1.26.5をインストールした)。チームが普段からGoを使っていないなら、ここに摩擦が生じる。障壁になるのはColly 自体ではなく、1行もコンパイルする前に必要になる言語環境のほうだ。

Goを用意したあと、go get github.com/gocolly/colly/v2を実行するとv2.3.0が解決された。検証した経路では、ブラウザもヘッドレスChromeも不要だった。

バージョン表記には少し紛らわしい点がある。Goモジュール側はv2.3.0(2025年12月公開)として解決されたが、GitHubのReleases画面で確認できた最新エントリは確認時点でv2.2.0(2025年3月)だった。これはモジュール/リポジトリのバージョンとGitHub Releaseのエントリの違いであって、モジュールとGitタグの違いではない。今回検証したのはv2.3.0だ。

実践: 抽出と運用の境界

Colly を、自己完結型のフィクスチャサーバー(Goのhttptest)と、公開されている2つのデモサイトに対して実行した。現在のベンチマークディレクトリとresults/colly-test-summary.jsonには成果物が置かれているが、どちらのリンクも更新され続けるブランチを指している。この記事では検証済みのコミット、正確なコマンド、ビルドフラグ、フィクスチャのシード値までは示していないため、まだ不変の再現手順とは言えない。

制御された静的フィクスチャでは、設定したセレクタにより、期待していた12件中12件の商品レコードと、3件中3件の記事段落をすべて取得できた。直接のJSON応答はHTMLパーサーを一切経由しなかった。OnResponseが本文を渡し、テストハーネス側で期待していた8件すべてをJSONデコードした。500の単一フィクスチャはOnErrorに届き、ステータスも確認できたうえでその実行はクラッシュしなかったが、これだけで無人運用時の信頼性が証明されるわけではない。公開されているBooks to Scrapeページでは、セレクタが20件の商品を返し、公開サイトでの簡易な動作確認として機能した。

巡回については、ハーネスのシード深さの規約に従ってMaxDepth(2)を設定し、フィクスチャのグラフ内で17件のURLを訪問した。これは巡回の網羅性を示す結果であり、速度の結果ではない。観測されたこのトレースは、任意のグラフ全般についての主張ではなく、results/local_crawl_graph.jsonに記録された内容そのものだ。

Colly はJavaScriptを実行しない。JavaScriptでレンダリングされるフィクスチャでは対象カードが0件、公開されているQuotes to Scrape JSページでも対象の引用文が0件だった。要素がブラウザ実行後にしか存在せず、アクセス可能な裏側のエンドポイントも用意されていない場合、HTTP専用の経路ではそれらの要素をレンダリング済みDOMとして見ることはできない。レンダラーを組み合わせるか、JSONのフィクスチャが示すように、利用可能であれば裏側のエンドポイントを直接呼び出す必要がある。

非同期コレクター、レート制限やポライトネス設定、プロキシのローテーション、リトライ、キューやストレージのバックエンドは負荷をかけて検証していない。経過時間、スループット、並行実行数、CPU、メモリ、対象側のレイテンシ、比較用のベースラインも計測していない。したがってこの記事は、速度や無人運用時の信頼性について何も主張しない。

フィクスチャの結果をどう読むか

成功した3つのコンテンツ経路は、それぞれ異なる契約を検証している。カタログと記事のケースは、サーバーが返すHTMLに対するCSSセレクションを試すものだ。分母は抽出前に定義したフィクスチャの期待値、つまり12件の商品レコードと3件の記事段落である。これを「期待したレコードを抽出できた」と表現しているのは意図的なものだ。今回の実行では、あいまい一致、重複処理、部分フィールドの許容、コーパス全体の再現率といった定義はしていない。したがってこの結果を一般的な抽出精度として拡大解釈すべきではない。

JSONのケースはDOMセレクションを迂回する。Colly はOnResponseを通じてレスポンスのバイト列を受け取り、JSONデコードはテストハーネス側が行う。だからといって「Colly はJavaScriptをレンダリングしない」という事実が、クライアント依存のサイトをすべて対象外にするという意味にはならない。クライアントが使うデータソースが直接呼び出せるエンドポイントであり、ブラウザの外でも再現可能なリクエストであれば、HTTPクローラーだけで十分な場合がある。認証、生成されるシグネチャ、ブラウザ専用の状態、アンチボット制御があれば話は変わるが、今回はそのいずれも検証していない。

500のルートが試しているのは復旧ではなく振り分けだ。登録済みのOnErrorコールバックがそのフィクスチャレスポンスとステータスを受け取ったことを示しているにすぎない。本番環境のクローラーには、リトライ可能なコード、バックオフ、致命的な失敗、永続化、アラート通知に対する明確な方針が別途必要になる。今回のテストはそうした判断の根拠を与えるものではなく、「コールバックが発火した」ことを「そのジョブを無人で信頼できる」と読み替えるべきではない。

17件のURLグラフも同様に限定的なものだ。これはこのフィクスチャ、このシード規約、そしてMaxDepth(2)によって生成された訪問集合を確認したにすぎない。秒間ページ数、ホスト間の公平性、メモリの増加傾向、循環URLや重複URL形式への挙動については何も示していない。そうした確認には、別途ワークロードテストとキューのテストが必要になる。

今回の実行結果に基づく選定チェックリスト

まず、Colly が実際に受け取るレスポンスの中身を確認しよう。必要なフィールドがサーバーの返すHTML内にあるならOnHTMLを使い、レコードを受け入れる前にフィールド数や必須キーを検証する。レスポンスがJSONならOnResponseで本文を処理し、スキーマを検証する。HTMLが単なるアプリケーションの外殻にすぎないなら、ブラウザを追加する前に、アクセス可能な裏側のリクエストにデータが含まれていないか確認するべきだ。

ブラウザ実行が必要になった場合は、Colly のフラグ一つでレンダリングが有効になると期待せず、別コンポーネントとして扱うべきだ。ブラウザ側が準備完了を確認し、レンダリング済みのコンテンツや裏側のレスポンスを公開し、そのデータをパイプラインの残り部分に渡す必要がある。今回のレビューではそうした統合はテストしていない。

デプロイに際しては、Goのバージョン、モジュールのバージョン、ビルドフラグ、CGOの状態、正確なコマンド、フィクスチャのシード値、リポジトリのコミットを記録しておくこと。これらは現在公開されているリンクには欠けており、検証可能な成果物と、持続的に再現できる状態との差になる。運用面では失敗パターンの一覧を用意し、速くて信頼できると言い切る前に、実際に重要となるワークロードを測定するべきだ。

メリットとデメリット

メリット:

• OnHTMLで期待していたカタログ商品12/12件、記事段落3/3件を抽出できた。
• OnResponseによるJSON処理がきれいで、DOMパースは不要だった。APIの項目は8/8件。
• 検証した500応答はOnErrorに届き、ステータスも取得できた。
• 深さ制限付きクロールで、単一のコレクターから17ページに到達した。
• Goの実行ファイルにコンパイルされ、検証した経路では対象側に別途Goランタイムが不要だった。
• 制約の緩いApache-2.0ライセンス。

デメリット:

• JavaScriptの実行機能がなく、クライアントレンダリングされたコンテンツは一律0件になる。
• Goのツールチェーンが必要で、Goに不慣れなチームはスクレイパーを書く前にこのセットアップコストを払うことになる。
• 検証したモジュール(v2.3.0)は、確認時点のGitHub Release最新版(v2.2.0)より先行している。
• 出力は自前のコード次第であり、Colly はScrapyのような組み込みのデータセット/フィードエクスポーターは提供しない。
• 非同期処理、レート制限、プロキシ、キューのバックエンドは存在するが今回は検証しておらず、スループットや規模は未計測のままだ。

向いている人・向いていない人

すでにGoを書いていて、対象がサーバー生成のHTMLか直接アクセス可能なJSONであれば、Colly はよく合う。コールバックモデルのおかげで、構造化されたマッチ、生のペイロード、リクエスト失敗がきれいに分離される。コンパイル済みの実行ファイルであるため、対象マシンに別途言語環境を用意しなくてよい点も利点だが、完全な静的リンクかどうかはここでは検証していない。

必要な対象要素がブラウザ実行後にしか現れず、使える裏側のエンドポイントもない場合はレンダラーを追加する必要がある。直接のJSONエンドポイントがあれば、レンダリングなしでも取得できる。またGoのツールチェーンを導入したくないチームや、抽出サービス側にスキーマ整形とセレクタ保守までまとめて任せたいチームには、Colly はあまり向いていない。

代替案とThunderbitの位置づけ

Colly は自分たちで運用するオープンソースソフトウェアだ。ベンダーへの利用料はかからないが、計算資源、帯域、プロキシ、ストレージ、可観測性、そしてエンジニアリングのコストは自分たちで負担することになる。対象サイトがレンダリングを必要とする場合、リクエストの挙動、パース用のコールバック、クロールロジック、ブラウザ統合まですべて自前で用意しなければならない。

マネージド型の抽出サービスは、こうした責任の一部をベンダー側に移す。私たちはThunderbitを開発しているが、今回のフィクスチャに対しては検証していないため、この記事ではレンダリング、アンチボット対応、品質、レイテンシ、コストの比較はしない。ここで言えるのは「責任の所在」という違いだ。Colly はHTTPレスポンスとコールバックを自分のGoプロセスの中で扱う。一方でマネージドサービスは、データ取得とスキーマ整形を従量課金で引き受けてくれる場合がある。

関連するベンチマークレビュー: オープンソーススクレイパーの全体比較、ScrapyのPythonクローラーレビュー、Scraplingの適応型セレクタレビュー。

Thunderbitでウェブデータ抽出を試す

総評

Colly は、サーバー生成のHTMLや直接のJSONを対象とし、自前の抽出コードを持つ意志があるGoチームにとって有力な候補だ。今回のフィクスチャが裏付けているのは、期待どおりのレコード抽出、境界を区切った1回分のクロールトレース、そして観測された1件の500コールバックであり、速度や規模、無人運用時の信頼性ではない。ブラウザでレンダリングされるDOMについては、元となるデータエンドポイントを直接呼び出せない限り、別の経路が必要になる。

Thunderbitでウェブデータ抽出を試す Get Started Free

よくある質問

このレビューでColly の速度を測定しましたか? いいえ。測定したのは期待どおりのレコード抽出、直接のJSON処理、1件のエラーコールバック、そしてフィクスチャのクロールグラフの網羅性だ。経過時間、スループット、並行実行数、CPU、メモリ、比較用のベースラインは測定していない。

ColyでJavaScriptレンダリングされたページをスクレイピングできますか? Colly はページのJavaScriptを実行しない。そのため検証したHTTP経路では、レンダリング済みDOMにしか現れない対象要素は取得できなかった。ただしJSONのフィクスチャが示すとおり、アクセス可能な裏側のJSONエンドポイントは直接呼び出せる。実行が必須で、再現可能な裏側のリクエストからデータを得られない場合はレンダラーを使うこと。

Colly を使うにはGoを知っている必要がありますか? はい。Colly は単独のCLIではなくGoのライブラリだ。importし、コールバック(OnHTML、OnResponse、OnError)を登録し、コンパイルする必要がある。今回検証したマシンにはGoが入っておらず、セットアップはGoツールチェーン(1.26.5)のインストールから始まった。チームがすでにGoを使っていないなら、この環境構築こそが実質的な導入コストになる。

インストールしたバージョンが、Colly の最新GitHub Releaseと一致しないのはなぜですか? Goモジュールはv2.3.0(2025年12月)として解決されたが、確認時点で見えたGitHub Releaseの最新エントリはv2.2.0(2025年3月)だった。今回検証したのはv2.3.0であり、これはバージョン表記の違いであって、インストールが壊れている証拠ではない。

Colly は商用利用でも無料ですか? Apache-2.0ライセンスであり、制約が緩く商用利用にも向いている。とはいえ、導入前には必ずリポジトリで最新のライセンスを確認してほしい。

本番導入の前には、今回のフィクスチャ結果を類推で広げるのではなく、運用リスクに見合ったテストを追加すること。代表的な対象で繰り返しクロールした時間を計測し、CPUとピーク時のメモリを記録し、リトライ可能な失敗と致命的な失敗の両方を試し、並行実行時のポライトネスを確認する。永続化が重要なら、重複処理とキューの状態を見ながらクロールを一度停止して再開してみる。デプロイの簡便さが重要なら、コンパイラとリンカの正確な設定を記録し、生成された実行ファイルのランタイム依存関係を確認する。これらの確認によって今回のフィクスチャが示した内容自体が変わるわけではない。あくまで、その同じライブラリ構成が特定の本番ジョブに合っているかどうかを判断する材料になるだけだ。