1. エグゼクティブサマリー
AD Manager は、MA(マーケティングオートメーション)で生成した LP に Google 広告を自動出稿し、その効果を ABCランク分析で判定して予算配分まで導く社内サービスである。
MA 拡張 v2.0(F-11〜F-24)により、AI による LP の自動生成・出し分け・計測基盤は設計済みである。しかし広告連携(F-18)は「オーディエンスの同期」までしかカバーしておらず、広告の入稿・予算管理・効果判定・改廃の意思決定は Google Ads 管理画面での手作業に残されたままである。AD Manager はこのギャップを埋める。
KGI(2027/2末)
月1件 以上
広告経由の商談数
KGI(2027/2末)
¥20,000 以下
有効リード単価(CPL)
工数削減
▲82%
広告運用 月20h → 3.5h
広告予算
月5〜10 万円
少額開始・段階増額
初期開発費
500 万円
5.0人月(〜2027/2)
骨子は次の4点。
- LP連動の自動出稿 — LP の因子(訴求軸・業種文脈)から RSA 広告文・キーワードを自動生成し、承認フロー経由で入稿
- 計測の一気通貫 — 広告クリック →
/r/{tracking_code}→ LP 行動計測 → CV → 商談化までを既存の連結キーで1本につなぎ、商談化はオフライン CV として Google Ads へ書き戻す - ABCランク分析 — 貢献度のパレート累積で A/B/C を判定し、「A へ寄せ、C を止める」判断案を毎週機械的に提示
- ガードレール — 予算上限・除外リスト・承認なし入稿禁止を F-24 の思想で「機能として強制」
前提条件: 媒体は Google Ads 専業で開始(Meta は Phase 3)。基盤は MA 拡張と同じ Cloudflare に統一。広告予算は月5〜10万円から開始。
2. 背景と目的
2.1 現状 — 資産は揃いつつある
| 層 | 文書 | 内容 | 状態 |
|---|---|---|---|
| MA 本体(v1.2) | MA_機能仕様書 | 企業リストアップ、メール/フォーム営業、ADコード計測、GA4 連携 | 仕様確定・レビュー待ち |
| MA 拡張(v2.0) | MA_拡張機能仕様書 | AI-LP 自動生成、文脈別出し分け、ファーストパーティ計測、ベイジアン実験、横断アトリビューション | 仕様確定・レビュー待ち |
受け皿(LP)と計測(F-14)と学習(F-15)は揃う。足りないのは、そこへ水を引く「蛇口」である。
2.2 課題 — 広告チャネルの「片翼」問題
2.3 AD Manager の位置づけと目的
AD Manager は、MA 拡張の機能群(F-11〜F-24)の続きの番号(F-25〜F-31)として実装する広告運用レイヤである。独立プロダクトではなく、同一の Cloudflare 基盤・同一のデータベース・同一の連結キー(tracking_code / company_id)の上に積む。目的は次の3つ。
- プル型チャネルの確立 — プッシュ型(メール・フォーム)に、検索広告という「相手の検討タイミングを捉える」チャネルを追加する
- 意思決定の機械化 — 広告の改廃・予算配分を ABCランク分析として定式化し、毎週の運用を「判断案の承認」に変える
- 投資対効果の可視化 — 広告費を商談・受注まで追跡し、「広告に月いくら使うべきか」を経営が判断できる材料を出す
3. サービス概要
3.1 提供価値
「LP を作れば、広告が付いてくる。数字を見れば、次の一手が書いてある。」
| 利用者 | 提供価値 |
|---|---|
| マーケティング担当 | LP 公開から広告出稿までのリードタイムを日単位→分単位に短縮。入稿作業ゼロ |
| 営業(インサイドセールス) | 広告経由の高関心訪問者が既存の架電キュー(F-23)に自動投入される |
| マネジメント | 広告費→リード→商談→受注の一気通貫レポート。ABC ランクによる予算配分根拠の明示 |
| 開発・運用 | Cloudflare 単一基盤・単一デプロイ。既存 MA と運用が分離しない |
3.2 主要ユースケース
3.3 スコープ
| 含むもの | 含まないもの |
|---|---|
| Google Ads のキャンペーン〜RSA 管理と API 入稿 | Meta / LinkedIn / X への出稿(Phase 3 以降。アダプタ層のみ設計考慮) |
| LP 連動の広告文・KW 自動生成(LLM) | ディスプレイバナー等の画像クリエイティブ制作 |
| 費用・成果の日次同期、CV 書き戻し(拡張CV/オフラインCV) | SEO・オーガニック最適化(F-17 の領域) |
| ABCランク分析と運用アクション提案・実行 | 商談管理・受注管理(SFA/CRM 領域) |
| 予算管理・自動ガード、広告ガードレール(F-31) |
4. 事業計画
4.1 事業目標(KGI / KPI)
| 区分 | 指標 | Phase 1 完了時 (2026/11末) | Phase 2 完了時 (2027/2末) | Phase 3 期間 (2027年度) |
|---|---|---|---|---|
| KGI | 広告経由の商談数 | 累計1件以上(初商談) | 月1件以上 | 月2件以上 |
| KGI | 有効リード単価(CPL) | 計測可能になること | 20,000円以下 | 15,000円以下 |
| KPI | 広告経由リード数 | 月2件以上 | 月4件以上 | 月8件以上 |
| KPI | LP CVR(クリック→CV) | 1.0%以上 | 2.0%以上 | 2.5%以上 |
| KPI | 広告運用工数 | 月10時間以内 | 月5時間以内 | 月5時間以内 |
| KPI | 無駄配信率(C ランク費用比率) | 計測開始 | 20%以下 | 10%以下 |
ベンチマーク: 国内 BtoB 検索広告は CPC 300〜800円、LP CVR 1〜3%、CPL 1.5〜4万円のレンジが目安。本計画の目標はこのレンジの中位〜やや良好水準に、LP 出し分け(F-13)と ABC 運用の改善効果を織り込んで設定している。
4.2 フェーズ計画
| フェーズ | 期間 | ゴール | 主な内容 |
|---|---|---|---|
| Phase 0: 準備 | 2026/8下旬〜9月中旬 | 出稿できる状態 | MCC・アカウント開設、Developer Token 申請、CV 設計、KW 初期調査、要件確定 |
| Phase 1: MVP | 2026/9中旬〜11月 | 計測が回る状態 | 手動キャンペーンで少額出稿(月5万円)、日次同期、/r/{code} 連携、CV 書き戻し、統合レポート |
| Phase 2: 自動化 | 2026/12〜2027/2 | 判断が回る状態 | 広告自動生成・API 入稿(承認付き)、ABC エンジン、予算ガード、週次運用の定常化 |
| Phase 3: 拡張 | 2027/3〜 | 広げる状態 | 承認付き自動予算配分、P-MAX アセット連携、Meta アダプタ設計、受託横展開検討 |
4.3 開発・運用体制
| 役割 | 人数 | 稼働目安 | 担当 |
|---|---|---|---|
| プロダクトオーナー | 1 | 10% | 事業目標・予算・フェーズゲート判断 |
| 開発(フルスタック) | 1〜2 | Phase 1: 1.0人月/月、Phase 2: 0.75人月/月 | Workers/D1 実装、Google Ads API 連携、ABC エンジン |
| 広告運用担当 | 1 | 週2〜3時間 | KW 戦略、広告文レビュー、週次 ABC 承認 |
| 法務確認(スポット) | - | 都度 | 外部送信規律・個人関連情報の確認(G-09 と共通) |
4.4 費用計画
4.5 効果試算
| 項目 | 保守シナリオ | 標準シナリオ | 好調シナリオ |
|---|---|---|---|
| 平均 CPC | 600円 | 450円 | 350円 |
| 月間クリック | 167 | 222 | 286 |
| LP CVR | 1.5% | 2.0% | 2.5% |
| 月間リード | 2.5件 | 4.4件 | 7.1件 |
| CPL | 40,000円 | 22,500円 | 14,000円 |
| 商談化率 | 15% | 20% | 25% |
| 月間商談 | 0.4件 | 0.9件 | 1.8件 |
投資回収の考え方
- 商談価値: 月1商談 × 成約率25% × 平均受注粗利(仮 120万円)= 月30万円相当の粗利創出期待値
- 工数削減: 月16.5時間 × 5,000円/時 ≒ 月8万円
- 横展開価値: 受託案件テンプレートとして外販できた場合、1案件あたり数百万円規模の構築費
標準シナリオが実現すれば、開発完了から約13〜14か月(2028年度第1四半期)での回収が目安。CPL 実績が目標を下回った場合は広告予算の増額で回収を前倒しできるため、増額判断を四半期レビューに組み込む。保守シナリオに留まる場合は Phase 3 投資を縮小し、キーワード・LP の見直しを先行する。
注意: 上記は計画時点の仮定に基づく試算。成約率・受注粗利は四半期ごとに実績で置き換え、乖離をフェーズゲートでレビューする。
5. システム構成
5.1 全体アーキテクチャ(Cloudflare 統一)
MA 拡張 v2.0 の第一候補構成(Cloudflare エッジ)に AD Manager のコンポーネントを追加する。新しいインフラは増やさない。
5.2 Google Ads API 連携方針
| 項目 | 方針 |
|---|---|
| アカウント構成 | MCC(クライアントセンター)を開設し配下に自社アカウント。受託横展開時はクライアントアカウント追加のみで対応 |
| API アクセス | Developer Token は「基本アクセス」を申請(自社利用では十分)。審査1〜2週間を見込み Phase 0 で最優先着手 |
| 認証 | OAuth 2.0(リフレッシュトークン)。Workers Secrets に保管 |
| 同期 | 日次 Cron で過去3日分を洗い替え取得(媒体側の遅延確定に対応)。レポートは GAQL |
| 入稿 | すべて「一時停止」状態で作成 → 承認フロー経由で有効化(G-17) |
| レート/障害 | API 障害時は同期スキップ・翌日リカバリ。入稿は Queues のリトライに委譲 |
5.3 MA との連携(連結キーとデータフロー)
広告クリックも既存の計測リダイレクト /r/{tracking_code} に着地させる。これにより LP 出し分け(F-13)・行動計測(F-14)・アトリビューション(F-23)がそのまま広告流入にも機能する。
5.4 データベース設計(追加テーブル概要)
| テーブル | 主なカラム | 用途 |
|---|---|---|
ad_accounts | account_id, mcc_id, oauth_ref, status | 広告アカウント管理 |
ad_campaigns | campaign_id, name, budget_monthly, status, lp_experiment_id | キャンペーンと LP 実験の紐づけ |
ad_groups | ad_group_id, campaign_id, tracking_code, theme_factor | 広告グループ。tracking_code の発行単位 |
ad_keywords | keyword_id, ad_group_id, text, match_type, source | キーワード(AI 生成/手動の別を記録) |
ad_creatives | creative_id, headlines(json), descriptions(json), approval_status | RSA アセット。承認状態を持つ |
ad_daily_stats | date, entity_type, entity_id, impressions, clicks, cost, conversions | 日次成果(3日洗い替え) |
ad_conversions | gclid, tracking_code, cv_type(lead/deal), value, uploaded_at | CV 書き戻し台帳 |
ad_abc_snapshots | week, entity_type, entity_id, score, rank, action, approved_by | ABC 判定履歴(監査可能) |
ad_budget_guards | campaign_id, monthly_cap, pace_alert_at, hard_stop_at | 予算ガード設定 |
6. 機能要件(概要)
機能番号は MA 拡張 v2.0(F-11〜F-24)の続番。詳細仕様は Phase 0 で別紙「AD Manager 機能仕様書」として起こす。
| 機能ID | 機能名 | 概要 | フェーズ |
|---|---|---|---|
| F-25 | 広告アカウント・キャンペーン管理 | MCC/アカウント接続(OAuth)、キャンペーン・広告グループ・KW・RSA の一覧/作成/変更/停止 | 1〜2 |
| F-26 | LP連動広告自動生成 | LP 因子から KW 候補・RSA 広告文(見出し15/説明文4)を LLM 生成。文字数・NG 表現チェック付き | 2 |
| F-27 | 予算管理・自動ガード | 月次上限、日次ペース監視、超過アラート→自動一時停止。全体上限も保持 | 1〜2 |
| F-28 | コンバージョン計測連携 | gclid 捕捉、リード CV・商談化 CV のオフラインアップロード、CV タグ稼働監視 | 1 |
| F-29 | ABCランク分析エンジン | 貢献度スコア、パレート累積ランク判定、アクション提案生成(7章) | 2 |
| F-30 | レポーティング | 広告→LP→リード→商談の一気通貫レポート。F-23 へのデータ供給 | 1〜2 |
| F-31 | 広告ガードレール | G-16〜G-21(9.3項)。承認なし入稿禁止・除外必須・予算上限等を強制 | 1〜2 |
7. ABCランク分析仕様
7.1 分析の考え方
ABCランク分析(パレート分析)は、「成果の大半は少数の広告が生んでいる」という経験則に基づき、貢献度の累積比率で対象を A/B/C の3ランクに分類し、予算と手間の配分を決める手法である。広告運用の意思決定 OS として次のように適用する。
7.2 分析単位と貢献度スコア
ランク判定はキャンペーン/広告グループ/キーワード/クリエイティブの4階層で独立に行う。貢献度スコアは金額換算の期待値で統一する。
| 構成要素 | 単価(初期値) | 説明 |
|---|---|---|
| 商談化数 | × 120,000円 | 受注粗利期待値から設定。四半期ごとに実績で更新 |
| リード CV 数 | × 20,000円 | 商談化率 × 商談価値から逆算 |
| プロキシ成果 | × 数百円 | スクロール75%到達・CTA クリック等(F-14)。CV が少ない初期でも「LP を読ませている広告」を拾う |
7.3 最低データ量ガード(統計的な安全装置)
| ルール | 内容 |
|---|---|
| 評価期間 | 直近28日のローリングウィンドウ(週次で再計算) |
| 最低クリック数 | 30クリック未満は「判定保留(N)」。C 判定による自動停止の対象にしない |
| 新規保護期間 | 配信開始から14日間はランク対象外(Google 側の学習期間も考慮) |
| ベイズ補正 | CVR 系指標は事前分布(アカウント平均)で縮約し、少データの過大/過小評価を抑える(v2.0 統計エンジンの思想を継承) |
| 少額予算での構成 | 予算月5〜10万円の間は同時稼働の広告グループを3〜5個に絞り、1グループあたりのクリック量を確保する(評価期間は必要に応じ56日へ延長) |
| 人の上書き | 季節・在庫要因は「要因メモ」付きで上書き可(監査ログに記録) |
7.4 運用アクション(ランク → 次の一手)
LP 実験との役割分担: 「どの LP が効くか」は F-15(ベイジアン実験・バンディット)が担い、「どの広告(流入源)に金を張るか」を ABC が担う。広告グループ=tracking_code=LP 実験の文脈という対応により、両者は同じデータ基盤の上で干渉せず補完する。
7.5 判定の表示仕様
- ランクは前週からの遷移(↑↓→)付きで表示(例: 「B → A」)
- 各判定に根拠(score 内訳・クリック数・費用)を展開表示
- 承認画面は「今週の判断案」を1画面に集約し、一括承認/個別修正が可能
- 全判定・承認・実行は
ad_abc_snapshotsに永続化し、後から判断の正しさを検証できる
8. 運用計画
8.1 運用体制と RACI
| 作業 | 広告運用担当 | 開発 | PO | 法務 |
|---|---|---|---|---|
| キーワード戦略・広告文レビュー | R/A | C | I | - |
| 週次 ABC 承認・予算再配分 | R | I | A | - |
| 月次予算計画の増減 | C | I | R/A | - |
| システム監視・障害対応 | I | R/A | I | - |
| CV 設計・計測変更 | C | R | A | - |
| 外部送信・個人関連情報の確認 | I | C | A | R |
| 四半期 法令レビュー | I | C | A | R |
R=実行 / A=説明責任 / C=相談 / I=報告
8.2 運用リズム(日次・週次・月次・四半期)
8.3 インシデント対応
| インシデント | 検知 | 一次対応(自動) | 二次対応(人) |
|---|---|---|---|
| 予算超過ペース | 日次監視 | 130%ペースで自動一時停止 | 原因分析(CPC 高騰/クリック急増)→上限見直しか再開 |
| CV 計測断 | 48時間 CV ゼロ×クリック50以上 | アラート | タグ・リダイレクト・gclid 捕捉の疎通確認。計測断中は ABC 判定を自動保留 |
| 広告不承認・警告 | 審査状態チェック | 媒体側で配信停止 | ポリシー該当箇所を修正し再審査。NG 辞書に反映 |
| API 障害・同期失敗 | Cron 失敗通知 | 翌日洗い替えで自動リカバリ | 2日連続失敗で手動同期・原因調査 |
| LP 配信障害(F-13 側) | 既存監視 | - | 広告を一括一時停止(受け皿が死んでいる間の費用を止める)→復旧後再開 |
8.4 KPI モニタリングとアラート閾値
| 指標 | 閾値 | 通知先 |
|---|---|---|
| 月次予算消化ペース | 110% 警告 / 130% 自動停止 | 広告運用担当・PO |
| CPL(28日) | 目標の1.5倍超過で警告 | 広告運用担当 |
| 無駄配信率(C 費用比率) | 25%超で警告 | 広告運用担当 |
| LP 表示速度(LCP) | 2.5秒超で警告(既存 CWV 監視と共通) | 開発 |
| 品質スコア | 平均5未満の KW が費用上位に入ったら警告 | 広告運用担当 |
9. リスク・法令遵守
9.1 リスク登録簿
| # | リスク | 影響 | 発生度 | 対策 |
|---|---|---|---|---|
| R-1 | 予算の想定外消化(設定ミス・CPC 高騰) | 高 | 中 | 二重上限(キャンペーン+全体)と自動停止。入稿は必ず一時停止状態で作成 |
| R-2 | アカウント停止・広告不承認の頻発 | 高 | 低 | NG 表現チェック(景表法・最上級表現)、人の承認必須(G-17)、再審査 Runbook |
| R-3 | CV 計測の欠損(gclid 未捕捉・タグ断) | 中 | 中 | 日次監視、計測断中の判定保留、リダイレクト方式の必須化(G-15 継承) |
| R-4 | Developer Token 審査の遅延 | 中 | 中 | Phase 0 で最優先申請。遅延時は管理画面手動運用+CSV 取込で Phase 1 を先行 |
| R-5 | 低トラフィックでランク判定が回らない | 中 | 高 | 判定保留・ベイズ補正・広告グループ数の絞り込み(3〜5個)。プロキシ指標で早期シグナルを拾う |
| R-6 | 属人化(広告運用担当の離脱) | 中 | 低 | 判断ロジックのコード化(ABC)と Runbook 整備が本サービスの目的そのもの |
| R-7 | 受け皿 LP の品質不足で広告費が無駄になる | 高 | 中 | Phase 1 ゲートに LP CVR 1%以上を設定。未達なら出稿を増やさず LP 改善(F-15)を先行 |
9.2 法令・ポリシー遵守
| 領域 | 要求 | 対応 |
|---|---|---|
| 外部送信規律 (電気通信事業法 27条の12) | Google 広告タグ・リマーケティングタグによる外部送信の通知・公表 | F-24 G-07 の公表テキスト自動生成に Google Ads タグを追加。全 LP フッターからリンク |
| 個人関連情報(個情法 31条) | カスタマーマッチ(メールハッシュのアップロード)は同意確認が必要 | G-09「法務確認済み」フラグが ON になるまで機能は起動しない(F-18 と共通) |
| 改正個人情報保護法 (2026/7/17 公布) | Cookie ID 等の不適正利用禁止の強化・課徴金新設。罰則一部 2027/1/17 先行施行見込み、全面施行 2028/7/17 期限 | 四半期法令レビューで施行状況を追跡し、施行前に同意・公表文面を再点検 |
| Google Ads ポリシー | 誇大表現の禁止、リンク先要件(noindex LP でも AdsBot クロール許可が必要) | G-05(AdsBot 拒否禁止)は既存ガードレールで担保済み。生成広告文のポリシーチェックを F-26 に内蔵 |
| 特定電子メール法ほか | 広告経由リードへのメール接触は既存 MA のルールに従う | 既存 F-08 / G-12(do_not_contact)をそのまま適用 |
9.3 広告ガードレール(F-31: G-16〜G-21)
F-24 の「人の注意力に頼らず機能として強制する」方針を広告領域に拡張する。
| # | 対象 | 強制内容 | 違反時の挙動 |
|---|---|---|---|
| G-16 | 予算 | 全キャンペーン合計の月次上限を必ず設定 | 未設定では配信開始 API を拒否 |
| G-17 | 入稿 | AI 生成の広告・KW は人の承認なしに有効化できない(一時停止で作成) | 未承認は 403 |
| G-18 | 除外 | 除外リスト(CV済/既存顧客/do_not_contact)未適用のキャンペーンは配信不可 | 有効化前チェックでブロック |
| G-19 | リンク先 | 最終ページ URL は /r/{code} 形式のみ許可(計測の抜け道を塞ぐ) | 入稿バリデーションエラー |
| G-20 | 自動アクション | 自動実行は「停止・減額」方向のみ。増額は必ず人の承認 | 増額 API は承認フロー経由のみ |
| G-21 | 生成広告文 | NG 表現辞書(最上級・断定・比較優良誤認)該当案は承認画面に出せない | 生成時に自動リジェクト・再生成 |
10. スケジュール・マイルストーン
| 時期 | マイルストーン | 完了条件 |
|---|---|---|
| 2026/8 第4週 | M0: 計画承認 | 本書の経営承認、Phase 0 着手 |
| 2026/9 第2週 | M1: 出稿環境確立 | MCC・アカウント開設、Developer Token 取得、CV 設計確定 |
| 2026/9 第3週 | M2: 初回出稿 | 手動キャンペーンで月5万円の配信開始(LP は F-12 生成分) |
| 2026/10 末 | M3: 計測一気通貫 | 費用同期・gclid 捕捉・リード CV 書き戻しが自動で回る |
| 2026/11 末 | M4: Phase 1 ゲート | 統合レポート稼働、広告経由リード月2件、LP CVR 1%以上 |
| 2027/1 末 | M5: 自動入稿稼働 | F-26 承認フロー付き入稿、F-27 予算ガード自動停止 |
| 2027/2 末 | M6: Phase 2 ゲート | ABC 週次運用の定常化、CPL 2万円以下、商談月1件、運用工数月5時間以内 |
| 2027/4〜 | M7: Phase 3 着手 | 自動予算配分(承認付き)、Meta アダプタ設計、横展開判断 |
11. 今後の検討事項
- Meta 広告アダプタの詳細設計(Phase 3)— 媒体抽象化レイヤは F-25 実装時に切っておくが、Meta 固有の CV 仕様(CAPI)は別途調査
- P-MAX の扱い — アセットグループへの LP 因子供給は有望だが配信面の制御が効きにくい。Phase 2 実績を見て少額テストから
- 受託横展開の商品化 — MCC 構成のまま顧客アカウントを追加できるため、Phase 3 で「LP 生成+広告運用自動化」パッケージの外販可否を判断
- 入札戦略の自動切替 — CV 蓄積後の「目標コンバージョン単価」への切替タイミングの自動提案(当面は手動)
- ABC の粒度拡張 — 検索語句・オーディエンスセグメントレベルのランク分析(データ量が揃ってから)
- LLM コスト・品質の監視 — 広告文生成の品質評価(不承認率・CTR)をプロンプト改善にフィードバック
12. 改訂履歴
| 版 | 日付 | 内容 |
|---|---|---|
| v1.0 | 2026-08-17 | 初版作成(事業計画・運用計画) |