予算ペーシングとは、月予算に対する消化率を日次で追い、理想支出との乖離に応じて介入を決める管理を指す。手順は、分母を配信日で置く → 変更履歴と消化額の段差を突き合わせる → 日予算合計 × 30.4 で課金上限を検算する → 総額の前に配分を見る。30.4 倍は上限であって着地予測ではなく、未消化なら超過しない。
なぜ消化率だけを見ていると手遅れになるのか
予算ペーシングとは、月予算に対する消化率を日次で追い、理想支出との乖離幅に応じて介入するかを決める管理を指す。手順は ①理想支出の分母を暦日ではなく配信日で置いてペース乖離率を出す ②変更履歴を取得し、消化額の段差と変更を時刻で突き合わせる ③配信中キャンペーンの日予算合計 × 30.4 が契約上の月予算を超えていないかを検算し、超えていれば上限として是正するか超過の可能性を承認する ④総額を削る前に配分を見る、の順。例外として、意図した前倒し消化・季節性・変更直後・月初 1〜2 日は、乖離が出ても介入しない。30.4 倍は課金上限であって着地予測ではなく、着地の見込みは実績・残日数・需要から別に出す。
消化率は結果であって原因ではない。「今月は 2 割ほど超えそうです」という報告は、それだけでは打ち手に変換できない。乖離が生じた日時と、その日時に入った設定変更を並べて初めて、抑制するのか、配分を直すのか、そもそも設定値を是正するのかが決まる。
判定に使っている帯は次のとおりで、これは当社が運用している内規である（Google 公式が定める閾値ではない）。乖離幅だけでなく、残りの配信日数と組み合わせて打ち手を変える。介入の前提として、計測の健全性、コンバージョンの計上遅れ、入札戦略の学習状態、限界効率も確認する。乖離だけで増減幅を決めない。
表: 当社内規の判定帯（媒体の推奨値ではない）
| ペース乖離（+ が超過） | 残配信日が月の 1/2 以上 | 残配信日が 1/3 未満 |
|---|---|---|
| ±10% 以内 | 変更なし | 変更なし（着地見込みだけ確認） |
| +10〜15% | 原因確認、翌営業日に再判定 | 低効率な面から 10〜15% 抑制 |
| +15〜20% | 低効率な面から 10〜15% 抑制 | 抑制し、着地予測を日次で更新 |
| +20% 超 | 緊急レビュー（予算・配信制約・計測・売上を同日確認） | 同左に加え、設定値そのものを是正 |
| −15% 以下 | 好調な面の日予算を 10〜15% 増額し 3〜7 日観察 | 無理に追わず、翌月繰越と事業側施策を確認 |
本稿の実務側の観察は、複数キャンペーンを運用する広告アカウント 1 件の監査にもとづく。出典は匿名化した支援案件の実装ログで、観測主体は当社、観測範囲は当該アカウントの変更履歴と配信実績、観測期間はある月の月初から数日。案件が特定されないよう、業種・規模・時期・金額の実額は抽象化し、比率は丸めている。以下は一般則ではなく、公式仕様で説明できる範囲に限って一般化した観察である。
理想支出の分母は、暦日ではなく実際の配信日で置く
手順 1 — 理想支出の分母を「配信日」で置き直す
平日のみ配信、あるいは特定の時間帯だけ配信しているアカウントで、暦日ベースの線形理想支出を分母に置くと、乖離率は実態より大きく出る。監査したアカウントでは、暦日ベースだと超過幅が実態より 1 割ほど大きく見えていた。
分母は次の順に精度を上げる。配信日ベース（当月の配信予定日数で割る）を主指標に置き、曜日ごとの支出偏りが大きい場合はさらに曜日係数で補正する。曜日係数は直近 8〜12 週の同曜日支出比率から作り、連休・長期休暇のように配信を止めた週は係数の作成から除外する。
| 分母の置き方 | 使いどころ | 注意点 |
|---|---|---|
| 暦日ベース（線形） | 全曜日配信で偏りが小さいとき | 平日のみ配信では超過を過大に見せる |
| 配信日ベース | 主指標。曜日・時間帯の制限があるとき | 手動停止した日を配信日から外す |
| 曜日係数で補正 | 曜日の支出偏りが大きいとき | 停止期間を含む週を係数の材料にしない |
月初 1〜2 日は分母が小さく、乖離率が大きく振れるため判定を保留する。**この保留は「見ない」ではなく「事故だけ見る」**である。通常の支出があるのにコンバージョンが突然ゼロになった、データが取得できない、といった事故は成熟度を待たずに扱う。
手順 2 — 変更履歴を取り、消化率の段差と突き合わせる
ここが監査の本体である。管理画面の変更履歴は、画面上の操作だけでなく、自動ルール・API・エディタ経由の変更も表示する。取得したら、変更日時・変更者・経路・対象・変更前後の値を 1 表にして、日次の消化額の推移と時刻で並べる。
監査したアカウントでは、直近の変更はいずれも同じ日に管理画面から入った日予算の引き上げで、自動ルールによる変更はなかった。消化額の段差はその日を境に生じており、主要因の候補を日予算の変更に絞り込めた。ただし時系列の一致は因果の確定ではない。同時期の検索需要、競合、入札戦略、審査状況を排除するために、変更前後の予算による表示機会の損失率、表示回数、クリック単価を併記して確度を示す。逆にいえば、変更履歴を取らずに消化率だけを見ていれば、「配信が伸びた」以上の説明はできなかった。
乖離は「いつ・誰が・何を変えたか」と突き合わせて初めて原因になる
注意点が 2 つある。第一に、Google 広告 API の変更イベント（ChangeEvent）で取得する場合、期間に上限がある。日付範囲は直近 30 日以内、1 回の照会は上限 1 万行で、これは API の仕様であり管理画面の変更履歴の表示期間とは別である（API のバージョン更新で変わりうるため、公開時点の公式ページで再確認する）。API で月をまたぐ監査をするなら、月次で取得して保存する運用を先に作っておく。
第二に、変更者が取得できない更新記録が別系統にある。変更履歴（ChangeEvent）は変更日時・変更者・前後の値を含む監査記録だが、エンティティ単位の更新追跡（ChangeStatus）は「どのリソースがいつ変わったか」を検出するためのもので、変更者や理由は含まれない。監査したアカウントでも、更新追跡には出るのに変更履歴に対応する記録がない更新が変更履歴の数倍あり、深夜帯にまとまっていた。
| 記録 | 含まれるもの | 含まれないもの |
|---|---|---|
| 変更履歴（ChangeEvent） | 変更日時・変更者・経路・対象・変更前後の値 | 変更者の付かないシステム側の更新 |
| 更新追跡（ChangeStatus） | 変更されたリソースと最終更新時刻 | 変更者・変更前後の値・理由 |
状況証拠はそろっていても「自動」と断定はせず、「不明」として残した。ここを推測で埋めると、後日「クライアント側が触った」といった誤った前提が独り歩きする。
手順 3 — 設定値そのものを検算する：日予算合計 × 30.4
日次監視は「実績が理想を超えたら気づく」後追いの仕組みで、設定値の時点で契約予算を超える課金上限を許可している型は検出できない。Google は平均日予算に対し、1 日あたり最大 2 倍、1 か月あたり 30.4 倍を課金上限としているGoogle 広告ヘルプ「平均日予算について」[1]。これは上限であって支出の保証ではなく、検索需要・入札・広告ランクによっては上限まで使われない。したがって、配信中キャンペーンの日予算合計 × 30.4 が契約上の月予算を超えている状態は「契約予算より高い課金上限を自分で許可している」状態であり、満額近く消化されれば超過し、未消化なら超過しない。上限管理の観点では、この状態を検出した時点で是正するか、超過の可能性を承認して残すかを決める。
監査したアカウントがまさにこれで、月初に引き上げられた日予算の合計は、上限の掛け算だけで契約上の月予算を超えていた。日々の消化を細かく見ても検出できない種類の状態である。
| 検算のタイミング | 式 | 注意点 |
|---|---|---|
| 月初・変更前（設定監査） | Σ(配信中キャンペーンの平均日予算。共有予算は共有予算単位で 1 回だけ) × 30.4 ≤ 月予算 | 費用列に税・手数料が含まれるかを請求書と照合。総額予算型・開始終了日付きのキャンペーンは別計算 |
| 月央の着地見込み | MTD 実績 + 残配信日 × 直近の配信日平均支出（レンジで持つ） | 上限の計算とは別物。月中に予算を変えた場合は変更前の実績と残期間で分ける |
| 月央の是正 | 必要日次支出 = (月予算 − MTD 実績) ÷ 残配信日 | 月初の上限をそのまま流用しない |
| 日予算への換算 | 日予算合計の上限 = 必要日次支出 ÷ 実測倍率 | 実測倍率 = 配信日平均支出 ÷ 日予算合計 |
配信日を限定しているアカウントで上限まで使われる場合、配信日あたりの倍率は理論上 30.4 ÷ 当月の配信日数に近づく（配信日が 20〜22 日なら約 1.4〜1.5 倍）。監査したアカウントの実測は 1.3〜1.5 倍だったが、未消化なら 1 に近づくため、アカウントごとの過去実績から推定し、固定値を流用しない。月初に出した「月予算 ÷ 30.4」の上限を月央にそのまま使うと、すでに超過した分だけ足りず、是正してもなお超える。
設定値の検算は、日次監視では代替できない
費用の定義をそろえるのも同じ理由で必須である。管理画面の費用列に税や手数料が含まれるかは請求国と契約形態で異なるため、請求書と照合して同じ基準に直してから契約上の月予算と比べる。
手順 4 — 総額の前に配分を見る
超過が確定的でも、いきなり全体を削ると縮小均衡に入る。監査したアカウントでは、成果の出ていない検証用キャンペーンが消化の大きな割合を占め、一方で最も効率の高いキャンペーンは日予算が据え置かれ、予算不足で表示機会の一部を失っていた。この状態で総額を一律に削れば、効率の高い面から先に削られる。
判断材料になるのが、予算による表示機会の損失と、広告ランクによる損失の内訳である。予算による損失が大きい面は増額で取り戻せる余地があるが、ランクによる損失が大きい面は増額だけでは取り戻せない。**「削る前に、どこが予算律速で、どこがランク律速かを分ける」**のが順序である。
AI の日次アドバイザーは何を根拠に人へ決裁を回すのか
日次のペーシング監視は、判定基準が数値で書ける以上、自動化に向く。当社では毎朝、各アカウントのデータを取得し、社内の判断基準に照らして正常・要観察・介入候補の 3 つにタグ付けし、介入候補だけを 1 件 1 メッセージで人の決裁に上げる運用にしている。人が返すのは承認・見送り・保留の 3 択で、承認されるまで媒体への書き込みは行わない。
| 段階 | 担当 | 中身 |
|---|---|---|
| 取得 | 自動 | 期間窓ごとの実績・ペース・変更履歴を取得 |
| 判定 | 自動 | 内規の帯に照合し、正常 / 要観察 / 介入候補に分類 |
| 候補化 | 自動 | 1 候補につき、状況の数値・根拠の条項・打ち手・様子見条件・効果判定までの日数を書く |
| 決裁 | 人 | 承認 / 見送り / 保留の 3 択 |
| 実行 | 自動 | 承認された範囲だけを、変更幅の上限内で実行し記録 |
効かせている制約は 3 つで、見送られた提案は理由が変わらない限り再提案しない、金額影響が大きい変更は実行案件ではなく検討案件として上げる、判定に使った数値と根拠の条項を必ず添える（根拠が書けなければ「基準がない」と報告する）、である。
実行の可否は人が決める。自動化するのは取得・判定・候補化まで
いつ「乖離していても放置」が正解か
乖離が出たら常に介入する、という運用は誤りである。次の場合は、乖離を確認したうえで変更しない。
| 状況 | なぜ放置が正解か | 確認すること |
|---|---|---|
| 意図した前倒し消化 | 商戦期・在庫・キャンペーン期間に合わせた計画的な配分 | 前倒しの終了日と、その後の抑制計画 |
| 季節性による偏り | 曜日・月内の偏りは例年どおりの挙動 | 曜日係数と前年同月の形 |
| 変更直後（当社内規ではおおむね 72 時間。入札戦略の変更を伴う場合は公式の学習期間の案内に従う） | 効果判定の期間内で、重ねて触ると原因が分離できない | 前回変更の日時と判定予定日 |
| 月初 1〜2 日 | 分母が小さく乖離率が大きく振れる | 事故の有無だけを見る |
| コンバージョンの計上遅れ | 直近日の成果は後から上振れする | 計上遅れの実測日数 |
様子見も打ち手である。ただし再判定日を決めてから見送る
見送る場合は、次にいつ判定するかを決めてから見送る。再判定日のない様子見は、単に忘れる運用と区別がつかない。
次に読む診断チェック — 予算超過を報告する前に 7 項目を確認する
- 理想支出の分母を、暦日ではなく当月の配信予定日で置いたか。
- 曜日の支出偏りが大きい場合、直近 8〜12 週から曜日係数を作り、停止期間を材料から除いたか。
- 変更履歴を取得し、変更日時・変更者・経路・変更前後の値を 1 表にしたか。
- 消化額の段差と、変更履歴の日時を並べて突き合わせたか。
- 変更者を取得できない更新を、「自動」と断定せず「不明」として残したか。
- 配信中キャンペーンの平均日予算合計（共有予算は 1 回）× 30.4 を、費用の定義をそろえて契約上の月予算と比べ、超えていれば上限として是正するか承認を取ったか。
- 総額を削る前に、予算律速の面とランク律速の面を分けたか。
7 項目のうち 1 つでも「確認できない」が残るなら、その着地予測は暫定として扱い、報告に未確認項目を明記する。mixednuts では、こうした日次の運用設計と広告アカウントの監査を マーケティング支援 として提供している。
FAQ
Q. 予算ペーシングの理想支出は、暦日で割ってよいか？ A. 全曜日に配信していて偏りが小さいなら暦日でよい。平日のみ配信や時間帯の制限があるアカウントでは、分母を当月の配信予定日数に置き換える。暦日のままだと乖離率が実態より大きく出て、不要な抑制を招く。
Q. 変更履歴はどこまでさかのぼれるか？ A. Google 広告 API の変更イベント（ChangeEvent）で照会する場合、日付範囲は直近 30 日以内、1 回の照会は上限 1 万行となる（API の仕様。管理画面の変更履歴の表示期間とは別で、バージョン更新で変わりうる）。API で月をまたぐ監査を想定するなら、月次で取得して自社側に保存する運用を先に作っておく。
Q. 変更履歴に出てこない更新はどう扱えばよいか？ A. エンティティ単位の更新追跡（ChangeStatus）には変更者や変更前後の値がないため、そこから原因は復元できない。状況証拠がそろっていても「自動」と断定せず「不明」として残す。推測で埋めた前提は、後の判断を誤らせる。
Q. 日次で消化率を見ていれば予算超過は防げるか？ A. 検出できない型がある。Google は平均日予算の 30.4 倍を月間の課金上限としているため、配信中キャンペーンの日予算合計 × 30.4 が契約上の月予算を超えていれば、契約予算より高い課金上限を許可している状態にあり、満額近く消化されれば超過する（未消化なら超過しない）。設定を触る側で検算し、是正か承認をするしかない。
Q. 月の途中で是正するとき、日予算の上限はどう出すか？ A. 月初の「月予算 ÷ 30.4」を流用しない。まず (月予算 − 当月実績) ÷ 残配信日で必要日次支出を出し、それを実測倍率（配信日平均支出 ÷ 現行の日予算合計）で割って日予算合計の上限を求める。配信日を限定しているアカウントで上限まで使われる場合の理論値は 30.4 ÷ 配信日数だが、未消化なら 1 に近づくため、アカウントごとの過去実績から推定する。
Q. AI に予算変更まで任せてよいか？ A. 当社では取得・判定・候補化までを自動化し、実行の可否は人が承認・見送り・保留の 3 択で決める運用にしている。承認後の実行も、1 回あたりの変更幅と同一対象への変更頻度を機械側で制限する。金額影響が大きい変更は、実行案件ではなく検討案件として上げる。
参考文献 / Sources
予算とペーシングの仕様:
- Google 広告ヘルプ[1]: 平均日予算について — 1 日あたり 2 倍・1 か月あたり 30.4 倍の課金上限
- Google 広告ヘルプ: 超過配信と平均日予算について — 超過配信が起きる条件と上限の考え方
- Google 広告ヘルプ: キャンペーンの平均日予算を設定・変更する — 日予算の設定と変更の反映
変更履歴:
- Google 広告ヘルプ: 変更履歴について — 画面操作・自動ルール・API・エディタ経由の変更が記録される範囲
- Google 広告ヘルプ: アカウント履歴を確認する — ユーザー別・キャンペーン別の見方
- Google Ads API: Change Event — 直近 30 日・上限 1 万行の制約、変更者と変更前後の値の取得
- Google Ads API: Change Status — エンティティ単位の更新追跡と、変更者情報を持たないこと
- Google Ads API: change_event フィールド一覧 — 取得できるフィールドの定義
関連記事:
知見を、事業の実装へ。
60分の無料相談で、貴社に適した論点と次の一手を整理します。