課題
順位計測ツール、SEOダッシュボード、または競合分析ツールを開発しているチームにとって、2026年はユニットエコノミクスが崩壊した年となりました。Googleは今年、Google検索における num=100 URLパラメータを静かに廃止しました。これは、すべてのSERPスクレイパーが1回のrequestで100件の検索結果を取得するために使用していた手法でした。現在、同じカバレッジを得るには、1回ではなく10回のrequestが必要になります。
これは目に見えるコストに過ぎません。隠れたコストはさらに深刻です。
順位計測が機能するのは、適切な国、地域、都市の実際の検索者が目にするSERPを取得できている場合のみです。ロンドンで4位にランクインしているキーワードが、エディンバラでは11位、ベルファストでは19位になることもあります。ローカル3パック、ショッピングカルーセル、ニュースボックス、ナレッジパネル、AI Overviews。すべてのSERP機能は、地理的要因やデバイスによって変化します。（Scrape.doの調査によると、2026年初頭において、クエリの約36%でAI Overviewsのテキストが表示されていました。）スクレイパーが誤った都市のproxyを経由している場合、取得した順位データは「自信たっぷりに語られるフィクション」に過ぎません。
したがって、2026年に信頼性の高いSERPプロダクトを構築するには、通信レベルで本物のブラウザに見えるrequest、監視対象の正確な都市に存在するproxy、そしてGoogleが結果の半分をクライアントサイドでロードすることを選択した場合にJavaScriptをレンダリングする機能の3つを連携させる必要があります。これら3つのうち1つでも欠ければ、データは静かに劣化していきます。
FourAのアプローチ
大規模なSERPスクレイピングにおけるボトルネックは、requestではありません。ルーティングです。
多くの内製パイプラインは、固定されたproxyプールから開始し、クエリを変数として扱います。Googleのジオターゲティングを考慮すると、実際にはその逆です。クエリはすでに手元にあります。正しく設定しなければならないのはproxyです。
私たちは、多くのチームがFourA上で以下のようなパターンを構築しているのを見てきました。
Proxy Finderは、最新の生存確認によって検証され、国、地域、都市、およびASNのタグが付けられた、稼働中のproxyプールを維持します。マンチェスター、ボストン、またはサンパウロからのrequestが必要な場合、Proxy Finderは実際にその場所に存在し、直近のチェックで生存しているproxyを選択します。この選択は、フェッチ中ではなく、フェッチの前に実行されます。このルーティングレイヤーが重要である理由の詳細については、Smart Proxy Routingに関する記事を参照してください。
Singleは、SERPのフェッチ自体を処理します。標準的なオーガニック検索結果の場合、生のHTMLで十分です。
unblocker: trueを設定すると、Googleがその週にどのシグネチャをチェックしているかを把握していなくても、ハンドシェイクレベルのアンチボットの壁をrequestが通過します。このフラグが通信上で何を行うかについては、Web Unblocker postで詳しく解説しています。Browserは、JavaScriptの実行後に重要なコンテンツが表示されるSERPを処理します。AI Overviews、拡張されたショッピングパック、ナレッジパネルのコンテンツ、固定されたローカル3パックなどです。同じURL、同じターゲットであっても、requestは完全なブラウザセッションを介して実行され、完全に描画されたページを返します。（さらにスクリーンショットも取得できるため、SEO担当者から「ダッシュボードでは3位になっているのに、ブラウザでは6位に見えるのはなぜか」と問われた際にも役立ちます。）
proxyルーティングされたAPIに対する1回の呼び出し：
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"] }
}
}
}'
これにより、地理的に正確なproxy処理（Proxy Finder）、request自体（Single）、必要に応じたJavaScriptレンダリング（Browser）という3つの関心事がきれいに分離されます。コードにproxyのヘルスチェックロジックを組み込んだり、午前3時にどのIPがまだ生きているかを推測したりする必要はありません。それは他のシステムが解決すべき問題です。
そして、すべてのresponseを (keyword, location, device, timestamp) をキーとして保存します。これこそが、順位計測における真の最小単位です。「今日、このキーワードでこの順位だった」ではなく、「この分、このデバイスで、この都市から、このキーワードでこの順位だった」という情報が必要です。このレベルの属性情報がなければ、2日間のデータが静かに矛盾し合い、どちらが正しいかを判断する方法がなくなります。厳格な業種を監視しているSEOチームは、すでにこの現実に対応しています。また、bot detection went behavioral（ボット検知の行動分析化）についても執筆しています。これは、単発のrequestシグナルではなくrequestのシーケンスを監視するサイトに対して、4つ目の軸（セッションの継続性）を追加するものです。
結果
12の都市にわたる5,000個のキーワードを1日2回監視する順位計測ツールは、従来の num=100 制度下では1日あたり約120,000回のrequestでした。単純なページネーションの計算（業界のベンチマークに基づく例示的なシナリオ）により、現在では120万回近くに達します。
この構成を3つのプロダクトスタックに移行したチームからは、一般的に以下のような報告が寄せられています。
- requestあたりのコストが40〜60%削減：独自のproxyプールを運用する場合と比較して、proxyの入れ替え、デッドIP、およびローテーション維持のためのエンジニアリング工数にコストを支払う必要がなくなったことが主な要因です。
- 都市レベルの位置情報の正確性が約70%から95%以上に向上：Proxy Finderが都市ごとにフィルタリングし、proxyを引き渡す直前のチェックで生存を確認するためです。
- AI Overviewsのための特別なパスが不要：Single経由でフェッチするキーワードを、パイプラインを書き換えることなくBrowserに昇格させることができます。仕様は同一であり、URLを入力すればresponseが出力されます。
10個のキーワードとノートPC1台だけであれば、このような仕組みは不要です。しかし、パイプラインが複数の国にまたがる数万個のキーワードを監視し、顧客が月曜日の午前9時にダッシュボードを更新し、その順位データが正確でなければならない場合には、これが必要になります。
主なまとめ
SERPモニタリングにおいて、難解な部分はかなり前からrequestそのものではなくなっています。それは常にルーティングでした。どの都市からフェッチしているのか？そのIPは生きているか？Googleは、その場所にいる実際の検索者が目にするレイアウトを返したのか、それともスクレイパーを検知したときに返す中身のないページを返したのか？
自社で構築したスタックで順位計測を行っているSEOチームにとって、2026年の課題はGoogleをスクレイピングするかどうかではありません。それはすでに実行しているはずです。課題は、ルールが予告なく変更されたときに、インフラが信頼できる順位データを生成し続けられるかどうか、そしてその状態を維持するためにエンジニアリングチームのリソースをどれだけ割く覚悟があるかということです。