AdTech
リテールメディアネットワークや広告プラットフォームのデータクリーンルーム:クラウドが提供するものを使うか、製品をライセンスするか、自社で作るか
データクリーンルームがリテールメディアネットワーク、パブリッシャー、広告プラットフォームのために何をするのか、何をしないのか、そしてクラウドのクリーンルーム、ライセンス製品、自社での構築のあいだでどう選ぶかを解説する。
執筆:amBrain読了10分
この記事の内容
データクリーンルームとは、二つの企業が互いの顧客データを照合し、合意した分析だけを実行する共有の作業スペースで、たいていはクラウド上にある。うまく設定されていれば、どちらの側も相手の生の記録を見ることはない。リテールメディアネットワークはこれを使って、ブランドの広告を見て、そのあとでその商品を買った買い物客が何人いたかを、ブランドに伝えることができる。ブランドが受け取るのは合計の数字であって、名前のリストではない。クリーンルームは、自社のクラウドやデータウェアハウスが提供するものを使うことも、クリーンルーム製品をライセンスすることも、自社で作ることもできる。どれを選ぶかは、自社のデータと広告主のデータがどこにあるのか、そしてクリーンルームが自社の売り物の一部なのかどうかで決まる。
短い答え:自社のデータと広告主の大半のデータが一つのクラウドやデータウェアハウスにあるなら、そのクリーンルームから始める。組みたいブランドがさまざまなプラットフォームを使っていて、その大半とすぐに組む必要があるなら、製品をライセンスする。クリーンルームが自社の売り物の一部なら、自社で作る。その場合でも、自社の層はクラウドのクリーンルームの上に置ける。どれを選んでも、最初のブランドがクエリを実行する前に、照合のルール、許可するクエリ、オーディエンスの最小人数、ログを決めておく。
データクリーンルームは、リテールメディアネットワークや広告プラットフォームのために何をするのか
リテールメディアの典型的なケースでは、ブランドがスポンサードプロダクト広告、つまり自社の検索結果に表示される有料の商品掲載を出している。自社は広告の閲覧と売上のデータを、ブランドは自らの顧客リストを持ち寄る。両者は、ハッシュ化と呼ばれる同じ一方向の計算式で各メールアドレスをコードに変えるので、同じメールアドレスからは必ず同じコードが得られる。クリーンルームがコードを照合し、ブランドは、照合で一致した買い物客のうち何人が広告を見て、何人が買ったかといった合計を受け取る。
米国の連邦取引委員会(FTC)の職員は、2024年11月、同委員会のテクノロジーブログへの投稿でクリーンルームを取り上げた。職員たちはクリーンルームを、「データの利用を制限するルールに縛られた状態で、企業がデータを交換し、分析できるようにするクラウドのデータ処理サービス」と説明している。
デジタル広告の米国の業界団体である Interactive Advertising Bureau(IAB)は、2026年9月29日に、コマースにおけるクリーンルームについてのフレームワークを公表した。そのページには、「オーディエンスの重複、データエンリッチメント、ターゲティング、サプレッション」といった用途が挙げられている。平たく言えば、共通する顧客が何人いるのか、その顧客についてほかに何がわかるのか、そして誰に広告を見せ、誰を外すのかである。
パブリッシャーや広告プラットフォームも同じ仕組みを使う。パブリッシャーは、ログインしている読者を広告主の顧客と照合できる。広告主が広告を買うために使うシステムである DSP(デマンドサイドプラットフォーム)は、自らの広告を見た人を広告主の売上と照合できる。
クリーンルームでは解決できないことは何か
クリーンルームがデータをどこまで守れるかは、その設定しだいである。FTC の職員は同じ投稿でこう書いている:「既定では、DCR を提供するサービスのほとんどはプライバシーを保護するものではない。」DCR はデータクリーンルーム(data clean room)の略である。職員たちはこう続けている:「そうではなく、企業は、各制約が効果を発揮するよう、一つひとつを意図的に設定し、適用しなければならない。」
クエリについてのルールで、あらゆる手口を防げるわけではない。BigQuery データクリーンルームについての Google のドキュメントは、分析ルールでは「高度なクエリが許可されていないデータを抽出するのを完全には防げない可能性がある」と警告している。AWS Clean Rooms のドキュメントは、そうした手口の一つとして、「個人に関する記録を追加または削除し、クエリ結果の違いを観察することによって」一人の人物について知る方法を説明している。
ハッシュ化しても、データは匿名にはならない。FTC の職員は2024年7月、同じブログにこう書いている:「企業は、個人情報をハッシュ化すれば匿名化されるかのように行動したり、そう主張したりすべきではない。」欧州委員会は、個人データのうち「非識別化、暗号化、または仮名化されていても、人物の再識別に使えるものは、引き続き個人データである」としている。したがって、それには EU の主要なデータ保護法である GDPR が適用される。仮名化とは、名前を、なお本人に結びつけられるコードに置き換えることである。
法的な義務は、それぞれの企業に残る。IAB Tech Lab は、デジタル広告の技術標準を定める団体である。そのクリーンルームに関するガイダンスは、プライバシー法の遵守を「データ提供者(Data Contributor)の責任」、つまりデータを持ち込む企業の責任としている。また、パートナーは、互いが「完全かつ正確な(なりすまし/改ざん/水増しされていない)データ」を持ち込むと信頼し合わなければならないとしている。さらに、マッチ率、つまり相手側に対応する記録が見つかった記録の割合は、「想定と異なる場合がある」とも指摘している。
そもそもクリーンルームがまったく必要ない場合もある。IAB のコマース向けフレームワークは、クリーンルームは「あらゆるデータや計測のニーズにとって適切な解決策というわけではない」としている。
この記事の出典はすべて2026年11月3日に閲覧した。FTC の引用は職員によるブログ投稿からのもので、FTC の規則ではない。プライバシー法については、EU と米国の出典だけを引用している。ほかの国にはそれぞれ独自のルールがある。
クリーンルームを提供しているのは、どのクラウドとデータウェアハウスか
AWS、Google Cloud、Snowflake、Databricks は、それぞれ自社のサービスの中でクリーンルームを提供している。データウェアハウスとは、企業が分析のために記録を保管しておくデータベースのことだ。買い手にとっての違いは次のとおり:
- AWS Clean Rooms:AWS によれば、コラボレーションは「AWS からデータを移動したり、別のクラウドサービスプロバイダーにデータを読み込んだりする必要がない」。このサービスは、Snowflake と Databricks に保存されたデータも読み取れる。クエリの費用をどのパートナーが払うかは、クリーンルームを設定する側が選ぶ。
- Google Cloud の BigQuery データクリーンルーム:Google によれば、エグレス制御、つまりクリーンルームから何を外に出してよいかを決めるルールが、データにクエリを実行するパートナーによる生データのコピーとエクスポートを自動的に防ぐ。
- Snowflake Data Clean Rooms:Snowflake のドキュメントには、「データプロバイダーは Snowflake Enterprise Edition を使用しなければならない」、そして「分析の実行者が分析のコストを負担する」とあり、クエリを実行するパートナーがその費用を払うことになる。
- Databricks Clean Rooms:Databricks によれば、コラボレーターは「ほかのコラボレーターのテーブル、ビュー、ボリュームにあるデータを見ることはできない」。既定では、分析コードは一つひとつ、実行される前にほかのコラボレーターの承認を受けなければならない。
自社のクラウドやデータウェアハウスが提供するクリーンルームを使うべきなのはどんなときか
次の大半が当てはまるなら、それを使う:
- 広告のログと売上の記録が、すでにそのプラットフォームにある
- 組みたいブランドの大半が同じプラットフォームを使っているか、そのプラットフォームが、ブランドのデータを置かれた場所のまま読み取れる
- ブランドが求めているのは、オーディエンスの重複やキャンペーン後の売上といった、いくつかの標準的な分析である
- ルールを設定し、承認済みのクエリを書き、新しいブランドごとに立ち上げを手伝うデータエンジニアがいる
難点は、ほかのプラットフォームを使うブランドで、そうしたブランドは、自社が使うプラットフォームでアカウントを開くか、データをそこにコピーしなければならないかもしれない。IAB Tech Lab のガイダンスは、「一部の DCR プラットフォーム間でデータを移動するのは、手間がかかったり、費用がかさんだりする可能性がある」と警告している。また、クラウドのクリーンルームは汎用のツールであって、リテールメディア向けの製品ではない。ブランド向けの画面とレポート、そして新しいブランドごとの支援は、自社で作るか、手作業で対応することになる。
クリーンルーム製品をライセンスすべきなのはどんなときか
次のような場合は、ライセンスする:
- 組みたいブランドが、データをさまざまなクラウドやデータウェアハウスに置いていて、今年中にその大半と組む必要がある
- ブランドのマーケティングチームがコードを書かずに使える、既製の分析と画面がほしい
- データチームが小さく、接続を保つ作業はベンダーにお金を払って任せたい
一度に多くのプラットフォームに接続できる製品もある。LiveRamp の小売業者向けスタートガイドによれば、「AWS、GCS、Azure Blob、Snowflake、Google BigQuery、Databricks を含む」クラウドベースのほとんどのストレージへのデータ接続を設定できる。このガイドは既製のオファリングとして Retail Intelligence を挙げており、これは「ブランドと RMN を接続する(オプションでパブリッシャーのオーバーレイも追加可能)」ものだ。RMN とはリテールメディアネットワークのことである。
その代償は、料金と、計測できる内容に対する主導権の低下である。IAB Tech Lab のガイダンスは、「DCR の料金体系は大きく異なることがある」とし、参加者ごとに独自のライセンスが必要かどうかを尋ねるよう勧めている。あとで離れる場合は、分析を作り直し、すべてのブランドを設定し直さなければならないかもしれない。
自社でクリーンルームを作る価値があるのはどんなときか
自社で作ることが報われるのは、次のような場合である:
- クリーンルームが自社の売り物の一部であり、計測とオーディエンスについて独自のルールを持ちたい
- オーディエンスを、買い物客のリストを自社のシステムの外に出すことなく、スポンサードプロダクトのオークションと、広告を選んで数えるシステムであるアドサーバーに届けなければならない
- クエリごとやパートナーごとの料金が、自社のシステムを運用するチームのコストを上回るまでに膨らんでいる
自社で作ることは、新しいプライバシーエンジンを作ることを意味するとは限らない。Amazon Ads は、広告主向けのクリーンルームである Amazon Marketing Cloud を「クラウドベースのクリーンルームソリューション」と呼び、それが「AWS Clean Rooms 上に構築されている」と述べている。クラウドのクリーンルームの上に置く自社の層が、照合、承認済みのクエリ、ブランド向けの画面、ログ、アドサーバーとの連携を担うことができる。
仕事はローンチの後も続く:新しいクエリを確認し、数字についてのブランドの質問に答え、削除の要請を反映し、新しい標準に追随する人が必要だ。自社のチームにそれを担う人がいないなら、まずはクリーンルームを使うか、ライセンスする。
どの道を選んでも、自社で決めることは何か
これらのルールを守らせるのはソフトウェアだが、それを決めるのは自社のチームである:
- ID の照合:メールアドレスやポイントカードの番号など、何をもとに人を照合するのか、そして各側がそれをどう準備するのか。IAB Tech Lab の PAIR プロトコル(Publisher Advertiser Identity Reconciliation)は「可換暗号に依拠している」。各側が自らの秘密鍵で識別子を暗号化し、二重に暗号化された値は、誰も復号することなく比較できる。PAIR は、IAB Tech Lab が2025年7月に非推奨とした以前の OPJA 仕様に取って代わった。どの売上がどの広告のあとに生じたのかの計測については、IAB Tech Lab が2025年2月に ADMaP(Attribution Data Matching Protocol)を確定させている。
- 同意:各買い物客が何に同意したかの記録。IAB Tech Lab のガイダンスは、データを持ち込むすべての企業に、「該当する場合/必要な場合には、同意の証拠を提供する」よう求めている。
- 許可するクエリ:各ブランドが実行してよい分析で、事前に書かれ、承認されたもの。AWS はこれを分析テンプレート(analysis templates)、Google はクエリテンプレート(query templates)と呼んでいる。
- オーディエンスの最小人数:結果の各行は、誰一人として目立たないだけの人数を含んでいなければならない。IAB Tech Lab のガイダンスは具体的な数を定めていない。Google の広告データを分析するための同社のツールである Ads Data Hub は、差分チェック(difference checks)モードでは、結果の1行あたり約50人のユニークユーザーを求めている。ノイズ挿入(noise injection)モードでは約20人を、クエリがクリックとコンバージョンのデータだけを読む場合は約10人を求める。AWS は最小人数に満たない行を除外するが、「クエリの出力は、出力制約のために結果が削除されたことを示さない」。合計が合わないことがある理由を、ブランドに説明しておく。
- ノイズとクエリの上限:差分プライバシーは、答えの一つひとつにわずかなランダムノイズを加えるので、ある一人がデータに含まれていてもいなくても、結果はほとんど変わらない。AWS では、クエリを実行するたびにプライバシーバジェットの一部が消費される。このバジェットと、クエリごとに加えられるノイズによって、パートナーが実行できるクエリの数が制限される。
- ログ:誰がどのクエリをいつ実行したか。IAB Tech Lab のガイダンスは、これらの記録は「すべてのデータ提供者から透明性をもって見えるようにすべきである」としている。
- 結果の取り出し:オーディエンスは、ダウンロードできるメールアドレスのリストとしてではなく、広告システムが使える形で、自社のアドサーバーやブランドの DSP に届かなければならない。
- 削除:コラボレーションが終わったとき、ガイダンスは「データ提供者のデータと、あらゆる DCR の結果の速やかな削除と破棄」を求めている。
クラウドやベンダーと契約する前に、何を確認すべきか
- 自社のデータは自社のアカウントの中にとどまるのか、それともどこか別の場所にコピーが作られるのか
- 各ブランドに、同じプラットフォームのアカウントやライセンスが必要か。その費用は誰が払うのか
- クエリごとの費用は誰が払うのか。ブランドの数が2倍になると、請求額はどう変わるのか
- 自社独自の承認済みクエリを追加し、オーディエンスの最小人数、ノイズ、クエリの上限をブランドごとに設定できるのか
- 自社のデータに対して実行されたすべてのクエリを、誰がいつ実行したのかとともに確認できるのか
- 削除の要請と同意の撤回は、すでにクリーンルームにあるデータにどう反映されるのか
- 離れるときに何を持ち出せるのか。承認済みのクエリ、ログ、そして自社の買い物客の ID をパートナーの ID と結びつける照合テーブルはどうか
コード、クエリ、データは誰のものか
クラウドのクリーンルームでは、サービスはプロバイダーのものであり、自社のチームが書いたクエリは自社のものである。ライセンス製品では、自社のために書かれた分析が自社のものになるのは、契約にそう書かれている場合だけだ。自社で作れば、ソースコードを所有でき、それを変更するためにどのチームでも雇える。開発会社には、自らが保持するコンポーネントと、それらを自社が使い続けられるライセンスを契約に列挙してもらう。
どの道を選んでも、三つのことを契約に盛り込む。買い物客と売上のデータは自社のものであり続け、プロバイダーはそれを自社のクリーンルームを運用するためにだけ使ってよい。承認済みのクエリには自社の計測手法が詰まっているので、それを持ち出せるようにしておくべきだ。照合テーブルは個人データとして扱い、それがどこに保管され、いつ削除されるのかを契約に書いてもらう。
構築を任せる会社に何を聞くべきか
- 自社のクラウドのクリーンルームの上に構築するのか、それとも中核部分を自分たちで書くのか。それはなぜか
- 何をもとに買い物客を照合するのか。照合には PAIR に、計測には ADMaP に従うのか
- 各ブランドのクエリはどう承認され、オーディエンスの最小人数はどこで適用されるのか
- ブランドが二つの結果を比べて一人の買い物客について知ることを、どうやって防ぐのか
- オーディエンスはどうやって自社のアドサーバーとオークションに届くのか。それにはどれくらいの時間がかかるのか
- ログには何が記録され、誰が読めて、どれくらいの期間保存されるのか
- 削除の要請や同意の撤回は、すでに照合されたデータにどうやって届くのか
- いま稼働しているシステムで、これが動いているところを見せてもらえるか
amBrain はどこに位置づけられるか
このブログを発行しているのは amBrain である。amBrain の説明のうち二行は、クリーンルームの両側にあるシステム、つまりクリーンルームに入っていく広告イベントと、そこから出てくるオーディエンスを使うアドサーバーを表している。一行はこうだ:「amBrain はアドテク向けのイベント分析パイプラインを構築する。インプレッションとクリックのイベントの収集、処理、レポーティングである。」もう一行はこうだ:「amBrainはアドサーバーを構築します:ターゲティング、フリークエンシーキャップ、レポーティング。」さらにもう一行はこうある:「RTBBidder、クライアント向けに構築したデマンドサイドプラットフォーム。」
amBrain は2019年からソフトウェアを作っている。顧客との仕事の進め方については、こう述べている:「三つの形態:フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニア。」所有権についての一文はこうだ:「顧客は、プロダクトとコードの完全な所有権を保持する。ただし、私たちの再利用可能なコンポーネントは除く。」署名の前に、そのコンポーネントを名前で列挙した一覧を求めること。
この記事は事例紹介ではない。RTBBidder の名前を挙げていることを除けば、顧客のための仕事については述べていない。amBrain がいずれかの顧客のためにデータクリーンルームを構築、ライセンス、設定したとは述べておらず、amBrain の価格や期間も示さない。ここで名前を挙げたほかの組織は、それぞれが公開しているページから引用しており、この記事は、amBrain とそれらのいずれかとのあいだに何らかの関係があるとは主張しない。
この記事は法的助言でもない。プライバシー法が自社のデータにどう適用されるかは、弁護士に確認する。amBrain が候補リストに入っているなら、ほかのどの会社とも同じ質問をすること。
トピック
- データクリーンルーム
- リテールメディア
- データプライバシー
- 自作か購入か