GA4のMCPサーバーは「Google認証で自作」が最適だった｜公式・第三者・トークン方式と比べた選定基準
Google Analytics（GA4）のデータをClaudeやChatGPTから直接読むには、MCPサーバーが必要です。「つなぎ方」を書いた記事は増えましたが、「どの方式を選ぶか」を比べたものは見当たりません。当社は4つの方式を検討し、自作（Cloud Runでのリモートサーバー）を選びました。さらに自作の中でも、初版の「トークン認証」から「利用者が自分のGoogleアカウントでログインする方式（OAuth 2.1）」に作り直しています。利用者の手順はコネクタにURLを登録して、Googleでログインするだけ。この方式で作ったサーバーは mcp-dir Hub として誰でも使える形で公開しています。その判断材料を、2026年9月時点の実態として公開します。
初版 2026年9月7日／更新 2026年9月22日（Google認証版を追加）／更新 2026年10月3日（公開版 mcp-dir Hub と、公開後に分かったことを追記）／使用クライアント：Claude Code・Claude（Anthropic）。各サービスの仕様は変わるため、半年ごとに検証し直して更新します（次回 2027年3月予定）。
結論：方式はここが違う
違いは「サーバーがどこで動くか」「認証情報をどこに置くか」「利用者が何をするか」の3点に集約されます。
| 方式 | 費用 | 利用者がすること | 見えるデータの範囲 | 向いている相手 |
|---|---|---|---|---|
| Google公式 analytics-mcp | 無料 | 端末にサーバーを入れ、鍵ファイルを置く | 置いた鍵の権限 | 1人で試す人 |
| Google Cloud リモートMCP | — | — | — | GA4は対象外 |
| 第三者のMCPコネクタ | 有料（月額） | URL登録とOAuth許可 | 本人の権限 | 社内にエンジニアがいない場合 |
| 自作（トークン認証） | 実行時間のみ（少額） | URLとトークンを受け取って登録 | サーバーの鍵の権限（全員同じ） | 少人数・社内限定 |
| 自作（Google認証・OAuth 2.1） | 実行時間のみ（少額） | URL登録とGoogleログイン | 本人の権限 | チーム・社外にも広げたい場合 |
そもそもGA4のMCPサーバーは何をしているのか
MCP（Model Context Protocol）は、AIに外部のデータやサービスをつなぐための共通規格です。GA4の文脈では、AIの代わりにGoogle Analytics Data APIを叩いて、結果をAIが読める形で返す小さなサーバーがMCPサーバーにあたります。
これがないと、GA4の数字をAIに見せる作業は「管理画面でレポートを作る → CSVで書き出す → チャット欄に貼る」の手作業になります。つないでしまえば、「先月の流入元別のコンバージョンを出して」と書くだけで、AIが自分でAPIを呼んで答えます。読み取り専用で作るのが基本で、公式・自作いずれも書き込みはしません。GA4の設定がAIによって勝手に変わることはない、という前提です。
MCPそのものの仕組みは MCP連携とは で解説しています。この記事では、GA4に限った「どう用意するか」だけを扱います。
Google公式のGoogle Analytics MCPで足りなかった3点
まず前提として、公式サーバーはよくできています。GitHubの googleanalytics/google-analytics-mcp がそれで、無料・読み取り専用・first-partyです。導入は pipx run analytics-mcp を指定する形で、実質コマンド1行です。コミュニティ製の非公式ラッパーを使う理由は、もうほとんどありません。
それでも当社の用途には合いませんでした。理由は3つあり、いずれも機能ではなく「どこで動くか」に関する制約です。
① 「リモート」ではなくローカル型だった
公式は各自の端末で動かすローカル型で、ホスト型（リモート）は提供されていません。つまり利用者ごとに、端末にサーバーを入れ、認証情報のJSONファイルを置く必要があります。当社は「ディスクに秘密鍵を置かない」方針で他のMCPサーバーを運用していたため、ここが噛み合いませんでした。
② GA4はGoogle Cloudの公式リモートMCPの対象外だった
Google Cloudは2026年3月から、対応サービスを有効にすると自動でリモートMCPサーバーが使えるようになりました。BigQuery・Cloud SQL・Cloud Run など70製品以上が対象です。しかしGoogle Analytics・Analytics Data API・Search Consoleは、この一覧に含まれていません（2026年9月22日時点で再確認）。
③ Claudeのコネクタ一覧にもGA4はない
Claudeのコネクタ一覧にはNotionやSlackなどが並びますが、GA4・Search Console・Google広告といったデータ系サービスは収録されていません。ワンクリックで繋ぐ経路は、現時点では存在しません。
ツールの数では公式が上。ただし後から足せる
公平に書くと、機能面では公式のほうが充実しています。公式は7つ、当社の自作は2つからのスタートでした。
自作は2段階で進めた：まずトークン認証、次にGoogle認証
自作と決めてから、当社は2回作っています。1回目は最小構成の「トークン認証」、2回目が現在使っている「Google認証（OAuth 2.1）」です。先に最小構成を出して、人数が増えたときに困った点を2回目で直した、という順番です。
| 初版：トークン認証 | 現行：Google認証（OAuth 2.1） | |
|---|---|---|
| 利用者の手順 | 管理者からURLとトークンを受け取り、クライアントに登録 | コネクタにURLを登録し、Googleでログイン |
| GA4を呼ぶ名義 | サーバーが持つサービスアカウント（全員同じ） | 利用者本人のGoogleアカウント |
| 見えるプロパティ | サービスアカウントに権限を付けたもの全部 | 本人がGA4で見られるものだけ |
| 利用者を外すとき | トークンを無効化し、全員に再配布 | GA4側の権限を外すだけ |
| サーバーが持つ秘密 | サービスアカウントの鍵と共有トークン | OAuthクライアントの秘密のみ（GA4の鍵は持たない） |
| 構築の手間 | 4ファイル・本体約200行 | 認証まわりが増え、初版の数倍 |
トークン認証で困った2点
1つ目は「誰が呼んでも同じ権限」になること。サーバーは1つのサービスアカウントでGA4を呼ぶので、トークンを持つ人は、そのアカウントに権限を付けたプロパティを全部読めます。社内数人なら問題ありませんが、社外の人やクライアント企業に開放するには向きません。
2つ目はトークンの配布と回収。増員のたびに管理者がトークンを渡し、誰かが抜けたら全員分を作り直す運用になります。人数が10人を超えたあたりから、この手間が無視できなくなりました。
Google認証（OAuth 2.1）にすると何が変わるか
利用者は自分のGoogleアカウントでログインし、サーバーはその人の名義でGA4を呼びます。見えるデータの範囲は「本人がGA4で見られるもの」と完全に一致し、境界を決めるのはGoogle側になります。サーバーにはプロパティの許可リストもサービスアカウントの鍵もありません。コードにバグがあっても、本人の権限を超えて読める余地がない設計です。
ClaudeやChatGPTのカスタムコネクタは、この方式（OAuth 2.1＋PKCE、クライアントの自動登録、サーバー情報の自動取得）に対応しています。だから利用者側はURLを登録して、出てきたGoogleのログイン画面で許可するだけで済みます。
Google認証版の構成
当社の構成は Cloud Run ＋ HTTP ＋ OAuth 2.1 です。GA4の鍵はどこにも置きません。要点は「サーバーは本人のトークンを預かって代理で呼ぶだけ」という点にあります。
サーバーが用意しているもの
MCPのやりとりをする窓口が1つと、ログインまわりの窓口が数個です。ログインまわりは規格（OAuth 2.1・RFC 8414・RFC 9728）どおりに作ってあるので、ClaudeやChatGPTのコネクタが自動で見つけて使います。
| 窓口 | 役割 |
|---|---|
| MCP（Streamable HTTP） | ツール一覧の提示とGA4レポートの実行。ログイン済みの人だけ通す |
| サーバー情報の公開（.well-known） | 「どこでログインするか」をクライアントに自動で教える。URL登録だけで済むのはこれのおかげ |
| クライアント登録 | ClaudeやChatGPTが自分を登録する。人手での事前登録は不要 |
| 認可・コールバック・トークン発行 | Googleのログイン画面へ送り、戻ってきた結果をもとに、サーバー用のトークンを発行する |
ツールは run_report（通常レポート）・run_realtime_report（直近30分）・ping・auth_status（ログイン済みかの確認）の4つです。求めるGoogleの権限は analytics.readonly のみで、書き込みはできません。公開版の mcp-dir Hub では、同じ1本の接続に Search Console（webmasters.readonly）と TrendViewer のツールも入っています。
初版（トークン認証）の中身も残しておく
「まず動くものを最短で」という場合は、初版の構成が今でも最小です。書くファイルは4つ、本体は約200行。同じ形でSearch Console用のサーバーも並べられます。
| ファイル | 役割 | 分量の目安 |
|---|---|---|
| server.py | ツールの定義、トークンの検証、GA4のAPI呼び出し。実質これが本体 | 約200行 |
| requirements.txt | 使うライブラリの指定（MCPのSDK、Google認証、Webサーバー） | 5行 |
| Dockerfile | コンテナ化の手順（Python 3.12） | 8行 |
| .dockerignore | コンテナに入れないファイルの指定 | 2行 |
利用者の手順は2ステップ
Google認証版で、利用者がすることは次の2つだけです。端末に何かを入れる作業はありません。
- コネクタにURLを登録する。Claudeなら設定の「コネクタ」から「カスタムコネクタを追加」を選び、サーバーのURLを貼ります。ChatGPTも同様です。
- Googleでログインする。登録直後にGoogleのログイン画面が開くので、GA4を見ているアカウントを選び、読み取りを許可します。
これで、チャット欄に「先月の流入元別のコンバージョンを出して」と書けば動きます。見えるプロパティは、そのアカウントがGA4の管理画面で見られるものと同じです。
人数が増えたときに差が出る
1人で使うなら公式が手軽です。差がつくのは利用者が増えたときで、ここが当社の決め手になりました。公式は端末ごとに導入するので設定作業が人数分だけ発生し、自作は初回の構築1回で済みます。さらにGoogle認証版なら、増員時のトークン発行すら不要です。
自作でうまくいかなかったこと
良いことばかりではありません。実際に運用して困った点を、初版と現行それぞれから挙げます。
初版・現行に共通するもの
仕様変更の追随は自分持ちになる。GA4のAPIが変われば自分で直す必要があります。公式なら追随してもらえるので、ここは明確に不利です。半年に一度は動作確認する運用にしています。
接続済みなのに「ツールが0個」と表示されることがある。同時に多くのセッションから叩くと、ツール一覧の取得がタイムアウトする症状です。サーバー自体は生きているので、慌てて作り直す必要はありません。当社はこの場合、REST APIを直接叩いてその場をしのいでいます。原因の切り分けを知らないと「壊れた」と誤診しがちな挙動です。
最初はツールが少ない。前述のとおり、ファネル分析やカスタムディメンションの確認は後から足す前提になります。「あとで足せる」は裏を返せば「今はない」なので、最初に必要な分析を洗い出しておくほうが手戻りが減ります。
Google認証版で新たに出たもの
Googleの審査が要る。GA4の読み取り権限（analytics.readonly）はGoogleが「機微なスコープ」に分類しています。審査を受けていないアプリは、外部ユーザーの上限が100人です。社内や取引先の数十人までなら審査なしで足りますが、それを超えて開放するならGoogleの審査を通す必要があります。当社は2026年10月1日に審査を申請し、結果待ちです（ブランディングの確認は即日、データアクセスの審査は数日〜数週間かかります）。審査が通るまでは、ログイン時に「このアプリは Google で確認されていません」という警告が出ます。「詳細」から進めますが、初めての人には説明が要ります。必要なものは、自社ドメインのURL、プライバシーポリシーへの明記（何を読み、何を保存し、AIの学習に使わないこと）、ログインからデータ表示までの説明動画の3つでした。
ログイン状態の保存場所を決めないと、再デプロイで全員ログアウトになる。初版のようにサーバーが1つの鍵を持つ構成と違い、Google認証版は「誰がログイン済みか」をサーバーが覚えておく必要があります。これをメモリに置いたままだと、デプロイし直すたびに全員がログインし直しになり、サーバーを2台以上に増やすと片方が発行したログインをもう片方が知らない状態になります。当社は当初Cloud Runを1台に固定して回避していましたが、公開に合わせて保存先を Firestore に移し（トークンは暗号化して保存）、再デプロイしてもログインが切れなくなりました。
公開して分かったもの（2026年10月追記）
社内数人から「誰でも使える」に広げる前にセキュリティ診断をやり直したところ、認証まわりに2つの穴が見つかりました。どちらも直してから公開しています。
認可コードがそのままアクセストークンとして通っていた。Googleログイン直後に発行する一時的なコードを、本物のトークンと同じ場所に保存していたため、コードを手に入れた人は本来必要な検証（PKCE）を飛ばして10分間データを読めました。コードの保存場所をトークンと分け、検証に通ったときだけトークンを発行するように直しました。
偽のリンクで他人のセッションを奪える構造だった。サーバー側に「どのアプリに、どこへ接続を渡すか」を利用者に見せる画面がなく、Googleの同意画面（正規のアプリ名）だけで進んでいました。攻撃者が自分の受け取り先を指定したリンクを踏ませれば、被害者がGoogleでログインするだけで接続が奪えます。これはOAuthの仕様上よく知られた問題で、登録済みのアプリしか受け付けない・ClaudeやChatGPT以外の接続先には確認画面を出す、の2つで塞ぎました。
不特定多数が同時につなぐと「混みすぎ」で断られる。ClaudeやChatGPTからの登録・トークン取得は、各社のサーバーから来るため全利用者が同じ送信元に見えます。送信元ごとの回数制限を社内向けのまま公開すると、数人が同時に接続しただけで失敗します。公開前にサーバー間の窓口だけ上限を引き上げました。
逆に、想定したほど問題にならなかったのが費用です。Cloud Runはリクエストがない間は課金されないため、社内数人が1日に数十回叩く程度では月額はごくわずかで済んでいます。これは初版・現行とも同じです。
どれを選ぶか
よくある質問（FAQ）
GA4のMCPサーバーは公式のものがありますか？
あります。GitHubの googleanalytics/google-analytics-mcp がGoogle公式です。ただし2026年9月時点では実験版で、各自の端末で動かすローカル型です。ホスト型（リモート）は提供されていません。
GA4はGoogle Cloudの公式リモートMCPで使えますか？
使えません。2026年9月時点で70製品以上がリモートMCPに対応していますが、Google Analytics・Analytics Data API・Search Consoleは対象外です。
自作の「トークン認証」と「Google認証（OAuth 2.1）」は何が違いますか？
トークン認証はサーバーが1つの鍵でGA4を呼ぶため、トークンを持つ人は全員同じ範囲が見えます。Google認証は利用者が自分のGoogleアカウントでログインし、本人がGA4で見られる範囲だけが見えます。利用者の手順もURL登録とGoogleログインだけになるため、社外にも広げるならGoogle認証をおすすめします。
Google認証版を使う側に必要なものは何ですか？
GA4のプロパティを閲覧できるGoogleアカウントと、ClaudeまたはChatGPTのカスタムコネクタが使えるプランだけです。端末にサーバーを入れたり、鍵ファイルを置いたりする作業はありません。
GA4のMCPサーバーは自分で作らないと使えませんか？
いいえ。1人で使うなら公式のローカル版がコマンド1行で導入できます。「チームで共有したい」「端末に鍵を配りたくない」という条件が出てきたときに、はじめて自作を検討してください。当社が同じ構成で運用しているサーバーを mcp-dir Hub として公開しているので、URL登録とGoogleログインだけでGA4とSearch Consoleを読むこともできます（無料）。社内に手が足りない場合は、同じ構成での構築代行も承っています。
この記事について
- 初版は2026年9月7日、Google認証版の追記は2026年9月22日時点の検証です。各サービスの仕様は変わるため、半年ごとに検証し直して更新します（次回 2027年3月予定）。
- 第三者のMCPコネクタ（Windsor・Porter 等）は未検証です。公開資料の範囲でのみ記載しています。
- 当社の構成は Cloud Run ＋ HTTP ＋ OAuth 2.1（Google認証）で、現在は GA4・Search Console・TrendViewer を1本の接続で読む mcp-dir Hub（接続URL
https://hub.haldata.net/mcp）として公開しています。初版のトークン認証版も最小構成として残しています。セキュリティ上、認証の実装の詳細は掲載していません。 - レビュー分析データをAIから直接扱う仕組みは TrendViewer MCP、MCPそのものの解説は MCP連携とは をご覧ください。構築のご相談は お問い合わせ から承ります。