「gemini web scraping」で検索して並ぶ記事を、いくつか開いてみてください。想定読者はほぼ決まっています。仮想環境はとっくに用意済み、Pydantic のスキーマも書き慣れ、async ライブラリの好みまである Python 開発者。そのタイプなら、コードから読み進めて支障ありません。ただ、markdownify の役割を学ぶ気はないけれど構造化データだけは取り出したい、という営業・マーケティング・EC運用の担当者も大勢います。後者は少数派ではないのです。
Gemini は Google のマルチモーダル AI ファミリーで、Web データ抽出の手段として一気に存在感を増しています。2025 年の Stack Overflow Developer Survey によれば、開発者の 84% が AI ツールを使っているか使う予定だと答えており、LLM を使ったスクレイピングはこの潮流の一部です。注意したいのは、「URL を 1 本入れれば動くデモ」と「ページネーション・サブページ・ボット対策・崩れた HTML を本番で安定してさばく仕組み」がまるで別物だという点です。本記事では Python とノーコード、両方の手順を解説します。実際のトークン計算でモデル選定の目安を示し、他の記事が手薄な複数ページのスクレイピングまで踏み込み、Gemini がどこで通用しなくなるかも率直に書きます。読み終えるころには、自分の業務にどの道が向くか、そして開発者にもビジネスユーザーにも待つ罠をどう回避するかが見えているはずです。
Gemini Web Scraping とは？
Gemini web scraping とは、Webページの中身——HTML、Markdown、あるいはスクリーンショット——を Google の Gemini AI モデルに渡し、ページを読み解いて構造化データの形で返してもらう手法です。CSS セレクタも XPath も、サイトがレイアウトをちょっといじっただけで壊れる脆いルールも、書く必要がありません。
基本となる流れは、次の 4 ステップです。
- ページを取得する（
requests、ヘッドレスブラウザ、Chrome 拡張などを使用） - 内容を整形して変換する（通常は HTML → Markdown にしてトークンコストを削減）
- 抽出したい項目を示すスキーマと一緒に Gemini に送る
- 構造化された JSON を受け取る — スプレッドシート、CRM、データベースにそのまま使える形で
これを、BeautifulSoup や Selenium に頼る従来型のスクレイピングと比べてみましょう。従来型では、div.product-title > span.price のようなセレクタを一つずつ手で書き、来週サイトがデザインを変えないことをひたすら祈ることになります。対する Gemini は、人間がページを眺めるようにして文脈をくみ取り、レイアウト変更にもある程度ついていき、複雑で崩れた書式すらカスタムルールなしで処理します。
もう一つ見落とせないのが、Gemini が設計段階からマルチモーダルだという点です。テキスト、画像、動画、音声、PDF、コードを一回のリクエストでまとめて扱えます。だからこそ、HTML の代わりにスクリーンショットを送るような、他の多くの LLM では難しい抽出方法も成立します。この点は後半で扱います。
なぜ Gemini Web Scraping はビジネスチームに重要なのか
マーケティングマネージャーや EC アナリストが、なぜ LLM や Web スクレイピングに目を向けるべきなのか。理由は突き詰めればシンプルです。時間が大幅に浮くうえに、サイトが更新されるたびに壊れる心配が小さいから——この 2 点に尽きます。
Web スクレイピングソフトウェア市場は 2025 年の約 10 億ドルから、2030 年には 20 億ドル超へ拡大すると見込まれており、なかでも AI 駆動の抽出は最も成長が速い領域です。これは一過性のブームではなく、各チームのデータの集め方そのものが変わりつつある、という証拠と読むべきでしょう。
Gemini を使ったスクレイピングが、日々の業務にどう効いてくるのか。代表的なユースケースを整理すると、こうなります。
| ユースケース | 抽出する内容 | 恩恵を受ける人 |
|---|---|---|
| リード獲得 | ディレクトリ、LinkedIn（公開情報）、企業サイトの連絡先情報 | 営業、BDR |
| 競合価格の監視 | 商品価格、在庫状況、キャンペーン情報 | EC、価格戦略チーム |
| 商品カタログ抽出 | 商品名、仕様、画像、レビュー | 商品企画、マーケットプレイス運用 |
| 不動産掲載情報 | 物件詳細、価格、担当者情報 | 不動産営業、投資家 |
| コンテンツ収集 | ニュース、ブログ記事、SNS の言及 | マーケティング、PR |
| 求人市場調査 | 職種名、給与、勤務地 | 人事、採用 |
実務での旨味は大きく 2 つです。まず、解析スクリプトを書いては直しテストしてデバッグする堂々巡りから解放されること。ページはモデルが毎回その場で読み直します。次に、サイトが <div> をわずかに動かすたびに開発者を呼ぶ必要がなくなること。Gemini には無料枠もあり、小規模なら ほぼゼロコストで試せます。Flash-Lite で 1 日約 1,000 リクエスト、Pro で約 100 リクエスト まで、クレジットカードすら不要です。
どの Gemini モデルを選ぶべき？（Flash Lite / Flash / Pro）
スクレイピングという観点では、Gemini の各モデルは横並びではありません。多くの解説記事に欠けていたのが、まさにこの実用的な比較です。モデル選びを誤ると、余計な出費を抱えるか、あてにならないデータをつかまされるか、どちらかに陥ります。
現行の Gemini 2.5 系 3 モデルは、いずれも 1,048,576 トークンのコンテキストウィンドウを備え、マルチモーダルに対応しています。差が出るのは、コスト・速度・複雑な抽出への強さの 3 点です。
| モデル | 入力コスト（100万トークンあたり） | 出力コスト（100万トークンあたり） | 向いている用途 | 複雑なスキーマでの精度 | 速度 |
|---|---|---|---|---|---|
| Gemini 2.5 Flash Lite | 約 $0.025 | 約 $0.10 | シンプルで平坦なデータ、大量処理 | ⚠️ 入れ子や任意項目が苦手 | 最速 |
| Gemini 2.5 Flash | 約 $0.075 | 約 $0.625 | ほとんどのスクレイピング | ✅ 構造化抽出に十分強い | 速い |
| Gemini 2.5 Pro | 約 $0.3125 | 約 $2.50 | 複雑な入れ子スキーマ、例外ケース | ✅ 最も高精度 | 最も遅い |
(価格は Gemini Developer API に基づきます。Batch API はこれらの料金から 50% 割引です。)
Gemini 2.5 Flash Lite: 速くて安いが、欠損に注意
Flash Lite は、とにかくコストを抑えたい場面の選択肢です。商品名や価格、一段だけの一覧情報といった、平坦でシンプルなデータを大量にさばくのに向いています。ただし弱点もあり、任意項目、タイムスタンプ、入れ子データでつまずく報告が出ています。Google のフォーラムでは、ある開発者が Flash Lite は スキーマに必須でないプロパティが混じると「暴走する」と書き込んでおり、トークン上限まで同じ一文を吐き続けることがあるそうです。スキーマが 2 段以上の入れ子を含む場合や、ページで項目の有無が変わる場合、Flash Lite はトークンと気力の両方を削ってきます。
Gemini 2.5 Flash: ほとんどのスクレイピングで最適バランス
実務のスクレイピングで最初に手を伸ばすべきは、Flash です。構造化抽出に強く、ページネーションも難なくこなします。入力コストは Flash Lite の約 3 倍ですが、得られる精度を考えれば十分に見合う差です。GPQA レベルの推論ベンチマーク でも Flash は Pro に肉薄するスコアを出しており、スクレイピングで必要な推論・正規化・平坦化を一通りさばけます。
Gemini 2.5 Pro: 複雑データ向けの最高精度モデル
Pro は精密さが問われる仕事のためのモデルです。サイズ・色・価格のバリエーションが何通りもある商品仕様のような深い入れ子スキーマを扱うとき、あるいは誤りが一切許されないとき（法務・金融・医療データなど）に投入します。入力コストは Flash Lite の約 12 倍なので、価格より精度が優先される案件に絞るのが賢明です。
コスト試算: 商品ページ 10,000 件を処理する場合
HTML を Markdown に前処理する前提（これは実際にそうすべきで、後ほど詳述します）なら、典型的な商品ページは生 HTML の約 20,000 トークンから、Markdown で約 4,000 トークンまで圧縮できます。出力 JSON は 1 ページあたり約 500 トークンです。
| モデル | 入力コスト（4,000万トークン） | 出力コスト（500万トークン） | 10,000 ページの合計 |
|---|---|---|---|
| Flash Lite | $1.00 | $0.50 | 約 $1.50 |
| Flash | $3.00 | $3.13 | 約 $6.13 |
| Pro | $12.50 | $12.50 | 約 $25.00 |
Markdown 前処理を省くと（生 HTML だと入力が約 2 億トークンに膨らむ想定）、これらの金額は一気に 4〜5 倍へ跳ね上がります。つまり前処理こそ、パイプライン全体で最も費用対効果の高い一手なのです。
コードとノーコード: Gemini Web Scraping の 2 つの道
ここが分岐点です。自前でパイプラインを設計する開発者なら、Python + Gemini API で自由度を最大化できます。逆に、ターミナルに触れず今すぐデータがほしいビジネスユーザーなら、ノーコードの AI スクレイパーのほうが早くゴールに着きます。
| 比較項目 | Gemini API（Python） | Thunderbit（ノーコード） |
|---|---|---|
| 準備時間 | 15〜30 分（環境、キー、ライブラリ） | 1 分未満（Chrome 拡張を入れるだけ） |
| コーディングの必要性 | あり（Python、Pydantic） | なし |
| ページネーション対応 | 手動で実装 | 標準搭載（クリック型・無限スクロール両対応） |
| サブページの追加抽出 | サイトごとのカスタムコード | 「サブページをスクレイプ」を 1 クリック |
| トークンコスト管理 | 手動（HTML 整形、モデル選択） | AI エンジン側で処理 |
| エクスポート先 | スクリプト経由で JSON/CSV | Excel、Google Sheets、Airtable、Notion |
| 最適な人 | カスタムパイプラインを作る開発者 | 今すぐデータが必要なビジネスユーザー |
Thunderbit は、そのノーコードの選択肢です。裏側で Gemini、ChatGPT、Claude などを使い分け、列の提案から 2 クリックでの抽出、好きなツールへのエクスポートまでこなす Chrome 拡張です。この後、両方のやり方を順に見ていきます。
スプレッドシート派なら、Quadratic も覚えておいて損はありません。シート内で Gemini を使った Web スクレイピングができる AI スプレッドシートです。ただし、商品一覧やディレクトリ、リードデータベースのように「すでにわかっている Webページ」を起点にする業務では、Thunderbit のほうがユーザーの頭の動きに馴染みます。
手順で解説: Python を使った Gemini Web Scraping
ここからは開発者向けの内容です。ノーコードで進めたい方は、この章は飛ばしてかまいません。
始める前に:
- 難易度: 中級（Python の基本知識が必要）
- 所要時間: 初回の抽出まで約 20〜30 分
- 必要なもの: Python 3.10 以上、Google AI Studio アカウント（無料）、対象 URL
ステップ 1: Python 環境と Gemini API キーを準備する
最初に、プロジェクトフォルダと仮想環境をこしらえ、必要なライブラリを入れます。
mkdir gemini-scraper && cd gemini-scraper
python -m venv venv && source venv/bin/activate
pip install -U google-genai requests beautifulsoup4 markdownify pydantic
重要: 2026 年の時点で使うべき SDK は google-genai だけです。旧パッケージの google-generativeai は 2025-11-30 をもって終了し、すでに非推奨になっています。チュートリアルに import google.generativeai as genai と書いてあれば、それは古い記事だと判断してください。
続いて、Google AI Studio で API キーを発行します。"Get API Key" を押して新しいキーを作り、環境変数として保存します。
export GEMINI_API_KEY="your-key-here"
これで、依存関係も API キーもそろった Python 環境のできあがりです。
ステップ 2: 対象ページの HTML を取得する
requests でページを引っ張ってきます。ここでは商品ページを抽出する例で進めましょう。
import requests
url = "https://example.com/product/widget-pro"
response = requests.get(url, headers={"User-Agent": "Mozilla/5.0"}, timeout=30)
html = response.text
サイトが JavaScript で重くレンダリングしていたり、ボット対策がきつかったりすると、requests.get() は空の HTML や 403 を返すことがあります。その対処は制限の章で扱いますが、公開サイトの多くはこれだけで問題なく動きます。
ステップ 3: HTML を整えて Markdown に変換する
多くの記事が触れてはいるのに、数字で示さないのがこの工程です。典型的な商品ページの生 HTML は約 20,000 トークンにも達します。BeautifulSoup で不要部分を削いで Markdown 化すると約 765〜4,000 トークンまで落ち、5〜10 倍の削減 が実現します。実コストの圧縮と誤認識の抑制、その両方に直結します。
from bs4 import BeautifulSoup
from markdownify import markdownify
soup = BeautifulSoup(html, "html.parser")
main = soup.select_one("main") or soup # 本文エリアだけを取得
markdown_content = markdownify(str(main))
select_one("main") を挟むと、ヘッダー・フッター・ナビゲーション・スクリプトといった、トークンを浪費してモデルを惑わせるノイズをまとめて落とせます。サイトに <main> タグがなければ、.product-detail、#content、あるいは実データを包んでいる要素を順に試してください。
ここまで来れば、ページの意味のある中身だけが詰まった、きれいな Markdown 文字列が手に入ります。
ステップ 4: データスキーマを定義して Gemini に送る
返してほしい形を、Pydantic で定義します。google-genai SDK は、response_schema に Pydantic の BaseModel をそのまま渡せる仕様です。
from google import genai
from google.genai import types
from pydantic import BaseModel
class Product(BaseModel):
name: str
price: str
sku: str | None = None
description: str
sizes: list[str] = []
colors: list[str] = []
client = genai.Client() # GEMINI_API_KEY を環境変数から読み込む
response = client.models.generate_content(
model="gemini-2.5-flash",
contents=f"このページから商品情報を抽出してください:\n\n{markdown_content}",
config=types.GenerateContentConfig(
response_mime_type="application/json",
response_schema=Product,
),
)
product = response.parsed
print(product)
既知のバグ一覧 を踏まえると、注意すべき点がいくつかあります。
- Gemini に渡すスキーマでは
Field(default=...)を使わない こと。API がValueErrorを返します。代わりに、型レベルでsku: str | None = Noneと書きます。 - 入れ子は浅めに（最大 3 階層まで） 保つのが無難です。深すぎるスキーマは、Flash と Flash Lite で再帰的な出力や閉じ忘れの括弧を招きます。
- Flash Lite を使うなら、必須項目をはっきり指定し、欠損時は空文字などの代替値を充てる ほうが安全です。Flash Lite の任意フィールド処理は 安定していません。
これで、ページから構造化データを抱えた Product オブジェクトが得られます。
ステップ 5: 抽出したデータを保存・出力する
結果を JSON、あるいは CSV で書き出します。
import json
with open("products.json", "w") as f:
json.dump(product.model_dump(), f, indent=2)
Google Sheets へ流すなら gspread が便利です。データベースに入れるなら、使っている ORM に合わせてシリアライズしてください。Gemini の構造化出力は、たいていの下流ツールへそのまま渡せるくらい整っています。
手順で解説: コードなしで Gemini Web Scraping を行う方法（Thunderbit を使用）
こちらはビジネスユーザー向け、あるいは使い捨てのスクレイピングスクリプトをわざわざ書きたくない開発者向けの章です。
始める前に:
- 難易度: 初級
- 所要時間: 初回の抽出まで約 5 分
- 必要なもの: Chrome ブラウザ、Thunderbit 拡張機能（無料枠あり）
ステップ 1: Thunderbit の Chrome 拡張をインストールする
Chrome ウェブストア を開いて「Chrome に追加」をクリックします。あとはメールアドレスで登録するだけで、ここまで 1 分とかかりません。先ほどの Python の 15〜30 分のセットアップと、ぜひ見比べてみてください。
ステップ 2: 対象ページを開いて「AI Suggest Fields」をクリックする
スクレイピングしたいサイトを開きます。商品一覧でも、不動産ディレクトリでも、リードデータベースでも、何でも構いません。ブラウザのツールバーにある Thunderbit アイコンを押し、「AI Suggest Fields」 をクリックします。
すると Thunderbit の AI がページを読み取り、列名とデータ型を自動で提案します。たとえば「Product Name」「Price」「Rating」「Image URL」といった具合です。列名を整えたり、不要な項目を消したり、列ごとにカスタム AI プロンプトを足したりもできます（例:「High/Medium/Low で分類」「英語に翻訳」など）。
しかも、1 行も抽出する前に、設定した列をテーブルのプレビューで確認できます。
ステップ 3: 「Scrape」をクリックして結果を確認する
あとはワンクリックです。Thunderbit がページネーション（「次へ」ボタン式も、無限スクロール式も）を処理し、データを構造化テーブルへ落とし込みます。取得方法は次の 2 つから選べます。
- クラウドスクレイピング: 速く、最大 50 ページを並行処理できます。公開サイト向きです。
- ブラウザスクレイピング: ログイン済みのブラウザタブの中で動きます。認証が要るサイト（CRM、会員制ディレクトリ、社内ツールなど）に使います。
結果は拡張機能のサイドバーにテーブル形式で並びます。エクスポートの前に、明らかな取りこぼしがないか目を通しておきましょう。
ステップ 4: Excel、Google Sheets、Airtable、Notion にエクスポートする
エクスポートボタンを押して形式を選ぶだけです。Thunderbit は Excel、Google Sheets、Airtable、Notion へ無料で書き出せます。画像フィールドは Notion や Airtable の画像ライブラリへ直接アップロードされるので、商品写真や顔写真を扱うときにも重宝します。
JSON のパースも、スクリプトも要りません。データはそのまま使える状態です。
Gemini を使った複数ページ・サブページのスクレイピング
ほとんどの記事は、1 つの URL を処理したところで筆を置きます。けれど、現場のスクレイピング業務はそこで終わりません。
ページネーション付きの商品 500 ページや、詳細サブページを抱えたデータを抜き出すのは、それ自体がひとつの仕事です。単一 URL のデモと現実の業務との間には、それくらい大きな隔たりがあります。
Gemini API でページネーションを扱う（コード編）
ページ番号付きの URL があるなら、空の結果が返ってくるまでループを回します。これがいちばん典型的なパターンです。
import time
all_products = []
for page in range(1, 101): # 最大 100 ページ
url = f"https://example.com/products?page={page}"
md = fetch_clean(url) # 先ほどの HTML→Markdown 関数
response = client.models.generate_content(
model="gemini-2.5-flash-lite", # 一覧ページなら低コストで十分
contents=f"商品名と URL を抽出してください:\n\n{md}",
config=types.GenerateContentConfig(
response_mime_type="application/json",
response_schema=list[ListingItem],
),
)
items = response.parsed
if not items:
break
all_products.extend(items)
time.sleep(4) # 無料枠のレート制限に配慮
カーソルベースや無限スクロールのサイトでは、フロントエンドが叩いている XHR エンドポイントをブラウザの Network タブで突き止め、そのエンドポイントを直接ループするのが定石です。再レンダリングより安上がりで、LLM の出番は項目のクリーニングが必要なときだけに絞れます。
ここでもトークンコストは油断できません。ページが増えれば、その分だけ請求もかさみます。単純な一覧ページには Flash Lite を、詳細抽出にだけ Flash を充てる——この使い分けが効きます。
サブページをスクレイピングして、よりリッチなデータを取得する（コード編）
おなじみの 2 段階パターンです。ステージ 1 で一覧ページから URL を拾い、ステージ 2 で各詳細ページを訪ねて、より細かいデータを取りに行きます。
# ステージ 1: 安価な Flash Lite で URL を収集
class Listing(BaseModel):
product_urls: list[str]
listing = client.models.generate_content(
model="gemini-2.5-flash-lite",
contents=f"商品 URL を抽出してください:\n{listing_md}",
config=types.GenerateContentConfig(
response_mime_type="application/json",
response_schema=Listing,
),
).parsed
# ステージ 2: Flash で詳細を抽出
class ProductDetail(BaseModel):
name: str
price: str
specs: dict[str, str]
reviews: list[str]
for url in listing.product_urls:
md = fetch_clean(url)
detail = client.models.generate_content(
model="gemini-2.5-flash",
contents=f"商品詳細を抽出してください:\n{md}",
config=types.GenerateContentConfig(
response_mime_type="application/json",
response_schema=ProductDetail,
),
).parsed
# detail を保存...
time.sleep(0.5)
動くことは動きます。ただし、URL の重複排除、エラー処理、レート制御、リトライのロジック、そしてスキーマを変えるたびに取り直さずに済む HTML キャッシュなど、周りを固める処理がそれなりに要ります。50 ページなら何とかなっても、5,000 ページともなると、もはやインフラを組む作業に近づいてきます。
ノーコードの代替: Thunderbit のページネーション・サブページ抽出機能
Thunderbit は、クリック型も無限スクロール型も自動でさばきます。ループのコードは不要です。サブページの追加抽出では、「サブページをスクレイプ」機能が一覧の各リンク先を巡り、元のテーブルへより深い項目を継ぎ足してくれます。スクリプト 1 本ではなく、1 クリックで済むのです。
クラウドスクレイピングなら最大 50 ページを並行処理できるため、商品カタログや不動産ディレクトリを大規模に扱う場面では差がはっきり出ます。Python のループやリトライを自分で面倒見たくない人にとって、これはかなり現実的な選択肢です。（Web サイトから Excel にデータを抽出する方法 は別記事でも解説しています。）
スクリーンショットスクレイピング: Gemini のマルチモーダルな近道
ほぼどの記事もまるごと飛ばすのが、生 HTML の代わりに Webページの スクリーンショット を Gemini の vision API へ送る方法です。ある開発者は、スクリーンショット 1 枚で約 258 トークンしかかからないと 報告しています。整形済み Markdown でさえ数千トークンを要することを思えば破格の差で、単純な抽出ならコスト面でかなりの威力を発揮します。
Gemini の Vision API を Web Scraping に使う方法
Playwright でスクリーンショットを撮り、エンコードして Gemini に渡します。
from playwright.sync_api import sync_playwright
from google import genai
from google.genai import types
from pydantic import BaseModel
class Product(BaseModel):
title: str
price: str
with sync_playwright() as p:
page = p.chromium.launch().new_page()
page.goto("https://example.com/product/widget-pro")
page.wait_for_load_state("networkidle")
png_bytes = page.screenshot(full_page=False) # 画面上部だけ
client = genai.Client()
resp = client.models.generate_content(
model="gemini-2.5-flash",
contents=[
{"inline_data": {"mime_type": "image/png", "data": png_bytes}},
"商品タイトルと価格を JSON で抽出してください。",
],
config=types.GenerateContentConfig(
response_mime_type="application/json",
response_schema=Product,
),
)
print(resp.parsed)
Google の 画像トークンに関するドキュメント によれば、縦横ともに 384 ピクセル以下の画像は 258 トークンで処理されます。それより大きい画像は 768×768 のチャンクに分割され、チャンクごとに 258 トークンです。画面上部だけの短いスクリーンショットなら 258〜1,600 トークン程度に収まりますが、極端に縦長のフルページスクリーンショットは約 5,000 トークンに達し、きれいな Markdown（約 765〜1,200 トークン）に見劣りすることもあります。
スクリーンショットスクレイピングの限界
- 密度の高い表では精度が落ちやすい: 複数列のレイアウト、小さなフォント、重なった要素では、丸ごと誤認識するというより「一部のラベルが読めない」「見出しの対応がずれる」といった崩れ方をしがちです。
- リンクをたどれない: Vision が返すのはテキストだけで、クリックできるアンカーは返ってきません。ページネーションもサブページ抽出も不可能です。
- 解像度の上限: 約 10 px を下回る文字は誤読されやすくなります。Google は長辺を約 1,568 px まで縮小します。
- 取得オーバーヘッドがある: Playwright の起動と
networkidleの待機だけで 1 ページあたり 2〜5 秒。件数が増えれば、この積み重ねが効いてきます。
スクリーンショットスクレイピングが本領を発揮するのは、JavaScript が重いページ、ボット対策が固いサイト（requests.get() だと 403 なのにブラウザでは見られるケース）、そしてグラフや画像の中にデータが埋め込まれたページです。文章量の多い長文ページでは、やはり Markdown に軍配が上がります。
Thunderbit の画像・PDF スクレイピングも、これと同じ AI 画像認識のアプローチを採っています。画像や PDF を放り込めば構造化テーブルが返ってくるので、スクリーンショットのスクリプトや base64 の煩わしい処理とは無縁です。（あわせて 画像を Excel に変換する方法 もどうぞ。）
Gemini Web Scraping が失敗するケースと、その代替策
Gemini は「抽出エンジン」であって、「取得エンジン」ではありません。ページの中身を Gemini まで届けられなければ、当然ながら何もできないのです。
このやり方が破綻する典型例はいくつかありますが、たいていの記事はさらりと流すだけです。ここでは正面から書きます。
| 制限 | 何が起こるか | 対処法 |
|---|---|---|---|
| ボット対策 / Cloudflare | API リクエストがブロックされる。requests.get() は 403 かチャレンジページを返す | TLS フィンガープリントをローテーションするプロキシを使う、またはブラウザベースのツールを使う（Thunderbit のブラウザスクレイピングはログインセッションをそのまま利用） |
| トークンウィンドウの制限 | 大きなページは実用的な文脈長を超える（理論上は 100 万トークンでも、安定抽出には約 20〜30 万トークンが現実的） | HTML→Markdown の整理、ページ分割、またはスクリーンショット活用 |
| 画像コンテンツでのハルシネーション | Gemini が実際の画像ではなく alt テキストやキャプションから推測してしまう | 出力を検証する、画像データには vision API を明示的に使う、grounding バリデータを追加する |
| API レート制限 | 大量処理で制限される。無料枠は Pro で 1 日約 100、Flash Lite で約 1,000 リクエスト | キュー管理、バッチ処理（50% 割引）、または既成ツールに切り替える |
| 抽出の不安定さ（Lite モデル） | 任意項目、タイムスタンプ、入れ子データが抜けたり、作られたりする | Flash/Pro に上げる、またはスキーマ制約を強める |
| 保護されたサイト（LinkedIn など） | エラーか空データが返る | アクティブなログインセッションでのブラウザスクレイピングを使う（Thunderbit は対応）；利用規約を守る |
このうちいくつかは、もう少し補足しておきます。
ボット対策は、いまや LLM まで視野に入れています。 2025 年 7 月時点で Cloudflare は AI クローラーをデフォルトでブロック しており、最初の 5 か月で 4,160 億件の AI ボットリクエストを遮断したと伝えられています。Datadome も 2025 年に LLM 特化の検知を追加し、LLM ボットのトラフィックが 4 倍に増えたと報告しました。Datadome で守られたサイトに、単純な requests.get() + Gemini ではまず歯が立ちません。鍵は IP ではなくフィンガープリント。TLS フィンガープリントが「Python requests」だと丸わかりなら、いくら IP を回しても無意味です。
ハルシネーションは見抜きにくい。 「役に立つように」訓練された LLM は、任意項目を null で返す代わりに、それらしい中身をでっち上げて埋めることがあります。URL スラッグからブランド名を推し量ったり、TLD から通貨を当て推量したり、スケルトンローダーからレビュー件数をひねり出したり——実際にそういう振る舞いを目にしてきました。対策は、厳格な Pydantic スキーマ、検証結果を返して再試行させるループ、抽出値がソース HTML に本当に存在するか照合する grounding バリデータ、そして 2 段階抽出（Flash で抽出し、Pro でサンプル検証）です。
100 万トークンのコンテキストは、まるまる使えるわけではありません。 Chroma などの研究 によると、推論の品質はトークン上限に届くずっと手前から落ち始めます。構造化抽出では、実用上の上限を約 20〜30 万トークンと見積もるのが現実的です。
判断フローチャート: どのツールを使うべき？
- 少量 + シンプルなページ + 開発者 → Gemini API 無料枠 + Python
- 中量 + 複雑なスキーマ + 開発者 → Gemini 2.5 Flash の有料版 + Python + 構造化出力 + 前処理
- 量を問わず + 非開発者 + ログイン制限やページネーションが多い → Thunderbit
- 超大量 + 強いボット対策 + 重要業務 → 取得基盤は管理型スクレイピング（プロキシサービス）に任せ、抽出レイヤーとして Gemini を使う
Gemini Web Scraping: 時間とコストを節約するコツ
Python を書く場合でも、ボタンをポチポチ押す場合でも、次の勘どころを押さえておくだけで作業はぐっと楽になります。
- Gemini に送る前に、必ず HTML を Markdown へ前処理する。 一般に 5〜10 倍のトークン削減 が見込め、BeautifulSoup で先に不要部分を落とせば 95% 削減も狙えます。
- 使うのは
google-genaiだけ。 廃止されたgoogle-generativeaiパッケージには手を出さないこと。 - Flash Lite は平坦なスキーマ限定で使う。 入れ子や任意項目が顔を出したら、ためらわず Flash へ上げる。
- Gemini に渡す Pydantic スキーマでは
Field(default=...)を避ける。 型レベルでsku: str | None = Noneと書く。 - Pydantic と
response_schemaは必須。 仕様書であると同時に、ハルシネーションを防ぐガードレールにもなります。 - 1,000 ページを超える作業には Batch API を使う。 50% 割引が効くうえ、リアルタイムの RPM 制限にも影響しません。
- 新しい抽出ロジックは、まず 10〜50 行を目で確かめる。 精度のズレは、見ない限り気づけません。
- 生 HTML はディスクにキャッシュする。 スキーマをちょっと変えるたびに、取り直す必要はありません。
- 各行にソース URL を残す。 そうすれば、全体をやり直さずに個別ページだけ再クロールできます。
- ノーコード派は、Thunderbit の列ごとのカスタム AI プロンプトを使い倒す。 翻訳・分類・要約などのプロンプト設計を、スプレッドシートの層に持ち込めます。
最後にもう一点。無料枠を本番にそのまま流用しないこと。 2025 年 12 月には上限が 50〜80% 引き下げられており、今後も予告なく変わる可能性があります。
まとめ
Gemini の 1 URL デモと本番で回るパイプラインの間には、思っている以上の距離があります。
Python + Gemini API のルートなら、モデル選択、前処理、ページネーション、スキーマ設計のすべてを自分の手で握れます。一方、Thunderbit のようなノーコードのルートなら、ターミナルに触れずとも、ビジネスユーザーが同じ構造化データ抽出を実現できます。
この記事で押さえておきたい要点は、次のとおりです。
- モデル選びは重要です。 大量処理なら Flash Lite、バランス重視なら Flash、複雑な抽出なら Pro。何となく最安モデルを選んで、後からデータが間違っている理由に頭を抱えるのは避けましょう。
- 複数ページ・サブページのスクレイピングこそ、解説記事が弱い部分 であり、実務で本当に効いてくる部分です。本記事では、そのギャップを埋める両方の方法を示しました。
- 限界を正直に把握することが、結局は最速の近道です。 サイトが API リクエストをはねるなら、どんなプロンプトの工夫も届きません。最先端っぽさではなく、用途に合った道具を選びましょう。
- HTML を Markdown へ前処理するのが、最も効果の大きい最適化です。 コストを 75% 以上削り、ハルシネーションも抑えられます。
ノーコードの手を試したいなら、Thunderbit の無料枠 で数ページ抽出してみてください。コード派なら、Gemini の無料 API 枠で午後ひとときのプロトタイプづくりに挑戦できます。どちらでも、コピペよりはるかに速く構造化データが手に入ります。Web サイトから Excel へデータを抽出する方法 や おすすめの AI Web スクレイパー も、ブログで取り上げています。
AI Web Scraping に Thunderbit を試す Get Started Free
FAQ
Gemini を使った Web Scraping の費用はどのくらい？
Gemini API には無料枠があり、2026 年初頭時点では Pro が 1 日約 100 件、Flash が約 500 件、Flash Lite が約 1,000 件まで使えます（2025 年 12 月に上限が引き下げられました）。有料枠では、HTML を先に Markdown に前処理する前提で、商品ページ 10,000 件の抽出コストは Flash Lite で約 $1.50、Flash で約 $6、Pro で約 $25 です。前処理をしないとコストは 4〜5 倍になります。Batch API なら、リアルタイムでない処理を 50% 割引で実行できます。
Gemini でログイン必須サイトをスクレイピングできますか？
Gemini の API だけではサイトにログインできません。Gemini は渡された内容を処理するだけです。自分の認証済みセッションで HTML を取得する必要があります（たとえば、ヘッドレスブラウザと保存済みクッキーを使う）。Thunderbit の Browser Scraping モードなら、その処理を標準でこなせます。ログイン済みの Chrome タブ内で動くため、ブラウザで見えているサイトなら Thunderbit で抽出できます。
Gemini を使った Web Scraping は合法ですか？
合法性は、サイトの利用規約、データの種類、そしてあなたの管轄地域によって変わります。米国では、hiQ v. LinkedIn や Meta v. Bright Data 以降、ログインせずに公開されているデータのスクレイピングは一般に許容されると考えられていますが、個別事情が大きく影響します。ログイン後のデータをスクレイピングする場合は、法的リスクが高くなります。EU では、公開サイトの情報であっても個人データには GDPR が適用されます。常に robots.txt と利用規約を確認し、正当な根拠なく個人データを収集しないでください。
動的で JavaScript が多いサイトも Gemini でスクレイピングできますか？
はい。ただし、先に JavaScript をレンダリングする必要があります。方法は、ヘッドレスブラウザ（Playwright、Puppeteer）を使うか、サイトの API エンドポイントを直接横取りする方法です。レンダリング済み HTML を取得できれば、あとは通常どおり整形して Gemini に送ります。あるいは、Gemini の vision API を使ったスクリーンショットスクレイピングなら、JavaScript レンダリング自体を回避できます。ブラウザで表示できるなら、Gemini も見られます。Thunderbit は Cloud / Browser の両モードで、JavaScript レンダリング済みページに自動対応しています。
Gemini でのスクレイピングと、Thunderbit のような専用ツールの違いは何ですか？
Gemini は抽出エンジンであり、内容を解釈して構造化データを返します。ただし、サイトを巡回したり、ページネーションを処理したり、認証を管理したり、スプレッドシートへ出力したりはしません。つまり、ページ内容を Gemini に届ける仕組みと、結果を活用する仕組みは別途必要です。Thunderbit のような専用ツールは、取得、レンダリング、AI 抽出、ページネーション、サブページ追加抽出、エクスポートを 1 つにまとめています。面倒な配線は不要です。
さらに詳しく
