広告運用チェックリスト｜日次・週次・月次・入稿前の確認項目
広告運用チェックリストは、確認項目を増やすための表ではありません。「いつ、誰が、何を見て、異常なら誰へ渡すか」をそろえ、担当者が替わっても同じ入口から判断するための道具です。まず、次の四つの枠をそのまま複製してください。
まず複製する、日次・週次・月次・入稿前の一覧
| 頻度 | 主な目的 | 完了時に残すもの |
|---|---|---|
| 日次 | 配信事故、費用急変、計測・LP異常を早く見つける | 取得日時、異常の有無、連絡・一次対応 |
| 週次 | 予算進捗と施策の変化を観測する | 調査事項、担当、期限、次回確認日 |
| 月次 | 目標を評価し、次月の継続・修正・終了を決める | 評価根拠、次月施策、判定指標、承認事項 |
| 入稿前 | 設定、表現、導線、権利、承認の漏れを防ぐ | 変更前後、確認者、承認記録、戻す条件 |
日次の表へ月次分析を詰め込むと、毎朝の確認が重くなります。反対に、月次の表が配信状態の確認だけでは、施策を続けるか判断できません。頻度ごとに目的を分けたうえで、各行を次の六欄で作ります。
一行は、判定基準と次の動きまで書く
チェックリストの一行は「対象」「確認方法」「正常の基準」「異常時の行動」「担当」「証跡」で作ります。単に「CPAを確認」では、どの期間と比較し、何件の成果で判断するかが分かりません。
| 欄 | 記入例 |
|---|---|
| 対象 | 一般検索キャンペーンの予算進捗 |
| 確認方法 | 前日までの確定値と月間予算表を比較 |
| 正常の基準 | 案件別の進捗レンジ内。販促予定と整合 |
| 異常時の行動 | 計測と休止状況を確認し、責任者へ調整案を出す |
| 担当 | 一次確認者と承認者を記載 |
| 証跡 | 取得日時、画面URL、判断、対応を施策メモへ保存 |
すべてを数値の閾値にする必要はありません。「公開前の商品名が含まれていない」「遷移先で申込を完了できる」など、Yes/Noで確認する項目もあります。一方、成果件数の少ない案件に固定CPAの警告値を当てると誤反応が増えます。案件別の条件を残します。
判断の背景や例外まで説明する必要がある項目は、チェック表だけで完結させず、広告運用マニュアルの作り方で紹介した手順・基準・連絡先へつなぎます。チェックリストは「確認したか」、マニュアルは「どう判断するか」を受け持つ、と分けると更新しやすくなります。
日次は、事故につながる変化へ絞る
日次確認を詳細分析の時間にすると、担当案件が増えるほど続かなくなります。配信停止、審査、急な費用変化、予算制限、計測欠損、LPの表示、緊急連絡だけを優先します。
| 日次の確認 | 見る内容 | 問題がある場合 |
|---|---|---|
| 配信状態 | 意図しない停止、審査落ち、配信先 | 原因と影響範囲を記録し、責任者へ連絡 |
| 費用 | 前日値、月間進捗、急変 | 計測・設定・需要を確認して調整案を作る |
| 成果計測 | タグ、主要成果、媒体と分析側の差 | 配信変更を急がず、計測担当へ確認 |
| LP | 表示、フォーム、主要端末 | 影響範囲を確認し、必要なら停止を相談 |
| 連絡 | 顧客からの休止・変更依頼 | 対象、期限、承認者を確認して対応 |
異常を見つけた人が、すべてを一人で直す必要はありません。広告設定、計測、LP、顧客連絡の担当を分け、緊急度と連絡先をチェック表からたどれるようにします。
毎日同じ警告が出るなら、無視を習慣化する前に基準を見直します。正常な季節変動まで異常扱いしているのか、根本対応が終わっていないのかを切り分けてください。
週次と月次は、頻度ごとの判断を混ぜない
週次では、予算進捗、主要KPI、検索語句や配信面、広告別の差、直近施策、未完了ToDoを確認します。短期の変動だけで月間評価を決めず、追加で調べる内容と小さな調整案を残します。
月次では、目標と実績、媒体・キャンペーン別の寄与、施策履歴、広告主側の出来事、継続・修正・終了する施策、次月予算、顧客の承認事項を確認します。週次メモを入力にすれば、月末に出来事を思い出す作業を減らせます。
| 頻度 | 完了条件 |
|---|---|
| 週次 | 調査事項、担当者、期限、次回確認日が決まった |
| 月次 | 評価の根拠、次月施策、判定指標、必要な承認がそろった |
チェック後に何も残らなければ、確認した事実を次回へ使えません。問題なしの場合も、取得日時と確認者を記録します。
複数案件で同じ項目を使う場合も、警告値や承認者まで一律にしないでください。共通の書式と案件固有の条件を分ける考え方は、広告運用を標準化する方法で詳しく整理しています。
入稿前は、設定・表現・導線・承認を別の人が見る
作成者は、入力した内容を正しい前提で読みやすいため、重要な入稿は別の確認者を置きます。案件の規模やリスクに応じ、二者確認が必要な変更をあらかじめ定めます。
| 分類 | 入稿前の確認項目 |
|---|---|
| 設定 | アカウント、キャンペーン、期間、予算、入札、地域、年齢、配信面 |
| クリエイティブ | 商品名、価格、注記、画像、動画、CTA、ブランド表現 |
| 導線 | URL、パラメータ、表示、フォーム、計測、端末別動作 |
| 権利・法令 | 素材の利用範囲、広告規制、媒体ポリシー、必要な注記 |
| 承認 | 顧客承認、社内承認、変更理由、公開日時、戻す条件 |
変更前後の画面と承認記録を残します。Google広告では変更履歴から、誰がいつどのような変更を行ったかを確認できます（Google広告ヘルプ「アカウントの変更履歴について」）。媒体の履歴に顧客との合意や判断理由は含まれないため、社内記録も必要です。
Cotomuは差し戻しを案件別チェックへ変える場面で使う
具体的には、若手が資料や入稿案を作り、マネージャーの確認待ちに入る前です。チーム運用・レビューのAI伴走支援では、月次レポート、改善提案、定例資料、過去のレビューコメントから、提出前の確認観点やチェックリストの下書きを整理します。
案件Aでは価格注記、案件Bでは商談品質、案件Cでは在庫確認が差し戻しの中心なら、共通項目と案件固有項目へ分けます。AIが過去の指摘を候補として束ね、担当者が自分で一次確認します。マネージャーは重要な判断と例外へ絞ってレビューし、最終判断を行います。
利用中の管理ツールでは、担当者が閲覧できる範囲を必要な案件に限定し、編集操作は管理者と承認者が担います。チェックフローには「案件ごとの閲覧範囲」と「編集・承認権限」を別々に記載します。誰が一次確認し、誰が変更と承認を行うかを混同しないためです。異動や担当変更の際は、案件への付与と管理者の役割をそれぞれ見直します。
AIがチェック済みと判定しただけで入稿を許可する仕組みではありません。人が元資料と画面を確認し、承認記録を残す前提です。
チェックリスト自体も、事故と空振りから更新する
漏れが起きたら項目を一つ足すだけで終えず、なぜ既存項目で止められなかったかを確認します。確認方法が曖昧だった、担当が決まっていなかった、証跡へたどれなかった、緊急時に省略された、といった原因ごとに直します。
一方、三か月間一度も判断に使われず、別の項目と重複する確認は統合を検討します。項目が増え続けると、重要な警告が埋もれます。事故リスクが高いものを上へ置き、参考確認は別欄へ分けます。
更新者、更新日、変更理由、適用案件を残します。現場の誰かが気づかないまま書式だけ変わると、新旧のチェック表が混在するからです。
この見直しは、確認作業そのものを減らす機会にもなります。毎回別画面から転記している項目、同じ内容を二つの表で確認している項目、判断に使われない記録を洗い出してください。広告代理店の業務効率化で整理したように、先に作業を削り、残った定型確認だけを自動取得やAIの下書きへつなぐ順番が安全です。
差し戻された一行を、六つの欄で作り直す
直近で差し戻された入稿を一件選び、原因となった項目を「対象、確認方法、正常の基準、異常時の行動、担当、証跡」の六欄へ書き直します。
別の担当者にその一行だけを渡し、同じ資料から同じ判定へ進めるか試してください。質問が出た箇所を具体化し、必要な画面や承認記録へリンクします。AIを使う場合も、過去の差し戻しを分類して候補を出すところまでとし、基準の採用と配信可否は人が決めます。こうした役割分担を含む全体像は、広告代理店のAI活用・DX入門でも説明しています。
一行を実際に使って直し、その後に日次、週次、月次へ横展開することが、形だけではない広告運用チェックリストを作る最短の方法です。
次に読む