GA4の月次レポートを自動化するには、まず「毎月、何を判断するための報告か」を決めます。そのうえで、APIによる取得、決めた式での集計、AIによる要約、人による確認をつなぎます。
最初の対象は、毎回同じ手順でつくっている表ひとつで十分です。この記事では、自然検索からの集客と問い合わせを振り返る月次レポートを想定し、項目の設計から取得失敗への対応、公開前の確認までを整理します。設計例であり、実際の顧客データや成果を示すものではありません。
- 取得APIで条件を指定
- 集計同じ式で比較
- 要約AIが確認点を整理
- 判断人が施策を決定
レポートの目的と指標を決める。
「アクセスを報告する」だけでは、指標が増え続けます。「自然検索で訪問されるページのうち、今月どこを改善するか」のように、会議で決めることを一文にします。必要な切り口は、その判断から逆算します。
| 確認したいこと | 取得元・項目 | そろえる条件 |
|---|---|---|
| どの入口が使われたか | GA4:ランディングページ、セッション | 対象プロパティ、前月、セッションの参照元/メディア |
| 問い合わせにつながったか | GA4:設定した問い合わせのキーイベント | イベント名、計測開始日、カウント方法、確認担当 |
| 検索結果でどう見られたか | Search Console:ページ別の表示回数・クリック数 | 対象プロパティ、期間、検索タイプ、国・デバイスの絞り込み |
| 何を変更したか | 運用記録:改修日、販促、在庫や計測の変更 | 対象URL、変更内容、担当者、確認日 |
自然検索をGoogleに絞る場合は、GA4側でもセッションの参照元/メディアを google / organic に合わせます。売上も扱うなら、GA4で計測した購入収益と、受注管理上の売上のどちらを使うか明記します。キャンセルや税、送料などの扱いが異なる数字を、同じ売上として混ぜないためです。
月ごとの日数や販促条件も記録します。増減率の計算では、比較元がゼロの場合を別扱いにし、欠損はゼロに変換しません。数値の定義と計算式を先に決めることで、毎回の解釈がぶれにくくなります。
API・集計・AI・人の役割を分ける。
1. APIで、同じ条件のデータを取得する。
GA4のData APIでは、runReport に対象プロパティ、期間、ディメンション、指標、フィルタなどを指定してレポートを取得できます。たとえば、期間を前月の開始日・終了日、切り口をランディングページ、指標をセッション数とする設計です。利用権限と、組み合わせ可能な項目を確認して実装します。
取得条件、実行時刻、結果の件数を記録します。データが複数ページに分かれる場合は全体を取得できたか確認し、APIの利用上限も考慮します。最初はCSVで同じ表をつくり、必要な項目が固まってからAPIへ置き換える進め方でも構いません。
2. 合計や増減は、決めた計算処理でつくる。
取得した数値から、合計、前期間との差、比較表を計算します。元データ、集計後の表、要約文を分けて残せば、誤りがあったときにどこまで戻るか分かります。AIの文章生成に、数値の集計そのものを任せない構成にします。
3. AIには、確認済みの表を渡す。
要約を依頼するときの指示例
以下は確認済みの月次集計です。数値を作り足さず、次の形式で整理してください。 1. 観測できた変化:対象ページと表の行番号を添える 2. 理由の仮説:断定せず、根拠と不足している情報を書く 3. 次に確認すること:画面、計測、運用記録を分ける 欠損や比較条件の違いがあれば、要約の冒頭に示してください。
入力は必要な集計結果に絞り、個人の問い合わせ本文などを混ぜないようにします。出力された数値とページ名は、必ず元の表と照合します。
4. 人が、現場の事情を加えて判断する。
アクセス増加と記事公開が同じ時期でも、記事が原因とは限りません。広告、季節、在庫、計測設定の変更も確認します。AIの仮説から調べる順番を決め、実施する改修と担当者は人が判断します。
失敗を検知し、不完全な報告を止める。
自動化では、正常に動いたときと同じくらい、止まったときの設計が大切です。取得失敗をゼロとして扱うと、実際には起きていない売上やアクセスの急減を報告してしまいます。
- 権限の失効・認証エラー
- 処理を止め、接続先と権限を担当者が確認します。認証情報をログやレポート本文に含めないようにします。
- 利用上限・一時的な通信障害
- 上限のある再試行を設け、解消しない場合は通知します。失敗した集計のまま要約や配信へ進めません。
- 取得件数の不足・必要項目の欠損
- 件数、必要な列、取得済みの期間を確認します。前回との差が大きいときは、実際の変化か取得不備かを調べます。
- 期間・タイムゾーン・反映時点の違い
- 各サービスの日付の扱いとデータ更新状況を確認します。再取得した場合は更新時刻を残し、どの時点の数字か明示します。
レポートには「対象期間」「取得時刻」「取得状況」を表示します。前回値を代わりに見せる場合も、その対象期間が分かるようにします。必要なデータが揃わないときは配信を止め、担当者が確認できる状態で保存します。
手作業と照合し、次の行動につなぐ。

導入時は、対象期間、フィルタ、指標の定義をそろえ、既存の手作業の表と照合します。GA4の管理画面とAPIに差があれば、まず条件とデータの扱いを確認します。合わない数字を係数で無理に合わせず、説明できる状態にしてから定例運用へ移します。
月次レポートの末尾に残す項目
わかったこと:どのページで、何が変わったか まだ確かめたいこと:理由の仮説と、追加で見る情報 次に行うこと:対象URLと、変更する内容 担当・確認日:誰が実施し、いつ振り返るか 判断の条件:販促、在庫、計測変更などの注意点
最初の試運転では、正常な取得だけでなく、権限エラーや空の結果でも配信が止まるか確認します。毎月の収集が安定してから、対象レポートを増やします。
改善候補の選び方は、Search ConsoleとGA4を使ったサイト改善へ。商品ページから先の動きを調べる場合は、購入までの導線の見直しへ。レポートの完成後に、実際のページを直す時間を確保することまで含めて設計します。
レポートを会議で確認した後は、決めた改善を担当者へ引き継ぎます。AI議事録から担当・期限・タスクを整理する方法では、数字を見て終わらず、次の仕事へつなぐ手順を紹介しています。
参考資料
- Google Analytics Data API:レポートの作成
- Google Analytics Data API:ディメンションと指標
- Google Analytics Data API:利用上限
APIの仕様は2026年10月22日に確認しました。利用できるデータは、設定と権限に応じて異なります。



