「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コード）に任せるべき場面

シリーズ記事

第1弾：BS4 vs Scrapling — HTML構造が変わっても要素を自動復元できるか検証した
第2弾：【Pythonスクレイピング】Scrapling vs Scrapy 実測比較 ── 4.4倍速パーサーで組むハイブリッド構成
本記事は第3弾です

この記事の対話版（先輩×後輩の掛け合い形式）もあります

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年のスクレイピングの最適解です。

シリーズ記事

第1弾：BS4 vs Scrapling — HTML構造が変わっても要素を自動復元できるか検証した
第2弾：【Pythonスクレイピング】Scrapling vs Scrapy 実測比較 ── 4.4倍速パーサーで組むハイブリッド構成
第3弾：本記事

この記事の対話版（先輩×後輩の掛け合い形式）もあります
AIスクレイピングの話をもう少しカジュアルにまとめています。