GAログって見にくい…そのままじゃ使えない...! そんな状態から、自動で見やすく整形して、グラフでわかりやすく可視化するところまでを一気通貫で構築してみました。BigQuery、Dataform、Cloud Scheduler、Looker Studio を組み合わせて、「取ってきたログを毎日自動で見える化する」データパイプラインをGCP上で作ってみたので、その流れや注意点をまとめていきます！1. GAログをDataformで整形するGAログの整形に入る前に、まずやったのがローカルでGAイベントを送るためのテストページをつくることでした。「GAのタグを入れたHTMLをただ開いただけでは、イベントがうまく送られないことがある」これは割と陥りやすい落とし穴です。なので今回は、Pythonを使って仮のローカルサーバーを立てて動作確認をしました。〇ローカルサーバーの立ち上げ手順やったことは以下の3ステップだけです：ターミナル（PowerShell）を開くcd Downloads でファイルのあるディレクトリへ移動python -m http.server で起動Pythonの標準機能でサーバーを立てると、すぐに http://localhost:8000 でアクセスできるようになります。ブラウザで以下のURLを開くと、自分が用意した html が表示されますブラウザでアクセスしたときの画面ページにアクセスすると、GAタグが動作し、イベントがGoogle Analytics側に送られるようになります。反映には最長で48時間ほどかかることもあるので、イベント送信後は少し待つ必要があります。〇イベントが送信されたかをGA上で確認ページにアクセス後、GA4の「Realtime」画面を開くと、自分のアクセスがリアルタイムで反映されていることが確認できました。リアルタイムオーバービュー画面また、[Realtime pages] タブを見ると、実際に html へのアクセスが1件記録されていました。この時点で「GAのタグは正しく動作していて、イベントが送られている」と判断できます。〇GA → BigQuery連携がONになっているか確認GAのイベントデータは、BigQueryとの連携設定ができていないとログとして出力されません。 そのため、管理画面の「BigQueryリンク設定」が有効になっているかを必ずチェックします。BigQuery連携設定の画面この設定が有効になっていれば、翌日以降にBigQueryの該当プロジェクト内に events_YYYYMMDD テーブルが作成されて、データが反映されていきます。データの流れを確認できたところで、次にこのテーブルをもとにして、Dataformを使った整形・加工を進めていきます。〇GAイベントがBigQueryに反映されたことを確認GA4の設定とローカルでのテストページ公開からしばらく経つと、BigQuery上に events_YYYYMMDD 形式のテーブルが出現します。今回も、events_20250519 というテーブルが自動生成されており、GAのログが格納されていることが確認できました。2.DataformでSQLXモデルを作成して、イベントログを整形するBigQueryに格納されたテーブルは、GA4から送られてきた生ログの集合体です。このままでは構造が複雑で扱いづらいため、Dataformを使って分析や可視化に使いやすいテーブルへ整形していきました。使用したツール：Dataform（Webコンソール）Dataformでは、GUIベースでSQLXという形式のファイルを作成・管理できます。SQLXとは、SQLと設定（config）を組み合わせたDataform独自の記述フォーマットで、BigQueryに対する変換・作成処理を自動化できます。・作成したSQLXファイルの内容以下は、実際に page_view イベントだけを抽出して整形したSQLXの中身です。Gitブランチの名前は分かりやすく、（ga_transform）という名前にしました。DataformのSQLX編集画面右上の ▶ 実行ボタンを押せば、BigQueryにテーブルが作成されます。〇抽出しているフィールドの意味user_pseudo_id: 匿名のユーザーID（GAが自動付与）event_name: GAイベント名（今回は page_view のみ抽出）event_timestamp: イベントのUNIXマイクロ秒（→変換して event_datetime に）geo.country: 国名（GAが自動で付加）device.category: 使用デバイス（mobile, desktopなど）〇実行後のBigQuery側の状態SQLXを手動で実行したところ、無事 page_views_summary という名前のテーブルが作成されました。実行後のBigQueryテーブルスキーマ画面 テーブルには、整形済みのカラムが正しく並んでいて、想定通りの出力になっていることが確認できました。3. Cloud SchedulerからWorkflows経由で Dataformを定期実行する整形処理のSQLXモデルをDataformで手動実行するところまでは完了しました。ここから先は、「これを毎日自動で回せるようにしたい」という運用フェーズに入ります。最終的には、Cloud Scheduler → Workflows → Dataform の構成にすることで、安定した自動実行環境を構築できました。〇Cloud Schedulerで毎日7:30に実行まずはCloud Schedulerを使って、「毎日午前7時30分」に処理をトリガーするジョブを作成しました。Cloud Schedulerのスケジュール設定頻度：30 7 * * *（cron形式）タイムゾーン：日本標準時（JST）リージョン：us-central1（Workflowsと合わせた）〇Workflowsを経由させてAPIを安定実行当初は「Cloud Scheduler → Dataform API」の構成で進めようとしましたが、以下のような問題に直面しました。認証エラー（403）リージョン不一致による実行失敗（404）Dataform APIのURL形式が難解で扱いづらいそのため途中から、Cloud Workflowsを中継として挟む構成に切り替えました。Workflowsトリガー情報（タイムゾーン・リージョン）Workflows 実行用URLの型： https://workflowexecutions.googleapis.com/v1/projects/◯◯/locations/◯◯/workflows/◯◯/executions認証はOAuthトークン、サービスアカウントを指定スコープは https://www.googleapis.com/auth/cloud-platform〇Workflows内の処理内容Workflowsの中では、以下の2ステップが順番に実行されます。コンパイル：指定のGitブランチ（ga_transform）でSQLXコードを解釈ワークフロー実行：そのコンパイル結果をもとに、実際のテーブル変換処理を開始Workflowsのコードと可視化フロー〇詰まったポイントとその対応◎リージョン不一致によるエラー GA、BigQuery、Dataform、Workflows、Cloud Scheduler のリージョン設定がそれぞれバラバラになっていたことで、API呼び出し時にエラーが発生してしまいました。特に Workflows と Scheduler は初期設定で asia-northeast1（東京）と us-central1（アイオワ）に分かれていたため、整合性が取れず実行が失敗していました。→ すべてのサービスを us-central1 に統一することで正常に動作しました。◎Dataform の GitHub 連携が必須だった Dataform では、SQLXモデルを本番環境で運用するには「リリース構成」に Git のブランチ（ga_transform など）を指定する必要があります。ただし、このブランチ指定は GitHub と連携していないと選択できず、最初はリリース構成を保存できないという状態でつまずいてしまいました。→ 事前に GitHub リポジトリと Dataform を連携させておくことで、スムーズに構築が進みました。◎認証スコープの不足で 403 エラー Cloud Scheduler から Workflows を呼び出す際に、OAuth の認証スコープを cloudfunctions のままにしていたことで、Dataform API から 403 Forbidden が返ってきてしまいました。→ 認証スコープを https://www.googleapis.com/auth/cloud-platform に修正したことで、問題なく認証が通るようになりました。〇結果：毎日安定して実行されるように！この構成によって、毎朝7:30にSchedulerがWorkflowsをトリガーし、DataformのSQLXが自動で実行される状態が完成しました。BigQueryには整形済みテーブルが日々更新され、可視化の土台が自動で保たれる仕組みです。4.CloudMonitoringを使ってジョブエラーをGmail通知するCloud Scheduler を使って定期的に Dataform のワークフローを実行する仕組みを構築したものの、処理に失敗しており、これに気づけないのは大きな問題です。特に、URLの誤記や認証スコープのミス、Dataform 側の API 呼び出しエラーなどは、目に見えず分かりにくいです。そこで、Cloud Monitoring を用いたアラート通知の仕組みを導入し、Cloud Scheduler ジョブの HTTP 実行エラー（401〜404）を検知 → Gmail に自動通知というフローを実現しました。実装ステップ〇ステップ1：ログベースの指標を作成Cloud SchedulerのログはCloud Loggingに蓄積されているため、これをベースに指標を抽出します。今回は logging/user/scheduler_error_not_found_count というログベースメトリクスを作成し、活用しました。これは、Cloud Scheduler のジョブがリソース（エンドポイント）に到達できなかった回数をカウントしてくれる指標です。ログベースメトリクスの選択画面〇ステップ2：アラート条件を構成ログから抽出したエラーカウントが 1回でも発生したら即通知されるように、しきい値を「0」としてアラート条件を設定します。〇ステップ3：通知チャネルとして Gmail を登録次に通知の送り先として、Gmail アドレスを通知チャネルに追加します。この設定により、エラー発生後数分でメールが届きます。Gmailに届いたエラーメール〇テスト検証アラート設定後、以下のように 意図的に失敗させて動作検証 を行いました。ワークフローのURLをわざと存在しないものに変更 → 404 エラー発生サービスアカウントの認証スコープを複数外す → 403 エラー発生→ どちらのケースでも、Cloud Scheduler のジョブ失敗ログに応じて scheduler_error_not_found_count がカウントされ、Gmailへ通知が飛びました。アラートがトリガーされたログ詳細〇成果と利点このアラート設定によって、Cloud Schedulerのエラーにすぐ気づける仕組みができました。Gmailに通知が届くようにしたことで、Slackやモニタリング画面を見ていないときでもエラーを確認できるようになり、とても安心です。実際に403や404のエラーが出たときも、すぐにメールで気づけるので、対応のスピードが早くなります。認証の設定ミスなどもすぐに直せるようになりました。5. Looker Studioでダッシュボード化整形済みのGAログデータはBigQuery上に保存されているため、Looker Studioと直接連携するだけで、すぐにダッシュボードとして可視化できます。今回は以下のようなグラフや地図を組み込み、視覚的に理解しやすいレポートを作成しました：ページ閲覧数とユーザー数の比較（棒グラフ）日別のページビュー数推移（折れ線グラフ）国別アクセスの分布（地図）デバイスカテゴリ別の割合（円グラフ）BigQueryにたまったデータをLooker Studioで可視化することで、誰でも直感的にデータを見られるようになりました。グラフや地図で表示されることで、ページビューの傾向やユーザーの行動がすぐにわかり、日々の変化にも気づきやすくなります。また、ダッシュボードはURLで簡単に共有できるので、情報をすぐ共有できます。更新も自動なので、集計やレポート作成の手間も大きく削減できると思います。６. まとめGAのイベントログを整形し、BigQueryに蓄積・可視化する今回の仕組みは、「自動化 × データ活用」を実現するうえで非常に効果的でした。SQLやGitなど多少の知識は必要でしたが、Dataformを使うことで変換処理の管理がしやすくなり、Workflows・Cloud Schedulerと組み合わせることで定期実行の自動化も実現できました。さらに、Cloud Monitoringによるエラー検知やLooker Studioでの可視化により、業務運用の安定性と情報共有のしやすさも大きく向上しました。技術的な構成はやや複雑に見えますが、構築さえ済ませてしまえば、あとは「放っておける」仕組みになります。ダッシュボードを通じて、データの動きを定期的に確認できるようになったのも大きな成果です。データを整えて自動で活用する。 それは、ほんの少しの設定と工夫で、誰にでもできるようになります。「BigQueryにデータはあるけど活かせていない」「分析レポートを毎回手動で集計している」そんな悩みがある方こそ、一度この流れを体験してみてください。きっと、日々の仕事に小さな余裕が生まれるはずです。