Google広告、Meta広告、Yahoo!広告、GA4、Search Consoleの数字を1つの画面にまとめたマーケティングダッシュボードは、AIエージェントを使えば自作できます。各媒体のAPIと連携する処理も、BigQueryで集計するクエリも、書かせれば短時間で動きます。専用のSaaSを契約しなくても、毎朝勝手に最新の数字へ更新される状態まで作れます。
難所はコードではなく、データの意味を判断する部分です。そのユーザー数は足してよいのか、その日付は何時間ずれているのか、この合計が一致しないのは仕様なのかバグなのか。ここを誤ると、動いているのに数字が間違っているダッシュボードができます。
日本AI導入支援協会のマーケティングエンジニアが、5媒体を1つのダッシュボードに集約し、毎朝自動で更新される状態まで実装しました。その構成をもとに、作り方を4つの手順に分けて解説します。各手順の最後には、実装担当者のコメントとして、実際に踏んだミスとその対策を付けます。
運営者情報
AI JOURNALは一般社団法人 日本AI導入支援協会が運営する、日本企業のAI活用支援を目的としたメディアです。記事制作にあたっては、経済産業省「AI事業者ガイドライン」をはじめとする公的機関の公表情報等を参考にしています。内容の正確性には十分配慮していますが、誤りや更新漏れがある場合は、お問い合わせフォームよりご連絡ください。掲載情報は公開日時点のものであるため、最新情報は公式サイト等でご確認ください。
マーケティングダッシュボードの作り方は4つの手順に分かれる
自作の構成は、データの流れに沿って4つの層になります。各媒体のAPIと連携してデータを取得する層、BigQueryにためて整形する層、Googleスプレッドシートへ出力する層、そしてダッシュボードとして表示する層です。作る順番もこのとおりで、下の層から順に固めていきます。層ごとに責任範囲を分けておくと、どこかが壊れたときに切り分けができます。
段数が多く見えますが、それぞれに理由があります。取得と保管を分けるのは、加工を間違えても取り直さずにやり直せるようにするためです。保管と表示のあいだにスプレッドシートを挟むのは、表示側の実装方式に制約があるためです。この2点は手順2と手順3で扱います。
AIが関わるのは3カ所です。各媒体との連携処理やBigQueryのビューを書かせる実装の部分、毎朝データを取り直してダッシュボードを更新させる運用の部分、そして数値の変化に対する考察の初稿を書かせる部分です。このうち実装と運用をこの記事で扱い、考察の生成は広告レポートをAIで自動化する方法で詳しく扱っています。
この記事の前提になる実装環境
以降の手順とコメントは、次の構成を前提にしています。データ元はGoogle広告、Meta広告、Yahoo!広告（検索広告とディスプレイ広告）、GA4のBigQueryエクスポート、Search ConsoleのBigQuery一括エクスポートの5媒体です。取得したデータはBigQueryへ蓄積し、集計はすべてビューで行っています。ビューの結果はConnected Sheetsの抽出機能でGoogleスプレッドシートへ展開し、表示はClaudeのアーティファクトとして公開した単一のHTMLファイルです。取得処理の実行環境は、当初がWindowsのタスクスケジューラ、移行後がCloud Run JobsとCloud Schedulerの組み合わせです。開発環境はWindowsで、シェルはGit BashとPowerShellの両方を使っています。
環境が違えば当たらない症状もあります。逆に、同じ構成を取るなら同じ順序でほぼ同じ箇所に当たります。
Looker Studioだけで足りるケースと足りないケース
単一媒体の可視化なら、Looker Studioで足ります。Google広告もGA4もSearch Consoleも公式コネクタがあり、つなぐだけでレポートになります。無料で使えるので、まずここから試すのが順当です。
足りなくなるのは、複数媒体を横断して見ようとした瞬間です。Looker Studioは可視化のツールであって、データ統合のツールではありません。媒体ごとに別のデータソースを貼り付けたレポートは作れますが、媒体をまたいだ合計や共通の指標を出そうとすると、結局どこかでデータを1カ所に集める作業が必要になります。つまりBigQueryのような集約先は、Looker Studioを使う場合でも遅かれ早かれ必要になります。そして集約先まで作ってしまえば、見せ方はLooker Studioでも自作のダッシュボードでも自由に選べます。Looker Studio自体の構築を外部に任せる場合の考え方は、Looker Studioの構築代行とは？AIでのレポート自動化との使い分けで整理しています。
手順1、広告媒体・GA4・Search Consoleと連携して日次データを取得する
最初の手順は、5媒体からデータを毎日取り込むところまでです。
取得の方式は媒体によって2通りに分かれます。Google広告、Meta広告、Yahoo!広告は各社のAPIを直接呼び、レポートを日次で取得します。GA4とSearch Consoleは、APIを書くよりも公式のBigQueryエクスポートを使うほうが早く、精度も高くなります。GA4は管理画面のBigQueryリンクでイベント単位の生データが日次で入り、Search Consoleは一括データエクスポートの設定でサイト単位とURL単位のテーブルが毎日追記されます。この2つは設定を入れた日以降のデータしか入らないため、構想の段階で先に有効化しておくと、後から検証に使える期間が伸びます。
取得処理は日付を引数に取り、同じ日を何度実行しても同じ結果になる形で書きます。取り込み先は日付でパーティションを切ったテーブルにし、対象日のパーティションだけを入れ替える方式にすると、失敗した日をあとから単独で流し直せます。認証情報はコードに書かず、シークレットとして実行環境に持たせます。
実行環境は、検証のあいだは手元のPCで構いません。継続して毎朝更新するなら、Cloud Run JobsのようなマネージドなジョブとCloud Schedulerの組み合わせに寄せます。このコード自体は、各媒体のAPIドキュメントを渡せばAIエージェントがほぼ書き切れる範囲です。
手順1でミスしやすいポイントと対策
Meta広告APIはアカウントIDを間違えてもエラーにならず空の配列が返る
Meta広告は、広告アカウントIDの指定を誤るとエラーではなく空の配列を返すことがあります。処理としては正常終了するので、ログを見ても失敗に見えません。エラーが出ていないから成功しているとみなす作りにすると、0行を取り込み続けたまま数週間が過ぎます。
対策は、取得件数のチェックを取り込み処理そのものに組み込むことです。想定される最低件数を下回ったら異常として扱い、後続の処理を止めます。APIがエラーを返さない以上、異常の定義はこちら側で持ちます。Google広告やYahoo!広告でも、取得が中途半端に失敗したときは0行ではなく一部だけ取れた状態になるため、件数のチェックは全媒体に入れます。
Yahoo!広告は検索広告とディスプレイ広告でAPIが分かれている
Yahoo!広告は検索広告とディスプレイ広告でリファレンスもバージョン体系も別々に進みます。仕様変更の追従も2媒体ぶん必要になるので、運用の手間を見積もるときもこの前提で数えています。
Yahoo!広告のAPIは、検索広告とディスプレイ広告で別建てです。リファレンスも検索広告APIとディスプレイ広告APIに分かれており、バージョン体系も別々に進みます。認証もエンドポイントも別に扱う必要があります。
対策というより設計判断ですが、Yahoo!広告は実質2媒体として扱い、取得処理もテーブルも最初から分けて用意します。1媒体として設計してから分けると、テーブルの作り直しになります。
Yahoo!広告のリフレッシュトークンは新旧を並行稼働させると片方が無効になる
実行環境を手元のPCからクラウドへ移すとき、移行期間は両方動かして様子を見ようとしました。Yahoo!広告ではこれが構造的に不可能でした。リフレッシュトークンが、使うたびに新しい文字列が発行されて古い文字列が無効になる方式だったからです。気づかないまま移行日を迎えていたら、新旧の両方が止まっていた可能性があります。
2カ所から同じトークンを使うと、片方が更新した瞬間にもう片方の手元のトークンが失効します。対策は、トークンをローテーションする方式の媒体については、切り替えを一度で行う前提で計画を立てることです。並行稼働で安全側に倒すという発想がそのまま逆効果になる箇所なので、移行計画を書く前に媒体ごとのトークン方式を確認します。
Git Bashからgcloudを実行すると引数がスペースで壊れる
サービスアカウントを作るときに、空白入りの表示名を渡したところ意味の分からないエラーが出ました。gcloudの設定や権限を疑って調べていて、原因にたどり着くまで時間を溶かしました。
gcloud iam service-accounts create ads-daily --display-name="Ads daily pipeline runner"
'Ads' は内部コマンドまたは外部コマンドとして認識されていません。Windows環境でGit Bashからgcloudコマンドを実行すると、gcloudのインストールパスと引数の両方にスペースが含まれている場合に、引数の解釈が壊れることがあります。表示名の一部が別のコマンドとして扱われている状態です。対策は、同じコマンドをPowerShellから実行することです。それで通ります。
Windowsのタスクスケジューラで動かすと実行されない日が出る
検証のあいだは自分のPCのタスクスケジューラで回していました。スリープ中や持ち出し中は動かないので、毎朝更新する運用にするならクラウド側へ移す前提で考えていました。
最初の検証はWindowsのタスクスケジューラで十分に動きます。ただしこの方式は、PCがスリープしていれば動かず、持ち出していれば動かず、電源が入っていない日は静かに実行されないままになります。毎朝更新されている前提のダッシュボードでは、そこが弱点になります。
対策は、本番運用をCloud Run JobsとCloud Schedulerの組み合わせに寄せることです。毎朝決まった時刻に起動し、手元のPCの状態に依存しません。移行の際は、前述のトークンの制約があるため一度で切り替えます。
手順2、BigQueryにためてビューで集計する
2つ目の手順は、取り込んだデータを集計して、レポートに出す形の表を作るところまでです。表示側は後からいくらでも作り直せますが、集計の設計を誤ると出てくる数字そのものが狂います。最も検証に時間をかける層です。
設計の原則は2つあります。1つは、APIから取得したデータはそのままの形で保管し、加工をかけないことです。集計や変換はすべてビューで行います。加工ロジックを間違えたとき、生データが残っていれば何度でも作り直せます。生データを加工して上書きすると、APIから取り直すことになり、媒体側に取得可能期間の制限がある場合は取り直すことすらできません。ビューはCREATE OR REPLACE VIEWで冪等に書いておくと、デプロイ用のスクリプトを何度実行しても同じ状態になります。
もう1つは、ビュー層を広告、GA、Search Consoleの3軸に分けることです。それぞれに入口となるビューを1本置き、その裏に詳細ビューをぶら下げます。統合ダッシュボードという言葉から、データを1本のテーブルに統合する設計を思い浮かべがちですが、この3つは結合できません。粒度も更新タイミングも設計思想も異なるためです。広告は日次かつ媒体かつキャンペーンかつ広告グループの単位、GAはセッションやイベントの単位、Search Consoleは日次かつクエリの単位で、共通する結合キーは日付だけです。日付だけで結合すれば行数が掛け算で膨らむだけで、意味のないテーブルができます。統合するのは見せる場所であって、データそのものではありません。初めて構築する人がいちばん取り違えやすい箇所で、ここを誤ったまま進めると後戻りが大きくなります。
ビューを作ったら、SELECTした結果を手計算や管理画面の数字と突き合わせます。この照合をしないまま次の層へ進むと、表示の不具合と集計の不具合が混ざって切り分けができなくなります。
集計でミスしやすいポイントと対策
0行の日にパーティションが更新されず前日のデータが残る
対象日のパーティションを入れ替える方式では、その日のデータが0行だと書き込む行がないため、パーティションの中身が入れ替わりません。広告を止めた日に前日の配信実績が出続けることになり、数字がゼロにならないぶん異常としても検知されません。
数字がゼロにならないため、異常としても検知されません。対策は、0行の日に対象パーティションを明示的に空にする処理を別で用意することです。書き込みの副作用に任せず、削除を独立した操作として持ちます。
ユニークユーザー数を日次の合計で出すと多く出る
週次のユーザー数を日次の合計で出しているレポートは実務でよく見かけます。月曜に訪問した人が水曜にも訪問すれば日次では2回数えられるため、合計すると実際より多く出ます。
週次のユーザー数を、日次のユーザー数の合計で求めると、実際より多い数字になります。月曜に訪問した人が水曜にも訪問すれば、日次では2回数えられるためです。
セッション数や新規ユーザー数（初回訪問イベントの数）は加算できる指標なので合計して構いません。重複排除を伴う指標だけは、週の値を週の単位で、生のイベントデータから数えなおす必要があります。集計済みのテーブルから足し直せる指標かどうかを、ビューを作る前に指標ごとに決めておくと事故が減ります。
チャネル別のユーザー数を足してもサイト全体の数字にならない
チャネル別の合計とサイト全体の数字は一致しません。同じ人が複数のチャネルから訪れるためで、一致しないほうが正しい状態です。受け取る側からは指摘されやすいので、集計の持ち方を先に決めておきます。
同じ問題はチャネル別の合計でも起きます。OrganicとDirectとReferralのユーザー数を足しても、サイト全体のユーザー数にはなりません。同じ人が複数のチャネルから訪れるためです。
対策は、チャネル別の集計とサイト全体の集計をそれぞれ独立に生データから計算し、UNION ALLで縦に積むことです。サイト全体の行には、チャネル名の列にセンチネル値を入れておきます。
-- チャネル別の行
SELECT week_start, channel_group, COUNT(DISTINCT user_pseudo_id) AS users
FROM base GROUP BY week_start, channel_group
UNION ALL
-- サイト全体の行（チャネル名にセンチネル値を入れる）
SELECT week_start, "(all)", COUNT(DISTINCT user_pseudo_id)
FROM base GROUP BY week_startこうすると1つのビューの中に、チャネル別の明細と全体の合計が共存します。表示側はセンチネル値の行を全体値として読み、それ以外を明細として読みます。
検証では、全体値とチャネル別の合計を並べて差分を確認します。重複した分だけチャネル別の合計のほうが大きくなるため、差分が0以上であれば重複排除が効いています。4週分の確認では差分が0、2、1、0でした。
CTRやCPAを日次の平均で出すと実態からずれる
比率の指標を日次の平均で出しているレポートもよく見かけます。表示回数が数十件しかない日と数千件の日が同じ重みで効くため、期間の合計から計算しなおします。
CTRやCPC、CPAといった比率の指標は、日次の値の平均ではなく、期間の合計から計算します。CTRであれば、期間のクリック数合計を期間の表示回数合計で割ります。日次の平均を取ると、表示回数が極端に少ない日も同じ重みで効いてしまい、実態からずれます。
進行中の週を前週の7日分と比べると毎回マイナスに見える
進行中の週を前週の7日分と比べているダッシュボードは多く、水曜に見れば3日分と7日分の比較になります。毎週前半だけ落ち込んで見えると、数字そのものが信用されなくなります。
対策は、進行中の期間について、前の期間も同じ日数だけ切り取って比較することです。実データがある最終日を基準に、前週の同じ曜日までの合計と比べます。月次も同様に、前月の1日から同じ日までを対象にします。ラベルも前週比ではなく前週同期間比と明示的に出し分けます。月末の日数が異なるケース、たとえば1月31日に対する2月のような場合は、月末に丸める処理を入れておきます。
Search Consoleのデータで数字が合わない箇所と対策
Search ConsoleのBigQuery一括エクスポートは便利ですが、他のデータと並べたときに数字が合わない理由になる癖があります。
data_dateが太平洋時間で広告やGA4と日付がずれる
数時間のずれで週次の判断が変わることは多くありません。ただ、ずれを知らせないまま日別の数字を突き合わせると、原因の分からない差として扱われるので、揃えずに使うかわりに基準時刻を画面へ明記する方針にしました。
エクスポートされるテーブルのdata_dateは太平洋時間の日付です。日本時間で動いている広告データやGA4のデータとは、日付の切れ目がずれます。
対策は2つに分かれます。変換して日本時間に揃えるか、揃えずに使い、レポート側に基準時刻が違う旨を明記するかです。揃える場合はタイムゾーン変換を全クエリに通す必要があり、手間が増えます。
順位の列名がテーブルによって違い、平均掲載順位には1を足す
平均掲載順位に足す1を忘れると、全ページの順位がそろって1つ良く出ます。数字としてはもっともらしい値になるため、レビューでも気づきにくい箇所です。
サイト全体はsearchdata_site_impressionのsum_top_position、URL単位はsearchdata_url_impressionのsum_positionです。平均掲載順位は、順位の合計を表示回数の合計で割り、1を足して求めます。エクスポートされる順位が0始まりで記録されているためで、この1を忘れると全ページの順位が1つ良く出ます。
SELECT
data_date,
SUM(clicks) AS clicks,
SUM(impressions) AS impressions,
SAFE_DIVIDE(SUM(sum_position), SUM(impressions)) + 1 AS avg_position
FROM `PROJECT.searchconsole.searchdata_url_impression`
GROUP BY data_dateクエリ別の合計がサイト全体の数字と一致しない
レポートを受け取る側からは、合計が合わないという指摘が来ます。仕様である旨を画面内に注記として置いておくと、そのたびに説明する手間がなくなります。
クエリ別の数字をすべて足しても、サイト全体の数字にはなりません。これはバグではなく仕様です。Search Consoleは検索回数が極端に少ないクエリを匿名化し、クエリの値をnullにしたうえでis_anonymized_queryフラグを立てます。プライバシー保護のための処理です。
したがって、サイト全体の数字を出すときは匿名化されたクエリも含めて集計し、クエリ明細を出すときは匿名化を除外して集計します。この2つが一致しないのが正しい状態です。
進行中の週は2日から3日欠ける
進行中の週は反映のラグで2日から3日ぶん欠けます。前週と並べると急落しているように見えるため、初期表示は直近の閉じた週にしています。
反映にラグがあるため、進行中の週のデータは不足した状態になります。前週との比較で急落しているように見えるのは、多くの場合この欠けが原因です。
対策は、週次レポートの初期表示を直近の閉じた週にしておくことです。進行中の週も選べるようにしたうえで、進行中であることをバッジで明示します。
手順3、Connected Sheetsでスプレッドシートへ出力する
3つ目の手順は、BigQueryのビューの結果をGoogleスプレッドシートへ渡すところです。Connected Sheetsの抽出機能を使うと、ビューを指定してシートのタブへ結果を展開でき、更新のスケジュールもシート側で設定できます。表示に使う5つのテーブルを、それぞれ別のタブへ出します。
ダッシュボードから直接BigQueryを参照しない理由は、手順4で扱う表示側の制約にあります。表示するページから外部への通信ができないため、どこかでデータを持ち出す必要があり、スプレッドシートがその中継地点になります。認証を分けられるので、閲覧者にBigQueryの権限を渡さずに済む利点もあります。
この層で決めておきたいのは、シートへ出す粒度です。表示に必要な粒度まではBigQuery側で集約してから出します。次のコメントのとおり、粒度を落とさずに出すと読み取りの上限に当たります。
手順3でミスしやすいポイントと対策
スプレッドシートの読み取りがエラーなしで途中で切れる
Search Consoleのクエリ別データを日次のまま出していたところ、サイズが大きすぎて読み込みが途中で切れました。エラーは出ず、文字列が切断された状態で返ります。パースの側では列が足りないという別の症状として出ます。
シートの読み取りにGoogle Driveのコネクタを使う場合、返ってくるのは全シートタブを連結した1つのMarkdown文字列です。タブを指定して取り出すことはできず、すべてまとめて返ります。そしてこの返却値には実質的なサイズの上限があります。
対策は、Search ConsoleとGAをBigQuery側で週次に集約してからシートへ出力し、クエリ別はさらに各週のクリック上位50件に絞ることです。データ量が大きく減り、安定して読み込めるようになります。週次レポートで日次のクエリ別データを使う場面はないため、粒度を落としても失われる情報はありません。
連結Markdownはアンダースコアがエスケープされ、ヘッダーが3行目にある
ここはシート側の仕様なので、変わる前提でパーサ側に吸収させています。テーブルの判別を出現位置に頼ると、シートのタブ順を入れ替えられた時点で壊れます。
この連結された文字列には固有の癖があります。アンダースコアがバックスラッシュでエスケープされて返るため、campaign_idのような列名はそのままでは一致しません。また各テーブルの1行目は空行、2行目が罫線、実質的なヘッダーは3行目という構造になっています。パーサを書くときは、この3点を前提にします。
複数のテーブルが連結されているため、どれがどのテーブルかの判別も必要です。ここは出現位置ではなく、ヘッダーに含まれる列名の組み合わせで判定します。位置で判定すると、シートのタブ順を変えた瞬間に壊れます。campaign_idを含めば広告のテーブル、channel_groupを含めばGAのチャネル別テーブル、というように列名で一意に特定します。
手順4、単一HTMLで表示し毎朝自動で更新する
最後の手順は、ダッシュボードの画面を作り、毎朝データを差し替えて再公開する処理を組むところです。
画面は単一のHTMLファイルとして実装し、Claudeのアーティファクトとして公開する構成です。この方式にはページから外部への通信ができないという制約があります。CSPで止められているため、ページを開いたらBigQueryやスプレッドシートを読みに行く、という一般的な作りができません。そこで、データはHTMLの中にJavaScriptの配列として直接書き込みます。そのうえでデータ部分をコメントのマーカーで挟み、外部の自動処理が毎朝そのマーカーの間だけを差し替えて、同じURLへ再公開します。
/* DATA:START */
const DATA_UPDATED = "2026-07-29";
const SNAPSHOT = [ /* 各テーブルの行データ */ ];
/* DATA:END */ページ側にデータ読み込みの機能を持たせる方法もありますが、その場合は閲覧者側にもデータへの権限が必要になり、URLを送れば誰でも見られるという要件と両立しません。共有のしやすさを優先するなら、焼き込み方式になります。
毎朝の処理は、スプレッドシートを読む、テーブルをパースする、JavaScriptの配列の形に組み立てる、現在公開中のページを取得する、マーカーの間を差し替える、同じURLへ再公開する、という流れです。この処理自体もサーバー側で自動実行させます。作成用のAPIは公開されていないため、画面から手作業で作成します。あわせて、実行環境のネットワークアクセス設定で公開先のドメインを許可しておく必要があります。これを忘れると再公開の段階で失敗します。
グラフの配色は色覚シミュレーションで数値検証する
グラフの系列色は、P型とD型の色覚特性のシミュレーションをかけ、隣り合う系列の色差を数値で確認します。
実装時の検証では、候補の1つがD型のシミュレーションで色差1.6程度まで落ちました。人の目がわずかな違いとして識別できる境界がおよそ2.3とされているため、事実上区別できない値です。この配色は採用していません。
黄色系は白背景でコントラスト比が2程度にしかならず、単独では読みにくくなります。黄色を使うなら、色だけに頼らない見せ方にします。凡例に数値を併記する、テーブルを併置するといった形で、色が判別できなくても情報が取れる状態にしておきます。採用したのは青、黄、緑、ピンク、紫の5色で、全ペアの組み合わせで検証を通しています。グラフの配色や見せ方の設計は、GA4レポートを自動化する方法で扱った可視化の考え方とも共通します。
手順4でミスしやすいポイントと対策
公開したダッシュボードで日本語が文字化けする
公開したページで日本語が大きく文字化けしました。ページ側でメタタグを足しても直りません。配信ラッパーの外側は変えられないためです。
原因は文字エンコーディングの判定にあります。ブラウザはエンコーディングを判定するとき、HTML Standardのprescanアルゴリズムに従って先頭1024バイトまでを走査します。アーティファクトの配信ラッパーには相応の量のJavaScriptが含まれており、charsetの宣言がこの1024バイトより後ろに位置します。宣言が見つからなければブラウザはエンコーディングを推測し、外せば文字化けします。
対策は、HTMLを完全にASCIIだけで構成することです。マークアップ内のテキストは数値文字参照に、JavaScriptの文字列リテラルはユニコードエスケープに変換します。ASCII文字しか含まれていなければ、どのエンコーディングで解釈されても結果は同じになるため、文字化けは起きません。手作業では追いつかないため、UTF-8のソースファイルを書き、ビルドスクリプトで純ASCIIに変換する構成にします。ビルド時には非ASCII文字が1バイトでも残っていたら失敗するチェックを入れます。CSSブロック内はエスケープが効かないため、CSSのコメントは英語で書くルールにし、日本語コメントを書いた時点でビルドが落ちるようにします。
取得したHTMLをそのまま再公開するとページが二重構造になる
現在公開中のページを取得して、データ部分を差し替えて公開しなおす処理を書きました。取得したHTMLをそのまま公開ツールへ渡していたところ、ある日ページが二重構造になりました。
取得したHTMLには配信用のラッパー、つまりdoctypeからhtml、head、bodyまでの外側の殻が含まれています。一方で公開ツールは、渡されたコンテンツに自動でラッパーを付ける仕様です。ラッパー込みのものを渡せば、その外側にもう一枚ラッパーが付きます。
対策は、取得したHTMLから最初のbody開始タグの直後から最後のbody終了タグの直前までを切り出し、その中身だけを渡すことです。あわせて、公開の直前にdoctypeやhtmlタグが残っていたら停止するチェックを入れます。取得と公開は一見対称に見えても、扱うデータの形が違うことがあります。
自動実行の仕組みを取り違えるとPCを起動しないと動かない
ローカルで動くスケジュールタスクとクラウドで動くルーティンは名前が似ています。ローカル側はデスクトップアプリが起動していないと動かず、PCを立ち上げないと更新されない元の問題に戻るため、クラウド側で組んでいます。
Claudeにはローカルで動くスケジュールタスクと、クラウドで動くルーティンの2種類があり、名前が似ているため混同しやすくなっています。ローカルのほうはデスクトップアプリが起動していないと動かないため、PCを立ち上げないと更新されないという元の問題に戻ります。完全にサーバー側で動くクラウドのルーティンを使います。
壊れたデータで上書きしないための安全弁
取得が中途半端に失敗すると、0行ではなく一部だけ取れた状態になることが多く、行数の下限だけでは判定しきれません。上書きすると前の状態は戻せないので、チェックは重ねて掛けています。
自動更新で避けたいのは、壊れたデータで正常なページを上書きすることです。上書きすれば前の状態は残りません。公開の前に通すチェックを複数用意します。
| チェック | 停止する条件 |
|---|---|
| マーカーの存在 | DATA:START と DATA:END が見つからない |
| データ配列の宣言 | 5つのテーブルの配列宣言が揃っていない |
| 行数の下限 | テーブルごとに定めた最低行数を下回る（広告なら15行など） |
| 前回との比較 | 現在公開中の行数より20%以上減っている |
| 文字種 | 組み立てたHTMLに非ASCII文字が混ざっている |
とくに効くのは前回との比較です。データ取得が中途半端に失敗したときは、0行になるのではなく一部だけ取得できた状態になることが多く、最低行数のチェックだけではすり抜けます。
チェックに引っかかった場合は何もせず、前日のデータのまま残します。古いデータが表示されているほうが、壊れたデータが表示されるより被害が小さく、翌日に正常に動けば自動的に復旧します。
AIに実装させるなら、空いた時間は検証と安全弁に回す
難所はコードではありません。SQLを書くこと自体は難しくありません。難しいのは、このユーザー数は足してよい数字なのか、この日付は何時間ずれているのか、この合計が一致しないのは仕様なのかバグなのか、を判断することです。ここを誤ると、動いているのに間違っているダッシュボードができます。止まらない分、間違いに気づくのも遅れます。
そして自動化するなら、壊れたときに止まる仕組みをセットで作ります。自動化はうまくいっているあいだ何も起きないため、失敗したときの挙動でしか品質を測れません。
実装をAIに任せると、書く速度が上がる分、空いた時間を検証と安全弁の設計に回せます。ビューを作ったらSELECTして手計算と突き合わせる、ダッシュボードの数字を1つずつ元データと照合する。この工程を省くと数字が信用されなくなり、半年後には見られないダッシュボードになります。
自作が難しい場合は構築だけを外部に任せる
ここまでの手順は、Google Cloudやサービスアカウント、各媒体のAPIの扱いにある程度慣れた人が、最初の構築に時間を割ける前提のものです。実際には、媒体ごとのAPI申請で止まる、BigQueryの設計まで手が回らない、作ったものの数字が合わず検証で止まる、といった理由で進まないことも少なくありません。
その場合は、構築だけを外部に任せ、運用は自社で回す分担がおすすめです。日本AI導入支援協会の広告レポート自動化・ダッシュボード構築支援では、レポート業務の棚卸しとKPI設計から始め、広告、GA4、Search Console、CRMといったデータの統合、可視化基盤の構築、月次レポートの自動化、AIによるレポート要約や改善コメントの作成までを一貫して支援しています。特定のSaaSありきではなく業務に合わせて組むため、自作で目指していた形をそのまま実装まで持っていけます。
参照
- Google 広告 API レポートの概要
- Meta Marketing API インサイト
- LINEヤフー広告 API 認可認証について
- LINEヤフー広告 検索広告API リファレンス
- LINEヤフー広告 ディスプレイ広告API リファレンス
- GA4 BigQuery Export のセットアップ
- GA4 BigQuery Export スキーマ
- BigQuery への Search Console データの一括エクスポートについて
- Search Console 一括エクスポートのテーブル仕様（列名と匿名化クエリ）
- BigQuery パーティション分割テーブル
- BigQuery のデータを扱うコネクテッドシート
- Cloud Run ジョブの作成と実行
- Cloud Scheduler でジョブを作成する
- HTML Standard 文字エンコーディングの判定（prescan）
コメント