Google SheetsのIMPORTXMLが制限に達したときの7つのサイン：プロキシを使った独自のパーサーを作るべき時

Wildberries、Ozon、またはAvitoで競合の価格を監視するためにGoogle SheetsのIMPORTXMLを使用している場合、早かれ遅かれ、スプレッドシートは#N/Aエラーを頻発し、データの更新が数時間遅れることがあり、時には全くデータが引き出せなくなることもあります。これはバグではなく、Google Sheetsの制限と同じIPアドレスからの大量リクエストに対するサイトの保護の結果です。本記事では、スプレッドシートがそのリソースを使い果たしたことを示す兆候を理解し、独自のプロキシを使用したパーサーにスムーズに移行する方法を解説します。

IMPORTXMLの仕組みとその利用目的

IMPORTXMLは、XPathクエリを使用してページからデータを取得し、セルに直接挿入するGoogle Sheetsの組み込み関数です。=IMPORTXML("URL"; "//span[@class='price']")の形式の数式を使用すると、コードの一行も書かずにWildberriesやOzonの商品カードから価格を引き出し、毎時自動的に更新することができます。

セラーやマーケターにとって、これは理想的な解決策に見えます: 開発者もサーバーも必要なく、すべてが慣れ親しんだスプレッドシート内で機能します。20〜30商品の小さな店舗は、実際に数年間にわたりIMPORTXMLだけで問題なく運営できることがあります。しかし、追跡するSKUの数が数百を超え、更新頻度が1日に1回ではなく1時間ごとに必要になると、システムの不具合が発生し、その機能の設定では解決できなくなります。

問題は、すべてのIMPORTXMLリクエストがGoogleのサーバーから送信されることであり、あなたのコンピュータからではないことです。Googleにはそのようなリクエスト用のIPアドレスの制限されたプールがあり、マーケットプレイスはこれらの範囲をよく知っています。リクエストが多くなると、サイトの保護が作動し、セルには価格の代わりにエラーや空の値が表示されます。

IMPORTXMLが機能しなくなった7つの兆候

より複雑な解決策に移行する前に、問題が本当に制限によるものであることを確認してください。以下は、その判断に役立つ具体的な症状です:

1. 大量の#N/A — 同時に30〜50％の数式が機能しなくなり、昨日は正常でページの構造も変わっていなかった。
2. 更新の遅延が増加 — 以前はデータが5〜10分で更新されていたのが、今ではスプレッドシートが「考え」続けて30〜40分かかるか、手動で再計算しない限り全く更新されない。
3. "Resource at url contacted too many times"エラー — 同じドメインへの内部リクエスト制限に達したことを示すGoogleからの直接的なメッセージ。
4. データが古くなっている — スプレッドシートの価格がサイトの実際の価格と異なるのは、Googleがページのキャッシュされたバージョンを返すため。
5. 行数が300〜500を超える — 1つのドキュメント内のIMPORTXML数式が多いほど、ドメインによる集団的なブロックのリスクが高まります。
6. 1時間ごと以上の更新頻度が必要 — IMPORTXMLは物理的にリアルタイム監視には適しておらず、IPのローテーションメカニズムがありません。
7. サイトが認証やキャプチャを要求する — WildberriesやOzonは、IMPORTXMLが基本的に通過できないJavaScriptのチェックを表示するページをますます頻繁に示します。

リストの2〜3項目に該当する場合、それはGoogle Sheetsの一時的なグリッチではなく、技術の構造的な限界です。その後は数式を無限に修正したり、IFERRORを追加したりして手動で再計算することができますが、手作業の量は有用なデータの量よりも早く増加します。

なぜサイトはGoogle Sheetsからのリクエストをブロックするのか

WildberriesやOzonのようなマーケットプレイスは、毎日競合、分析サービス、ボットから数百万の自動リクエストを受け取っています。サーバーを過負荷にせず、価格データを大量のパースから保護するために、いくつかの保護レベルを導入しています:

• IPによるレート制限 — 1つのアドレスから1分あたりN件以上のリクエストが来ると、IPが一時的にブロックされます。
• User-Agentの分析 — IMPORTXML用のGoogleボットからのリクエストは、ヘッダーによって通常のブラウザと簡単に区別できます。
• JavaScriptレンダリング — 一部のコンテンツはスクリプトを介して動的に読み込まれ、IMPORTXMLはJSを実行せずに元のHTMLのみを表示します。
• ジオフィルタリング — GoogleのサーバーIPからのリクエストは、「実際の購入者とは異なる」としてフィルタリングされることがよくあります。

問題は、全世界のIMPORTXMLユーザーが技術的に同じ制限されたGoogleのサーバーIPアドレスのセットを使用していることです。何千ものスプレッドシートが同時に同じWildberriesドメインにリクエストを送ると、サイトの保護は特定のユーザーではなく、全範囲をブロックし、あなたを含むすべてが影響を受けます。

IMPORTXML vs ノーコードパーサー vs 独自パーサー: 比較表

Google Sheetsの組み込み機能からの移行は、必ずしもプログラマーを雇うことを意味するわけではありません。中間的な選択肢もあります。主要なパラメータに基づいて3つのアプローチを比較します:

基準	IMPORTXML	ノーコードパーサー (Octoparse, ParseHub)	プロキシを使用した独自パーサー
コードが必要	いいえ	いいえ	はい (または契約者)
リクエストの制限	厳格で隠された	プランによる	自分で管理
IPのローテーション	利用不可	部分的に組み込まれている	プロキシを通じて完全な制御
JSページとの互換性	いいえ	はい	はい (Selenium/Playwrightを使用)
更新頻度	1時間ごとまたはそれ以下	設定可能	リアルタイムまでの任意
スケール (SKU)	200〜300まで	数千まで	実質的な制限なし

ノーコードパーサーは、開発者なしで迅速にタスクを解決するための良い中間ステップです。しかし、価格監視が一時的なタスクではなく継続的なビジネスプロセスである場合、プロキシを使用した独自のパーサーはデータの制御と他のサービスやその制限に依存しないことから投資に見合う価値があります。

マーケットプレイスの解析に必要なプロキシの種類

独自のパーサーがIMPORTXMLよりも安定して機能する主な理由は、Googleのサーバープールの代わりに異なるIPアドレス間でリクエストを分散できることです。しかし、プロキシの種類も重要です:

• データセンタープロキシ — スタートに最も速くて手頃なオプション。マーケットプレイスがまだ自動リクエストのパターンを認識していない場合に適しています。パーサーの初期テストや少数のSKUに適しています。
• レジデンシャルプロキシ — 実際の家庭プロバイダーのIPアドレスを使用しているため、WildberriesやOzonには通常の購入者のように見えます。これは、地理的制限やトラフィックパターンによるブロックを避けるための主要な選択肢です。
• モバイルプロキシ — モバイルオペレーターのIPで、マーケットプレイスは非常に慎重にブロックします。なぜなら、1つのモバイルIPの背後には同時に何千もの異なるユーザーがいることが多いからです。サイトやアプリのモバイルバージョンを介したパースが必要な場合に有効です。

WildberriesやOzonの価格監視を開始するには、レジデンシャルプロキシを各リクエストごとまたは数分ごとにローテーションする組み合わせが最適です。これにより、レート制限に引っかかるリスクが減少し、数百の異なるアドレス間で数千のリクエストを分散させ、さまざまな地域の通常のユーザーの行動を模倣することができます。

独自のパーサーへの段階的移行計画

IMPORTXMLからの移行は、作業を完全に停止する必要はありません — 新しいパーサーがテストされている間、スプレッドシートをバックアップチャネルとして残しておくことができます。

1. IMPORTXMLで使用されていたSKUとXPathセレクターのリストを固定します — これは新しいソリューションのためのデータマップです。
2. パーサーの形式を選択します: プログラマーなしで迅速に開始できるノーコードサービス（Octoparse、ParseHub、Apify）または、チームに開発者やフリーランサーがいる場合はPython/Node.jsのスクリプト。
3. IPのローテーションを伴うプロキシを接続します。これがないと、新しいパーサーはIMPORTXMLと同じブロックに直面し、ただ少し遅れるだけです。
4. リクエストのスケジュールを設定し、リクエスト間に小さなランダムな遅延（2〜5秒）を設けます — これにより、パターンによる保護が作動する可能性が減ります。
5. データをGoogle Sheetsに戻すためにGoogle Sheets APIまたはZapier/Makeのようなサービスを使用し、チームのレポートやダッシュボードを壊さないようにします。
6. 10〜15％の商品でテストを行い、古いIMPORTXMLのデータと比較して精度を確認し、完全に切り替える前に確認します。
7. エラーに対するアラートを設定します — キャプチャや403コードを受け取った場合にプロキシをすぐに切り替えたり、リクエストの頻度を下げたりするために、Telegramやメールで通知します。

プロキシを使用したPythonの最小限のパーサー

チームに開発者がいる場合、基本的なパーサーは実際には数十行のコードで済みます。以下は、requestsライブラリを使用してプロキシ経由で商品ページをリクエストする簡略化された例です:

import requests
import time
import random

proxies = {
    "http": "http://login:password@proxy_host:port",
    "https": "http://login:password@proxy_host:port",
}

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                  "AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36"
}

urls = [
    "https://example-marketplace.com/product/12345",
    "https://example-marketplace.com/product/67890",
]

for url in urls:
    try:
        response = requests.get(url, headers=headers, proxies=proxies, timeout=10)
        if response.status_code == 200:
            # その後、BeautifulSoupやlxmlを使用して価格をパース
            print(f"OK: {url}")
        else:
            print(f"{url}のステータス {response.status_code}")
    except requests.exceptions.RequestException as e:
        print(f"リクエストエラー: {e}")

    time.sleep(random.uniform(2, 5))  # リクエスト間の待機時間

WildberriesやOzonのようなJavaScriptを介して価格が動的に読み込まれるページの場合、通常のrequestsの代わりに、実際のブラウザのようにページをレンダリングできるSeleniumやPlaywrightが必要です。また、プロキシを起動パラメータを通じて渡すこともサポートしています。

起動前のチェックリスト

結論

IMPORTXMLは、商品リストが小さく、更新頻度が重要でない間は素晴らしいツールです。しかし、大量の#N/A、増加する遅延、制限に関する直接的なエラーメッセージが表示されると、Google Sheetsの組み込み機能がアーキテクチャの限界に達したことを示すサインです。これは、スプレッドシートの設定では技術的に修正できません。なぜなら、問題はGoogleの制限されたIPアドレスプールにあり、マーケットプレイスはそれを全体としてブロックします。

ノーコードサービスやPythonスクリプトへの移行は、リクエストのIPアドレスを制御することで問題を解決します。Wildberries、Ozon、またはAvitoの価格を定期的に監視する予定がある場合は、レジデンシャルプロキシから始めることをお勧めします。これは、実際の購入者のトラフィックに似ているため、ブロックのリスクが最も低くなります。初期のテストには、より手頃なデータセンタープロキシを使用し、モバイル版のサイトを対象とするシナリオにはモバイルプロキシを検討してください。