Claude CodeでJSサイトをJSON取得：最適スクレイピングAPI
Claude CodeからJavaScriptで描画されるサイトのデータをJSONで取得する場合、適したスクレイピングAPIは「JSONをどこまで返してくれるか」と「ブロック耐性を誰が担うか」の2点で決まります。レンダリング機能の有無だけでは選べません。多くのAPIがヘッドレスブラウザを備えているためです。
Claude Codeは、そのままではオープンウェブを十分に読めません。SPA(React、Vue、Next.jsなど)は初期HTMLがほぼ空で、遅延ロードされたデータはブラウザがスクリプトを実行して初めてDOMに現れます。単純なHTTP fetchでは目的のデータに届かないため、レンダリング済みの結果を返す外部APIか、MCPサーバー経由のブラウザ制御が必要です。
この記事では、スクレイピングAPIを返却形式で3タイプに分け、Claude Code側のJSON設計とトラブル対処までを整理します。
JavaScriptレンダリング、構造化抽出、JSON Schemaの違い
3つの用語は混同されやすいため、先に定義します。
- JavaScriptレンダリング: ヘッドレスChromiumなどでページのスクリプトを実行し、描画後のDOMを得る処理です。実用上の論点は待機戦略(特定セレクタの出現待ち、ネットワークアイドル待ち、固定待機)です。
- 構造化抽出: ルールまたはLLMでフィールドを特定し、型付きJSONとして返す処理です。
- JSON Schema: 返却JSONが満たすべき型・必須項目を定義する契約です。Claude Codeに渡す前の検証基準になります。
詳しい背景は、Bright DataのJavaScriptレンダリングの用語解説も参考になります。
JSONをそのまま返すAPIとDOMから整形するAPIの選び分け
候補は返却形式で次の3タイプに分かれます。
| タイプ | 返すもの | 代表例 | JSON化の責務 |
|---|---|---|---|
| A | スキーマ適合または自動抽出済みJSON | Firecrawl、Zyte API | API側 |
| B | レンダリング後のDOM/セレクタ抽出結果 | Browserless | 自前 |
| C | レンダリング済みHTML中心 | ScrapingBee(render_js) | 自前(または別途AI抽出) |
フィールドが多く、サイトごとにセレクタを書きたくないならタイプAが近道です。DOMの挙動を完全に制御し、自社モデルへ確定的にマッピングしたいならタイプBかCが向きます。
Firecrawl: スキーマ付きJSONを最短で得たい場合
Firecrawlは公式ページで、各スクレイプを実際のChromiumインスタンスで実行し、React、Vue、Next.jsなどのJavaScript多用サイトに対応すると明記しています。Docsの/scrapeではformatsとしてMarkdownや構造化データ(JSON)を扱えます。JSON Schemaやプロンプトを渡して抽出させる設計です。
留意点はコストです。Billingのドキュメントには「JSON format (LLM extraction)」で1ページあたり+4クレジットと記載されています。大量ページを処理する場合は、この加算を見積もりに入れてください。
Zyte API: 型が決まったデータを自動抽出したい場合
Zyte APIの主要エンドポイントはhttps://api.zyte.com/v1/extract(POST)で、browserHtmlをtrueにするとJavaScriptレンダリング済みHTMLを取得できます。加えて、product、article、jobPosting、serp、pageContentなどのデータタイプを指定する自動抽出が使えます。EC商品や求人のように対象が定型なら、セレクタ設計を省けます。
Browserless: DOMを自前でJSON化したい場合
Browserlessの/scrape APIは、ヘッドレスブラウザでJavaScriptを描画し、指定したCSSセレクタに基づいて要素を抽出します。エンドポイントはPOST https://production-sfo.browserless.io/scrape?token=YOUR_API_TOKENの形式です。返るのは要素単位の結果なので、自社のJSON Schemaへのマッピングは自分で書きます。抽出ロジックがブラックボックスにならない点が利点です。
ScrapingBee: render_jsで取得し、整形は後段に回す場合
ScrapingBeeはrender_jsパラメータでJavaScript実行を有効化する設計です。中心はレンダリング済みHTMLの取得なので、Cheerio相当のパースか、Claude Codeによる再整形を前提にします。「JSONがネイティブに返る」とは想定しないほうが安全です。
Bright Dataはブロック耐性とJSレンダリングを同じ基盤で担う
ここまでのAPIは抽出形式の違いが主題でした。もう一つの軸であるブロック耐性は、本番運用で失敗の主因になります。
Bright Dataは、公開ウェブの発見、アクセス、抽出、対話を一体で提供するWebデータ基盤です。Browser API Pricingページには、Built-in Website Unlocking、CAPTCHA Solving & JS Rendering、Automated Proxy Managementが価格に含まれると記載されています。Puppeteer、Playwright、Seleniumに対応し、Free Tierは月5Kクレジットです。表示価格はUSD建てで、請求は取引時の為替レートで換算されます。
Browser APIはPlaywrightやPuppeteerのコードをそのまま接続できるため、タイプBに近い「DOMを自分で制御する」構成を、CAPTCHAやIPブロックの対処込みで組めます。事前構築済みのScraper APIや、サイト全体を扱うCrawling APIを使えば、抽出済みデータの取得にも寄せられます。
Claude Code側の接続は、MCPが現実的です。Claude向けのBright Data MCPサーバーを使えば、Claude Codeがエージェントとして検索、クロール、ブラウザ操作を呼び出せます。設定例はClaude Code向けMCPサーバーの比較記事で確認できます。
JSON Schema検証とフォールバックで契約を固定する
どのAPIを選んでも、Claude Codeに渡す前にJSONを契約として固定します。流れは次のとおりです。
- JSON Schemaを定義する(必須項目、型、enum、価格などの数値範囲)。
- APIの返却を受け取り、Ajv(Node)やjsonschema(Python)で検証する。
- 不一致なら、抽出範囲を縮小して再試行する。
- それでも失敗する場合は、HTMLまたはテキストを併せて取得し、Claude Codeで再整形するか、セレクタ抽出に切り替える。
- 検証済みJSONのみを推論の根拠にする。
待機戦略も契約の一部です。タイムアウト、遅延ロードへの待機条件、無限スクロールの打ち切り条件を明示してください。
よくある失敗と対処
レンダリングしても要素が取れない。 待機条件が合っていない、またはクリックやスクロールが必要なケースが大半です。セレクタ出現待ちに切り替え、actionsや自動操作で展開してください。
CAPTCHAやブロックで失敗する。 単純なレンダリングAPIでは対処できません。アンロック機能とプロキシ管理を内包するサービスを選ぶか、再試行とIPローテーションを自前で設計します。
JSONがスキーマに合わない。 検証を必ず挟み、項目数を減らして再抽出します。LLM抽出は出力が揺れるため、必須項目を絞るのが有効です。
無限スクロールやページネーションがある。 1回の呼び出しで完結させず、ページ単位のループかCrawling API系の機能で分割します。
要件の4点を固めてからPoCに進む
選定を整理すると、次のとおりです。
- Firecrawl、Zyteは、スキーマ付きまたは型付きJSONを得やすいタイプです。
- Browserless、ScrapingBeeは、DOMやHTMLの取得に強く、JSON化は自前になります。
- Bright Dataは、アンロック、JSレンダリング、ブラウザ制御、クロールを同一基盤で担えるため、ブロックが頻発するサイトや、エージェント運用で安定性を重視する場合に向きます。
PoCの前に、(1)必要フィールド数、(2)ログインの有無、(3)待機が必要な動的UIの有無、(4)1ページあたりのクレジット許容量を決めてください。これらが決まれば、5〜10ページ程度の検証でAPIタイプの優劣は判断できます。