広告会社で新しい案件の企画を始めるときに、過去のクリエイティブのABテストの記録から似た訴求の勝ち負けを探し、訴求の仮説の根拠として示す

処理の起点を決める

取り込みと検索で、きっかけが2つあります。

取り込みは、テストの終了です。 運用チームが毎週の締めでテストの勝ち負けを決めた時点で、その組を索引に入れます。終わっていないテストは入れません。 途中の数字で勝ち負けを付けると、最後にひっくり返った組が「勝ち」として残ります。

検索は、企画メモの登録です。 プランナーが企画メモの欄を埋めて登録すると動きます。オリエンの資料を丸ごと入れる形にはしません。 資料には広告主の売上や販売計画が書かれており、それを検索の入力に使うと、検索の記録にまで広告主の秘密が残ります。検索に使うのは、プランナーが書いた商材・ターゲット・狙い・試したい方向の4欄だけです。

同じ企画メモで、方向を変えて何度も探すことを前提にします。1回の検索で答えを出させる設計にはしません。

入力データを集める

質を決めるのは、訴求の型と閲覧の区分の2つです。 訴求の型が無ければ、意味で探す対象は文面そのものになり、「初回無料」と「返金保証」が同じ不安の解消の訴求だと分かるかは埋め込み次第になります。 閲覧の区分が無ければ、どの記録を誰に見せてよいかを検索のたびに人が判断することになります。

訴求の型の分類表は、10個前後に絞ります。 価格・お得、機能・性能、不安の解消、権威・実績、限定・期間、共感・物語、手軽さ・すぐ使える、口コミ・利用者の声、比較・乗り換え、その他。細かく分けすぎると、1つの型に入るテストが数件になり、勝ち負けの組として並べる意味が薄れます。

データの取得方法を決める

取り込みは、配信レポートからテストの組を1行、案を1件として取り出します。テストの組と案は親子の関係で、検索で返すのは案、並べるのは組です。

勝ち負けの帯は、取り込みのときに Lambda が計算します。 同じテストの案どうしで、コンバージョン率（コンバージョンが少ない媒体ではクリック率）の差を見て、「勝ち」「負け」「差なし」の3つを付けます。差が小さいもの、表示回数が社内で決めた下限に届かないものは「差なし」です。この判定に統計のどの方法を使うかは、運用チームの社内の基準に合わせます。 ここで大事なのは方法の選び方ではなく、同じ基準を全テストに当てることです。

共有版の索引には、実数を入れません。 入れるのは、勝ち負けの帯と、差の大きさの帯（大・中・小）だけです。広告主名と商品名は伏せ、業種と商材の区分（「月額制の学習サービス」など）だけを残します。 伏せ方は取り込みのときに機械で行い、検索のときに伏せる設計にはしません。検索のときに伏せる設計だと、1か所の伏せ忘れで実数が出ます。

AIへ渡す前に整形する

1. テストの完了の確認 … 勝ち負けが決まったテストだけを取り込みます。途中で止めたテストは「中止」として別に残します
2. 案の中身の書き起こし … バナーは文字要素を、動画は冒頭・展開・締めの3つに分けた構成を文字にします。画像そのものは索引に入れません
3. 訴求の型の下書きと確定 … Claude API に型と要約を下書きさせ、運用担当が確定します。確定していない案は検索の対象に入れません
4. 勝ち負けの帯の計算 … 同じテストの案どうしで比べ、「勝ち」「負け」「差なし」を付けます
5. 共有版への変換 … 広告主名・商品名・ブランド名の一覧を使って伏せ字にし、実数を帯に置き換えます
6. 埋め込み … 訴求の要約と、案の文面を1つの文章にまとめて埋め込みます。文書側の埋め込みと検索側の埋め込みに同じモデルを使います
7. 企画メモの整形 … 検索のときは、4欄のうち空欄があっても止めず、書かれた欄だけで探します

3番目を人の確定にしているのは、訴求の型が検索の軸そのものだからです。 型の付け間違いは、そのまま「似た訴求」の取り違えになります。1テストあたりの確定は1〜2分で、運用担当が締めの作業のついでに行える量にします。

5番目で使う伏せ字の一覧は、営業管理の台帳から作り、受注の手続きのたびに商品名を足します。

AIに処理させる

生成AIの仕事は、取り込みと検索で1つずつです。 検索そのもの（どの案が近いか）は OpenSearch が点数で決め、生成AIは点数を付けません。

検索の側で生成AIが読むのは、OpenSearch が返した上位の組だけです。 上位20件の案を組ごとにまとめると、多くの場合8〜12組になります。それぞれの組について、比べた案の文面、訴求の型、勝ち負けの帯を渡します。

4行目がいちばん起きやすい失敗です。 共有版の文面に特徴的な言い回しが残っていると、生成AIは「おそらく大手の〇〇社の案件」と書きます。伏せ字にした意味が、説明文の1行で消えます。 指示で禁じたうえで、出力に広告主名の一覧の語が含まれていないかを Lambda で確かめます。

指示内容を固定する

検索の側の指示です。 取り込みの側（訴求の型の下書き）は、分類表を渡して型と要約を返させるだけの短いものです。

あなたは広告会社のストラテジックプランナーの調べものを手伝う立場です。
新しい企画のメモと、検索で見つかった過去のABテストの組を渡します。
組ごとに、何と何を比べてどちらが勝ったかを説明してください。

【企画メモ】
商材：{product}
ターゲット：{target}
狙い：{goal}
試したい方向：{direction}

【検索で見つかったテストの組】{test_groups}
（組ごとに test_id、媒体、業種、商材の区分、案の一覧が入っています。
　案ごとに variant_id、訴求の型、文面または構成、結果の帯があります）

【書くこと】
1. 組ごとに、比べた案の訴求の違いを1〜2文で書く
2. 結果の帯をそのまま写す（win / lose / no_diff）
3. 企画メモのどの欄と、どこが近いと判断したかを書く
4. 企画メモと条件が違う点（媒体、ターゲット、商材の価格帯など）を書く

【厳守事項】
- 結果の帯を書き換えないでください。文面の印象で勝ち負けを判断しないでください。
- no_diff の組を「やや勝ち」「傾向がある」と書かないでください。
- 表示回数・クリック率・コンバージョン率などの数値を書かないでください。
  渡していない数値を推測で補わないでください。
- 広告主名・商品名・ブランド名を推測しないでください。
  伏せ字の部分は伏せ字のまま扱ってください。
- どの訴求で行くべきか、どの案が良いかの結論を書かないでください。
- 訴求の型ごとの勝ち数を数えないでください。
- 渡した組の順番を変えないでください。
- 企画メモと近いと言えない組は、near を false にし、理由を書いてください。
  無理に近い点を探さないでください。
- 文面に書かれていないことは「不明」としてください。

「no_diff を傾向と書かない」を独立させているのには理由があります。 差なしの組を渡すと、生成AIは文面を読んで「わずかに価格訴求が上回った」と書きがちです。差が無いという結果は、それ自体が企画の材料です。 「価格を前に出しても変わらなかった」は、価格以外の訴求を試す理由になります。

「近いと言えない組は near を false に」も明記します。 何も言わないと、検索が返した組のすべてに近い理由をこじつけます。プランナーが捨てる組を素早く見分けられることも、調べものの時間を減らす要素です。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に JSON スキーマを渡す方式）を使います。

{
  "memo_id": "",
  "index_scope": "internal | shared",
  "groups": [
    {
      "test_id": "",
      "media": "",
      "category": "",
      "variants": [
        { "variant_id": "", "appeal_type": "", "result_band": "win | lose | no_diff" }
      ],
      "contrast": "",
      "near": true,
      "near_reason": "",
      "differences": ""
    }
  ]
}

1つ目の理由は、組を壊さずに返せることです。 自由文で受けると「価格訴求の案が勝った」という1文になり、何と比べて勝ったかが抜け落ちます。 variants に比べた案をすべて並べることで、負けた案の文面も一緒に画面に出せます。

2つ目は、result_band を検算できることです。 生成AIが写した帯を、Lambda が索引の値と突き合わせます。1つでも違えば、その組の説明を捨てて帯だけを表示します。 指示で禁じるだけでなく、後段で必ず確かめます。

3つ目は、near で絞り込めることです。 画面では near が true の組を上に、false の組を折りたたんで下に出します。

型ごとの勝ち数は、JSONではなく Lambda が数えます。 画面の上部に次の表を出します。

この表は、検索で返った組の中だけの数です。 全テストの集計ではありません。画面にもそう書きます。

システムへ連携する

検索のリクエストは次の形です。 match の句と knn の句を hybrid に並べ、filter で業種と閲覧の区分を絞ります。

GET /creative-tests-shared/_search?search_pipeline=appeal-hybrid
{
  "size": 20,
  "query": {
    "hybrid": {
      "queries": [
        { "match": { "copy_text": { "query": "{product_terms}" } } },
        { "knn": { "appeal_vector": { "vector": [0.01, 0.02], "k": 50 } } }
      ],
      "filter": {
        "bool": { "must": [
          { "terms": { "category_group": ["{category}"] } },
          { "term": { "status": "confirmed" } }
        ] }
      }
    }
  }
}

検索パイプラインは、キーワードの句に0.3、ベクトルの句に0.7の重みを付けて始めます。 公式ドキュメントの例と同じ配分で、min_max で正規化して arithmetic_mean で合わせます。この重みは出発点で、第8章の試しと運用の記録を見て動かします。

社内版の索引を使うのは、企画メモの広告主と、検索した人の担当チームが一致したときだけです。 判定は Lambda が営業管理の台帳を引いて行い、画面からはどちらの索引を使うかを選べないようにします。

人が確認する

人が確認するのは、取り込みの段階と検索の段階の2か所です。

1. 訴求の型の確定（取り込み） … 運用担当が、生成AIの下書きした型と要約を確かめます。型を直したら、直した理由を1行残します
2. 組の取捨（検索） … プランナーが、返ってきた組から使うものを選びます。負けた案の文面も必ず読みます
3. 条件の違いの確認 … differences に書かれた媒体・ターゲット・価格帯の違いを見て、その組を根拠にしてよいかを判断します
4. 共有版の記録を広告主に見せる前の確認 … 企画書に過去の組を載せるときは、伏せ字のまま載せ、ディレクターが確かめます

2番目で「負けた案も読む」を求めるのは、勝った案だけを見ると訴求の差が分からないからです。 「初回無料」が勝ったとき、負けた案が「月額980円」なのか「30日返金保証」なのかで、学べることがまったく違います。

目標は、1件20分です。 内訳は、組を見比べて取捨するのに15分、企画メモに書き込むのに5分です。それより長くかかる月は、検索が近くない組を多く返しているか、訴求の型の付け方がばらついています。

例外に対処する

上から2行目までを「正常な結果」として扱うのが大事です。 前例が無いことは、企画にとっては新しい訴求を試す理由になります。検索が何かを返さなければならない設計にすると、遠い組を近いと言い張る説明が生まれます。

最後の行は、判定に迷ったら狭いほうに倒すという原則です。 台帳の整備漏れで、競合の担当チームに実数が出る経路を作らないためです。

記録を残す

• 企画メモの4欄と、検索した人・日時・使った索引（社内版／共有版）
• OpenSearch が返した案と点数、使った検索パイプラインの重み
• 生成AIに渡した組と、返ってきたJSON
• プランナーが選んだ組と、選ばなかった組
• 訴求の型を人が直した記録と、その理由
• 説明を捨てた記録（帯の不一致、広告主名の検出）

4つ目が、検索を良くする材料になります。 選ばれた組と選ばれなかった組の対は、そのまま重みの見直しに使う評価用のデータになります。

最後の行は、伏せ字の一覧の穴を見つけるために残します。 同じ広告主の語で説明が捨てられ続けているなら、取り込みの段階の伏せ字が足りていません。