毎朝Google広告の管理画面を開いて、昨日の数字をコピーしてスプレッドシートに貼る。月初はキャンペーン別の実績をExcelにまとめ直して上司やクライアントに送る。この作業は、Google公式の手段だけで、ほぼ無料で消せます。
問題は、自動化のやり方が1つではないことです。調べると「Looker Studioでつなぐ」「スクリプトを書く」「BigQueryに転送する」「Ads APIを叩く」と別々の話が出てきて、どれが自分に合うのか判断がつきにくい。
以下では、それぞれのやり方の設定手順と限界、Ads APIを直接使う場合の開発者トークン申請からGAQL・Pythonの実コード、さらに集めたデータをAIにつないで分析・考察まで自動化する方法までを、2026年7月時点の公式ドキュメントに沿って順に見ていきます。数字を集めて終わりではなく、「考察つきのレポートが毎朝届く」状態がゴールです。
先に結論です。Google公式の手段は4つあり、選び方は用途で決まります。
図のとおり、どのやり方も費用はほぼかかりません。違いが出るのは、出力先と書くコードの量です。
順に設定手順を見ていきます。
いちばん簡単な方法です。Looker Studio（旧データポータル）にはGoogle広告のネイティブコネクタが組み込まれており、画面操作だけでつながります。以下、コピペで完走できる手順です。
（本記事のUI表記は2026年7月時点のものです。Looker Studio・Google広告・Google CloudコンソールいずれもUIは頻繁に更新されるため、以降の各手順でも同様の前提で読んでください。）
ここまでの確認: 表に日別・キャンペーン別の実績数値が入っていれば成功です。左上のレポート名をクリックして分かりやすい名前（例: Google広告 日次レポート）に変更し、右上の「共有」ボタン横のフォルダアイコンで保存先を指定して保存すれば、以降は同じURLを開くだけで最新の数字が見られる状態になります。
難点は、データの更新間隔がおおむね12時間ごとに寄り、リアルタイムの数字は追えないこと。加えて生データを加工しにくく、「手数料を上乗せした請求ベースの金額で見たい」「別集計の売上と突き合わせたい」といった要件が出てきた時点で手狭になります。
無料ダッシュボードとしての位置づけや他ツールとの比較は広告レポート自動化ツール比較｜主要9ツールの料金・対応媒体・選び方で整理しました。
「レポートはスプレッドシートで欲しい」なら、この方法です。Google Adsスクリプトは広告アカウントに内蔵されたJavaScript実行環境で、開発者トークンもOAuth設定も要りません。以下、書き込み先スプレッドシート作成からスケジュール実行までコピペで完走できる手順です。
Google広告 日次レポート）に変更してEnterキーを押しますhttps://docs.google.com/spreadsheets/d/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/edit#gid=0）を丸ごとコピーして、メモ帳などに控えます。後述のコード中の スプレッドシートのURL に貼り付けますスプレッドシートのURL の部分は、手順1でコピーしたURLに置き換えてください（前後のクォートは残す）/**
* Google広告のキャンペーン別・日別レポート（過去30日）を
* 指定スプレッドシートのアクティブシートに書き込む
*/
function main() {
const query =
'SELECT segments.date, campaign.name, metrics.clicks, ' +
'metrics.cost_micros, metrics.conversions ' +
'FROM campaign WHERE segments.date DURING LAST_30_DAYS ' +
'ORDER BY segments.date';
// ↓「スプレッドシートのURL」を手順1で控えたURLに置き換える
const sheet = SpreadsheetApp.openByUrl('スプレッドシートのURL').getActiveSheet();
sheet.clear(); // 前回の書き込みを消してから最新データを流し込む
AdsApp.report(query).exportToSheet(sheet);
}daily-report-fetch）に変更しますsegments.date / campaign.name / metrics.clicks / metrics.cost_micros / metrics.conversions の列と、過去30日分のデータが書き込まれているはずですここまでの確認: スプレッドシートを開き直して、日別・キャンペーン別の行が入っていれば成功です。エラーになった場合は画面下部の実行ログに詳細が出るので、URLの貼り間違い（docs.google.com/spreadsheets/d/... の形式か）を最初に確認してください。
翌朝、指定した時刻帯の後にスプレッドシートを開いて、最新日付までのデータが入っていれば自動化が動いています。実行ログはスクリプト一覧の「ログ」列（アイコン）から確認できます。
MCC（管理アカウント）のスクリプトなら複数アカウントの横断も可能です。
難点は1実行あたり最大30分という壁と、出力先が実質スプレッドシートに限られることの2点。アカウント数が多い代理店や、大量の検索語句データを扱う場合は、実行時間の上限に当たります。GASでスプレッドシートに書き込む一般的な設計は広告レポートをスプレッドシート×GASで自動化する方法で扱っています。
複数の切り口で分析したい、AIに分析させたい、他のデータと組み合わせたい。そうなったときの本命がこれです。BigQuery Data Transfer Service（DTS）のGoogle Ads転送を設定すると、広告アカウントの全レポートデータが毎日BigQueryに自動で溜まります。
設定は画面操作だけで、開発者トークンも不要です。以下、コピペで完走できる手順です。
ads-bq-transfer）を入力し、「作成」をクリックします。数十秒後、右上ベルアイコン（通知）に完了通知が出るので、通知内の「プロジェクトを選択」をクリックします（上部バーのプロジェクト名が今作った名前になっていることを確認）BigQuery API と入力し、検索結果の「BigQuery API」をクリックして「有効にする」をクリックします（すでに有効の場合は「管理」ボタンが表示されます）BigQuery Data Transfer API を検索し、「有効にする」をクリックしますここまでの確認: 「APIとサービス」→「有効なAPIとサービス」の一覧に「BigQuery API」と「BigQuery Data Transfer API」の両方が表示されていれば成功です。
google_ads。半角英数と _ のみ使用可）左のエクスプローラーでプロジェクトの下に、今作ったデータセット（例: google_ads）が表示されていれば準備OKです。
Google Ads Daily Transfer）google_ads）を選択123-456-7890 の形式で表示されるものを、ハイフンなしの10桁、例: 1234567890 で入力）。MCCのIDを指定すれば配下アカウントを一括転送できます7 のまま（過去7日分を毎回洗い替えでコンバージョン遅延を補正）Google Ads Daily Transfer）をクリックしますads_Campaign_<customer_id>（キャンペーン属性）や ads_CampaignBasicStats_<customer_id>（インプレッション・クリック・費用などの指標）といったテーブルが並んでいれば、正常にデータが入っていますここまでの確認: エディタで以下のSQLを実行して、行が返ってくれば成功です。<customer_id> は手順4で入れたIDに置き換えてください。
SELECT
s._DATA_DATE AS date,
c.campaign_name,
SUM(s.metrics_impressions) AS impressions,
SUM(s.metrics_clicks) AS clicks,
SUM(s.metrics_cost_micros) / 1000000 AS cost_jpy,
SUM(s.metrics_conversions) AS conversions
FROM `プロジェクトID.google_ads.ads_CampaignBasicStats_<customer_id>` AS s
JOIN `プロジェクトID.google_ads.ads_Campaign_<customer_id>` AS c
ON s.campaign_id = c.campaign_id
AND c._DATA_DATE = s._DATA_DATE
WHERE s._DATA_DATE = DATE_SUB(CURRENT_DATE('Asia/Tokyo'), INTERVAL 1 DAY)
GROUP BY date, c.campaign_name
ORDER BY cost_jpy DESC;属性テーブルと指標テーブルを campaign_id でJOINして使うのが基本構造です。翌日以降は、手順4で設定した時刻に自動で転送が走り、テーブルが日次で更新されます。
費用面が優秀で、Google Ads転送そのものは無料。かかるのはBigQueryのストレージとクエリ料金だけで、月10GiBの保存・1TiBのクエリまでの無料枠（2026年7月時点）に広告レポート程度のデータ量は収まることが多く、実質0円で回せます。転送はデフォルトで過去7日分を毎回洗い替えるため、コンバージョンの計上遅れも勝手に補正されます。
実務で気をつけるのは、指標テーブルに CampaignStats ではなく CampaignBasicStats を使うこと。Stats系はクリック種別などで行が分かれており、素朴にSUMすると数字が合わなくなります。加えてSQLを書ける人がチームに要ります。クエリの書き方次第でスキャン課金が変わる点は、BigQueryのコスト設計に踏み込むBigQueryの料金体系とコスト削減｜課金トラップと対策に譲ります。
社内システムへの組み込み、独自ツールの開発、リアルタイムに近い取得。ここまで来るとAds API直連携です。いちばん自由ですが、いちばん段取りが要ります。順を追って、コピペで完走できる粒度で説明します。
やり方4は前提物が多く、途中で足りないことに気づくと詰まります。着手前に以下が揃っているか確認してください。
Ads APIを呼ぶには開発者トークンが必須で、取得にはMCC（管理アカウント）が必要です。通常の広告アカウントからは申請できないため、持っていなければ先にMCCを無料で作成します。
自社MCC）を入力、「このアカウントの用途」で「自社の広告を管理する」を選択、「請求先の国」と「タイムゾーン」（(GMT+09:00) 東京）、通貨（日本円 JPY）を選択して「送信」をクリックします123-456-7890 の形式で右上に表示）が発行されます。これをMCCのお客様IDとして控えます開発者トークンでアクセスできるのは、そのトークンを発行したMCCにリンクされている広告アカウントだけです。 忘れると後の実行が必ず PERMISSION_DENIED で失敗します。
123-456-7890 形式）を入力し、「送信」をクリックしますDeveloper token の欄が現れ、ABCdefGHIjklMNOpqrsTUV のような22文字前後の文字列が発行されます。これを開発者トークンとして控えますここまでの確認: APIセンター画面に「開発者トークン」の値と、現在のアクセスレベル（初期は「テストアカウントのみ」）が表示されていれば発行成功です。この時点ではテストアカウントに対してのみAPI呼び出しが可能で、本番アカウントに対してはBasicアクセスの承認後に使えるようになります。
したがって、発行直後の検証パスは次のいずれかです。
customer_id をそのテストアカウントのIDに置き換えて先に進むこの使い分けを飛ばして、承認前の本番アカウントIDでいきなり手順3のスクリプトを走らせると、確実に DEVELOPER_TOKEN_NOT_APPROVED で落ちます。
トークンには4つのアクセスレベルがあります（2026年7月時点）。
| アクセスレベル | 使える相手 | 操作数の上限 | 取得 |
|---|---|---|---|
| テスト | テストアカウントのみ | 15,000/日 | 即時 |
| Explorer | 本番アカウント可 | 2,880/日 | 発行時に自動付与 |
| Basic | 本番・テスト | 15,000/日 | 申請後、公式目安は約2営業日（遅延時で1週間前後） |
| Standard | 本番・テスト | ほぼ無制限 | Basic取得後に申請、実務体感で1〜2週間程度 |
（テスト列の15,000/日は「テストアカウント環境での上限」を指します。Explorerでもテストアカウントに対しては15,000/日まで叩けます。）
重要なのは、レポート取得の search/searchStream は1リクエスト=1オペレーションとして数えられることです。何万行返ってきても1回は1回。日次レポートを取るだけならBasicの15,000/日で余裕があり、Standardまで必要になるのは外部提供ツールを作るケースがほとんどです。
BasicアクセスへのアップグレードはAPIセンター画面の「アクセスレベル」欄の「適用」（Apply）ボタンから申請できます。表示された追加フォームで、より詳細な利用目的とリクエスト数見込みを記入して送信します。
開発者トークンとは別に、OAuth 2.0のクレデンシャル（クライアントID・クライアントシークレット・リフレッシュトークン）が要ります。以下、Google CloudコンソールでOAuthクライアントを作り、OAuth Playgroundでリフレッシュトークンを取るところまで通します。
ads-api-report）を入力し、「作成」をクリックします。作成完了後、通知内の「プロジェクトを選択」で切り替えますads-api-report）ads-api-oauth-client）https://developers.google.com/oauthplayground と入力（末尾スラッシュなしが基本。もしOAuth Playground側で redirect_uri_mismatch が出た場合は、末尾スラッシュ付きの https://developers.google.com/oauthplayground/ も追加登録してから再試行してください）〜.apps.googleusercontent.com という形式）と「クライアント シークレット」がダイアログに表示されます。この画面を閉じるとシークレットは再表示できないため、必ず両方をこの場でコピーしてパスワード管理ツールなどに保存してください（再発行は可能ですが手間がかかります）Google Ads API と入力し、検索結果の「Google Ads API」をクリックして「有効にする」をクリックします「APIとサービス」→「有効なAPIとサービス」の一覧に「Google Ads API」が表示され、「クライアント」画面に作成したOAuthクライアントの行があれば準備完了です。
https://www.googleapis.com/auth/adwords1// で始まる長い文字列が表示されるので、これをコピーして控えます。これがリフレッシュトークンですここまでの確認: 「Refresh token」欄が 1// で始まる文字列で埋まっていれば成功です。空のままの場合は、Googleアカウントのアクセス権管理で該当アプリのアクセス権を一度削除してから、手順6からやり直してください。
注意: OAuth同意画面の公開ステータスが「テスト」のままだと、リフレッシュトークンは7日で失効します。継続運用する場合は、Google Auth Platformの「対象」画面にある「アプリを公開」をクリックして本番ステータスにしておいてください。
自社アカウントのバッチ処理を定期実行するなら、本来はサービスアカウント一択です。リフレッシュトークンの失効管理が不要になり、サーバー運用がぐっと楽になります。ただし、サービスアカウントのメールアドレスはメール受信ができないため、Google広告UIから通常ユーザーと同じ「招待→受諾」フローで追加することはできません。多くの場合、MCC経由でのリンク付けや、事前に承認された連携経路を用意する必要があります。設定パターンは環境（自社MCCの有無、既存のGCPユーザー連携、対象アカウント数）によって変わるため、公式ドキュメントを必ず参照してください（1つのサービスアカウントに直接紐付けられるのは20アカウントまで。それ以上はMCC経由でカバーします）。
以降のコード例は、記事として一気通貫で試しやすい2-2のリフレッシュトークン方式で書いています。本番の定期実行に載せるときは、google-ads.yaml を公式ドキュメントのサービスアカウント形式に置き換えて動かしてください。
ここまでで揃うのは以下の値です。手元にコピーしてから次に進んでください。
python3 --version を実行）mkdir ads-api-report && cd ads-api-report
python3 -m venv .venv
source .venv/bin/activate # Windowsは .venv\Scripts\activatepip install "google-ads>=27,<28"原則として、ライブラリの最新版がその時点のAPIの最新versionに対応します。バージョン範囲を切っておくと、意図せず後方非互換のライブラリに上がって import 時点で壊れる、といった事故を避けられます。
google-ads.yaml を作るgoogle-ads.yaml というファイルを新規作成し、以下を貼り付けます。5か所のプレースホルダを、手順3冒頭で控えた値に置き換えてください（前後の引用符は残す）# google-ads.yaml — 認証情報ファイル(このファイルはGitにコミットしない)
developer_token: 'ここに開発者トークン(手順1-3で控えた22文字前後の文字列)'
client_id: 'ここにクライアントID(〜.apps.googleusercontent.com)'
client_secret: 'ここにクライアントシークレット'
refresh_token: 'ここにリフレッシュトークン(1// で始まる文字列)'
login_customer_id: '1234567890' # MCCのお客様ID(ハイフンなし10桁)
use_proto_plus: Trueなお、明示的にAPIバージョンを固定したい場合は、上記に加えて api_version: v25 のような1行を追加してください。指定がなければ、インストールしているライブラリが対応する最新versionが使われます。
.gitignore に google-ads.yaml を追加しておくのが安全ですecho "google-ads.yaml" >> .gitignorefetch_report.py というファイルを作り、以下を貼り付けます。customer_id = "1234567890" の10桁を、データを取りたい広告アカウントのお客様IDに置き換えてください"""
Google広告のキャンペーン別・日別レポート(過去30日)を取得して標準出力に表示する。
実行前準備:
- 手順1〜2で開発者トークン・OAuthクレデンシャルを取得済み
- 手順3-2で google-ads.yaml を作成済み
- pip install google-ads 済み
実行: python fetch_report.py
"""
from google.ads.googleads.client import GoogleAdsClient
from google.ads.googleads.errors import GoogleAdsException
def main():
# google-ads.yaml を読み込む(カレントディレクトリのファイルを指定)
client = GoogleAdsClient.load_from_storage(path="./google-ads.yaml")
# サービス取得時にAPIバージョンを明示できる(執筆時点で現行のv25。約1年でサンセット)。
# yaml側に api_version を書いた場合は version 引数は省略可。
ga_service = client.get_service("GoogleAdsService", version="v25")
query = """
SELECT
segments.date,
campaign.id,
campaign.name,
metrics.impressions,
metrics.clicks,
metrics.cost_micros,
metrics.conversions
FROM campaign
WHERE segments.date DURING LAST_30_DAYS
ORDER BY segments.date
"""
# ↓ データを取りたい広告アカウントのお客様ID(ハイフンなし10桁)に書き換える
customer_id = "1234567890"
try:
stream = ga_service.search_stream(customer_id=customer_id, query=query)
print("date\tcampaign_name\tclicks\tcost_jpy\tconversions")
for batch in stream:
for row in batch.results:
cost_jpy = row.metrics.cost_micros / 1_000_000 # 100万分の1単位を通貨単位へ
print(
f"{row.segments.date}\t{row.campaign.name}\t"
f"{row.metrics.clicks}\t{cost_jpy:.0f}\t{row.metrics.conversions}"
)
except GoogleAdsException as ex:
# よくあるエラー:
# DEVELOPER_TOKEN_NOT_APPROVED → 本番未承認(テストアカウントで検証)
# USER_PERMISSION_DENIED → MCCに広告アカウント未リンク or 認可アカウントに権限なし
# invalid_grant → リフレッシュトークン期限切れ(2-2をやり直し)
print(f"エラー: request_id={ex.request_id}")
for error in ex.failure.errors:
print(f" {error.error_code}: {error.message}")
raise
if __name__ == "__main__":
main()python fetch_report.pyここまでの確認: 標準出力に行が流れれば成功。何も出ない場合はデータ0件（テストアカウントや配信停止中）、GoogleAdsException が出た場合はメッセージで切り分けます。DEVELOPER_TOKEN_NOT_APPROVED は1-3の本番承認待ち（テストアカウントで検証）、USER_PERMISSION_DENIED は1-2のMCCリンクか2-2の認可アカウント権限を確認、invalid_grant は2-2のリフレッシュトークンをやり直します。
期間は DURING LAST_30_DAYS のほか BETWEEN '2026-07-01' AND '2026-07-31' のような指定もできます。GAQL（Google Ads Query Language）で使えるフィールドやセグメントの一覧は公式リファレンスで参照できます。
これをCloud FunctionsやCloud Runに載せてスケジュール実行し、結果をBigQueryやスプレッドシートに書き込めば、完全に自社仕様のレポートパイプラインになります。
なお、Apps Script（GAS）からもREST版の searchStream を UrlFetchApp で呼べますが、やり方2のGoogle Adsスクリプトとは別物です。アカウント内蔵のAdsスクリプトは開発者トークン不要、外部から叩くGASはトークン必須。GASから直接Ads APIを叩く実コードは、別記事の広告レポートをスプレッドシート×GASで自動化する方法を参照してください。スプレッドシートに出すだけならやり方2で足ります。
ここまでで「数字が自動で集まる」状態はできました。もう一歩踏み込んで、レポートの考察をAIに書かせるところまでが2026年時点の自動化の射程です。段階別に3つの形があります。
いちばん手軽なのは、やり方2で作ったスプレッドシートやCSVを、ChatGPT・Gemini・Claudeに渡して分析させることです。プロンプトは、欲しいアウトプットを列挙する形が安定します。
添付はGoogle広告のキャンペーン別・日別実績（過去30日）です。
1. CPAが悪化しているキャンペーンと、その要因の仮説
2. 予算の再配分案（増額すべき・減額すべきキャンペーン）
3. 今週チェックすべきポイント3つ
を、根拠となる数字を引用しながら簡潔にまとめてください。これだけで、週次ミーティングの「所感」レベルの下書きは出てきます。始める前に、機密データの扱いと「入力を学習に使わせない設定」だけ社内ルールを確認しておいてください。
やり方3でBigQueryにデータが溜まっていれば、「SQLで前日実績を集計 → 生成AIのAPIに渡して考察を生成 → Slackやメールに配信」という日次パイプラインが組めます。以下、GASで動かすまでの手順を通します。
AIza〜 で始まる文字列）をコピーして控えますads-daily-summary）と投稿先ワークスペースを選択 → 左メニュー「Incoming Webhooks」→ 上部トグルを「On」→「Add New Webhook to Workspace」→ 投稿先チャンネル（例: #広告運用）を選択して「許可する」→ 生成された https://hooks.slack.com/services/T.../B.../... の形式のURLをコピーして控えますGEMINI_API_KEY → 上記で控えたGemini APIキーSLACK_WEBHOOK_URL → 上記で控えたSlack Webhook URLGCP_PROJECT_ID → 手順3-1で作ったGoogle CloudプロジェクトのID。上部バーのプロジェクト名プルダウンを開き、ダイアログ内の「ID」列に表示される英数字文字列（例: ads-bq-transfer-123456）を使います（表示名ではなくIDを使う点に注意。名前を入れると「Not found」で落ちます）コード.gs の中身を全削除し、以下を貼り付けます。手順3の google_ads データセット名と ads_CampaignBasicStats_<customer_id> / ads_Campaign_<customer_id> の <customer_id> を、自分のIDに置き換えてください/**
* BigQueryから前日実績を集計 → GeminiでサマリをつくってSlackに投稿する日次バッチ
* トリガー: 時間主導型 → 日付ベースのタイマー → 午前7〜8時
*/
function dailyAiSummary() {
const props = PropertiesService.getScriptProperties();
const projectId = props.getProperty('GCP_PROJECT_ID');
const geminiKey = props.getProperty('GEMINI_API_KEY');
const slackUrl = props.getProperty('SLACK_WEBHOOK_URL');
// ---- 1. BigQueryで前日実績をキャンペーン単位に集計 ----
// ↓ <customer_id> を自分の広告アカウントIDに置き換える(ハイフンなし10桁)
const sql = `
SELECT
c.campaign_name,
SUM(s.metrics_impressions) AS impressions,
SUM(s.metrics_clicks) AS clicks,
SUM(s.metrics_cost_micros) / 1000000 AS cost_jpy,
SUM(s.metrics_conversions) AS conversions,
SAFE_DIVIDE(SUM(s.metrics_cost_micros) / 1000000, SUM(s.metrics_conversions)) AS cpa
FROM \`${projectId}.google_ads.ads_CampaignBasicStats_<customer_id>\` AS s
JOIN \`${projectId}.google_ads.ads_Campaign_<customer_id>\` AS c
ON s.campaign_id = c.campaign_id AND c._DATA_DATE = s._DATA_DATE
WHERE s._DATA_DATE = DATE_SUB(CURRENT_DATE('Asia/Tokyo'), INTERVAL 1 DAY)
GROUP BY c.campaign_name
ORDER BY cost_jpy DESC
`;
const request = { query: sql, useLegacySql: false };
let queryResults = BigQuery.Jobs.query(request, projectId);
const jobId = queryResults.jobReference.jobId;
// 完了待ち(通常数秒)
while (!queryResults.jobComplete) {
Utilities.sleep(500);
queryResults = BigQuery.Jobs.getQueryResults(projectId, jobId);
}
const rows = (queryResults.rows || []).map(function (r) {
return r.f
.map(function (c) {
return c.v;
})
.join('\t');
});
if (rows.length === 0) {
Logger.log('前日のデータが0件でした');
return;
}
const header = 'campaign_name\timpressions\tclicks\tcost_jpy\tconversions\tcpa';
const numbers = [header].concat(rows).join('\n');
// ---- 2. Gemini APIで考察を生成 ----
const prompt =
'あなたはGoogle広告運用のプロです。以下の前日(タイムゾーンはJST)のキャンペーン別実績から、\n' +
'(1) CPAが悪化していそうなキャンペーンとその仮説、\n' +
'(2) 今日の運用で確認すべきポイントを3点、\n' +
'日本語で簡潔にまとめてください。根拠となる数字は必ず本文中に引用すること。\n\n' +
'=== 前日実績 ===\n' +
numbers;
// モデル名は執筆時点(2026年7月)の現行版。世代・エイリアスは適宜差し替え。
const geminiRes = UrlFetchApp.fetch(
'https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent',
{
method: 'post',
contentType: 'application/json',
headers: { 'x-goog-api-key': geminiKey },
payload: JSON.stringify({ contents: [{ parts: [{ text: prompt }] }] }),
muteHttpExceptions: true,
}
);
if (geminiRes.getResponseCode() !== 200) {
throw new Error('Gemini API失敗: ' + geminiRes.getContentText());
}
const summary = JSON.parse(geminiRes.getContentText()).candidates[0].content.parts[0].text;
// ---- 3. Slackに投稿 ----
const slackRes = UrlFetchApp.fetch(slackUrl, {
method: 'post',
contentType: 'application/json',
payload: JSON.stringify({ text: '*Google広告 前日サマリ*\n' + summary }),
muteHttpExceptions: true,
});
if (slackRes.getResponseCode() !== 200) {
throw new Error('Slack投稿失敗: ' + slackRes.getContentText());
}
Logger.log('Slackに投稿しました');
}dailyAiSummary を選択して「実行」をクリックしますdailyAiSummaryポイントは1つだけで、生データを丸投げしないこと。何万行の生ログを渡すより、上記のSQLでキャンペーン別・日別に集計した数十行を渡すほうが、考察の精度もAPI費用も桁違いに良くなります。この考え方はなぜAI時代にこそデータ基盤が必要か｜生成AIが失敗する理由で詳しく扱っています。
補足として、BigQueryにはSQLから直接Geminiを呼び出す生成AI関数（BigQuery ML）もあり、GASを挟まずGCP内で完結させたい場合はそちらの構成が選べます。ただし本記事のようにSlackへの通知や別サービス連携まで含めるなら、GASを間に挟む本構成のほうが素直です。
ChatGPTやClaudeのコネクタ・MCP（AIから外部ツールに接続する仕組み）でBigQueryをつなぐと、「先月からCPAが悪化した要因を分解して」のような対話での深掘り分析ができます。定型は自動配信、非定型は対話。この分担で回すのが手堅い運用パターンです。
ここまでのAI分析・異常検知を既製で載せたい場合は、私たちのアドヨミAIのように、広告データのBigQuery集約とAI考察をセットで提供するサービスという選択肢もあります。
ここからは、実際に運用して初めて気づきやすいポイントです。Evastでも広告データ基盤の構築で繰り返し踏んできた石を並べます。
まず筆頭は、リフレッシュトークンが7日で失効する件。OAuth同意画面が「テスト」ステータスのままだと、リフレッシュトークンは7日で切れます。開発中に「先週動いていたのに認証エラーになった」となる原因の代表格で、対処は同意画面を本番ステータスに公開することです。あわせて、6か月使われないトークンも失効します。
次に、cost_micros の割り忘れ。費用は cost_micros という100万分の1単位で返ってきます。1,230円なら 1230000000。1,000,000で割らずにレポートに載せて、桁違いの請求額に青ざめるのは通過儀礼です。
GAQL側の落とし穴として、セグメントを足すほど行が細かく分割され、組み合わせによっては互換性エラーになります。また segments.date をSELECTに入れると、WHEREでの期間指定が必須になります。2026年6月からは細かいセグメントに37か月のさかのぼり上限も入りました。まず最小のクエリで動かし、セグメントは1つずつ足すのが安全です。
日付の扱いにも一癖あります。レポートの日付は広告アカウントに設定されたタイムゾーンで区切られ、クエリ側では変えられません。海外アカウントを扱う場合、自社の集計基準とずれる前提で設計する必要があります。
そしていちばん厄介なのが、APIバージョンの寿命。Ads APIは約3か月ごとに新バージョンが出て、メジャー版の寿命はおよそ1年です（直近ではv21が2026年8月に廃止）。コードに埋めたバージョン番号は、年1〜2回の載せ替え作業が発生する前提で保守計画に入れておく必要があります。
ここまでのやり方は、Google広告1媒体なら十分に内製できる範囲です。実際、やり方1〜3は無料で、半日もあれば動き始めます。
内製の限界が来るのは、たいてい媒体が増えたときです。Yahoo!広告、Meta、TikTokと増えるたびに、認証方式もAPIの仕様も更新頻度も違う連携を1本ずつ作り、仕様変更のたびに直し続けることになります。Yahoo!広告側の手順と仕様の違いは、別記事のYahoo!広告レポート自動化のやり方｜広告APIの使い方とAI分析を参照してください。レポート自動化の費用対効果が崩れるのは、だいたいこの局面。外注した場合の相場感については広告レポート自動化の費用は？ツール・代行の料金相場と選び方に別途まとめています。
私たちが提供しているアドヨミAIは、まさにこの「複数媒体×BigQuery集約」を肩代わりするサービスです。Google・Meta・TikTokなどの広告データをAPIで自動連携して自社所有のBigQueryに集め、前処理からAI分析・異常検知まで載せて、初期5万円・月額1.5万円〜（媒体数に応じた累進制、例: 4媒体で月5.5万円）で運用できます。この記事のやり方3・4とAI分析を全媒体分まとめて外注する、と考えていただくと位置づけが近いです。
Google広告1媒体のレポート自動化は、公式手段だけで実質0円から始められます。ダッシュボードで見るならLooker Studio、スプレッドシートに落とすならGoogle Adsスクリプトが最短。分析まで踏み込むならBigQuery Data Transferが本命で、Ads API直連携は自由度と保守負担が最大です。
集めたデータをAIに渡すコツは、生ログを丸投げせず集計してから渡すこと。落とし穴で最も踏みやすいのは、リフレッシュトークン7日失効と cost_micros の単位ミスの2つです。ここが越えられれば、あとは媒体を増やしていく段階に入ります。
明日の朝のコピペ作業を1つ消すところからでも、効果は体感できます。まずはやり方1か2を今日設定してみてください。
株式会社EvastのアドヨミAIは、Google・Meta・TikTokなど主要媒体の広告データをAPIで自動連携し、自社所有のBigQueryに集約する半スクラッチ型の広告レポート自動化・AI分析サービスです。
現状の運用の棚卸しからで構いません。1媒体・最短2週間から始められます。
Amazon広告のレポート自動化は、まず「Amazon Ads API」と出品者業務向けの「SP-API」を混同しないことが出発点です。LWA（Login with Amazon）でのOAuth認証、API利用申請、Profile ID取得の手順から、reporting/reportsへのレポートリクエスト→ステータスのポーリング→ダウンロードという非同期取得の3ステップ、Pythonの実コードまでを、2026年8月時点で確認できる公式情報に沿って整理します。
Meta広告のレポート自動化でつまずくのは、公式コネクタが無いことと、トークンの静かな失効です。この記事はMarketing API直連携を軸に、システムユーザートークンでの無期限運用と、管理画面との数値ずれの直し方までまとめました。
TikTok広告のレポートを毎朝手で集めているなら、自動化の選択肢は3つ。管理画面のスケジュールレポート、コネクタ・ETLツール、Marketing API直連携。API利用に必要な開発者登録・アプリ審査の通し方、無期限アクセストークンの取得、/report/integrated/get/でのレポート取得の実コード（curl・Python・GAS）、日別取得の30日制限やCVが後から増える仕組み、集めたデータをAIにつなぐクリエイティブ疲弊検知の要点を、2026年7月時点の公式情報を軸にまとめた。
Yahoo!広告はLooker Studioの公式コネクタが無く、Google広告と同じ感覚で自動化しようとすると手が止まる。管理画面のメール配信、API申請不要のYahoo!広告スクリプト、そしてLINEヤフー広告APIの直連携まで、それぞれのやり方と実コード、集めたデータをAIにつなぐところまでを2026年7月時点の公式情報で整理した。