マーケティングオートメーションサービス 拡張機能仕様書

— AI-LP大量生成 × マルチチャネル獲得基盤 —

目次

1. はじめに
2. 発想の転換 — 本仕様の中核となる3つの考え方
3. システム全体像
4. マーケティングアプローチの全体設計
5. 機能要件 第I部 — AI-LP生成・実験基盤(F-11〜F-16)
6. 機能要件 第II部 — 新規チャネル(F-17〜F-22)
7. 機能要件 第III部 — 横断機能(F-23〜F-24)
8. 統計エンジン仕様
9. 計測仕様
10. 画面仕様(追加)
11. データベース設計(追加)
12. API設計(追加)
13. 非機能要件
14. 法令・コンプライアンス
15. 段階導入計画
16. 今後の検討事項
17. 出典

1. はじめに

1.1 背景

v1.2 で定義した本システムの獲得チャネルは メール営業(F-08) と フォーム営業(F-06) の2つに限られる。いずれも「こちらから送る」プッシュ型であり、以下の構造的な限界を持つ。

とくに 「受け皿の不在」 が最大の損失である。F-09 のADコード計測により「どの企業のどの担当者がクリックしたか」は既に取得できているにもかかわらず、その先が全社共通の1枚のページであるため、せっかくの反応が商談に転換しない。

1.2 目的

本書は、以下を目的とした拡張機能を定義する。

1. 受け皿の最適化 — AIによりLP(ランディングページ)を大量に自動生成し、相手・流入経路ごとに最適な1枚を出し分ける
2. 効果の科学的な判定 — 生成したLPのどれが効いているかを、低トラフィック環境でも意味のある形で統計的に評価する
3. チャネルの多重化 — メール・フォーム以外の獲得経路(広告/SEO/ウェビナー/資料/SNS・コミュニティ)を機能として組み込む
4. 横断的な効果測定 — 上記すべてを1つのアトリビューションモデルで比較可能にする

1.3 v1.2 との関係

• v1.2 の F-01〜F-10 は変更しない。本書の機能はすべて v1.2 の上に積む
• v1.2 の F-09(ADコード/計測リダイレクト)は本書の基盤として全面的に再利用する。tracking_code が新機能全体の連結キーとなる
• v1.2 の企業マスタ・アプローチ履歴は、そのままLPパーソナライズの入力になる
• ただし 技術スタックについては本書で別案を提示する(3.2項)。v1.2 は SQLite + 自前サーバを想定していたが、本書の機能群は Cloudflare のエッジプラットフォーム上での実装を第一候補とする

1.4 スコープ

含むもの

• LPの生成・配信・計測・実験・パーソナライズ
• 広告オーディエンス連携、SEOコンテンツハブ、ウェビナー、資料ゲート、SNS/コミュニティ運用支援
• チャネル横断のアトリビューション分析
• 上記に伴うコンプライアンス管理機能

含まないもの

• LPのデザイン制作そのもの(ブロックライブラリの初期整備は人手で行う)
• 広告の入稿・課金・クリエイティブ制作(広告媒体の管理画面側の作業)
• ウェビナーの配信基盤そのもの(Zoom等の外部サービスを利用)
• CRM/SFA としての商談管理・受注管理

1.5 用語定義(追加分)

2. 発想の転換 — 本仕様の中核となる3つの考え方

「LPを50パターン自動生成してアクセス分析する」という要望をそのまま実装すると、統計的に破綻する。本章はその理由と、代わりに何を設計するのかを先に述べる。以降の機能要件はすべてこの3つの考え方から導かれている。

2.1 なぜ「50パターン一斉A/Bテスト」は成立しないのか

2群の比率を比較して有意差を検出するのに必要なサンプル数は、有意水準5%(両側)・検出力80%のとき次式で近似できる。

n ≈ 2 × (Z(α/2) + Z(β))² × p̄(1-p̄) / (p₁ - p₂)²
  = 15.68 × p̄(1-p̄) / d²        (Z(α/2)=1.96, Z(β)=0.84)

これを本システムの現実的な数値に当てはめる。

一方、当社のLPに現実的に見込める流入は、メール営業のクリック反応・広告・SEOを合算しても 月間数千セッション の規模である。これを50バリアントに均等配分すると 1バリアントあたり月100セッション未満。必要数の 1/11 〜 1/138 にしかならない。

さらに50個を同時に検定すると多重比較問題が発生する。有意水準5%で49回の比較を行うと、すべて差がなくても「どれかが有意」と誤判定される確率は 1 − 0.95⁴⁹ ≈ 92% に達する。Bonferroni補正で α を 0.05/49 に絞ると、必要サンプル数はさらに約2.2倍に膨らむ。

結論: 「50バリアントを均等配分して、CVRの有意差で勝者を決める」設計は当社の流入規模では永久に結論が出ない。この事実を仕様の出発点に置く。

2.2 中核アイデア① — 評価を3層に分ける(50個を"検定"しない)

50個をいきなり統計検定にかけるのではなく、安いふるいから順にかける。

第1層の意味は大きい。CVRが2%のとき CV は 100セッションで2件しか出ないが、CTAクリック率は20%前後、スクロール50%到達率は40%前後あるため、同じセッション数で 10〜20倍の情報量 が得られる。

さらに第1層では Sequential Halving(逐次半減法) を用いる。全バリアントに均等配分してから下位半分を切り、残りに同じトラフィックを再配分する。第0層を通過した約20件を 20 → 10 → 5 と3ラウンドで絞れば、全バリアント同時検定に比べて必要総トラフィックを大幅に圧縮できる(具体的なラウンド設計は5.5.3項)。

2.3 中核アイデア② — バリアントを"因子の組合せ"として作る

50個をバラバラの独立したページとして生成すると、50個ぶんのデータが必要になる。そうではなく、LPを因子(変数)の組合せとして構成する。

50バリアント = 訴求軸(5水準) × 構成テンプレート(5水準) × CTA文言(2水準)

こうすると、評価の単位を「バリアント」ではなく「水準」にできる。

「どのページが勝ったか」ではなく「どの訴求軸が効くのか」「どのCTA文言が効くのか」を学習し、その組合せとして勝ちパターンを合成する。これが低トラフィックで50パターンを扱う唯一の現実的な方法である。

実装上は、水準ごとの効果を独立に推定するのではなく、階層ベイズ(部分プーリング) を用いる。データの少ない水準の推定値を全体平均へ引き寄せることで、少数サンプルでの過大評価を防ぐ。

2.4 中核アイデア③ — 「勝者を1つ選ぶ」のをやめる(相手ごとに出し分ける)

ここが本仕様のもっとも新しい部分である。

一般的なLPOツールは「全訪問者にとって最良の1枚」を探す。しかし本システムは訪問者が誰かを知っている。v1.2 の F-09 で、メール本文のURLは https://{本システム}/r/{tracking_code} に置換されており、tracking_code から 企業ID・業種・都道府県・企業規模・アプローチ履歴・テンプレートID が一意に引ける。

つまり本システムは、一般的なLPOツールが持ち得ない 「訪問者の企業属性を事前に知った状態でLPを描画できる」 という決定的な優位を持つ。

したがって最適化の目的関数を次のように変える。

一般的なLPO   : argmax_v  CVR(v)                    … 全体で最良の1枚
本システム    : argmax_v  CVR(v | context)          … 文脈ごとに最良の1枚
                context = {業種, 都道府県, 企業規模, 流入チャネル, アプローチ回数, 過去の反応}

これは コンテキスチュアル・バンディット(文脈付き多腕バンディット) と呼ばれる定式化である。50バリアントは「1つの勝者を決めるための候補」ではなく、「文脈に応じて配るための引き出し」 になる。50個作る意味がここで初めて生まれる。

さらに、狙いを定めた重点企業に対しては、バリアントの選択ではなく 企業名を差し込んだ専用LP(ABM-LP) を自動生成する(F-16)。

一般企業   → 50バリアントから文脈マッチで1枚を選択
重点企業   → その企業のためだけの1枚を生成(社名・業種課題・類似実績を差し込み)

2.5 3つの考え方のまとめ

3. システム全体像

3.1 機能マップ

┌─────────────────────────────────────────────────────────────────────┐
│                    既存 (v1.2 / F-01〜F-10)                          │
│  企業リストアップ  連絡先抽出  CSV取込  アプローチ管理                  │
│  メールTPL  フォームTPL  分析  SendGrid送信  GA連携  環境設定           │
└───────────────────────────────┬─────────────────────────────────────┘
                                │ 企業マスタ / tracking_code / アプローチ履歴
                                ▼
┌─────────────────────────────────────────────────────────────────────┐
│              第I部  AI-LP生成・実験基盤 (F-11〜F-16)                   │
│                                                                     │
│   F-11 ブロックライブラリ ──▶ F-12 AI LP生成(50) ──▶ F-13 配信エンジン │
│                                      │                    │          │
│                                      │                    ▼          │
│                              F-16 ABMパーソナライズ   F-14 行動計測   │
│                                      │                    │          │
│                                      └────────────────────┤          │
│                                                           ▼          │
│                                              F-15 実験統計エンジン    │
└───────────────────────────────┬─────────────────────────────────────┘
                                │ LP・計測基盤を共用
                                ▼
┌─────────────────────────────────────────────────────────────────────┐
│                  第II部  新規チャネル (F-17〜F-22)                    │
│  F-17 SEOコンテンツハブ   F-18 広告オーディエンス連携                  │
│  F-19 ウェビナー運用      F-20 資料ゲート/ナーチャリング               │
│  F-21 SNS・コミュニティ   F-22 匿名訪問企業推定(オプション)            │
└───────────────────────────────┬─────────────────────────────────────┘
                                ▼
┌─────────────────────────────────────────────────────────────────────┐
│                  第III部  横断機能 (F-23〜F-24)                       │
│  F-23 チャネル横断アトリビューション   F-24 コンプライアンス・ガードレール │
└─────────────────────────────────────────────────────────────────────┘

3.2 技術構成 — 2案の比較

v1.2 では「SQLite + 自前APIサーバ + ジョブキュー」を想定していた。本書の機能群、とくに LPの配信 は次の要求を持つため、この構成では不利になる。

• 表示速度: LPのCVRは表示速度に直結する。LCP 2.5秒以下(良好判定)を全国どこからでも満たす必要がある
• リクエスト単位の出し分け: 訪問者ごとにバリアントを選び、その場で描画する
• スパイク耐性: 広告出稿やメール一斉送信の直後にアクセスが集中する
• 書き込みの並列性: 行動計測イベントは1セッション20件以上発生する。SQLiteの単一ライタでは詰まる

そこで Cloudflare のエッジプラットフォーム を採用する。適用範囲について2案を提示する。詳細な手順は別冊『CloudFlare構築・運用手順書』を参照。

案A: 部分適用(新機能のみ Cloudflare)

[既存MA本体]                        [新設: Cloudflare]
 Node.js/Python API      ──API──▶   Workers (LP配信 + 計測API)
 SQLite                              D1 (LP・実験・イベント集計)
 ジョブキュー                         R2 (画像・生成物)
 管理画面                            Workers AI / AI Gateway (生成)
                                     Analytics Engine (生イベント)
                                     Durable Objects (バンディット状態)

案B: 全面移行(MA本体ごと Cloudflare)

[Cloudflare 単一構成]
 Workers (Static Assets)  … 管理画面SPA + API + LP配信を1デプロイ単位で
 D1                        … 企業・アプローチ・LP・実験のすべて
 R2                        … 添付・エクスポート・LP画像
 Queues / Workflows        … リストアップ・抽出・送信・生成の非同期処理
 Cloudflare Access         … 管理画面の認証(自前ログイン実装が不要になる)
 Browser Rendering         … フォーム営業のヘッドレスブラウザ処理
 Cron Triggers             … GA同期・統計再計算

判断の指針

本仕様書の機能要件は どちらの案でも実装できる よう、実装技術に依存しない形で記述する。Cloudflare 固有の実装手段は各機能の「実装メモ」に補記する。

3.3 データフロー(LP関連)

 ① 生成                ② 配信                    ③ 計測              ④ 学習
┌──────────┐      ┌─────────────────┐      ┌──────────┐    ┌──────────────┐
│ 因子・水準  │      │ /r/{code} 着地   │      │ view      │    │ 第0層 事前     │
│ ブロック    │─┐   │   ↓ 企業を特定    │      │ scroll    │    │ 第1層 逐次淘汰 │
│ プロンプト  │ │   │   ↓ 文脈を構築    │─────▶│ cta_click │───▶│ 第2層 ベイズ   │
└──────────┘ │   │   ↓ バリアント割付 │      │ form_*    │    │       ↓        │
              ├──▶│   ↓ エッジで描画   │      │ cv        │    │ 配信重みを更新  │
┌──────────┐ │   └─────────────────┘      └──────────┘    └───────┬──────┘
│ LLM       │─┘             ▲                                          │
│ (生成)     │                └──────────────────────────────────────────┘
└──────────┘                        重みは KV 経由で即時反映

4. マーケティングアプローチの全体設計

4.1 チャネル俯瞰

メール・フォーム以外の手法を、相手の検討状態の軸で整理する。本システムが押さえるべきなのは、既存2チャネルが空白にしている「①潜在」「②情報収集」の層である。

4.2 チャネル別の実務ベンチマーク

社外の公開値である。数値は出典元により幅が大きく、当社の実測で置き換えることを前提とした初期値として扱う。

X/LinkedInのオーガニック運用、YouTube・Podcast、パートナー経由売上比率については、業界横断の定量的な公開データが見当たらなかった。 これらは「認知・信頼構築」目的として位置づけ、KPIは当社の実測で定義する(F-21)。

4.3 自動化できる範囲・できない範囲

新チャネルを機能化する際、MAが自動化できるのは「配管」であって「中身」ではない。この線引きを最初に固定する。

5. 機能要件 第I部 — AI-LP生成・実験基盤(F-11〜F-16)

5.1 F-11 LPブロックライブラリ・因子定義

5.1.1 概要

LPを1枚の塊としてではなく、再利用可能なブロックの積層として管理する。AI生成の品質と安全性は、このライブラリの整備度で決まる。「AIに自由に作らせる」のではなく「AIには決められた枠の中を埋めさせる」という設計思想である。

5.1.2 ブロック種別

5.1.3 因子(Factor)と水準(Level)の定義

バリアント生成は 因子の直積 で行う(2.3項)。因子はユーザーが定義でき、既定として以下を用意する。

バリアント数 = 各因子の水準数の積。既定では 5 × 5 × 2 = 50 となり、要望の「50パターン」を満たす。因子・水準を増減すればバリアント数は自動で変わる。

設計上の要点: 上限を50に固定しない。ただし「有効バリアント数 ≦ 100」の上限を設ける(それ以上は第0層スクリーニングの前段で機械的に間引く)。

5.1.4 入力

5.1.5 処理仕様

1. ブロックはサーバ側でのみ結合される。クライアントに未使用ブロックを送らない(表示速度とCWVのため)。
2. デザイントークンはCSS変数として単一のスタイルシートに集約し、全バリアントで共有する。バリアント間でCSSは変わらない(=キャッシュが効く)。
3. ブロックテンプレートには差込変数({{company_name}} {{industry}} {{case_title}} 等)を定義でき、F-16のパーソナライズで使用する。
4. ライブラリはバージョン管理する。実験実行中のライブラリは変更をロックし、変更時は新バージョンを作成する(実験の途中でページが変わると計測が無効になるため)。

5.1.6 制約

• ブロックのHTMLは許可タグのホワイトリスト方式で検証する(<script> は不可)。
• 1バリアントあたりのHTMLサイズ上限 200KB(gzip前)。超過時は生成をエラーとする。
• 外部CDNの読み込みを禁止する(LCP悪化とプライバシー上の理由)。フォント・アイコンは自己ホストする。

5.2 F-12 AI LPパターン自動生成

5.2.1 概要

因子の組合せごとにLLMでコピーを生成し、ブロックライブラリと結合して最大50パターンのLPを自動生成する。

5.2.2 入力

5.2.3 処理仕様

[1] 因子の直積を展開                → 50組の (appeal, structure, cta_copy)
[2] 組合せごとにプロンプトを構築      → システムプロンプト + 因子指示 + 事実データ
[3] LLMでコピー生成 (並列・レート制御) → JSON Schema で構造化出力を強制
[4] 事実チェック                    → 事例DB・数値の照合、禁止表現検査
[5] 重複検査                        → 埋め込みベクトルのコサイン類似度
[6] ブロック結合 → HTML生成          → サーバ側レンダリング
[7] 品質スコア算出 (第0層)           → 5.2.5参照
[8] プレビュー生成                  → ヘッドレスブラウザでスクリーンショット
[9] レビュー待ちキューへ             → 人が承認するまで公開しない

LLM出力の構造化: 自由文ではなく次のスキーマで出力させる。これにより後段の機械処理とチェックが可能になる。

{
  "hero": { "headline": "…(全角40字以内)", "subcopy": "…(全角90字以内)", "cta_label": "…" },
  "problem": { "items": ["…", "…", "…"] },
  "solution": { "headline": "…", "body": "…" },
  "proof": { "case_ids": ["CASE-012", "CASE-031"], "highlight_metric": "保守工数を月32時間削減" },
  "differentiator": { "items": ["…", "…", "…"] },
  "faq": [ { "q": "…", "a": "…" } ],
  "meta": { "title": "…(全角30字以内)", "description": "…(全角120字以内)" },
  "self_eval": { "clarity": 4, "specificity": 5, "target_fit": 4, "reasoning": "…" }
}

5.2.4 ハルシネーション防止(必須要件)

営業用LPに虚偽の実績が載る事故は、当社の信用に直結する。以下を必須とする。

5.2.5 第0層スクリーニング(公開前品質スコア)

トラフィックを1件も使わずに、明らかに弱いバリアントを落とす。

合格ライン: 60点以上、かつ事実チェック違反ゼロ。 50件生成 → 実際に公開されるのは概ね 15〜25件 となる。ここで落ちた分は再生成キューに戻る。

5.2.6 実装メモ(Cloudflare)

生成コストの目安: 1バリアントあたり 入力200 + 出力800トークン程度。50件で入力1万・出力4万トークン。Workers AI の Llama 3.1 70B 相当の公表換算(入力 26,668 Neurons/100万トークン、出力 204,805 Neurons/100万トークン)で計算すると約 8,500 Neurons/回 となり、無料枠(10,000 Neurons/日)にほぼ収まる規模。ただしモデル別の換算値は変わりうるため、実装前に公式の料金表で再計算すること。

5.3 F-13 LP配信エンジン(文脈別出し分け)

5.3.1 概要

訪問者ごとにバリアントを1つ選び、エッジで描画して返す。本システムの心臓部。

5.3.2 URL設計

5.3.3 処理仕様(リクエスト時)

① 文脈(context)を構築する
   ├ /r/{tracking_code} の場合 : tracking_code → アプローチ → 企業 を解決
   │    context = {company_id, industry, pref, size, channel:'email',
   │               approach_count, prior_reaction, template_id}
   └ /lp/{slug} の場合         : UTM・Referer・Accept-Language から推定
        context = {channel, utm_campaign, utm_content, keyword_cluster, device}

② 割付済みかを確認する
   ├ Cookie `ma_v` が存在し、同一実験のものであれば → 同じバリアントを再表示
   └ 無ければ → ③へ                          ※必ず同じ人に同じ面を見せる

③ バリアントを選択する
   ├ 実験ステータス = 'exploring'  → 均等ランダム(第1層・逐次淘汰の対象)
   ├ 実験ステータス = 'bandit'     → 文脈付きThompson Sampling(8章)
   └ 実験ステータス = 'fixed'      → 確定した勝ちバリアント
   ※ 常に 5〜10% を「探索枠」として残し、勝者以外にも配信し続ける(環境変化への追随)

④ 描画する
   ├ ブロックHTMLを結合(サーバ側)
   ├ 差込変数を展開(F-16のパーソナライズを含む)
   ├ Cookie `ma_v` / `ma_s` を発行(HttpOnly=false, SameSite=Lax, 有効期限90日)
   └ HTMLをストリーミング返却

⑤ 記録する(レスポンスをブロックしない)
   └ assignment イベント + view イベントを非同期で書き込む

5.3.4 割付の固定(Sticky Assignment)

同一訪問者には常に同じバリアントを表示する。 これを守らないと計測が壊れる。

Cookie値は改ざん防止のためHMAC署名を付与する。

5.3.5 パフォーマンス要件

CWVの閾値はいずれも 75パーセンタイル値 で判定する。LCP: 良好 ≤2.5秒 / 改善が必要 2.5〜4.0秒 / 不良 >4.0秒。INP: ≤200ms / 200〜500ms / >500ms。CLS: ≤0.1 / 0.1〜0.25 / >0.25。(web.dev)

5.3.6 実装メモ(Cloudflare)

• Workers + Static Assets で配信する。Cloudflare は新規プロジェクトについて Pages ではなく Workers を推奨しており、SPA/静的アセットとAPIを1デプロイ単位にできる(Cloudflare Blog)。
• バリアントを Workers の「バージョン」として持たせてはならない。 Gradual Deployments はバージョン間のトラフィック分割ができるが、(a)対象は直近100バージョンまで、(b)配分変更のたびにデプロイ操作が要る、(c)割付の粒度がリクエスト単位、という制約がある。バリアントはあくまでD1上のデータとして持ち、単一のWorkerが描画する。
• 配信重み(バンディットの結果)は KV に置き、Workerは読むだけにする。KVは結果整合だが、重みは数十秒遅れても実害がない。
• 逆に 割付結果・イベントは KV に書かない(結果整合のため計測が壊れる)。D1 / Analytics Engine / Durable Objects を使う。
• バンディットのカウンタは Durable Objects(実験ごとに1インスタンス)で直列化する。D1に高頻度UPDATEをかけるとロック競合が起きる。

5.4 F-14 LP行動計測(ファーストパーティ計測)

5.4.1 概要

LP上の訪問者行動を自社ドメインで直接計測する。GA4は補助として併用するが、実験判定の一次データはGA4に依存しない。

5.4.2 GA4に依存しない理由

GA4は「全社共通の指標」「経営報告用の数字」として引き続き使う(既存F-09を継続)。実験の判定には自前計測を正とする、という二層構造にする。

5.4.3 計測イベント定義

5.4.4 実装方式

• スクロール到達は IntersectionObserver(閾値0.5)でセクション単位に検出し、1セクション1回のみ記録する。scroll イベントの直接監視はしない(するなら {passive:true} 必須)。
• 滞在時間は Page Visibility API で可視状態のみを積算する(バックグラウンドタブを計上しない)。
• 送信は navigator.sendBeacon()。visibilitychange(hidden) と pagehide で発火する。unload は信頼性が低いため使わない。
• CWVは web-vitals ライブラリの onLCP / onINP / onCLS で確定値を取得し lp_vitals として送信する。
• クリック座標はビューポート比(%)に正規化して保存し、ヒートマップ描画に用いる。
• 計測スクリプトは 8KB(gzip後)以内、defer 読み込み、外部ドメインへのリクエストを行わない。

5.4.5 データ量の見積り

1セッションあたり: scroll 10件 + click 平均5件 + visibility 3件 + vitals 1件 ≒ 20イベント、1件 200〜300バイト。

5.4.6 実装メモ(Cloudflare)

• 生イベントは Workers Analytics Engine に writeDataPoint() で書く。カーディナリティ無制限で、バリアント×企業×セグメントの組合せを気にせず記録できる。保持期間3か月。SQL APIで集計取得。
• 集計済みの日次サマリは D1 に保存する(3か月を超える長期分析・レポート用)。
• 実験カウンタ(成功/試行)は Durable Objects (SQLiteバックエンド) で直列に更新する。DOのSQLiteバックエンドはGA済みで、Cloudflare は新規名前空間についてSQLiteバックエンドの使用を推奨している。
• ボット除外: Turnstile・User-Agent・行動パターン(0msスクロール等)で除外フラグを立て、集計から除く。

5.5 F-15 LP実験・統計エンジン

5.5.1 概要

2.2項の3層評価を実装する。実験の状態遷移と各層の判定ロジックを定義する。詳細な数式は8章。

5.5.2 実験の状態遷移

 draft ──[生成完了]──▶ screening ──[第0層合格]──▶ review
                                                    │
                                              [人が承認]
                                                    ▼
                                              exploring ◀────┐
                                        (均等配分・逐次淘汰)   │
                                                    │        │[有意差なし/
                                          [候補が5件以下]      │ 環境変化検知]
                                                    ▼        │
                                                 bandit ──────┘
                                        (Thompson Sampling)
                                                    │
                                        [勝者の優越確率 ≥ 95%
                                         かつ 最小サンプル充足]
                                                    ▼
                                                  fixed
                                        (勝者95% + 探索5%)

5.5.3 第1層 — プロキシ指標による逐次淘汰

アルゴリズム: Sequential Halving(逐次半減法)

1. 現在の候補集合に均等にトラフィックを配分する
2. 各バリアントがラウンド最小サンプル数(既定300セッション)に到達したらラウンド終了
3. 複合プロキシスコアの下位半分を脱落させる
4. 候補が5件以下になるまで繰り返す

複合プロキシスコア(重みは設定可能):

proxy_score = 0.40 × normalize(CTAクリック率)
            + 0.30 × normalize(スクロール50%到達率)
            + 0.20 × normalize(中央値エンゲージ時間)
            + 0.10 × normalize(フォーム開始率)

normalize() は候補集合内でのZスコアを 0〜1 に写像する。

ラウンド設計の例(1バリアント300セッション/ラウンド):

20バリアントを同時にCVRで検定すると 20×3,820 = 76,400セッション必要なのに対し、逐次淘汰なら 10,500セッションで5件まで絞れる(約1/7)。

早期打ち切り: 明らかに劣るバリアントは300セッションを待たずに落とす。ベイジアンな判定で P(そのバリアントが最良) < 1% となった時点で脱落させる。

5.5.4 第2層 — ベイジアン判定 + Thompson Sampling

候補が5件以下になったら、本命指標(CV)で判定する段階に移る。

• 各バリアント i の CVR を Beta分布でモデル化: θᵢ ~ Beta(αᵢ, βᵢ)
• 事前分布は 一様 Beta(1,1) ではなく、全バリアントの集約値から作る経験ベイズ事前分布を用いる(低トラフィックでの収束を早めるため。8.3項)
• 配信は Thompson Sampling: 毎リクエスト各分布から1点サンプリングし、最大のバリアントへ配信する
• 判定: P(variant_i が最良) ≥ 95% かつ 各バリアントの累計CV ≥ 20件 で fixed に遷移

5.5.5 因子(水準)単位の効果推定

バリアント単位の勝敗と並行して、常に因子水準単位の効果を推定する。 これが実務上もっとも役に立つアウトプットになる。

出力例:

この結果は次回の生成(F-12)に自動でフィードバックされ、勝ち筋の水準を厚めに配合した新しい50パターンを作る。世代を重ねるごとに母集団の質が上がる。

5.5.6 セグメント別の効果推定

同じ推定を、セグメント(業種・企業規模・チャネル)ごとにも行う。データが薄いセグメントは階層ベイズにより全体平均へ縮約されるため、過学習しない。

セグメント別の勝者が全体最良と異なる場合、F-13の配信エンジンはセグメント別の勝者を優先する(コンテキスチュアル・バンディット)。

5.5.7 誤用防止のガードレール

低トラフィックでの統計判断は、放置すると必ず誤用される。以下を機能として強制する。

5.6 F-16 企業識別パーソナライズLP(ABM-LP)

5.6.1 概要

重点企業に対して、その企業のためだけの1枚を自動生成・配信する。2.4項の中核アイデアを最も直接的に実装する機能。

5.6.2 パーソナライズの3段階

5.6.3 L2の処理仕様

[1] 対象企業の選定
    ├ 手動選択 / セグメント条件 / スコア閾値(F-23のリードスコア)
    └ 上限: 1回のバッチで500社
[2] 企業ごとの文脈データを収集
    ├ 企業マスタ(業種・都道府県・規模・サイトURL)      … 既存F-01/F-02
    ├ アプローチ履歴(送信済テンプレ・反応の有無)        … 既存F-04
    └ 公開情報の要約(自社サイトのトップ・事業紹介ページ) … F-02のクロール結果を再利用
[3] 事例マッチング
    └ 同業種 → 同規模 → 同技術領域 の優先順で事例DBから最大3件を選択
[4] LLMで差込文を生成(コピー全体ではなく "差込部分のみ")
    ├ hero.headline の企業向け言い換え
    ├ problem.items の業種特化版
    └ proof の事例選定理由(1文)
[5] 事実チェック(F-12と同じ検査を適用)
[6] account_token を発行し、専用URL /a/{account_token} を確定
[7] レビュー → 承認 → 公開

5.6.4 出力

5.6.5 制約・注意事項

• 社名の表示は「取引先/見込み先として認識している」ことの開示になる。 相手に不快感を与えうるため、既定は「社名を直接出さず、業種・規模・課題を合わせる」L2弱パーソナライズとする。社名の明示は設定でONにする。
• 個人名の差し込みは、名刺交換等で正当に取得した情報に限る。推測した個人名を出してはならない。
• L3は人の編集を必須とする。AI生成のまま公開できない。
• ABM-LPのURLは推測可能であってはならない。連番・企業名のローマ字表記等を使わない。

5.6.6 効果測定上の扱い

ABM-LPはバリアント実験の対象外とする(1社1枚のためN=1で統計的評価ができない)。代わりに以下を記録する。

再訪の検知は営業上もっとも価値が高い。 同じ企業から3日以内に2回目の訪問があった場合、インサイドセールスの架電キュー(F-23)に自動投入する。

6. 機能要件 第II部 — 新規チャネル(F-17〜F-22)

6.1 F-17 検索意図クラスタ / SEOコンテンツハブ

6.1.1 概要

検索意図のクラスタを定義し、クラスタごとにコンテンツとLPを紐づけて管理する。大量ページの自動生成は行うが、インデックス方針を機能として厳格に制御する。

6.1.2 なぜインデックス制御が必須なのか

Googleのスパムポリシーは「scaled content abuse(大規模なコンテンツの不正利用)」を、ランキング操作を主目的として大量のページを生成し、ユーザーへの価値がほとんど無い行為と定義している。明示的なNG例に「生成AIツール等を使い、ユーザーに価値を加えずに大量のページを生成すること」が含まれる。(Google スパムポリシー)

一方、AI利用そのものは禁止されていない。Googleの生成AIコンテンツに関するガイダンスは、AI活用を認めたうえで「独自性・付加価値・労力がほとんど無いコンテンツ」を問題とする、という立場を明確にしている。(Google 生成AIコンテンツのガイダンス)

さらに「doorway pages(誘導ページ)」ポリシーは、地域名違いの類似ページ量産や、実質同一内容のページの大量配置を明示的に対象としている。(doorway pages)

したがって本システムは「大量生成LPを自然検索にインデックスさせない」ことを既定とし、インデックスさせる場合は別の厳しい要件を課す。 この判断を機能として強制する(F-24)。

6.1.3 ページ種別とインデックス方針

重要な実装ルール: インデックスさせたくないページは <meta name="robots" content="noindex,follow"> で制御し、robots.txt でブロックしない。robots.txt でクロールを止めると、他ページからのリンク経由で「コンテンツなし」の状態で検索結果に出ることがあり、確実な除外にならない。またGoogle広告のクローラ(AdsBot)を robots.txt で塞ぐと、広告の品質評価・配信に支障が出る。(noindex の使い方)

6.1.4 クラスタ管理

6.1.5 段階公開(必須)

一度に大量のページを公開しない。1回の公開は50ページ以内とし、公開後2週間のインデックス率(Search Consoleで確認)を記録してから次の公開を許可する。インデックス率が70%を下回った場合は自動的に次の公開をブロックし、警告を出す。

「安全なページ数の上限」についてのGoogle公式の数値基準は存在しない。上記の数値は業界の実務的推奨に基づく当社の運用基準であり、実測に応じて見直す。

6.1.6 生成AI検索(LLMO/AEO/GEO)の扱い

Googleは公式ガイドで、生成AI検索機能向けの別建ての最適化は不要と明言している。

「Google検索の生成AI機能は既存の中核的な検索ランキング・品質システムに根ざしているため、従来のSEOのベストプラクティスは引き続き有効」 「Google検索に表示されるために、新しい機械可読ファイル、AI用テキストファイル、マークアップ、Markdownを作成する必要はない」 (Google: 生成AI機能向け最適化ガイド)

llms.txt は2026年8月時点で、Google・OpenAI いずれからも「利用している」という公式確認が取れていない。 本システムでは llms.txt の生成機能を実装するが、既定はOFFとし、「効果は未確認」と画面上に明示する。

代わりに実装するのは、従来SEOの延長線にある確実な施策のみとする。

6.2 F-18 広告オーディエンス連携

6.2.1 概要

MA内の企業リスト・行動データを広告媒体のオーディエンスとして同期し、広告成果をMA側で突合する。広告の入稿・クリエイティブ・入札は対象外(4.3項)。

6.2.2 オーディエンスの種別

6.2.3 処理仕様

1. セグメント条件を定義し、対象企業/訪問者IDを日次で抽出する。
2. 媒体別のアダプタを通じてオーディエンスを同期する(Google Ads / Meta / LinkedIn / X)。
3. 除外リストは常に最優先で適用する。CV済み・配信停止・既存顧客への広告配信は事故になる。
4. 広告からの流入は utm_* + 独自パラメータ ma_ch=ads&ma_src={媒体} で識別し、F-13の文脈構築に渡す。
5. 広告費は媒体APIまたはCSVで日次取り込み、F-23でCPA/ROASを算出する。

6.2.4 制約・法令上の注意(重要)

• 改正電気通信事業法の外部送信規律(第27条の12) により、Cookie等で利用者情報を外部(広告事業者)へ送信する場合、送信情報の種別・送信先事業者名・利用目的について通知または公表が必要になる。本システムは F-24 で、送信先タグの一覧から公表用テキストを自動生成する。
• 個人関連情報の第三者提供: Cookie ID等を提供先で個人データと紐づけることが想定される場合、提供元は本人同意の取得状況を確認する義務がある。メールアドレスのハッシュ値を広告媒体の顧客一致機能へアップロードする運用は、この規律に直接かかる。実施前に必ず法務確認を経ること。
• 2026年7月17日に公布された改正個人情報保護法により、Cookie ID等の不適正利用禁止が強化され課徴金制度が新設された。全面施行は公布から2年以内(2028年7月17日が期限)、罰則の一部は2027年1月17日先行施行の見込み。本機能は施行時期に合わせた再点検を前提とする。

6.3 F-19 ウェビナー運用

6.3.1 概要

ウェビナーは調査したチャネルの中で CPLが最も低い部類(3,000〜8,000円) であり、かつ工程のほぼ全てが自動化可能なため、新チャネルの中で最優先で実装すべき機能である。

6.3.2 自動化する工程

[企画] ─(人)─▶ [告知] ─▶ [申込] ─▶ [リマインド] ─▶ [開催] ─(人)─▶ [視聴データ取込]
                  │         │           │                            │
                  ▼         ▼           ▼                            ▼
              LP自動生成  フォーム    3回配信              スコアリング・セグメント
              (F-12流用) +Turnstile  (前日/1h前/直前)              │
                                                                     ▼
                                        [アンケート] ─▶ [フォロー配信] ─▶ [架電キュー]
                                                          分岐配信          F-23

6.3.3 リマインド設計

申込者の参加率は全業種平均で約46%(申込者の半数以上が参加しない)。リマインドの設計がそのまま成果に直結する。

6.3.4 視聴データに基づくセグメントとフォロー

6.3.5 共催ウェビナー

共催は相互のリストを活用できるためCPLをさらに下げられるが、リード分配ルールの事前合意が必須。機能として以下を持つ。

• 共催相手ごとの申込フォーム(流入元識別)
• リードの帰属ルール設定(全件共有 / 自社流入のみ / 相手流入のみ)
• 共有リードには source=co_host:{相手名} を付与し、以後の配信で同意状況を明示的に管理する

6.3.6 法令上の扱い

ウェビナー申込は相手が能動的に情報を登録した行為であるため、以後のメール配信は特定電子メール法上の同意取得が成立しやすい(フォーム営業とは性質が異なる)。ただし申込フォームに受信同意のチェックと利用目的の明示を必ず置く。共催で相手方から受領したリードへの配信は、相手方が同意を取得しているかを確認する。

6.3.7 外部連携

6.4 F-20 コンテンツゲートとナーチャリング

6.4.1 概要

ホワイトペーパー等の資料をフォームの背後に置き(ゲート)、ダウンロードを起点に関係を育てる。既存のフォーム・メール基盤の延長で実装でき、実装コストが低く効果が読みやすい。

6.4.2 ゲート設計

6.4.3 検討フェーズ推定

閲覧した資料の種類と順序から、相手の検討段階を推定する。 これがナーチャリングの中核ロジックになる。

6.4.4 スコアリング

スコア閾値(既定50点)を超えたリードは F-23 の架電キューに自動投入する。スコアは日次で3%減衰させ、古い行動の影響を薄める。

6.4.5 ステップ配信

• 資料種別ごとにシナリオを定義(既定5通/3週間)
• 分岐条件: 開封しない → 件名を変えて再送 / クリックした → 関連事例を送る / CVした → シナリオ停止
• 全シナリオに配信停止リンクと送信者情報を含める(特定電子メール法。既存F-08の共通フッターを継承)

6.5 F-21 SNS・コミュニティ運用支援

6.5.1 概要

SNS・コミュニティは直接のリード獲得チャネルではなく、認知と信頼の構築チャネルである。定量的な公開ベンチマークが乏しいため、本機能の目的は「効果を出すこと」ではなく「効果を測れる状態にすること」に置く。

6.5.2 機能

6.5.3 KPI

公開ベンチマークが無いため、当社の実測をKPIとする。

6.5.4 制約

• 投稿内容の自動生成・自動投稿は行わない。 下書き生成までとし、投稿は必ず人が承認する(炎上・誤情報のリスク)。
• SNSのユーザーIDとメールアドレスの自動名寄せは行わない(精度と法的論点の両面で実装しない)。名簿からの手動紐付けのみ。
• 各媒体のAPI利用規約・レート制限を遵守する。規約変更時に機能が停止しうることを前提に、フォールバック(手動運用)を必ず用意する。

6.6 F-22 匿名訪問企業推定(オプション機能)

6.6.1 概要

自社サイト・LPに訪問した匿名ユーザーのIPアドレスから企業単位での訪問元を推定する。法務確認を経るまで実装・有効化しない前提のオプション機能として定義する。

6.6.2 仕組みと精度の限界

IPアドレスを法人契約回線のデータベースと照合して企業を推定する。ただし以下の限界がある。

• 特定できるのは企業単位までであり、個人は特定できない
• 在宅勤務・モバイル回線・プロキシ・VPN経由では精度が大きく落ちる
• 一致率は業種・企業規模に強く依存する(大企業ほど当たりやすい)

精度・料金の定量的な公開データは見当たらなかった。導入判断の前に必ずPoCで一致率を実測すること。

6.6.3 法的論点(実装の前提条件)

本機能は「法務確認済み」フラグが環境設定でONにならない限り、機能自体が起動しない実装とする。

6.6.4 実装方式の選択肢

6.6.5 出力

• 訪問企業の推定結果(企業名・確度・訪問ページ・滞在時間)
• 既存の企業マスタとの自動名寄せ(確度が閾値以上の場合のみ)
• 「アプローチ済み企業が匿名で再訪した」検知 → 架電キューへ最優先で投入(F-23)

7. 機能要件 第III部 — 横断機能(F-23〜F-24)

7.1 F-23 チャネル横断アトリビューション分析

7.1.1 概要

メール・フォーム・LP・広告・SEO・ウェビナー・資料・SNS のすべてを1本の時系列に統合し、「どのチャネルの組合せが商談を生んだか」を可視化する。既存 F-07(分析)を包含する上位機能。

7.1.2 統合の連結キー

名寄せの流れ: 匿名訪問(visitor_id)→ フォーム送信でメールを取得 → contact_email から company_id を解決 → 過去の匿名行動を遡って企業に紐づける(バックフィル)。これにより「CVの3週間前から検討が始まっていた」という事実が可視化される。

7.1.3 タッチポイント時系列

company_id: C-01382 (株式会社◯◯製作所 / 製造業 / 従業員80名)
─────────────────────────────────────────────────────────
2026-06-03  email       メール営業 送信 (TPL-07)
2026-06-03  email       開封
2026-06-11  lp          /r/{code} 着地 → V-023 表示 / スクロール60% / 離脱
2026-06-24  ads         リターゲティング広告 クリック → V-023(固定割付)
2026-06-24  lp          スクロール100% / 料金ブロック閲覧 45秒
2026-07-02  webinar     ウェビナー申込 → 参加(視聴82%)/ 質問あり
2026-07-02  score       スコア 68点 → 架電キュー投入
2026-07-04  call        架電 → 担当者接続
2026-07-15  deal        商談化 ★
─────────────────────────────────────────────────────────

7.1.4 アトリビューションモデル

単一のモデルに依存しない。 4つを並べて表示し、解釈は人が行う。

7.1.5 主要レポート

7.1.6 架電キュー(インサイドセールス連携)

「話すべき論点の候補」の自動生成は本機能の目玉。「料金ブロックを45秒閲覧」「属人化解消の訴求軸のLPで完読」といった行動から、相手の関心事を推定して営業に渡す。

7.2 F-24 コンプライアンス・ガードレール管理

7.2.1 概要

本拡張で扱う領域(AI生成コンテンツ、Cookie、広告連携、大量ページ公開)は、いずれも運用ミスが法令違反や検索評価の毀損に直結する。これらを人の注意力に頼らず、機能として強制する。

7.2.2 ガードレール一覧

G-15 の背景: v1.2 の F-09 は、本文内URLの書き換え方式として「計測リダイレクト経由(既定)」と「直接付与」の2つを環境設定で選べる。「直接付与」を選ぶと /r/{tracking_code} への着地が発生せず、F-13 が前提とする企業文脈の解決ができなくなる。 したがってLP実験・ABM-LPを運用している間は、計測リダイレクト方式を必須とする。

7.2.3 コンプライアンス・ダッシュボード

7.2.4 法改正への追随

改正個人情報保護法(2026年7月17日公布)の全面施行は公布から2年以内(2028年7月17日が期限)、罰則の一部は2027年1月17日先行施行の見込み。四半期に1回、法令要件のレビューをスケジュール化する(運用手順書に定期タスクとして記載)。

8. 統計エンジン仕様

本章は F-15 の実装仕様である。実装言語は問わないが、数値はすべて倍精度浮動小数で扱う。

8.1 2群比率のZ検定(参考指標として表示)

p̂ = (x₁ + x₂) / (n₁ + n₂)
SE = √( p̂(1-p̂) × (1/n₁ + 1/n₂) )
Z  = (p̂₁ - p̂₂) / SE

両側 α=0.05 で |Z| > 1.96 のとき有意。ただし本システムでは主表示にしない。 多重比較補正後の値と併記し、ベイズの優越確率を主表示とする(理由: 5.5.7 のガードレール)。

8.2 必要サンプルサイズ

n ≈ 2 × (Z(α/2) + Z(β))² × p̄(1-p̄) / d²      d = |p₁ - p₂|
  = 15.68 × p̄(1-p̄) / d²                      (α=0.05両側, 検出力80%)

実験作成画面で、指定した指標・ベース率・検出したい差から必要セッション数と到達見込み日数を必ず提示する。到達に90日以上かかる設定は警告する。

8.3 ベイジアン評価(本命)

各バリアント i について、CVRを Beta分布でモデル化する。

事前分布 : θᵢ ~ Beta(α₀, β₀)
観測     : sᵢ 回のCV、fᵢ 回の非CV
事後分布 : θᵢ | data ~ Beta(α₀ + sᵢ, β₀ + fᵢ)      ← 共役性により閉形式

事前分布の決め方(重要): 一様分布 Beta(1,1) は低トラフィックで不安定になる。全バリアントの集約実績から経験ベイズで決める。

全体CVR      : p̄ = Σsᵢ / Σ(sᵢ + fᵢ)
事前の強さ    : κ  (既定 100。「100セッション相当の事前知識」の意味)
α₀ = p̄ × κ ,  β₀ = (1 - p̄) × κ

これにより、データの少ないバリアントの推定値は全体平均へ引き寄せられ(縮約)、たまたま2件CVした10セッションのバリアントが「CVR 20%」として1位に出る事故を防ぐ。

優越確率 P(最良) はモンテカルロで求める。

for m = 1..M (M = 100,000):
    for each variant i: draw θᵢ⁽ᵐ⁾ ~ Beta(αᵢ, βᵢ)
    winner[argmax_i θᵢ⁽ᵐ⁾] += 1
P(i が最良) = winner[i] / M

期待損失(Expected Loss) も併せて算出し、「勝者を確定しても失う期待CVRが閾値以下」であることを確定条件に加える。

EL(i) = E[ max_j θⱼ - θᵢ ]        既定閾値: 0.1% (0.001)

8.4 Thompson Sampling(配信)

各リクエストにつき:
  1. 対象バリアント集合 A(セグメント条件で絞り込み済み)を取得
  2. for each i in A:  θᵢ ~ Beta(αᵢ, βᵢ) をサンプリング
  3. 選択: argmax_i θᵢ
  4. ただし確率 ε(既定 0.05)で A から一様ランダムに選ぶ  ← 探索枠を常に残す
  5. 表示後、試行数 nᵢ += 1。CV発生時 sᵢ += 1

実装上の注意

• JavaScript/TypeScript には標準のベータ分布サンプラーが無い。ガンマ分布経由(Marsaglia-Tsang法)で実装するか、jstat 等を用いる。
• リクエストごとに10万回のモンテカルロを回してはならない。 配信時は1バリアント1サンプルのみ。優越確率の計算(10万回)はCronによる日次バッチで行い、結果をKVにキャッシュする。
• サンプリング用の乱数はリクエスト単位で独立させる。Workerのグローバルスコープに状態を持たせない。
• パラメータ (α, β) の更新は Durable Objects で直列化する。

8.5 階層ベイズによる因子効果推定

バリアント v が因子水準の集合 L(v) から構成されるとき、ロジット空間で加法モデルを置く。

logit(θ_v) = μ + Σ_{ℓ ∈ L(v)} γ_ℓ
γ_ℓ ~ Normal(0, τ_f²)        f は ℓ が属する因子
τ_f ~ HalfNormal(0.5)        因子ごとの効果のばらつき(弱情報事前分布)

τ_f が小さく推定される因子は「その因子は効いていない」、大きい因子は「効いている」と読める。データが薄い水準の γ は 0 へ縮約される(=過大評価しない)。

実装: フルMCMCは重いため、以下のいずれかを用いる。

出力は水準ごとの 事後平均・95%信用区間・全体比 とし、5.5.5 の表として表示する。

8.6 セグメント別推定(コンテキスチュアル)

セグメント s とバリアント v の組合せについて、次の階層構造で推定する。

logit(θ_{v,s}) = μ + α_v + β_s + δ_{v,s}
δ_{v,s} ~ Normal(0, τ_δ²)      交互作用項。τ_δ は小さめの事前分布

交互作用 δ が有意に大きい (v, s) の組が「そのセグメントに特別に効くバリアント」である。τ_δ を小さめに置くことで、データの薄いセグメントで偽の交互作用を検出するのを防ぐ。

セグメントの定義:

全組合せは 6×3×7×2 = 252 だが、セッション数が閾値(既定200)未満のセグメントは推定を行わず、上位の階層(業種のみ、チャネルのみ)へフォールバックする。

8.7 判定サマリの表示仕様

実験画面には常に以下を表示する。数値だけを並べない。

┌──────────────────────────────────────────────────────┐
│ 実験: 製造業向け・システム保守 2026Q3                  │
│ 状態: bandit  /  経過 14日  /  累計 4,820 セッション    │
├──────────────────────────────────────────────────────┤
│ 現在の最有力: V-023 (属人化解消 × 実績先行 × 資料DL)    │
│   推定CVR 3.4%  [95%信用区間 2.6% – 4.3%]              │
│   最良である確率 78%   期待損失 0.31%                   │
│                                                        │
│   ⚠ 確定条件に未到達です                                │
│      ・最良確率 78% < 95%(あと約1,900セッション)        │
│      ・期待損失 0.31% > 0.10%                          │
│   この段階で運用を確定しないでください。                 │
├──────────────────────────────────────────────────────┤
│ 因子効果(この実験でいま言えること)                      │
│   訴求軸「属人化解消」  +38% [+9% – +71%]  ★確度高      │
│   構成「実績先行型」    +27% [−2% – +58%]   確度中       │
│   CTA「資料をダウンロード」+18% [+1% – +37%] ★確度高    │
└──────────────────────────────────────────────────────┘

9. 計測仕様

9.1 イベントスキーマ(共通部)

すべてのイベントは以下の共通フィールドを持つ。

9.2 GA4との併用方針

Measurement Protocol の制約(実装時に必ず守る)

• 1リクエスト最大25イベント、パラメータ各25個、POSTボディ130KB未満
• client_id は自前生成せず、_ga Cookie 由来の値を使う。独自IDだと地理・デバイス情報が付かず (not set) の原因になる
• session_id / session_number を明示しないと別セッション扱いになる
• リアルタイム反映は保証されない。GA4は「補完」であって記録の正ではない
• api_secret はローテーション可能な形で環境設定(F-10)に置く

9.3 Google Search Console の位置づけ

結論: Search Console は LPバリアント実験の効果測定には使えない。 ただし別の役割で必須になる。無料で導入コストがゼロなため「これで測れるのでは」と考えやすいが、測れるものが根本的に違う。

9.3.1 なぜ実験の判定に使えないのか

一言でいえば、Search Console は「検索結果に出てクリックされたか」までしか見ない。本システムが知りたいのは「着地した後にどう動いたか」であり、守備範囲が重なっていない。

9.3.2 では何に使うのか — 2つの必須の役割

役割① コンプライアンス監視(G-03 / G-06)の実測手段

本システムの最大のリスクは「大量生成LPが誤ってインデックスされること」である。その検知は Search Console でしかできない。

URL Inspection API のクォータはサイトあたり 600 QPM / 2,000 QPD。 1回の公開が50ページ以内(G-06)なので、日次で全バリアントを検査しても十分収まる。G-06 の自動チェックはこのAPIで実装する。

⚠ robots.txt でブロックしていると、Googleが noindex 自体を読めないため「インデックス登録を許可?」が常に「はい」と表示される。14.2項で robots.txt を使わない理由の一つがこれ(監視が効かなくなる)。

役割② 代表LP・コンテンツ記事(F-17)の自然検索実績

インデックスさせる代表LP・記事については、GSCが正しい道具になる。クエリ別の表示回数・順位・CTRを見て、コンテンツの改善やクラスタ設計(6.1.4)に反映する。ただしコンバージョンは測れないので、成果はF-14の自前計測と突き合わせる。

9.3.3 3つのツールの役割分担

「効率」で選ぶなら順序が逆になる。 GSCは導入コストがゼロだが、実験の判定に必要なデータを1つも供給しない。自前計測(F-14)は実装コストがかかるが、判定に必要なデータを全て、遅延なく供給する。測れないものを安く測っても、意思決定は1つも進まない。

9.4 ボット・無効トラフィックの除外

除外対象は削除せずフラグを立てる。集計からは除くが、監査・不正検知のために生データは保持する。

9.5 データ保持

10. 画面仕様(追加)

10.1 画面一覧

10.2 主要画面の補足

S-15 実験作成ウィザード

最終ステップで、選択した因子構成から次を必ず提示し、ユーザーの同意を得てから生成に進む。

生成されるバリアント数   : 50 (5 × 5 × 2)
第0層通過見込み          : 15〜25件
第1層(逐次淘汰)所要      : 約 10,500 セッション / 現在の流入(月5,000)で約 63日
第2層(CV判定)所要        : 約 19,100 セッション (5件 × 3,820) / 約 115日

⚠ 全工程の完了まで約 178日(5.9か月)かかる見込みです。
   期間を短縮するには:
   ・判定指標をCVからCTAクリック率に変える(1件あたり約1,095)
       → 第2層 約33日 / 全工程 約96日(3.2か月)
   ・因子を減らす(例: CTAを固定して 5×5=25 にする)
   ・流入を増やす(広告出稿・メール配信量の増加)

この「先に現実を見せる」設計が、本システムで最も重要なUXである。 統計的に不可能な実験を始めさせない。

S-16 バリアントレビュー

• 50件をカード形式で一覧(スクリーンショット + スコア + 因子ラベル)
• 事実チェック違反は赤枠で最上部に固定表示し、承認ボタンを無効化
• 一括承認は可能だが、違反ゼロのバリアントのみが対象
• 差戻し時は理由を選択(事実誤り/表現が硬い/訴求がずれている/デザイン崩れ)。理由は次回生成のプロンプトに反映される

S-25 架電キュー

• 1画面1リードのカード形式(営業がそのまま電話をかけられる)
• 「話すべき論点の候補」を3点まで自動提示
• 架電結果を1クリックで記録(接続/不在/NG/商談化)

11. データベース設計(追加)

11.1 ER概要

companies (既存)
   │1                                    ┌── lp_libraries
   │                                     │       │1
   │n                                    │       │n
approaches (既存) ──1─n── lp_assignments │   lp_blocks
   │                          │n         │
   │                          │          │
   │                     lp_variants ─n─1┴─ lp_experiments
   │                          │1                 │1
   │                          │n                 │n
   │                     lp_events          experiment_rounds
   │                                             │1
   │                                             │n
   │                                        factor_effects
   │
   ├──n── abm_pages
   ├──n── webinar_registrations ──n─1── webinars
   ├──n── asset_downloads ──────n─1── assets
   ├──n── call_queue_items
   └──n── touchpoints  ← 全チャネルの統合時系列

11.2 主要テーブル定義

lp_libraries — LPブロックライブラリ

lp_blocks — ブロック

lp_experiments — 実験

lp_variants — バリアント

lp_assignments — 割付

UNIQUE(experiment_id, visitor_id) および UNIQUE(experiment_id, company_id)(company_id が NULL でない場合)で、同一実験内の割付を一意にする。

lp_events — イベント(日次サマリ)

生イベントは Analytics Engine に置き、本テーブルには日次×バリアント×セグメントの集計を保持する。

INDEX(experiment_id, date), INDEX(variant_id, date), INDEX(segment_key, date)

factor_effects — 因子効果推定結果

abm_pages — ABM専用LP

touchpoints — 全チャネル統合時系列

INDEX(company_id, occurred_at), INDEX(visitor_id, occurred_at)

その他、webinars / webinar_registrations / assets / asset_downloads / seo_clusters / ad_audiences / social_posts / call_queue_items / compliance_flags / audit_logs を同様に定義する(詳細は実装時に確定)。

11.3 設計方針

• 書き込み頻度の高いカウンタをRDBに直接UPDATEしない。 Durable Objects で直列化し、日次でD1へ同期する。
• 生イベントはRDBに入れない(Analytics Engine)。RDBが持つのは日次サマリまで。
• lp_events は日付でパーティション相当の設計とし、古い月のデータはR2へアーカイブする。
• 既存 v1.2 のテーブル(companies / approaches / templates 等)は変更しない。新テーブルから外部キーで参照するのみ。
• ⚠ company_id の型は v1.2 の companies.id に合わせる。 v1.2 は INTEGER PRIMARY KEY AUTOINCREMENT を採用しているため、本書の表で TEXT と記した company_id / approach_id 等の既存テーブルを参照するカラムは INTEGER とする(本書独自のID(実験・バリアント・ライブラリ等)は TEXT の推測困難な文字列を使う)。実装時にこの対応表を最初に確定すること。

12. API設計(追加)

12.1 公開エンドポイント(認証不要 / LP配信・計測)

/c のレート制限: 1 visitor_id あたり 60イベント/分。超過分は破棄する(エラーを返さない)。

12.2 管理API(認証必須)

12.3 共通仕様

• 認証: 既存v1.2の方式を継承(案Bの場合は Cloudflare Access JWT による検証)
• レスポンス形式・エラーコード体系は v1.2 の 6.2 を継承する
• 非同期ジョブは 202 Accepted + job_id を返し、GET /api/jobs/{job_id} で進捗を取得する
• 全ての変更系APIは監査ログに記録する(操作者・日時・対象・差分)

12.4 定期実行(Cron)

13. 非機能要件

14. 法令・コンプライアンス

14.1 適用される法令・ガイドライン

14.2 インデックス制御の設計根拠(再掲・重要)

• 大量生成LPを検索インデックスに載せると、scaled content abuse および doorway pages に抵触するリスクがある
• 除外は <meta name="robots" content="noindex,follow"> で行う。robots.txt でブロックしてはならない(他ページからのリンク経由で検索結果に出うるため、確実な除外にならない)
• AdsBot を robots.txt で拒否してはならない(広告の品質評価・配信に支障)
• インデックスさせるページ(代表LP・記事)は、AI下書きに人が一次情報・独自データを加筆したものに限る

14.3 AI生成物の運用ルール

1. 人の承認なしに公開しない。例外を作らない(F-24 G-01)
2. 実績・数値・固有名詞はデータベースの値のみを使い、AIに創作させない(F-12.2.4)
3. 生成に使用したモデル名・プロンプトのバージョン・生成日時をバリアントに記録する(後から検証できるようにする)
4. 生成物に対する苦情・指摘があった場合、該当バリアントを即時停止できる緊急停止機能を持つ
5. 顧客名・事例の使用は、事例DB上で「公開許諾済み」フラグが立っているものに限る

14.4 運用ルール(推奨)

15. 段階導入計画

「50パターン生成」から作り始めない。受け皿(LP配信)と物差し(計測)を先に作る。 生成は最後でよい。

フェーズ0 — 基盤(1〜1.5か月)

フェーズ0だけで既に効果が出る。 既存メール営業のクリック先が「全社共通ページ」から「そのメールの訴求に合ったLP」に変わるだけで、CVRは改善しうる。

フェーズ1 — 実験(1〜1.5か月)

フェーズ2 — AI生成(1〜2か月)

フェーズ3 — パーソナライズ(1か月)

フェーズ4 — チャネル拡張(2〜3か月)

15.1 各フェーズの判断基準

フェーズを進める前に、必ず以下を確認する。前フェーズの成果が出ていないのに次へ進まない。

16. 今後の検討事項

17. 出典

Google 公式(検索・広告)

• Spam policies for Google web search — scaled content abuse の定義
• Google Search's guidance about AI-generated content
• Doorway pages
• Block search indexing with noindex
• Consolidate duplicate URLs
• Guide to optimizing for generative AI features on Google Search — llms.txt 不要の明言
• Destination requirements (Google Ads)
• About Quality Score for Search campaigns

Google Analytics / Web

• GA4 engagement rate and bounce rate
• GA4 User engagement
• Measurement Protocol reference
• GA4 Data API PropertyQuota
• About data thresholds
• web.dev LCP / INP / CLS

統計

• A Tutorial on Thompson Sampling (Russo et al., Stanford)
• Almost Optimal Exploration in Multi-Armed Bandits (Karnin, Koren, Somekh 2013) — Sequential Halving
• Two-proportion Z-test
• Optimizely: Test tips for low-traffic sites

日本のBtoBマーケティング

• BtoBのCPL相場一覧(start-link)
• リスティング広告のCPA(data-be.at)
• LinkedIn広告の費用(data-be.at)
• BtoBリスティング広告の業種別平均CPA(note)
• ウェビナー・イベントの参加率(リコー)
• ITreview 掲載料金(キャククル)
• BOXIL 広告掲載費用(キャククル)

日本の法令

• 特定電子メールの送信の適正化等に関する法律(総務省)
• 改正電気通信事業法による外部送信規律(のぞみ総合法律事務所)
• 外部送信規律と個人関連情報の第三者提供(JPAC)
• 2026年 個人情報保護法改正(牛島総合法律事務所)
• IPアドレスから得られる情報は個人情報にあたるのか(docodoco)

Cloudflare

• Workers limits / pricing
• Workers AI pricing / models
• D1 limits / pricing
• Workers Analytics Engine
• Durable Objects pricing
• Gradual deployments
• Full-stack development on Cloudflare Workers — Pages ではなく Workers 推奨
• 社内資料: cloudflare-feature-catalog-synon.md、cf-internal-app-starter/

改訂履歴

本書の数値・ベンチマークについて 外部の公開値は出典元により幅が大きく、当社の条件と一致するとは限らない。すべて初期値として扱い、運用開始後は自社の実測値に置き換えること。「公開データが見当たらなかった」と記した項目は、推測で埋めず実測で埋める。