Claude Code

Search ConsoleのMCPをClaude Code・Claude Desktopに接続してSEO分析する手順

この記事でわかること

Google Search ConsoleとGA4をMCPサーバー経由でClaudeに接続すると、これまで管理画面を行き来しながらやっていた分析が、会話のまま片付くようになります。具体的には、次のようなことが数十秒で出せるようになります。

  • 掲載順位4〜10位でCTRが2%を切っているページの抽出（＝リライトの優先順位リスト）
  • エラーメッセージ形式のクエリだけ、あるいは疑問文クエリだけを正規表現で切り出した分析
  • Search Consoleのクリック数と、GA4の滞在時間・PV/セッションを突き合わせた記事評価
  • AI Overview経由の流入がどう推移しているかという、AIO対策・LLMO対策の効果測定

管理画面のUIは1回の表示が1,000行までですが、APIなら25,000行。フィルタも正規表現が使えます。「やりたかったけど手間に見合わないので諦めていた分析」が、諦めなくてよくなるというのが実際の変化です。

接続作業そのものは10分程度で終わります。つまずくとすれば、サービスアカウントのメールアドレスをSearch Console側にユーザー追加し忘れる箇所くらいで、これを忘れるとAPIは正常なのに list_sites が空配列を返すという、切り分けの難しい状態になります。この記事ではそうした実際に踏んだ落とし穴も含めて書いています。

Claude CodeでもClaude Desktopでも同じことができます。ブラウザ版のclaude.aiだけを使っている場合は、後述する理由で今回の構成は動きません。

SEO分析を自動化するAIとデータ連携のイメージ

Google Search ConsoleのMCPで何ができるのか

結論から言えば、Google Search Consoleの管理画面では組めない条件を、日本語の指示のまま投げられるようになります。管理画面のUIは1回の表示が1,000行までで、フィルタも「〜を含む」「〜と完全一致」といった決まった形しか選べません。MCPサーバー経由でAPIを叩くと、正規表現フィルタと最大25,000行の取得が使えるので、「エラーメッセージ形式のクエリだけ」「順位4〜10位かつCTR2%未満のページだけ」といった切り口をその場で組み立てられます。

MCP（Model Context Protocol）とは、AIと外部ツールをつなぐための共通規格です。Search Console APIを直接叩くスクリプトを書く手もありますが、MCPサーバーとして繋いでおくとSEO分析のたびにコードを書かずに済むのが大きな違いです。キーワード選定の途中で「やっぱりこの条件も見たい」と思ったとき、スクリプトを書き換えるのではなく会話で条件を足せます。

以下は2026年8月時点、Claude Code 2.1系と mcp-server-gsc 0.3.0 での内容です。このパッケージが提供するツールは8つです。

  • search_analytics / enhanced_search_analytics — クエリ・ページ・国・デバイス別の検索パフォーマンス取得
  • detect_quick_wins — 順位とCTRの組み合わせから改善余地のあるクエリを自動抽出
  • list_sites — 権限のあるプロパティ一覧
  • index_inspect — URL単位のインデックス状況
  • list_sitemaps / get_sitemap / submit_sitemap — サイトマップの確認と送信

その前に、動く環境と動かない環境

今回使う mcp-server-gsc は、自分のPC上でNode.jsのプロセスとして動くローカルMCPサーバー（stdio形式）です。ここが対応環境を分ける境目になります。

環境 可否 設定方法
Claude Code 可 claude mcp add コマンド
Claude Desktop（Mac / Windows） 可 claude_desktop_config.json を編集
claude.ai（ブラウザ版） 不可 —

ブラウザ版が使えない理由は、仕組みを知ると納得できます。claude.aiのカスタムコネクタはリモートMCPのみに対応していて、接続はあなたのPCからではなくAnthropic側のクラウドから行われます。つまり接続先はインターネットから到達できる必要があるわけです。手元のPCで npx が起動するローカルサーバーには、Anthropicのクラウドから到達しようがありません。

逆に言えば、Claude Codeを使っていなくてもまったく問題ありません。デスクトップアプリのClaudeを使っているなら、設定ファイルにJSONを数行足すだけで同じことができます。コマンドラインに馴染みがない方は、次の「2-B」の手順を見てください。

接続手順

1. Google Cloud側の準備

Google Cloudのコンソールで対象プロジェクトを開き、Search Console APIを有効化します。次にサービスアカウントを作成し、JSON形式の鍵をダウンロードします。

ここで一番忘れられやすいのが次の手順です。Search Console側の「設定 → ユーザーと権限」で、作成したサービスアカウントのメールアドレス（名前@プロジェクトID.iam.gserviceaccount.com の形式）をユーザーとして追加します。これをやらないと、APIは有効なのに list_sites が空配列を返すという分かりにくい状態になります。認証は通っているのに権限がない、という切り分けの難しいエラーです。

2-A. Claude Codeに登録する

stdio形式のサーバーなので、claude mcp add に -- 区切りでコマンドを渡します。

claude mcp add --scope user \
  --env GOOGLE_APPLICATION_CREDENTIALS=/path/to/credentials.json \
  --transport stdio gsc \
  -- npx -y mcp-server-gsc

細かいところですが、--env の直後にサーバー名を置いてはいけません。CLIが名前を「もう一つの KEY=value」として読もうとして弾かれます。上の例のように --env とサーバー名の間に --transport などを挟むか、順序を入れ替えてください。

-- より後ろはすべてサーバー起動コマンドとしてそのまま渡されます。ここを省くと、サーバー側のオプション（--port など）をClaude Code自身のオプションとして解釈しようとして失敗します。

2-B. Claude Desktopに登録する

デスクトップアプリの場合は設定ファイルを直接編集します。アプリ上部のメニューから「Settings…」を開き（ウィンドウ内の設定ではなくOSのメニューバー側です）、「Developer」タブの「Edit Config」ボタンを押すと、設定ファイルが開きます。

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
  • Windows: %APPDATA%\Claude\claude_desktop_config.json

そこに次の内容を書きます。すでに他のサーバーを登録している場合は、mcpServers の中に gsc のブロックを足してください。

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

保存したら、アプリを完全に終了してから起動し直します。再読み込みではなく終了が必要です。起動後、入力欄の左下にあるコネクタのアイコンから「gsc」が一覧に出ていれば成功です。

認証情報のパスは絶対パスで書いてください。相対パスだと、アプリの作業ディレクトリが想定と違うため読み込みに失敗します。うまく繋がらないときは、macOSなら ~/Library/Logs/Claude/mcp*.log、Windowsなら %APPDATA%\Claude\logs\ にログが出ているので、そこを見るのが早道です。

3. スコープをどれにするか（Claude Codeの場合）

Claude Codeでは、MCPサーバーの登録先を3つから選べます。判断基準はシンプルで、認証情報を含むかどうかです。

スコープ 保存先 有効範囲 バージョン管理
local（既定） ~/.claude.json 追加したプロジェクトのみ されない
project プロジェクト直下の .mcp.json そのプロジェクト される（チーム共有）
user ~/.claude.json 自分の全プロジェクト されない

Search Consoleの分析は特定のリポジトリに紐づく作業ではないので、--scope user が扱いやすいはずです。逆に project スコープは .mcp.json がリポジトリにコミットされるため、鍵ファイルのパスや headers に認証情報を書くと事故になります。チーム共有したい場合は、認証情報を含まない形にできるかを先に確認してください。

同じ名前のサーバーが複数のスコープに定義されている場合は local → project → user の優先順位で、優先度の高い定義がまるごと採用されます。フィールド単位でマージされるわけではないので、「userスコープの環境変数だけ引き継がれる」といった期待はできません。

登録できたら claude mcp list で ✔ Connected が出るかを確認します。MCPサーバーの追加手順そのものはNotion MCPサーバーをClaude Codeに追加して仕様書を参照するでも扱っているので、他のサーバーを繋ぐ場合はそちらも参考にしてください。

クリック数だけで「勝っている」と判定しない

接続できたら、まず自分のサイトが何で流入を取れているかを確認します。直近1ヶ月のクエリを、掲載順位3位以内かつクリックが発生しているものに絞るだけです。

「直近30日のクエリを取得して、掲載順位3位以内でクリックが1以上のものだけをCTR降順で出して」

筆者が自社の技術ブログでこれをやったときは、上位に並んだのが全部エラーメッセージをそのまま検索したクエリでした。CTRは50〜60%台。逆に「〇〇 プラグイン」「〇〇 SEO」のような一般的なキーワードは、表示回数が100前後あってもクリックはほぼゼロでした。

ただし、ここで「エラー記事を量産すればいい」と結論を出すと読み違えます。

Search Consoleは「入口を取れたか」しか見ていない

Search Consoleのクリック数は、検索結果からサイトに入ってきたところまでの指標です。入ってきた人がどう振る舞ったかは一切分かりません。そこで同じ期間のGA4を突き合わせてみると、印象がかなり変わりました。

記事のタイプ セッション 平均滞在時間 PV/セッション
エラー文完全一致で1位（CTR 62.5%） 187 145秒 1.10
エラー文完全一致で2.6位（CTR 31.6%） 107 126秒 1.07
ORMの仕様を通しで解説した記事 157 519秒 1.59
管理画面の機能追加手順を解説した記事 30 346秒 1.30

一番上の記事は、流入数だけ見ればサイト全体で2番目に多い入口です。ところがPV/セッションが1.10。ほぼ全員が1ページだけ見て帰っています。滞在時間も145秒しかありません。

これは当然といえば当然で、エラーメッセージで検索する人の意図は「このエラーを今すぐ消したい」の一点です。該当箇所を読んで、コードをコピーして、ブラウザを閉じる。検索意図がピンポイントであるほどCTRは上がり、同時に回遊しなくなります。CTRの高さと離脱の速さは、同じ性質の裏表なんですね。

対して、ORMのフィールドタイプを一覧で解説した記事は滞在519秒・PV/セッション1.59。こちらは「調べながら作業している人」が読んでいるので、関連する記事にも移動しています。

2つの指標を役割で使い分ける

だからといってエラー記事に価値がないわけではありません。入口としては圧倒的に効率が良いので、書く価値は十分にあります。問題は、GSCのクリック数だけを成果指標にすると「入口ばかり増えてサイトが育たない」状態に気づけないことです。

判断基準としては、この2段構えが分かりやすいはずです。

  • Search Consoleで見るのは「入口として機能しているか」— クリック数、CTR、平均掲載順位
  • GA4で見るのは「入口として機能した後どうなったか」— 平均エンゲージメント時間、エンゲージメント率、PV/セッション

特にPV/セッションは効きます。1.0に近ければ「答えだけ持って帰られている」、1.3を超えていれば「読み進めてもらえている」と、かなり素直に読める指標です。GA4のエンゲージメント率（旧来の直帰率の裏返しにあたる指標）も見る価値はありますが、こちらは「10秒以上の滞在」でも満たされてしまうため、エラー解決型の記事だと高く出やすい点に注意してください。上の表でも、PV/セッション1.10の記事がエンゲージメント率では47.6%と、決して低くない数字を出しています。回遊しているかどうかを見たいなら、PV/セッションのほうが素直です。

そのうえで打つ手は、エラー記事をやめることではなくエラー記事の作りを変えることです。エラーの解消手順だけで終わらせず、「なぜこのエラーが起きるのか」という仕組みの説明と、関連する記事への導線を本文中に置く。実際、上の表で滞在519秒を記録している記事は、仕様の背景から書いてあるタイプでした。同じ流入数でも、1ページで終わるか2ページ読まれるかで、サイト全体の伸び方は変わってきます。

GA4にもMCPサーバーがあるので、Search Consoleと同じ要領で接続しておけば、この突き合わせを1つのセッションの中で完結できます。「GSCで上位のクエリを取って、そのランディングページのGA4指標を並べて」と頼めば、上の表と同じものがそのまま出てきます。この2つを別々のツールで見比べていると、そもそも突き合わせようという発想が出てきません。手間が消えることで、見るようになる指標があります。

「表示されているのに取れていない」を見つける

勝ちパターンが分かったら、次は取りこぼしです。detect_quick_wins は、順位とCTRのしきい値を指定して該当クエリを自動で抽出してくれます。既定値は「掲載順位4〜10位・CTR2%以下・表示回数50以上」で、しきい値は指定で変更できます。

この帯が狙い目なのは、すでにGoogleに評価されているのにクリックされていない状態だからです。順位を上げる施策は時間がかかりますが、タイトルとディスクリプションの書き換えは今日できます。順位が変わらなくてもCTRが2%から5%になれば、クリック数は2.5倍です。

実際、筆者のサイトでは1位を取っているのにCTRが1.1%しかない記事が見つかったことがあります。原因はタイトルが検索意図とずれていたことでした。順位が良いからといって放置していると、こういう記事は永久に取りこぼし続けます。

これはそのままリライトの優先順位付けに使えます。SEOのリライトは「なんとなく古い記事から手をつける」になりがちですが、この抽出結果を上から処理すれば改善幅が読める順に着手できます。公開から時間が経った記事のうち順位4〜10位でCTRの低いものを機械的に出すだけなので、作業リストとしてそのまま使える粒度です。

需要の裏取りは別のAPIでやる

ここがSearch ConsoleのMCPだけでは埋まらない部分です。

Search Consoleは「すでに自分のサイトが表示されたクエリ」しか持っていません。まだ記事を書いていない分野は、需要があってもデータがゼロです。「AI関連のキーワードを分析して」と頼んでも、その分野に記事がなければ「データがありません」としか返ってきません。当然なのですが、分析に慣れていないとここで判断を誤ります。

これから参入する分野の需要を見るには、検索ボリュームを持つ別のAPI（キーワードプランナー系のデータを提供するサービス）と突き合わせる必要があります。単月のボリュームだけでなく、月次推移を取って伸び率を見るのが重要です。

2026年8月時点で日本国内の検索ボリュームを調べたところ、たとえば「claude code 使い方」は直近3ヶ月平均が1年前の約5.3倍、「claude code インストール」は約5.6倍に伸びていました。一方で「gemini cli」は月間4万件という大きなボリュームがありながら、直近3ヶ月平均は1年前の0.36倍。ボリュームだけ見れば後者のほうが遥かに大きいのに、実態はピークを過ぎて下がり続けているわけです。

単月のボリュームで記事を決めていたら、確実に読み違えます。伸び率と組み合わせて初めて「今書くべきか」が判断できます。

実務での落とし穴

データは2〜3日遅れる

Search Consoleのデータ確定には数日かかります。「昨日公開した記事の反応を見る」という使い方はできません。日次の変動を追う場合は、直近3日分は暫定値として扱ってください。

平均掲載順位は「平均」でしかない

掲載順位8.5位と表示されていても、実際には1位のときと30位のときが混ざっているだけかもしれません。平均値を実際の順位だと思い込むのが一番危ない読み方です。日付でグルーピングして分散を見るか、そもそも順位の絶対値ではなく「クリックが発生しているか」で判断したほうが安全です。

AI検索経由のクエリがCTRを歪める

最近のSearch Consoleには、「〜とは何ですか」「〜はどうやって設定しますか」のような、長い疑問文のクエリが増えています。AI Overview（AIO）やAIモードが表示された検索です。これらは表示回数だけが積み上がってクリックがほぼ発生しないため、混ぜたままCTRを計算すると、記事のタイトルが悪いという誤った結論になります。

ここで誤解しやすいのが「このクエリは誰が入力したのか」です。AI OverviewとAIモードは「クエリファンアウト」という仕組みを使い、ユーザーの質問を内部で複数のサブクエリに展開して検索します。そのため「長い疑問文＝AIが機械的に生成したもの」と考えたくなりますが、これは間違いです。

Googleの公式ドキュメントによれば、Search Consoleのクエリディメンションに表示されるのはユーザーが実際に入力したクエリで、内部で展開されたファンアウトクエリは個別のクエリとしては報告されません。つまりあの長い疑問文は、AIが答えてくれることを期待した人間が、そのまま文章で打ち込んだものです。検索の仕方そのものが変わってきている、というだけの話なんですね。

これが分かると、扱い方が変わります。CTRの計算からは外すべきですが、ネタとしては捨ててはいけません。疑問文クエリは「読者が知りたいことが、読者自身の言葉でそのまま書かれているデータ」です。記事のh2・h3を設計するとき、これ以上に確度の高い材料はそうありません。

実務としては、次の2つを使い分けることになります。

  • CTRやリライト判断をするとき — excludingRegex で疑問文クエリを除外してから判定する
  • 記事の構成や新規テーマを考えるとき — includingRegex で疑問文クエリだけを抽出して読む

同じ正規表現の出し入れだけで両方できるので、追加の手間はありません。後者はそのままAIO対策・LLMO対策の効果測定にも使えます。AI検索対策として何かを施したなら、施策前後で疑問文クエリの表示回数がどう動いたかを見るのが素直な評価方法です。

なお2026年6月から、Search Consoleに生成AI検索専用のパフォーマンスレポートが段階的に提供され始めています。AI OverviewとAIモードでの表示回数を切り出して見られるものですが、2026年8月時点では一部サイトへの先行提供で、ディメンションもページ・国・日付・デバイスのみ。クエリディメンションがないため、上記の正規表現による切り分けは当面必要になります。

取得行数はトークンを消費する

25,000行取れるからといって全部取ると、そのままコンテキストを圧迫します。フィルタと rowLimit で先に絞ってから投げるのが基本です。「全部取ってから考える」は、この用途では悪手です。

読み取り専用に留めるなら権限を絞る

mcp-server-gsc には submit_sitemap というサイトマップを送信するツールも含まれています。分析目的しかないのであれば、Search Console側でサービスアカウントに与える権限を「制限付き」にしておくか、Claude Code側の permissions でツール単位の制御をかけておくと安全です。設定方法はClaude Codeでpermissionsのallow/deny/askで許可プロンプトを制御する手順にまとめています。

まとめ

Search ConsoleのMCPを繋ぐ価値は、レポートを自動化することではありません。管理画面のUIでは組めない切り口を、思いついた瞬間に試せるようになることです。「エラー文だけ抜きたい」「疑問文だけ除きたい」といった条件を、SQLを書く感覚で自然言語のまま投げられます。

そのうえで押さえておきたいのは、Search Consoleの数字だけでSEOの成果を判断しないことです。クリック数とCTRは入口の指標でしかなく、入ってきた人が読み進めたかどうかはGA4を並べて初めて見えます。両方をMCPで繋いでおくと、この突き合わせが会話1往復で済むようになります。手間が消えると、見る指標が増えます。

Claude Code・Claude Desktopのどちらでも同じことができるので、コマンドラインを普段使わない方でも問題ありません。設定ファイルにJSONを数行足すだけです。まずは自分のサイトで「掲載順位3位以内でクリックが発生しているクエリ」を出してみるところから始めると、手応えが分かりやすいはずです。