GA4×AIエージェント：Google Analyticsに質問するだけで答えが返ってくる

GA4向けのAIエージェントとは、Google Analyticsのプロパティへのアクセス権を持ち、普段の言葉で投げかけた質問を適切な指標・ディメンション・期間に置き換え、Data APIでレポートを実行して、文章で答えてくれるソフトウェアです。レポートを組み立てる作業から、質問するだけのスタイルへと変わります。

口に出せば6秒で済む疑問のために、20分かけてデータ探索を組んだ経験がある人なら、その魅力はすぐにわかるはずです。一方で、あまり語られないものの、同じくらい現実的なリスクもあります。エージェントがディメンションを取り違えると、自信たっぷりで読みやすい、けれど間違った答えが返ってきます。しかも出力を見ても、正しい答えとまったく見分けがつきません。

この記事では、接続の仕組み、何を質問すべきか、エージェントがGA4特有でやりがちなミス、そしてコストについて解説します。

GA4向けAIエージェントとは？

構成要素は3つです。1つ目は接続で、読み取り専用スコープによるプロパティへのOAuthアクセスです。2つ目は変換レイヤーで、「前四半期のモバイルのコンバージョンはどうだった？」といった質問を、Googleが求める指標名・ディメンション名・期間を含むData APIリクエストに変換します。3つ目はループで、エージェントが返ってきた結果を見て、答える前に2回目のクエリが必要かどうかを判断する仕組みです。

この3つ目こそが、エージェントと自然言語の検索ボックスを分けるポイントです。「なぜコンバージョンが落ちたのか」と聞くと、検索ボックスはコンバージョンのグラフを返すだけです。エージェントはコンバージョンを取得し、減少が1つのチャネルに集中していることに気づき、そのチャネルをランディングページ別に取得して、原因となっている2ページを突き止めます。つまり、文字どおり入力した内容ではなく、本当に知りたかったことに答えてくれるのです。

Google Analytics 4にAIエージェントを接続する方法

方法は2つあり、どちらが合うかはマーケターか開発者かによって変わります。

方法1：ホスト型のOAuth接続

マーケター向けの方法です。Googleアカウントでプロダクトを承認してプロパティを選ぶと、接続情報がサーバー側に保存され、毎回のクエリで再利用されます。当社の実装では、エージェントは最初のGA4ツール呼び出しの時点で有効なAnalytics接続があるかを確認します。接続がない場合も、エラーで止まったり当て推量で進めたりはしません。連携設定画面へのディープリンク付きで接続を促すインタラクティブな案内を表示し、接続後に会話を再開します。プロパティは、ワークスペースの設定で指定していればそれを使い、指定がなければ接続先の最初のプロパティを使います。

セットアップは数分で、インストールも不要です。その代わり、使えるのはベンダーが用意したツールカタログに限られます。

方法2：MCP

開発者向けの方法です。Googleは公式のGoogle Analytics MCPサーバーを公開しており、MCP対応のクライアントならどれでもGA4を扱えるようになります。提供されるのは run_report、run_realtime_report、run_funnel_report、get_account_summaries、get_property_details、get_custom_dimensions_and_metrics、list_google_ads_links です。認証は読み取り専用のAnalyticsスコープでApplication Default Credentialsを使います。実際には、Google CloudプロジェクトでAdmin APIとData APIを有効にし、gcloud auth application-default login を実行することになります。

これをベースに開発する前に、注意点が2つあります。まず、Googleはこのサーバーを試験運用版（experimental）と明記しています。次に、MCPがエージェントに与えるのはツールであって、どれを呼ぶべきかという判断力ではありません。推論の質は、あくまでモデルとプロンプト次第です。

普段の言葉でGA4にどんな質問ができるか

うまくいく質問には共通の型があります。比較の軸、セグメント、そして絶対日付で指定した期間です。

Compare organic search conversions for [date range A] against [date range B],
broken down by landing page. Show the 10 pages with the largest absolute change.
Flag any row where sessions are low enough that the rate change may be noise.

Which acquisition channels improved and which declined over [date range],
measured by conversions rather than sessions? Name the conversion event you used.

Where do users drop off before completing [goal] over [date range]?
Give raw counts alongside percentages.

Is the gap between mobile and desktop conversion rate widening or narrowing
versus the previous equivalent period? Show both periods.

うまくいかないのは、漠然とした質問です。「サイトの調子はどう？」と聞くと、あらゆることの要約が返ってくるものの、結論は何もありません。しかもコストは高くつきます。目的があいまいなほど、明確な質問よりも多くのクエリに展開されるからです。

自動化する価値のあるGA4の指標

動いたら必ず理由を説明すべき指標は自動化し、それ以外は必要なときに聞けば十分です。

指標	自動化する理由	注意点
チャネル別コンバージョン	ビジネスが本当に気にしている数字だから	どのコンバージョンイベントがメインに設定されているか
ランディングページ別コンバージョン率	ページの問題とトラフィックの問題を切り分けられる	母数が小さいと極端なパーセンテージが出る
参照元別エンゲージメント率	コンバージョンが動く前に質の変化をつかめる	Universal Analyticsの直帰率とは定義が異なる
チャネル別収益	施策を売上に結びつけられる	使用しているアトリビューションモデル
デバイス別・国別セッション	率の変化の裏にある構成の変化を説明できる	カーディナリティが高く、行が (other) にまとめられる

AIエージェントがGA4データでやりがちな分析ミス

このセクションはぜひ2回読んでください。以下のミスはどれも、出力だけ見るとまったく普通に見えます。

クリック数とセッション数を同じものとして扱う。Search Consoleは検索結果のクリックを数え、GA4はページが読み込まれた後のセッションを数えます。両者が一致することはありません。エージェントがその前提に触れずに比較すると、定義の違いにすぎない「差異」を「発見」してしまいます。

ユーザー単位とセッション単位の指標を混ぜる。ユーザー単位の指標をセッション単位の指標で割っても、意味のない数字ができるだけです。それでも、きちんと小数点以下2桁まで整形されて出てきます。

(not set) と (other) を無視する。カーディナリティの高いディメンションは (other) にまとめられ、アトリビューションできないトラフィックは (not set) に入ります。エージェントが表示されている行だけを合計して総数として報告すると、この2つを黙って除外していることになります。

小さな母数から変化率を読み取る。コンバージョンが2件から3件になれば50%の改善ですが、実質的には何も起きていません。必ず率と並べて実数も表示するよう、エージェントに指示しましょう。

どのコンバージョンイベントを使うのかがあいまい。ほとんどのプロパティでは複数のキーイベントが設定されています。プロンプトで指定しなければエージェントが勝手に選び、その選択は実行するたびに変わる可能性があります。

相対的な期間指定。「先月」がいつを指すかは、プロパティのタイムゾーンやクエリの実行タイミングによって変わります。施策の判断に使う分析では、絶対日付を使いましょう。

対策は、数字が重要なプロンプトの末尾に次の一文を加えることです。

Every figure must come from the connected property.
Where a figure is unavailable, write "not available" - never estimate.
State the metric, dimension and date range you used for each number.

大事なのは最後の一文です。これでエージェントは使ったクエリを示すようになり、「信じるしかない主張」が「30秒で検証できる主張」に変わります。

エージェントが守るべきGA4 APIの上限

これは豆知識ではありません。そもそもどの質問に答えられるかを左右する条件です。

GoogleのData APIの割り当てに関するドキュメントによると、標準プロパティでは1プロパティあたり1日200,000コアトークン、1時間あたり40,000、1プロジェクト・1プロパティあたり1時間14,000、同時コアリクエストは10件までです。Analytics 360のプロパティでは1日2,000,000、同時リクエストは50件まで。そして重要なのが、リクエストの複雑さがトークン消費量を左右するという点です。ディメンションが多いほど、期間が長いほど、カーディナリティが高いほど、多くの割り当てを消費します。リクエストに returnPropertyQuota を追加すれば、リアルタイムの消費量を確認できます。

実務上の影響として、大規模なプロパティでエージェントに自由に探索させると、1日の割り当てを午後だけで使い切ってしまうことがあります。そうなると、リセットされるまで後続のレポートはすべて失敗します。ディメンションを絞り、期間を具体的に指定したプロンプトは、わかりやすいだけでなく、追加購入できない「通貨」の節約にもなるのです。

GA4からはエージェントが答えられないこと

プロパティの中にそもそも答えがない質問もあります。良いエージェントと悪いエージェントの違いは、それを正直に言えるかどうかです。

データ探索で、保持期間を超える範囲のこと。Googleのデータ保持に関するドキュメントでは、標準プロパティのユーザー単位・イベント単位のデータ保持期間は2か月または14か月で、360でない限り14か月が上限です。Google シグナルのデータは、設定にかかわらず26か月が上限です。ここで重要なのは、保持期間が影響するのはデータ探索とファネルレポートであって、標準の集計レポートではないという点です。そのため、長期間にわたるチャネル単位のトレンドには正しく答えられても、同じ期間のユーザー経路については答えられない、ということが起こり得ます。エージェントがこの2つを区別しなければ、それらしい何かを出力してしまいます。

しきい値が適用されているもの。ユーザー数が少なく個人が推測できてしまう場合、GA4はその行を表示しません。エージェントが見えている分だけを合計して総数として示すと、本人も気づかないまま過少な数字を報告していることになります。

同意していないユーザーに関すること。同意の設定によっては、行動データの一部がモデリングされた推計値になるか、そもそも存在しません。この欠落はエラーとしては現れず、単に小さい数字として現れます。

エージェントに直接こう聞いてみてください。「この分析のうち、保持期間の上限、しきい値、同意による欠落の影響を受けているのはどの部分？」この質問に正直に答えられるエージェントなら、使い続ける価値があります。

AIエージェントにGoogle Analyticsへのアクセスを渡しても安全か？

GA4へのアクセスは、付与できる連携の中でも比較的安全な部類です。理由は構造的に3つあります。スコープが読み取り専用なので何も変更されないこと。Googleアカウントからいつでもアクセスを取り消せること。そして最悪の結果でも「間違った結論」にとどまり、それはプロパティを見れば自分で確認できることです。

それでも注意すべき点が2つあります。1つ目は、設定によってはGA4データに個人データが含まれる可能性があるため、エージェントのベンダーがクエリ結果をどこで処理・保存しているかを把握しておくことです。2つ目は、同じエージェントが任意のWebページも取得できる場合、外部の誰かが書いたテキストをあなたの指示と同じコンテキストに持ち込める、いわゆるプロンプトインジェクションの問題です。当社のランタイムでは、各ツールに「読み取り」「生成」「書き込み」のタグを付け、取得したコンテンツを信頼できないものとして隔離し、信頼できないコンテンツが入ってきたターンでは、そのターンが終わるまで書き込みタグのツールを実行しないようにしています。GA4のクエリは「読み取り」タグなので、どちらにしても影響はありません。

GA4エージェントのクエリにかかるコスト

コストは2つの要素で決まります。1つはツール呼び出しです。当社のカタログではGA4クエリは1回につき50クレジットで、本格的な調査では何回も呼び出します。エージェントはデータを取り、確認し、また取りに行くからです。もう1つはモデルのトークンです。1ターン内のすべてのモデル呼び出しを合わせて100万トークンあたり300クレジットで課金され、コンテキストに入るデータ量に比例します。50行を返すクエリが、5,000行を返すクエリよりも推論コストがはるかに安いのはこのためです。

ここから導かれるルールは、割り当てと同じです。幅広さより精度のほうが安くつきます。「サイトの調子はどう？」は、クレジットの面でも割り当ての面でも最も高くつく質問であり、しかも返ってくる答えは最も使えないものになります。

エージェントはLooker Studioの代わりになるか？

なりません。理由は能力ではなく再現性です。ダッシュボードは毎回同じ指標を同じレイアウトで表示します。モニタリングや、クライアントに定期的に見せるものには、まさにそれが必要です。一方エージェントは、同じ質問でも日によって違うルートをたどることがあります。

うまくいく役割分担は、ダッシュボードが「何が起きたか」に答え、エージェントが「なぜ起きたか」に答えるという形です。定点観測にはダッシュボードを残し、ダッシュボードに説明のつかない動きが出たときにエージェントに聞きましょう。定期的な納品物については、柔軟性より確実な再現性が重要になるので、GA4レポートの自動化の記事を参考にしてください。

まず何から始めるか

プロパティを読み取り専用で接続し、今四半期すでに手作業で答えを出した質問を1つエージェントに聞いてみましょう。そして結果を比べます。次に、各数字の裏にある指標・ディメンション・期間を示すよう指示し、そのうち1つをGA4の管理画面で確認してください。これを2回やるだけで、ベンダーの資料をいくら読むよりも、そのツールを信頼できるかどうかがよくわかります。

Autopilotは、ここで説明したOAuthフロー、接続の案内、クエリのループを、あなた自身のプロパティに対して実行します。