「Colly」で検索すると、まず目に入る形容詞はだいたい決まっています。速い。Go で動く高速クローラー、コンパイルされるから速い、ブラウザを挟まないから速い。とはいえ、そこに具体的な数値が添えられていることは、ほとんどありません。
そこで私は、その評判をそのまま信じるのをやめました。小さな検証用サイトを立てて、Colly をそこに向けて動かし、このライブラリが実際に何をしてくれるのかを確かめました。たとえば、実ページでの再現率、失敗したリクエストのさばき方、深さ制限付きクロールがどこまで回るのかです。先に結論だけ言うと、静的ページの抽出は再現率100%で返り、500 エラーは想定どおりの場所で処理され、深さ制限をかけたクロールでは、ブラウザを使わない単一の静的バイナリから17ページまで到達しました。さらに、JavaScript で描画されるページに対しては、きれいに0件を返しました。もっとも、ここは「速い」と語る文脈で、よく抜け落ちるところです。
Colly は実際には何なのか、そして何ではないのか
Colly は自分たちを「Golang 向けの洗練されたスクレイパー兼クローラーフレームワーク」と説明していますが、この一文には見た目以上の意味があります。これは Go のライブラリで、gocolly/colly のスター数は 2026-07-09 時点で約25.4k、ライセンスは Apache-2.0 です。URL を放り込めばすぐ使える CLI ツールではありません。Go のコードを書き、パッケージを読み込み、いくつかのコールバックを設定し、最後にひとつの実行ファイルへコンパイルします。
考え方としてはイベント駆動型なので、リクエストしてパースするだけのやり方に慣れている人は少し戸惑うかもしれません。レスポンスを順番に走査して、行ごとにフィールドを抜き出すわけではありません。Collector にハンドラを登録し、ライブラリがページをたどるたびにそれを発火させます。OnHTML は一致した CSS セレクタが出てくるたびに抽出コードを走らせます。OnResponse は生のレスポンスボディを渡してくれるので、対象が HTML ではなく JSON のときに特に重要です。OnError はリクエストが失敗したときにそれを拾います。クロールも仕組みは同じです。リンクを処理するハンドラの中で見つけた URL に対して Visit() を呼ぶと、Colly がそれをキューに積み、MaxDepth がどこまで巡回してよいかを決めます。コールバック、訪問キュー、深さ制限、コンパイル済みの静的バイナリ。インタープリタなし、ランタイムなし、メモリ上に headless Chrome を抱えることもありません。
コールバックモデルが、抽出の体感をどう変えるのか
このツールの個性は、コールバックにかなり集約されています。今回の検証でも、主に使ったのは次の3つです。
OnHTML(selector, handler) はいちばんよく使うものです。.product や article p に対して登録すると、Colly は DOM を解析しながら、一致した要素ごとにハンドラを呼び出します。構造化抽出はここで行います。ループを書いてデータを拾うのではなく、「何を欲しいのか」をそのまま書けるのが気持ちいいところです。
OnResponse(handler) はその一段下にあり、通信で返ってきた生データをそのまま受け取れます。対象がマークアップではなく JSON を返すなら、DOM は一切触りません。ボディを自分で unmarshal するだけです。私の実行では、このコールバックのおかげで、HTML を1文字もパースせずに JSON API を扱えました。
OnError(handler) は、たいていスクレイパーが朝3時に沈んだときに初めて思い出すコールバックです。リクエスト失敗時に発火し、レスポンスを渡してくれるので、ステータスコードを確認して次にどうするか決められます。失敗を静かに飲み込むクローラーは、派手に落ちるものより厄介です。Colly はそのどちらでもなく、そこが無人運用ではかなり大事です。
さらに、これらのコールバックの上に乗る2つの機能が運用面で効いてきます。MaxDepth はクロールの深さを制限するので、リンクをたどるコレクターが無限に広がらず、2ホップ先で止まります。そしてビルド結果は単一の静的 Go バイナリです。1回コンパイルすればランタイム依存なしの1ファイルができ、サーバーや CI ジョブに置いてそのまま動かせます。新しい環境で Python の virtualenv につまずいたことがあるなら、このデプロイのしやすさは、ただの注釈ではなくちゃんとした利点として響くはずです。
セットアップ — 誰も口にしない Go ツールチェーン
依存関係の話は短いですが、実際のハードルは1つだけあります。先にそこを言っておきます。私が試したマシンには Go が入っていなかったので、Colly は Go ライブラリですから、まずツールチェーンを入れる必要がありました。Homebrew 経由で Go 1.26.5 を入れたのが最初の一歩です。チームがすでに Go を使っていないなら、実際に面倒なのはそこです。ライブラリそのものではなく、コンパイル前に必要な言語環境のほうですね。
Go が入ってしまえば、Colly の導入はかなり素直でした。go get github.com/gocolly/colly/v2 は何事もなく v2.3.0 を解決し、ブラウザも headless も不要で、最後に残るのはコンパイルされたバイナリだけでした。パーサーを入れたあと、最初の取得で追加依存が雪崩みたいに増える Python 系スクレイパーと比べると、驚くほど地味です。この地味さは、ここではむしろ褒め言葉です。
ひとつだけ、誤解を避けるためにはっきりさせておきます。Go proxy 上の最新モジュールは v2.3.0 で、公開日は 2025年12月です。一方、GitHub の最新タグ付きリリースは v2.2.0 で、2025年3月です。つまり、私が検証した v2.3.0 は、リポジトリの Releases ページより先に進んでいます。これは Go modules と GitHub タグが時間のズレを起こす仕様上の癖であって、異常ではありません。go get と Releases ページで数字が食い違っても、驚かないでください。
実地検証 — 「速い」の中身を数字で見る
Colly は、Go の httptest で作った自己完結型の検証サーバーに加えて、公開デモサイト2つにも対して実行しました。つまり、結果は「私がそう言っている」だけではなく、再現できるものです。得られた結果は次のとおりです。
| テスト | 対象 | 結果 |
|---|---|---|
| 静的カタログ + ページネーション | ローカル検証環境 | 12/12 件の商品、再現率 1.0 |
| 記事抽出 | ローカル検証環境 | タイトル + 3/3 段落 |
| 動的 JSON API | ローカル検証環境 | OnResponse 経由で 8/8 件、再現率 1.0 |
| HTTP 500 の処理 | ローカル検証環境 | OnError に振り分け、ステータス 500 |
クロールグラフ（MaxDepth 2） | ローカル検証環境 | 17ページ |
| Books to Scrape | 公開デモ | 20件の商品 |
| 動的ページ（JS なし） | ローカル検証環境 | 0件のカード（想定どおり） |
| Quotes JS（未レンダリング） | 公開デモ | 0件（想定どおり） |
上から順に見ると、全体像がきれいにつながります。静的抽出は問題なし。カタログからは12件中12件、記事からは3段落中3段落を取り出せました。どちらも OnHTML セレクタで動いています。JSON API のテストでは HTML パーサーは一切使っていません。OnResponse がボディを渡し、それを unmarshal して、8件中8件を取得しました。500 テストは特に大事にしています。なぜなら、スクレイパーを一晩回しっぱなしにできるかの境目がここだからです。Colly は失敗を OnError に送り、ステータスも明示してくれました。クラッシュもなければ、黙って落ちることもありません。公開されている Books to Scrape のデモでは、特別な処理なしで20件の商品を取得できました。
クロール結果は今回のハイライトです。ただし、表現は正確にしておきたいです。MaxDepth(2) を設定したコレクターが、リンクをたどり、絶対 URL に解決しながら、私の検証グラフの中で 17ページ に到達しました。これで「速い Go クローラー」という言葉に、ようやく具体的なページ数が結びついたわけです。ただし、言い方は慎重であるべきです。ここでの17ページは「深さ2のクロールの中で」到達したページ数です。深さの数字は私のテストハーネス側のカウンタであり、実行条件を表すものです。Colly が内部的に「深さ2ちょうど、それ以上は絶対にたどらない」と契約として保証している、という意味ではありません。検証可能で正確に言うなら、「深さを2に制限した状態で、クロールはグラフをたどって17ページに到達した」です。
そして、ここが限界です。つまり、よくある「とにかく速い」という記事が、あまり触れない部分です。Colly は JavaScript を実行しません。JavaScript で描画される検証用ページに向けたところ、返ってきたカードは 0件 でした。公開の Quotes to Scrape JS page に向けても、結果は 0件 です。これはバグではありませんし、弱点というより設計です。Colly は HTTP クローラーで、HTML をダウンロードして解析するだけで、クライアントサイドのスクリプトを実行するブラウザは起動しません。Scrapy のような HTTP ファーストのクローラーと同じで、欲しい内容が JavaScript 実行後にしか現れないなら、Colly は毎回空の結果を返します。どれだけ速くても、そこは変わりません。必要ならレンダラーと組み合わせるか、最初からレンダリング機能付きのツールを選んでください。
なお、私が今回あえて試していないものもはっきり書いておきます。async collector、rate limiting と polite 設定、proxy rotation、queue や storage バックエンドには触れていません。Colly にはそれらがありますが、今回動かしたのは抽出とクロールの中核だけです。README には、1コアあたり毎秒1000リクエスト超のスループットがうたわれていますが、それはプロジェクト側の数値です。私が測ったのはページ数と再現率であって、スループットではありません。なので、ここで言う「速い」は、実際に計測したコンパイル済み Go の抽出経路を指しており、まだ実行していない Scrapy との直接比較ではありません。
長所と短所
長所:
- 静的抽出で再現率100% —
OnHTML経由でカタログ商品12/12件、記事段落3/3件。 OnResponseによる JSON 処理がきれい — DOM 解析なしで API 8/8件。- 失敗時の振り分けが正確 — 500 が
OnErrorに入り、ステータスも見える。クラッシュなし。 - 深さ制限付きクロールで1つのコレクターから17ページに到達。
- 単一の静的 Go バイナリ、実行時依存ゼロ — デプロイと運用の面でかなり扱いやすい。
- Apache-2.0 の寛容なライセンス。
短所:
- JavaScript 実行なし — クライアント描画のページは 0 件で固定。
- Go ツールチェーンが必要。すでに Go を使っていないチームは、スクレイパーを書く前にそのセットアップコストを払う必要がある。
- 最新モジュール（
v2.3.0）が最新のタグ付きリリース（v2.2.0）より先に進んでいて、Releases ページを見る人を混乱させやすい。 - 出力は自分のコードで組み立てる必要がある。Colly は Scrapy のようにデータセットやフィード書き出しを標準で提供するわけではない。
- async、rate limiting、proxy、queue バックエンドはあるが、今回は未検証。「速い」は今回測った抽出経路の話であり、スループットの直接比較値ではない。
Colly が向いている人、避けたほうがいい人
すでに Go を書いていて、HTML か JSON ベースのサイトを高速にクロールしたいなら、Colly はかなり相性がいいです。クリーンなデプロイを「単一バイナリをサーバーに置いて動かすこと」と考えるなら、インタープリタも virtualenv も依存関係のガチャも不要で、まさにそのために作られたツールです。抽出が単純な作業から一歩進んだ瞬間、コールバックモデルの価値が出てきます。構造化 HTML には OnHTML、生のペイロードには OnResponse、見逃したくない失敗には OnError。静的ページや API ベースの対象を CI で定期クロールするなら、有力でストレスの少ない選択肢です。
一方で、対象が JavaScript に強く依存しているなら、少なくとも別のツールを組み合わせるべきです。私が前に置いたクライアントレンダリング型ページでは、Colly はすべて 0 を返しました。これは設定で切り替えられるものではなく、設計そのものです。Go を触らないチームで、数サイトをスクレイピングするだけのためにツールチェーンを立てたくないなら、それも見送ったほうがいいでしょう。言語のコミットメントは現実であり、その保守責任も自分たちにあります。そして、コードではなく構造化データそのものを受け取りたいなら、Colly のコールバック方式では、その整形作業を完全に自分側で担うことになります。
代替案 — マネージド AI スクレイピング API が活きる場面
Colly は無料の open source ライブラリで、自分でコンパイルして自分で動かします。Go のコード、コールバック、クロールロジック、実行マシンまで全部自分で持つ代わりに、リクエストごとの課金は不要で、運用も社内に閉じられます。Go の現場にとっては十分に筋の通った選択で、単一バイナリで配布できるのも本当に快適です。
ただし、止まるポイントは2つあり、その2つは別のものと比べる価値があります。1つ目は JavaScript です。Colly はレンダリングしないので、クライアントサイド前提の内容はブラウザを足さない限り対象外です。2つ目は構造化です。Colly はコールバックを提供するだけで、きれいな出力の形は自分のコードで作る必要があります。マネージド AI スクレイピング API は、その両方に別の答えを出します。Thunderbit の開発者向けスタックは、JS レンダリングを処理し、構造化データをサーバー側で返します。POST /distill はページをきれいな LLM 向け Markdown に変換し、動的コンテンツや bot 対策もまとめて処理します。POST /extract は、あなたが定義した JSON Schema に沿った構造化 JSON を返し、必要なページでは renderMode を使って完全なブラウザレンダリングにも切り替えられます。AI エージェントやコーディング支援向けには Thunderbit MCP サーバーもあり、thunderbit_suggest_fields は無料なので、導入前にそのページがどんな項目を持つかを試せます。ターミナル、CI、cron には npx @thunderbit/thunderbit-cli で使える CLI もあります。
トレードオフは、どちらが優れているかではありません。仕事をどこに持たせるか、です。Colly なら、レンダリングなし、解析、自前の保守をすべてコンパイル済みバイナリの中に収め、1回ごとのコストはゼロ。その代わり、サイトの見た目や構造が変わったときは自分で面倒を見る必要があります。マネージド API なら、JS レンダリング、bot 対策、構造化出力を手放せて、その対価として呼び出しごとに支払います。小規模で、Go ネイティブで、HTML か JSON ベースで、しかも自分で持ちたい対象なら？ Colly の制御性と速度が勝ちます。JavaScript が多いページや、もう1つコールバックを書くよりスキーマ付き JSON をそのまま受け取りたいなら？ それはマネージド側の出番です。より広い選択肢を見たいなら、best web scraping tools や best web scraping GitHub projects のまとめが、Colly の立ち位置をブラウザ型やマネージド型の選択肢と並べて整理してくれます。
結論
Colly は使うべきか？ はい。Go を書いていて、HTML か JSON を高速にクロールしたいなら、このツールは「速いクローラー」という評判どおりの仕事をし、しかもその評判に数値が付きました。静的抽出は再現率100%。OnResponse で JSON もきれいに取得。500 は消えずに OnError に届く。深さ2のクロールで17ページに到達。しかもすべてが1つの静的バイナリにコンパイルされ、実行時依存もありません。このカテゴリ全体でも、かなり扱いやすいデプロイ形態です。
ただし、期待値はきちんと合わせるべきです。JavaScript は一切レンダリングしません。私の検証では、クライアントサイドのページはすべて0件でしたし、それは設定漏れではなく恒久的な仕様です。Go ツールチェーンも必要なので、Go 以外のチームは最初にセットアップの負担があります。インストールするモジュール（v2.3.0）は最新のタグ付きリリース（v2.2.0）より先を行っているので、ページ同士で数字が違っても慌てないでください。そして、ここで言う「速い」は、私が測った抽出経路の話であって、まだ実行していないスループットベンチマークではありません。その条件の中では、Colly は速く、安定していて、実運用に乗せやすい Go クローラーです。そして JavaScript を求め始めた瞬間、その評判どおりの実力を見せてくれます。
Web データ抽出に Thunderbit を試す Get Started Free
よくある質問
Colly は本当に速いのですか？ それを示す数値はありますか？ 私が測ったコア処理に限れば、速いと言って差し支えありません。コンパイル済み Go で、静的抽出は再現率100%（カタログ商品12/12件）、JSON 処理もきれいで、深さ2のクロールでは17ページに到達しました。しかも単一の静的バイナリで実現しています。ただし、Scrapy とのスループット比較は行っていないので、「速い」はあくまで計測した抽出挙動として受け取ってください。直接対決の速度スコアではありません。
Colly で JavaScript 描画のページはスクレイピングできますか？ いいえ。Colly は HTTP クローラーで、HTML をダウンロードして解析しますが、ブラウザを起動して JavaScript を実行することはありません。JavaScript 描画の検証用ページは 0 件、公開の Quotes JS ページも 0 件でした。クライアントサイドのコンテンツを扱うなら、Colly にレンダラーを組み合わせるか、最初からブラウザレンダリング内蔵のツールを使う必要があります。
Colly を使うには Go を知っている必要がありますか？
はい。Colly はスタンドアロンの CLI ではなく Go ライブラリです。読み込んで、OnHTML、OnResponse、OnError などのコールバックを登録し、コンパイルします。私が試したマシンには Go が入っていなかったため、最初の作業はツールチェーンのインストール（1.26.5）でした。チームがすでに Go で開発していないなら、その環境整備こそが本当のセットアップコストです。
インストールしたバージョンが Colly の GitHub 最新リリースと一致しないのはなぜですか？
Go モジュールと GitHub のリリースタグがずれているからです。Go proxy 上の最新モジュールは v2.3.0（2025年12月）ですが、GitHub の最新タグ付きリリースは v2.2.0（2025年3月）です。私が検証したのは v2.3.0 です。これはモジュールとタグの差によるもので、壊れたインストールではありません。
Colly は商用利用でも無料ですか？ はい。Apache-2.0 なので、商用利用にも向いた寛容なライセンスです。とはいえ、実際に採用する前には必ず repo で現在のライセンスを確認してください。
