この記事の結論
GA4 MCPは、APIを2つ有効にしてGA4のアカウントに閲覧権限を1回付ければ全プロパティを読めます。僕の会社は7プロパティをつなぎ、ログイン切れで3回止まった後に鍵方式へ移しました。Claudeとの連携手順つき。
目次8項目
【実践講座】Claude Code 2daysセミナー（第二の脳構築講座）の詳細を見る →
GA4 MCPをつなぐのに僕に必要だったのは、APIを2つ有効にすることと、GA4の「アカウント」に閲覧の権限を1回付けることでした。公式のGoogle Analytics MCPなら、Claude Codeから会話で全プロパティの数字を読めます。迷うのは手順より認証の選び方で、無人で回すなら鍵方式が切れません。
僕の会社では、自社サイトと案件のLPを合わせた7つのプロパティを、1つのサービスアカウントで読んでいます。ただ人のログインを出発点にしていた間は、2026年7月13日・8月中旬・8月26日の3回、接続が丸ごと止まりました。
この記事では、公式どおりの設定、権限をアカウントの階層で付ける理由、ADC・借用・鍵の選び方を順に書きます。「GA4 MCPを入れたいけれど、どの認証で始めればいいの？」と迷っているなら、比較表の章から読んでも判断できます。
GA4 MCPでできること：読み取り専用で、READMEにある7つのツールを会話から呼べる
GA4 MCPは、AIからGA4のデータを読むためのGoogle公式のMCPサーバーです。正式な名前はGoogle Analytics MCP Serverで、GitHubでは「Experimental（実験的）」とされています。
ここでいうMCPとは、AIと外部のツールをつなぐための共通の接続口の規格です。
仕組みそのものはMCPとは（AIと業務ツールをつなぐ仕組みと実例）で書いたので、ここではGA4につなぐ部分に絞ります。
Googleの開発者向けページには、このサーバーは読み取りの要求にだけ使え、GA4の設定は変えられないと書かれています。サーバーは手元のパソコンで動き、裏ではGA4のAdmin APIとData APIを呼びます。
公式のREADMEに載っているツールは7つです（2026年10月16日に確認）。AIはこの中から、質問に合うものを自分で選んで呼びます。
| ツール名 | 何を返すか |
|---|---|
get_account_summaries | 読めるGA4のアカウントとプロパティの一覧 |
get_property_details | 1つのプロパティの詳しい情報 |
list_google_ads_links | プロパティにつないだGoogle広告のアカウント |
run_report | 通常のレポート（期間・指標・ディメンションを指定） |
run_funnel_report | ファネル（段階ごとの離脱）のレポート |
get_custom_dimensions_and_metrics | プロパティに作ったカスタムの指標とディメンション |
run_realtime_report | 今まさに起きていることのリアルタイムのレポート |
リポジトリのコードには、ほかにlist_property_annotationsとrun_conversions_reportもあります（2026年10月16日に確認）。READMEの7つだけで数えると、実際の数と合いません。
最初に呼ぶのはget_account_summariesです。僕の会社でも、つながったかどうかは、このツールでプロパティの一覧が返るかで確かめています。
使い道は、接続の手順書に書いた質問の例が分かりやすいと思います。「あるLPの直近14日のセッション数と直帰率は？」「離脱率が高いページの上位5つは？」といった問いです。
手順書では、こうした問いに数字と改善案で答えられる状態をゴールに置きました。管理画面でレポートを組み直さなくても、会話のまま期間や比べる軸を変えられるのが一番の利点です。
公式のREADMEには、Claude CodeのほかにGemini CLIとGemini Code Assistの設定例も載っています。AIの道具が変わっても、GA4側の準備（APIと権限）は同じです。
つなぐ前に決めることは3つあります。どのGoogle Cloudのプロジェクトで APIを動かすか、どの認証で動かすか、GA4の権限をどの階層に付けるかです。後ろの2つで後の手間が大きく変わるので、別の章で詳しく書きます。
GA4 MCPの設定手順：APIを2つ有効にして、Claude Codeに登録するまで
手順は6つです。公式のREADMEの流れに、僕の会社で実際につまずいた点を足しています。コマンドの中の値は伏せ字にしているので、自分の環境の値に置き換えてください。
1. Google Cloudのプロジェクトを用意する
GA4のAPIを呼ぶための、Google Cloudのプロジェクトを1つ用意します。僕の会社では、GA4の分析だけに使う専用のプロジェクトを作りました。
専用にしておいてよかったのは後になってからです。鍵の作成を例外にする設定を、このプロジェクト1つに絞れました。用途の違うものを同じプロジェクトに混ぜないのがおすすめです。
2. APIを2つ有効にする
Google Analytics Admin APIとGoogle Analytics Data APIを、そのプロジェクトで有効にします。READMEの前提も、この2つです。
僕の手順書には、有効にし忘れるとPermissionDeniedが出ると書いていました。ところが2026年7月13日に実際に出たのは403 SERVICE_DISABLEDです。
原因は、APIを呼ぶプロジェクトとの紐付けが外れ、共有のクライアントの扱いになっていたことでした（社内の移行メモ）。
このエラーが出たら、APIの有効化と、APIを呼ぶプロジェクトの指定の両方を見直します。プロジェクトの指定は手順5の環境変数でも行います。
3. pipxを入れて、サーバーを動かせるようにする
READMEの手順は、Python用のツールpipxでサーバーを動かす形です。パッケージ名はanalytics-mcpで、Pythonは3.10以上が前提です。
僕の会社は最初の導入のとき、別の道具（uv）でGitHubから直接入れました。どちらでも動きますが、これから入れるならREADMEどおりpipxにそろえる方が、手順の差で迷わずに済むと考えています。
4. 認証を用意する（ADC）
ここでいうADCとは、Googleのプログラムがログイン情報を決まった順番で自動で探す仕組みです。
公式ドキュメントでは、環境変数GOOGLE_APPLICATION_CREDENTIALSが指すファイル、gcloudで作ったファイル、実行環境のサービスアカウントの順に探します。
READMEは、GA4のアカウントかプロパティにアクセスできる利用者のADCを使う形です。スコープにanalytics.readonlyを含めることが必須とされています。自分のアカウントで始めるなら、次のように実行します。
gcloud auth application-default login \
--scopes https://www.googleapis.com/auth/analytics.readonly,https://www.googleapis.com/auth/cloud-platform \
--client-id-file=/path/to/oauth-client.json--client-id-fileには、自分で作ったOAuthクライアントのファイルを渡します。
2026年7月13日、僕が既定のクライアントのままログインし直したときは、既定のクライアントでのGA4の読み取りは近く止めるという警告がgcloudから出ました。
ログインが終わると、Credentials saved to file:の後に保存先のパスが出ます。このパスを次の手順で使います。
公式ドキュメントでは、macOSとLinuxの既定の保存先は$HOME/.config/gcloud/application_default_credentials.jsonです。
5. Claude Codeに登録する
READMEのClaude Code向けの手順は、claude mcp addを利用者の範囲（--scope user）で実行し、環境変数を2つ渡す形です。値を伏せ字にすると、次のようになります。
claude mcp add analytics-mcp \
--scope user \
-e "GOOGLE_APPLICATION_CREDENTIALS=/path/to/credentials.json" \
-e "GOOGLE_PROJECT_ID=YOUR_PROJECT_ID" \
-- pipx run analytics-mcp1点だけ注意があります。READMEは本文でプロジェクトの変数にGOOGLE_CLOUD_PROJECTを勧めつつ、例ではGOOGLE_PROJECT_IDを使っていて、名前がそろっていません。
僕の会社はGOOGLE_CLOUD_PROJECTで登録して動いています。迷ったら、使っている版のREADMEを開いて確かめるのが確実です。
範囲をuserにしておくと、どのフォルダでClaude Codeを開いても同じGA4の接続を使えます。僕の手順書でも「全プロジェクトから使える」ことを理由にこの範囲を選びました。
6. 再起動して、1回データを取る
登録したらClaude Codeを再起動し、「GA4のプロパティ一覧を出して」と頼みます。プロパティの名前が並べば接続は完了です。
空の一覧（[]）が返ったら、認証は通っていて、GA4側の権限が付いていない状態です。僕の会社の接続メモにも、この症状は閲覧者の付与が済んでいないときに出ると残しています。
「設定した」と「取れた」は別なので、一覧が返るまでを完了の条件にしてください。権限の付け方は次の章で書きます。
GA4の権限は「アカウント」に1回：7プロパティを1つのサービスアカウントで読む構成
権限はプロパティごとではなく、GA4の「アカウント」の階層で付けます。アカウントで付けた権限は、その中のすべてのプロパティに同じ内容で引き継がれます。
GA4のヘルプでは、アカウントの階層で追加した利用者は、そのアカウントの全プロパティに同じ権限で入れると説明されています。追加の操作には、その階層の管理者の役割が必要です。
付ける場所による違いを並べます。
| 付ける場所 | 効く範囲 | 向く場面 |
|---|---|---|
| アカウント | その中のすべてのプロパティ | 社内の分析用に、案件のLPをまとめて読ませる |
| プロパティ | そのプロパティだけ | 読ませる範囲を1つの案件に絞りたい |
僕は、社内の分析に使う接続ならアカウント、範囲を絞りたい接続ならプロパティで付けるのがよいと考えています。下の階層で権限を減らすことはできないので、広く付けすぎないことも大事です。
サービスアカウントとは、人ではなくプログラムがGoogleのサービスを使うための専用のアカウントです。僕の会社では、GA4を読むためだけのものを1つ作りました。
そのメールアドレス（xxx@<project>.iam.gserviceaccount.comの形）を、GA4の「アカウントのアクセス管理」で閲覧者として追加しました。
役割を閲覧者にしたのは、編集の権限を持たせる理由が無いからです。
手順書には「プロパティの列ではなく、アカウントの列で付ける」と太字で書きました。案件のLPが増えても、同じアカウントの中に作る限り付け直しが要らないからです。
ここで1つ、思っていた数と合わない場面がありました。2026年7月17日14時に接続を確かめると、見えたのは2つのアカウントにまたがる5つのプロパティでした。
7月13日の移行メモで想定していた7つより、2つ少ない数です（同メモの追記）。認証は通っているのに一部だけ見えないときは、まず付与の漏れを疑います。
接続メモには「別のアカウントが残っていれば、同じ付与が必要」と書き残しています。アカウントで付けた権限は、そのアカウントの中にしか効きません。GA4のアカウントが分かれていれば、その数だけ追加します。
2026年8月30日の恒久化のメモの時点では、同じサービスアカウントで全7プロパティを読める状態になっていました。8月21日には、新しい案件のLPのプロパティも、この接続で読む対象として接続メモに追記しています。
もう1つの学びは、アカウントの名前と中身をそろえておく大切さでした。7月17日の確認では、ある案件の名前を付けたアカウントに、ほかのLPのプロパティも入っていました。メモには、名前の整理は要検討と残しています。
GA4 MCPの認証の選び方：ADC・借用・鍵を比べる
答えは、使う人がその場にいるかどうかで決まります。人が会話しながら使うだけならADCか借用、人のいない時間に定期処理を回すならサービスアカウントの鍵が向きます。
3つの方式を、出発点と切れる条件で比べます。右端は僕の会社で使った期間です。
| 方式 | ログインの出発点 | 止まるとき | 追加で要るもの | 僕の会社で使った期間 |
|---|---|---|---|---|
| ADC（自分のログイン） | 自分のGoogleアカウント | 自分のログインが切れたとき | GA4のAPI2つ・自分のOAuthクライアント | 2026年7月13日に失効するまで |
| 借用（impersonation） | 自分のログイン → サービスアカウントの短期のトークン | 出発点のログインが切れたとき | Service Account Credentials API・トークン作成者のロール | 7月17日〜10月4日（約2か月半） |
| 鍵（サービスアカウントの鍵） | 鍵のファイル | 鍵を無効にする・消すとき | IAM API・鍵の作成を止める組織ポリシーの例外 | 10月4日から |
ADC：試すだけなら一番早い
ADCは準備がいちばん少なく、自分がGA4を見られるなら、GA4側の作業も要りません。試しに会話で数字を出してみるだけなら、これで十分です。
弱点は、ログインが切れるたびに人が入り直す必要がある点です。僕の会社では、2026年7月13日にこのログインが失効したのが、方式を見直す最初のきっかけでした。
借用：鍵を持たずにサービスアカウントで読む
借用は、自分のログインを出発点に、サービスアカウントの短期間のトークンをその都度発行してもらう方式です。公式ドキュメントは、事前に認証された人が要るぶん、鍵より安全な方法と位置づけています。
準備は2つです。Service Account Credentials APIの有効化と、自分へのトークン作成者のロール（roles/iam.serviceAccountTokenCreator）の付与です。
認証のファイルは、次のコマンドで作ります。
gcloud auth application-default login \
--impersonate-service-account=xxx@<project>.iam.gserviceaccount.com \
--scopes=https://www.googleapis.com/auth/analytics.readonly,https://www.googleapis.com/auth/cloud-platform2026年7月17日にこの方式に移したとき、権限の反映には約30秒かかりました（社内の移行メモ）。付与した直後に失敗しても、少し待ってからやり直せば通ります。
ただ出発点は人のログインなので、そこが切れると止まります。僕の会社で接続が丸ごと止まった3回は、どれもADCか借用の時期に起きました。
鍵：人のログインと関係なく動く
鍵方式は、人のログインと関係なく動きます。一方で公式ドキュメントは、サービスアカウントの鍵はセキュリティのリスクになり、勧めないとしています。漏れた鍵は、ほかの情報なしで悪用できるからです。
僕の会社が鍵を選んだのは、毎朝の定期タスクが、人のいない時間にGA4と検索データを取るからです。リスクは、閲覧しかできないアカウントの鍵に限ることと、例外を分析専用のプロジェクト1つに絞ることで小さくしました。
借用から鍵へ移したとき、GA4の管理画面の作業もMCPの登録もやり直さずに済みました。MCPが読む認証ファイルの場所を変えず、中身だけを差し替えたからです（社内の恒久化メモ）。
接続が3回止まって鍵方式に移るまで：GA4 MCPの認証の実録
僕の会社のGA4の接続は、ADCから借用、借用から鍵へと2回方式を変えました。きっかけはどちらも、人のログインが切れて全プロパティが一度に読めなくなった出来事でした。
1回目の変更のきっかけは2026年7月13日のADCの失効です。鍵ファイルの方式へ移そうとしたところ、7月17日に鍵の作成が組織ポリシーで止められていると分かり、借用方式にしました。
この制約の意味と外し方はiam.disableServiceAccountKeyCreationの意味と対処に書いています。
借用に移した後も、出発点のログインが切れるたびに止まりました。社内の恒久化メモに残る失効は、7月13日・8月中旬・8月26日の3回です。
ログインし直した後のエラーの直し方はGA4 MCPの「503 Reauthentication is needed」の原因と直し方にまとめました。
2026年8月30日、僕は「恒久的にずっとログインできる状態に」と社内のAIチームに頼みました。返ってきた案は、分析専用のプロジェクト1つだけ鍵の作成を例外にし、認証ファイルを鍵に置き換える形です。
見送った案もメモに残っています。Workspaceのセッションを延ばす案は、全社の設定に触るのに効く確証がありませんでした。組織の外にプロジェクトを作る案は、GA4の権限の付け直しと個人のアカウントへの依存が残りました。
実際に鍵へ切り替えたのは10月4日です。借用方式がinvalid_raptで定期的に切れ、検索データの自動の再送信まで止まったのが決め手でした。
切り替えの日は2か所でつまずきました。鍵の作成にはIAM APIの有効化が要り、作成直後の1〜2分はInvalid JWT Signatureで失敗しました。
もう1つ、記録に残しているのがPythonの落とし穴です。GA4のMCPのPythonを、SEOの作業用スクリプトのフォルダで動かすと落ちました。そこにある自作のqueue.pyが、同じ名前の標準モジュールを上書きしていたためです。
MCPサーバーや、その認証を確かめるスクリプトは、自作のファイルが並ぶフォルダの外で動かすのが安全です。同じ名前のファイルがあるだけで、原因の分かりにくい失敗になります。
切り替えた後の毎朝のGA4の取得は、10月5日から9日まで5日続けて成功しました（再認証の記事に載せた定期タスクの取得記録）。社内のMac2台のうち、もう1台はこの時点で借用方式のまま残しています。
GA4とClaudeの連携を業務で使うときの注意5つ
業務で使うなら、つなぐことより「止まらない・漏れない・間違えない」の3つを先に決めておきます。僕の会社で決めていることと、公式の勧めを5つ挙げます。
1. スコープは読み取りだけにする。 READMEどおりanalytics.readonlyを基本にします。サーバー自体も読み取り専用なので、AIに渡す権限もそこに合わせ、GA4の役割も閲覧者にとどめます。
2. APIを呼ぶプロジェクトをはっきり指定する。 7月13日の403 SERVICE_DISABLEDは、共有のクライアントの扱いになったのが原因でした。今は環境変数とADCの両方に同じプロジェクトを設定しています。
3. 鍵は1か所に置き、Gitに入れない。 公式は、鍵をソースコードの置き場に入れないことを求めています。誤って入れたら、置き場から消すだけでなく、IAMで鍵をすぐに消すよう書かれています。
僕の会社では、鍵は1台のMacの決まったフォルダだけに置き、持ち主以外は読めない設定にして、Gitの管理から外しました。公式は、鍵の定期的な入れ替えも勧めています。
4. 漏れたときの動きを決めておく。 公式は、漏れた鍵をGoogle Cloudが自動で無効にする設定（DISABLE_KEY）を勧めています。見つけてもらえる保証は無いので、ほかの対策もそのまま続けます。
5. 設定を変えたら再起動して、1回データを取る。 起動中のMCPサーバーは、古い認証を持ったまま動いていることがあります。認証ファイルを差し替えたら、AIのアプリを再起動して一覧を取り直すまでを1セットにしています。
GA4や広告の数字をAIに読ませる仕組みを、自社の業務に合わせて組みたい場合は、下のセミナーで具体的な作り方をお伝えしています。
まとめ
- GA4 MCP（Google Analytics MCP）は、Google公式の読み取り専用のMCPサーバー。READMEに載るツールは7つ（コードには9つ）で、GA4の設定は変えられない
- 準備はGoogle Cloudのプロジェクト1つ、API2つ（Admin・Data）、
analytics.readonlyの認証、Claude Codeへの登録の4つ - 権限はGA4のアカウントの階層で閲覧者を1回付ければ、その中の全プロパティに効く。アカウントが分かれていれば、その数だけ付ける
- 認証は、使う人がその場にいるならADCか借用、無人の定期処理なら鍵。僕の会社は人のログインを出発点にしていた間に3回止まった
- 僕なら、試すだけならADCで始め、毎朝の定期処理に組み込むと決めた時点で、閲覧専用のサービスアカウントの鍵に移します
よくある質問
GA4 MCPでGA4の設定を変えることはできますか？
できません。Googleの開発者向けページでは、このMCPサーバーは読み取りの要求にだけ使え、GA4の設定は変えられないとされています。スコープも読み取り専用の analytics.readonly が前提なので、AIが誤ってイベントやコンバージョンの設定を書き換える心配はありません。
権限はプロパティごとに付ける必要がありますか？
GA4のアカウントの階層で付ければ、そのアカウントの全プロパティに同じ権限が効きます。プロパティごとに付ける必要はありません。ただしGA4のアカウントが複数に分かれているなら、アカウントの数だけ追加の操作が要ります。
プロパティの一覧を頼んだら空の結果が返りました。何が原因ですか？
認証は通っているのに、GA4側で閲覧の権限が付いていない状態です。GA4の管理画面の「アカウントのアクセス管理」で、MCPが使うアカウント（サービスアカウントならそのメールアドレス）を閲覧者として追加し、もう一度一覧を取ってみてください。
Claude Code以外のAIでもGA4 MCPは使えますか？
使えます。公式のREADMEには、Claude CodeのほかにGemini CLIとGemini Code Assistの設定例が載っています。どれも手元のパソコンでサーバーを動かし、同じ認証ファイルを読む形なので、GA4側の権限の付け方は変わりません。