ブログ / ハウツー

きれいな状態を保てるインフルエンサーデータベースの作り方（スプレッドシートまたはCRM）

2026年10月23日 · 10分で読めます

インフルエンサーリストの多くは手早く作ったスプレッドシートから始まり、四半期もたたないうちに混乱します。同じクリエイターが別々のハンドルで3回登場し、フォロワー数は1年前のまま、なぜ「保留」と書いてあるのか誰も覚えていません。このガイドでは、Google Sheets、Airtable、CRM、本格的なデータベースのいずれでも、成長しても使いやすさを保てるインフルエンサーデータベースの作り方を紹介します。1人につき1レコード、SNSアカウントは個別に保存、すべてのリンクを正規化し、各情報をいつどうやって知ったかを記録します。

まずデータベースの目的を決める

列を追加する前に、データベースで支えたい判断を1文で書きましょう。「スキンケアのキャンペーン向けにクリエイターを探し、誰に報酬を払ったかを管理する」と「市場調査のためにドイツのフィットネス系クリエイターをすべて洗い出す」では、設計が変わります。目的が決まれば、必要な項目、更新の頻度、集めないものが見えてきます。

誰が使い、何で絞り込むかも決めておきます。使う人が増えるほど編集ルールは厳しくする必要があり、絞り込みに使う項目（ジャンル、国、プラットフォーム、ステータス）は、自由記述ではなく決まった選択肢を持つ専用の列にします。

アカウントごとではなくクリエイターごとに1行

最も役に立つ設計上の判断は、人とアカウントを分けることです。たとえば「Maya Okafor」というクリエイターが、Instagramで@mayabakes、TikTokで@mayabakes_、YouTubeでMaya in the Kitchenというチャンネルを運営しているとします。それぞれを1行にすると、彼女に3回メールを送り、リーチを3回数えることになります。

表を2つ使いましょう（スプレッドシートなら2つのタブ、CRMなら2つのオブジェクト）。1人1行のcreators（クリエイター）と、SNSのプロフィールごとに1行のaccounts（アカウント）です。accountsの各行は、すべてのハンドルが変わっても変わらない固定のクリエイターIDを参照します。

creators表

accounts表

CSVでインポートやエクスポートをするなら、途中で名前が変わらないよう、ヘッダーを列名とまったく同じにしておきます。

creator_id,display_name,primary_niche,country,languages,business_email,status,owner,notes,created_at,updated_at
account_id,creator_id,platform,handle,platform_user_id,canonical_url,followers,followers_as_of,link_confidence,link_evidence,source

プロフィールURLとハンドルをすべて正規化する

重複の多くは、1つのプロフィールが別々の書き方をされたものです。https://instagram.com/MayaBakes?igsh=abc123、instagram.com/mayabakes/、@mayabakesは1つのアカウントですが、スプレッドシートには3つの値に見えます。入力するたびに必ず正規化しましょう。

1. Step 1空白を除いて小文字にする

   値の前後の空白を取り除き、小文字に変換します。Instagram、TikTok、Xのハンドルは大文字と小文字を区別しないので、MayaBakesとmayabakesは同じアカウントです。

2. Step 2トラッキングなどの余分な部分を削る

   ?や#以降をすべて削り（共有リンクにはigsh、utm_source、is_from_webappなどのパラメータが付くことがよくあります）、末尾のスラッシュも取り除きます。

3. Step 3ハンドルを取り出す

   ハンドルだけを取り出し、先頭の@を外してhandle列に保存します。プロフィールではなく投稿、リール、動画を指すリンク（たとえば/p/、/reel/、/video/）は受け付けないか、先に投稿者のプロフィールを調べます。

4. Step 4正規URLを作り直す

   プラットフォームごとに1つの決まった形式で、ハンドルからURLを生成します。元の共有リンクを正規URLの列に貼り付けてはいけません。

5. Step 5既存のレコードと照合する

   accounts表で同じプラットフォームとハンドル（またはプラットフォームのユーザーID）を検索します。すでにあれば、その行を更新します。

YouTubeには特に注意が必要です。チャンネルには@ハンドル、恒久的なチャンネルIDを含む/channel/UC...のURL、古い/c/や/user/のURLのいずれからでもアクセスできます。チャンネルIDはハンドルが変わっても残るので、platform_user_idに保存し、YouTubeの行のキーとして扱いましょう。

Google Sheetsなら、InstagramとTikTokのハンドルの抽出を数式でできます。A列に元のリンクがある場合、次の数式は小文字のハンドルを返し、リンクが一致しなければ空欄を返します。

=IFERROR(LOWER(REGEXEXTRACT(A2, "(?i)instagram\.com/([a-z0-9._]+)")), "")
=IFERROR(LOWER(REGEXEXTRACT(A2, "(?i)tiktok\.com/@([a-z0-9._]+)")), "")

次の列で正規URLを作ります。たとえば="https://www.instagram.com/" & B2 & "/"です。Instagramの数式は投稿のリンクにも一致してpを返すので、p、reel、explore、storiesなどの値で絞り込み、その行は手で直しましょう。

重複を排除し、統合し、根拠を記録する

同じ人物、別のハンドル

MayaはInstagramでは@mayabakes、TikTokでは@mayabakes_なので、ハンドルだけで照合してもつながりません。アカウント同士を結びつける根拠を探しましょう。プロフィールのリンク、両方を載せたリンクインバイオのページやWebサイト、同じ仕事用メールアドレス、一方のアカウントがもう一方に言及していることなどです。一致を確認できたら、両方のアカウント行を同じcreator_idに紐づけます。

同じハンドル、別の人物

Instagramの@jordanrunsとXの@jordanrunsは、無関係の2人かもしれません。ハンドルの一致は確認すべき手がかりとして扱い、決して証拠とはみなさないでください。

2つのクリエイターレコードを統合するときは、次のようにします。

1. 既存の参照が使えるよう、古いほうのcreator_idを残します。
2. 重複側のアカウント行、メモ、案件をすべて残す側に移します。
3. 古いエクスポートをたどれるよう、重複側のIDはすぐに削除せず、merged_into列（または小さな統合ログ）に残します。
4. 値が食い違う場合は、日付が最も新しい値を残します。

すべてのリンクに根拠と確信度を記録する

人物とアカウントの結びつきは1つの主張であり、主張は間違うことがあります。1年後のチームメンバーは、なぜそのTikTokアカウントをMayaのものだと判断したのかを知る必要があります。各アカウント行にlink_confidenceとlink_evidenceの2列があれば足ります。

根拠は「本人っぽい」ではなく、「YouTubeの概要ページからリンクあり、2026-10-20に確認」のように、他の人が検証できる形で書きましょう。ツールで見つけた一致なら、そのスコアと理由を保存し、確信度の低い一致は自分でも確認します。

管理する項目、更新日、ステータス

フォロワー数やエンゲージメント、ハンドルさえも変わるので、指標の列にはすべて対応する_as_ofの日付を付けます。項目の種類ごとに更新ルールを決めましょう。

レポートに使う項目は、上書きせずに小さなmetrics_history表（アカウントID、日付、フォロワー数、再生数）に追記していけば、成長を示せます。

シンプルなステータスのパイプラインを使う

短いリストのドロップダウンを使い、status_changed_atの日付を加えると、放置されたレコードが分かります。多くのチームで使えるパイプラインの例です。

クリエイターデータのプライバシーの基本

クリエイターは人であり、すべての項目が公開プロフィールから得たものであっても、インフルエンサーデータベースは個人データの保管場所です。ここに書くのは一般的な情報で、法的助言ではありません。ご自身の状況については専門家に確認してください。EUと英国のGDPRやカリフォルニア州のCCPAを含む、多くのプライバシー法に共通する原則がいくつかあります。

• 法的根拠を持つ。 GDPRのもとでは、B2Bのアプローチに正当な利益を根拠とする企業が多くあります。その場合、処理が必要であり、クリエイターの利益を上回らないことを説明できなければなりません。その理由を文書にしておきましょう。
• 公開された関連データだけを集める。 クリエイターが仕事のために公開している情報にとどめます。自宅の住所や家族の情報は決して保存しないでください。
• プラットフォームの規約を守る。 多くのプラットフォームは許可のない自動スクレイピングを禁止しているので、公式API、手作業での調査、許可されたアクセスを使うツールを優先しましょう。
• 本人に知らせ、請求に応じる。 GDPRでは一般に、他の情報源から集めたデータについて、遅くとも最初に連絡する時点で本人に知らせる必要があります。クリエイターから自分のデータの開示や削除を求められたとき、creator_idが1つにまとまっていれば、その人に関するすべての行を見つけられます。
• 不要になったものは削除する。 一定期間連絡しなかった候補を削除するなどの保存ルールを決め、実際に運用しましょう。
• アクセスを制限する。 編集権限は必要な人だけに与えます。

スプレッドシート、CRM、データベース：移行のタイミング

どれを選んでも、同じ2つの表とIDを使い続けましょう。そうすれば、後でCRMやデータベースに移るときも作り直しではなくインポートで済みます。

accounts表を速く埋める

accounts表を作るうえで最も時間がかかるのは、たいてい各クリエイターの別アカウントを探す作業です。sociallinks.devは、Instagram、TikTok、YouTube、XのプロフィールURLを1つ受け取り、そのクリエイターの他のプラットフォームのアカウントを、確信度スコアと一致ごとの根拠付きで返します。これは上のlink_confidence列とlink_evidence列にそのまま対応します。一括モードでは最大500件のプロフィールリンクを受け付け、スプレッドシートで返します。

クリエイターのアカウントを探す ほかのガイド