「Claudeにスクレイピングさせたら、もうコード書かなくてよくない？」
結論を先に言います。場面による。
ダミーECサイトで6パターン実測した結果、少量・探索ならClaude、大量・定期実行ならPythonコードという明確な分岐点が見えました。1ページ約3,200トークン消費、1000ページで約330万トークン。サブスク内で使えるが、大量取得は利用上限との戦いです。
この記事では、Claude Cowork と Claude Code+MCP の2つの方法で実際に検証した数値を全て公開します。
この記事でわかること
- Claude Cowork と Claude Code+MCP、2つのAIスクレイピング手法の違い
- 6シナリオの実測データ：単一ページ／ページネーション／構造変更／JS動的／Anti-Bot／大量取得
- トークン消費量の具体的な数値
- Claudeが得意な場面と、従来手法（Pythonコード）に任せるべき場面
この記事の対話版（先輩×後輩の掛け合い形式）もあります
Claudeでスクレイピングする2つの方法
1. Claude Cowork（GUI操作型）
Claude DesktopのCowork機能で、AIがブラウザを人間の代わりに操作する。
- セットアップ: ゼロ。Claude Desktopをインストールするだけ
- 操作: 「このページの商品名と価格を取って」とプロンプトで指示
- 仕組み: 実際のChromeブラウザを操作してページを開き、DOMを読み取る
- 料金: Claude Pro($20/月)〜Max($200/月)のサブスクリプション
2. Claude Code + MCP（API型）
Claude CodeからMCPサーバーを経由してWebページにアクセスする。
- セットアップ: MCPサーバーの設定が必要（約10分）
- 操作: CLIまたはAPI経由。コードの中から呼び出せる
-
MCPツール群:
- WebFetch MCP — URLを指定してHTMLを取得。シンプルだがJS実行不可
- Playwright MCP — ブラウザエンジンでJS実行・動的ページ対応
- scrapling-fetch-mcp — ScraplingのUA偽装＋フィンガープリント回避をMCP経由で利用
- 料金: Max($100〜$200/月)のサブスクリプションに含まれる
2つの違いを一言で言うと
- Cowork = 「AIアシスタントにブラウザ操作をお願いする」
- CC+MCP = 「コードの中からAIを呼び出してデータ取得を依頼する」
Coworkはプログラミング不要で手軽。CC+MCPは自動化に向いている。
検証環境
「実サイトだと条件がバラバラになる」ので、Flask製のダミーECサイトを用意して条件を統一しました。
- 商品数: 30商品（6商品 x 5ページ）
-
v1 / v2 切替: HTMLの構造をガラッと変更（
.product-card→.item-tile等） -
JS動的描画:
/dynamicでsetTimeout(1500ms)後にDOMを追加 -
Anti-Bot:
?bot_check=1でUser-Agentベースのボット検知 - 比較対象: 同じサイトをPythonコード（Scrapling）でも叩いて、結果を横並びで比較
シナリオA：単一ページ取得（6商品）
最もシンプルなケース。1ページから商品名・価格・カテゴリ等を取得します。
| Claude Cowork | Claude Code+MCP | 参考: コード（Scrapling） | |
|---|---|---|---|
| 取得件数 | 6件 | 6件 | 6件 |
| 所要時間 | 手動30秒〜 | 0.032秒 | 0.018秒 |
| トークン消費 | サブスク内 | ~3,200 | $0 |
| 正確性 | 100% | 100% | 100% |
※ Cowork・CC+MCPともサブスク内で追加コストは発生しません。所要時間はローカル処理のみの値で、実際にAPIを叩くと1回2〜5秒くらいかかります。
Claude Code+MCP のトークン内訳
| 項目 | トークン数 |
|---|---|
| 入力（HTML + プロンプト） | 2,564 |
| 出力（JSON結果） | 588 |
| 合計 | 3,152 |
HTMLのサイズが直接トークン消費に効く
1ページのHTMLが約7,200バイト（2,460トークン）。これにプロンプト分が加わって入力2,564トークン。ECサイトの商品一覧はHTMLが比較的軽いためこの程度ですが、重いページだとトークン消費が跳ね上がります。
シナリオB：ページネーション巡回（5ページ30商品）
5ページを順に巡回して、合計30商品を取得します。
| Cowork | CC+MCP | 参考: コード | |
|---|---|---|---|
| 取得件数 | 30件 | 30件 | 30件 |
| 所要時間 | 手動2〜3分 | 0.068秒 | 0.025秒 |
| トークン消費 | サブスク内 | ~16,600 | $0 |
| LLM呼び出し回数 | 5回+ | 5回 | 0回 |
トークン消費が5倍になる理由
CC+MCPでは、ページごとにLLMを呼び出すため、5ページ = 5回の呼び出し = トークン消費も5倍です。
| ページ | 入力トークン | 出力トークン | 合計 |
|---|---|---|---|
| 1/5 | 2,668 | 588 | 3,256 |
| 2/5 | 2,542 | 586 | 3,128 |
| 3/5 | 2,542 | 590 | 3,132 |
| 4/5 | 2,553 | 592 | 3,145 |
| 5/5 | 2,543 | 588 | 3,131 |
| 合計 | 13,742 | 2,897 | 16,639 |
Coworkの場合は「次のページに進んで」と手動で指示する必要があり、5ページで2〜3分かかります。
シナリオC：サイト構造変更（v1 → v2）— Claudeの真価
HTMLの構造が完全に変わった場合の対応力。これがAIスクレイピング最大の強みです。
| Cowork | CC+MCP | 参考: コード | |
|---|---|---|---|
| v1取得 | 6件 | 6件 | 6件 |
| v2取得（同じプロンプト/コード） | 6件 | 6件 | 0件 |
| プロンプト/コードの変更 | 不要 | 不要 | セレクタ書き直し必要 |
| トークン消費（v1+v2合計） | サブスク内 | ~6,300 | $0 |
なぜClaude は構造変更に強いのか
従来のスクレイピングは div.product-card のようなCSSセレクタでHTML要素を指定します。HTMLの構造が article.item-tile に変わればセレクタが壊れて0件になります。
一方、Claudeには同じプロンプトを渡すだけです:
このHTMLから商品データ（名前、価格、カテゴリ、評価、レビュー数、説明）を
抽出してJSON配列で返してください
LLMはHTMLを意味的に理解するので、タグ名やクラス名が変わっても「これが商品名だろう」「これが価格だろう」と推測できます。セレクタの知識がなくても対応できるのが最大のメリットです。
従来手法の対策: Scrapling Adaptive
第1弾の記事で検証した通り、ScraplingのAdaptive機能を使えばv1で保存した「要素の指紋」からv2でも自動復元を試みます。ただしAdaptiveの精度は100%ではなく、大幅な構造変更では失敗することもあります。
一方、LLM方式はプロンプトが同じなら構造変更の程度に関係なく対応できる点が強みです。
シナリオD：JS動的コンテンツ
setTimeout(1500ms) で遅延描画されるページ。SPAやReactアプリで典型的なパターンです。
| Cowork | CC+MCP (WebFetch) | CC+MCP (Playwright MCP) | 参考: コード | |
|---|---|---|---|---|
| 取得件数 | 6件 | 0件 | 6件 | 0件(静的) / 6件(Playwright) |
| JS実行 | ブラウザで自動 | 不可 | 可能 | Playwright必要 |
| トークン消費 | サブスク内 | ~1,600（失敗） | ~3,300 | $0 |
ポイント: WebFetch MCPではJavaScriptが実行されないため、描画前のHTMLしか取得できません。JS描画ページにはPlaywright MCPが必須です。
Coworkは元々ブラウザで操作するので、JS描画のページでも自然に対応できます。
MCPツールの選択がカギ
CC+MCPでは、対象ページの特性に応じてMCPツールを使い分ける必要があります:
シナリオE：Anti-Bot対策
User-Agentベースのボット検知下での動作を確認します。
| MCPツール | User-Agent | ステータス | 取得件数 |
|---|---|---|---|
| WebFetch MCP | httpx/0.27 (WebFetch MCP) |
403 Blocked | 0件 |
| Playwright MCP | ブラウザUA | 200 OK | 6件 |
| scrapling-fetch-mcp | ステルスUA + フィンガープリント回避 | 200 OK | 6件 |
| 参考: curl | curl/7.0 |
403 Blocked | 0件 |
- Cowork: 実際のChromeで操作するため、ボット検知をそもそも受けません（常に200 OK）
-
WebFetch: User-Agentが
httpx/0.27のため、簡単なUA検知にも引っかかります - scrapling-fetch-mcp: ScraplingのUA偽装＋フィンガープリント回避が効いて突破
シナリオF：大量取得は現実的か？
Claudeで1000ページ規模のスクレイピングを回したらどうなるか。
トークン消費の試算
| 規模 | CC+MCP のトークン消費 | 参考: コード |
|---|---|---|
| 1ページ | ~3,300 | $0 |
| 10ページ | ~33,000 | $0 |
| 100ページ | ~33万 | $0 |
| 1000ページ | ~330万 | $0 |
1000ページで約330万トークン消費。 Maxプランのサブスク上限を大きく圧迫します。大量取得を定期実行するなら、Pythonコード（トークン消費ゼロ）が現実的です。
Coworkは大量取得に不向き
Coworkは手動操作のため、自動化・定期実行に向きません。以下の制約があります：
- 1000ページを手動で「次のページ」と指示し続けるのは非現実的
- Proプラン($20/月)には利用回数の上限がある
- cron等のスケジューラとの連携が困難
Claudeスクレイピングのコスト全体像
ここまでの6シナリオを踏まえて、Cowork と CC+MCP のコストを一覧で整理します。
| Cowork | CC+MCP | 参考: コード | |
|---|---|---|---|
| 月額 | Pro $20〜Max $200 | Max $100〜$200 | $0 |
| 1ページあたり | サブスク内 | ~3,300トークン | $0 |
| 1000ページ | 不可能（手動） | ~330万トークン | $0 |
| 自動化 | 不可 | 可能 | 可能（cron等） |
コストの考え方
Cowork・CC+MCPともにサブスク月額のみで追加料金はかかりません。ただしサブスクには利用上限があり、大量取得は上限を圧迫します。Pythonコードなら月額$0・トークン消費ゼロ・利用上限なしです。
いつClaude、いつコード？
Claudeが得意な場面・苦手な場面
得意（Claudeを使うべき場面）
| 場面 | 理由 |
|---|---|
| 初見のサイト調査 | セレクタを知らなくてもHTMLを読んでデータを抽出してくれる |
| プロトタイプ・少量取得 | コードを書く前に「取れるか」を確認。初動が圧倒的に速い |
| 構造変更への即応 | 同じプロンプトでv1もv2も対応。セレクタ書き直し不要 |
| セレクタの探索 | 「この商品名のCSSセレクタは？」と聞けば教えてくれる |
苦手（コードで書くべき場面）
| 場面 | 理由 |
|---|---|
| 定期実行（毎日cron） | 毎回LLMを呼ぶとトークン消費が積み重なる |
| 大量取得（100ページ以上） | 100ページで~33万トークン。サブスク上限を圧迫 |
| 処理速度が重要 | 実際のAPI呼び出しは1回2〜5秒。コードの0.018秒/ページとは桁違い |
| 出力の完全再現性 | LLMの出力は毎回微妙に異なる可能性がある |
得意・苦手がこれだけ明確に分かれるなら、両方の強みを組み合わせるのが合理的です。
おすすめの使い方: AIとコードのハイブリッド
「探索はClaude、実行はコード」。この使い分けが、AIの手軽さとコードのコスト効率を両立する最適解です。
まとめ
| 評価軸 | Cowork | CC+MCP | コード |
|---|---|---|---|
| 手軽さ | ★★★★★ | ★★★★ | ★★★ |
| 正確性 | ★★★★★ | ★★★★★ | ★★★★★ |
| 耐変更性 | ★★★★★ | ★★★★★ | ★★ |
| コスト効率 | ★★ | ★★★ | ★★★★★ |
| スケーラビリティ | ★ | ★★★★ | ★★★★★ |
Claudeのスクレイピング能力は本物です。特に構造変更への対応力は、セレクタベースの従来手法にはない大きな強みです。
一方で、コストとスケーラビリティの制約も明確。「Claudeがあればコードは不要」ではなく、「Claudeがあるからこそコードの価値が活きる」——探索はAIに任せて、人間はコードを書くことに集中する。それが2026年のスクレイピングの最適解です。
この記事の対話版（先輩×後輩の掛け合い形式）もあります
AIスクレイピングの話をもう少しカジュアルにまとめています。