← すべての記事
ユースケース 読了時間 1 分

num=100廃止後の大規模なSERPモニタリング

num=100の廃止により、大規模なGoogle順位計測は困難になりました。SEOエンジニアリングチームが2026年に向けてSERPモニタリングインフラを再構築する方法を解説します。

serp-monitoringrank-trackingseoweb-scrapinggoogle-search

課題

検索順位追跡ツール、SEOダッシュボード、競合インテリジェンスツールを構築しているチームにとって、2026年はユニットエコノミクスが崩壊した年となりました。Googleは今年、Google検索においてnum=100 URLパラメータを密かに廃止しました。これは、すべてのSERPスクレイパーが1回のリクエストで100件の結果を取得するために使用していた手法です。現在、同じカバレッジを得るには1回ではなく10回のリクエストが必要になります。

これは目に見えるコストにすぎません。隠れたコストはさらに深刻です。

検索順位の追跡は、適切な国、地域、都市において実際の検索ユーザーに見えるSERPを正確に取得できて初めて成り立ちます。ロンドンで4位のキーワードが、エディンバラでは11位、ベルファストでは19位になることもあります。ローカルパック（3-pack）、ショッピングカルーセル、ニュースボックス、ナレッジパネル、AI Overviews。すべてのSERP機能は地域やデバイスによって変化します。(Scrape.doの調査によると、2026年初頭にはクエリの約36%にAI Overviewのテキストが表示されていました。) スクレイパーが誤った都市のプロキシを経由した場合、取得される順位データは信憑性のない不正確なものになります。

そのため、2026年に実用に耐えうるSERP製品を提供するには、3つの要素を連携させる必要があります。ワイヤーレベルで本物のブラウザに見えるリクエスト、監視対象の正確な都市に位置するプロキシ、そしてGoogleが検索結果の半分をクライアントサイドで読み込む場合にJavaScriptをレンダリングする機能です。どれか1つでも欠ければ、データの精度は気づかないうちに低下します。

FourAのアプローチ

大規模なSERPスクレイピングにおけるボトルネックは、リクエスト自体ではなくルーティングにあります。

内製のデータパイプラインの多くは固定のプロキシプールから構築を始め、クエリを変数として扱います。しかし、Googleの地域ターゲティングにおいては順序が逆になります。クエリは固定された入力情報であり、適切に制御すべき変数はプロキシ側です。

FourA上でこの仕組みを実装するチームの多くは、概ね以下のようなパターンを採用しています。

  1. Proxy Finderは、最新の生存確認によって検証され、国、地域、都市、ASNのタグが付与されたプロキシの稼働プールを維持します。マンチェスター、ボストン、サンパウロからのリクエストが必要な場合、Proxy Finderは実際にその都市に存在し、直近のチェックで生存が確認されたプロキシを選択します。この選択処理はフェッチ中ではなく、フェッチの前に実行されます。このルーティング層が重要である理由の詳細は、スマートプロキシルーティングの記事を参照してください。

  2. Singleは、SERPのフェッチ処理自体を実行します。通常のオーガニック検索結果であれば、生のHTMLで十分です。unblocker: trueを設定すれば、Googleがその時点で検証しているシグネチャを個別に把握していなくても、リクエストに最新のブラウザシグネチャが付与されます。このフラグがワイヤーレベルでどのような挙動をするかについては、Web Unblockerの解説記事で詳しく解説しています。

  3. Browserは、JavaScriptの実行後に重要なコンテンツが表示されるSERPを処理します。AI Overviews、展開されたショッピングパック、ナレッジパネルのコンテンツ、固定表示されるローカルパックなどが該当します。同一のURLとターゲットに対し、リクエストを完全なブラウザセッション経由で実行し、完全に描画されたページを返します。(さらにスクリーンショットも取得できるため、ダッシュボードでは3位と表示されているのにブラウザでは6位に見えるとSEO担当者から指摘された際のエビデンスとしても役立ちます。)

プロキシルーティング対応APIへの単一呼び出しの例:

curl -X POST "https://api.foura.ai/api/proxy" \
  -H "x-api-key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "maxTries": 3,
    "timeout_ms": 20000,
    "request": {
      "method": "GET",
      "url": "https://www.google.co.uk/search?q=plumber+manchester&hl=en-GB",
      "unblocker": true,
      "validate": {
        "status": { "accept": [200] },
        "data": { "fail": ["unusual traffic", "/sorry/", "captcha"] }
      }
    }
  }'

これにより、3つの関心事が明確に分離されます。地域に応じた適切なプロキシ処理（Proxy Finder）、リクエスト自体（Single）、そして必要な場合のJavaScriptレンダリング（Browser）です。コード側でプロキシのヘルスチェックロジックを保持したり、深夜3時にどのアドレスがまだ生存しているかを推測したりする必要はありません。それは別のレイヤーが処理すべき問題です。

そして、すべてのレスポンスを(keyword, location, device, timestamp)をキーにして保存します。これこそが順位トラッキングにおける真のデータ単位です。「本日このキーワードでこの順位だった」ではなく、「この日時のこの分、この都市から、このデバイスにおいて、このキーワードでこの順位だった」と記録します。このレベルの属性情報がなければ、2日間のデータが矛盾した場合にどちらが正確だったのか判断できなくなります。保護された業種を監視しているSEOチームは、すでにこの問題に直面しています。リクエスト単位のシグナルではなくリクエストシーケンスを監視するサイト向けに、4つ目の軸（セッション継続性）を追加するBot検出の行動ベース化についても解説しています。

結果

従来のnum=100環境では、12都市にわたって5,000キーワードを1日2回監視する順位トラッカーは1日あたり約120,000リクエストでした。ページネーションの計算上、現在は約120万リクエストに達します（業界標準に基づく試算）。

この構成を3製品スタックに移行したチームからは、以下のような報告が寄せられています。

  • リクエスト単価が40〜60%削減: 自前のプロキシプールを運用する場合と比較して、プロキシの入れ替えコスト、無効なIP、ローテーション保守のためのエンジニアリング工数が不要になったことが主な要因です。
  • 都市レベルの位置精度が約70%から95%以上に向上: Proxy Finderが都市単位でフィルタリングし、プロキシを引き渡す直前のチェックで生存確認を行うためです。
  • AI Overviews向けの専用パイプラインが不要: Singleで取得していたキーワードは、パイプラインを書き換えることなくBrowserへ移行できます。URLを入力してレスポンスを受け取るというインターフェースは同一です。

キーワードが10個だけでラップトップ上で完結するなら、この仕組みは不要です。しかし、複数の国にまたがる数万件のキーワードを監視し、月曜日の朝9時に顧客がダッシュボードを更新した際、正確な順位データを提示する必要がある場合には不可欠となります。

主なポイント

SERP監視における難所は、もはやリクエストの送信自体ではありません。ルーティングです。どの都市から取得しているか。そのIPは生存しているか。Googleは現地の実際の検索ユーザーが見るレイアウトを返しているか、それともスクレイパーを検知した際のダミー画面を返しているかです。

独自構築したスタックで順位トラッキングを運用しているSEOチームにとって、今後の論点はGoogleをスクレイピングすべきかどうかではありません。それはすでに実施しているはずです。重要なのは、予告なしに仕様が変更されてもインフラが信頼性の高い順位データを生成し続けられるか、そしてその維持にどれだけのエンジニアリングリソースを割くかという点です。