自社サイトにコンテンツ記事の追加を始めたところ、その効果測定で手が止まりました。Googleアナリティクス（GA4）は導入済みで、データは日々蓄積されています。それでも「先月追加した記事は読まれているのか」を確認するのに、毎回手間取る。

原因ははっきりしていました。知りたいことは日本語で言えるのに、それをGA4の画面操作に翻訳する工程が挟まる。この翻訳ができないと数字にたどり着けません。

本稿では、この翻訳工程を生成AIに任せる構成——MCPを使ってGA4と生成AIを直接つなぐ方法——について、当社で実際に構築した手順と、途中でつまずいた点をそのまま整理します。

課題の所在 — GA4は「使える人」を選ぶツールになっている

GA4は柔軟性の高いツールです。ただしその柔軟性は、利用者が自分で分析を設計できることを前提にしています。ディメンションと指標を選び、期間を指定し、必要ならフィルタを組む。この設計ができる人にとっては強力ですが、日常的に触っていない担当者にとっては相応のハードルになります。

結果として、次のような状態が生じます。

• どの画面を開けば知りたい数字が出るのか分からない
• 確認のたびに操作方法を調べ直すため、数字を見る行為が習慣化しない
• アクセス解析ができる担当者が限られ、業務が属人化する

当社でも同じことが起きていました。コンテンツを追加しても、その反応を確認するには操作方法を思い出すところから始めなければならず、確認の頻度が落ちていく。データはあるのに、意思決定に使われない状態です。

ここで押さえておきたいのは、これを「担当者のスキル不足」と捉えないことです。問題はツールと利用者の間のインターフェースにあります。「先月追加した記事は読まれているか」という問いは日本語で明確に表現できているのに、それを画面操作へ翻訳する工程がボトルネックになっている。だとすれば、解くべきはその翻訳工程です。

解き方を変える — 習得するのではなく、習得せずに済む形にする

一般的な解決策は「担当者を教育する」ことです。しかし、日常業務の片手間で使うツールに対して習得コストを払い続けるのは現実的とは言えません。担当者が変われば振り出しに戻ります。

そこで当社が取ったのは、GA4の操作方法を習得するのではなく、GA4に自然言語で問い合わせられる環境を用意するというアプローチです。

これを可能にするのがMCP（Model Context Protocol）です。生成AIと外部のツールやデータソースを接続するための規格で、対応するサーバーを用意すると、AIが外部システムのデータを直接参照できるようになります。

Google Analyticsについては、Googleが公式のMCPサーバーをオープンソースで公開しています。ライセンスはApache 2.0で、GitHub上で開発されています。これを生成AIのクライアントに接続することで、次のような問いかけに実データで答えられる状態になります。

• 「先月のセッション数をチャネル別に出して」
• 「今月追加した記事のうち、最も読まれているのはどれか」
• 「オーガニック検索からの流入が増えているページを教えて」

担当者に求められるのは「何を知りたいか」を言語化することだけになります。ディメンション名を覚える必要も、探索レポートを組み立てる必要もありません。

何ができるようになるか

このMCPサーバーは、Google Analytics Admin APIとData APIを利用してデータを取得します。当社が導入したバージョン0.7.0では、以下の機能が利用できました。

前提として押さえておくべき点が2つあります。

ひとつは読み取り専用であることです。GA4の設定を変更する操作は含まれておらず、AIが誤って計測設定を壊す心配はありません。また、サーバーは利用者のマシン上でローカルに動作するため、認証情報が外部のサービスに送信されることもありません。

もうひとつは、Googleがこれを「Experimental（実験的）」と位置づけていることです。リポジトリ上でも実験的な位置づけが明示されており、将来的な仕様変更の可能性は考慮しておく必要があります。基幹業務に組み込むのではなく、まずは日々の確認作業から使い始めるのが妥当な入り方だと考えています。

構築手順

実際の手順を記します。macOS環境を前提とし、所要時間は30分程度でした。プロジェクトIDなどは例示の値に置き換えています。

1. Google Cloud CLIの導入

Google CloudのAPIを利用するため、CLIツールを導入します。

brew install --cask google-cloud-sdk

あわせて、MCPサーバー本体が起動するかを先に確認しておくと切り分けが楽になります。

uvx analytics-mcp

「Starting MCP Stdio Server」と表示されれば正常です。公式ドキュメントでは pipx の利用が案内されていますが、Pythonパッケージマネージャの uv が導入済みであれば uvx でも動作します。必要なPython環境は自動で用意されるため、新たにpipxを入れる必要はありませんでした。

2. Google Cloudプロジェクトの作成とAPIの有効化

認証情報の管理範囲を明確にするため、この用途専用のプロジェクトを作成することを推奨します。既存プロジェクトに相乗りすると、不要になった際の後片付けが煩雑になります。

gcloud auth login
gcloud projects create my-ga4-mcp --name="GA4 MCP"
gcloud config set project my-ga4-mcp
gcloud services enable analyticsadmin.googleapis.com analyticsdata.googleapis.com

有効化するのは、プロパティ情報を扱う「Google Analytics Admin API」と、レポートデータを取得する「Google Analytics Data API」の2つです。いずれも無料枠で利用できるため、課金アカウントの紐付けは不要でした。

3. 認証方式を選ぶ

公式ドキュメントでは、利用者個人のGoogleアカウントで認証する方式（Application Default Credentials）が案内されています。当社でもまずこの手順を試しましたが、ブラウザ上で「このアプリはブロックされます」と表示され、認証を完了できませんでした。

OAuth同意画面の対象は組織内部に設定しており、その点に不備はありませんでした。Google Workspaceの管理コンソールにある、外部アプリケーションのアクセス制御に起因するものと考えられます。この制御は、自組織内で作成したアプリケーションであっても対象になる場合があります。

対処の方向性は2つあります。管理コンソールで当該のクライアントを許可する方法と、サービスアカウント方式に切り替える方法です。当社は後者を選びました。理由は3点あります。

• OAuth同意画面を経由しないため、組織のアプリケーション制御ポリシーの影響を受けない
• 組織全体のセキュリティ設定を変更せずに導入できる。1つのツールを動かすために全社の設定に手を入れるのは、影響範囲が釣り合わない
• ブラウザでの再認証が不要なため、定期実行による自動レポート生成へ発展させやすい

そもそもGA4のデータは、メールや文書のような業務データとは性質が異なります。専用のアカウントを作り、必要なプロパティにのみ明示的に閲覧権限を与える構成のほうが、権限管理の見通しも良くなります。

4. サービスアカウントの作成

gcloud iam service-accounts create ga4-mcp \
  --display-name="GA4 MCP" \
  --project=my-ga4-mcp

mkdir -p ~/.config/ga4-mcp
chmod 700 ~/.config/ga4-mcp

gcloud iam service-accounts keys create ~/.config/ga4-mcp/service_account.json \
  --iam-account=ga4-mcp@my-ga4-mcp.iam.gserviceaccount.com

chmod 600 ~/.config/ga4-mcp/service_account.json

発行されるキーファイルは、それ単体でGA4のデータにアクセスできる秘密鍵です。クラウドストレージの同期対象フォルダやGitリポジトリの中には置かず、アクセス権限を制限した専用ディレクトリで管理してください。当社の作業ディレクトリはクラウド同期下にあるため、意図的にホーム配下へ隔離しています。

5. GA4側で閲覧権限を付与する

作成したサービスアカウントは、GA4から見れば見知らぬ新規ユーザーにすぎません。GA4の管理画面から明示的に権限を与える必要があります。

1. Googleアナリティクスの「管理」を開く
2. プロパティ列の「プロパティのアクセス管理」を選択する
3. 「＋」からユーザーを追加し、サービスアカウントのメールアドレスを入力する
4. 「新規ユーザーにメールで通知する」のチェックを外す（サービスアカウントにメールは届きません）
5. 役割は「閲覧者」を選んで追加する

複数のプロパティを対象にする場合は、プロパティ単位ではなくアカウント単位で権限を付与すると、配下のプロパティにまとめて適用できます。役割は「閲覧者」で十分です。MCPサーバー自体が読み取り専用である以上、それ以上の権限を与える意味はありません。

6. 生成AIクライアントへ登録する

当社ではClaude Codeを利用しているため、次のコマンドで登録しました。

claude mcp add analytics-mcp \
  --scope user \
  -e "GOOGLE_APPLICATION_CREDENTIALS=$HOME/.config/ga4-mcp/service_account.json" \
  -e "GOOGLE_PROJECT_ID=my-ga4-mcp" \
  -- /opt/homebrew/bin/uvx analytics-mcp

ユーザー単位で登録することで、作業ディレクトリを問わず利用できるようになり、認証情報のパスが個別プロジェクトの設定ファイルに記録されることも避けられます。また、実行コマンドは絶対パスで指定しておくと、環境変数の差異による起動失敗を防げます。

7. 動作確認

登録後、クライアントを再起動してから確認します。実際に「直近28日のセッション数をチャネル別に出して」と日本語で問い合わせたところ、チャネル別の集計が返ってきました。GA4の管理画面を一度も開くことなく、必要な数字にたどり着けています。

つまずいた3つのポイント

構築の過程で時間を要した箇所を、そのまま共有します。

① 認証がブロックされる

前述のとおりです。Google Workspaceを利用している組織では、公式ドキュメントの手順どおりに進めても認証が完了しない場合があります。組織の設定を変更する権限がない、あるいは変更したくない場合は、サービスアカウント方式への切り替えが現実的な回避策になります。

② GA4側の権限付与を忘れる

手順5を実施しないまま進めると、認証には成功するのにプロパティが1件も取得できないという状態になります。エラーメッセージが出ないため原因を特定しづらく、最も時間を消費しやすい箇所です。データが空で返ってくる場合は、まずGA4側の権限設定を確認してください。

③ クライアントを再起動していない

MCPサーバーの登録が完了していても、起動中のセッションには反映されません。接続状態が正常と表示されているのにAIがツールを認識しない場合は、再起動で解決します。

運用設計 — MCPに分析まで任せない

運用して分かったのは、MCPに分析まで担わせようとすると破綻するということです。

レポートの取得結果は、そのまま生成AIの処理対象になります。期間を広げたりディメンションを増やしたりすると行数が急増し、処理効率が落ちます。そこで役割を次のように分けています。

取得したデータを一度ファイルに書き出し、以降の集計はそのファイルに対して実行する。生成AIが直接扱うのは集計結果だけにする。この形にすると、扱うデータ量が増えても安定します。

もうひとつ有効なのが、よく使う分析パターンをあらかじめ定義しておくことです。自社で使うプロパティの情報、頻繁に使うディメンションと指標の組み合わせ、前月比・前年同月比といった定型の分析軸を書き留めておく。これを省くと、結局は「どの項目を指定すべきか」を都度調べることになり、GA4の画面で迷っていた状態と本質的に変わらなくなります。

数字を読むときの前提

API経由で取得しても、GA4のデータ特性そのものは変わりません。管理画面の数値と差異が生じる主な要因として、次の2点は理解しておく必要があります。

ひとつはデータのしきい値です。ユーザー数が少ない場合、個人が特定されることを避けるために行が出力されないことがあります。「0件」と「しきい値によって表示されていない」は別物です。

もうひとつは「(other)」行です。ディメンションの組み合わせが多くなると上限に達し、細かい値が「(other)」にまとめられます。詳細な内訳を見たい場合は、期間や条件を絞って取得し直す必要があります。

自動生成したレポートを他者と共有する場合は、こうした前提を注記として添えておくことをおすすめします。数字が独り歩きすると、誤った判断につながります。

まとめ

ツールが高機能であることと、現場で使われることは別の問題です。使われない理由が「操作が難しいから」であるとき、取りうる手段は2つあります。使いこなせる人材を育てるか、使いこなさなくても目的を達成できる形にするか。

MCPによる接続は後者にあたります。ツールの操作を習得するコストを生成AIに肩代わりさせることで、担当者は「何を知りたいか」という本質的な問いに集中できます。当社では、この構築によって数字を確認する頻度が明確に上がりました。習慣化を阻んでいたのは、意欲ではなく操作の手間だったということです。

同じ考え方は、GA4に限らず社内の各種システムに応用できます。データは蓄積されているのに参照されていない、特定の担当者しか扱えない状態になっている。こうした課題は、多くの場合ツールそのものではなく、ツールと利用者の間のインターフェースに原因があります。