クリエイター選定はフォロワー数で決めない。成果アセットから逆引きする方法

クリエイターを選ぶとき、多くの運用担当者はまずマーケットプレイスを開きます。フォロワー数の範囲を指定し、カテゴリーと地域で絞り込み、数百件の検索結果から見覚えのある名前を選ぶ。よくある手順ですが、出発点が違います。

フォロワー数、カテゴリー、地域が示すのは、その人が「どんな属性のクリエイターか」です。一方で本当に知りたいのは、成果が検証済みの広告クリエイティブと同じ構造のコンテンツを、その人が作れているかどうか。この2つは、しばしばまったく別の話です。

先に対象範囲を明確にしておくと、ここで扱うクリエイターディレクトリ、サジェストワード、アセットランキングはいずれも、各プラットフォームの公開クリエイターマーケティング機能およびクリエイティブセンターを、自分のアカウントでログインして利用したものです。署名の利用や制限の回避はしていません。本稿で扱うのは、公開データを意思決定につなげる方法です。

フォロワー数は遅れて効いてくる、ノイズの多い指標

フォロワー数を軸に選ぶ方法が構造的にズレる理由は、独立した3つあります。どれか1つだけでも十分です。まず、フォロワー数は過去の蓄積値です。その人が以前にバズったことは分かっても、今月も成果を出せるかは分かりません。2年前のヒットで100万人まで伸び、その後は勢いを失ったアカウントが、投稿ごとに小さな反応の山を作りながら伸びているアカウントより一桁上に表示されることもあります。欲しいのは後者です。次に、数値にはノイズが混ざります。購入フォロワー、自社カテゴリーと関係ないヒット、重ならないオーディエンス属性まで、すべてが1つの数字に押し込まれています。その総数から「自社に関係する視聴者が何人いるか」は取り出せません。さらに、フォロワー数順に並べれば必ず大手が先頭に来ます。単価も最も高くなりがちです。本当に費用対効果がよいのは、適切な構造でコンテンツを作れ、投稿単位のエンゲージメントも高い中堅層であることが多いのに、フォロワー数を主軸にすると、そこまでスクロールしない場所に埋もれてしまいます。

クリエイター検索のフィルターで、頼りすぎるべきでない項目

クリエイター検索のフィルターパネルには多くの項目がありますが、大まかには3種類に分けられます。

1つ目は属性タグです。フォロワー数帯、地域、言語、カテゴリーがこれに当たります。明らかに合わない言語や地域を除くための粗い絞り込みには使えます。ただし、選定の主軸にすると先ほどの問題にぶつかります。特にカテゴリーは危険です。たとえば同じ「beauty」タグでも、片方はレビュー動画、もう片方はコント動画を作っているかもしれません。自社に必要なのは、そのうち一方だけです。

2つ目はプラットフォームが算出したスコアです。中央値の再生数やエンゲージメント率は、蓄積値ではなく直近の動きを反映するため、フォロワー数よりは参考になります。ただし、これらは成果であって構造ではありません。その人のコンテンツが効いていることは示しても、なぜ効いているかは説明しません。クリエイター価値や受諾率のような複合スコアは、さらにプラットフォーム側のブラックボックスです。最適化しているのはプラットフォーム上の取引であり、自社のROIではありません。参考値にはなりますが、選定の主軸には向きません。

そして、本当に不足している3つ目の情報は、そもそもディレクトリにありません。それがコンテンツ構造です。フックが入る秒数、課題提起から始めるのか結果を先に見せるのか、ナレーションなのか寸劇なのか、訴求点をどこでどう組み込むのか。フィルターパネルにこの軸は1つもありません。しかし、クリエイティブを再現可能な形で横展開できるかを決めるのは、まさにここです。

成果アセットから構造を抽出し、クリエイターを逆引きする

フィルターディレクトリからコンテンツ構造は得られません。したがって、クリエイター側から順方向に絞り込むのは行き止まりです。起点にすべきなのはクリエイターライブラリではなく、自社の成果アセットライブラリです。「成果が出た」の定義もデータで置く必要があります。秒単位の視聴維持率がどこで落ちるか、クリックのピークが何秒目に来るか、CTRがカテゴリー内で何パーセンタイルに位置するか。こうした判定は視聴維持率カーブの記事で扱っています。ここでは、すでに基準を通過したアセット群がある前提で進めます。

各アセットから、フックの型、冒頭3秒の画面、訴求が出るタイミング、ストーリーの組み方といった構造的特徴を1件ずつ取り出します。それを構造特徴カードに圧縮し、勝ちアセットに共通する要素から「有効な構造プロファイル」を作ります。たとえば「課題提起で開始＋5秒目に結果を先出し＋実演者によるナレーション」といった形です。「コンテンツ品質が高い」のような曖昧な言葉ではなく、説明できる数個の構造要素に落とす必要があります。

その後、クリエイターライブラリへ戻ります。ただしフォロワー数では絞りません。構造プロファイルを使い、直近の投稿がその構造に合うクリエイターを逆引きします。見るべきなのは候補者が実際に投稿している動画の構造であって、フォロワー数ではありません。出力も、「フォロワーが50万人だから」ではなく、「直近3投稿が、自社の上位パーセンタイルのアセットと同じフック構造を使っているため推薦する」と説明できるものであるべきです。

サジェストワードは、プラットフォームが作ったコンテンツクラスタ

候補を扱える規模まで絞るうえで、最も有用で、過小評価されがちなのがサジェストワードです。検索ボックスでシードワードを入力した際に表示される関連語群は、サイト全体の行動データからプラットフォームが作ったコンテンツクラスタの投影と考えられます。シードに本当に隣接する語として展開されるため、思いつきで設定したカテゴリーより精度が高いことが多く、自社の分類体系にない方向性が1つか2つ混ざっていることも珍しくありません。最終回答として使うのではなく、シード拡張に使いましょう。自社で拾えていなかった隣接領域を広げ、その各領域で構造プロファイルに合うクリエイターを絞り込みます。

特徴抽出と類似性判定に使うモデル

このフローでモデルに任せる仕事は2つです。構造的特徴を抽出することと、2つの構造が似ているかを判断すること。どちらも単に「採点して並べる」仕事ではありません。欲しいのは0〜100の類似度ではなく、どこが一致し、どこが一致しないのかを明示する構造化された判断です。

4つの工程では、モデルに求める能力が異なります。

モデルを切り替えて結果が目に見えて変わるのは、3つ目の類似性判定だけです。項目抽出なら大半のモデルでできます。難しいのは、類似性判定で「不一致を言語化する」部分です。弱いモデルは高い類似度と、両者に共通する要素を言い直した段落を返しがちです。強いモデルなら、「プロファイルは結果先出しを求めているが、このクリエイターの直近3本は制作プロセスの実況型。フックは一致する一方、物語構造が違うため注意が必要」と言えます。必要なのは後者です。

鵜呑みにせず、実際に検証してください。手順は、リバースエンジニアリングの記事でアルゴリズムファミリー識別モデルを選定した方法と同じです。過去に起用し、成果が良かったと分かっているクリエイターを対照として選びます。有効な構造プロファイルとその人の直近コンテンツをclaude-opus-5とgpt-5.6-solに渡し、類似性判定が特定の動画まで根拠をたどれるかだけを見ます。「どの動画の、どの構造要素か」を示せる層を使うべきです。これはアルゴリズムフィンガープリントの記事でいう反証の質と同じです。高スコアであっても、きちんと疑義を出せるかを見ます。

本当の障害はモデルの切り替えコスト

3ベンダーにまたがる4つのモデル階層を使うとなると、SDKは3種類、認証方式も3種類、エラー形式も3種類です。工程ごとに階層を切り替えるために3つのクライアントをつなぐのは割に合いません。その結果、多くの人が最初から最後まで1つのモデルだけを使います。本来は推論モデルを使うべき類似性判定まで安価な層で済ませ、根拠を追跡できないスコアだけを大量に抱えることになります。

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

# Similarity judgment: the reasoning tier
curl https://aireiter.com/api/v1/chat/completions \
  -H "Authorization: Bearer $AIREITER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "messages": [{"role": "user", "content": "<effective structure profile + a creator recent-content list>"}]
  }'

# Extract structural-feature cards in bulk: change the model field, leave the rest
#   "model": "claude-sonnet-5"

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

料金面では、Claudeモデルは定価から30%オフ、GPTモデルは半額です。割引が効くのは主なコスト部分です。アセットを1件ずつ構造特徴カードへ変換する工程は、数百から数千件の大量呼び出しになります（Claude Sonnet 5）。呼び出し量は類似性判定の1桁から2桁上で、支出の大半を占めます。30%オフは、最もコストのかかる工程に直接効きます。

• APIキーを取得する

• 登録なしで試す：まずは既知のクリエイター1人を対象に、手作業で類似性判定を実行してください。特定の動画まで根拠をたどれるか確認してから、実装するかを決めるとよいでしょう。

マッチングを設定したら、次は有効な構造を生成ブリーフへ落とし込み、サイト内の画像・動画生成に渡してアセットをまとめて作ります。この一連のパイプラインは、クリエイターマッチングを1工程として含むキーワードから完成広告までの記事で扱っています。

検証の基準は、特定アセットまで根拠を追えること

このフローと、「モデルに大量のクリエイターを渡して何人か推薦させる」ブラックボックス型の手法を分けるのは、追跡可能性です。適格なマッチは、「クリエイターXを推薦する。その根拠は、Xの直近N本目の動画構造が、有効アセットYと一致するため」と分解できなければなりません。X、N、Yはすべて具体的である必要があります。どれか1つでも欠ければ検証できず、配信後のデータが返ってきたときにレビューもできません。したがって、プロンプトには追跡可能性を明記します。すべてのマッチについて、対応する具体的なアセットと構造要素を出させる。追跡できないものは、類似度がどれほど高く見えてもノイズとして捨てます。

まとめ

フォロワー数を動かし、カテゴリーと地域を重ねてクリエイターを選ぶ。標準的に見えるこの方法は、構造的に間違っています。絞り込んでいるのは属性タグであり、必要なのはコンテンツ構造の一致です。逆から進めましょう。成果クリエイティブから構造を抽出し、プロファイルを作り、その構造に合うクリエイターを逆引きする。そして、すべてのマッチを特定のアセットまで追跡可能にします。

フィルターディレクトリが返すのは静的なタグです。実際に成果を出したアセットが持つのは、再現可能な構造です。フォロワー数の列だけを見て、判断を止めてはいけません。