AIエージェントをGoogle Search Consoleに連携する6つの方法

AIエージェントにGoogle Search Consoleのデータを渡す現実的な方法は6つあります。ホスティング型のOAuthコネクタ、コミュニティ製のMCPサーバー、Search Console APIの直接利用、BigQueryへの一括エクスポート、スプレッドシート経由の連携、そしてエージェントを使わずSearch Console自体に組み込まれたAI設定機能を使う方法です。所要時間は2分からほぼ丸1日までさまざまで、どれを選ぶべきかは「16か月より前の履歴が必要かどうか」で決まります。

この最後のポイントこそが分かれ道なので、先に押さえておきましょう。Search Analytics APIが1回のリクエストで返せるのは最大25,000行で、保持される履歴は16か月分です。16か月を過ぎたデータは消えます。見えなくなるのではなく、削除されるのです。もっと長い履歴が欲しいなら、この記事で紹介する方法のうち対応できるのは1つだけ。しかも、必要になる前に始めておく必要があります。

方法1：ホスティング型のOAuthコネクタ

セットアップ：2〜5分。コード不要。

SEOエージェント製品にGoogleアカウントへのアクセスを許可し、プロパティを選ぶだけです。接続情報はサーバー側に保存され、クエリのたびに再利用されます。ほとんどのマーケターにはこの方法がおすすめです。手抜きだからではありません。トラブルの起きやすいポイントをツール側で処理してくれるからです。よくできたコネクタは、接続がないことを検知すると推測で進めずに接続を促し、複数のプロパティを持っている場合はどれを使うかを判別し、25,000行の上限を超える分も意識させずにページ送りで取得してくれます。

私たち自身の実装では、Search Consoleツールは読み取り専用としてタグ付けされており、最初の呼び出し時に有効な接続があるかを確認します。接続がなければ、連携設定画面へのディープリンク付きの対話型接続プロンプトを返し、戻ってきたら会話を再開します。

トレードオフ：使えるのはベンダーが用意したツール群だけです。ベンダーが実装していない形のクエリを投げたくても、それはできません。

方法2：Search Console用のMCPサーバー

セットアップ：15〜45分。開発作業に慣れていることが前提。

Model Context Protocol（MCP）は、AIアシスタントを外部システムにつなぐためのオープンなクライアント／サーバー標準です。そのため、Claude Desktop、Claude Code、CursorなどMCPに対応したクライアントであれば、Search Console用のサーバーを直接呼び出せます。

重要な注意点があります。GoogleがMCPサーバーを公式に公開しているGA4とは違い、Search Console向けの公式Google MCPサーバーは存在しません。あるのはコミュニティによる実装で、選択肢は充実しています。たとえばmcp-server-gscは、25,000行の上限までの検索アナリティクスデータの取得と正規表現によるフィルタに対応しており、読み取り専用です。

設定は、MCPクライアントに認証情報付きでサーバーを指定するJSONブロックを書くだけです。

{
  "mcpServers": {
    "search-console": {
      "command": "npx",
      "args": ["-y", "mcp-server-gsc"],
      "env": { "GOOGLE_APPLICATION_CREDENTIALS": "/path/to/service-account.json" }
    }
  }
}

トレードオフ：検索データへの認証情報をコミュニティ製パッケージに預けることになります。ソースコードを読み、できるだけ読み取り専用のスコープを使い、バージョンを固定しましょう。また、サーバーが実装しているプロトコルのバージョンが、クライアント側の想定と合っているかも確認してください。

方法3：サービスアカウントでSearch Console APIを使う

セットアップ：1〜3時間。コードを書く作業です。

自由度は最も高い反面、手間も最もかかります。手順は次のとおりです。

1. Google Cloudプロジェクトを作成する（既存のものを使ってもOK）。
2. そのプロジェクトでSearch Console APIを有効にする。
3. サービスアカウントを作成し、JSONキーをダウンロードする。
4. サービスアカウントのメールアドレスを、Search Consoleのプロパティ自体にユーザーとして追加する。権限は「制限付き」（読み取り専用）にします。
5. キーを使ってエージェントを認証し、searchanalytics.queryを呼び出す。

誰もが忘れるのがステップ4です。Cloud側で認証情報を作成しても、それだけではプロパティへのアクセス権は付与されません。この2つは別々の権限システムで、2つ目を飛ばすと汎用的な403エラーが返ってきます。しかもプロパティのアクセス権の問題ではなく、APIの有効化の問題のように見えてしまいます。一度はこれで20分ほど無駄にすると思っておきましょう。

ページ送りを含む最小限のクエリ本文は次のようになります。

{
  "startDate": "2026-04-01",
  "endDate":   "2026-06-30",
  "dimensions": ["query", "page"],
  "rowLimit":  25000,
  "startRow":  0
}

1ページごとにstartRowを25,000ずつ増やし、要求した行数より少ないレスポンスが返ってきたら止めます。それ以外の部分、つまり割り当て（クォータ）の管理、リトライ、トークンの更新などは、すべて自分で作ることになります。

トレードオフ：完全な柔軟性が手に入る代わりに、クォータ管理、ページ送り、リトライ、トークン更新を自分で抱えることになります。どのコネクタにもない形のクエリがエージェントに必要な場合や、データを自社インフラの中にとどめておく必要がある場合に選びましょう。

方法4：BigQueryへの一括エクスポート

セットアップ：約1時間。さらに最初のエクスポートが届くまで最大48時間。

16か月問題を解決できるのはこの方法だけです。そして、まだ必要なくても今日のうちに設定しておくべき方法でもあります。履歴は過去にさかのぼって溜まるのではなく、設定した時点から先に向かって溜まっていくからです。

Googleの一括データエクスポートに関するドキュメントによると、手順は次のとおりです。

1. 課金が有効になっているGoogle Cloudプロジェクトを作成または選択する。これは必須です。
2. そのプロジェクトでBigQuery APIとBigQuery Storage APIを有効にする。
3. Search Consoleのサービスアカウントに、プロジェクトに対する2つのロール、BigQuery Job User（BigQuery ジョブユーザー）とBigQuery Data Editor（BigQuery データ編集者）を付与する。
4. Search Consoleで「設定」から「一括データエクスポート」を開き、CloudプロジェクトIDとデータセットのロケーションを入力する。
5. 待つ。最初のエクスポートは48時間以内に届き、その後は毎日実行されます。

本格的に導入する前に知っておきたい点が2つあります。まず、匿名化されたクエリはプライバシー保護のためエクスポートから除外されます。そのため、BigQueryの合計値はSearch Consoleの画面と完全には一致しません。これは想定どおりの挙動でバグではありませんが、そう教えておかないと、両者を比較したエージェントは存在しない食い違いを報告してしまいます。次に、データセットのロケーションは後から変更できず、変えるにはやり直すしかありません。慎重に選びましょう。

データがBigQueryに入れば、エージェントはSearch Console APIではなくSQLでクエリを実行します。これで行数の上限と保持期間の制約が一気になくなります。小規模サイトならコストはBigQueryの無料枠に収まりますが、大規模サイトでは無視できない金額になります。テーブル全体をスキャンせず、パーティションの日付列で絞り込むようエージェントに指示しておきましょう。大規模プロパティの3年分のデータに対して条件なしのSELECT *を書くエージェントは、忘れられない請求書を生み出します。

トレードオフ：費用がかかり、全選択肢の中で最もインフラの手間が大きく、初日には何も得られません。それでも、複数年にわたる分析を実現できる唯一のルートです。

方法5：スプレッドシート経由の連携

セットアップ：10〜20分。コード不要。

アドオンやApps Scriptを使ってSearch Consoleのデータを定期的にGoogleスプレッドシートへ書き出し、スプレッドシートにアクセスできるエージェントにそのシートを読ませる方法です。エージェントがすでにスプレッドシートを読めて、今日の午後にはデータを渡したい、というときの現実的な選択肢です。

トレードオフ：データの鮮度は最後のエクスポート時点のままで、シートを設定した人があらかじめ絞り込んだデータしかありません。さらに、誰も想定していなかったクエリでエージェントが深掘りすることもできません。それこそがエージェントを導入した理由のはずなのに、です。あくまでつなぎの手段と考えましょう。

方法6：接続しないという選択肢

セットアップ：不要。

Search ConsoleにはAIが組み込まれています。GoogleのAIを活用した設定機能（AI-powered configuration）を使えば、やりたい分析を自然な言葉で説明するだけで、レポートのフィルタ、比較、指標の選択に変換してくれます。「/blog を含むページの今四半期のトラフィックを、昨年の同じ四半期と比較して」と頼めば、自動で設定されます。

Googleがはっきり示している制約も知っておきましょう。対象は検索結果の「検索パフォーマンス」レポートだけで、DiscoverやGoogleニュースには使えません。フィルタ、比較、指標は設定してくれますが、表の並べ替えやデータのエクスポートはできません。また、AIがリクエストを誤解する可能性があるとGoogle自身が注意を促しているので、分析結果を信用する前に、適用されたフィルタを確認する必要があります。さらに、これはあくまで設定機能です。GA4とSearch Consoleをまたいで推論したり、原因を調べたりはしてくれません。

これとは別に、Search ConsoleにはGoogleのAI面からのトラフィックを対象とした生成AIのパフォーマンスレポートも加わりました。知りたいのがAI面での露出であれば、これが信頼できる一次情報であり、サードパーティの推計では代わりになりません。

結局どの方法を選ぶべき？

方法	セットアップ	16か月超の履歴	向いているケース
ホスティング型コネクタ	2〜5分	不可	今日すぐ答えが欲しいマーケター
MCPサーバー	15〜45分	不可	すでにMCPクライアントを使っている開発者
APIを直接利用	1〜3時間	不可	独自形式のクエリ、データを社内にとどめたい場合
BigQueryエクスポート	1時間＋48時間	可	複数年の分析、大規模サイト
スプレッドシート連携	10〜20分	不可	一時的な回避策
組み込みのAI設定	不要	不可	レポート作成の時短（原因調査には不向き）

多くのチームが最終的に落ち着くのは、日々の疑問にはホスティング型コネクタを使い、その裏でBigQueryエクスポートを静かに回し続けておく組み合わせです。そうすれば1年後には、他の誰も持っていない履歴データが手元にあります。この2つは競合しません。

エージェントにSearch Consoleへのアクセス権を渡しても安全？

3つの条件を守れば、おおむね安全です。読み取り専用で付与すること。Search Consoleの権限にはサイトマップの送信や削除リクエストも含まれますが、エージェントにはどれも必要ありません。個人のOAuth許可より、範囲を絞ったサービスアカウントを優先すること。そうすれば、アクセスの取り消しが特定の社員のアカウントに左右されません。そして書き込み系ツールとWeb取得系ツールを分けておくこと。競合のページを読んだエージェントは、外部の誰かが書いたテキストを、あなたの指示と同じコンテキストウィンドウに取り込んでいます。そのページに命令が仕込まれていれば、無防備なエージェントはそれに従ってしまいかねません。私たちのランタイムでは、取得したコンテンツを信頼できないものとして隔離し、そのターンを「汚染済み」としてマークしたうえで、人間が承認しない限り、そのターンの残りでは書き込みタグの付いたツールをすべて拒否します。Search Consoleへのクエリは読み取りタグなので、どちらにしても安全です。

よくあるセットアップエラーとその本当の意味

症状	よくある原因	対処法
APIは有効なのに、すべてのクエリで403が返る	サービスアカウントがプロパティのユーザーとして追加されていない	Search Consoleのプロパティ設定でそのメールアドレスを「制限付き」権限で追加する
エラーは出ないが結果が空	プロパティURLの不一致（ドメインプロパティとURLプレフィックスプロパティの違い、または末尾のスラッシュ漏れ）	Search Consoleに表示されているとおりにプロパティの文字列をコピーする
エージェントが妙にきりのいい合計値を報告する	結果が25,000行の上限で打ち切られたのに、完全なデータとして扱われている	startRowでページ送りするか、打ち切りがあれば明示するようエージェントに求める
数値がSearch Consoleの画面と違う	匿名化されたクエリがBigQueryエクスポートから除外されている、または日付の区切りが異なる	BigQueryなら想定どおり。それ以外ならタイムゾーンと絶対日付を確認する
一括エクスポートを設定したのにデータセットが現れない	まだ48時間以内、またはプロジェクトで課金が有効になっていない	待ってから、課金設定と2つのIAMロールを確認する
MCPサーバーは起動するがツールが1つも表示されない	認証情報のパスが間違っている、またはクライアントとのプロトコルバージョンの不一致	envのパスが正しく解決されるか、サーバーが対応する仕様バージョンを確認する

どの方法を選んでも押さえておきたい2つのこと

ページ送りは正直に扱うこと。25,000行を要求して、ちょうど25,000行を受け取り、その合計を報告するエージェントは、実は打ち切られたデータを報告しています。ページ送りをするか、結果が上限に達したことを明記するよう指示しましょう。

日付は絶対日付で指定すること。「先月」のような相対的な表現は、プロパティのタイムゾーンとクエリを実行した時点を基準に解釈されます。自信満々で筋は通っているのに間違っている、というSearch Console分析の原因として最も多いのがこれです。

接続ができたら、エージェントがSearch Consoleのデータから実際に何を見つけられるかで実行する価値のある分析を紹介しています。また、Autopilotは方法1で説明したホスティング型コネクタのルートを実装しています。