GA4 の公式 MCP サーバーを勘違いした話 |岡山、広島、福山の人材支援、IT化支援の株式会社シーズ

GA4 の公式 MCP サーバーを勘違いした話 - 株式会社シーズ|岡山、広島、福山の人材支援、IT化支援の株式会社シーズ

GA4 の公式 MCP サーバーを勘違いした話

こんにちは!システム開発チームです。

当社もいろいろな業務で AI を利用していますが、MCP の設定で少し勘違いしたお話です。

事の始まり

Claude で GA4 のデータ分析を行いたくて MCP サーバーの設定を始めました。紹介サイトやらを見て回ると、あちこちに「公式」の文字。よし、これだ、と迷わず採用。

GCP プロジェクトとサービスアカウントを作成し、GA4 プロパティにアカウントを追加、Claude の MCP 設定もすんなり終わり、無事に GA4 への接続に成功しました。

「公式ツールだし、これでもう安心」——このときは何の疑いもなくそう思っていました。

あれ、プロパティごとに設定し直すの?

使い始めてすぐに違和感がありました。

GA4 のプロパティを複数扱いたかったのですが、このパッケージは、~/.claude.json 内の MCP 設定で環境変数 GA_PROPERTY_ID に 1 つのプロパティ ID を固定で渡す設計。つまり「1 プロパティ = 1 サーバー」で、複数のプロパティを見るには mcpServers にサーバー名を変えてエントリをいくつも並べるしかありませんでした。

おまけにサーバーの数だけ npx プロセスが起動するので、増やしすぎると起動時間・リソースが増える点が気になります。

「公式ツールなのに、不便な作りだな」と思いつつ、まあそういうものかと納得しかけていました。

「公式はプロパティを横断管理できる」という情報にぶつかる

念のため他のやり方がないか調べていたところ、「公式の MCP サーバーなら複数プロパティを横断的に扱える」という情報を見つけました。

あれ、さっき使ったやつも公式のはずでは……?

半信半疑で Claude に聞いてみたところ、あっさりこう返ってきました。

それは公式ではありません。

調べ直してみると、実態はこうでした。

  • 利用していた mcp-server-google-analytics の開発者は Google とは無関係の 個人
  • パッケージマネージャ上ではすでに サポート終了し、リポジトリもアーカイブされた

聞いた瞬間、思わず二度見しました。あちこちのサイトで「公式」っぽく紹介されていたのはなんだったのか…。ちょっと頭が混乱してきました。

本物の公式に乗り換える

改めて Google 自身の開発者向けサイトを確認すると、googleanalytics という公式組織配下で、まったく別の MCP サーバー実装(analytics-mcp)が公開されていました。こちらこそが正真正銘の公式ツールで、複数プロパティを横断して扱える設計になっていました。

ここから、次の対応を行いました。

  • pipx をインストールし、commandnpx から変更
  • パッケージを analytics-mcpGoogle 公式)に切り替え
  • 認証方式を変更(プロパティ固定の環境変数方式から、GCP サービスアカウント鍵のファイルパスを指定する方式に)
  • GCP プロジェクトに Google Analytics Admin API の権限を追加(Data API 権限は事前に設定済み)
"analytics-mcp": {
  "command": "pipx",
  "args": ["run", "analytics-mcp"],
  "env": {
    "GOOGLE_APPLICATION_CREDENTIALS": "/Users/user-name/.claude/credentials/ga-service-account.json",
    "GOOGLE_PROJECT_ID": "my-project-id"
  }
}

作業自体は淡々と進みましたが、「最初からこっちを使っていれば二度手間にならなかったのに」という気持ちは拭えませんでした。

AI に聞いても間違えた

余談ですが、今回の一件を後で Gemini にも聞いてみたところ、「mcp-server-google-analytics は公式です」という趣旨の回答が返ってきました。こちらから間違いを指摘すると、素直にこう返してきました。

失礼いたしました、ご指摘の通りです。mcp-server-google-analytics という名前のリポジトリは Google 公式のものではありません。不正確な情報をお伝えしてしまい申し訳ありません。

人間だけでなく、AI も各所の「公式」表記をそのまま鵜呑みにしていたわけです。それだけこの誤解が広く出回っている、ということの裏返しでもあります。

それでも、あえて非公式を選ぶ理由がなくもない

非公式の mcp-server-google-analytics ですが、実は一概に「劣っている」とも言い切れません。

公式の analytics-mcp は、Admin API を使ってサービスアカウントがアクセスできる 全アカウント・全プロパティを横断的に一覧・操作 できてしまいます。裏を返せば、利用者に渡す権限としてはかなり大きい。一方、非公式パッケージは環境変数でプロパティ ID を 1 つに固定する不便な設計でしたが、これは言い方を変えれば「そのプロパティ以外には絶対に手が届かない」という 最小権限 の構成でもあります。

「特定のサイトのデータだけ見せたい、他のプロパティには絶対に触れさせたくない」というような、権限を意図的に絞りたい場面に限っては、非公式パッケージの不便さがそのまま安全装置として機能する、というのが唯一の使いどころかもしれません。

教訓

一番怖いのは、今回の「公式」表記のように 間違ってはいないのに誤解を招く パターンです。「公式です」と嘘をつかれたわけではなく、こちらが言葉の意味を早合点しただけなので、後から見返しても「まあ、そう読むよなぁ」となってしまい、非常に気づきにくいのです。AI に聞いても最初は同じ勘違いをする、というのがその根深さを物語っています。

MCP サーバーに限らず、外部パッケージを「公式」という触れ込みだけで信用する前に、

  • 提供元がその企業の公式組織・公式ドメインかどうか
  • パッケージマネージャ上でサポート終了になっていないか
  • 逆に、権限を絞りたいなら「不便な非公式」がむしろ都合が良い場合もある

の 3 点を意識しておくと、今回のような遠回りや、必要以上に大きな権限を渡してしまう事態を防げそうです。