influencer-discovery

インフルエンサーの発掘

エビデンスに裏付けられたクリエイター候補を複数のプラットフォームから見つけ、明示された発掘フィルターに照らして審査し、型付きのFit評価に向けた順位付けなしの準備キューを作成します。

クイックスタート

Find 20 influencers in [niche] for [brand/product]

Find influencers in [niche] with 50K-200K followers on TikTok and Instagram,
based in [location], engagement above 4%, who have worked with brands like [brand]

スキルの契約

• 読み取り：ブランド／製品、ニッチまたはカテゴリ、対象プラットフォーム、フォロワー数の範囲、エンゲージメントの下限、意思決定に関係する地域／言語、オーディエンスの属性、除外条件。ユーザーのエクスポート、公開ソース、名簿、またはライブコネクターから取得した日付付き候補レコード。指定されている場合は、現在のキャンペーンのSTAR evidence_window。メモリに存在する場合は、以前のentity-registryのブランドプロフィールとaudience-mapperの出力。memory/creators/内の既存の名簿レコード（重複排除は、creator-registryによってすでに名簿に登録されているクリエイターとの、検証済みの本人確認リンクを通じてのみ行います）。
• 書き込み：デフォルトでは発掘結果をインラインで返します。別途、厳密な許可がある場合に限り、memory/influencer/influencer-discovery/YYYY-MM-DD-<topic>.mdに保存します。保存する成果物では、安定した不透明なcreator_refと、仮名化したrecipient_ref、contact_source_ref、agency_refを使用し、元のハンドル、プロフィールURL、連絡先情報は一時的なものとして扱います。また、地域情報は明示されたフィルターに必要な粒度でのみ保持します。許可されたソース成果物または検証済みのcreator-registryリンクから解決できる場合に限り、不透明なhandle_ref／source_refの本人確認リゾルバーを保存します。それがない場合は、identity_status: unresolvedを保持し、隠れた元ロケーターの対応表は保存せず、cross_session_locator_required: trueを設定します。検証済みのcreator-registry集約IDが存在する場合は再利用します。それ以外の場合は、候補の系統に対して一度だけcreator-<UUIDv4>を生成します。creator_refに、元のハンドル、名前、URL、メールアドレス、プロバイダーID、またはそれらの決定的ハッシュを設定してはいけません。名簿への登録に値するクリエイターの更新ごとに、registry-events.pyを通じたmemory/events/creators.ndjsonへのoperation: proposeリクエストについて、別途厳密な許可が必要です。memory/creators/内の正規レコードを書き込めるのはcreator-registryのみです。
• 昇格：別途、厳密な許可がある場合に限り、永続的な事実（検証済みのクリエイター／ハンドル参照、確認済みのニッチ／プラットフォームの対応状況、競合が多いクリエイター）をmemory/hot-cache.mdに昇格します。発掘準備状況やキュー内の位置は、永続的なランキング情報ではありません。
• 完了条件：
  • 必要な検索条件がそろっていること。そろっていない場合は、候補を捏造せず、足りない条件を明示してNEEDS_INPUTで停止します。
  • 完全な条件／エビデンスがない場合、未処理の元ロケーターがちょうど2件残っている状態は、審査済みの候補リストではなくNEEDS_INPUTです。別途許可された中間チェックポイントにはPARTIALとラベルを付け、すべての不足項目を列挙し、ティアや順位を含めません。
  • フォロワー数、エンゲージメント、ブランドセーフティのフィルターを通過した候補が、少なくとも要求数そろっていること。
  • 各候補に、フィールド単位のエビデンス履歴（provider/tool、source_ref、observed_at、期間、エビデンスラベル）、オーディエンスの評価、およびエビデンス完全性のトリアージ状態（READY_FOR_FIT | NEEDS_REFRESH | INELIGIBLE）があること。この状態はスコアでもSTAR Suitabilityの判定でもありません。
  • すべての候補が、レポートと引き継ぎを通じて安定した不透明なcreator_refを1つ保持していること。元の本人確認ロケーターは一時的なものとして扱い、creator_refにコピーしてはいけません。
  • 矛盾する観測結果は別々に保持され、本人情報を統合する場合は検証済みの相互リンクがあること。また、Fitへの引き継ぎでは、現在のSTAR evidence_windowに照らして、変動する各フィールドにcurrent、stale、unknownのいずれかを付け、refresh_requiredのフィールドがあれば明記すること。
  • 次のステップへの参照を含む、順位付けなしのFit準備キューが作成されていること。必須フィールドに古い情報または不明な情報が1つでもある場合、更新されるまではNEEDS_REFRESH、NOT_RANKED、NEEDS_INPUTを設定すること。
• 主な次のスキル：fit-scorer — 加重基準で発掘した候補をスコアリングし、順位付けします。

ハンドオフの要約

skill-contract.md §Handoff Summary Format に記載されている標準形式で出力してください。

データソース

プランニングとスクリーニングにライブ連携は不要（Tier 1）ですが、実際のクリエイターリストには候補レコードが必要です。公開されているハンドル／リンク、ユーザーから提供されたエクスポート、既存の名簿レコード、またはライブ検索コネクターが該当します。検索条件だけでは、特定のクリエイターや指標が存在する証拠にはなりません。候補ソースがない場合は、クエリ／収集計画と NEEDS_INPUT を返してください。ハンドル、プロフィール、数、オーディエンスデータを決して捏造しないでください。

証拠の正規化はレポートテンプレート内でのみ行い、新しい取り込みレイヤーを作らないでください。すべての事実項目について、provider/tool、source_ref、observed_at、測定期間（または not-supplied）、および次のラベルのいずれかを保持してください：Measured、Calculated、Estimated、User-provided、Proxy。同じ項目に値の不一致がある場合は、別々の観測値として保持してください。平均化したり、新しい値を自動的に優先したり、名前／ハンドルだけで ID を統合したりしないでください。プロバイダーをまたぐ ID を 1 人のクリエイターとして扱えるのは、検証済みのクロスリンク、またはユーザーによる明示的な確認がある場合のみです。

ツールによって結果の精度を高められる場合は、~~ コネクタープレースホルダーを使用してください。

• ~~influencer database — 一括検索、フォロワー／エンゲージメント指標、オーディエンスの属性。
• ~~social platform analytics — プラットフォーム標準のクリエイターマーケットプレイスデータ、トレンドのサウンド、関連アカウント。
• ~~CRM — 検証済み ID リンクの確認対象として、既存パートナーとの一致候補を提示します。レコードを自動的に統合しないでください。
• ~~audience overlap — クリエイターのオーディエンスとブランドのオーディエンスの一致度を推定します。

キー不要の候補カードメタデータ（oEmbed）：YouTube（https://www.youtube.com/oembed?url=<video-url>&format=json）、TikTok（https://www.tiktok.com/oembed?url=<post-url>）、X（https://publish.twitter.com/oembed?url=<post-url>）は、投稿のタイトル、作者名／ハンドル、サムネイルをキーなしで返します。これにより候補を一時的に特定し、ID データを手作業でコピーする代わりに、検証済みハンドルへの不透明な証拠参照を保持できます。ハンドル参照は creator_ref とは別のものです。上流から明示的に引き継がれた creator_ref、または検証済みのクリエイターレジストリ ID リンクがある場合に限り、集約データを解決できます。それ以外の場合は、新しいランダムな不透明参照を作成し、ID の不一致を保持してください。メタデータのみで、フォロワー数やエンゲージメント指標は含まれません。そのため、YouTube の場合を除き、これらのデータには ~~influencer database または手動のエクスポートを使用してください。

測定済みの YouTube 指標（無料キー）：python3 "${CLAUDE_PLUGIN_ROOT}/scripts/connectors/youtube.py" channel @handle を実行すると、実際に表示されているチャンネル登録者数、総再生回数、動画数が返されます。また、youtube.py videos @handle --limit 10 を実行すると、動画ごとの再生回数／高評価数／コメント数が追加され、YouTube 候補者のプロフィール行を Estimated から Measured に更新できます。無料の YOUTUBE_API_KEY（1 日あたり 10,000 ユニット。チャンネル確認 1 回につき約 1～3 ユニット）。利用規約上の境界：名前が特定された候補リストの審査に使用してください。一括クリエイターデータベースを構築してはなりません。競合目的のデータ収集に対する割り当て枠の拡張は拒否されます。scripts/connectors/README.md を参照してください。

各カテゴリで利用できる無料／キー不要の手順と、オプトインの MCP レイヤーについては CONNECTORS.md を参照してください。いずれも必須ではありません。すべての手順はユーザー提供の入力だけでも実行できます。

手順

各ステップには references/templates.md に入力用ブロックがあります。該当するブロックをコピーしてください。このスキルでは、インフルエンサーごとのスコア、STAR Suitability の判定、アウトリーチの優先度、アクション順位は計算しません。記録するのは証拠の完全性と、宣言されたフィルターの結果です。後続処理における型付き比較とランキングは fit-scorer が担当します。

1. 検索条件を定義します。 ブランド、目標、オーディエンスの定義、予算／フォロワー層、プラットフォーム、最低エンゲージメント率、地域／言語、除外条件、必須／優先パラメーターの表を確認します。必須条件が不足している場合は、NEEDS_INPUT で停止します。ユーザーがオーディエンスの定義について支援を求めている場合に限り、audience-mapper を案内します。ステップ1のテンプレート。
2. 検索を実施します。 ハッシュタグ、類似アカウント、競合他社への言及、プラットフォーム固有の検索機能を活用します。生のハンドル名／プロフィールURLを含めてよいのは、ステップ2の一時的な検索ブロック内だけです。保存や引き継ぎの前に必ず削除してください。保存しても安全なバッチには、creator_ref、識別ステータス、解決可能な場合は不透明な handle_ref／source_ref、プロバイダー／ツール、検索目的、observed_at、期間、根拠ラベルを記録します。公開ハンドル名／リンク、ユーザーのエクスポートデータ、名簿レコード、ライブ検索コネクターのいずれからも候補レコードを取得できない場合は、正確なクエリパックと収集テンプレートを作成し、NEEDS_INPUT を返して、クリエイターを特定する前に停止します。ステップ2のテンプレート。
3. 初期スクリーニングを実施します。 フォロワー数の範囲、エンゲージメント、直近の活動状況、関連性、ブランドセーフティに基づいて候補を絞り込み、危険信号（フォロワーの購入疑惑、論争、競合他社との独占契約、活動停止）を集計します。これらは検索時の兆候であり、検証済みの STAR 不適合や除外判定ではありません。該当する根拠が確認できない場合は、後続のスコアリングでも「不明」のままにします。プラットフォーム別の確認ポイント：references/platform-vetting.md。ステップ3のテンプレート。
4. インフルエンサープロフィールを作成します。 条件を満たす各クリエイターについて、まず明示的に引き継がれた不透明な creator_ref、またはハンドルとの関連が検証済みのクリエイターレジストリの集約 ID を再利用します。どちらもない場合は、ランダムな creator-<UUIDv4> を1つ生成し、このレポート系列全体で変更せずに再利用します。ハンドル名やその他の識別情報からこの ID を生成してはいけません。認可された資料または検証済みのレジストリリンクで解決できる場合に限り、不透明なハンドル／根拠参照を保存します。それ以外の場合は identity_status: unresolved のままにし、隠れた参照対応表は作成せず、後のセッションで生の識別子を再度求めます。その後、プロフィール（仮名化された識別情報参照、フィールド単位の指標とオーディエンスの根拠、コンテンツ、パートナーシップ履歴、連絡経路の参照、根拠の充足度を示すトリアージ状態）を記入します。矛盾がある場合は個別の行として保持し、プロバイダー間の識別情報を統合するのは、クロスリンクを検証した後に限ります。変動する各観測値を、現在のキャンペーンの STAR evidence_window と比較します。期間内なら current、期間外なら stale、期間または日付がない場合、あるいは STAR の期間自体がない場合は unknown です。古い、または不明な必須フィールドは表示したまま refresh_required に設定し、triage_state: NEEDS_REFRESH、ranking_status: NOT_RANKED、NEEDS_INPUT を必須とします。全体に適用される有効期限をでっち上げてはいけません。スコア、推薦ランク、STAR 適合性の判定は出力しません。連絡先を段階的に確認しながら、1人のクリエイターを詳しく調査する場合は、references/creator-dossier.md を使用します。ステップ4のテンプレート。
5. 検索レポートをまとめます。 プロフィールを集約し、概要統計、プラットフォーム別／フォロワー層別の記述的な内訳、宣言済みフィルターに基づく順位付けなしの根拠キュー3種類（READY_FOR_FIT、NEEDS_REFRESH、INELIGIBLE）を作成します。Fit の型付けが完了する前に、クリエイターの組み合わせを推薦したり、誰かに「優先」／「強く推奨」のラベルを付けたり、候補を実行順位で並べたりしてはいけません。入力が生の識別子2件のみで、条件／根拠が不完全な場合は、NEEDS_INPUT を返し、審査済みの候補プールを保存しません。部分的なチェックポイントを作成する場合は、個別かつ明示的な保存許可が必要です。また、PARTIAL／NOT_VETTED と明記し、条件／根拠の不足項目を列挙します。順位、スコア、「上位」ラベル、fit-scorer への引き継ぎを含めてはいけません。ステップ5のテンプレート。
6. インサイトを追加します。 ニッチな分野のコンテンツトレンド、競合状況、今後の検索に向けた提案を記載します。ステップ6のテンプレート。 ディスカバリーレポートはインラインで返します。レポートの保存、候補リストのキャッシュ、および registry-events.py を通じて operation: propose として各登録 worthy なクリエイターを送信することは、3 つの別個の操作であり、それぞれに正確な承認が必要です。承認がなければ、適格なパスを提示し、何も書き込みません。検証済みの候補リストが存在したら、fit-scorer にフィールドレベルのエビデンスと STAR の evidence_window、freshness_status、および refresh_required リストを渡します。現在の STAR ウィンドウが存在しない場合は、作成せずにフレッシュネスを unknown としてマークします。fit-scorer は S1〜S10 のエビデンス読み取りを記録し、検証済み STAR の拒否権を決定してゲート判定を下すのは creator-content-auditor のみです。

コンパクトな例

ユーザー: 「新しいエコ衣料ブランドのために、サステナブルファッション分野のマイクロインフルエンサー（フォロワー 1 万〜10 万人）を 15 人見つけてください。」

日付付きエクスポートまたはライブコネクターが候補レコードを返した場合の出力例: 不透明な creator_ref ごとに 1 つのフィールドレベルのエビデンスプロファイルを作成し、宣言されたフィルターの下で各行を READY_FOR_FIT、NEEDS_REFRESH、または INELIGIBLE に配置します。すべての行は NOT_RANKED のままです。古い/不明な必須フィールドは NEEDS_INPUT となり、現在完全な行のみが fit-scorer に引き継がれます。候補レコードがない場合は、クエリ/収集プランと NEEDS_INPUT のみを返します。レポートはインラインで返され、その後、保存、昇格、およびレジストリ提案の権限が個別に提示されます。完全なウォークスルーは references/templates.md にあります。

参考資料

• references/templates.md — すべてのステップの記入ブロック（基準、検索、スクリーニング、プロファイル、レポート、インサイト）、実例、ヒント、および「何を/いつ」の概要。
• references/platform-vetting.md — プラットフォームごとのクリエイター向けプレイブック（X/LinkedIn/TikTok/YouTube/Reddit）で、ステップ 3〜4 のスクリーニングとプロファイリングに役立ちます。
• references/creator-dossier.md — 公開データからの構造化されたクリエイターごとのドシエ。連絡先発見のウォーターフォール付き。
• skill-contract.md — 共有コントラクトと Handoff Summary の形式。
• state-model.md — メモリ層と保存パスの規則。
• CONNECTORS.md — 無料/キー不要のデータレシピとオプトインの MCP レイヤー。
• references/star-benchmark.md の STAR ベンチマーク — fit-scorer が下流で適用するスコアリングフレームワーク。
• scout フェーズの兄弟スキル: fit-scorer、audience-mapper、trend-spotter。

次に最適なスキル

プライマリ: fit-scorer — アウトリーチの前に、重み付けされた基準で発見された候補をスコアリングしてランク付けします。

代替（同じインフルエンサーファミリー）:

• competitor-tracker — ディスカバリーで競合が飽和したクリエイターが浮上し、まず競合フィールドをマッピングしたい場合。
• audience-mapper — ターゲットオーディエンスがまだぼんやりしており、再検索の前に基準を明確にする必要がある場合。

終了条件: 訪問済みセットを維持します。このセッションで既にスキルが呼び出されている場合は、再呼び出しせずに停止し、チェーン完了を報告します。最大チェーン深度は起点リクエストから 3 ホップです。到達したら停止して要約します。

関連スキル

• audience-mapper - 誰にリーチするかを定義
• fit-scorer - 発見されたインフルエンサーをスコアリングしてランク付け
• competitor-tracker - 競合のインフルエンサーを見つける
• outreach-manager - 発見されたインフルエンサーに連絡