競合広告300本をモデルに読ませても、返ってくるのは形容詞4つ。やるべきことは別にある

公開されている広告ライブラリから競合の見出しを300本集めた。さて、競合が本当に何を訴求しているのか知りたい。このとき、300本をそのままチャットに貼り付けて「これらの広告の訴求ポイントを要約して」と聞くのは、もっとも手軽で、もっとも収穫の少ないやり方です。

返ってくるのはたいてい、「コストパフォーマンスを訴求している」「ユーザー体験を重視している」「緊急性を演出している」「明るく前向きな感情トーン」といった数行でしょう。広告を1本も読まずに書ける内容です。

データに問題があるわけではありません。各プラットフォームの広告ライブラリやクリエイティブセンターは公開されており、自分のアカウントで閲覧できます。何かを回避しているわけでもない。問題は問いの立て方です。集約された問いを渡せば、モデルも集約された答えしか返せません。300本の広告を形容詞4つに圧縮すれば、情報はほぼ抜け落ちます。残るのは、間違ってはいないけれど使い道のない記述です。

大量のコピー分析から実際に使える結果を得るには、まず「使える」とは何かを定義する必要があります。「お得感を押し出している」はアクションにつながりません。一方で、「節約の約束に数値による裏付けと期限を組み合わせた訴求が、このバッチの40%を占め、価格感度の高い層に向けられている」なら、次のクリエイティブで何を変数として設定すべきかが分かります。後者を得るには、1回で済ませようとしてはいけません。工程を2つに分けます。

「訴求を要約して」が曖昧な答えに終わる理由

ワンショット分析が失敗するのは、プロンプトの書き方が悪いからではなく、タスクの構造に原因があります。

モデルに同時に頼んでいるのは、性質の異なる2つの仕事です。1つは広告ごとの情報抽出。どんな約束をしているか、根拠を示しているかといった問いには、基本的に一意の答えがあります。もう1つは、抽出した情報の分類です。どの約束を同じカテゴリとして扱うか、境界をどこに置くかには判断が必要です。

この2つを1回の呼び出しに詰め込むと、モデルは近道を選びます。広告を1本ずつ抽出せず、テキストの塊から印象で要約し、聞き手が望みそうな前向きな形容詞を並べる。だから結果がぼやけます。

ワンショットには中間成果物も残りません。「コストパフォーマンスを訴求している」という結論が出ても、どの広告に基づくのか、何割を占めるのか、反例はあるのかをたどれない。別のバッチで再実行すれば結論も変わります。中間成果物のない分析は、レビューも改善もできません。

広告ごとの抽出とクラスタリングを分ける

正解は、間に構造化フィールドの層を置いた2段階の処理です。

第1段階では、コピーを1本ずつ固定スキーマに沿って分解します。最低限ほしい軸は4つです。中核となる約束、根拠の種類、緊急性の出し方、想定されるオーディエンス。この段階では広告を1本ずつ見て、説明文なしの厳格なJSONだけを返させます。

You will receive one ad headline. Break it apart along the fixed fields below.
Output JSON only, no explanation.

<copy>
{{one piece of copy}}
</copy>

Fields and allowed values (pick only from the given enum; when unsure pick
unknown; do not invent values):

- promise: [save money, save time, look better, get healthier, make money,
  learn a skill, belong, identity, unknown]
- evidence: [testimonial, data/numbers, authority, before/after, demo,
  none, unknown]
- urgency: [time limit, scarcity, price-rise warning, fear of missing out,
  none, unknown]
- audience: a short phrase, inferred from the wording, for who it's talking to
  (e.g. "night owls", "moms with kids", "junior designers")

Output:
{"promise":"...","evidence":"...","urgency":"...","audience":"..."}

300本を処理すれば、手元にあるのは300個のテキスト塊ではなく、300件の構造化レコードです。この時点で「訴求を要約して」は、曖昧な意味理解タスクから、集計・グループ化・分布の可視化ができるデータタスクに変わります。

第2段階がクラスタリングです。対象にするのは元のテキストではなく、抽出済みのフィールドです。生テキストをクラスタリングすれば、意味的な類似性という同じ霧の中に戻ってしまいます。フィールドなら、明確な境界を持つ少数の離散的な次元でグループ化できます。

クラスタリングでは反例を必ず出させる

クラスタリング用プロンプトで重要なのは、「グループ化して」ではありません。モデルに反例を持ってこさせることです。

Below are N ad headlines already extracted into structured records.
The categories are frozen. Do not add categories.

<records>
{{JSON array, each with promise/evidence/urgency/audience}}
</records>

Output three things in order:

1. Combination clustering
   Group by (promise x evidence x urgency), and give each group's record
   count and one representative sample.

2. Counterexample check
   For the top 3 groups by record count, pick one record per group whose
   audience clearly departs from the group's mainstream, and explain why it
   got grouped there. Is it really the same selling point, or did step one
   extract a field wrong?

3. Gaps
   Which combinations that should be common don't appear even once in this
   batch? Are those gaps "nobody's doing it" or "my sample didn't cover it"?

このプロンプトの価値は第2項にあります。モデルは自然に利用者を満足させようとするため、促さなければ、出してきたクラスタを不自然なほど整合的に見せがちです。自分で作ったグループから「合っていない1件」を取り出させると、モデルは結論を出したつもりになった後も検証を続けざるを得ません。分類の境界が粗すぎること、あるいは第1段階でフィールド抽出を誤ったことが見えてきます。

モデルに自分の仕事をつつかせる方法は、広告分析に限った話ではありません。コードのリバースエンジニアリングでは、これを反証セクションとして扱います。モデルがアルゴリズムの系統を特定したら、それを鵜呑みにせず、「標準実装とはどこが違うのか」と答えさせる。同じ原理は、難読化コードの扱いやアルゴリズムのフィンガープリント判定で、モデルが安易に同意へ寄る傾向を抑えるのにも使えます。コピーのクラスタリングでは、反例チェックがその反証セクションになります。

工程ごとに使うモデルを変える

この2段階でモデルに求める能力は正反対です。同じモデルを両方に使うのは、単純に無駄が大きいです。

コストが桁違いになるかどうかは、この役割分担で決まります。件数に比例して増えるのはフィールド抽出だけです。300本なら300回、1,000本なら1,000回の呼び出しになります。一方、クラスタリングはバッチごとに1回です。1〜2回しか実行しないクラスタリングには高価な推論ティアを使い、数百回走る抽出には最安ティアを使う。この設計だけで総額は10倍変わります。

逆に、抽出を高価なティア、クラスタリングを安価なティアにすると、よくある無駄になります。抽出にそこまでの推論力は不要なのにコストをかけ、安価なティアがもっとも苦手とするクラスタリングで失敗するからです。

どこまでティアを下げられるかは、私の言葉を信じるより、まず1回比較すれば分かります。

1. すでに集めた広告から20〜30本を取り出します。

2. フィールド抽出では、同じバッチをclaude-sonnet-5とclaude-opus-5の両方に通し、4フィールドがレコード単位でどれだけ一致するかを比較します。

3. クラスタリングでは、同じ抽出済みレコードを両ティアで処理し、2点を確認します。反例チェックが本当にグループを掘り下げているか、それとも候補を言い換えているだけか。さらに、ギャップが次に取るべきアクションを示しているかです。

4. 結果の読み方は明快です。抽出の一致率が高ければ、この工程は安価なティアに落としてコストを削れます。安価なティアがクラスタリングで有用な反例を出せないなら、その工程は推論ティアに残します。

罠1：カテゴリをモデルに勝手に作らせる

抽出時にenumを渡さず、カテゴリをモデルに発明させる。これはもっとも入りやすい罠です。

最初のバッチだけ見れば問題なさそうです。もっともらしいカテゴリ群が返ってきます。しかし2つ目のバッチでは、同じ種類のコピーを扱っているのにカテゴリ名が変わり、粒度がずれ、境界も動きます。2つのバッチを並べてトレンドを見ようとしても、対応しません。1つ目の「discount」と2つ目の「save money」は同じなのか。誰にも分かりません。バッチごとにカテゴリが漂流すれば、バッチ横断の比較はすべて見せかけになります。

対策は、カテゴリを決める仕事と、カテゴリを使う仕事を分けることです。まず長文コンテキスト向けのティアで、大量のサンプルを一度に読みます。数百件をまとめて読むのは、まさに長文コンテキストの仕事です。そのうえで、網羅性があり粒度の揃ったenumを導き、手作業でレビューして固定します。

以後の抽出では、固定済みenumからしか選ばせません。該当しないものはunknownに入れ、その場で新カテゴリを作ることは許さない。抽出プロンプトにある「pick only from the given enum, do not invent」という一文は、この制約を具体化したものです。

一言でいえば、カテゴリを決めるのはあなたであり、モデルは箱を埋めるだけです。

罠2：出現頻度を有効性と混同する

抽出とクラスタリングを終えると、レコード数で並べ替え、もっとも頻出する訴求を「もっとも効く訴求」と見なしたくなります。これは見落としやすい間違いです。

頻度が示すのは、「みんながこの書き方をしている」ことだけです。「この書き方が効いている」ことではありません。広告には模倣の連鎖が実際にあります。ある広告が当たると、1週間も経たないうちに市場全体が追随し、クリエイティブセンターには似た見出しが一夜で何十本も並びます。頻度を数えると、その模倣もすべて含まれます。その結果、「この訴求がもっとも人気だ」と結論づけても、実際には全体として成果が出ておらず、誰も先にやめていないだけかもしれません。頻度が測るのは同調であって、効果ではありません。

頻度と有効性を分けるには、各レコードに効果データを紐づける必要があります。公開広告ライブラリの各アセットには、再生数、いいね数、CTRなどのフィールドがあります。本来並べ替えるべきなのは生のレコード数ではなく、「特定の訴求組み合わせのうち、高パフォーマンスのパーセンタイルに入る割合」です。秒ごとの視聴維持率やCTRパーセンタイルを意味のあるシグナルとして読む方法は、別の記事で扱っています。ここで強調しておきたいのは、頻度表と効果表は別々の表でなければならないことです。1つに混ぜた瞬間、結論は壊れます。

この段階でのモデルの仕事は並べ替えではなく、要因帰属です。頻度の高い組み合わせとその効果分布を中程度の推論ティアに渡し、「この頻度は効いているから高いのか、それとも互いに模倣しているから高いのか」と聞く。数値に照らして判断させます。ここで要因帰属を誤っても、最終的には実際の効果データで検証するため、コストは大きくありません。

罠3：勝ち広告だけを分析する

3つ目の罠はデータソースに潜んでいます。注意しないと存在にも気づきません。広告ライブラリやクリエイティブセンターは、デフォルトでうまく配信された広告を見せてくれます。「hot ads」や「Top Ads」といった項目は、実質的にプラットフォームがパフォーマンスで事前選別した生存者です。

勝ち広告を集めてクラスタリングし、「成功する広告の共通点」を見つけて真似する。これは典型的な生存者バイアスです。失敗した広告にも、まったく同じ特徴がある可能性が高いからです。たとえば勝ち広告の90%に「time limit」が使われていて、「期限訴求は効く」と結論づけたとします。しかし失敗した広告の90%にも同じく期限訴求があれば、その特徴には識別力がありません。成功・失敗とは関係なく、業界の標準になっているだけです。

対策は、勝ち広告に対照群を用意することです。公開広告ライブラリでは通常、業界、マーケティング目標、期間で絞り込めます。同じフィルタを使い、インプレッションは得たもののエンゲージメントが明らかに低いアセットにも到達します。それらも抽出・クラスタリングし、勝ち広告群と並べます。価値があるのは「勝ち広告が持つもの」ではなく、「勝ち広告にはあって負け広告にはないもの」という差分集合です。その差分集合に現れる特徴だけが、次のアセットに書き込む価値を持ちます。

完全な負け広告サンプルは得られません。それで構いません。小規模でも低パフォーマンスの対照群があれば、Top Adsだけから導いた結論よりはるかに信頼できます。

最終成果物は要約ではなく変数表

2段階の処理を踏み、3つの罠を避けたなら、最終成果物は「このバッチの競合はXXを訴求している」という文章であってはいけません。それでは再び曖昧な要約に戻ってしまいます。必要なのは変数表です。

• 各次元（promise、evidence、urgency、audience）が取り得る値。

• すでに有効性が裏付けられた組み合わせ。差分集合に入り、かつパフォーマンスのパーセンタイルが高いものです。

• まだ誰も試していない組み合わせ。ギャップ分析から掘り出したものです。

この表は、そのまま生成タスクの入力に使えます。有効性が確認された組み合わせは、バリエーションを量産する対象へ。空白の組み合わせは、低コストで試すプローブへ回せます。コピー次元の変数はテキストモデルに渡してスクリプトを書かせ、ビジュアルやトーンの変数は画像・動画モデルに渡してアセットを作る。競合コピーから自社の完成した広告までの線がつながります。この変数表は、クリエイティブパイプラインのブリーフ工程が読むものでもあります。

クラスタリングの目的は、見栄えのよい分類チャートを作ることではありません。次の制作バッチを動かす変数表を作ることです。

4つのティアを1つのキーで使い分ける

ここまでのフローには4つのティアが必要です。抽出用の安価で高並行なティア、カテゴリ設計用の長文コンテキストティア、クラスタリング用の推論ティア、要因帰属用の中程度の推論ティアです。これらは複数ベンダーにまたがり、SDK、認証方式、エラー形式もそれぞれ異なります。

工程ごとにモデルを切り替えるためだけに複数のインターフェースをクライアントへつなぐのは、割に合いません。これが、多くの人が結局は全工程を1モデルで済ませ、先ほどの無駄に行き着く本当の理由です。高価なティアを抽出で燃やすか、クラスタリングで反例を出せない安価なティアに頼るかのどちらかになります。

AIReiterは、この層を一本化します。キーは1つ、インターフェースはOpenAI互換の1つ。その背後に4つのティアがあり、リクエストボディのmodelフィールドを変えるだけで切り替えられます。

# Extract fields: the cheap high-concurrency tier
curl https://aireiter.com/api/v1/chat/completions \
  -H "Authorization: Bearer $AIREITER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "messages": [{"role": "user", "content": "<extraction prompt + one piece of copy>"}]
  }'

# Cluster: switch to the reasoning tier, leave the rest
#   "model": "claude-opus-5"
# Frequency attribution:
#   "model": "gpt-5.6-sol"

すでにOpenAI SDKを使っているなら、base_urlをhttps://aireiter.com/api/v1に向けるだけで、ほかは変える必要がありません。Anthropic SDKでは、同じキーでPOST /api/v1/messagesを呼び出します。

価格面では、Claudeモデルは定価から30%オフ、GPTモデルは半額です。そして、この割引がもっとも効くのがこのフローです。件数に比例して増える工程はフィールド抽出だけで、300本なら300回、1,000本なら1,000回になります。ここを最安のSonnetティアで処理し、さらに30%オフが乗るため、削減額の大半を占めます。クラスタリングと要因帰属はバッチごとに数回しか走らないため、ここで推論ティアを使っても負担は大きくありません。カテゴリ設計は、同じキーで利用できる長文コンテキストのKimi K3を使い、バッチごとに1回実行します。

• APIキーを取得する

• 登録なしで試す：まずは数本の広告を手作業で処理し、抽出結果の一致度とクラスタリング時の反例について、安価なティアと推論ティアを比較してください。手応えを確認してからスクリプト化すれば十分です。

まとめ

大量の広告コピー分析が曖昧な答えに終わるのは、モデルが弱いからではありません。抽出と分類を1回の呼び出しに押し込んでいるからです。

広告ごとに、固定enumに沿った構造化フィールドを抽出する。これを数百回、安価なティアで回す。その後、フィールドをクラスタリングし、モデルには反例も出させる。こちらは推論ティアで1回実行する。途中では3つの罠を警戒します。モデルにその場でカテゴリを発明させないこと。頻度を有効性と読まないこと。勝ち広告には対照群を与えることです。最後に残すのは「コストパフォーマンスを訴求している」という一文ではなく、次の制作バッチを動かす変数表です。

このフローにおけるモデルは、実質的に別々の2つの道具です。安価な抽出器と、自らの結論を検証できる分類器。役割に合ったティアで別々に使えば、数百本の広告から実行可能な示唆が得られます。1つのモデルにまとめてやらせれば、残るのは形容詞だけです。