誰かから、900件のリストが掲載されたディレクトリへのリンクが送られてきて、明日までにそれをスプレッドシートにまとめてほしいと頼まれたとします。
スクレイパーを作成することもできます。3時間かけてコピー&ペーストすることもできます。あるいは、無料のChrome拡張機能をインストールし、4回クリックするだけで、90秒でCSVファイルを作成することもできます。
WebRobotsが開発したInstant Data Scraperは、その3つ目の選択肢です。このツールは、現在表示されているページをスキャンし、どの部分がデータであるかを推測して、結果をCSVまたはExcel形式でエクスポートします。アカウント登録も、コーディングも、費用は一切かかりません。
また、これは多くの人が1ヶ月以内に使いこなせなくなるツールでもあり、その理由は十分に予測可能です。
このガイドでは、この拡張機能の機能、正しい使い方、動作しなくなる5つの具体的なポイント、そしてそれぞれの状況でどのような手段を講じるべきかについて解説します。
この記事は、住宅用プロキシプロバイダーであるGeonodeとして公開しています。プロキシは、以下の5つの不具合箇所のうち1つにのみ関連しており、記事ではそれがどれかを説明しています。残りの4つについては、まったく別のツールが解決策となります。
「Instant Data Scraper」の実際の機能
この拡張機能は、ウェブページ上の繰り返し構造をスプレッドシートの行に変換するという、ある特定の課題を解決します。
ウェブ上のデータの多くは、商品一覧、検索結果、ディレクトリ一覧、コメントスレッド、価格表など、一定のパターンで構成されています。各項目は、隣接する項目と同じHTML構造を持っています。 Instant Data Scraperは、こうした繰り返される構造を探し出し、それらがユーザーが求めるデータであると推測します。
セレクタを記述する必要はありません。開発者ツールを開く必要もありません。拡張機能が推測を行い、プレビュー表を表示するので、ユーザーはそれを承認するか、ページ上の別のブロックを指定するだけです。
機能の概要
自動検出。 拡張機能がページをスキャンして抽出対象を提案するため、開発者でない多くのユーザーが躊躇してしまう手順が不要になります。
ページネーションの処理。 「次のページ」ボタンを指定するだけで、拡張機能が自動的に一連のページを順に処理し、進行に合わせて行を追加していきます。
無限スクロール。 ページネーションではなく、スクロールするにつれてコンテンツが読み込まれるページの場合、拡張機能はスクロールを続けながらデータを収集し続けます。
列の制御。 列の名前を変更したり、不要な列を非表示にしたり、エクスポート前にフィルタリングしたりできます。
CSVおよびExcelへのエクスポート。 XLS、XLSX、またはCSV形式へ直接エクスポートできます。
無料、階層制なし。 アカウント不要、試用期間なし、行数制限なし。これは非常に珍しいことなので、明確に述べておく価値があります。
これではないもの
スケジューラではありません — 自動的に毎晩実行されることはありません。APIでもありません — 下流のシステムから呼び出すことはできません。クローラーでもありません — サイト全体ではなく、現在表示しているページ上で動作します。また、ユーザー自身の接続を使用するため、ブロッキングの問題を解決するものではありません。
4つのステップで使い方を解説
1. データが掲載されているページを開く
サイトのトップページではなく、実際のリストページに移動してください。データが検索結果の中に含まれている場合は、まず検索を実行してください。正当なログイン情報が必要な場合は、まずログインしてください。この拡張機能は、ブラウザに表示される内容をそのまま認識します。
作業を始める前に、サイトが許容する範囲でページサイズを最大に設定してください。「1ページあたり20件」ではなく「1ページあたり100件」を表示するサイトであれば、ページ送り作業を5分の4削減できます。
2. 拡張機能を起動し、推測結果を確認する
拡張機能のアイコンをクリックします。ページがスキャンされ、プレビュー表が表示されます。
一般的なレイアウトの場合、推測はたいてい正しいです。間違っている場合は、通常、メインコンテンツではなくナビゲーションメニューやサイドバーを認識してしまったことが原因です。拡張機能は検出した他のテーブルも表示するので、プレビューが実際に表示したい内容と一致するまで、それらを切り替えて確認してください。
次の手順に進む前に、プレビューを注意深く確認してください。 行数が妥当か、列が揃っているか、1つずれていないかを確認します。この段階で位置ずれに気づけば、ジョブ全体を再実行する手間が省けます。
3. ページネーションまたはスクロールの設定
ページネーションのあるサイトでは、「Locate Next」コントロールを使用し、サイト独自の「次のページ」ボタンをクリックしてください。拡張機能はその要素を記録し、再利用します。
無限スクロールの場合は、代わりにスクロールモードに切り替えてください。
ページ間の遅延時間は意図的に設定してください。デフォルトは高速です。これを2~3秒に引き上げることは、最も価値のある変更です。これにより、処理途中でレート制限にかかる可能性が劇的に低減され、40ページのジョブの場合でも所要時間は2分しか増えません。
4. 実行とエクスポート
クロールを開始したら、そのタブをそのままにしておきます。拡張機能はページが開いてアクティブな状態である必要があります。タブを切り替えたり、マシンをスリープ状態にしたりすると、処理が中断される可能性があります。
完了したら、列の名前を変更して不要な列を削除し、CSVまたはXLSX形式でエクスポートします。
使用する前に出力を確認してください。 行数がサイトの表示数と一致しているか確認し、実際のページと照らし合わせて数行を抜き打ちでチェックし、特に最後のページを注意深く確認してください — 切り捨ては末尾に現れます。
得意な分野
機能一覧よりも、「スイートスポット」を正確に把握しておくことの方が有用です。
単発のデータ抽出。 今日、一度だけ必要な単一のリスト。セットアップ時間は1分未満で、スクリプトによるアプローチでは到底及ばない速さです。
従来のレイアウト。 サーバーサイドでレンダリングされるテーブル、商品グリッド、ディレクトリ一覧、検索結果など、明確な反復構造を持つあらゆるもの。
小~中規模のデータ量。 数十ページにまたがる数千行程度までなら問題なく処理できます。
技術に詳しくないユーザー。 これこそが真の価値です。ターミナルを開いたことのない人でも、数分でウェブサイトから構造化データを抽出でき、それによって本来なら開発者に負担がかかるボトルネックを解消できます。
探索的な作業。 スクラッパーの開発に工数を割く前に、この拡張機能を使えば90秒で「このデータは、自分が考えているような形式になっているのか?」という疑問に答えられます。
もしあなたの業務がこの説明に当てはまるなら、ここで読むのを止めてください。この拡張機能が最適な解決策であり、以下に続く内容は、あなたには関係のない問題について書かれているからです。
問題が発生する箇所
多くの人が直面する5つの問題点を、発生しやすい順に紹介します。
1. ページ数
この拡張機能はブラウザ上で動作し、ブラウザの処理速度に依存するため、一度に1ページずつしか処理できません。数十ページ程度なら問題ありません。 しかし、数千ページとなると、タブを何時間も開いたままにしておく必要があり、一旦停止してしまった場合、スムーズに再開することはできません。
並列処理も、キューも、チェックポイントもありません。400ページ中300ページ目でクロールが中断した場合、通常は最初からやり直すことになります。
2. レート制限とブロック
これはプロキシが真の解決策となるため、最も多くの紙幅を割いています。
すべてのリクエストは、ご自身のIPアドレスから送信されます。リクエスト頻度を追跡するサイトからは、1つのアドレスから、一定の間隔で、構造的に同一のリクエストが継続的に行われているように見えます。これは、人間によるブラウジングの挙動とは異なります。
その結果、通常はCAPTCHAの表示、続いてリクエスト制限、そして一時的なアクセスブロックが発生します。ビジネス上重要なサイトにおいて、オフィスのIPアドレスがフラグ付けされることは、実質的なコストとなります。
リクエスト速度を落とすことは有効であり、まず試すべき対策です。しかし、一定量を超えるとこれだけでは不十分になります。なぜなら、問題は速度ではなく、すべてのリクエストが1つのアドレスから送信されていることにあるからです。リクエストを多数のアドレスに分散させることこそが根本的な解決策であり、そのためにはプロキシが必要ですが、ブラウザ拡張機能ではリクエストごとにプロキシを利用することはできません。
3. スケジュール設定
拡張機能は単独では動作しません。毎朝6時に価格情報を取得する必要がある場合、誰かがブラウザを開いてクリックしなければなりません。定期的な作業には、スクリプト化されたスクレイパーか、ホスティングサービスが必要です。
4. 扱いにくい構造
自動検出は、繰り返されるパターンを前提としています。 リスト形式ではなくページ全体に散在するデータ、タブやアコーディオンなどの操作を伴うコンテンツ、行ごとに個別にアクセスする必要がある詳細ページ、そして非標準的な方法でコンテンツを組み立てるJavaScript依存度の高いインターフェースなどには対応が困難です。
また、一覧ページから詳細ページへのリンクをたどって戻ってくることもできません。これは非常に一般的な要件ですが、この拡張機能では完全に不可能です。
5. 統合
出力は、人間がダウンロードするファイルです。パイプライン、ダッシュボード、またはモデルでデータが必要な場合、そのファイルを毎回誰かが移動させる必要があります。APIもWebhookもありません。
知っておくべき代替案
直面している課題に合わせてツールを選びましょう。
その他のブラウザ拡張機能
同様の機能を持つ拡張機能がいくつかあり、中にはAIを活用したフィールド検出機能やクラウド実行機能を備えたものもあります。検出が具体的な課題である場合は試してみる価値がありますが、これらのツールには共通の根本的な制約があります。それは、使用するブラウザ、IPアドレス、クリック回数に制限があるという点です。
拡張機能を切り替えることで検出の問題は解決できますが、処理量、スケジュール設定、ブロック、統合といった課題は解決されません。
ビジュアルスクレイパーアプリケーション
ポイント&クリック式のビルダーを備えたデスクトップおよびクラウドツールは、さらに一歩進んだレベルにあります。これらは、多段階のフロー、詳細ページの閲覧、スケジュールされたクラウド実行に対応しています。そのほとんどは商用ツールです。
自動検出には構造が複雑すぎるものの、それでもコードを書きたくない場合に適した選択肢です。
独自に作成する
requests や BeautifulSoup を組み合わせた Python なら、サーバーサイドレンダリングされたページに対応できます。Playwright や Selenium は、JavaScript を多用するサイトを処理します。Scrapy は、リトライや並行処理機能が組み込まれており、大規模なクロールに対応します。
これは最も柔軟ですが、最も手間もかかります。一度作成すれば永久に実行され続けるため、定期的なジョブであればその価値は十分にあります。
スクレイピングAPI
URLを受け取り、解析済みのデータを返すサービスで、URLのローテーションやサーバーサイドでのレンダリングを処理します。リクエストごとのコストを支払う代わりに、インフラの維持管理が不要になります。
インフラを所有せずにデータを入手したい場合に適しています。
独自コードを用いたプロキシ
スクレイパーの制御権を保持しつつ、ローテーションされたアドレスを経由してリクエストをルーティングします。APIよりも手間はかかりますが、大量処理ではコストが安く、ロジックを自社で管理できます。
スクレイピング作業が恒常化すると、ほとんどのチームがこの方法に落ち着きます。
拡張機能の枠を超えたスケーリング
単発のジョブが定期的なジョブになると、問題の性質が変わってきます。
転換点を認識する
以下のいずれかに該当する場合は、対応を検討しましょう:ジョブが複数回実行される、ページ数が数百ページを超える、レート制限を受けた、出力が自動化されたシステムに連携されている、あるいは構造上、詳細ページへのリンクをたどる必要がある場合などです。
置き換え後の姿
拡張機能が実行する処理をスクリプト化した基本的な例:
import time
import requests
from bs4 import BeautifulSoup
proxies = {
"http": "http://USERNAME:PASSWORD@proxy.geonode.io:9000",
"https": "http://USERNAME:PASSWORD@proxy.geonode.io:9000",
}
rows = []
for page in range(1, 41):
r = requests.get(
f"https://example.com/listings?page={page}",
proxies=proxies,
timeout=30,
)
if r.status_code != 200:
print(f"page {page}: HTTP {r.status_code}")
continue
soup = BeautifulSoup(r.text, "html.parser")
for item in soup.select(".listing-item"):
rows.append({
"title": item.select_one(".title").get_text(strip=True),
"price": item.select_one(".price").get_text(strip=True),
})
time.sleep(2)
print(f"collected {len(rows)} rows")
約30行のコードで、拡張機能では実現できない以下の利点が得られます:無人実行が可能、既知のページから再開可能、そして1つのアドレスに集中してリクエストを送り続けるのではなく、多くのアドレスにリクエストを分散させることができます。
この規模でのプロキシのコスト
テキストのスクレイピングは負荷が軽い。画像を含まないHTMLページは通常50~200 KBであるため、1万ページ分だと1~2 GB程度になる。
[Geonode
](https://geonode.com/pricing)のGBあたり0.79ドルの基本料金で計算すると、作業全体で**1~2ドル**程度になります。また、新規アカウントには1 TBの無料容量が付与されるため、金銭のやり取りが発生する前に、この規模の作業を数多くこなすことができます。 料金は、100 GBで1 GBあたり0.50ドル、1 TBで0.27ドルまで下がります。
率直に言えば、1万ページ程度であればどちらのプランでもコストは微々たるものであり、移行する理由は価格ではなく信頼性です。価格が問題になり始めるのは数百万ページ規模の場合であり、そこではプロバイダーごとに0.79ドルから7.00ドルと幅のあるGBあたりの単価が、実質的な金額として積み上がってきます。
拡張機能は手元に置いておく
本格的なパイプラインが整った後も、この拡張機能は本来の強みである「1行のコードも書く前に、新しいソースを処理する価値があるかどうかを確認する」という点で、依然として有用です。
ルールを守ること
この拡張機能を使えばデータ収集が簡単になるため、収集すべきかどうかという判断を軽視してしまいがちです。
利用規約をよく読んでください。 多くのサイトでは、自動収集を明示的に制限しています。ツールが無料で使いやすいからといって、サイト利用時に同意した内容が変わるわけではありません。
公開データを優先しましょう。 誰でも閲覧できる商品リスト、価格、仕様などは、ログインが必要な情報や個人情報よりもはるかに安全です。法的根拠がない限り、個人の個人情報を収集してはいけません。
サイトの処理能力を尊重しましょう。 収集が許可されている場合でも、過度な収集頻度は実際のユーザーにとってサービスの質を低下させます。リクエスト間の間隔を空けることは礼儀であると同時に、アクセス制限を回避するためにも役立ちます。
robots.txt を確認してください。 これは法的拘束力のある文書ではありませんが、運営者が何を望んでいるかを示しており、これを無視すると、後々善意に基づく主張の説得力を損なうことになります。
著作権は依然として適用されます。 事実は一般的に保護されませんが、創造的なコンテンツは保護されます。価格情報の抽出は、記事の再掲載とは異なります。
管轄権は異なります。 規則は国によって異なり、事業を行う場所、インフラが設置されている場所、データ主体が所在する場所によって異なる場合があります。商業的に重要な作業については、自身の状況に合わせた専門家の助言を求めてください。
よくある質問
Instant Data Scraperは無料ですか?
はい。このChrome拡張機能は無料で、全機能が利用でき、有料プランや利用制限もありません。この種のツールとしては珍しい特徴です。アカウント登録も不要で、試用期間もありません。
すべてのウェブサイトで動作しますか?
いいえ。テーブル、商品一覧、検索結果、ディレクトリ一覧など、明確で反復的な構造を持つページでは問題なく動作します。一方、リスト形式ではなくページ全体に散在しているデータ、タブやアコーディオンの奥にあるコンテンツ、詳細ページへのリンクをたどって戻ってくる必要があるサイトなどでは、処理が困難な場合があります。
スクレイピングが途中で止まってしまったのはなぜですか?
通常はレート制限が原因です。すべてのリクエストが自身のIPアドレスから、機械的な一定のリズムで送信されるため、多くのサイトがこのパターンを制限またはブロックします。ページ間の遅延を2~3秒に増やすことで、ほとんどの場合解決します。一定量を超える場合は、リクエストを複数のアドレスに分散させる必要がありますが、これはブラウザ拡張機能では実現できません。
自動実行するようにスケジュール設定できますか?
いいえ。この拡張機能は、ブラウザのタブが開いており、人が手動で開始する必要があります。定期的な処理には、スクリプト化されたスクレイパーまたはホスト型スクレイピングサービスが必要です。
これを使用すると、IPアドレスがブロックされてしまいますか?
リクエストレートを積極的に監視しているサイトでは、その可能性があります。リスクは処理量と速度が増すにつれて高まります。そのサイトがビジネス上重要な場合は、遅延時間を十分に確保するようにしてください。オフィスのIPアドレスがフラグ付けされることは、実質的なコストとなります。
いつ他の手段に切り替えるべきですか?
作業が繰り返し行われる場合、数百ページを超える場合、すでにレート制限がトリガーされた場合、自動システムにデータを供給する場合、またはリンクをたどって詳細ページにアクセスする必要がある場合です。これらのいずれかに該当すれば、切り替えの妥当な判断材料となります。
ブラウザ拡張機能にプロキシは必要ですか?
いいえ。そもそも、ブラウザ拡張機能ではリクエストごとにプロキシを使用することはできません。プロキシが重要になるのは、スクリプト化されたスクレイパーに移行したときです。また、その時点でブロックされることが、通常、最大の課題となります。
まとめ
Instant Data Scraperは、ある1つの作業において非常に優れています。それは、構造化されたページを、コードを一切使わずに、1分以内に無料でスプレッドシートに変換することです。一般的なリストからの1回限りのデータ抽出においては、結果が出るまでのスピードという点で、これに勝るものはありません。
ただし、5つの制限があり、それらは予測可能です。処理量に関しては、ブラウザの速度で1ページずつ処理されるためです。 レート制限:すべてのリクエストが自身のIPアドレスから送信されるためです。スケジューリング:人間による操作と、開いたままのタブが必要だからです。構造:自動検出は繰り返しのパターンを前提としており、リンクをたどって詳細ページへ進むことができないためです。統合:出力はエンドポイントではなくファイルであるためです。
どの制限にぶつかるかによって、次にどのような手段に移行すべきかが決まります。 検出の問題は、別の拡張機能やビジュアルスクレイパーの利用を示唆します。スケジューリングや構造の問題は、独自にスクリプトを作成する必要があることを示唆します。統合の問題は、スクレイピングAPIの利用を示唆します。ブロックされる場合は、プロキシが解決策となります。その根本的な問題は速度ではなく、すべてのリクエストが単一のアドレスから送信されているという事実にあるからです。
そして、実際に移行する場合、そのデータ量は多くの人が予想するよりも少ないものです。テキストページ1万ページ分はおおよそ1~2 GBであり、これは基本料金で数ドル程度、無料枠の範囲内に十分収まります。この規模では、移行の理由はコストではなく信頼性です。
両方を維持しておくのが賢明な習慣です。拡張機能は下調べ用――このソースを基に構築する価値はあるか? パイプラインは、2回実行する必要があるあらゆる処理用です。