この記事のまとめ
サーチコンソールを MCP で Claude などの AI につなぐと、AI が自分で Search Console のデータを取りにいけるようになります。ただ、Search Console のデータを外から取る公式の口は、私が確かめた範囲では Search Console API と BigQuery への一括エクスポートです。Search Console API を呼ぶ MCP サーバーなら、取れるのは多くても API の範囲までで、それを超えることはなく、サーバーの作りによってはその一部だけになります。行数の上限も、データの遅れも、全部の行が返る保証が無いことも API と同じです。
BigQuery への一括エクスポートを設定していれば、その表を BigQuery 用の MCP サーバー経由で AI に読ませる形もありえます。こちらは API の行数の上限の外ですが、Google Cloud の設定が要り、設定した日より前には遡りません。Google が出している公式の Search Console MCP サーバーは、確かめた範囲では見つかりませんでした。第三者が作ったものを使うなら、中身と渡す権限を自分で確かめます。記事ごとの判断に要るのが数本のページとそのクエリなら、画面からエクスポートした CSV で足りる場面が多い、というのが私の考えです。
「Search Console を MCP でつなげば、AI がリライトする記事を選んでくれる」という話を見かけた。Claude や ChatGPT はふだんから使っている。けれど、つなぐと何が取れて何ができるのか、自分もつなぐべきなのか、つなぐなら何に気をつければいいのかが分からない。そんな人に向けて書いています。
読み終えるころには、Search Console API を呼ぶ MCP サーバーなら、取れるデータは多くても API の範囲までだということと、自分のブログならつながなくても CSV で足りるかどうかの見当が付くはずです。私は Search Console 用の MCP サーバーを入れて試してはいないので、特定のサーバーの使い方や良し悪しは書きません。
Search ConsoleのZIPを読み込むと、候補の判定と1記事分の診断カードを無料で確認できます。登録は不要です。ZIPが無い場合は、診断カードの見本を確認できます。
結論: API を呼ぶ MCP サーバーなら、取れるのは多くても Search Console API の範囲
AI に Search Console のデータを渡す方法は、大きく分けて2つです。画面からエクスポートした CSV を自分で渡すか、MCP などでつないで AI に取りにいかせるか。並べるとこうなります。
| くらべるところ | 画面のエクスポート(CSV)を渡す | MCP でつなぐ(中で Search Console API を呼ぶ場合) |
|---|---|---|
| 取れる数字 | クリック数・表示回数・CTR・掲載順位 | 同じ4つ |
| 行数 | 表に出る分まで(1,000行) | 1回で最大25,000行。1日分のデータにつき、プロパティ・検索タイプごとに最大5万行(クリック数の多い順) |
| ページとクエリを同じ表に | できない(ページで絞ってからクエリを出す) | できる |
| データの遅れ | あり | 同じくあり(通常2〜3日後に取れるようになる) |
| Google アカウントの権限を渡すか | 渡さない | 渡す(誰のサーバーに、どの範囲で渡すかを決める) |
つなぐと手間は減りますが、画面と違う種類の指標が増えるわけではありません。取れる範囲は API の範囲を超えることはなく、サーバーの作りによってはその一部だけになります。違いは行数と、ページとクエリを同じ表で取れることと、AI が自分で取りにいけることです。それぞれの根拠は、このあと公式のドキュメントの字で示します。
MCP とは何か: AI アプリを外のシステムにつなぐ決まり
MCP は Model Context Protocol の略です。公式サイトのWhat is the Model Context Protocol (MCP)?は、最初にこう説明しています。
MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems.
MCP は、AI のアプリを外のシステムにつなぐための、オープンソースの標準(決まり)です。同じページは USB-C のたとえを使っています。機械ごとに違う差し込み口を作らなくても、決まった形の口があればつながる、という意味です。
仕様(Specification)の概要では、登場するものが3つに分けられています。AI のアプリの側が Hosts(と、その中の Clients)、データや機能を出す側が Servers です。Servers が出せるものの1つが Tools で、仕様は "Tools: Functions for the AI model to execute"、つまり AI のモデルが実行する関数だと書いています。
Search Console にあてはめると、Search Console のデータを取りにいく機能を Tools として持った MCP サーバーがあり、Claude などの AI のアプリがそれを呼ぶ、という形になります。ここで大事なのは、MCP が決めているのはつなぎ方で、データがどこから来るかは、そのサーバーの作りで決まることです(これは仕様の概要を読んだうえでの私の理解です)。
Google 公式の Search Console MCP サーバーは、確かめた範囲では見つからなかった
2026年10月9日に、次の場所で Search Console 用の MCP サーバーを探しました。
- Search Console API のドキュメント(トップ・ガイド・リファレンス)
- Google 検索セントラルのブログの記事一覧
- Google Cloud のドキュメントにある、Google Cloud の MCP サーバーの対応製品の一覧(Supported products)
どこにも、Google が出している Search Console の MCP サーバーは見つかりませんでした。私が見ていない場所にある可能性はあるので、「無い」とは言い切りません。今後出ることもありえます。
一方、Search Console のデータを外のプログラムから取る口として、Search Console ヘルプはSearch Console API を使用して Search Console のデータをエクスポートするというページで API を案内しています(ほかに BigQuery への一括エクスポートもあります)。なので、「Search Console の MCP サーバー」として出回っているものは、中で Search Console API を呼んでいると考えるのが自然です。ただしこれは私の推測で、作りはサーバーごとに違います。
もう1つの公式の出口として、BigQuery への一括エクスポートがあります。Google Cloud の MCP サーバーの対応製品の一覧(Supported products | Google Cloud MCP servers)には BigQuery が載っているので、一括エクスポートを設定していれば、その表を BigQuery 用の MCP サーバー経由で AI に読ませる形もありえます。この場合は API の行数の上限の外で、ヘルプのBigQuery への Search Console データの一括エクスポートについてには「Search Console で利用可能な、プロパティに関するすべてのパフォーマンス データ(匿名化されたクエリを除く)を確認できます。」とあります。ただし Google Cloud の設定が要り、無料枠を超えると料金がかかります。また、設定した日より前には遡りません(詳しくはサーチコンソールのBigQueryエクスポートは必要?過去データと費用の注意点)。この形も、私は試していません。
第三者が作ったサーバーを使うなら、誰が作ったものか、中で何をしているかを自分で確かめてください。この記事では、特定のサーバーを勧めることも、良し悪しを評価することもしません。私自身、どれも入れて試していないからです。
API を呼ぶなら、取れるデータは多くても Search Console API の範囲
中で Search Console API を呼ぶサーバーなら、取れるデータは多くても API のドキュメントに書かれた範囲までで、サーバーの作りによってはその一部だけになります。ブログのリライトに関係するところを、Search Analytics: query(検索パフォーマンスのデータを取る API のリファレンス)と、パフォーマンス データを取得していますという題のガイド(英語版の題は Getting your performance data)から引きます。
数字は、画面と同じ4つ
API が返す数字は、行ごとのクリック数(clicks)・表示回数(impressions)・CTR(ctr)・掲載順位(position)です。画面の検索パフォーマンス レポートと同じ4つで、それ以外の指標はありません。行をまとめる軸(dimensions)には、国・デバイス・ページ・クエリ・検索での見え方・日付・時間を指定できます。
Search Console ヘルプも、API について「この API は、レポートで利用できるフィルタリング、並べ替え、タイプ別集計などのすべての機能に対応していますが、自由形式の SQL クエリには対応していません。」と書いています。画面でできる絞り込みがプログラムからできる、という位置づけです。
行数の上限: 1回で最大25,000行、1日分のデータにつき5万行
1回に返す行数(rowLimit)は、リファレンスの日本語版でこう決まっています。
[省略可。有効な範囲は 1 ~ 25,000。デフォルトは 1,000] 返される最大行数。結果をページ分割するには、startRow オフセットを使用します。
指定しなければ1,000行で、最大は25,000行です。それより多いときは、開始位置(startRow)をずらして何回かに分けて取ります。さらにガイドには「検索タイプ(ウェブ、画像など)ごとに 1 日あたり最大 5 万行のデータを公開」とあります。英語版ではここに、クリック数の多い順("sorted by clicks")と添えられています。Search Console ヘルプは、この上限をプロパティごととしています。つまり、1日分のデータにつき、プロパティ・検索タイプごとに最大5万行(クリック数の多い順)です。個人ブログでこの上限に届くことは多くないと思いますが、API を呼ぶ MCP サーバーでつないでも、この上限は変わりません。
全部の行が返るとは限らない(日本語版は訳がずれている)
リファレンスには、全部の行が返るかについての1文があります。英語版はこうです。
The API is bounded by internal limitations of Search Console and does not guarantee to return all data rows but rather top ones.
API は Search Console の内部の制限を受けるので、全部の行を返すことは保証せず、上位の行を返す、という意味です。ところが日本語版は「この API は Search Console の内部的な制限を受け、すべてのデータ行ではなく上位のデータ行のみを返すことが保証されています。」となっていて、「保証しない」が「保証されています」に変わっています。日本語版だけ読むと逆の印象になるので、ここは英語版を正として読んでください。ガイドの「一部のデータを落とすことがある」という記述とも合うのは英語版のほうです。
ガイドにも、ページやクエリでまとめると、計算を現実的な時間で終えるために一部のデータを落とすことがある("When you group by page and/or query, our system may drop some data")と書かれています。AI がつないで取ってきた表でも、クエリの合計が画面のグラフの合計と合わないことは起こりえます。
データの遅れも同じ
ガイドは「データは通常 2~3 日後に利用可能になります。」と書いています。また、リファレンスでは、取得の条件(dataState)を「final」にするか省略すると、「返されるデータには確定したデータのみが含まれます。」とあります。AI に「昨日の数字を見て」と頼んでも、まだ取れないか、確定していない数字が混ざるかのどちらかです。遅れが数字をどう歪めるかはサーチコンソール データ反映はいつ、遅い理由と数字の歪み方に書きました。
MCP でつなぐと楽になること
取れる範囲が API を超えなくても、つなぐ意味が無いわけではありません。CSV を渡す方法と比べて、楽になるのは次の3つです。
- ページとクエリを同じ表で取れる。画面からエクスポートした CSV では、ページの表とクエリの表が別々で、どのクエリがどのページの分かはつながりません(理由はサーチコンソールのクエリとページの違い、CSVでは2つがつながりませんに書きました)。API なら、まとめる軸にページとクエリを両方指定できます
- 1,000行より多く取れる。画面のエクスポートは表に出る1,000行までですが、API は分けて取れば、さきほどの上限まで取れます
- 落として渡す手間が無い。期間や絞り込みを言葉で頼むと、AI がサーバーの機能を呼んで取りにいきます(サーバーが対応していれば)
記事が数百本あるブログで、全記事のページとクエリの組み合わせを一度に見たいなら、つなぐ意味はあります。逆に、AI が取ってきた数字をそのまま信じてよいかは別の話です。AI は表を読み違えたり、合計を作り間違えたりすることがあるので、どのデータを使って答えたのかを示させて、元の数字と照らします。AI に数字を作らせない頼み方はキーワード選定はAIでできる?数字は作らせずGSCのクエリを渡すにまとめました。
記事ごとの判断なら、CSV で足りる場面が多い
ここからは私の判断です。個人ブログのリライトで、1本の記事をどう直すかを決めるときに要るのは、その記事のページの数字と、そのページで表示されているクエリの上位いくつかです。これは画面で取れます。ページで絞ってからクエリのタブを開けば、その1本のクエリが並びます。それをエクスポートして AI に渡せば、つながなくても同じ材料がそろいます。
エクスポートの行数については、Search Console ヘルプのSearch Console レポートからデータを直接エクスポートするにこうあります。
レポートのデータは、代表的なサンプルとなる 1,000 行分に切り捨てられています。小規模なサイトでは、ほとんどまたはすべてのデータが含まれますが、通常大規模なサイトの場合、データは 1,000 行を超えます。
1本の記事のクエリを見るのに1,000行で足りないことは、個人ブログではあまり無いと思います。ページの一覧も、表示のあったページが1,000本に届かないブログなら、全部入ることが多いはずです。エクスポートの手順と、落ちてくる ZIP の中身はサーチコンソールのCSVエクスポート手順、落ちてくるのはZIPで、使うのは1枚だけに書きました。
| こんなとき | 私なら |
|---|---|
| 直す記事を数本選んで、1本ずつ考えたい | CSV で足りる。つながない |
| 記事は1,000本未満で、月に1回くらい見直す | CSV で足りる |
| 全記事のページとクエリの組み合わせを、まとめて見たい | API でつなぐ意味がある(MCP か、BigQuery などほかの方法か) |
| 記事が1,000本を超え、表に入らないページがある | API でつなぐ意味がある |
CSV で足りる場面でわざわざつながないのは、つなぐと Google アカウントの権限をどこかに渡すことになるからです。渡さずに済むなら、そのほうが確かめることが少なくて済みます。
Search ConsoleのZIPを読み込むと、候補の判定と1記事分の診断カードを無料で確認できます。登録は不要です。ZIPが無い場合は、診断カードの見本を確認できます。
つなぐ前に決めること
それでもつなぐなら、入れる前に次の3つを決めておきます。どれも特定のサーバーの話ではなく、どのサーバーにもあてはまる話です。
1. 誰が作ったサーバーか
MCP の仕様は、Tools について次のように書いています。
Tools represent arbitrary code execution and must be treated with appropriate caution.
Tools は任意のコードの実行にあたるので、それ相応に注意して扱わなければならない、という意味です。同じ安全の章の Implementation Guidelines には、こうした安全の原則を MCP そのものは強制できない("While MCP itself cannot enforce these security principles at the protocol level")とも書かれています。つまり、MCP だから安全、ということはありません。安全かどうかは、サーバーを作った人と、それを動かすアプリの作りしだいです。作った人が分かるか、中身(ソースや説明)を読めるか、いつ更新されているかを見て、分からないものは入れません。
2. どの権限を渡すか
Search Console API のリファレンスには、検索パフォーマンスのデータを取るのに要る権限(スコープ)として、webmasters.readonly と webmasters の2つが並んでいて、どちらか1つがあれば取れると書かれています。名前のとおり、readonly は読むだけの権限です。データを読むだけなら、読むだけの権限で足りるはずなので、サーバーがそれ以上の権限を求めてきたら、なぜ要るのかを確かめます(この部分は私の考えです)。
Search Console のプロパティに、ほかの人を足す権限の話はサーチコンソールの権限、見せるだけならフルユーザーで足りますにまとめました。MCP でつなぐときに渡すのは、人に足すこの権限とは別の、プログラムにデータを読ませる許可です。どういう形で許可を出すかはサーバーによって違うので、入れる前に説明を読んで確かめます。
3. 鍵や許可を、他人に渡さない・公開しない
つなぎ方によっては、Google のログインで許可を出すのではなく、鍵のファイルや文字列を自分のパソコンに置く形のものもあります。どの形でも、その鍵や許可は、自分の Search Console のデータを読むためのものです。他人に渡さない、ブログや SNS や公開の場所に貼らない、使わなくなったら許可を取り消す。私が書けるのは、この一般的な注意までです。設定の手順は、使うサーバーと Google の公式ドキュメントで確かめてください。
よくある質問
Google 公式の Search Console MCP サーバーはありますか
2026年10月9日に、Search Console API のドキュメント、Google 検索セントラルのブログの一覧、Google Cloud の MCP サーバーの対応製品の一覧を見た範囲では、見つかりませんでした。私が見ていない場所にある可能性と、今後出る可能性はあります。「公式」と書かれたものを見かけたら、Google のドメインのページで案内されているかを確かめてください。
MCP でつなげば、AI がリライトする記事を選んでくれますか
つないで変わるのは、AI がデータを取りにいけるようになることです。どの記事を直す候補にするかの基準(掲載順位の範囲、表示回数の下限、CTR を何と比べるか)は、自分で決めて頼む必要があります。基準を決めずに「直す記事を選んで」と頼むと、AI がその場で作った基準で選ぶことになります。私が使っている基準と手順はサーチコンソールでリライト記事をどう選ぶ?迷わない判定基準と手順に書きました。
CSV を貼るのと MCP でつなぐのとで、AI の答えは変わりますか
渡る数字が同じなら、答えの材料は同じです。違いが出るのは、CSV に入らない分(1,000行を超える分や、ページとクエリの組み合わせ)を使う質問をしたときです。逆に、つないだ場合は AI がどの期間・どの絞り込みで取ってきたかが見えにくくなることがあるので、答えといっしょに、取った条件を書かせるようにします。
MCP でつなげば、画面に出ないクエリも見られますか
画面の表は1,000行で切れるので、それより下の行は API なら取れることがあります。ただし、検索数がごく少ないクエリ(匿名化されたクエリ)は API でも出てきません。API は全部の行を返すことも保証していないので、「全部見える」ようにはなりません。
MCP サーバーを入れて試しましたか
試していません。この記事に書いたのは、公式のドキュメントと仕様を読んで分かることと、そこからの私の考えです。実際の使い勝手や、特定のサーバーで何ができるかは書いていません。
まとめ
- MCP は、AI のアプリを外のシステムにつなぐための標準。決めているのはつなぎ方で、データの出どころはサーバーの作りで決まる
- Google 公式の Search Console MCP サーバーは、確かめた範囲では見つからなかった。第三者が作ったものは、誰が作ったか・中で何をしているかを自分で確かめる
- Search Console のデータを外から取る公式の口は、API と BigQuery への一括エクスポート。API を呼ぶ MCP サーバーなら、取れるのは多くても API の範囲で、それを超えることはなく、サーバーの作りによってはその一部だけ(数字は4つ、1回で最大25,000行、1日分のデータにつきプロパティ・検索タイプごとに最大5万行(クリック数の多い順)、全行は保証されない、通常2〜3日の遅れ)
- 一括エクスポートを設定していれば、BigQuery 用の MCP サーバー経由で読ませる形もありえる(API の行数の上限の外。ただし Google Cloud の設定が要り、設定した日より前には遡らない)
- つなぐと楽になるのは、ページとクエリを同じ表で取れること、1,000行より多く取れること、落として渡す手間が無いこと
- 記事ごとの判断に要るのが数本のページとそのクエリなら、画面のエクスポート(CSV)で足りる場面が多い(私の判断)
- つなぐなら、読むだけの権限で足りるかを確かめ、鍵や許可を他人に渡さない・公開しない
この記事で引いた公式の情報は、Search Console API のドキュメント2つ(Search Analytics: query のリファレンス/パフォーマンス データを取得しています)、Search Console ヘルプの3つ(Search Console API を使用して Search Console のデータをエクスポートする/Search Console レポートからデータを直接エクスポートする/BigQuery への Search Console データの一括エクスポートについて)、Google Cloud のドキュメント1つ(Supported products | Google Cloud MCP servers。最終更新 2026-10-06)、Model Context Protocol の公式ページ2つ(What is the Model Context Protocol (MCP)?/Specification の概要。版は 2026-07-28)です。2026年10月9日に取得し、引用は原文の字のままです。API の日本語版と英語版で意味がずれている箇所は、本文で断ったうえで英語版を正としました。
つなぐかどうかとは別に、ページの CSV が1枚あれば、どの記事から直す候補にするかの切り分けまではできます。その切り分けのために私が作ったツールがあるので、ここから宣伝として書きます。
サーチコンソールのエクスポートをZIPのまま置くだけで、4.0〜20.5位のページを、表示回数100回以上は通常判定、30〜99回は参考判定、30回未満は本文中心の監査に分け、この順に、同じ区分の中ではCTR機会差(表示回数 × (期待CTR − 実CTR)で出す「回相当」の数)の多い順に並べて出します。 判定と候補3記事のCTR機会差の確認、そのうち1記事分の診断カードまでは無料です。有料は2,980円(税込)の買い切りで、無料の1件を除いた3記事分の診断カードが対象です。3記事分が揃うとき(判定に出た候補が4件以上のとき)だけご案内します。生成の利用期限は購入から7日間で、月額課金や自動更新はありません。ログインも不要です。 CSVファイルそのものはブラウザの外に出ませんが、診断カードを出すときは選んだ1ページぶんの数値(URL・キーワード・順位・表示回数・CTR)を、タイトル取得を押したときは最大10件のURLを送ります。
⚠️ このツールは、Search Console に API や MCP でつなぎません。読むのは、画面からエクスポートした CSV(ZIP のままでかまいません)だけで、Google アカウントの権限も求めません。そのため、1,000行を超える分や、ページとクエリの組み合わせは判定に入りません。表示回数が0のページは扱えず、掲載順位4.0〜20.5位に入るページが無いブログでは、候補が0件になることがあります。順位やクリック数が上がることを約束するものでもありません。
Search ConsoleのZIPを読み込むと、候補の判定と1記事分の診断カードを無料で確認できます。登録は不要です。ZIPが無い場合は、診断カードの見本を確認できます。
