マーケティングPDCAの自動化を設計する方法|AI分析・承認・記録の進め方
計画と実行までは進んでも、データを見て次の手を決めるところで止まってしまう。マーケティングのPDCAでは、こうした運用上の詰まりを一つずつ解消する必要があります。この記事では、AIを使った分析補助と定期処理を組み合わせ、確認と改善を続けるための設計を整理します。
この記事でわかること
- マーケティングのPDCAが止まる箇所の切り分け方
- 手動でAIを使う「高速化」と定期起動する「自動化」の違い
- Planで決める仮説・KPI・見直し条件
- マーケPDCAを自動化する4ステップと、委譲・承認の境界
- 分析補助プロンプトと、定期取得・承認・記録の設定項目
まずは一つのデータ源と施策に絞り、何を測り、どの条件で判断するかを決めます。本記事の初期運用例では、取得・一次分析・提案を定期処理にし、実行は人が承認して判断記録を残します。この記事は、その運用設計と分析用プロンプトをまとめたものです。個別ツールの接続や実行処理は利用環境に合わせた設定・実装が必要で、プロンプトを貼るだけで定期運用が完成するわけではありません。
マーケティングのPDCAが止まる箇所を切り分ける
PDCAが止まったら、計画・実行・計測・確認・意思決定のどこで詰まっているかを調べます。Check(評価)やAct(改善)が後回しになる場合もあれば、担当者や権限が決まっていない、計測が壊れている、判断に必要なデータが足りない場合もあります。原因を一つに決めつけず、作業記録とデータを確認しましょう。
PDCAは、Plan(計画)・Do(実行)・Check(評価)・Act(改善)を繰り返す改善の枠組みです。小さく試した結果を確認し、学んだことを次の計画へつなげます。定義と手順はASQのPDCA解説でも確認できます。本記事では、マーケティング施策の分析・改善案の作成をAIで補助する運用に当てはめます。
計画段階で目標や測り方が曖昧だと、結果が出ても評価しにくくなります。ただし、基準を決めた後も、計測漏れ、成果の反映待ち、実行量の不足、承認の停滞などを確認する必要があります。計画の良し悪しだけで運用や成果は決まりません。
最初に「計画した施策を実行できたか」と「評価できるデータがあるか」を分けます。KPIが動かないことだけでは、施策が効かなかったとは判断できません。
| 状態 | 確認すること | 次の手 |
|---|---|---|
| 実行できていない | 担当・期限・権限・作業量 | 詰まりを解消し、繰り返す作業を自動化候補にする |
| 実行したが評価できない | 欠測・反映遅延・件数・比較条件 | 計測を直す、追加データを待つなど、判断を保留する |
| 評価できるが目標未達 | 仮説・実行内容・外部変化 | 原因候補を検証し、継続・変更・停止を選ぶ |
改善策は詰まっている工程に合わせます。分析が負担なら定期処理、判断が曖昧なら基準の整理、承認待ちなら責任者と期限の設定、計測不備なら取得処理の修正が先です。
「高速化」と「自動化」は違う
AIによる作業の高速化と、定期処理による自動化は分けて考えます。手動で試して分析内容を確かめ、その後に繰り返す工程を自動化すると、どこに人の確認が必要かを把握しやすくなります。作業頻度や負担が小さければ、手動運用を続ける選択もあります。
高速化は、たとえばChatGPTにデータを貼り付けて分析を頼む、レポートを下書きしてもらう、といった使い方です。一つひとつの作業は速くなりますが、「データを集める」「AIに頼む」「結果を見る」という起点は、結局すべて人の手です。人が忙しくなれば、そこで止まります。
この記事でいう自動化は、取得・一次分析・提案の処理を、設定した時刻や条件で開始できる状態です。定期起動とは別に、接続の保守、失敗の検知、結果の確認、実行を委ねる範囲と承認条件の設定が必要になります。
| 手動でAIを使う高速化 | 定期処理による自動化 | |
|---|---|---|
| 処理の起点 | 人がデータを渡す | 設定した時刻・条件で起動する |
| 減らす作業 | 集計や下書きの作成 | 繰り返す取得・分析依頼 |
| 担当者が不在のとき | 開始されない | 処理は起動するが、承認待ちや失敗は残る |
| 人の役割 | 入力と結果の確認 | 監視・保守・承認・結果の確認 |
💡 Tip: 定期起動できることと、運用が続くことは別です。失敗通知の受け手、確認する時間、担当不在時の引き継ぎ先まで決めておきましょう。
P(計画)で仮説・KPI・見直し条件を決める
Planでは、結果を評価するための基準を用意します。戦略から導いた仮説、目標KPI、見直し・停止の条件を着手前に書いておきましょう。計画は成果を保証するものではなく、実行後に何を学び、どこを変えるかを判断するための出発点です。
Checkでは、想定と実際の違いを確認します。Actでは、その違いを踏まえて継続・変更・停止・追加調査を選びます。計画時に置いた基準も、データの定義や事業条件が変わった場合は、変更理由を残して見直します。
戦略に基づいた仮説を持つ(白紙でPDCAを回さない)
誰に(WHO)・何を(WHAT)・どう届けるか(HOW)から、「この施策でどの行動が変わると考えるか」を仮説にします。仮説は因果関係の証明ではありません。予測と結果の違いを確かめるために、施策以外に結果を変えそうな要因も記録します。
記入する型は「【対象と課題】に対して【施策】を行うと、【行動】が変わり、【KPI】が改善すると考える。理由は【根拠または仮定】。確認方法は【比較条件と評価時点】」です。数値目標は過去データや事業上の必要水準から置き、予測と実績を混ぜないようにします。
戦略そのものの組み立て方はWHO-WHAT-HOWフレームワークの実践ガイドで整理しています。PDCAのPは、この戦略を具体的な仮説に翻訳する工程だと考えるとつながりが見えます。
なお、名前の似た「WHY-WHAT-HOW」とは目的が異なります。両者の使い分けはWHO-WHAT-HOWとWHY-WHAT-HOWの違いで確認しておくと、仮説の立て方がぶれません。
何を測るか(KPI設計)
KPIは、指標名だけでなく定義・計算式・取得元・対象期間・目標・責任者まで決めます。たとえばフォーム改善を扱うなら、完了数と「完了数÷フォーム到達数」を組み合わせ、重複や社内アクセスの扱いもそろえます。これは指標設計の例であり、改善実績を示すものではありません。
ここで2つ、外せない原則があります。
- 途中の行動と最終成果を組み合わせる — CTRやフォーム到達率などは、成果より早く変化を確認する候補になります。ただし、先行して動いたことは原因の証明ではありません。どの成果を予測する指標なのかを仮説として置き、関係が続くかを確認します。確認頻度は、データの更新頻度と顧客の検討期間に合わせます。
- 事業上の目的とのつながりを確認する — PVやフォロワー数にも認知・到達の評価として役割がありますが、それだけで売上への貢献は判断できません。目的に応じて問い合わせ・購入・継続などの結果と合わせて確認します。
主目標と補助指標を分け、補助指標だけが良くなった場合の扱いも決めます。たとえば到達数が増えても完了率が下がった場合は、流入元や対象者の構成が変わっていないかを調べます。
関連記事
AIでマーケティング戦略を立てる方法|準備・検証・施策選びの手順
記事を読む撤退ラインを先に決める
見直しの条件と、直ちに止める条件を分けます。目標未達は、件数不足や計測遅延がないか確認してから継続・変更・停止を判断します。一方、費用上限の超過、誤配信、計測障害などは、成果の評価期間を待たず停止・調査する条件として決めておきます。
撤退ラインとセットで、Plan B(次の打ち手)も用意しておきます。「主力施策が空振りしたら、次はどこに予算を振り替えるか」まで決めておくと、撤退がそのまま次の一手につながります。やめて終わり、にしないための準備です。
観測期間はチャネル名だけでは決められません。次の条件を確認し、評価できる時点と、評価できない場合に見直す日を計画に記入します。
| 確認する条件 | 期間・判断への反映 |
|---|---|
| 購買や商談までの時間、計測の反映遅延 | まだ結果が反映されていない期間を、未達の確定値として扱わない |
| 比較期間の長さ・曜日・季節性・施策変更 | 条件をそろえるか、違いを分析上の制約として記録する |
| 件数と率の分母、判断したい差の大きさ | 評価に十分な情報があるかを確認し、不足なら結論を保留する |
| 費用上限・運用上の異常 | 成果の評価を待たず止める条件を別に設定する |
たとえば問い合わせ数が少なく、商談結果も未確定なら、経過日数だけで施策の成否を決めず「観測継続」と記録します。その場合も、次の確認日と追加費用の上限を決め、無期限に続けないようにします。
⚠ 注意: 欠測はゼロとは異なります。取得できなかった日や未確定の成果をゼロで埋めて比較せず、復旧や再取得を優先してください。確認に必要な期間と、損失を抑える停止条件は分けて管理します。
仮説・KPI・見直し条件が整理できたら、繰り返す作業を自動化します。自動化してからも、判断に使うデータの品質と運用体制を点検します。
マーケティングPDCAを自動化する4ステップ
ここでは「①取得と検証 → ②一次分析 → ③改善候補の作成 → ④承認・実行記録と次回への反映」の4ステップで設計します。①〜③は定期処理の候補です。この初期運用例の④では、人が提案を確認し、承認した内容を実行・記録します。

それぞれ、AIに任せる部分と人が関わる部分を整理します。
- 取得と検証 — 対象データ源を一つ選び、必要な権限で取得します。取得時刻・対象期間・行数・エラーを保存し、欠測や重複がないか確認します。検証に失敗したデータは分析へ送らず、担当者へ通知します。
- 一次分析 — 同じ定義・期間・対象で比較し、件数、率の分母、変化量を整理します。集計・計算結果は元データと照合し、AIの説明だけで異常や有意差を確定しません。
- 改善候補の作成 — 変化に対する複数の要因仮説と、その確認方法を出します。追加調査や判断保留も候補に含め、想定効果を実績として扱わないようにします。
- 承認と記録 — 責任者が採用・却下・保留を決め、理由・担当・実行日・次回確認日を残します。次回は承認済みの変更と実行状況も入力し、結果を比較します。
この初期運用例では、接続・検証できた処理を定期化し、予算や配信、公開内容を変える前に責任者が確認します。運用を検証できた後は、あらかじめ許可した低リスクの処理を自動実行へ移すことも検討できます。
AIへ委ねる範囲と承認条件を決める
AIには、集計だけでなく、戦略の選択肢、優先順位、継続・変更・停止の判断案も任せられます。本記事では出力を確かめる初期運用として、人が実行を承認する構成を採っています。これは固定の役割分担ではありません。委譲範囲は、処理の影響、元に戻せるか、データの品質、検証結果に応じて決めます。
誤った集計や不十分な仮説を実行につなげると、費用や顧客対応へ影響します。低リスクの処理を委譲する場合も、許可する操作、対象、費用・回数の上限、停止条件、記録先、戻す方法を先に決めます。たとえば検証済み集計の定期保存や社内向け分析メモの下書きは、許可範囲を限定して自動化を試せます。
⚠ 注意: AIの判断案ができたことと、実行権限を与えたことは別です。許可範囲を超える変更、上限超過、データ不備などは処理を保留し、承認者へ渡すようにします。本記事の初期運用例では施策の実行を都度承認とし、後から委譲範囲を広げる場合も境界を記録します。
承認者は、提案に必要な材料があるかも確認します。条件がそろっていなければ「追加調査」や「保留」を選びます。承認待ちが続く場合は、自動化の範囲を増やす前に、確認の頻度と担当を見直します。
関連記事
AIマーケターでできること|調査・企画・制作・分析の具体例
記事を読む週次レポートの入力から、次の行動までを一件で見る
自動化する前に、手動で同じ入出力を確かめます。以下は説明用の架空データと、編集部が作った報告例です。実際の運用成績やAIの実出力ではありません。Google Search Consoleなどで集計した、一つのページ・同じ検索条件の週次比較を想定します。

期間,表示回数,クリック数,変更記録
前週,10000,200,変更なし
今週,12000,180,週初にタイトルを変更
分析担当には、この表と「タイトル変更後に何を確認すべきか」という問いを渡します。期待する報告は次のような内容です。
確認できた変化:表示回数は20%増、クリック数は10%減。CTRは前週200÷10,000=2.0%、今週180÷12,000=1.5%で、0.5ポイント低下した。
まだ分からないこと:表示された検索語や掲載順位の構成が変わっている可能性がある。タイトル変更がクリック減の原因とは、この集計だけでは言えない。
次に確認すること:同じ検索語・端末・国で比較し、表示の増えた検索語と順位を確認する。そのうえで、タイトルが読者の疑問に答えているか見直す。
ここから人が「まず検索語別に調べる」と決めたら、次回へ渡す記録を残します。調べる前に、AIが自動でタイトルを戻す流れにはしません。
判断:タイトルの再変更は保留。検索語別の変化を先に調べる。
担当:記事担当者
期限:次回の週次確認まで
必要データ:同じ期間の検索語・端末・国別の集計
実行記録:取得したファイルと日時、比較条件を残す
次回の問い:既存の主要検索語でもCTRが下がったか。
不足時:結論を保留し、取得できない項目を担当者へ報告する。
取得失敗を「成果ゼロ」にしない
今週のクリック数が空欄なら、0として計算せず、取得状態を確認します。0件の実績と、接続失敗で数値がない状態は違います。今週の集計が未完成なら、分析結果は「データ不足で保留」とし、再取得または人への確認を次の仕事にします。
また、検索クリック180件と資料申込3件が別々の集計にあっても、同じ対象者をつなげられていなければ、3÷180をこの記事の申込率とは呼べません。集客、記事内の遷移、申込はそれぞれの定義で記録し、接続できる範囲だけファネルとして評価します。
この入力・報告・判断記録を手動で確認した後、既存の取得処理と定期実行へつなぎます。毎週の実行には対象期間の識別子を付け、同じ週の再実行で重複した通知や施策が発生しないようにします。
AIの実出力と修正箇所も見たい場合は、SEOレポート自動化をAIで試した実例を参照してください。前回の判断を引き継ぐ場面と、データ不足で結論を保留する場面を、入力から追えます。
AIでPDCAの分析を補助するプロンプト集
以下は、データ要約・要因仮説・改善候補を順に作る手動用プロンプトです。データを貼って実行するだけでは定期自動化になりません。まずこの手順で出力を確認し、定期運用する場合は、取得・検証・起動・保存・通知を別途つなぎます。
① データの要約と異常検知
あなたはマーケティングの分析補助者です。次の入力を確認してください。
- 指標の定義・計算式・取得元、今回と比較対象の期間・タイムゾーン:[記入]
- 対象・除外条件、各指標の値、率の分子と分母、目標:[記入]
- 欠測・未確定値・反映遅延、施策や計測設定の変更:[記入]
最初に比較条件がそろっているかを確認し、不明な定義や欠測を列挙してください。
欠測をゼロで補完せず、定義・期間・対象が異なる数値はそのまま比較しないでください。
比較可能な指標だけ、元の値・件数・分母とともに変化を整理してください。
率の差はパーセントポイント、相対変化は増減率として区別し、分母ゼロの場合は算出不可にしてください。
目標との差、確認が必要な変化、判断保留の理由を分けて出してください。件数不足や偶然変動の可能性を残し、統計検証なしで有意差・原因を断定しないでください。
② 要因の仮説出し
入力:①の比較可能な結果・未確認事項、Planの仮説、施策の実行記録、外部変化。
観測された事実と推測を分け、計測上の問題、施策側の変化、対象構成や季節性などの要因候補を挙げてください。
各仮説に、支持する材料・反する材料・追加で必要なデータ・確認方法を添えてください。
前後差や相関だけで因果を確定しないでください。材料が足りない場合は原因不明とし、存在しないデータや顧客の声を作らないでください。
③ 次アクションの提案
入力:①②の結果、戦略仮説、KPIの定義と目標、観測条件、費用上限・停止条件。
改善候補を必要な数だけ提案してください。追加調査・観測継続・停止も選択肢に含めてください。
各案に、狙い、根拠、未確認事項、必要作業、担当候補、費用への影響、確認日を添えてください。
期待する変化は予測として示し、根拠のない効果量・実績を作らないでください。
採用・却下・保留の判断案と理由を示し、承認者が判断を記入できる形で返してください。この初期運用では実行権限は与えていません。実行せず、実行後に確認すべき指標と戻す条件も示してください。
AIには目標だけでなく、データの定義、制約、実行記録を渡します。それでも解釈や計算が正しいとは限らないため、元データとの照合を行います。分析の前提と未確認事項も一緒に保存しておくと、次回の判断を追いやすくなります。
このプロンプトは、AIに判断案まで作らせ、人が確認する初期運用を想定しています。判断案の作成と実行権限の委譲を分け、許可していない処理は実行させません。低リスクの実行を後から委ねる場合は、許可範囲と承認が必要になる条件を運用設定にも反映します。

関連記事
ChatGPTのマーケ戦略が「浅い・ありきたり」になる理由|型(WHO/WHAT/HOW)で自社専用にする方法【2026】
記事を読む「やりっぱなし」を「回り続ける」に変える
定期運用へ進む前に、次の設定表を埋めます。例として「問い合わせフォームの集計を定期取得し、改善候補を担当者が承認する」運用を考えます。これは構築時の設計例であり、MyMarketer単独で実装済みの機能や導入成果を示すものではありません。
| 設定項目 | 記入・確認する内容 |
|---|---|
| 仮説とKPI | どのフォーム変更がどの行動を変えるか。到達数・完了数・完了率の定義と除外条件を記録する |
| 取得元・保存先 | 利用中の解析サービスの取得方法、対象ID、読み取り権限、保存先を決める。取得日時と対象期間を保存する |
| 定期起動 | 更新時刻・計測遅延を踏まえた実行日時とタイムゾーン、実行担当アカウントを設定する |
| 取得後の検証 | 期間・定義・行数・欠測・重複を検査。不合格なら分析を保留し、再取得または担当者確認へ回す |
| 分析と提案 | 検証済み集計、仮説、前回の承認・実行記録を入力。出力と入力の参照先を同じ実行IDで保存する |
| 通知・承認 | 通知先、承認者、確認期限を指定する。期限超過は再通知し、未承認の施策は実行しない |
| 実行・次回確認 | 採否・理由・担当・実行日時・費用・次回確認日を記録する。保留なら不足資料と再確認日を残す |
| 失敗時の扱い | 接続切れや取得失敗を通知し、再試行回数と停止条件を決める。同じ実行IDで重複提案・重複実行しない |
Google Apps Scriptを使う構成なら、実装した取得・検証処理を時間主導のトリガーで起動できます。トリガーの実行権限や失敗通知はGoogle公式のインストール型トリガーの説明で確認してください。トリガーだけでは解析サービスやAIとの接続は完成せず、それぞれの接続処理と利用条件の確認が必要です。
本番運用前に手動実行し、正常なデータが保存・分析・通知されること、欠測時に提案が保留されること、未承認の案が実行されないこと、同じ期間を再取得しても記録が重複しないことを確認します。定期起動後も実行履歴を確認し、失敗や通知漏れを担当者が追える状態にします。
MyMarketerの利用を検討する場合も、自社で必要な取得元・定期実行・分析・承認・記録が、どこまで提供範囲に含まれるかを確認してください。本記事の設計全体が一つのサービスで完結するとは限りません。対応していない工程は、既存の解析・自動化環境や担当者の作業で補う前提で構成を選びます。
なお、この自動化の出発点になるのが、施策の前段にある戦略と提案です。何をPDCAで回すのかが定まっていないと、自動化しても回す対象が曖昧なままになります。施策を提案書に落とす工程はマーケティング提案書の作り方で、AIマーケティングに使えるツールの全体像はAIマーケティングツールの比較でまとめています。
よくある質問(FAQ)
Q. マーケティングのPDCAは何から自動化すればいいですか?
繰り返し負担が大きい工程から選びます。データ取得を自動化する場合は、一つの取得元とKPIに絞り、権限・保存先・定期起動・欠測検知・失敗通知を設定します。取得結果が管理画面と一致するかを確認してから分析につなぎます。
Q. AIにPDCAを全部任せても大丈夫ですか?
AIには取得・分析だけでなく、戦略や施策の判断案も任せられます。本記事は初期運用として施策実行を人が承認する構成ですが、検証済みの低リスク処理は事前に範囲を定めて委譲する選択もあります。上限超過、許可範囲外、データ不足のときは停止・保留して承認者へ戻し、判断と実行結果を記録します。
Q. PDCAが続かないのですが、どうすれば回りますか?
まず、未実行・計測不備・情報不足・分析負担・承認待ちを切り分けます。仮説とKPIを明確にするだけでなく、担当・確認期限・失敗通知・次回の記録まで決め、止まっている工程から改善します。
Q. 高速化と自動化はどちらを先にやるべきですか?
まず手動のプロンプトでデータと出力を確かめ、繰り返す必要がある処理を定期運用へ移すと検証しやすくなります。必要な頻度や作業量によっては手動でも構いません。定期化するときは、起動だけでなく監視・承認・記録も設定します。
まとめ:速く回すより、正しく回り続ける
PDCAの自動化では、仮説・KPI・見直し条件を整理し、止まっている工程を切り分けます。分析用プロンプトを手動で使う段階と、取得・検証・分析・通知を定期起動する段階を分けて設計しましょう。
先行する指標の変化を原因と決めつけず、欠測、分母、比較条件、成果の反映遅延を確認します。初期運用ではAIの判断案を人が確認し、その理由と実行結果を次回へ渡します。委譲範囲を広げても、許可範囲外の処理を保留する条件と記録を残し、改善の過程を追えるようにします。
最初は一つの施策とデータ源で試し、正常時だけでなく取得失敗や承認待ちも確認してください。運用負担と判断に必要な情報を見ながら、扱う指標と自動化の範囲を広げます。
自社のデータ接続や担当分担まで含めて運用を組みたい場合は、AIマーケターチーム構築支援の内容をご覧ください。
継続して改善を進める担当を用意するには、起動だけでなく、使う情報・権限・困ったときの報告先も決めます。AI社員の定義と、仕事を継続して任せるための準備で全体像を確認できます。
著者について

山本至人
200社以上の中小企業マーケティングを支援。WHO-WHAT-HOWフレームワークをAIに組み込んだMyMarketerの開発者。株式会社WHAT代表取締役。東京大学松尾研AI経営修了。法政大学法学部卒業。映像制作事業やDtoCアパレルブランドなど複数の新規事業立ち上げにCMOとして携わる。2023年株式会社WHAT設立。外部CMOサービスにて多くの企業のマーケティング支援を実施。東京大学松尾研AI経営修了。
- 株式会社WHAT 代表取締役
- 東京大学松尾研 AI経営寄付講座 修了
- 複数企業の外部CMOとしてマーケティング支援を実施


