過去に制作したバナー・コピー・動画の台本を、業種・訴求・媒体・成果で探し、新しい制作の参考になるものを根拠付きで出す

処理の起点を決める

取り込みと検索で、起点が2つあります。

取り込みは、制作管理表で制作物が「納品済み」になったことを起点にします。 制作途中の版や、広告主に出す前の案は取り込みません。採用されなかった案を、実際に配信されたもののように見せないためです。 ただし、比較用に作ったAパターン・Bパターンは両方とも配信されるので、両方を取り込みます。

成果の帯は、毎月の配信実績のレポートが出た日に書き込みます。 配信が終わって間もない制作物は数字が少なく、帯を付けません。表示回数が一定に達するまでは「判定前」とします。

過去5年分の約4万本は、別に一括で取り込みます。 訴求の区分は担当者の確認が取れないので、「未確認」の印を付けて区別します。

検索は、プランナーやデザイナーが検索画面で「探す」を押したときに動きます。

入力データを集める

質を決めるのは、業種と訴求の区分です。 業種が「化粧品」「コスメ」「スキンケア」とばらばらでは、絞り込みが効きません。業種は30程度、訴求は20前後の区分に先に固定します。 区分を後から変えると、全件の付け直しになります。

配信実績と制作物の対応は、運用担当の手元の表を1つにまとめるところから始めます。 制作物番号を広告の名前に入れる運用にすれば、以後は対応表が要らなくなります。

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

1件の単位は、制作物1本です。 動画は台本と代表のコマを、1本の制作物としてまとめます。

埋め込みは、Cohere Embed v4 の inputs で作ります。 1件の入力に、制作物の文字（業種、媒体、フォーマット、コピー）と画像を並べ、input_type は search_document にします。検索時の文章やラフの画像は search_query で埋め込みます。 取り込みと検索で input_type を取り違えると、近さの計算がずれます。

絞り込みは、k-NN のクエリの中に書きます。

{
  "size": 20,
  "query": {
    "knn": {
      "embedding": {
        "vector": [0.021, -0.008],
        "k": 20,
        "filter": { "bool": { "must": [
          { "term": { "industry": "スキンケア" } },
          { "terms": { "media": ["SNS_A", "SNS_B"] } },
          { "terms": { "advertiser_group": ["G01", "G07"] } }
        ] } }
      }
    }
  },
  "aggs": {
    "by_appeal": { "terms": { "field": "appeal", "size": 20 } },
    "by_band": { "terms": { "field": "perf_band" } }
  }
}

ラフの画像で探すときも、search_query で埋め込みます。 手描きのラフは完成したバナーと見た目が違うので、依頼の文と一緒に入れたほうが近いものが出やすいと考えられます。 検索画面では、文とラフの両方を入れられるようにします。

絞り込みを k-NN の外に書かないでください。 近いものを先に20件引いてから業種で絞ると、20件のうち業種の合うものが2件しか残らないことが起きます。中に書けば、絞り込んだ範囲の中から20件を引けます。Faiss の場合、絞り込んだ件数が少なければ全件を比べる検索に切り替わるので、件数の少ない業種でも取りこぼしにくくなります。

件数の集計は terms 集計で返します。 訴求ごとの件数が並ぶと、「この業種では価格訴求が多く、体験談の訴求はまだ少ない」が見えます。terms 集計の既定は10個までなので、訴求の区分の数に合わせて size を20にします。項目は keyword 型である必要があります。

AIへ渡す前に整形する

1. 画像の形式と大きさ … Cohere Embed v4 に渡す画像は png・jpeg・webp・gif で、1枚5MBまでです。大きなものはサムネイルを作って渡します
2. 画像の縮小 … 2,458,624ピクセルを超える画像は縮小され、3,136ピクセル未満は拡大されるとされています。小さなバナー（320×50など）は拡大されるので、文字は別に渡します
3. 画像の中の文字 … バナーに入っているコピーは、制作データの文字の層から取り出します。取れないものは Claude に画像から読ませ、担当者が確かめます
4. 動画の代表のコマ … 冒頭・中盤・終盤の3コマを選び、台本の文字と一緒にします
5. 要求の大きさ … 1回の要求は96件まで、全体で約20MBが上限です。一括の取り込みはこの範囲に分けます
6. 広告主名の扱い … 画像の文字と属性に含まれる広告主名と商品名に印を付けます。閲覧の制限と、第13章の伏せ方に使います
7. サイズ違いの束ね … 同じデザインのサイズ違い（300×250と728×90など）は、1本の制作物の派生として束ね、検索結果に同じデザインが並ばないようにします
8. 成果の帯の計算 … 同じ媒体・同じフォーマットの制作物の中で、クリック率を並べて上位25％・中位・下位25％に分けます。表示回数が足りないものは「判定前」です

2番目を軽く見ないでください。 横長の小さなバナーは拡大されてぼやけ、画像の中の文字は埋め込みにほとんど効きません。 文字は必ず文字として一緒に渡します。

8番目は、第3章の（c）への答えです。 媒体をまたいで数字を比べるのをやめ、同じ土俵の中での位置だけを示します。

AIに処理させる

AIの仕事は2か所です。取り込み時の区分の下書きと、検索結果の理由づけです。

いちばん下の行が、いちばん起きやすい失敗です。 上位の帯のバナーを見せると、「人物の笑顔が効いた」のような理由を自信をもって書きます。 配信の時期、予算、ターゲットの設定が違えば、同じ見せ方でも結果は変わります。理由の推測は、制作者どうしの打合せに任せます。

指示内容を固定する

取り込み時（訴求の区分の下書き）

あなたは広告会社のクリエイティブ局で、納品済みの制作物を整理する担当です。
画像と文字を見て、訴求の区分と見せ方の特徴を付けてください。

【訴求の区分】次の一覧から最大2つ選んでください。一覧に無い区分を
作らないでください。当てはまらなければ「該当なし」としてください。
{appeal_list}

【見せ方の特徴】次の項目について、画像から読み取れることだけを書いてください。
- 人物の有無（有／無）　- 価格の表示（有／無）　- 主な色調
- 商品の写り方（単体／使用場面／なし）　- 行動喚起の文言（画像の中の文字を写す）

【厳守事項】
- 人物が誰かを書かないでください。
- 画像の中の文字が読み取りにくいときは、copy_text を空にし、
  text_unreadable を true にしてください。推測で埋めないでください。
- 成果や効果についての評価を書かないでください。

検索時（候補の理由づけ）

あなたは制作の参考を探す手伝いをします。新しい依頼と、検索で引いた
過去の制作物の候補を見比べ、1件ずつ「どこが近いか」を書いてください。

【厳守事項】
- 理由は、候補の項目（業種・訴求・媒体・フォーマット・見せ方の特徴・
  コピーの文字）と画像から読み取れることだけを根拠にしてください。
- 成果の帯、クリック率などの数字を書かないでください。表示はこちらで行います。
- 「この見せ方が成果につながった」のように、成果の理由を書かないでください。
- 近いと言えない候補は match を false にし、理由を1文で書いてください。
  無理に近い点を探さないでください。
- 広告主名と商品名を理由の文に書かないでください。

【新しい依頼】業種：{industry}／訴求：{appeal}／媒体：{media}／
  依頼の文：{brief_text}／ラフの画像：{rough_image}
【候補】{candidates}  ※1件ずつ「候補1：」のように番号を付けて画像と項目を渡す

「無理に近い点を探さない」を書かないと、全件に近い点を見つけます。 検索で引いた以上どれかの点は近いので、20件すべてに「訴求が同じ」と書かれ、見比べる意味がなくなります。

候補に番号を付けて渡すのは、複数の画像を区別させるためです。 公式のガイドでも、複数の画像を送るときは Image 1: のような短いラベルを付けることが勧められています。

出力形式を固定する

検索時は、次の形のJSONで受け取ります。

{
  "results": [
    {
      "candidate_no": 1,
      "creative_id": "",
      "match": true,
      "match_points": ["訴求が同じ（限定・期間）", "商品の使用場面を大きく見せている"],
      "differences": ["媒体のフォーマットが縦長"],
      "reason": ""
    }
  ]
}

JSONで受け取る理由は、表示とAIの出力を分けるためです。 検索画面には、サムネイル・成果の帯・権利の状態を OpenSearch の項目から表示し、AIの出力からは match_points と differences だけを並べます。数字と権利の状態がAIの文章に混ざらないので、写し間違いが起きません。

creative_id は、渡した候補の番号と照らします。 返った番号が候補に無ければ、その行は表示しません。

terms 集計の件数は、近似になることがあります。 公式ドキュメントでは、シャードが複数あるとき、件数の誤差の上限が doc_count_error_upper_bound として返るとされています。件数は傾向を見るためのもので、正確な本数が要るときは別に数えます。

システムへ連携する

制作管理表とファイルサーバーには書き込みません。 訴求の区分を確定した結果も、OpenSearch の側に持ちます。元の制作データを、検索の仕組みが書き換えることはありません。

人が確認する

1. 取り込み時：訴求の区分を確定する … 納品の直後に、作った本人が下書きを確かめます。直すのは区分だけで、数秒で済みます
2. 検索時：候補を自分の目で見る … サムネイルを開き、近い点・違う点を読みます
3. 成果の帯を鵜呑みにしない … 帯は結果で、理由ではありません。上位の帯の制作物は、配信の条件を運用担当に確かめてから参考にします
4. 権利の状態を確かめる … 「参考のみ」「期限切れ」のものを、そのまま流用しません

「未確認」の印の付いた過去の制作物は、使う前に区分を確かめます。 一括で取り込んだ4万本は、訴求の区分がAIの下書きのままです。参考に選んだときにその場で直してもらうと、使われるものから順に確かになります。

目標は、360件をならして1件10分です。 絞り込みと候補の理由づけで見る数が減り、成果の帯と権利の状態が最初から並びます。残る10分は、候補を見比べて選ぶ時間です。 これは制作者の判断なので、減らしません。

例外に対処する

3行目がいちばん大事です。 対応の取れない数字を推測で付けると、別のバナーの成果を参考にすることになります。 帯が付かないことは、正しい表示です。

記録を残す

• 取り込んだ制作物と、そのときの属性・権利の状態
• 訴求の区分の下書きと、担当者が確定した区分（直した場合はその差）
• 成果の帯を計算したときの元の数字と、計算した月
• 検索の条件（絞り込み、文章、ラフの画像の有無）と、返った候補の番号
• 候補のうち、打合せの資料に使われたもの

2つ目の差は、区分の一覧を見直す材料になります。 特定の区分ばかり直されているなら、その区分の定義があいまいです。

最後の行は、検索の質を測る数字になります。 上位に出たのに使われない候補が多ければ、埋め込みに渡す文字の組み立てを見直します。