クッキーシンク（Cookie Sync）とは？仕組みとシンク率の2つの定義【2026年】

クッキーシンク（Cookie Sync）とは、DSP・SSP・DMPのように別々のドメインでCookieを発行している事業者どうしが、同じブラウザに振られたIDを対応づける処理です。日本語では「クッキー同期」とも呼ばれ、業界仕様のOpenRTBではuser syncing、cookie matchingとも呼ばれています。この記事では、同期ピクセルが入札リクエストのbuyeruidになるまでの流れ、意味が2通りある「シンク率」の計算方法、2026年時点でSafariとFirefoxでは同期が効かない理由を、一次情報をもとに説明します。

まとめ：クッキーシンクとシンク率の要点

• クッキーシンクは、Cookieがドメインごとに分かれているために必要になる「ID対応表（マッチテーブル）づくり」です。同期ピクセルと302リダイレクトで互いのIDを渡し合います。
• 同期の結果は、OpenRTBの入札リクエストではuser.buyeruidに入ります。DSPはこの値でリターゲティングやフリークエンシー制御を行います。
• 「シンク率」には、アドテクで使うIDのマッチ率と、MAツールで使うハウスリストとCookieの紐づけ率の2つがあります。分母が違うので、数値を比べる前にどちらの意味かを確認してください。
• Safariはクロスサイトのリソースに対するCookieを2020年3月から既定でブロックしており、同期そのものが成立しません。Firefoxは追跡用と分類したドメインのCookieをブロックし、それ以外のクロスサイトCookieもサイトごとに区画化しているため、同期してもサイトをまたいだ照合には使えません。
• Chromeは2025年4月にサードパーティCookieの廃止を撤回し、同年10月にTopicsなどPrivacy Sandboxの主要APIを廃止すると発表しました。FLoCやTopicsは代わりの手段になりません。

クッキーシンクが必要になる理由

Cookieは発行したドメインにしか送られません。SSPのCookieにある「exchange-123」というIDと、DSPのCookieにある「dsp-789」というIDが同じブラウザのものだと、どちらの事業者も単独では判断できません。OpenRTB 2.6の付録C「Cookie Based ID Syncing」は、Cookieはドメイン固有であるため、ある事業者が別の事業者のIDを知るには同期が必要だと説明しています。同期する組み合わせとして典型例に挙げているのは、DSPとエクスチェンジ（SSP）、DSPとDMPです。

同期の結果は、「A社のcookieID123とB社のcookieID789は同じ利用者」という対応を記録したマッチテーブルとして残ります。複数のプラットフォームのIDを1人の顧客に束ねる「名寄せ」とは違い、クッキーシンクが対応づけるのは2社間のブラウザ単位のIDです。

クッキーシンクの流れ：同期ピクセルからbuyeruidまで

OpenRTBが示すエクスチェンジ主導の同期手順

OpenRTB 2.6の付録Cは、エクスチェンジがマッチテーブルを持つ例として次の手順を示しています。

1. DSPとエクスチェンジが、互いの同期用URLを交換する。
2. エクスチェンジが、広告配信などの機会にDSPの同期ピクセルを利用者のブラウザで読み込ませる。
3. DSPは自社のCookieからIDを読み取り（なければ新しく発行し）、そのIDをURLに埋め込んでエクスチェンジの同期URLへ302リダイレクトする。
4. リダイレクト先でエクスチェンジは自社のCookieを読み、2つのIDの対応をマッチテーブルに保存する。

https://ads.dsp.com/sync?exchange=29
  -> 302
https://platform.exchange.com/match?dsp=12&dsp_user_id=6b9a9765-697e-4c44-b393-dbb00ae7ac6b

URLは仕様書に載っている例示です。付録Cには、DSPがマッチテーブルを持つ逆向きの例も載っています。実装の細部は2社間で取り決めるものとされています。DSPとエクスチェンジの間ではエクスチェンジがマッチテーブルを持つ形が最も一般的ですが、どちらが持ってもかまいません。

入札リクエストでのIDの載り方：user.id・buyeruid・eids

エクスチェンジがマッチテーブルを持つ場合、入札リクエストを作るときに自社のCookie IDからDSP側のIDを引き、buyeruidに入れて送ります。OpenRTB 2.6では、ユーザーを表すフィールドが次の3つに分かれています。

エクスチェンジが対応表を持つ構成では、届いた入札リクエストのうちbuyeruidが入っているものの割合を指標にできます。buyeruidが空でも、DSP側のマッチテーブルでuser.idを照合したり、user.eidsに載ったIDを使ったりできる場合があります。入札の仕組み全体はRTB（リアルタイムビッディング）の解説で扱っています。

Google Authorized BuyersのCookie Matching

Googleの広告取引で入札する事業者には、Google Authorized BuyersのCookie Matchingという独自の仕組みがあります。入札者が起点になる場合は、https://cm.g.doubleclick.net/pixel?google_nid=…&google_cmという形式のマッチタグをブラウザに読み込ませ、入札者ごとのGoogle User IDを受け取ります。Google起点の同期で使うgoogle_pushパラメータは、google_cmと同じリクエストに入れてはいけないと定められています。

Googleは、マッチテーブルをGoogle側に置く「ホステッドマッチテーブル」を、保守と性能の面から推奨しています。Cookie Matchingのドキュメント（2026年9月17日更新）では、ホステッドマッチテーブルのエントリは14日で期限切れとみなしてよく、その後は更新できるとしています。まだ新しいエントリがある利用者へのCookie Matching呼び出しを抑えるのは入札者の責任で、Googleは配信時には回数を制限しないものの、守られているかを定期的に監視しています。同期は多く呼べばよいものではなく、上限を守りながら期限切れのIDだけを更新するものだということです。

シンク率の2つの定義と計算方法

「シンク率」を調べると、アドテクの文脈とMAツールの文脈で別々の定義が出てきます。どちらも「同期できた割合」ですが、分母が違うため数字をそのまま比べることはできません。

アドテクのシンク率：分母の定義と比較条件

アドテクのシンク率は、次の式で表されます。

シンク率（%）＝ 対応が取れたID数 ÷ 同期の対象にしたID数 × 100

分母の取り方は事業者ごとに違います。DSPが「受け取った入札リクエストのうちbuyeruid付きの割合」で測るのか、DMPが「連携先に渡したセグメントのIDのうち相手側で見つかった割合」で測るのかで、同じ取引でも値は変わります。シンク率を比較する際は、分母・測定期間・ブラウザ構成が明示されたデータを使う必要があります。比較に使うなら、分母と期間、そしてSafariのトラフィックが含まれているかを自社でそろえて測り直す必要があります。

MAツールのcookieシンク率：ハウスリストとの紐づけ率

MAツールやCRMでいう「cookieシンク率」は、自社が持つ顧客リストのうち、Webサイト上の行動（Cookie）と紐づいている人の割合です。MAツール「XD.GROWTH」の公式ブログ（運営はトライベック株式会社）の2022年3月8日の記事は、「cookieシンク率＝cookieを保有しているユーザー÷企業のハウスリストの件数」と定義しています。同記事によると、自社クライアントの業界別平均はBtoC企業が64.9%、BtoB企業が7.09%でした。1社の顧客平均にすぎませんが、会員ログインや購入でCookieと紐づく機会の多いBtoCと、問い合わせと資料請求でしか紐づかないBtoBの差がはっきり出ています。

こちらのシンク率は、メルマガからの流入やログインの促進など、自社サイトで本人とCookieを結びつける機会を増やすことで上がります。自社ドメインのCookieだけで紐づける実装なら、サードパーティCookieブロックの直接の影響は受けません。ただし、Safariではファーストパーティのスクリプト書き込み可能なストレージにも保存期間の制限があります。

アドテクのシンク率が下がる原因

ブラウザごとのサードパーティCookieの扱い

同期ピクセルは、閲覧中のサイトとは別のドメインで動きます。そのため、ブラウザのサードパーティCookie制限はシンク率を左右しますが、同期タグの設定や発火タイミングも影響します。

WebKitは2020年3月24日、iOS・iPadOS 13.4とmacOS向けSafari 13.1で、クロスサイトのリソースに対するCookieを既定で全面的にブロックすると発表しました。Safariの閲覧では、同期ピクセルがIDを読むことも発行することもできません。Safariの制限の全体像はITPの解説にまとめています。

MDNの解説によると、Firefoxの既定のCookieポリシーは、追跡用と分類したドメインだけをサードパーティの文脈でブロックします。それ以外のクロスサイトCookieにはTotal Cookie Protectionによる区画化が適用されます。Mozillaは2022年6月14日、Total Cookie Protectionを全デスクトップ利用者の既定にし、Cookieを作成元のサイトごとの「cookie jar」に分けました。ニュースサイトAで読み込まれた同期ピクセルとニュースサイトBで読み込まれた同期ピクセルは、別々の区画のCookieを見ることになります。同期の通信は発生しても、サイトをまたいだリターゲティングには使えません。

Chromeは2025年4月22日、サードパーティCookieを利用者が選ぶ現行の方式を維持し、新しい独立したプロンプトは出さないと発表しました。「Chromeは2024年までにサードパーティCookieを段階的に廃止する」という、かつて広く語られた前提は、すでに成り立ちません。廃止計画が撤回された経緯はサードパーティCookie廃止の現在地で詳しく扱っています。

Prebid.jsの既定値と同期の上限

ヘッダービディングのPrebid.jsを使うサイトでは、ページ側の設定でもシンク率が変わります。Prebid.jsのuserSyncの既定値は、公式リファレンスによると次のとおりです。

• syncEnabled：既定はtrue（同期を行う）
• syncsPerBidder：1アダプターあたりの同期数の上限。既定は5で、0にすると上限なし
• syncDelay：オークション終了から同期ピクセルを書き出すまでの待ち時間。既定は3,000ミリ秒
• filterSettings：既定ではimage型の同期だけを許可し、iframe型は無効

既定のままだと、iframe型の同期しか用意していないビッダーは同期できません。また、オークション終了から3秒以内に離脱した閲覧では同期ピクセルが書き出されません。iframe型を許可するには、filterSettings.iframeを明示します。次の例はPrebid.jsの読み込み後に実行し、bidderA・bidderBを導入済みアダプターの実際のbidderコードに置き換えます。

pbjs.setConfig({
  userSync: {
    filterSettings: {
      iframe: { bidders: ['bidderA', 'bidderB'], filter: 'include' },
      image: { bidders: '*', filter: 'include' }
    },
    syncsPerBidder: 5,
    syncDelay: 3000
  }
});

iframe型の同期は、ビッダーのドメインのページをサイト内で読み込むことになります。対象を全ビッダー（'*'）に広げるのではなく、同期URLと送信内容を確認したビッダーだけをincludeで指定するのが安全です。

サードパーティCookieに頼らない識別子への移行

ファーストパーティIDとEID：SharedIDとUID2

サードパーティCookieを使った同期の代わりに広がっているのが、パブリッシャー自身のドメインで持つIDをuser.eidsで入札リクエストに載せる方法です。Prebid.jsのUser IDモジュールは、取得したIDをOpenRTBのEIDS形式でアダプターに渡します。SharedIDは、パブリッシャーのファーストパーティドメインにUUIDを保存するモジュールで、EIDのsourceはsharedid.orgです。ファーストパーティCookieの性質はファーストパーティークッキーの解説で説明しています。

Unified ID 2.0（UID2）は、パブリッシャーが利用者のメールアドレスか電話番号（ハッシュ化済みでも未ハッシュでも可）をOperatorに送り、Operatorがraw UID2と暗号化されたUID2トークンを発行する仕組みです。2026年9月時点では、UID2を構成するサービスはすべてThe Trade Deskが管理しています。トークンには有効期限があり、推奨の更新間隔は1時間です。利用者はTransparency and Control Portal（transparentadvertising.com）からオプトアウトできます。

UID2を新しく発行するには、利用者のメールアドレスか電話番号が必要です。そのため、匿名で閲覧しているSafariの利用者について、クッキーシンクの代わりになるものではありません。ログイン会員が多いメディアでは同期の穴を埋めやすく、会員基盤のないサイトでは効果が限られます。

FLoC・Topicsなど廃止されたAPIを選択肢から外す理由

FLoCや、その後継のTopicsなど廃止が発表された広告関連APIは、クッキーシンクの代わりとして新しく採用する対象になりません。Googleは2022年1月25日、FLoCの提案を置き換えるものとしてTopics APIを発表しました。さらに2025年10月17日には、Topics、Protected Audience、Attribution Reporting、Private Aggregation、Related Website SetsなどのPrivacy Sandbox技術を廃止すると発表しています。2026年に計画を立てるなら、サードパーティCookieが使える環境での同期、ファーストパーティIDとEID、ログインを前提にしたUID2を組み合わせることになります。

クッキーシンクとプライバシー規制

研究で測られた同期の規模

クッキーシンクは利用者の目に見えない通信で行われます。Papadopoulosらの論文（WWW 2019）は、同じ国に住むモバイル利用者850人から2015〜2016年の12か月間に集めた閲覧ログを分析し、通常のWeb利用者の97%がクッキーシンクにさらされていたと報告しました。データセット全体では263,635件の同期リクエストが見つかり、同期によって1人の利用者を追跡できるドメインの数は6.75倍に増えていました。この研究は、クッキーシンクによって追跡情報の共有範囲が広がることを示しています。

日本の個人情報保護法：個人関連情報と提供先での同意確認

個人情報保護委員会のFAQ（Q8-1）は、Cookieなどの端末識別子は、個人情報に当たらない場合でも、通常は「個人関連情報」に当たるとしています。個人情報保護法第31条第1項は、提供先が個人関連情報を個人データとして取得すると想定されるときは、本人の同意が得られていることなどを確認しないで提供してはならないと定めています。ガイドラインでは、提供先がID等を介して受け取った情報を自社の個人データに付け足す場合も、「個人データとして取得する」場合に当たるとされています。

DMPで同期したCookie IDと行動データを広告主に渡し、広告主が会員IDとの対応表を使って顧客データベースに付け足す構成は、この規定の対象になります。クッキーシンクそのものは違法ではありませんが、同期したIDの渡し先が顧客データと突き合わせるかどうかによって、同意確認の要否が変わります。

電気通信事業法の外部送信規律：対象役務とページの範囲

2023年6月16日に施行された電気通信事業法の外部送信規律は、利用者の端末から外部へ情報を送らせるタグなどについて、通知・公表などを求めるものです。総務省のFAQ（問1-6）は、この規律がターゲティング広告そのものを規制するものではないと答えています。対象はSNS、検索、ニュース配信などの役務を提供する電気通信事業者で、問1-12は、自社サイトで商品を販売するだけの小売業者には適用されないと答えています。問2-12は、同じサイトの中でもニュース配信のページは対応が必要で、自己の情報発信のために運営する会社案内のページは対応の必要がないと答えています。同期ピクセルを置いているページが対象の役務にあたるかどうかで、対応の要否が決まります。

よくある質問

クッキー同期とクッキーシンクは同じ意味ですか？

同じ意味です。英語のCookie Syncを訳したものが「クッキー同期」で、OpenRTB 2.6はuser syncing、user matching、cookie matchingという別名も挙げています。GoogleのドキュメントではCookie Matchingという名前が使われています。

クッキーシンクとピギーバックの違いは何ですか？

ピギーバックは、あるタグの中から別の事業者のタグを呼び出させる「タグの相乗り」の配信方法です。クッキーシンクは、呼び出された先で2社のIDを対応づけてマッチテーブルに記録する処理を指します。同期ピクセルをピギーバックで配ることはありますが、2つは別の段階の話です。

シンク率はどのくらいあれば十分ですか？

業界共通の基準はありません。アドテクのシンク率は分母とブラウザ構成で大きく変わり、Safariの利用者が多いサイトでは構造的に低くなります。MAツールのcookieシンク率については、XD.GROWTHの顧客企業の平均としてBtoC 64.9%・BtoB 7.09%という数字がありますが、まずは自社の過去の値と比べて推移を見るのが確実です。

Safariではクッキーシンクはできないのですか？

サードパーティCookieを使う同期はできません。Safariは2020年3月からクロスサイトのCookieを既定でブロックしているため、同期ピクセルがIDを読むことも書くこともできません。Safariの利用者に届けるには、ログインを前提にしたUID2など、ファーストパーティの情報をもとにしたIDが必要です。

サードパーティCookieがなくなればクッキーシンクは不要になりますか？

Chromeは2025年4月にサードパーティCookieの廃止を撤回したため、Chromeの利用者の多くとの間では、2026年9月時点でも同期が機能しています。Cookieを使わないIDに移っても、事業者間でIDを対応づける必要はなくなりません。UID2は、Cookieの代わりにメールアドレスや電話番号をもとにして事業者間で共通のIDをつくる方法です。なお、EIDは識別子を入札リクエストで伝えるOpenRTBの形式で、それ自体がIDを対応づける仕組みではありません。

関連記事

• サードパーティCookieとは？仕組みとブラウザ別の扱いを解説【2026年最新】
• サードパーティCookie廃止の現在地と企業がとるべき対策【2026年最新】
• ITPとは？Safariの制限仕様と広告計測への影響・対策【2026年最新】
• DSP（デマンドサイドプラットフォーム）とは？仕組み・主要サービス・選び方を解説
• SSPとは？仕組み・DSPとの違い・主要サービスをわかりやすく解説