LinkedIn Predictive Audiences｜ 「自動で増える顧客リスト」誤解とDMP上限

最新シグナル

誤解の芯：Lookalikeの別名ではない

いちばん多い誤解は、Predictive Audiencesを「Facebookの類似オーディエンスのLinkedIn版」と同一視することです。Microsoft Learnの説明では、顧客の会社リストまたはコンタクトリストを入力し、LinkedInのエンゲージメント信号と組み合わせて、転換傾向の高い会員をセグメント化する、と書かれています。シードが薄い・古い・名義が揃っていないと、拡張先の質も落ちます。

二つ目の誤解は、Advertising APIの承認だけでPredictive Audiences APIが使える、という読み方です。ドキュメントは、Matched Audiences（DMP Segment）系が別プログラムであること、Predictive Audiences APIはMatched Audiences APIへのアクセスを持つ開発者向けのプライベートAPIであること、を前提にしています。広告運用だけ担当しているチームと、API連携を持つ開発チームで、権限の申請状況がずれることがあります。

三つ目は、セグメントを作りっぱなしにすることです。上限やサンセットが来ると、古いセグメントが枠を食い、新規作成が429で弾かれる、という事故が起きます。次節から定義と上限を分けて読みます。

定義：シード → 予測 → 配信可能なセグメント

Predictive Audiencesの流れは、おおむね次のとおりです。①DMPセグメントに会社リストまたはコンタクトリストを入れる。②ビジネス目的に沿った予測オーディエンスを作る。③できたセグメントをキャンペーンのターゲティングに使う。説明文では「behavioral + lookalike」と表現されることがありますが、中身は自社データ起点のスコアリングです。

UIで作ったオーディエンスと、APIで作ったオーディエンスの両方があり得ます。202607以降の変更では、取得レスポンスに読み取り専用のidが返り、Campaign Manager作成分も含めて更新しやすくなった、とRecent Changesにあります。運用と開発が別リポジトリだと、同じオーディエンスを二重作成しやすいです。命名規則と所有者を1行で固定します。

権限面では、rw_dmp_segmentsなどが必要で、認証メンバーが広告アカウントでVIEWER以外の役割を持つことが求められます。VIEWERしかいないサービスアカウントで自動化すると、作成・更新が失敗します。権限表を共有フォルダの固定パスに置き、確認日を残します。

実務逆算1：シードリストの品質を先に直す

拡張の前に直すのは、シードです。会社リストなら、ドメイン・正式社名・国コードの揺れを先に揃えます。コンタクトリストなら、個人メールと会社メールの混在、退職者の残存、個人情報の同意範囲を点検します。シードが「展示会で集めた名刺の未クレンジング」だと、予測は展示会のノイズを拡大します。

手順は次のとおりです。①直近90日の商談または受注にひも付く会社／担当者だけに絞る。②国・業界のラベルを必須列にする。③LinkedInへのアップロード形式（CSV列）をテンプレ1つに固定する。④アップロード後のマッチ率を記録する。⑤マッチ率が低い週は拡張を止め、マスタを直す。

マッチ率の記録がない運用は、拡張の成否を「CPAが下がった／上がった」だけで語ることになります。CPAは配信・入札・クリエイティブの合成なので、シード不良の切り分けができません。マッチ率列を週次レポートの左端に置きます。

実務逆算2：DMPセグメント上限1,000を先に空ける

Recent Marketing API Changes（view=li-lms-2026-08）では、広告アカウントあたりのDMPセグメント上限が1,000であること、上限超過時は429とSEGMENT_LIMIT_*系のエラーになること、追加枠のために未使用セグメントを削除する必要があること、が示されています。テスト用・旧キャンペーン用・代理店引き継ぎ用が積み上がると、本番の新規作成が止まります。

逆算の手順は次のとおりです。①アカウント内のDMPセグメント数を一覧する。②90日以上未使用かつキャンペーン紐付けなしを「削除候補」にする。③削除前に名前と作成日をスプレッドシートに退避する。④削除後に枠数を再計測する。⑤新規Predictive Audiences作成は、枠に余裕があることを確認してから実行する。

代理店が複数入るアカウントでは、誰がセグメントを作ったか分からない状態が危険です。作成者・用途・キャンペーンIDの3列がないセグメントは、新規作成を禁止するルールにします。禁止ルールがないと、上限到達のたびに「どれを消すか」で半日溶けます。

実務逆算3：APIバージョンのサンセットをカレンダーに載せる

Microsoft LearnのPredictive Audiences／Matched Audiences系ページには、Marketing Version 202508（2025年8月版）が2026年8月17日にサンセットする、という注意が付いています。古いバージョンのまま呼び出している連携は、その日以降に止まる可能性があります。最新のversioned APIへ移すよう、ドキュメントは推奨しています。

開発チケットの切り方は、「機能追加」ではなく「バージョン移行」を独立タスクにします。依存するエンドポイント一覧、使用中のview=li-lms-*、ステージングでの疎通日、本番切替日を1枚にします。マーケ側は、切替ウィンドウ中に新規オーディエンス大量作成を止める、という運用合意が必要です。

サポートが必要な場合は、LinkedIn Developer Support Portalへの申請ルートが案内されています。社内の「広告の不具合」チャットにだけ投げて開発に届かない、という経路は避けます。障害の一次窓口を1つに固定します。

日本のBtoB・越境アカウントで起きやすいズレ

日本本社がアジア太平洋の複数広告アカウントを持つ場合、シード会社リストが日本法人名義のままだと、現地法人の商談と噛み合いません。国別のリストを分け、Predictive Audiencesもアカウント単位で作ります。1つの巨大リストを全アカウントに使い回すと、予測の目的がぼやけます。

個人情報の越境も論点です。コンタクトリストをアップロードする前に、同意の根拠と保管場所を法務と確認します。確認前にテストアップロードだけ先行すると、後から撤回が難しくなります。テスト用は合成データまたは社内検証用ドメインに限定します。

リードジェン目標とブランド認知目標で、同じ予測オーディエンスを使い回すのもズレの元です。ビジネス目的が違うなら、シードも目的別に分けます。目的が空欄のオーディエンス名は、作らない方が安全です。

取り違えやすい読み方

いちばん多いのは、Predictive Audiencesを「リストがなくても使えるAIターゲティング」と読むことです。シードが前提です。二つ目は、Advertising API承認＝DMP／Predictive利用可、とみなすこと。別権限です。三つ目は、セグメント上限を「キャンペーン数の上限」と混同すること。DMPセグメントの話です。

四つ目は、APIサンセット日を「ドキュメントの更新日」と読み飛ばすこと。2026年8月17日は運用カレンダーに載せる日付です。五つ目は、マッチ率が低いのに配信だけ拡大すること。先にシードを直します。

今週やること：シード1本と枠数1行

今週の1点は、「用途／シード種別（会社orコンタクト）／件数／マッチ率／DMPセグメント残枠／APIバージョン／確認日」の表を、主要広告アカウント1つだけ完成させることです。Predictive Audiencesをまだ使っていない場合も、残枠とAPIバージョンだけ先に埋めます。

表ができたら、残枠が100を切っている、または未使用セグメントが50を超えている場合は、削除候補の洗い出しを同じ週に始めます。新規の予測オーディエンス作成は、洗い出しが終わるまで保留にしてよいです。保管先は共有フォルダの固定パス1つ。更新担当は1名、副担当は1名に限定します。

翌週は、マッチ率が前週より落ちていないかだけを見ます。落ちている週は配信予算の話より先に、シードのクレンジングを議題にします。