ad-budget-pacing

予算ペーシング

あなたは有料メディアのペーシング分析担当者です。あなたの仕事は、現時点までの消化額を、本来この時点までに消化されているべき額と比較し、乖離が実際に問題なのかを判断して、その原因を特定し、ギャップを埋めるために今日の日予算をいくら変更すべきか、担当者に1つの数値を伝えることです。

このスキルが防ごうとしているアンチパターンは、「12％遅れています」で終わるアラートです。これでは、分析担当者が行うべき計算を読み手に押し付けるうえ、プラットフォーム独自の配信の仕組みで完全に説明できる乖離までアラートしてしまいます。ペーシングの乖離は過去に関する証拠であって、未来への指示ではありません。推奨する前に診断し、変更は可逆性のある最小限のものにしてください。

対象範囲と引き継ぎ

このスキルは追跡とフラグ付けを行いますが、アカウントには変更を加えません。推奨には必ず担当者を明記して引き継ぎます。予算や入札額の変更を実行するのは、アカウントの運用担当者です。隣接する領域は、関連するスキルに任せます。

• 予算を最初に設定する → mbfinotti/advertising-skills@ad-spend-allocation。
• 停止しきい値と損失ガードレール → mbfinotti/advertising-skills@ad-spend-guardrails。
• 消化額の背後にあるCAC／ROASが健全かどうか → mbfinotti/advertising-skills@cac-roas-benchmark。
• 意図的なスケールアップの計画 → mbfinotti/advertising-skills@paid-media-scaling。
• 入札方法の選択 → mbfinotti/advertising-skills@ad-bidding-strategy。
• ペーシング以外のアカウントレベルの根本原因診断 → mbfinotti/advertising-skills@ad-account-diagnostic。
• トラッキング停止の疑い（ペーシング不足の原因として特定されたもの） → mbfinotti/advertising-skills@ad-conversion-tracking。

対象範囲は、1つのキャンペーンまたは1つのアカウントと、1つの予算の比較に限ります。共有予算に対する複数チャネルの再配分は対象外です。

ヒアリング

質問は一度に1つずつ行い、データからすでに分かることは省略します。戦術的な確認です。短く済ませてください。

1. 対象期間は暦月ですか、それとも開始日と終了日が固定された配信期間ですか？日付を教えてください。
2. 対象期間の総予算はいくらですか。また、必達額（必ず使い切る必要がある）ですか、それとも目標額（効率性を優先）ですか？
3. 対象のプラットフォームはどれですか？
4. B2Bですか、それともB2Cですか？
5. 広告枠の購入は保証型／IOベースですか、それともオークション形式ですか？（これは目標曲線と対処法の両方に影響します。IOのセクションを参照してください。）
6. 既知の季節性や曜日ごとの傾向はありますか？また、加重曲線を作成できる、2～3サイクル分の配信実績がありますか？
7. アラートの受信者と、是正の担当者は誰ですか？
8. 是正はいつまでに完了している必要がありますか？期間の終了日ですか、それともそれより前のクライアント、財務、またはQBRのレビュー日ですか？
9. これは1つの配信期間に対する単発の確認ですか、それともこのアカウントで各期間に実施するペーシング運用ですか？
10. 許容できる作業量はどの程度ですか？分析担当者が毎日ざっと確認するだけですか、それとも曜日別インデックスの作成と保守に時間をかけられますか？

最後の3つの質問への回答は、以下の各選択肢の優先順位をすべて変えます。何かを推奨する前に必ず確認してください。

• 現在の期間中に期限が来る場合は、ほぼゼロに近いトリアージ確認とフラット曲線が優先されます。インデックスを構築して検証する時間はありません。
• 定期的に実施する場合は、加重曲線と記憶を活用した再調整が優先されます。どちらも期間を重ねるごとに効果が蓄積しますが、単一の配信期間では効果がありません。

これらの回答のいずれかで制約が明示された場合、単に順位を下げるのとは異なり、その選択肢は使えなくなります。最後に回すのではなく、選択肢から削除し、レポートには削除した選択肢と、削除の根拠となった回答を記載してください。

• 作業量の上限が1レイヤーの場合、週次の集計、期間終了時の総点検、期間途中のチェックポイントを運用サイクルから削除し、毎日の確認だけを残します。
• IOのないオークション形式のアカウントでは、追加配信とクレジットによる救済策を削除します。
• 使用可能な配信実績がない場合、2～3サイクル分の実績がそろうまで加重曲線を削除します。

最後に回された選択肢は、誰にも実行されず、次の期間にまた提案されるだけです。

算術

期間について、以下をすべて計算します。数式は業界で合意されている算術です（UpdateMate、PPC Hero、Adpulseでは同一の数式が示されています）。判断が入るのは基準値とゲートであり、数式ではありません。

elapsed_share      = days elapsed / days in period
expected_to_date   = period budget × elapsed_share            (flat curve)
pacing_ratio       = spend to date / expected_to_date
budget_utilization = spend to date / period budget
remaining_budget   = period budget − spend to date
projected_spend    = (spend to date / days elapsed) × days in period
required_daily     = remaining_budget / days remaining
adjust_spend_by    = required_daily − trailing 7-day average daily spend

• pacing_ratio が 1.0 なら計画どおりです。これを下回るとペーシング不足、上回るとペーシング超過です。
• projected_spend（ランレート、またはバーンレート。これらの用語は同じ意味です）は、「何も変わらなければ、最終的にどこに着地するか」を示します。
• required_daily は「明日から何を達成する必要があるか」を示します。予測値と併せて報告してください。予測値だけでは、修正の大きさが見えません。
• adjust_spend_by が成果物です。乖離の大きさだけでなく、ギャップを埋めるための本日の1日あたりの支出額の増減を符号付きで示します。

用語上の注意点が1つあります。「pacing %」は、ベンダーのツールによって少なくとも3つの互換性のない意味で使われています。

• 実績 ÷ 期待値
• 期間終了時点の消化率の予測
• 達成済みのペースと、今後必要なペースの比較

引用または取り込むペーシング値については、どの数式で算出したかを必ず明記してください。

キャンペーン全体ではペーシングに問題がない場合でも、キャンペーン内のオブジェクトにはフェアシェア下限のテストを適用してください。支出額が (period budget ÷ active objects) × elapsed share × 0.5 を下回るオブジェクトは、単に成果が低いのではなく、配信システムによって配信を抑制されています。これはキャンペーン全体のペーシング不足とは別の所見であり、全体指標だけでは見えません。

加重期待曲線

フラットな曲線は毎日が同じ価値だと仮定します。期間に週末、祝日、小売イベント、またはB2B特有の平日への偏りが含まれる場合、この仮定は誤りです。加重方式では、elapsed_share を日次重み指数の累積シェアに置き換えます。

expected_to_date = period budget × (Σ weights of elapsed days / Σ weights of all days)

指数は標準的な方法で作成します。各期間の指数 ＝ その期間の配信量 ÷ 全期間の平均（指数が 1.40 の週は、平均的な週を 40％上回ります）。指数は乗算するため、月の指数 × 曜日の指数で日次の期待値が得られます。重みは一般的なテンプレートではなく、アカウント独自の直近の配信実績から導出してください。また、2～3回分の完全なサイクルの履歴に基づく指数だけを信頼してください。

重要な理由は次のとおりです。後半に配信が集中する13週間の四半期では、加重曲線は第6週の終わりまでに配信量の34％を期待しますが、フラットな曲線では46％を期待します。そのため、フラットモデルでは、実際にはまったく問題のないペースが12ポイント遅れていると報告されます。すべてのレポートで両方の曲線を実行し、アカウントに既知の傾向がある場合は加重曲線でアラートを出してください。両者の差が10ポイント以上の状態で続くなら、重み付けが効果を発揮している証拠です。

この2つは互換性がなく、示す軸も異なります。

effort:     weighted > flat
value:      weighted > flat
efficiency: flat > weighted on a one-off check; weighted > flat from the second period onward

フラットな曲線はコストがほぼゼロで、今日の時点で十分な頻度で正しい結果を出せます。加重曲線は構築に1時間と、手元にない可能性もある2～3サイクル分の履歴が必要ですが、その後は追加コストがかかりません。効果が積み重なる資産なので、アカウントを複数回確認する場合は、優先順位が逆転します（面接の質問9）。デフォルトでは、履歴が乏しい場合、または今日中に回答が必要な場合はフラット曲線のみを使い、それ以外の場合は両方の曲線を使って、加重曲線でアラートを出します。

誤報ゲート

アラートが発火する前に、このゲートを実行してください。ペーシングに関する問題の大半は、配信システムが完全に説明できる数値に反応することで発生します。以下のいずれかに該当する場合は、アラートを抑制し、抑制理由をレポートに記録してください。

1. 累積で判断したとき、逸脱がプラットフォームの文書化された超過配信許容範囲内に収まっている。 主要なプラットフォームは、トラフィックを獲得するために単日の予算を意図的に超過して使い、期間予算に照らして精算します（許容範囲はプラットフォームに関する注記を参照）。累積消化額を按分した期間予算と比較し、単日消化額を日予算と比較してはいけません。
2. フライトの最初または最後の不完全な日である。 プラットフォームは、利用可能な時間に合わせて初日と最終日の消化額を調整します。このような日のペーシング不足は、純粋に機械的な理由で発生します。
3. 分母が小さすぎる。 経過日数が1、2日しかない比率や、期待値がほぼゼロの場合、数値は大きく変動し、誤報の大半を引き起こします。分母が小さすぎる場合や、比較できない期間（タイムゾーン、通貨、アトリビューション設定が異なる期間）にわたる場合は、パーセンテージに基づくアラートを発してはいけません。
4. 期間が短すぎて判断できない。 フライト初期の配信は、設計上変動が大きくなります。ペーシングの 逸脱 はすぐに測定できますが、対応する価値のあるペーシングの 問題 はそうではありません。実務者の経験に基づく下限として、消化額が目標単価のおよそ3倍に達するまで、効率の判断を保留してください。この水準で信頼度は約95％に達します（2倍の時点では、偽陰性率は依然として約13％です）。
5. 再学習期間内に予算が編集されている。 プラットフォームの説明によると、予算変更によってシステムは最適な配信を再学習します。編集後の変動は編集そのものによるもので、ペーシングの問題ではありません。判断する前に、安定化期間が過ぎるのを待ってください。
6. 数値が日中のものである、または修正前のものである。 トラフィックのピーク時にはダッシュボードの反映が数時間遅れ、消化額が修正されることもあります。また、無効トラフィックに対するクレジットによって、過去の消化額が後から減る場合もあります。日中の数値に基づいてアラートを発してはいけません。ペーシングの記録は不変ではないことに留意してください。

6つすべてのチェックを通過したアラートは、担当者が確認する価値があります。いずれかに該当しないものはノイズです。それをアラートとして報告すると、担当者が本当に重要なアラートを無視するようになります。

閾値

以下の既定値を設定し、どちらも明示的に実務者の慣例。このアカウントの過去の実績に照らして再調整することと記載してください。プラットフォームのルールとして扱ってはいけません。

• オンペースの範囲：ペーシング比率0.90～1.10。
• 緊急の範囲：0.85未満または1.15超。逸脱に原因の確認が加わった場合は、当日中にエスカレーションします。

以下の公開されている範囲は、順位を付けずに列挙しています。これらは4段階の調整で示された同一の主張であり、いずれもあなたのアカウントに対する根拠がないため、順位を付けると見せかけの精度になります。どれが適切かは、このアカウント固有の逸脱履歴だけで判断し、どれかを選ぶのではなく再調整してください。

• 90～110％（UpdateMate）
• 緑は95～105％、黄は85～115％（Insightful Pipe）
• ±15％を超えた場合にアラート、1.30を超えた場合に自動介入（US Tech Automations）
• DSPで取引される予算では、±5パーセントポイントが健全（Vortex IQ）

オンペースの範囲を文書化しているプラットフォームはありません。この不一致自体が、これらが慣例であることを示しています。

業界で唯一、プラットフォームが文書化しているペーシング閾値は、Googleの予算制限ステータスの根拠となるトラフィック損失5％のトリガーです（詳細はプラットフォームに関する注記を参照）。

広く繰り返し語られる「20％を超える予算変更でMetaの学習がリセットされる」というルールは俗説です。Metaの文書には記載がなく、実際の文言は、定量化されていない「変更の大きさ」にリセットのリスクを結び付けています。大幅な編集に慎重になるのは妥当なリスク管理ですが、20％をプラットフォームのルールとして引用するのは誤りです。

原因の診断

ゲートを通過する乖離は、原因がおよそ10通りある症状であり、それぞれ対処法が異なります。何かを推奨する前に、原因を見分ける証拠を確認してください。

この表は代替案の一覧ではなく、原因を照合するためのものです。そのため、どの原因にも順位はありません。各原因は、1つのアカウントの状態について互いに排他的な解釈です。最も効率的な原因を選ぶのではなく、証拠が裏付ける原因を見つけてください。重要なのは確認を実行する順序であり、その順序は表の下に続きます。

原因	方向	原因を見分ける証拠
予算上限に到達	予算による支出上限	予算制限による配信ステータス。日予算を早い時間に使い切る。予算によるインプレッションシェア損失が高い
入札上限に到達／目標が厳しすぎる	ペースが遅い	ランクによるインプレッションシェア損失が高く、予算による損失は低い。入札またはコスト管理を理由とする学習制限ステータス
オーディエンスが小さすぎる	ペースが遅い	オーディエンス規模の推定値が下限に近い。オーディエンス規模を理由とする学習制限ステータス。配信予測が低い
広告の不承認／ポリシー	急な配信不足	承認欄にポリシーコードとともに却下／不承認と表示されている
請求／支払いの失敗	すべてが同時に停止	請求バナー。アカウントレベルの支出上限に気付かないまま到達。支払いの拒否
トラッキング／ピクセルの障害	コンバージョン最適化オブジェクトのペースが遅い	支出が続いているのにコンバージョン数が横ばい、またはゼロ → mbfinotti/advertising-skills@ad-conversion-tracking に引き継ぐ
オークションコストの変動／競合他社／季節性	どちらもあり得る	CPM/CPCの推移。ペースが設定変更ではなく市場の動きに合わせて変化する
スケジュール／タイムゾーンの境界	表面的な現象のみ	デイパーティングが有効。アカウントとレポートのタイムゾーンが異なる。支出が日付の境界をまたぐ
フリークエンシー上限	上限が適用されたインベントリで配信不足	フリークエンシー分布で上限に達するにつれ、配信が抑制されている
学習フェーズ／編集によるリセット	ペースが不安定	学習ステータスが有効。最近の大幅な編集日
制御機能の競合	ペースが変動する	プラットフォームの自動ペース調整と外部の予算自動化の両方が同じオブジェクトに作用している。編集ログに交互の修正が記録されている

トリアージの順序

労力あたりに得られる情報量が多い順にチェックを実行します。最も安価なものから始めてはいけません。価格だけを見ていると、最初の3ステップで原因を1つずつ除外することになりますが、1つのステータス画面を見れば5つを除外できたはずです。評価軸は一致しないため、それぞれ個別に記載します。

efficiency: status sweep > edit log > constraint pair > audience size > auction-cost read > schedule check
value:      constraint pair > status sweep > auction-cost read > audience size > edit log > schedule check
effort:     auction-cost read > constraint pair > audience size > status sweep == edit log == schedule check

1. ステータスの一括確認 - 労力はほぼゼロ、画面は1つで、アカウントの変更も不要です。拒否／ポリシー、請求とアカウントの支出上限、予算制限、学習制限を一度に確認でき、11個の原因のうち5つをまとめて判別できます。原因が特定されたら、ここで終了します。
2. 過去7～14日間の編集ログ - 労力はほぼゼロです。学習フェーズのリセットと競合するコントローラーを特定し、チェック5でそもそもアラートを抑制すべきだったかどうかもわかります。
3. 制約要因の確認 - 1時間かかりますが、リストの中で最も価値の高いチェックです。
   • 予算によるインプレッションシェアの損失は、制約が資金であることを意味します。ランクによる損失なら、入札額か品質が制約であり、予算を増やしても効果はありません。
   • ソーシャルでは、代わりに配信診断に示された制限要因を確認します。
   • これは入札側と予算側を区別できる唯一のチェックであり、対処方法を決定します。これを確認せずに予算変更を勧めてはいけません。また、予算制限のフラグを解消するために予算を増やす場合は、損失の大きさとキャンペーンの収益性も必ず確認します。
   • このフラグが示すのは支出が制約されていることだけであり、その制約が不適切だということではありません。
4. オーディエンスサイズと配信予測 - 数分で済みますが、判別に役立つのは対象が狭い場合だけで、対象が広い場合はほとんど役に立ちません。
5. オークションコストの確認 - 最も時間がかかるチェックです。業界の CPM と日予算を照合し、配信期間中の CPM／CPC の傾向も確認します。設定では対処できない2つの原因、つまりインプレッションを買うには資金が少なすぎる対象と、市場の変化を特定できます。1～3で問題が見つからなかった場合にのみ、時間をかける価値があります。
6. スケジュールとタイムゾーン - 労力はほぼゼロですが、通常はゲートで確認済みです。数値が日付の境界をまたぐ場合に限って実施し、原因ではなく見かけ上の問題が見つかると考えてください。

この順序では、オークションコストの確認が後回しになります。 リストの中で最も時間がかかるチェックです。また、「ここに問題はなく、市場が変化した」と結論づけられる唯一のチェックでもあるため、情報量と労力の比率を重視すると毎回先送りされます。その結果、分析担当者が一見もっともらしいステータスフラグで確認を止め、季節性の問題に対して設定変更を行うことになります。

次のいずれかに該当する場合は、ステータスの一括確認より先に実施してください。

• 編集ログに変更がないのに、配信期間を通じて CPM または CPC が推移している。
• このアカウントで、同じ逸脱に対して今期すでに一度「修正」が行われている。

設定を問題なく修正した後も逸脱が再発するなら、それはオークションの動向を示しています。それを捉えられるチェックは、リストにある他のどのチェックよりも安価ではありません。制約要因の確認には、そのような優先措置は不要です。ステップ3のルールにより、予算を勧める前に必ず実施することになっています。

6つすべてで問題がなければ、配信は正常に機能していると結論づけ、現状を維持します。原因が特定されたら、同じ評価軸で対処方法の優先順位を決めます。対象間で再配分 > 制約要因（入札額、ターゲット、またはターゲティング）を解消 > 総支出を増やす。総額を増やす前に、効率のよい対象に資金を回し、無駄を抑えます。まず入札額を見直し、予算はその次です。

どちらの順序もあくまで基本であり、絶対的なルールではありません。アカウントや、実行する人によって変わります。アカウントにアクセスできる運用担当者なら、ステータスの一括確認は数秒で済みます。一方、エクスポートされたレポートを使う分析担当者にとっては、編集ログの確認のほうが制約要因の確認より時間がかかることがあります。

このユーザーについてすでにわかっていることを踏まえて順序を見直し、どの情報によってどのチェックの優先順位を変えたかをレポートに記載します。

• 過去に2回経験した請求の失敗
• オークションコストの確認をほぼ無料にできる社内 CPM ベンチマーク
• 配信診断で制限要因がすでに示されるプラットフォーム

B2B と B2C

計算、誤検知を除外するゲート、しきい値、診断マトリックスはどちらも同一です。再計算しないでください。異なるのは、想定される曲線と、それに対して進捗を調整する方法です。

• B2B：
  • 進捗の期待値は暦日ではなく営業日で計算します（実務上の慣例）。平日に偏るアカウントは、暦日ベースの曲線では毎週月曜日に構造上「遅れている」状態になります。
  • オーディエンスが少なく単価が高いため、日々の消化額は変動しやすくなります。分母が小さすぎる場合と期間が短すぎる場合のゲートを、より厳格に適用してください。
  • コンバージョンまでのタイムラグは数週間に及びます。進捗は支出の推移を基準にし、期間累計のコンバージョンを基準にしないでください。仕組み上、期間累計の数値は未確定だからです。
• B2C：
  • 週末や夜間が成果の大部分を占めることが多いため、営業日ベースの曲線による補正は適切ではありません。アカウント独自の曜日別指数を使用してください。
  • 小売イベントでは正当な急増が発生します。その急増を過剰なペースとして警告するのではなく、イベントに合わせて指数を前倒ししてください。

保証付き IO とオークション

買い付けタイプによって、目標曲線と対応策の両方が決まります。

• 保証付き／IO ベース：均等配信よりも 先行 するペースで進めます。トレーダーの一般的な慣行では、IO の進捗を按分値よりわずかに先行させ、配信不足が懸念される場合に限り、終盤で加速します。配信不足には契約上の救済措置があります。4A’s／IAB Standard Terms v3.0 では、両当事者が追加配信期間を交渉し、合意に至らない場合、買い手は未配信分の価値に相当するクレジットを受け取ることができます。2026 年 2 月発効の IAB Direct Buy Addendum では、重大な配信不足について売り手が買い手に速やかに通知する義務が追加されています。そのため、ダイレクト買い付けで進捗が遅れている場合は、配信リスクだけでなく開示義務も伴います。
• オークションで購入したパフォーマンス広告：同じ IAB 条項では、CPA、CPL、CPC の成果物は配信保証と追加配信の対象外であることが明記されています。いずれの当事者にも義務はありません。進捗が遅れるコストは、未消化予算による機会損失です。予算が厳格な確約でない限り、予算消化率より効率を優先します（インタビュー質問 2）。

IO の配信不足に対する救済措置は 3 つありますが、同じものではありません。

efficiency (= value, they agree here): accelerate > make-good flight > credit
effort:                                make-good flight > credit > accelerate
compliance cost:                       make-good flight == credit > accelerate

それぞれの救済措置には異なる役割があります。

• 加速：すでに利用できる配信設定で、配信期間中に元に戻すことができ、審査も発生しません。元の在庫で保証分全体を確保できます。
• 追加配信期間：インプレッション価値を回復できますが、交渉、契約変更、双方の承認が必要です。
• クレジット：交渉が不成立の場合に、規約で保証される代替措置です。キャンペーンが対象として購入されたオーディエンスではなく金銭を返還し、配信期間を修正するのではなく終了させます。

原則として、配信期間にまだ余裕がある間は加速し、加速では不足分を埋められなくなった時点で追加配信を交渉します。残り期間が短すぎる場合はこの原則が逆転します。交渉だけが、対応に間に合う可能性のある救済措置となるためです。

どちらの場合も早めに通知してください。対応が遅れると、在庫の問題に加えて信用も損ないます。

運用の周期

アカウントの運用方法に合わせて確認の頻度を調整します。各レイヤーは互いに影響し合いますが、工数の上限によって選択が必要になった場合に備えたメニューでもあります（インタビュー質問 10）。

efficiency: daily check > weekly roll-up > end-of-period sweep > mid-flight IO checkpoint
effort:     daily check > weekly roll-up == mid-flight IO checkpoint > end-of-period sweep

日次チェックは、合計で最も工数がかかります。これはタスクではなく、継続的に行う業務です。それでも最優先なのは、修正がまだ小さく済むうちに逸脱を検知できる唯一のレイヤーだからです。それより下のレイヤーはすべて、すでに広がったギャップを報告します。上限に収まるレイヤーがちょうど 1 つだけなら、日次チェックを実施し、残りは省略してください。

保証付きの買い付けでは順序が逆転します。この場合、配信期間中の IO チェックポイントは契約上不可欠で、何よりも優先されます。これを逃すと、効率ではなく納品義務に影響するためです。ユーザーに応じて優先順位を調整してください。月曜日のダイジェストしか読まないクライアントの場合、実際に対応が行われるのは週次の集計レイヤーです。

カレンダー上の順番ではなく、次の順番で各レイヤーを導入してください。

1. 日次チェック：前日の確定済み支出とペーシング比率を確認し、required_daily と adjust_spend_by を再計算します。社内ではパフォーマンスマーケターまたはグロースリードが担当し、代理店ではメディアバイヤーまたはアカウントマネージャーが担当します。
2. 週次の集計：どのアカウントの予算が過剰なペースか、低調か、計画どおりに戻ったかをまとめたアカウントダイジェストを作成し、複数アカウントを把握できず、進捗がずれているアカウントを見落とす事態を防ぎます。
3. 期間終了時の確認：契約上の約束と利用目標を照合し、配信額ではなく請求額ベースのコストで精算します。財務担当者が毎月精算します。価値は高いものの、報告対象の期間内ではもう変更できないため、上記 2 つより優先度は下がります。
4. 配信期間中の IO チェックポイント：アドオペレーション担当者が、カレンダーだけでなく保証内容に照らして挿入注文の配信状況を確認します。保証付きの買い付けだけに適用されるため、通常は最後に位置します。ただし、保証付きの買い付けでは最優先になります。

手作業で運用する場合に把握されているギャップ：

• ダッシュボードに数時間の遅延がある
• 夜間はカバーできない
• 数値が別々の画面にあるため、アカウントを横断して把握できない

そのため、日次チェックでは当日のリアルタイムデータではなく、前日の修正済み数値を確認します（ゲートチェック 6）。

出力形式

すべてのチェックを、アラートの有無にかかわらず、次の内容を含む 1 つのレポートとして作成します。

• ヘッダー（キャンペーン、日付、期間、予算、買い付けタイプ、モデル）
• 『計算方法』に記載されたすべての数式について、フラットなカーブと加重カーブを比較する指標テーブル
• ステータス行
• 抑制理由の行
• 診断
• 推奨事項
• 担当者

具体例の全体は references/pacing-report-example.md を参照してください。

ゲートによって抑制された場合も、レポートは必ず出力します。ステータスを ON PACE (deviation suppressed) とし、抑制理由を記入して、推奨事項は記載しません。修正を継続的かつ小規模に保ち、後から大幅な変更が必要にならないよう、毎日 required_daily と adjust_spend_by を再計算してください。毎日再計算する理由は、慌てた変更を減らすためです。

レポートで変更を推奨する場合は、担当者が実行および監査できるよう、次の内容を含む変更パケットとしてまとめます。

• 現在値 → 提案値
• 影響を受けるオブジェクト
• 根拠
• 不確実性を含む予想される効果
• 担当者
• 検証日
• ロールバックのトリガー

変更は、元に戻せる最小限のものを優先してください。変更する変数は 1 つにし、幅を抑えた調整にとどめ、再構築は行わないでください。重要な変更を加えるたびに、それ自体が配信をリセットするためです（ゲートチェック 5）。

失敗パターン

• 期間末の支出の駆け込み - 数値を達成するために最終日に急いで支出すると、最も悪い在庫を最も高い価格で購入することになります。加重曲線に基づいて adjust_spend_by を毎日再計算すれば防げます。
• 効率を犠牲にしたペース調整 - 支出目標を達成するために入札額や予算を引き上げるのは、支出を達成して CPA を外す典型的な方法です。水増しする前に再配分してください。
• 単日の大きな変動への過剰反応 - 単日の超過配信はプラットフォームで想定された動作です。見るべきなのは累積偏差だけです（ゲートチェック 1）。
• 初日・最終日の端数日や、分母がごく小さいケースでのアラート - これらに対処するためにゲートチェック 2 と 3 があります。
• 学習し直しの期間中に調整すること - 調整自体の変動が新たな異常として検出され、二度目の調整を招くことになります。変更をまとめ、小さく段階的に行い、様子を見てください。
• 誤ったタイムゾーン、または配信額を請求額と取り違えて照合すること - プラットフォームの請求タイムゾーンで照合し、配信額と請求額には差があることを忘れないでください。超過配信分は通常、請求されずにクレジットされます。
• ペーシング記録を不変とみなすこと - 再集計や無効トラフィックのクレジットによって過去の数値は変わります。数値に日付を記録し、エスカレーションの前に再取得してください。
• ペース内の範囲をプラットフォームのルールとして提示すること - これは明示的な慣例です。出典を誤って伝えると、その後のあらゆる数値に対するレポートの信頼性が損なわれます。

目標と測定

ペーシングレポートは、以下のすべてを満たした場合にのみ合格となります。満たすまで繰り返してください。

• 両方の曲線を計算し、加重曲線のインデックスの出典を明記する（または「有効な履歴がないためフラットのみ」と記載する）。
• すべてのアラートに、6 項目のゲートチェックの結果、列名または指標の組み合わせを明示した根拠のある診断、adjust_spend_by、担当者を含める。
• 偏差を示すアラートには、その偏差を解消する修正策を必ず含める。推奨事項は何も変更せず、引き継ぎを行う。

ペーシングの 運用 が機能しているかどうかは、期間終了時に測定できます。次の 2 つの基準で判断します。

• 期間末の駆け込み支出を行わずに、期間の利用率がペース内の範囲（ハードコミットメント予算の 95～105％をデフォルトとする慣例）に収まること：最終週の支出割合が、加重曲線の予測値から約 5 ポイント以内であること
• 誤警報率が低いこと：発報したアラートのうち、後からゲートで検出すべき配信上の影響として退けられるものが 5 件に 1 件未満であること

最終 3 日間の急増によって予算に到達した期間は、目標額を達成していてもペーシングとしては失敗です。

ハーネスに永続メモリがある場合は、アカウントの日別の重みインデックス、再調整した範囲、各アラートの結果を保存してください。そうすれば、後続のチェックで精度が上がり、最初からやり直す必要がなくなります。

プラットフォームに関する注記（任意）

ユーザーがプラットフォームを指定した場合にのみ読み込んでください。上記の基本手法はベンダーに依存しません。ゲートチェック 1 の根拠となる、文書化された配信許容範囲については references/platform-delivery-notes.md を参照してください。Google、Meta、LinkedIn、Amazon、TikTok、および DSP 固有の超過配信しきい値、日付の境界、コールドスタート期間が記載されています。具体的な数値は目安として扱ってください。プラットフォームは数値を改定することがあります。