Snowflake Clean Roomsで実現するデータコラボレーション

Snowflake Clean Roomsは、複数の組織が互いの生データを公開せずに共同分析を行うためのデータコラボレーション基盤です。 広告効果測定、顧客オーバーラップ分析、データエンリッチメントなどのユースケースで、 プライバシーを保護しながらデータの価値を引き出すことを目的としています。 GDPRやCCPAなどのプライバシー規制への対応が求められる中、 Clean Roomsはサードパーティクッキーの廃止後のマーケティング分析基盤としても注目されています。

Provider / Consumer 構造

Clean RoomsはProvider（データ提供者）とConsumer（データ利用者）の2者間で構成されます。 Providerがデータと分析テンプレートを定義し、ConsumerはテンプレートをAPIとして実行します。

┌─────────────────────────────────┐
│        Provider（広告媒体社）       │
│                                   │
│  [広告インプレッションデータ]         │
│   ├─ user_hash (ハッシュ化ID)      │
│   ├─ campaign_id                  │
│   ├─ impression_date              │
│   └─ channel                      │
│                                   │
│  [分析テンプレート]                  │
│   ├─ Overlap Analysis             │
│   ├─ Reach & Frequency            │
│   └─ Conversion Attribution       │
└──────────────┬──────────────────┘
               │ Clean Room（集計結果のみ共有）
               │ ← 生データは渡さない
┌──────────────┴──────────────────┐
│       Consumer（広告主）           │
│                                   │
│  [顧客データ]                      │
│   ├─ user_hash (ハッシュ化ID)      │
│   ├─ purchase_date                │
│   ├─ product_category             │
│   └─ amount                       │
│                                   │
│  テンプレートを実行 → 集計結果を取得   │
└─────────────────────────────────┘

技術的な仕組み

Clean Roomsは複数のSnowflake機能を組み合わせて実現されています。

テンプレート1：Overlap Analysis（顧客重複分析）

最も一般的なClean Roomのユースケースです。 Provider側の顧客リストとConsumer側の顧客リストをハッシュ化IDで突合し、 重複する顧客数やセグメント別の分布を集計結果のみで返します。

-- Provider側: Overlap Analysisテンプレートの定義（概念例）
CREATE OR REPLACE SECURE FUNCTION clean_room.overlap_analysis(
  consumer_table VARCHAR,
  join_column VARCHAR,
  group_by_column VARCHAR
)
RETURNS TABLE (segment VARCHAR, overlap_count NUMBER, overlap_pct FLOAT)
AS
$
  SELECT
    p.segment,
    COUNT(DISTINCT p.user_hash) AS overlap_count,
    ROUND(COUNT(DISTINCT p.user_hash) * 100.0
      / (SELECT COUNT(DISTINCT user_hash) FROM provider_data.customers), 2) AS overlap_pct
  FROM provider_data.customers p
  INNER JOIN IDENTIFIER(consumer_table) c
    ON p.user_hash = c.user_hash
  GROUP BY p.segment
  HAVING COUNT(DISTINCT p.user_hash) >= 25  -- 最小集計粒度（k-匿名性）
  ORDER BY overlap_count DESC
$;

-- Consumer側: テンプレートの実行
SELECT * FROM TABLE(
  shared_clean_room.clean_room.overlap_analysis(
    'my_db.my_schema.my_customers',
    'user_hash',
    'segment'
  )
);

テンプレート2：Data Enrichment（データエンリッチメント）

Consumer側のデータをProvider側のデータで補強するユースケースです。 たとえばConsumer側の顧客リストに対して、Provider側が保有するデモグラフィック属性のセグメント別集計値を付与します。 個人レベルの属性は返さず、セグメント粒度での統計値のみを提供します。

-- Provider側: Enrichmentテンプレート（概念例）
CREATE OR REPLACE SECURE FUNCTION clean_room.enrich_demographics(
  consumer_table VARCHAR
)
RETURNS TABLE (age_group VARCHAR, income_bracket VARCHAR, user_count NUMBER)
AS
$
  SELECT
    p.age_group,
    p.income_bracket,
    COUNT(DISTINCT c.user_hash) AS user_count
  FROM IDENTIFIER(consumer_table) c
  INNER JOIN provider_data.demographics p
    ON c.user_hash = p.user_hash
  GROUP BY p.age_group, p.income_bracket
  HAVING COUNT(DISTINCT c.user_hash) >= 50
  ORDER BY user_count DESC
$;

テンプレート3：Conversion Attribution（コンバージョン分析）

広告のインプレッションデータ（Provider）と購買データ（Consumer）を突合し、 キャンペーン別のコンバージョン率を集計で算出するパターンです。

-- 概念例: キャンペーン別コンバージョン集計
-- Provider: 広告インプレッション / Consumer: 購買データ

-- 結果のイメージ（集計データのみConsumerに返却）
-- campaign_id | impressions | converters | conversion_rate
-- CAMP_001    | 15,230      | 1,892      | 12.4%
-- CAMP_002    | 28,450      | 2,105      | 7.4%
-- CAMP_003    | 9,870       | 423        | 4.3%

Clean Rooms vs Data Sharing 比較表

プライバシー制御メカニズム

Marketplace連携

Snowflake Marketplaceでは、サードパーティベンダーがClean Roomソリューションを Native Appとして提供しています。LiveRamp、Habu（2024年にSnowflakeが買収）、InfoSumなどが 専用のClean Roomアプリを公開しており、Snowflakeアカウントにインストールするだけで Clean Room機能を利用開始できます。

導入フロー

Step 1: Provider側
  ├─ データの準備（ハッシュ化、匿名化）
  ├─ 分析テンプレートの定義（Secure UDF / Stored Procedure）
  ├─ プライバシー制御の設定（最小粒度、Row Access Policy）
  └─ Clean Roomのデプロイ（Share作成 or Native App公開）

Step 2: Consumer側
  ├─ Shareの受信 or Native Appのインストール
  ├─ 自社データの準備（結合キーのハッシュ化）
  └─ テンプレートの実行と結果の取得

Step 3: 運用
  ├─ テンプレートの実行ログ監視
  ├─ 結果のプライバシー検証
  └─ テンプレートの更新・追加

ベストプラクティス

• 結合キーは必ずハッシュ化する：メールアドレスや電話番号を平文で結合せず、SHA-256等でハッシュ化してからJOINする
• 最小集計粒度を厳格に設定：HAVING COUNT(*) >= 25〜50 を強制し、少数レコードの結果からの個人特定を防ぐ
• テンプレートのSQL内容を定期監査：テンプレートに意図しない集計パス（個人レベルのデータ漏洩につながるクエリ）が含まれていないか定期的にレビューする
• Aggregation Policyとの併用：テンプレート内のHAVING句に加え、Aggregation Policyをテーブルに直接適用することで多層防御を実現する
• Native App Frameworkでパッケージ化：複数のConsumerに同じClean Roomを提供する場合はNative Appとしてパッケージ化し、Marketplace経由で効率的に配布する

問題で確認

よくある質問