Google SERP と AI オーバービューのパースニング 2026: ガイド

```html

まだ1年前、Googleの検索結果を取得するにはGETリクエストにnum=100のパラメータを付けるだけで、100件の結果が純粋なHTMLで返ってきました。しかし、2026年にはそれは通用しません。GoogleはJavaScriptなしでのアクセスを遮断し、1ページあたりの結果数を100件から減らし、非同期でレンダリングされ、すべてのIPから見えるわけではないAI Overviewsというブロックを追加しました。新しい条件下でSERPを収集する方法、隠れた罠、そしてプロキシの種類の選択がパーサー自体よりも重要になった理由を探ります。

このガイドは誰のためのものか

検索結果のパース（SERPスクレイピング）は、SEOのポジションだけではありません。今日、これを使用するのは：

SEO専門家やエージェンシー — オーガニック、フィーチャードスニペット、「人々はまた質問する」、ローカル検索結果、そしてサイトがAI Overviewsに含まれているかを追跡します。
市場アナリスト — Googleが商業的なリクエストに対してAIブロックで誰を引用しているか、競合他社の最初のページがどのように変化しているかを監視します。
AIおよびデータチーム — RAGシステム、モデルのトレーニング、ファクトチェックのためのデータソースとしてSERPを収集します。

全員が共通の問題を抱えています：2026年、Googleは自動トラフィックと生のトラフィックを積極的に区別し、正しいインフラがなければデータ収集は最初の数十件のリクエストで壊れてしまいます。

何が変わったか：Googleによるスクレイパーへの3つの打撃

ガイドが正直であるために、古い指示がもはや機能しない理由から始めましょう。

2025年1月 — SearchGuard。 GoogleはJavaScriptチャレンジシステムを展開しました：通常のHTTPリクエストをrequestsやhttpxを通じて送信すると、HTMLではなくチャレンジページが返されます。JavaScriptを実行しなければ、結果を見ることはできません — 直接的なパースは瞬時に失敗します。

2025年9月 — num=100の終了。 Googleは1回のリクエストで100件の結果を返すパラメータを削除しました。今やトップ100は10件の個別リクエストでページネーションが必要です。深い監視には、実質的にリクエスト数が10倍に増えることを意味します（それに伴い、プロキシと予算への負荷も増加します）。

2025年12月 — 法的圧力。 2025年12月19日、GoogleはSerpApiに対してDMCAの苦情を提出し、SearchGuardは「技術的保護手段」であり、その回避は逆行規制に該当すると主張しました。前例はまだ解決されていませんが、トーンを設定しています：Googleのグレーなパースは技術的にも法的にも高くなっています。

特に注目すべきは、Googleの公式カスタム検索APIが終了することです — 現在のクライアントには2027年1月1日までに移行の締切が通知されています。つまり、「合法的な」代替手段も狭まっています。

検索結果の主な新機能 — AI Overviews

AI Overviews（以前はSGE）は、検索結果の上部に表示されるAIによって生成された要約で、ソースへのリンクが含まれています。スクレイピングにおいて、これは2026年の最も難しい要素です。

数が多い。 Ahrefsのデータによれば、AI Overviewsは約30%のリクエストに出現します。後の推定（Olostep）では、すべてのリクエストの最大48%および情報リクエストの最大80%を占めるとされています。このブロックを無視することは、明らかに不完全な検索結果を収集することを意味します。

非同期でレンダリングされる。 ブロックは3つの状態で存在します：HTMLで即座に返される（最も少ないケース）、メインページの数秒後にJavaScriptを介して読み込まれる（最も一般的なケース）、またはまったく表示されない。遅延読み込みの場合、生のHTTPレスポンスには空のコンテナが含まれ、コンテンツは後で引き出されるため、パーサーは待つ必要があります（実際には、ブラウザの自動化で約8秒かかります）。

すべてのIPから見えるわけではない。 ここが古いガイドが黙っている重要なポイントです：GoogleはAI検索の優先オーディエンスとしてモバイルユーザーを考慮しています。実際には、データセンターIPからはAI Overviewがまったく返されないことが多いのに対し、同じリクエストがモバイルオペレーターを介して送信されると完全なブロックが返されます。トップのアグリゲーターでさえ不完全さを認めています：SerpApiは2026年初頭にAI Overviewsの成功率が約68%であると報告していました。

ステップバイステップの解説：2026年にSERPを収集する方法

ボリュームを決定します。 1日あたり約100リクエストまでなら、自分のブラウザ自動化で実行可能です。100から10,000の間では、管理されたパーサーまたはSERP-APIが必要です。10,000を超える場合、エンタープライズインフラストラクチャとバッチ、ウェブフックが必要です。これが今後のスタックを決定します。
正しいURLを収集します。 基本のエンドポイントは/search、主要なパラメータはq（リクエスト、URLエンコーディング）、hl（インターフェースの言語）、gl（検索結果の国）、start（ページネーション：start=10 — 2ページ目、start=20 — 3ページ目など）です。覚えておいてください：num=100はもはや機能しません。深さはページネーションのみで取得します。
ブラウザレンダリングを使用します。 JavaScriptなしでは結果が得られないため、基本のスタックはPlaywrightまたはヘッドレスChromiumを使用したSeleniumです。自動化マーカーを必ず削除してください（フラグ--disable-blink-features=AutomationControlled）、さもなければアンチボットはナビゲーターのプロパティから管理されたブラウザを特定します。
AI Overviewを待ちます。 ページが読み込まれた後、すぐにDOMを取得しないでください：networkidleが安定するまで待ち、ブロックの読み込みを待ちます（目安は最大8秒）。ブロックの存在は、CSSクラスではなく「AI Overview」というタイトルのテキストでより確実に判断できます — Googleのクラスは動的で変わるため（条件付きのKevs9、Y3BBEは今日一つ、明日別のものになります）。
クラスではなく構造に基づいてパースします。 オーガニックは見出しタグ（h3）とセマンティクスに基づいて取得し、脆弱なクラス名に基づいてはなりません。2026年の検索結果から利用可能なのは：オーガニック結果、フィーチャードスニペット、「人々はまた質問する」、関連リクエスト、ナレッジグラフ、ローカルパック、広告、AI Overview内の引用です。
IPをローテーションし、遅延を設けます。 リクエスト間に現実的な間隔（4〜12秒）を設け、約5分ごとにIPを変更し、都市やオペレーターを変えます。あまりにも均一なリズムと1つのIPは、キャプチャに至る最も早い道です。

落とし穴

「空の」AI Overview。 読み込み後すぐにDOMを取得すると、遅延ブロックは空になります — そしてそれがないと思ってしまいます。常に待機と再確認を計画してください。
一回限りのセッションでの読み込み。 一部のAPIでは、遅延AI Overviewを読み込むためのセッションキーが一回限りで、約60秒間有効です — 後で再利用することは期待しないでください。
データセンターでの無駄な節約。 安価なデータセンターIPは、5〜10リクエストでキャプチャを引き起こし、AI Overviewsを表示しません。節約は不完全なデータと失われた時間に繋がります。
脆弱なセレクター。 CSSクラス名に依存すると、パーサーは次のリデザインで壊れます。テキストと構造を重視してください。
均一なリクエストのフィンガープリンティング。 すべてのストリームで同じUser-Agent、タイミング、ヘッダーはボットネットを示します。IPと同様にフィンガープリンティングを多様化してください。

どのタイプのプロキシを選ぶべきか

2026年には、プロキシがパーサーではなく、完全な検索結果を見られるかどうかを決定します。タスクに基づいて分解します。

モバイルプロキシ — AI Overviewsおよび最も「重い」リクエスト向け。 GoogleがAIブロックを最初にモバイルオーディエンスに提供するため、実際のオペレーターIP（T-Mobile、Verizon、Vodafoneなど）は、AI Overviewをトリガーするのに最も安定しており、観察によれば50〜200リクエストまで摩擦が発生しませんが、データセンターでは5〜10リクエストで摩擦が発生します。さらに、モバイルCGNAT-IPは数百の生の加入者と同じアドレスを共有しているため、Googleはそれを禁止することを恐れています。もしあなたのタスクがAI Overviewsを収集することや最も保護されたSERPを監視することであれば、モバイルプロキシから始めてください。

レジデンシャルプロキシ — オーガニックとボリュームのための作業馬。 通常の検索結果、ポジション、フィーチャードスニペット、ローカルパックを収集するために、レジデンシャルIP（家庭プロバイダーのアドレス）は、価格と成功の比率が最も良好です。実際のユーザーと区別が難しく、ローテーションにより一つのアドレスからの収集をスケールアップできます。AI Overviewが焦点でなく、ボリュームと地理が重要な場合の最適な選択は、ローテーション付きのレジデンシャルプロキシです。

データセンター — 下書き用にのみ。 迅速かつ安価ですが、2026年のGoogleに対しては限られたリクエストしか生き残らず、AIブロックを表示しません。パーサーのロジックをデバッグするのには適していますが、実際の収集には適していません。

特定のタスクに対して何を選ぶべきか不明な場合は、2026年のレジデンシャルとモバイルプロキシの比較を確認して始めてください：どのタイプがコストを節約し、どのタイプがデータを節約するかを詳しく説明しています。

結論

2026年のGoogleのパースは「パーサーを書く」というタスクではなくなりました。SearchGuardはJavaScriptのレンダリングを強制し、num=100の廃止はリクエスト数を10倍にし、AI Overviewsは主にモバイルIPから見えるブロックを追加し、遅延で読み込まれます。技術的にはすべて解決可能です：ブラウザ自動化、構造に基づくパース、合理的な間隔、ローテーション。しかし、収集の完全性と安定性を支える基盤は、AI Overviewsと保護されたリクエスト用のモバイルプロキシ、オーガニックとボリューム用のレジデンシャルプロキシです。自分のタスクに合ったプロキシのタイプから始めれば、パーサーはキャプチャに躓くことはなくなります。