アクセス解析は「見に行かない」— GA・Search Console 週次レポートを AI がチャットに届ける

カテゴリ
News

こんにちは!システムデザインワークスの山岸です。

前編では、弊社サイトの「ヘッドレスCMS × SSG × エッジ配信」という構成と、API 経由で記事投稿まで自動化できることを紹介しました。後編は、その「API で動かす」という発想を サイトの運用 に広げた実例です。Google Analytics(GA4)と Search Console のレポートを毎週自動で集計し、AI の要因分析を添えてチャットに届ける——「アクセス解析を見に行かない」運用のつくり方をお話しします。


APIで動かすサイト運用(前後編)

  1. 前編:脆弱性に強く、速いサイトのつくり方 — 脱WordPressという選択肢

  2. 後編:アクセス解析は「見に行かない」— GA・Search Console 週次レポートを AI がチャットに届ける(本記事)


背景・課題:「毎週アクセス解析を見る」は、続かない

Web サイトを持つ会社なら、一度は決めたことがあるはずです。「アクセス解析は週 1 回チェックしよう」。そして多くの場合、続きません。

  • GA4 と Search Console、それぞれ管理画面を開いて回るのが手間

  • 数字は並んでいても、「次に何をすればいいか」までは教えてくれない

  • 見る人が固定化し、その人が忙しいと誰も見なくなる(属人化)

弊社も例外ではありませんでした。正直に言うと、以前はアクセス解析を定期的に分析する習慣がそもそもありませんでした。さらに、この仕組みを作る過程で、問い合わせなどの イベント数が正しく計測できていなかった ことも分かりました。アクセス解析は「見る仕組み」と「正しく測る設定」の両方が揃って、はじめて役に立ちます。

そこで発想を変えました。人がデータを見に行くのではなく、見るべき変化のほうから人に届くようにする。 しかも「先週こうだったから、こうしよう」という示唆付きで。

取り組みの概要:毎週月曜の朝、AI の分析コメント付きでチャットに届く

いまの弊社の運用はこうです。毎週月曜の朝 9 時、Google Chat に前週分の週次レポートが自動投稿されます。人の作業はゼロ。届いたレポートを眺めて、気になった点をそのままチャットで話し合うだけです。

図を読み込み中…

レポートには、次の内容が 1 枚にまとまっています。

項目

内容

今週の KPI

問い合わせ数(CV)・CVR・セッション・ユーザー数・エンゲージメントを前週比付きで

擬似ファネル

問い合わせページ閲覧 → 問い合わせ完了の遷移率

直近 4 週トレンド

セッションと CV の推移(移動平均付き)

チャネル別・ページ別

検索・直接・参照の内訳と、ランディングページごとの成果

検索キーワード

Search Console のクリック・表示回数・掲載順位 Top

表示速度(CrUX)

実際の訪問者環境で計測された Core Web Vitals の定点観測

AI 分析

上記データを踏まえた「要因推察」と「改善アクション」の提案

ポイントは最後の AI 分析 です。数値の羅列で終わらせず、Gemini が「今週アクセスが減ったのはなぜか」「来週なにをすべきか」まで文章で添えてくれます。数字の分析が専門でないメンバーにとっても、レポートが「会話のきっかけ」として機能するようになりました。

実装・検証の要点

構成:サーバーレスの定期実行に全部乗せる

実行基盤は前編と同じ Cloudflare Workers です。Cron Triggers(定期実行)で週 1 回起動し、GA4 Data API・Search Console API・CrUX API から集計、Gemini で分析文を生成して、Google Chat の Webhook にカード形式で投稿します。専用サーバーは不要で、AI 分析に使っている Gemini も API の無料枠の範囲で運用できているため、この仕組みの追加ランニングコストは実質ゼロ です。設定はこれだけです。

1// wrangler.jsonc — 毎週月曜 00:00 UTC(= 09:00 JST)に発火
2{
3 "triggers": {
4 "crons": ["0 0 * * MON"]
5 }
6}

地味なハマりどころとして、Cloudflare の cron は 曜日の数字の解釈が標準 cron と違います(1 = 日曜。標準 cron では 1 = 月曜)。数字で書くと事故のもとなので、MON のような 3 文字表記をおすすめします。

つまずき①:問い合わせ(CV)が数えられていなかった

作ってみて最初に気づいたのが、問い合わせのイベント数がそもそも拾えていなかったことです。サイト側は問い合わせ完了時に generate_lead というイベントを送っていた一方、集計する側が見ていたのは別のイベント名。さらに GA4 側でも、対象イベントを「キーイベント」として登録していないと集計に乗りません。送る・登録する・数える、の 3 つが揃っていなかったのです。

アクセス解析の自動化では、集計ロジックの前に 「そもそも正しいイベントが飛んでいて、正しく数えられる設定になっているか」 の確認が欠かせません。ここを飛ばすと、見た目は立派な「間違ったレポート」が毎週届き続けることになります。

つまずき②:AI 呼び出しは「失敗する前提」で組む

Gemini のような外部 AI の API は、ごくたまに一時的なエラーを返します。週 1 回しか動かない仕組みでそれが起きると、その週のレポートがまるごと欠けてしまう。そこで一時エラーは自動リトライし、それでも AI 分析が得られなければ 分析なしでも数値レポートだけは必ず届く ように組んでいます。また、チャットに投稿せず内容だけ確認できるドライランも用意し、集計ロジックの変更を安全に試せるようにしました。

自動化は「動いたら終わり」ではなく、一部が壊れても全体は止まらない 設計にしておくと、安心して任せられます。

結果:分析の習慣ゼロから、毎週数字の話をするように

この仕組みにしてから、アクセス解析との付き合い方が変わりました。以前は誰も定期的に見ていなかった数字が、いまは毎週月曜の朝にチャットへ届き、「このキーワードで来てるんだ」「先週の記事、読まれてるね」と会話が生まれる。管理画面を開きに行く手間なしに、数字を見て話す習慣ができた のが、いちばんの成果だと感じています。

また、レポートの土台は複数サイトに横展開できる設計にしてあるので、お客様のサイトに同じ仕組みを載せることもできます。

まとめ

  • 「毎週アクセス解析を見る」運用は続かない。見るべき変化のほうから届く 形に変える

  • GA4・Search Console・表示速度の実測を週 1 で自動集計し、AI の要因分析を添えてチャットへ

  • イベント計測の食い違い・cron の曜日解釈・AI の一時エラーなど、つまずき所は「壊れても止まらない」設計でカバー

前編の「脆弱性に強く、速いサイト」と、後編の「見に行かないアクセス解析」。どちらも根っこは同じで、API で動かせるサイトは、守るのも運用するのも軽くなる ということです。

ご相談お待ちしております。

栃木県でアプリ開発・システム開発の会社をお探しの方、Web サイトや業務システムを長く安心して任せられるパートナー企業を探している方へ。 今回ご紹介したようなアクセス解析の自動レポート化はもちろん、日々の業務を楽にする自動化、業務システム・アプリ開発まで、システムデザインワークスが一貫して対応します。

「うちの GA、ちゃんと計測できてるのかな?」といった軽い疑問からで構いません。弊社は自社で実際に運用し、効果と落とし穴を把握したうえでご提案するスタイルです。お気軽にお問い合わせフォームよりご連絡ください。