アクセス解析は「見る」だけで止まりがちです。GA4をClaude CodeにMCPでつないだあと、数字を読む、仮説を立てる、直す、また測る、を一箇所で回し始めると、次の一手が決めやすくなります。ただし、回したからといって数字が上がる保証はありませんし、上がったとしても「その施策のおかげ」と言い切れるとも限りません。

この記事は、効く方法の紹介ではなく、私たちが自社サイトで試してきた運用の記録です。うまくいかなかった場面や、そもそも数字が動かなかった場面も含めて書きます。つなぎ方そのものは前提記事Claude CodeとGA4をMCPでつなぐにまとめてあるので、ここではつないだあとの回し方に絞ります。

GA4を「見る」で止まってしまう理由

GA4を開くと、ユーザー数、セッション、離脱率、いろいろな数字が並びます。ところが、その数字を前にして「で、明日から何を直せばいいのか」が出てこない。レポートは出るのに施策に落ちない、という状態は珍しくありません。

理由は、レポートが「起きたことの記録」だからです。数字は過去に何が起きたかを教えてくれますが、それをどう解釈し、どこに手を入れるかは、また別の頭の使い方を要します。グラフを眺める作業と、そこから打ち手を決める作業は、地続きに見えて実は別物なのです。

ムチオ
ムチオ
グラフは出るんだけど、で、結局どうすればいいの……ってなって、毎回そっ閉じしちゃうんだよね。
ルミナ
ルミナ
その感覚、とても正直だと思います。「見る」と「回す」は別の作業なんです。数字を眺めるところで止めず、そこから仮説を立てて手を動かすまでを一続きにすると、次の一手が決めやすくなりますよ。

その前に ── GA4の数字は「現実そのもの」ではない

回し方の話に入る前に、土台の注意をひとつ置いておきます。GA4に出てくる数字は、現実に起きたことの正確な写しではなく、計測できた範囲の近似だという点です。ここを飛ばすと、後の判断がまるごと危うくなります。

具体的には、次のようなことが起こります。

  • サンプリング。データ量が多い問い合わせでは、GA4は全件でなく一部を抽出して集計することがあります。GA4のData API経由だと、抽出が起きたかどうかの通知が出ないこともあります。
  • しきい値処理。件数が少ない行は、プライバシー保護のため表示されないことがあります。合計と内訳が合わないように見えるのはこのためです。
  • 行数の上限とその他への集約。組み合わせが多すぎると、あふれた分が「(other)」という行にまとめられます。細かい内訳が正確に見えているとは限りません。
  • 画面(UI)とAPIで値が違うことがある。GA4の管理画面で見た数字と、Claude Codeが読み取った数字がずれる場面があります。
  • そもそもの計測漏れ。タグの入れ忘れ、同意設定でオフになった計測、イベントの二重発火、複数ドメインをまたぐ導線、ボットや社内からのアクセス。こうした要因で、数字は簡単に上下します。
ムチオ
ムチオ
えっ、GA4の数字って、そのまま信じちゃダメなの?
ルミナ
ルミナ
丸ごと疑う必要はありませんが、そのまま現実だと思い込むのも危ないんです。数字は計測できた範囲の近似だと考えて、桁が大きくずれていないかを人が確かめる。その一手間を挟むだけで、判断のブレはだいぶ減りますよ。

改善ループの全体像 ── 読む→仮説→直す→また測る

前提を押さえたうえで、私たちがやっているのは次の4ステップを止めずに回すことです。

  1. 読む。GA4の数字をClaude Codeに読ませ、どこで人が動き、どこで止まっているかを言葉にしてもらう。
  2. 仮説。数字の中で気になる一点を選び、ここが弱いのはこういう理由ではと当たりをつける。
  3. 直す。その仮説に沿って、ページや広告設定を1か所だけ変える。同時にあれこれ変えない。
  4. また測る。直したあと、しばらく置いてもう一度同じ数字を見る。仮説の見立てと合っているかを、数字と照らす。

ここで、ステップ3の「1か所だけ変える」は良い習慣ですが、それだけで因果が確かめられるわけではありません。この点は実例②で正直に書きます。まずは4ステップを回すことより、回しながら「その数字の動きを、施策の効果だと言い切ってよいか」を疑う癖のほうが大事だと考えています。以下、私たちが実際に回している場面を3つ紹介します。

実例①:LPのどこで人が離れているかを、Claude Codeに読ませて仮説を立てる

最初によくやるのが、訪問から予約までの流れを段ごとに分けて、各段の到達率を出すことです。たとえば「ページを見た人」「ボタンを押した人」「予約まで進んだ人」という3段のファネルを作り、それぞれ次の段へどれだけ進んだかを見ます。

ここで先に断っておくと、このファネルは「頼めば勝手にできる」ものではありません。段の途中にあるCTAクリックや予約完了は、GA4がイベントとして計測できていて初めて数字になります。つまり、次のような準備が前提です。

  • CTAクリックや予約完了が、GA4のイベントとして正しく発火していること。
  • そのイベント名を把握していて、Claude Codeにどのイベントを段に使うか指定できること。
  • 予約ページが別ドメインなら、クロスドメインの計測設定ができていること。
  • 同じ行動を二重に数えていないこと(重複計測がないこと)。

この土台がないまま「ファネルを作って」と頼むと、AIは存在しないイベントから正しいファネルを作れません。計測がそろっていない段は、数字が出ても意味を持ちません。まずは自分のGA4に、段に使えるイベントがあるかを確認するところから始めます。

準備が整っていれば、Claude Codeへの頼み方はこんな型にしています。前提記事のとおり、GA4 MCPには段ごとの到達・離脱を出すrun_funnel_reportというツールが含まれているので、AIはそれを選んで実行します。

  • 「訪問 → CTAクリック(イベント名: click_cta) → 予約完了(イベント名: reservation_complete) のファネルを、直近30日で作って。各段の到達率と離脱率を出して」
  • 数字が出たら続けて「この中で、いちばん離脱が大きい段はどこ? そこで人が止まる理由として考えられる仮説を、3つ挙げて」

こうすると、Claude Codeは「この段で離脱が大きい」という指摘に加えて、「ボタンの文言が行動を促していないのでは」「その手前のページが長すぎて、たどり着く前に離れているのでは」といった仮説の候補を並べてくれます。私たちの場合、ある段で離脱が目立って大きいことが分かり、そこを最初の直しどころに決めました。ここでのポイントは、AIに事実の指摘だけでなく仮説の候補まで出させて、そこから人が1つ選ぶことです。仮説を選ぶ責任は人が持ちます。

実例②:直したら「また測る」 ── ただし数字が動いても因果は確定できない

仮説に沿ってボタンの文言やページの構成を直したあと、私たちは「よくなった気がする」で終わらせないようにしています。直した直後は、たいてい前より良く見えるものだからです。だから、しばらく置いてから同じファネルをもう一度出します。

ここが、この記事でいちばん誤解されやすいところです。「先週と今週を比べて、数字が上がれば仮説が当たり、下がれば外れ」と単純に判定してしまいそうになりますが、それは因果の証明にはなりません。相関と因果は違うからです。同じ期間には、施策以外の要因もいくらでも動いています。

  • 広告の流入量が増減した
  • 流入してきた検索キーワードの中身が変わった
  • 曜日や祝日、季節の影響
  • SNSやメール配信で一時的に人が来た
  • スマホとパソコンの比率が変わった
  • 新規の訪問者と再訪問者の割合が変わった
  • そもそもサンプル数が小さく、たまたまの揺れだった
  • 計測の設定を途中でいじった

これらのどれか、あるいは複数が重なって数字が動いた可能性を、前後比較だけでは切り分けられません。私たちが言えるのは「1か所だけ直した。そのあと数字が上がった」という事実までで、「だから直しのおかげだ」と言い切るのは飛躍です。

そこで、できる範囲で確からしさを上げる工夫をします。

  • 可能ならA/Bテストにする。同じ期間に、直した版と直す前の版を訪問者に振り分けて比べれば、外の要因の影響をそろえられます。因果に最も近づける方法です。
  • A/Bが難しければ、比較の条件をそろえる。前年の同じ時期や、直前の同じ長さの期間と比べる。流入チャネルやデバイスといったセグメントを固定して見る。曜日構成をそろえる。
  • サンプル数を確かめる。数十件しかない段の数%の上下は、ほとんど誤差の範囲です。判断できるだけの件数があるかを先に見ます。
  • 揺れの幅を意識する。1回の数字でなく、上下にどれくらいブレる指標なのかを見て、そのブレを超えた動きかどうかで判断します。
ムチオ
ムチオ
数字が上がったら仮説が当たり、じゃないんだ……。
ルミナ
ルミナ
そうなんです。数字が動いた理由は一つとは限らないので、上がった=直しのおかげ、とは言い切れないんです。だから「1か所だけ変える」で原因の候補を減らしつつ、できればA/Bで比べる。それでも確定でなく、確からしさが少し上がるだけ、という受け止め方が正直なところだと思います。

数字が動かない場面も、もちろんあります。直したのに到達率が変わらないことも、下がることもあります。そういうとき私たちは、直しを戻すか別の仮説に切り替えるかを、上の条件をそろえたうえで判断します。動かなかった事実も、記録として次の仮説の材料になります。

実例③:検索広告の検索語句から、除外キーワードを検討する

広告を出しているなら、検索語句レポートは見る価値があります。こちらが指定したキーワードだけでなく、実際にどんな言葉で検索した人がクリックしたか、が見られます。この中には、成果につながりにくそうに見える語も混ざっています。

私たちはこの検索語句をClaude Codeに読ませ、GA4 MCPのrun_conversions_reportなどとあわせて、費用やコンバージョンの内訳を整理してもらったうえで、除外の候補を検討しています。ただし、この運用は私たちのやり方の一例で、検証済みの最適解ではありません。むしろ、機械的にやると逆効果になりやすい落とし穴がいくつかあります。

まず、「ツール名だけ」「無料」といった語を、見込み客でないと決めつけないことです。情報収集の段階で調べていた人が、後日あらためて問い合わせにつながることもあります。検索語句という文字面だけで見込みの有無を推測するのは危うい。除外を判断するなら、その語のクリック数・費用・コンバージョン・検索の意図・マッチタイプまで見て、材料をそろえてからにします。件数が数クリックしかない語で結論を出さないほうがよく、ある程度の件数がたまるまで待ちます。

次に、除外キーワードは通常のキーワードと挙動が違う点に注意します。Googleの仕様では、除外キーワードは類義語や単数・複数といった表記ゆれには自動で広がりません。除外したい形は自分で挙げていく必要があります。一方でマッチタイプの選び方を誤ると、意図より広く止めてしまいます。検索語句レポートから除外を追加すると、初期設定が完全一致になっていることがあり、そのままだと狙った1語だけが止まる形になります。逆に除外の部分一致は、含めた語をすべて含む検索を止めるため、価値のある検索まで巻き込むことがあります。

そして、除外を増やしすぎないことです。Google自身、除外キーワードを増やしすぎると広告が届く範囲が狭まると注意しています。無駄なクリックを削るつもりが、見込み客への露出まで削ってしまっては本末転倒です。「毎日数語ずつ足すのがよい」と以前は考えていましたが、これも私たちの手ざわりであって、検証したわけではありません。頻度そのものより、一語ずつ材料をそろえて判断することのほうが大事だと、今は考えています。

ムチオ
ムチオ
じゃあ、これは見込み客じゃなさそう、ってAIが言ったらそのまま除外していいの?
ルミナ
ルミナ
そこは慎重にいきたいところです。AIが出すのはあくまで候補で、その語で来た人が本当に見込み客でないかは、費用やコンバージョンの数字と、件数がたまっているかを見ないと分かりません。数字の整理はAIに任せて、除外するかどうかの最終判断は人が持つ。この分担にしています。

つまずきポイント ── AIに丸投げしない・読み取り専用で使う

この回し方には、いくつか気をつける点があります。

  • スクリーンショットでなく数値で渡す。画面の画像を見せるより、Claude CodeがGA4のデータをMCP経由で直接読める状態にしておくほうが、読み違いが減ります。
  • 読み取り専用でつなぐ。GA4 MCPのツールは数字を「見る」ためのもので、設定を書き換えたりデータを消したりするものは含まれていません。認証も読み取り専用(readonly)の範囲に絞っておけば、想定外の操作を避けられます。
  • AIの読み取りを人が確認する。AIは数字を取り違えることも、仮説を強く言い切ることもあります。前述のとおり、GA4の数字自体が近似であることも忘れずに。最終的にどこを直すか、どの語を除外するかは、人が判断します。

安全な設定の詳細は前提記事Claude CodeとGA4をMCPでつなぐに、どこまでAIに任せてどこを人が握るかの線引きはAIに任せる範囲の線引きにまとめています。

なぜ「作る場所」で数字を見ると回しやすいのか ── 内製化という考え方

もう一つ、私たちがこの回し方を続けている理由があります。サイトを作っているその場所で、そのまま数字を見て直せる、という点です。

ふつうは、サイトを作る人、数字を見る人、直す人が分かれがちです。あいだで受け渡すたびに時間がかかり、認識のズレも生まれます。ところが、作る・測る・直すが一箇所で回ると、この受け渡しがなくなります。「ここで離脱している」という気づきから「ではこう直そう」までが、途切れずにつながる。AIが道具を使って自律的に動く仕組みの土台はAIエージェントとはで整理していますが、その道具の一つがGA4のMCPだと考えると分かりやすいと思います。

そして、この回し方が社内に根づくと、外に頼まなくても運用を回せる力が手元に残ります。レポートを受け取って眺めるだけの状態から、自分たちで数字を読んで手を動かせる状態へ。これは、AIやITを一度きりの導入で終わらせず、自社に運用力として残していく「内製化」という考え方につながります。数字の限界も含めて自分たちで扱えるようになることが、内製化の中身だと考えています。

次の一歩

改善は、いきなり大きく動かすものではありません。数字を読み、一点だけ仮説を立て、一箇所だけ直し、また測る。この小さな輪を、数字の限界を承知したうえで止めずに回し続ける。それが、私たちが今のところ手ごたえを感じているやり方です。回せば必ず数字が上がるとは言えませんし、上がっても因果を確定できるとは限りません。それでも、感覚だけで手を入れるより、次の一手を決める材料は増えると感じています。