GA4 と Search Console の数字は、MCP を2本入れると Claude Code から直接読めるようになります。GA4 は Google 公式の analytics-mcp、Search Console は公式 MCP が見つからなかったのでコミュニティ製の mcp-search-console を使いました(2026年8月時点)。導入にかかったのは約33分で、以後の数字取りは約4分です。
それまで毎週の数字確認は手作業で、約30分かかっていました。そして手作業の1回目で、集計の取り違えを2件やりました。この記事は「30分が4分になった」だけではなく、「手で集めた数字は間違える」と分かるまでの記録です。
この記事で分かること
- GA4・Search Console 用 MCP の選び方と設定例(Search Console に公式は無い)
- 導入で詰まった5ヶ所と回避策(uv の PATH・IAM 一覧・GSC_SKIP_OAUTH など)
- 手動集計と MCP の数字を突き合わせた結果(取り違えがもう1件見つかった)
週次の数字確認を始めると決めて、1回目を手で回したのが 2026-08-22 です。その30分が重くて、同じ日のうちに MCP の導入まで済ませました。自動化できるものは自動化したい性分です。
手作業も慣れれば速くなるとは思います。ただ、毎回どの画面の何を見るのかを確かめながらになるので、それなら AI に取ってきてもらいたいと思いました。この記事の所要時間と詰まりどころは、全部その日の実測です。
手作業の数字集めは30分かかって、2件間違えました
週次1回目は、Search Console と GA4 の管理画面をスクリーンショットで撮り、AI に渡して整形させる方式でやりました。数字の転記を自分でやらずに済むので、これはこれで楽です。ただ、画面の行き来と撮り直しを含めると約30分かかりました。
かかった時間より問題だったのは、あとから見つかった取り違え2件です。
- Search Console のクリック数を「0」と記録したが、実際は6だった。クエリ別の表だけを見ていたのが原因。まれなクエリはプライバシー保護のためクエリ表から省かれるとSearch Console のヘルプにある(2026年8月確認)。クエリ表の合計は0でも、ページ別表で見ると4ページ・計6クリックあった
- GA4 の PV 上位に「アドセンス同意 2」と記録したが、あとで MCP から同じ期間を取り直すと、該当するページが存在しなかった。管理画面のどこを読んでこの数字を書いたのか、再現できていない
どちらも AI の間違いではありません。人間が「管理画面のどの表を見るか」を選ぶところで起きています。「手で集めた数字は、時間がかかるだけでなく間違える」。それがこの日の結論でした。
Search Console に公式 MCP はある?(2026年8月時点の答え)
ありません。GA4 には Google 公式の MCP(analytics-mcp)がある一方、Search Console の公式 MCP は探した範囲で見つかりませんでした(2026年8月時点)。そのためコミュニティ製から選ぶことになります。
| 対象 | 使ったもの | 備考 |
|---|---|---|
| GA4 | analytics-mcp(Google 公式) | GitHub の googleanalytics organization が公開 |
| Search Console | mcp-search-console(コミュニティ製・AminForou/mcp-gsc) | 公式が無いためコミュニティ製を選定 |
Search Console 用は2つ比べました。選んだ AminForou 版には、検索アナリティクスに加えて URL 検査のツールがあります。対抗の ahonn 版(mcp-server-gsc)は検索アナリティクス1本です(2026年8月に両方の README で確認)。決め手は URL 検査でした。
この判断はあとで効きます。後半の「新記事2本の PV がゼロでした」の節で実際に使いました。
認証はサービスアカウント1本・最小権限で足りました
認証は Google Cloud のサービスアカウントを1本作り、GA4 と Search Console の両方で共用しました。GCP コンソールの画面操作だけで完結し、gcloud コマンドは使っていません。
権限は最小から始めました。GA4 は「閲覧者」、Search Console は「制限付き」です。結局そのまま足りました。あとで使う URL 検査も「制限付き」で通り、権限を上げた回数はゼロです。
コミュニティ製 MCP にキーを渡すことになる
mcp-search-console はコミュニティ製です。つまり Google が審査していないコードに、サービスアカウントのキーを渡すことになります。私はキーの権限を読み取り専用に限定して、仮に漏れても被害の上限が「このサイトの計測データを閲覧される」で止まる形にしました。書き込み権限を足す場合は、この前提が崩れることを踏まえてください。
キーの JSON ファイルはホームディレクトリ配下(~/.gcp/)に直接置き、1Password にはバックアップとして保管しています。1Password の CLI でラップして環境変数に流す形は見送りました。MCP はセッションのたびに起動するので、そのたびに認証ダイアログが出るからです。
設定は次の形です。読みやすいように、プロジェクト直下の .mcp.json に書く形で載せます。私の実運用はこのファイルではなく local scope(claude mcp add --scope local)で、設定をリポジトリに入れていません。同じリポジトリを別の PC で開いたとき、キーの無い環境で毎回起動エラーになるのを避けるためです。
{
"mcpServers": {
"analytics": {
"command": "uvx",
"args": ["analytics-mcp"],
"env": {
"GOOGLE_APPLICATION_CREDENTIALS": "C:\\Users\\USERNAME\\.gcp\\sa-key.json",
"GOOGLE_PROJECT_ID": "your-project-id"
}
},
"search-console": {
"command": "uvx",
"args": ["mcp-search-console"],
"env": {
"GSC_CREDENTIALS_PATH": "C:\\Users\\USERNAME\\.gcp\\sa-key.json",
"GSC_SKIP_OAUTH": "true"
}
}
}
}
GA4 公式の README には pipx run analytics-mcp の形で書かれています(2026年8月時点)。私はどちらも uvx で動かしました。なお command のところは、次の詰まり(1)の理由で、実際にはフルパス指定にするのが確実です。
MCP 導入で詰まった5ヶ所
導入全体は約33分で、そのうち GCP の画面操作が15〜20分です。ここからがこの記事の本体で、詰まった5ヶ所を回避策とセットで順に書きます。環境は Windows です。
(1) winget で入れた uv が、シェルを再起動しても PATH に出てこない
MCP の実行に uv(uvx)を使うので、winget install で入れました。「シェルを再起動してください」と表示されるので再起動しましたが、uvx が見つかりません。
Windows のユーザー環境変数は、シェルやアプリの再起動では反映されないことがあります。別のツールを入れたときにも、サインアウトするまで反映されない現象に当たっています。今回はサインアウトを待たずに回避しました。
さらにこの環境では WinGet Links フォルダにコマンドのエイリアスが作られておらず、実体は %LOCALAPPDATA%\Microsoft\WinGet\Packages\ 配下の astral-sh.uv_… フォルダの中にありました。回避は単純で、MCP の設定に uvx.exe のフルパスを書きます。mcp-search-console の README(2026年8月時点)も、Claude Desktop のような GUI アプリはシェルの設定を読まずに起動するから、という理由でフルパス指定を勧めています。
(2) 作ったはずのサービスアカウントが IAM の一覧に出てこない
サービスアカウントを作ったあと、「IAM と管理 → IAM」のプリンシパル一覧を見ても出てきません。どこだよ、という感じです。
ロールを付けずに作ったサービスアカウントは、この一覧に出ていませんでした。IAM のページにはロールを持つアカウントだけが並ぶようで(2026年8月時点)、ロール無しだと出てきません。見るべきは同じメニューの別項目「サービスアカウント」です。
AI が出してくる手順は結構間違っているので、こういうときは割とストレスです。エラーは何も出ないまま、作ったものだけが見えません。
(3) 「プロジェクト ID」の欄に数字を渡してしまう
GCP の画面には、プロジェクト名・プロジェクト ID・プロジェクト番号の3つが並んでいます(2026年8月時点)。初見では区別がつきません。私は設定にプロジェクト番号(数字)を貼ってしまい、通りませんでした。設定に使うのは英字のプロジェクト ID です。
ついでに、AI の思い込みも1件外れました。「ID には -1234 のようなサフィックスが付きます」と説明されていましたが、その名前が空いていれば素のまま通ります。実際、付けた名前がそのままプロジェクト ID になりました。
(4) AI がキーファイルを読もうとして、止められた
プロジェクト ID が分からなかったとき、AI(Claude Code)がサービスアカウントのキー JSON から project_id の値だけ抜き出そうとしました。ここで Claude Code の権限クラシファイアが、認証情報ファイルへのアクセスとしてブロックしました。
これは事故ではなく、安全機構が正しく働いた実例です。キーファイルは AI に読ませず、ID は GCP の画面で確認するのが正道でした。ちなみにこの記事を書いている途中にも、設定ファイルを開いて確かめようとした AI が同じブロックに当たっています。一貫して動いています。
(5) README の実物にしか書いていない設定が1つあった
Search Console 側の MCP をサービスアカウントで使うには、キーのパス(GSC_CREDENTIALS_PATH)に加えて GSC_SKIP_OAUTH=true という環境変数が要ります(2026年8月時点の README)。導入前に AI に要約させた調査結果には、この値が出てきませんでした。
「登録前に README の実物を読む」と計画に書いておいたのが効きました。要約は入口としては便利ですが、設定値の正確さは原文でしか担保できないと思います。
導入後: 同じ数字が4分で取れました
翌セッションで実データの検証をしました。GA4・Search Console とも1回目の呼び出しで通り、403 エラーも再認証もありません。手動で30分かけていた数字の取得が、約4分で終わりました。
手動の値と MCP の値の突き合わせが次の表です(同じ週を対象にした数字)。
| 指標 | 手動 | MCP | 判定 |
|---|---|---|---|
| GA4 トップページ PV | 11 | 11 | 一致 |
| GA4 記事 x-algorithm-cold-start | 4 | 4 | 一致 |
| GA4 記事 ai-review-rally-rules | 2 | 2 | 一致 |
| GA4「アドセンス同意」 | 2 | 該当ページ無し | 手動の誤り |
| Search Console クリック(全ページ) | 6 | 5 | 取得日の境界 |
| Search Console 表示回数(全ページ) | 166 | 158 | 取得日の境界 |
| Search Console 表示のあったページ数 | 18 | 18 | 一致 |
「アドセンス同意 2」は MCP 側に存在しませんでした。手動集計の取り違えが、クリック数の件に続いてもう1件確定したことになります。
Search Console のクリックと表示回数のズレ(6→5・166→158)は、どちらかの誤りではなく取得日の境界です。手動のときに1クリック・13表示だったページが、MCP では0クリック・12表示になっていました。最新のデータは暫定値であとから変動することがあると、Search Console のヘルプにも書かれています(2026年8月確認)。同じ「今週」でも取得タイミングで数字が動くので、数字を記録するなら取得日もセットで残す必要があります。
自動化して初めて出た数字: 新記事2本の PV がゼロでした
手作業のときは「新しい記事が PV 上位に出てこない」までしか分かりませんでした。MCP でパスを指定して絞り込めるようになり、初めてはっきりした数字が出ました。公開から数日たつ記事2本の GA4 PV が、部分一致で探してもゼロ行です。
- 8/19 公開の記事(AIに体験記を書かせたら、やっていないことを書いていた話): GA4 PV = 0
- 8/16 公開の記事(残量バーの自作記録): GA4 PV = 0
- ただし GA4 のタグ自体は生きている(サイト全体では8月は毎日 PV があり、確認した日も 4PV)
ここで、選定の決め手にした URL 検査を使いました。8/19 公開の記事を検査すると「Submitted and indexed」。インデックスには載っているのに、検索結果への表示はゼロでした。8/16 公開の記事は表示20回・クリック0です。
「サイトは計測されているのに、この2記事だけ1PVも無い」という形です。残る問いは「来ているのに数えられていないのか、そもそも誰も来ていないのか」です。切り分けは翌日にやり、結論は「到達がゼロ」でした。
記事ページのタグは正常で、ブラウザから計測リクエストも実際に飛んでいます。ただし自分のアクセスは GA4 の内部トラフィック除外に判定されていて、最初から数えられていません。外部からの到達は毎日記録されているので、計測の経路は生きています。GA4 と Search Console という別系統の2つが、独立に同じ答えを出しました。
副産物として、切り分けの定番手順が1つ使えないことも分かりました。「自分でページを開いて、GA4 のリアルタイムレポートに出るか見る」という確認は、内部トラフィック除外が効いている環境では使えません。タグが正常でも自分のアクセスは出ないので、正常なタグを壊れていると読んでしまいます。この環境で使えたのは、ブラウザの開発者ツールで計測リクエスト(en=page_view)が飛んでいるかを直接見ることでした。もう1つは Search Console のクリック数との突き合わせです。
もう1つ、掘って初めて分かったことがあります。直近30日でいちばん大きいアクセスの塊(デスクトップ・Windows・参照元なしの49PV)の中身を見ると、着地はほぼ全部トップページ。時間帯は深夜を含めて満遍なく分散し、ブラウザの種類もばらけていました。人の閲覧の形ではなく、GA4 の既知ボット除外をすり抜けたボットです。
手で画面を眺めていた頃は、この塊がどこから来ているのか分かっていませんでした。経路は分からないけれど何かしらアクセスはあるのだろう、くらいに思っていて、ボットだとは疑っていませんでした。「記事の数字は、チャネルを Organic Search と Referral に絞って見る」。それがこのサイトの正しい読み方でした。
まとめ: かかった時間と、手放した作業
| 項目 | 実測 |
|---|---|
| before(手動で1周) | 約30分・取り違え2件 |
| 導入 | 約33分(うち GCP の画面操作 15〜20分) |
| after(同じ数字を取る) | 約4分 |
| 詰まった箇所 | 5ヶ所 |
| 入れた MCP | 2本(GA4 は公式・Search Console はコミュニティ製) |
| 権限の昇格 | 0回(読み取り専用のまま) |
まとめ
- Search Console に公式 MCP は無い(2026年8月時点)。URL 検査まで使うなら mcp-search-console
- サービスアカウント1本・読み取り専用の最小権限で、全部足りた
- 手で集めた数字は間違える。30分が4分になったことより、取り違えが消えたことのほうが大きい
GA4 と Search Console を最初に入れたのは1年前で、そのときの記録が導入方法の記事として残っています。当時は管理画面を開くところから始めていました。1年たって、同じ画面をほとんど開かずに数字を読む形になっています。毎週の数字確認はこれから MCP 経由の4分で回し、手作業の頃のような読み間違いが出なくなるかを週次で見ていきます。
関連
-
-
Claude CodeとCodexの使用量をタスクバーに常時表示する。「残量バー」を自作した記録
2026/8/24 Claude Code, Codex, Python, 自作ツール
Claude Code と Codex CLI の残り使用量は /usage・/status を打たないと見えません。タスクバーに常時表示する Windows 常駐ツールを自作し、使用量エンドポイントの実測仕様と、AIレビューで出た欠陥19件をまとめました。
-
-
AIに自分の体験記を書かせたら、やっていないことを書いていました
2026/8/19 AI副業, Claude Code
AIに体験記の下書きを書かせたら、やっていないことが書いてありました。機械検品・AIレビュー・事実の照合・本人の通し読みの4層で何が捕まり、何が残ったかを実測の件数で記録します。最後まで残ったのは動機でした。
-
-
Google Search ConsoleとGA4の導入方法|アクセス解析を開始|AI副業実践記 #4
2026/3/16
はじめに ブログを公開したものの、「実際に誰かに見てもらえているのかな?」という不安がありました。調べてみると、多くの人が Google Search Console(サーチコンソール) と Goog ...