ScrapeGraphAI: LLMに抽出させたい項目を渡すだけでスクレイピングパイプラインを組むPythonライブラリ

ScrapeGraphAIが埋めようとしている穴は何か

従来のスクレイパーは、抽出したい要素のCSSセレクタやXPathを先に確定させる必要がある。サイトのマークアップが変われば、抽出は静かに壊れる。壊れたことに気づくのは、たいてい下流のデータが欠けたときだ。ScrapeGraphAIはこの前提を入れ替える。READMEは「Just say which information you want to extract and the library will do it for you!」と述べており、抽出対象の指定をセレクタではなくプロンプトに移している。想定読者は、ニュース記事や企業サイト、ローカルのXMLやJSONから項目を抜き出したいが、対象サイトごとにパーサを書き分けたくない開発者だ。対象はWebページだけではない。READMEはローカル文書としてXML、HTML、JSON、Markdownを挙げている。

SmartScraperGraphのデータフローとグラフという設計語

中心となるのはSmartScraperGraphで、READMEによれば単一ページからユーザープロンプトとソースURLだけで情報を抽出する。インスタンスにはprompt、source、configの3つを渡し、run()を呼ぶと辞書が返る。READMEの例では、企業概要、創業者、SNSリンクという3種類の異なる構造のデータが、1回の呼び出しで1つの辞書にまとまって返っている。ここが正規表現やBeautifulSoupのループとの決定的な違いだ。抽出ロジックを人間が書くのではなく、プロンプトの意味解釈をLLMに委ね、その結果をキー付きの構造として受け取る。ライブラリ名のgraphは、LLM呼び出しと取得処理をノードとして繋いだパイプラインを指す。READMEが示すパイプラインはSmartScraperGraph以外にも複数あり、SearchGraphは検索エンジンの上位n件の結果をまたいで抽出し、SpeechGraphは抽出結果から音声ファイルを生成する。ScriptCreatorGraphは抽出結果からPythonスクリプトを生成する。単一ページの抽出、複数ページの横断、成果物の生成という3段階の用途が、同じグラフという抽象の上に並んでいる。

インストールと最小構成の設定キー

導入はREADMEの記載どおり、pip install scrapegraphai の後に playwright install を実行する。2つ目は省略できない。READMEは「IMPORTANT (for fetching websites content)」としており、Webページの本文取得はPlaywright側が担う。仮想環境でのインストールが推奨されている。設定はgraph_configという辞書にまとめる。llmキーの下にmodel、model_tokens、formatを置き、トップレベルにverboseとheadlessを置く。READMEのOllama例ではmodelがollama/llama3.2、model_tokensが8192、formatがjson、headlessがFalseになっている。OpenAI系に切り替える場合、READMEはllmの中身だけを変えればよいとしており、api_keyとmodel（例: openai/gpt-4o-mini）を指定する。モデル名がプロバイダ接頭辞付きの文字列である点は見落としやすい。model_tokensはLLMの応答長ではなく、対象ページをどこまでモデルに渡せるかに関わる値として読める。headlessをFalseにするとブラウザが表示された状態で動くため、初回の挙動確認ではこちらが扱いやすい。

LLMが抽出器になることで生まれる失敗モード

最大の制約は、抽出結果がLLMの出力であることだ。READMEの出力例を見ると、創業者の1人目はnameが空文字列のまま、roleとlinkedinだけが埋まっている。これは動作例として載っているものだが、スキーマ上必須のフィールドが欠けうることをそのまま示している。数値や日付を厳密に取りたい用途では、この性質は致命的になりうる。もう1つはコンテキスト長との関係だ。model_tokensは8192という値が例示されているが、対象ページのHTMLが大きければ、その範囲に収まらない部分は抽出対象から落ちる。ページ全体を渡す設計である以上、JSで描画される大量のマークアップや、ナビゲーションだけで数千行あるサイトでは、狙った情報がそもそもモデルに届かない可能性がある。加えて、実行のたびにLLM呼び出しのコストとレイテンシが発生する。同じページを毎時取得して1つの数値だけを監視するような用途では、セレクタを1つ書くほうが安く、速く、確実だ。ScrapeGraphAIが向くのは、抽出項目が多く、DOMの変更頻度が高く、多少の欠損を許容できる、あるいは欠損を検出して再試行できる場面である。

Crawl4AIやFirecrawlと何が違うのか

READMEのトピックにはfirecrawl-alternativeが含まれている。FirecrawlはクロールしてMarkdown化したテキストを返すところまでを主目的に置く。ScrapeGraphAIはその先、返ってきた内容からどのキーに何を入れるかをLLMに決めさせる部分まで踏み込む。抽出スキーマの設計をプロンプトに寄せるか、呼び出し側のコードに寄せるかの違いだ。Crawl4AIも同様に、クロールとMarkdown変換、LLMに渡しやすいクリーンなテキストの生成を軸にする。ScrapeGraphAIはむしろ、取得した内容をどう構造化するかに重心がある。したがって、Markdownさえ手に入れば後段は自前のパイプラインで処理したいなら前者が素直であり、抽出結果を辞書として直接受け取りたいならScrapeGraphAIの出番になる。ただしScrapeGraphAIも内部でPlaywrightを使ってページを取得している以上、取得段階の難しさ（認証、レート制限、ボット対策）が消えるわけではない。

LLMフレームワークとの接続とMCP経由の利用

READMEはLangchain、Llama Index、Crew.ai、Agno、CamelAIとの連携を挙げ、低コード側ではPipedream、Bubble、Zapier、Dify、Toolhouseを列挙している。MCPサーバーも提供されており、MCP対応のクライアントからツールとして呼び出せる。これはつまり、ScrapeGraphAIを単体のライブラリとして使う以外に、既存のエージェント構成の中に抽出ステップとして差し込む使い方が想定されているということだ。注意したいのは、README内のn8nのリンクがlocalhost:5001を指している点で、これは公開ドキュメントとしてそのまま辿れるURLではない。連携先の一覧は広いが、各連携の成熟度はこの資料からは判断できない。採用を検討するなら、自分が使う連携先について別途ドキュメントを確認する必要がある。

MITライセンスとメンテナンスの見え方

ライセンスはMITで、商用利用を含めて制限が少ない。ただしREADMEの冒頭は、より高速でシンプルな方法としてScrapeGraphAI.comのクラウド版へ強く誘導しており、ホームページも同じドメインを指す。OSS版とクラウド版が並走する体制では、機能追加の重心がどちらに置かれるかを意識しておきたい。この資料から読み取れるリリースはv2.2.3、v2.2.4-beta.1、v2.2.4と短期間に並んでおり、betaと安定版が近い間隔で出ている。活発ではあるが、版が細かく動く前提でバージョンを固定して運用するほうが安全だ。アップグレードコストは、graph_configのllmキー周辺の仕様変更と、対応モデル名の変化に集約される可能性が高い。CIで特定バージョンを固定し、更新時にREADMEの設定例と自分のgraph_configを突き合わせる運用が現実的である。

どんなチームが採用し、どんなチームが避けるべきか

採用が向くのは、抽出したい項目が自然言語で説明でき、対象サイトが複数あってセレクタを書き分けるコストのほうが高い案件だ。たとえば企業情報の収集のように、ページごとに構造が違い、多少の欠損を後段で補正できる用途である。逆に避けるべきは、在庫数や価格のように1文字の誤りが許されない値を、大量のページから定期的に取得する案件だ。LLMの出力は確率的で、READMEの出力例自体が空のnameを含んでいる。判断の前に確認すべきは2つある。第一に、対象ページのHTMLがmodel_tokensの範囲に収まるか。第二に、formatをjsonに固定したうえで、欠損キーを検出したときに再試行する仕組みを自分の側に置けるか。この2つに答えが出ないなら、SmartScraperGraphのrun()は期待した辞書を返さない。

編集部の結論

向くのは、対象ページのDOMが頻繁に変わり、抽出項目を自然言語で書き下せる程度に要件が固まっているチームだ。逆に、毎回同一の正確な数値を秒単位で取りたい用途や、LLM呼び出しのコストを固定したい用途には向かない。導入前に確認すべきは、pip install scrapegraphai と playwright install を実行する環境で、選んだモデルのコンテキスト長が対象ページのHTML量に足りるか、そしてgraph_configのllmキーに渡すモデル名が利用中のプロバイダの命名規則に合っているかである。この2点が噛み合わない限り、SmartScraperGraphは空のフィールドや欠けたキーを返し続ける。

公式情報源

1. License: MIT
2. Project website
3. README
4. Releases
5. ScrapeGraphAI/Scrapegraph-ai on GitHub