hcaptcha-challenger を導入前に読む: マルチモーダル LLM で hCaptcha を解く仕組みと制約
🥂 Gracefully face hCaptcha challenge with multimodal large language model.
ひと目でわかる
- これは何？
- hCaptcha のチャレンジを、外部のキャプチャ代行サービスや Tampermonkey スクリプトに頼らず、ONNX モデルとマルチモーダル LLM の組み合わせで処理する Python ライブラリ。README とリポジトリ構成から読み取れる範囲で、何が動き、どこで止まるかを整理する。
- 誰に向いている？
- 採用を検討すべきなのは、hCaptcha が挟まるブラウザ自動化を自前で運用しており、外部のキャプチャ代行サービスへ画像を送りたくないチームである。逆に、解の成功率がそのまま売上や契約条件に直結する用途、あるいは GPL-3.0 の伝播を避けたいクローズドな製品に組み込む用途には向かない。
- 商用利用できる？
- 条件付きでできます。GPL-3.0 はコピーレフトのライセンスで、これを含むソフトウェアを配布する場合、そのソフトウェアのソースコードを同じライセンスで公開する必要があります。配布せず社内で使うだけなら、この義務は生じません。
- 今もメンテナンスされている？
- されています。最後のコミットは 32 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
hcaptcha-challenger が埋めるのは「画像判定そのもの」ではなく推論の差し替え口
hCaptcha を突破するツールは世の中に複数あるが、多くは外部のキャプチャ代行 API に画像を投げ、返ってきた座標を受け取るだけの薄いクライアントだ。hcaptcha-challenger はその構造を取らない。README は「Does not rely on any Tampermonkey script」「Does not use any third-party anti-captcha services」と明記しており、判定を自分の手元のモデルで完結させる方針を最初に置いている。対象読者は、Playwright などでブラウザ自動化を組んでいて、その途中に hCaptcha が現れる開発者である。とくに、画像を第三者のサーバへ送る経路を避けたい、あるいは代行サービスの従量課金を避けたい事情がある場合に意味が出る。
もう一点、このプロジェクトは「解く」だけでなく「解き方を差し替えられる」ことを売りにしている。README の表現を借りれば「Just implement some interfaces to make AI vs AI possible」であり、チャレンジ種別ごとに推論バックエンドを入れ替える前提で設計されている。単一の学習済みモデルを固定で使うツールではなく、ResNet、YOLOv8、ViT、CLIP-ViT といった複数のモデルを用途別に割り当てる構成だ。
チャレンジ種別ごとにモデルを割り当てる対応表
README の対応表を素直に読むと、このプロジェクトの守備範囲は 5 種類のチャレンジに分かれている。image_label_binary は ResNet の ONNX 分類モデル、image_label_area_select の point 形式は YOLOv8 の ONNX 検出モデル、同じ area_select でも bounding box 形式は YOLOv8 のセグメンテーションモデル、image_label_multiple_choice は ViT の ONNX ゼロショットモデル、image_drag_drop は Spatial Chain-of-Thought という割り当てになっている。
ここで見落とせないのは Agent Capability の列だ。image_label_binary、area_select の point、drag_drop の 3 つにはチェックが付いているが、bounding box 形式と multiple_choice には付いていない。つまり README の表の範囲では、後者 2 つは推論リソースは用意されているもののエージェント的な処理が未対応という扱いである。どのチャレンジが自分の対象サイトに出るかは実際に表示させないと分からないので、導入検討の最初の作業はこの表と目の前のチャレンジを突き合わせることになる。
高度なタスクとして別表に切り出されている Rank.Strategy、self-supervised challenge、Agentic Workflow も同じ構造で、それぞれ nested-model-zoo、CLIP-ViT、AIOps Multimodal Large language model が対応リソースとして挙げられている。表が 2 つに分かれていること自体が、基本の 5 種とそれ以外で成熟度に差があることを示唆している。
推論はローカル、判断は LLM という二層構造
README とリポジトリ構成から読み取れるデータフローはこうだ。まず Playwright でページを操作し、hCaptcha のチャレンジが表示されたらその画像を取得する。画像はチャレンジ種別に応じて ResNet、YOLOv8、ViT のいずれかの ONNX モデルに渡され、分類・検出・セグメンテーションの結果が得られる。drag_drop のように座標の推論だけでは足りない種別では、Spatial Chain-of-Thought とマルチモーダル LLM が判断に関与する。
モデルの配布経路が独特である。README の Workflow 表には「model: upload, upgrade」の行があり、参照先としてリポジトリ内の src ディレクトリと、GitHub Releases の model タグが挙げられている。つまり学習済み重みは PyPI パッケージ本体ではなく、Releases の別タグから取得する形になっている。パッケージをインストールしただけでは推論に必要な重みが揃わない可能性があり、CI やコンテナイメージを組む際はこの取得経路を明示的に扱う必要がある。
学習側のパイプラインも分離されている。データセットは Roboflow 上で管理され、ResNet と YOLOv8 の学習・検証はそれぞれ別の Colab ノートブック（roboflow_resnet.ipynb、roboflow_yolov8.ipynb）で行う構成が README に示されている。推論ライブラリと学習環境が同じリポジトリに同居していないため、自前のデータでモデルを作り直す場合は複数のリポジトリをまたぐことになる。
導入手順と、CI に組み込む際の注意点
パッケージは PyPI で hcaptcha-challenger として公開されている。README のバッジが PyPI のバージョンとダウンロード数を指しているので、pip install hcaptcha-challenger が入口になる。ただし先に述べたとおりモデル重みは別配布なので、インストール後にモデルの取得が別途必要になる可能性が高い。この点は README にコマンドレベルでの記載がないため、実際の取得手順は docs ディレクトリ配下の各言語版ドキュメント（README.md、README_zh.md、README_ru.md、README_vi.md）を確認する必要がある。
リポジトリには GitHub Actions のワークフローが 2 つ用意されている。sentinel.yaml と collector.yaml で、README の Workflow 表ではそれぞれ「ci: sentinel」「ci: collector」と説明されている。sentinel は hCaptcha 側の変更を監視する用途、collector はデータ収集の用途と読める。自前でフォークして運用する場合、この 2 つのワークフローがそのまま定期実行の雛形になる。
バージョンは v0.19.0（2026-01-05）、v0.18.13（2025-10-26）、v0.18.12（2025-10-22）と、直近はマイナーバージョンが比較的短い間隔で上がっている。hCaptcha 側の変更に追随する必要がある性質のソフトウェアなので、バージョンを固定して放置する運用とは相性が悪い。
GPL-3.0 であることの実務的な意味
ライセンスは GPL-3.0 で、これはこのプロジェクトを採用するかどうかを左右する要素になりうる。GPL-3.0 はコピーレフトの条件を持つライセンスであり、本ライブラリを組み込んだソフトウェアを配布する場合、そのソフトウェア全体のソース開示が求められる可能性がある。SaaS として自社サーバ内で実行するだけなら配布に当たらないという整理が一般的だが、クライアントアプリに同梱して配布する形や、社外に配る社内ツールに組み込む形では話が変わる。
ここは法的助言をする場ではないので、判断は各組織の法務に委ねる。実務的には、このライブラリを独立したプロセスとして起動し、自作のアプリケーションとはプロセス境界で分離する設計が取られることが多い。ライブラリとして import して同一プロセスに同居させる形とは、ライセンス上の含意が異なってくる。採用を決める前に、自分の配布形態がどちらに当たるかを先に確定させたほうがよい。
向かないケース: 成功率が契約条件になる用途と、エアギャップ環境
このプロジェクトが向かない場面ははっきりしている。第一に、解の成功率がそのまま売上や SLA に直結する用途だ。README には成功率や処理時間の数値が一切記載されておらず、筆者の手元で検証もしていない。数値の裏付けがない以上、成功率を前提にした設計はできない。
第二に、外部ネットワークに出られない環境である。モデル重みの配布が GitHub Releases の model タグ経由である以上、エアギャップ環境では別途ミラーを用意するか、リリースアセットを手動で持ち込む運用が必要になる。README にはこの取得をオフラインで行う方法の記載が見当たらない。
第三に、対象のチャレンジが対応表の外にある場合だ。hCaptcha はチャレンジの種類を随時変更しており、README の対応表はある時点のスナップショットにすぎない。とくに bounding box 形式の area_select と multiple_choice は Agent Capability の列にチェックが付いていないため、これらが対象サイトの主要なチャレンジであれば、このライブラリだけでは完結しない可能性が高い。
もう一点、README の「What's next」節には Dislock、undetected-playwright、epic-awesome-gamer という関連プロジェクトが並んでいる。これらは hCaptcha 突破を部品として使う側のツールであり、hcaptcha-challenger 自体の成熟度を示すものではない。周辺プロジェクトの存在を導入判断の根拠にしないほうがよい。
比較対象としての hcaptcha-model-factory と外部代行サービス
現実的な代替は 2 つある。ひとつは同じ著者周辺で運用されている hcaptcha-model-factory で、README の Workflow 表から Roboflow 上のデータセット管理とモデル学習を担う側のリポジトリだと分かる。違いは役割の分離にある。hcaptcha-challenger は推論と実行を担当し、model-factory は学習データと重みの生成を担当する。自前のデータでモデルを再学習させたい場合、challenger だけを導入しても学習経路は付いてこない。
もうひとつは外部のキャプチャ代行サービスである。こちらは画像を送れば答えが返るという単純な契約で、モデルの保守もチャレンジ変更への追随もベンダー側の責務になる。hcaptcha-challenger はその逆で、追随の責任が利用者側に移る。README の「Does not use any third-party anti-captcha services」という一文は、この責任の所在を意図的に自分側へ引き寄せる宣言だと読める。運用コストをベンダーに払うか、自前のモデル更新サイクルを回すかというトレードオフであり、どちらが優れているという話ではない。
判定を完全に手元で閉じたい、あるいは代行サービスの利用が社内ポリシーで禁止されているという制約があるなら、このプロジェクトの設計方針はその制約に直接応える。逆に、モデル更新を回す人員がいないのであれば、代行サービスのほうが現実的である。
採用判断の前に確認しておく 3 点
最後に、実際に手を動かす前に確認すべきことを絞っておく。第一に、対象サイトで実際に表示される hCaptcha のチャレンジ種別を確認し、README の対応表のどの行に当たるかを特定する。Agent Capability の列にチェックがない種別が主要であれば、このライブラリ単体では足りない。
第二に、モデル重みの取得経路を自分の環境で再現できるか確かめる。GitHub Releases の model タグから取得する形が前提なので、プロキシやミラーが必要な環境では、そこが最初の障害になる。
第三に、GPL-3.0 の下で自分の配布形態がどう扱われるかを先に整理する。プロセス分離で済むのか、同一プロセスに組み込むのかで結論が変わる。
これら 3 点は、いずれも README を読んだだけでは確定しない。実際に pip install hcaptcha-challenger を実行し、対象サイトのチャレンジを 1 種類表示させ、モデルが取得できるところまでを自分の環境で確認する。そこまでやってから、本番の認証フローに組み込むかどうかを決めればよい。
編集部の結論
採用を検討すべきなのは、hCaptcha が挟まるブラウザ自動化を自前で運用しており、外部のキャプチャ代行サービスへ画像を送りたくないチームである。逆に、解の成功率がそのまま売上や契約条件に直結する用途、あるいは GPL-3.0 の伝播を避けたいクローズドな製品に組み込む用途には向かない。導入前に確認すべきは 3 点で、第一に対象サイトの hCaptcha が README の対応表に載る 5 種類のどれに当たるか、第二にモデル配布が GitHub Releases の model タグ経由であるためエアギャップ環境では別途ミラーが必要になること、第三に hCaptcha 側の難易度変更に対してモデル更新が非同期であることだ。この 3 点を自前の環境で確かめるまで、本番の認証フローには組み込まないほうがよい。
コミュニティノート