CyberScraper 2077 を採用すべきか: LLM パース型スクレイパーの実態
A Powerful web scraper powered by LLM | OpenAI, Gemini & Ollama
ひと目でわかる
- これは何？
- Streamlit の GUI から Playwright と LLM を組み合わせてデータを抜き出すツール。抽出精度をモデルに依存させる設計で、API キーと Python 3.10 以上が前提になる。
- 誰に向いている？
- GUI から数クリックで対象サイトのデータを表形式に落とし、CSV や Google Sheets へ渡したい人には向く。逆に、毎日決まった構造のページを大量に処理するバッチや、LLM のトークン費用を予算に固定したい用途には向かない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 5 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
誰のためのツールか: 構造が毎回変わるページを相手にする人
CyberScraper 2077 が解こうとしているのは、セレクタを書いても次の改修で壊れる、というスクレイピングの古典的な問題である。README はこのツールを「AI-Powered Extraction」と説明し、AI モデルで Web コンテンツを理解して解析するとしている。つまり CSS セレクタや XPath を人手で維持する代わりに、抽出の判断を LLM に委ねる。対象読者として README が挙げるのはデータアナリストや、いわゆる netrunner 的な利用者だが、実際に恩恵を受けるのは、対象ページの DOM 構造が頻繁に変わる、あるいはページごとに構造がばらつくために都度パーサを書き直している人である。逆に、構造が固定されたページを大量に処理するだけなら、この依存関係の増え方は割に合わない。
抽出の流れ: Playwright で取得し、LLM に構造化させる
README から読み取れる構成はこうである。取得層に Playwright があり、インストール手順でも playwright install を別途実行させている。UI 層は Streamlit で、docker run のポートが 8501 なのは Streamlit の既定ポートと一致する。抽出層には OpenAI、Gemini、Ollama、そして LiteLLM 経由の任意モデルが並ぶ。ページ本文を取得したあと、どの要素をどう構造化するかを LLM に判断させ、結果を JSON、CSV、HTML、SQL、Excel のいずれかへ出力する。README は「Smart Parsing」として、抽出内容を構造化すると述べている。重要なのは、この流れの精度がモデルの指示追従性に乗っている点だ。README 自身が Ollama の節で「OpenAI と Gemini API のみを勧める」と書き、オープンソース LLM を使う場合はプロンプトの微調整やフィルタの追加が自分で必要になると認めている。抽出ロジックがコードではなくプロンプト側にあるという設計上の帰結である。
セットアップ: venv、playwright install、環境変数 3 系統
前提は Python 3.10 以上。手順は git clone のあと virtualenv venv と source venv/bin/activate、pip install -r requirements.txt、そして playwright install である。LLM の認証は環境変数で渡し、OpenAI は OPENAI_API_KEY、Gemini は GOOGLE_API_KEY を使う。LiteLLM 経由の場合は LITELLM_API_KEY、LITELLM_BASE_URL、LITELLM_MODELS の 3 つを設定し、サイドバーに litellm:<model> の形式でモデルが現れる。LITELLM_BASE_URL の既定値は http://localhost:4000/v1 と README に明記されている。Ollama は pip install ollama のうえで本体を別途導入し、ollama pull llama3.1 のようにモデルを取得する。Docker の場合は docker build -t cyberscraper-2077 . のあと、docker run -p 8501:8501 に -e OPENAI_API_KEY と -e GOOGLE_API_KEY を付けて起動する。Windows 利用者には Docker 手順を辿るよう README が明言しており、ネイティブ版の維持は行われない。
キャッシュと Tor と stealth: 実装されている周辺機能
README が挙げる周辺機能のうち、コストに直結するのがキャッシュである。コンテンツベースとクエリベースの 2 種類を LRU キャッシュと独自の辞書で実装し、冗長な API 呼び出しを減らすと説明されている。同じページを同じ指示で二度処理したときに API 課金が二重に発生しない、という意味では実用的な作りだ。取得側では stealth モードのパラメータでボット判定を避けるほか、ローカルブラウザのインスタンスを使う「Current Browser」機能があり、README はこれでボット検出の大半を回避できるとしつつ「必要なときだけ使うように」と注記している。Tor 経由で .onion サイトを取得する機能もあり、自動ルーティングを行うとされる。captcha 回避は URL 末尾に -captcha を付ける方式で、ネイティブ環境のみ、Docker では動作しないと明記されている。
見落としやすい制約: Docker と captcha、そしてモデル依存
導入判断で最初に引っかかるのは captcha 回避が Docker で動かない点である。コンテナで動かす前提を選んだ時点で、この機能は選択肢から外れる。次に効くのが Ollama 運用の現実で、README は生成と表示の速度がシステムの LLM 実行性能に依存すると書いている。つまりマシンスペックがそのままスループットになる。加えて、抽出結果の正しさを保証する仕組みは README には示されていない。LLM が指示を取り違えれば、エラーではなく「それらしいが違う表」が返る。出力形式が JSON や CSV であっても、値の妥当性は別問題である。ナビゲーション機能は BETA と明記されており、複数ページをまたぐ処理は安定版として扱うべきではない。
代替との違い: セレクタ型ツールと何が変わるか
比較対象として素直なのは Scrapy や BeautifulSoup と requests の組み合わせである。これらは CSS セレクタや XPath で抽出位置を明示し、パースは決定的に動く。同じ入力なら同じ出力が返り、API 課金も発生せず、ネットワークさえあればオフライン環境でも動く。代償は脆さで、サイト側のクラス名や DOM 構造が変わればパーサを書き直す必要がある。CyberScraper 2077 はこの順序を逆にしており、構造変化への耐性を LLM の汎化に預ける代わりに、出力の決定性、トークン費用、そしてモデルの品質への依存を引き受ける。どちらが優れているという話ではなく、ページ構造が読めるならセレクタ、読めないか頻繁に変わるなら LLM、という切り分けになる。
維持コストとライセンス: 誰が面倒を見るのか
ライセンスは MIT で、商用利用を含めて比較的自由に扱える。ただし MIT は無保証であり、抽出結果の正確性や適法性を作者が担保するものではない。 scraping の適法性は対象サイトの規約と適用される法域の問題で、ライセンス条項とは別に判断する必要がある。維持の面では、依存が Playwright、Streamlit、LLM プロバイダの API と広く、いずれかの破壊的変更がそのまま影響する。README には Windows ネイティブ版を維持しないと明記されており、プラットフォーム対応の優先順位は Docker にある。リリースは取得できておらず、バージョン番号に基づく互換性の判断はできない。README が「BETA」と付けた機能がそのまま残っている点も、安定性より機能追加を優先する姿勢の表れと読める。
編集部の結論
GUI から数クリックで対象サイトのデータを表形式に落とし、CSV や Google Sheets へ渡したい人には向く。逆に、毎日決まった構造のページを大量に処理するバッチや、LLM のトークン費用を予算に固定したい用途には向かない。導入前に確認すべきは 3 点で、Python 3.10 以上が使えるか、OPENAI_API_KEY か GOOGLE_API_KEY を用意できるか、そして Docker 運用なら captcha 回避機能が使えないことを受け入れられるかである。
コミュニティノート