Simplescraperを回した回数はもう1,000を超えました。あるときから記録する対象を変えました。「うまくいった数」ではなく「壊れた理由」です。問いを「動いたか」から「なぜ今回落ちたか」に切り替えた瞬間、公式ドキュメントより多くを学べるようになりました。
Simplescraper はコード不要でWebサイトからデータを抜き出せる、扱いやすいChrome拡張機能です。Chromeウェブストアの利用者は6万人を数え、クリックだけで完結する操作性がノーコード系スクレイパーとしての地位を固めています。とはいえ製品ページには書かれていない現実があります。ビジュアル型のスクレイパーは、どこで壊れやすいかを把握して初めて大規模運用に耐えるということです。2025年の調査は、繰り返しのデータ入力に従業員が週9時間超を割いていると報告しました。この負担がSimplescraperのようなツールへ人を向かわせるわけですが、癖を知らずに使うと、その9時間は「浮いた時間」ではなく「デバッグ時間」に化けます。以下、実運用で積み上げた5つの実践知を紹介します。選択が失敗したときの直し方、モードの使い分け、無料枠を無駄にしない方法、ブロック回避、そして乗り換えどきの見極めです。
Simplescraperの仕組みと、実践知が要る理由
商品タイトル、価格、画像、連絡先。ページ上の要素をクリックで選ぶだけで構造化データに変換できるのが、このChrome拡張機能の売りです。選んだ箇所は「レシピ」として保存され、似た構造の別ページにも使い回せます。
主な仕組みは5つです。
- クリックした部分から繰り返しパターン(商品一覧や検索結果、求人情報など)をSimplescraperが自動で見つけ出す。
- 抽出設定はレシピとして保存され、再実行やURLの一括処理に転用できる。
- 実行方式はブラウザ(Chrome上のローカル実行)とクラウド(サーバー上の無人実行)の2択。
- 出力先はGoogle Sheets、Airtable、webhook、Zapier、Make、CSV、JSONと幅広い。
- プロンプトでスキーマを渡すとCSSセレクタを自動生成するSmart Extract機能を近年追加。
想定ユーザーはマーケター、営業、EC担当、リサーチャーなど広範で、要は開発者を雇わずに構造化データが欲しい人向けです。ページの作りが整っていれば、結果はすぐに出ます。
問題は、整ったディレクトリや商品一覧の外に一歩出た瞬間に起こります。動的コンテンツ、ボット対策、遅延読み込み画像、入れ子になったHTML構造。こういう現実の壁が「頼れる道具」と「時間泥棒」を分けます。だからこそ、先に癖を知っておく価値があります。
実践知1:要素が選択できないときにやること
最もよく聞く不満がこれです。クリックするとハイライトされ、うまくいったように見える。ところが出力を開くと欄の半分が空です。画像が抜け、プロフィールが欠け、所在地が消えている。珍しくない光景です。
Simplescraper創業者自身、初期に「要素／CSSセレクタの検出はまだ完璧ではない」と認めています。誠実な姿勢ではありますが、深夜に壊れたジョブは直りません。
選択が失敗する4つのパターン
- 画像は表示領域までスクロールするまで実体として存在せず、これが遅延読み込み画像での取りこぼしにつながります。
- 入れ子・グループ化されたコンテナでは、できるだけ正確であろうとする自動検出がページ全体ではなく一部のセクションだけを拾うことがあり、「表の全行を一度に選べない」という声も出ています。
- React・Vue・AJAXなどで初回表示の後に描画される動的なJavaScriptコンテンツは、先走ったスクレイパーには存在しないものとして扱われます。
- 無限スクロールでは、スクロールするか「もっと見る」を押すまでデータそのものがHTMLに現れません。
手動セレクタに進む前に試すこと
- ページ末尾までスクロールし、遅延読み込みをDOMに展開させる
- 拾えた件数が少なすぎるときは「類似項目を含める」オプションを試す(グループ化コンテンツ向けにSimplescraperも推奨)
- JavaScriptの多いサイトでは、抽出開始前に数秒余分に待つ
- 500ページの本番投入前に、まず2〜3ページで結果を確認する
手動CSSセレクタに切り替えるタイミング
視覚選択が繰り返し失敗するなら、ここが手動に移る合図です。ライトユーザーで終わるか使いこなす側に回るかの分かれ目でもあります。
手順:
- 欲しい要素を右クリックして検証を開く。
- DevToolsでクラス名やdata属性を特定する(例:
.product-card .price、[data-test="location"])。 - Edit Propertiesタブにセレクタを貼り付ける。
- 小規模実行でセレクタの動作を確認する。
堅牢なセレクタのコツ:
div:nth-child(3)のような位置指定より.listing-titleのようなクラス名を優先- 更新に強いdata属性を積極的に使う
- 深くネストしたパスはHTML構造の変化に弱いので避ける
AI版の選択肢:Thunderbitにフィールドを任せる
まさにこの悩みに突き当たったことが、私たちのチームがThunderbitを作った理由です。「AI Suggest Fields」はページ構造をAIが読み取り、列と抽出ロジックを提案します。CSSの知識は要らず、サイトごとのレイアウトの違いにも、入れ子構造や遅延読み込みにもAI側が適応します。
セレクタのデバッグに毎回数分以上を溶かしているなら、このアプローチを試す価値は十分あります。
実践知2:ブラウザとクラウド、モードを使い分ける
用途に照らさず、最初に選んだモードをそのまま使い続けるユーザーは少なくありません。それが避けられたはずの失敗を招きます。
ブラウザ(ローカル)が向く場面
- LinkedInやCRMダッシュボードなど、ログインの裏側にあるページはアクティブなセッションが前提になる
- ページをすでに開いていて今すぐ単発で抜き出したいとき
- クラウドクレジットを温存したいとき(ローカル実行は消費しない)
代わりにPCの電源を落とせず、大量ジョブではクラウドより時間がかかります。
クラウドが向く場面
- ログイン不要な公開ページ(EC商品一覧、ディレクトリ、不動産サイトなど)
- 無人で回し続けたい定期監視
- 1回のバッチで最大5,000 URLを処理できる大量ジョブ
- Google Sheetsやwebhookへ自動で流し込みたいとき
その代わりクレジットを消費します。JS対応ページは1ページ2クレジット、非JSページは1クレジットで、無料枠の月100クレジットはすぐに尽きます。
判断フレームワーク
| シナリオ | 推奨モード | 理由 | 選び方を誤った場合のリスク |
|---|---|---|---|
| ログインが必要なページ（LinkedIn、ダッシュボード） | ブラウザ | 認証済みセッションが必要 | クラウドだとログイン壁にぶつかる |
| 公開ECの商品一覧 | クラウド | 高速で無人実行できる | ブラウザだとPCを占有する |
| 定期的な監視 | クラウド | 自分がいなくても動く | ブラウザだと常時立ち会いが必要 |
| ボット対策が厳しいサイト（Amazon、Yelp） | ブラウザ（代替）またはプロキシ付きクラウド | IPローテーションかセッション再利用が必要 | プロキシなしのクラウドはすぐブロックされる |
| 素早い単発抽出 | ブラウザ | すぐ実行でき、クレジット不要 | 1ページのためにクラウドを準備するのは大げさ |
Thunderbitでの体験
Thunderbitは同じ画面上の切り替えだけで完結します。クラウド側は最大50ページの同時処理に対応し、そのために別プランへ加入する必要もありません。ブラウザ側もログイン必須サイトへ追加設定なしで対応します。二つが一つのワークフローに収まっているだけで、モード選びに悩む場面自体が減ります。
実践知3:無料枠を無駄なく使い切る
料金の誤解は根強いです。「無料の拡張機能だから全部タダ」と思い込む声もあれば、有料プランの説明が目立たないせいで「高い」と早合点する声もあります。どちらも実態とはずれています。
無料プランの中身
現行プランは次のとおりです。
- ブラウザスクレイピングは無制限(Chrome上でのローカル実行)
- クラウドクレジットは月100
- レシピの保存上限は3つ
- 出力はCSVとJSONのみ
- 優先サポート、高度なプロキシ、追加クラウドクレジットは対象外
50件を無料枠で処理する場合
公開ECの商品ページを50件取りたいとします。
- ブラウザ実行なら費用はゼロ。ページを開き、レシピを走らせ、CSVに落とす流れで、手動でページ送りするなら15〜30分ほど見ておけば足ります。
- クラウド実行でJavaScriptレンダリングを有効にすると1ページ2クレジット。50ページで100クレジットとなり、月枠を1回のジョブで使い切ります。スケジュール実行や失敗時の再試行はできません。
たまの小規模利用には無料枠で十分ですが、自動化やスケールを求めた瞬間に足りなくなります。
無料枠の比較:Simplescraper対Thunderbit
| 機能 | Simplescraper 無料 | Thunderbit 無料 |
|---|---|---|
| ページ数/クレジット | ブラウザ無制限 + クラウド100クレジット | AI機能付きで6ページ |
| AI抽出 | 制限あり（Smart Extractはクレジット消費） | AI Suggest Fieldsをフル搭載 |
| 出力先 | CSV、JSON | Excel、Google Sheets、Airtable、Notion ― すべて無料 |
| 保存設定 | 3レシピ | テンプレートあり |
| サブページスクレイピング | 手動でレシピ設定 | ページ数に含まれる |
両者の設計思想は根本的に違います。Simplescraperは「ローカル無制限・クラウドは制限あり」という形。Thunderbitはページ数こそ絞られていますが、1ページごとにAI機能をフル装備し、日常的に使うツールへの無料出力も揃えています。多少の手作業をいとわずローカル中心で回すならSimplescraperの無料枠で足りますが、AI抽出と出力先の柔軟さを重視するならThunderbit側の1ページあたりの価値は高くなります。
実践知4:ブロックされないための備え
CAPTCHAの壁や空のデータセットに直面するまで、ボット対策を意識する人はほとんどいません。しかしその時点で、時間もクレジットもすでに失われています。
先回りの備えは、後始末より常に安上がりです。
リクエスト間隔を意図的に空ける
短時間の大量リクエストが、ブロックされる最大の原因です。1つのIPから10秒で50件届けば、サーバー側には「攻撃」にしか映りません。
目安:
- 一般的な商用サイトはページ間2〜5秒
- マーケットプレイスやレビューサイトなど警戒の強い対象は5〜10秒
- SimplescraperのAPIでは
waitForSelectorを指定すると、ページの読み込み完了を待つ分、自然に実行速度も落ちる
プロキシローテーションを検討する場面
IPアドレスをリクエストごとに切り替え、複数の利用者を装う仕組みです。次のような状況で効いてきます。
- Amazon、Yelp、TripAdvisor、LinkedInなどボット対策が強い対象
- IP単位でレートを制限してくるサイト
- 1ドメインに数百ページを当てる大規模バッチ
Simplescraperはプロキシモードとして標準・プレミアム・住宅用の選択肢を用意していますが、プランごとの利用範囲は公開ドキュメントだけでは判然としません。難易度の高い対象を無料枠だけで乗り切れると期待する前に確認が要ります。住宅用プロキシは高価な分、検知は避けやすい傾向にあります。
描画の重いサイトへの向き合い方
React、Vue、Angular製のサイトはコンテンツを初回読み込みの後に描画するため、実行が早すぎるスクレイパーには空欄しか残りません。
打てる手:
- クラウドモードでJavaScriptを実行させ、描画の完成度を上げる
- ブラウザ実行の前に手動スクロールで遅延読み込み分を呼び出す
- APIワークフローでは
waitForSelectorで対象要素の出現を待つ - 極端に動的なSPAの一部は、ビジュアルスクレイパーの守備範囲外だと割り切る
手間を丸ごと減らしたいなら
Thunderbitのクラウドスクレイピングは、ボット対策・CAPTCHA・JavaScriptレンダリングを自動処理します。プロキシ設定も遅延の微調整も手動スクロールも不要です。商品カタログを取るだけのためにDevOpsの真似事をしたくない人には、この差は小さくありません。問題そのものはなくなりませんが、あなた一人で抱える必要はなくなります。
実践知5:Simplescraperの限界を見切る
これは、2年前の自分に渡したかった章です。
ツールはある地点から「時間を節約する道具」ではなく「時間を奪う存在」に変わります。その転換点を早く察知できれば、「もう15本もレシピを作ったのだから今更やめられない」というサンクコストの罠にはまらずに済みます。
実用上ぶつかる壁
- ページ遷移を伴わずAJAXで内容を差し替える動的なシングルページアプリ
- 標準的なクリック型ページネーションではなく、延々スクロールが要る無限スクロール
- 一覧の後に各詳細ページを回って情報を足すサブページ強化。バッチワークフローで不可能ではありませんが設定はすぐに複雑化します。
- サイトのHTML構造が変わるたびに起こるレイアウト変更。丁寧に組んだセレクタが一瞬で無効になります。
乗り換えを考えるべきサイン
- CSSセレクタをスクレイピングのたびに手直ししている
- サイト更新のたびにレシピが壊れ、作り直しが発生する
- 数十〜数百ページ規模にしたいのに、クレジットや速度の上限に毎回引っかかる
- サブページを取るために何段もレシピを連鎖させている
- データを使う時間より、スクレイピングを保守する時間のほうが長い
最後の一つが最も分かりやすい目安です。「保守」が本業になった瞬間、ノーコードの利点は消えます。
AI主導のワークフローへ
ここで、私たちがThunderbitで作ったものに触れます。上に挙げた失敗パターンを踏まえて設計したものだからです。
- AIが実行のたびにページを読み直すため、レシピやセレクタの保守は不要。レイアウトが変わっても次回実行時にAIが追従します。
- サブページスクレイピングにより、一覧取得後に各詳細ページを自動巡回して表を1クリックで拡張できます。
- スケジュール設定は「毎週月曜9時」のような自然言語で指定できます。
- クラウドの同時実行数は50ページまで対応し、公開サイトでも速度が出ます。
- Google Sheets、Airtable、Notion、Excelへの無料出力が標準で、webhookの設定は不要です。
SimplescraperとThunderbit、並べて見る
まとめると次のようになります。
| 機能 | Simplescraper | Thunderbit |
|---|---|---|
| フィールド設定 | 手動CSSセレクタ / 視覚選択 | AI Suggest Fields（平易な英語） |
| サブページ強化 | バッチワークフローで可能（設定が複雑） | 1クリックで自動強化 |
| レイアウト変更への自動追従 | 壊れる（手動修正が必要） | AIが毎回ページ構造を読み直す |
| クラウドの同時処理数 | 最大5,000 URLのバッチ（プランにより変動） | 50ページを同時処理 |
| Notion/Airtableへの出力 | webhook経由（有料プラン） | ネイティブ対応、無料 |
| スケジューリング | プリセット + カスタム時間設定 | 自然言語で指定 |
| ボット対策 / CAPTCHA対応 | プロキシモードあり（プラン依存） | 自動対応、設定不要 |
| 無料枠 | クラウド100クレジット + ブラウザ無制限 + 3レシピ | AI機能付き6ページ + 無料エクスポート |
Simplescraperが得意なのは「シンプル」「視覚的」「設定が軽い」「たまの手直しは許容範囲」という領域です。Thunderbitは、そのモデルが行き詰まった先、ページの解釈、レイアウト変化への追従、ワークフローの複雑さを引き受ける側に立っています。
優劣の話ではなく、複雑さの曲線上でどこに位置しているかの違いです。それで十分です。
今日から使えるチェックリスト
次回のスクレイピングで参照してください。
- 本番前に少量でテスト。 2〜3ページで行数とフィールドの完全性を見る。
- 開始前にページ末尾までスクロール。 遅延読み込み分を呼び出すため。
- 検出範囲が狭ければ「類似項目を含める」を使う。
- モードは目的から逆算して選ぶ。 ログイン必須はブラウザ、公開ページや定期実行はクラウド。
- リクエスト間隔を空ける。 商用サイトで最低2〜5秒、警戒の強い対象はさらに長く。
- クレジットの計算を把握する。 クラウド100クレジット=JS対応ページ約50枚。
- レシピは変化の少ないページだけに使う。 更新が多いサイトでは壊れやすい。
- 基本のCSSセレクタを押さえる。 クラス名とdata属性は位置指定より頑丈。
- ブロックの兆候を早めに拾う。 結果が空、CAPTCHAが出たら速度かモードを見直す。
- 保守時間と活用時間を比べる。 保守が上回ったら代替案を検討する時期。
まとめ:せっかくのスクレイピングを無駄にしないために
1,000回を超えるスクレイピングから得た一番の学びは、特定のツールの良し悪しではありません。大事なのはソフトウェアではなく進め方です。 遅延読み込み、モードの選び違い、強すぎるボット対策、壊れやすいセレクタ。機能一覧を暗記するより、「なぜ失敗したか」を理解するほうがずっと役に立ちます。
シンプルな抽出作業なら、Simplescraperは十分に応えてくれます。ページが整っていて要求が控えめで、たまの手直しを気にしないなら相性は良好です。
けれど「使う時間」より「戦う時間」が長くなっているなら、セレクタのデバッグ、壊れたレシピの作り直し、プロキシの設定、手動スクロールに追われているなら、それは失敗ではなくシグナルです。ビジュアルスクレイピングだけではもう間に合わなくなっている、というシグナルです。
思い当たるなら、Thunderbitの無料枠を試してみてください。AI機能付きで6ページ、Sheets・Airtable・Notionへの無料出力も含まれます。今のワークフローと並べて、どちらがしっくりくるか見比べてください。「別のツールに切り替える」という判断自体が、最良の実践知になることもあります。
FAQ
Simplescraperは無料で使えますか?
使えます。無料プランにはローカルのブラウザスクレイピング無制限、月100クラウドクレジット、レシピ保存3つ、CSV/JSON出力が含まれます。JS対応のクラウドページは1ページ2クレジットなので、月100クレジットならクラウドで約50ページ処理できる計算です。有料は6,000クレジットのPlusが月39ドルから、15,000クレジットのProが月70ドルからです。
重いJavaScriptサイトにも対応できますか?
状況次第です。クラウドモードはJavaScriptを描画でき、シングルページアプリにも対応するとされていますが、複雑なSPA、重い動的描画、無限スクロール、強力なボット対策が重なるサイトでは結果が欠けることがあります。待機時間を適切に設定したクラウドモードで信頼性は上がるものの、動的要素の強いサイトはどのビジュアルスクレイパーにとっても依然として鬼門です。
クラウドとブラウザ、スクレイピングの違いは?
ブラウザ実行はChrome内でローカルに動き、いま開いているセッションを使えるためログイン必須サイトに強く、クレジットも消費しませんが、PCをつけっぱなしにする必要があります。クラウド実行はSimplescraperのサーバー上で無人動作し、速度もスケジュールも連携も優れますが、1ページごとにクレジットを消費し、個人アカウントの裏側にあるページには届きません。
Thunderbitのようなツールへの乗り換えを考えるべきタイミングは?
分かりやすい目安は、データを使う時間より保守に使う時間が長くなったときです。壊れたセレクタを直し続けている、プロキシ設定をいじり続けている、レシピを作り直し続けている、分析よりトラブルシューティングに時間を取られている。こうした状態なら、手動のビジュアルスクレイピングはすでに効率の限界を超えています。Thunderbitのように毎回AIがページ構造を読み直すツールなら、保守の大半を手放せます。
ブロックを避けるコツは?
三つあります。ページ間に2〜5秒の遅延を置いてペースを落とすこと(AmazonやYelpのような警戒の強いサイトはさらに長く)。クラウドIPを弾きやすいサイトではブラウザモードを併用すること(通常のアクセスに近く見えるため)。そして大規模バッチを警戒の強い対象へ当てるならプロキシローテーションを使うこと。ただし実際に使えるプロキシがプランに含まれているかは事前に確認してください。
さらに詳しく
