本当に使える Gemini Web Scraping のやり方（コードあり・ノーコードあり）

「gemini web scraping」と検索して出てくる解説記事の多くは、まるで同じ人に向けて書かれているかのようです。すでに仮想環境を用意していて、Pydantic のスキーマも理解済みで、async ライブラリにもこだわりがある Python 開発者向けの内容ばかり。もしあなたがそのタイプなら、もちろんコードから入って問題ありません。でも、営業・マーケティング・EC運用の担当者で、markdownify が何をするのか学ぶことなく、Webページから構造化データだけ取り出したいなら、あなたは少数派ではありません。

Gemini は Google のマルチモーダル AI ファミリーで、Web データ抽出の有力な選択肢として急速に存在感を高めています。2025 年の Stack Overflow Developer Survey では、 が AI ツールを使っている、または今後使う予定だと回答しており、LLM を活用したスクレイピングはその大きな流れの一部です。ただし、「1 つの URL で動くかっこいいデモ」と、「ページネーション・サブページ・ボット対策・崩れた HTML を本番レベルでさばける仕組み」はまったく別物です。このガイドでは、Python を使う方法とノーコードの方法の両方を紹介し、実際のトークン計算を交えながらモデル選定を解説し、ほかの解説記事が飛ばしがちな複数ページのスクレイピングまで扱います。さらに、Gemini スクレイピングがどこで破綻するのかも率直にお伝えします。読み終えるころには、自分の業務にどのやり方が合うのか、そして開発者にもビジネスユーザーにも起こりがちな落とし穴をどう避けるべきかがわかるはずです。

Gemini Web Scraping とは？

Gemini web scraping とは、Webページの内容（HTML、Markdown、あるいはスクリーンショット）を Google の Gemini AI モデルに渡し、ページを解釈して構造化データとして返してもらう方法です。CSS セレクタも、XPath も、サイトが少しレイアウトを変えただけで壊れる脆いルールも不要です。

基本の流れは次のとおりです。

1. ページを取得する（requests、ヘッドレスブラウザ、Chrome 拡張などを使用）
2. 内容を整形して変換する（通常は HTML → Markdown にしてトークンコストを削減）
3. 抽出したい項目を示すスキーマと一緒に Gemini に送る
4. 構造化された JSON を受け取る — スプレッドシート、CRM、データベースにそのまま使える形で

これを、BeautifulSoup や Selenium を使った従来型スクレイピングと比べてみましょう。従来型では、div.product-title > span.price のようなセレクタを手作業で書き、サイトが来週デザインを変えないことを祈るしかありません。Gemini は人間のようにページを読み取り、文脈を理解し、レイアウト変更にもある程度対応し、複雑で崩れた書式もカスタムルールなしで処理できます。

もう 1 つ重要な点があります。Gemini は最初からマルチモーダル対応です。テキスト、画像、動画、音声、PDF、コードを 1 回のリクエストで処理できます。そのため、HTML の代わりにスクリーンショットを送るような、他の多くの LLM では真似しにくい抽出方法も可能です。この点は後ほど詳しく見ていきます。

なぜ Gemini Web Scraping はビジネスチームに重要なのか

マーケティングマネージャーや EC アナリストが、なぜ LLM や Web スクレイピングを気にするべきなのか。答えはシンプルです。圧倒的に時間を節約できるうえ、サイトが更新されるたびに壊れることも少ないからです。

2025 年の約 10 億ドルから 2030 年には 20 億ドル超へ成長すると予測されており、その中でも AI 駆動の抽出は最も伸びている分野です。これは単なる流行ではなく、各チームのデータ収集方法が実際に変わっていることを示しています。

Gemini を使ったスクレイピングが、日々の業務フローにどう役立つのかを整理すると、こんなイメージです。

実務上のメリットは 2 つあります。1 つ目は、解析スクリプトを書いて、テストして、デバッグする作業を繰り返さなくて済むこと。モデルが毎回ページを新しく読み取ってくれます。2 つ目は、サイトが <div> を少し動かしただけで開発者を呼ぶ必要がなくなること。Gemini の無料枠なら、小規模な作業であればほぼゼロコストで試せます。たとえば まで、クレジットカード不要で使えます。

どの Gemini モデルを選ぶべき？（Flash Lite / Flash / Pro）

スクレイピングにおいて、Gemini の各モデルは同じではありません。これは、ほとんどの解説記事に欲しかった実用比較です。なぜなら、モデル選びを間違えると、無駄にお金がかかるか、ひどいデータが返ってくるからです。

現行の Gemini 2.5 系 3 モデルはいずれも 1,048,576 トークンのコンテキストウィンドウを持ち、マルチモーダルに対応しています。違いはコスト、速度、そして複雑な抽出への強さです。

(価格は に基づきます。Batch API はこれらの料金から 50% 割引です。)

Gemini 2.5 Flash Lite: 速くて安いが、欠損に注意

Flash Lite は低コスト重視の選択肢です。商品名、価格、1 段階の一覧情報のような、シンプルで平坦なデータを大量に処理するのに向いています。ただし、任意項目、タイムスタンプ、入れ子データで問題が報告されています。Google のフォーラムでは、ある開発者が スキーマに必須ではないプロパティが含まれると「暴走する」と報告しており、トークン上限まで同じ文を繰り返すことがあるそうです。スキーマが 2 段階以上の入れ子を持つ場合や、ページによって存在しない項目がある場合は、Flash Lite ではトークンも気力も削られます。

Gemini 2.5 Flash: ほとんどのスクレイピングで最適バランス

実務のスクレイピングで、まず試すべきなのは Flash です。構造化抽出に強く、ページネーションの処理もこなし、入力コストは Flash Lite の約 3 倍ですが、そのぶん精度向上の価値は十分あります。 でも Flash は Pro にかなり近いスコアを出しており、スクレイピングで必要になる推論・正規化・平坦化をきちんと処理できます。

Gemini 2.5 Pro: 複雑データ向けの最高精度モデル

Pro は精密作業向けです。たとえば、サイズ・色・価格のバリエーションが複数ある商品仕様のように、深く入れ子になったスキーマを扱うときや、誤情報が絶対に許されないとき（法務、金融、医療データなど）に使いましょう。入力コストは Flash Lite の約 12 倍なので、価格より精度が重要な案件に限定するのが得策です。

コスト試算: 商品ページ 10,000 件を処理する場合

HTML を Markdown に前処理する前提であれば（実際そうすべきです。後ほど詳しく説明します）、典型的な商品ページは生 HTML の約 20,000 トークンから、Markdown で約 4,000 トークンまで減ります。出力 JSON は 1 ページあたり約 500 トークンです。

Markdown 前処理をしない場合（生 HTML で入力が約 2 億トークンになる想定）、これらの金額は 4〜5 倍に跳ね上がります。前処理は、パイプライン全体で最も効果の大きい最適化です。

コードとノーコード: Gemini Web Scraping の 2 つの道

ここが分かれ道です。カスタムのパイプラインを作る開発者なら、Python + Gemini API で最大限の自由度を得られます。ターミナルを触らず、今すぐデータがほしいビジネスユーザーなら、ノーコードの AI スクレイパーのほうが早く実現できます。

は、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 キーを準備する

まずプロジェクトフォルダと仮想環境を作成し、必要なライブラリをインストールします。

1mkdir gemini-scraper && cd gemini-scraper
2python -m venv venv && source venv/bin/activate
3pip install -U google-genai requests beautifulsoup4 markdownify pydantic

重要: 2026 年時点で正しい SDK は google-genai だけです。旧パッケージの google-generativeai は 2025-11-30 で終了しており、すでに非推奨です。チュートリアルで import google.generativeai as genai と書かれていたら、そのコードは古いものです。

次に、 から API キーを取得します。"Get API Key" をクリックして新しいキーを作成し、環境変数として保存してください。

1export GEMINI_API_KEY="your-key-here"

これで、依存関係がそろい、API キーも設定された Python 環境が整いました。

ステップ 2: 対象ページの HTML を取得する

requests でページを取得します。ここでは商品ページを抽出する例を見てみましょう。

1import requests
2url = "https://example.com/product/widget-pro"
3response = requests.get(url, headers={"User-Agent": "Mozilla/5.0"}, timeout=30)
4html = response.text

サイトが重い JavaScript レンダリングを使っていたり、ボット対策が強かったりすると、requests.get() は空の HTML だけ返すか、403 を返すことがあります。この対処法は制限の章で説明しますが、多くの公開サイトではこれで十分機能します。

ステップ 3: HTML を整えて Markdown に変換する

多くの解説記事では触れられているのに、定量化されていないのがこの工程です。典型的な商品ページの生 HTML は約 20,000 トークンにもなります。BeautifulSoup で不要部分を削って Markdown 化すると、約 765〜4,000 トークン程度まで下がり、 ができ、実際のコスト削減と誤認識の抑制につながります。

1from bs4 import BeautifulSoup
2from markdownify import markdownify
3soup = BeautifulSoup(html, "html.parser")
4main = soup.select_one("main") or soup  # 本文エリアだけを取得
5markdown_content = markdownify(str(main))

select_one("main") を使うと、ヘッダー、フッター、ナビゲーション、スクリプトなど、トークンを無駄にしモデルを混乱させるノイズを取り除けます。サイトに <main> タグがない場合は、.product-detail、#content、または実データを囲っている要素を試してください。

このステップが終わると、ページの意味ある内容だけを含んだ、きれいな Markdown 文字列が得られます。

ステップ 4: データスキーマを定義して Gemini に送る

Pydantic を使って、返してほしい形式を定義します。google-genai SDK は、response_schema に Pydantic の BaseModel をそのまま渡せます。

1from google import genai
2from google.genai import types
3from pydantic import BaseModel
4class Product(BaseModel):
5    name: str
6    price: str
7    sku: str | None = None
8    description: str
9    sizes: list[str] = []
10    colors: list[str] = []
11client = genai.Client()  # GEMINI_API_KEY を環境変数から読み込む
12response = client.models.generate_content(
13    model="gemini-2.5-flash",
14    contents=f"このページから商品情報を抽出してください:\n\n{markdown_content}",
15    config=types.GenerateContentConfig(
16        response_mime_type="application/json",
17        response_schema=Product,
18    ),
19)
20product = response.parsed
21print(product)

から、いくつか注意点があります。

• Gemini に送るスキーマでは Field(default=...) を使わない でください。API が ValueError を返します。代わりに型レベルで sku: str | None = None のように書きます。
• 入れ子は浅く保つ のが無難です（最大 3 階層）。深すぎるスキーマは、Flash と Flash Lite で再帰的な出力や閉じられていない括弧の原因になります。
• Flash Lite を使う場合は、必須項目を明示し、欠損時は空文字などの代替値を使う 方が安全です。Flash Lite の任意フィールド処理は 。

これで、ページから構造化データを持った Product オブジェクトが得られます。

ステップ 5: 抽出したデータを保存・出力する

結果を JSON または CSV で保存します。

1import json
2with open("products.json", "w") as f:
3    json.dump(product.model_dump(), f, indent=2)

Google Sheets に流し込むなら gspread が使えます。データベースなら、使っている ORM に合わせてシリアライズしてください。Gemini の構造化出力は、そのまま多くの下流ツールに渡せるくらいきれいです。

手順で解説: コードなしで Gemini Web Scraping を行う方法（Thunderbit を使用）

こちらはビジネスユーザー向け、または使い捨てのスクレイピングスクリプトを書きたくない開発者向けです。

始める前に:

• 難易度: 初級
• 所要時間: 初回の抽出まで約 5 分
• 必要なもの: Chrome ブラウザ、（無料枠あり）

ステップ 1: Thunderbit の 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」をクリックして結果を確認する

あとは 1 回クリックするだけです。Thunderbit はページネーション（「次へ」ボタンを押す形式も、無限スクロールも）を処理し、データを構造化テーブルに抽出します。以下から選べます。

• クラウドスクレイピング: 速く、最大 50 ページを同時に処理できます。公開サイト向けです。
• ブラウザスクレイピング: ログイン済みのブラウザタブ内で動作します。認証が必要なサイト（CRM、会員制ディレクトリ、社内ツールなど）に使います。

結果は拡張機能のサイドバーにテーブル形式で表示されます。エクスポート前に、明らかな誤りがないか確認しましょう。

ステップ 4: Excel、Google Sheets、Airtable、Notion にエクスポートする

エクスポートボタンをクリックして形式を選ぶだけです。Thunderbit は Excel、Google Sheets、Airtable、Notion に無料でエクスポートできます。画像フィールドは Notion や Airtable の画像ライブラリに直接アップロードされるので、商品写真や顔写真を扱うときにも便利です。

JSON の解析も、スクリプトも不要。データはすぐに使えます。

Gemini を使った複数ページ・サブページのスクレイピング

多くの解説記事は、1 つの URL で終わってしまいます。でも実際のスクレイピング業務はそうではありません。

ページネーション付きの商品 500 ページや、詳細サブページを持つデータを抽出するのは 1 つの仕事です。そして、単一 URL のデモと現実の間には大きな差があります。

Gemini API でページネーションを扱う（コード編）

ページ番号付き URL がある場合は、空の結果が返るまでループします。これは最も一般的なパターンです。

1import time
2all_products = []
3for page in range(1, 101):  # 最大 100 ページ
4    url = f"https://example.com/products?page={page}"
5    md = fetch_clean(url)  # 先ほどの HTML→Markdown 関数
6    response = client.models.generate_content(
7        model="gemini-2.5-flash-lite",  # 一覧ページなら低コストで十分
8        contents=f"商品名と URL を抽出してください:\n\n{md}",
9        config=types.GenerateContentConfig(
10            response_mime_type="application/json",
11            response_schema=list[ListingItem],
12        ),
13    )
14    items = response.parsed
15    if not items:
16        break
17    all_products.extend(items)
18    time.sleep(4)  # 無料枠のレート制限に配慮

カーソルベースや無限スクロールのサイトでは、フロントエンドが呼んでいる XHR エンドポイントをブラウザの Network タブで確認し、そのエンドポイントを直接ループする必要があります。再レンダリングより安く、LLM に渡すのは項目のクリーニングが必要なときだけで済みます。

ここでもトークンコストには注意してください。ページが増えるほど請求も増えます。単純な一覧ページには Flash Lite を使い、詳細抽出にだけ Flash を使うのが賢いやり方です。

サブページをスクレイピングして、よりリッチなデータを取得する（コード編）

定番の 2 段階パターンです。ステージ 1 で一覧ページから URL を集め、ステージ 2 で各詳細ページにアクセスして、より詳しいデータを取得します。

1# ステージ 1: 安価な Flash Lite で URL を収集
2class Listing(BaseModel):
3    product_urls: list[str]
4listing = client.models.generate_content(
5    model="gemini-2.5-flash-lite",
6    contents=f"商品 URL を抽出してください:\n{listing_md}",
7    config=types.GenerateContentConfig(
8        response_mime_type="application/json",
9        response_schema=Listing,
10    ),
11).parsed
12# ステージ 2: Flash で詳細を抽出
13class ProductDetail(BaseModel):
14    name: str
15    price: str
16    specs: dict[str, str]
17    reviews: list[str]
18for url in listing.product_urls:
19    md = fetch_clean(url)
20    detail = client.models.generate_content(
21        model="gemini-2.5-flash",
22        contents=f"商品詳細を抽出してください:\n{md}",
23        config=types.GenerateContentConfig(
24            response_mime_type="application/json",
25            response_schema=ProductDetail,
26        ),
27    ).parsed
28    # detail を保存...
29    time.sleep(0.5)

これは動きますが、URL の重複排除、エラー処理、レート制御、リトライロジック、スキーマ変更のたびに再取得しなくて済むような HTML キャッシュなど、周辺処理がかなり必要です。50 ページなら何とかなっても、5,000 ページになるとインフラづくりに近くなります。

ノーコードの代替: Thunderbit のページネーション・サブページ抽出機能

Thunderbit は、クリック型も無限スクロール型も自動で処理します。ループのコードは不要です。サブページの追加抽出では、「サブページをスクレイプ」機能が一覧の各リンク先を訪問し、元のテーブルにより深い項目を追加してくれます。スクリプト 1 本ではなく、1 クリックで済みます。

クラウドスクレイピングでは最大 50 ページを同時処理できるため、商品カタログや不動産ディレクトリを大規模に扱うときに大きな差が出ます。Python のループやリトライ処理を管理したくない人にとって、これはかなり実用的な選択肢です。（ については別の解説もあります。）

スクリーンショットスクレイピング: Gemini のマルチモーダルな近道

ほとんどの解説記事が完全に飛ばしているのが、Webページの スクリーンショット を生の HTML の代わりに Gemini の vision API に送る方法です。ある開発者は、1 枚のスクリーンショットは約 258 トークンしかかからないと 。これは、整形済み Markdown ですら数千トークン必要なことを考えると、大きな差です。単純な抽出なら、かなり強力なコストメリットがあります。

Gemini の Vision API を Web Scraping に使う方法

Playwright でスクリーンショットを取得し、エンコードして Gemini に送ります。

1from playwright.sync_api import sync_playwright
2from google import genai
3from google.genai import types
4from pydantic import BaseModel
5class Product(BaseModel):
6    title: str
7    price: str
8with sync_playwright() as p:
9    page = p.chromium.launch().new_page()
10    page.goto("https://example.com/product/widget-pro")
11    page.wait_for_load_state("networkidle")
12    png_bytes = page.screenshot(full_page=False)  # 画面上部だけ
13client = genai.Client()
14resp = client.models.generate_content(
15    model="gemini-2.5-flash",
16    contents=[
17        {"inline_data": {"mime_type": "image/png", "data": png_bytes}},
18        "商品タイトルと価格を JSON で抽出してください。",
19    ],
20    config=types.GenerateContentConfig(
21        response_mime_type="application/json",
22        response_schema=Product,
23    ),
24)
25print(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 の面倒な処理は不要です。（あわせて も参考になります。）

Gemini Web Scraping が失敗するケースと、その代替策

Gemini は「抽出エンジン」であって、「取得エンジン」ではありません。ページ内容を Gemini に渡せなければ、当然ながら何もできません。

このアプローチが破綻する典型例はいくつかありますが、ほとんどの解説記事は軽く触れるだけです。ここでははっきり書きます。

いくつかは補足が必要です。

ボット対策は、今や LLM も意識しています。 2025 年 7 月時点で Cloudflare は しており、最初の 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 バリデータ、そして （Flash で抽出し、Pro でサンプル検証）です。

100 万トークンのコンテキストは、100 万トークン分使えるわけではありません。 によると、推論品質はトークン上限に達するずっと前から低下します。構造化抽出では、約 20〜30 万トークンを実用上の上限と考えるのが妥当です。

判断フローチャート: どのツールを使うべき？

• 少量 + シンプルなページ + 開発者 → Gemini API 無料枠 + Python
• 中量 + 複雑なスキーマ + 開発者 → Gemini 2.5 Flash の有料版 + Python + 構造化出力 + 前処理
• 量を問わず + 非開発者 + ログイン制限やページネーションが多い →
• 超大量 + 強いボット対策 + 重要業務 → 取得基盤は管理型スクレイピング（プロキシサービス）に任せ、抽出レイヤーとして Gemini を使う

Gemini Web Scraping: 時間とコストを節約するコツ

Python で書く場合も、ボタンをクリックする場合も、次のポイントを押さえるだけでかなり楽になります。

1. Gemini に送る前に、必ず HTML を Markdown に前処理する。 一般的に が期待でき、BeautifulSoup で事前に不要部分を削れば 95% 削減も可能です。
2. 使うのは google-genai のみ。 廃止された google-generativeai パッケージは使わないでください。
3. Flash Lite は平坦なスキーマだけに使う。 入れ子や任意項目が出てきたら、すぐ Flash に上げる。
4. Gemini に渡す Pydantic スキーマで Field(default=...) は避ける。 型レベルで sku: str | None = None のように書く。
5. Pydantic と response_schema は要。 仕様書であると同時に、ハルシネーションを防ぐガードレールにもなります。
6. 1,000 ページを超える作業では を使う。 50% 割引があり、リアルタイムの RPM 制限にも影響しません。
7. 新しい抽出ロジックは、まず 10〜50 行を目視で検証する。 精度のズレは、見ない限り気づけません。
8. 生 HTML はディスクにキャッシュする。 スキーマを少し変えただけで、毎回取り直す必要はありません。
9. 各行にソース URL を残す。 そうすれば、全体をやり直さず個別ページを再クロールできます。
10. ノーコード派は、Thunderbit の列ごとのカスタム AI プロンプトを活用する。 これで、翻訳・分類・要約などのプロンプト設計をスプレッドシート層に持ち込めます。

さらに 1 つ。無料枠を本番運用にそのまま使わないこと。 2025 年 12 月には制限が 50〜80% 引き下げられており、今後も予告なしに変更される可能性があります。

まとめ

Gemini の 1 URL デモと、本番で動くパイプラインの間には、想像以上の差があります。

Python + Gemini API のルートなら、モデル選択、前処理、ページネーション、スキーマ設計をすべて細かく制御できます。ノーコードのルート、たとえば のようなツールなら、ターミナルを触らなくても、ビジネスユーザーが同じ構造化データ抽出を実現できます。

ここで押さえたいポイントは次のとおりです。

• モデル選びは重要です。 大量処理なら Flash Lite、バランス重視なら Flash、複雑な抽出なら Pro。最安モデルを何となく選んで、データが間違っている理由に悩まないようにしましょう。
• 複数ページ・サブページのスクレイピングこそ、解説記事が弱い部分 であり、実務で本当に必要になる部分です。この記事では、そのギャップを埋める両方の方法を紹介しました。
• 制限を正直に理解することが、結果的に最速です。 サイトが API リクエストをブロックするなら、どんなプロンプト工夫も効きません。最先端っぽさではなく、用途に合った道具を選びましょう。
• HTML を Markdown に前処理するのが、最も効果の大きい最適化です。 コストを 75% 以上削減し、ハルシネーションも減らせます。

ノーコードの方法を試したいなら、 で数ページを実際に抽出してみてください。コード派なら、Gemini の無料 API 枠で午後 1 回分の作業で試作できます。どちらを選んでも、コピペよりずっと早く構造化データを得られるはずです。 や については、ブログで詳しく紹介しています。

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 に届ける仕組みと、結果を活用する仕組みは別途必要です。 のような専用ツールは、取得、レンダリング、AI 抽出、ページネーション、サブページ追加抽出、エクスポートを 1 つにまとめています。面倒な配線は不要です。

さらに詳しく