AWS Clean Rooms

解決する課題

複数の企業が持つデータを突き合わせて分析したい場面は多くあります。たとえば広告主と媒体社が「共通の顧客がどれだけ重複するか」「キャンペーンがどれだけ売上に寄与したか」を知りたいケースです。しかし、そのためにお互いの顧客リストや購買履歴の生データを相手に渡すのは、プライバシーと競争上の観点から大きなリスクになります。AWS Clean Rooms は：

• 各社の生データを相手にコピー・開示せず、合意したクエリだけを実行できる共同分析の場（コラボレーション）を提供する
• 出力できる列・結合キー・集計の粒度を分析ルールで制御し、個人を特定しうる結果が漏れないようにする
• データは各社のS3に置いたまま参照し、結果だけを受け取るため、データの所在と統制を各社が保ち続けられる

「他社とデータを突き合わせたいが生データは渡せない」「広告効果や重複顧客を安全に測りたい」という要件に向きます。他クラウドにも同種のデータクリーンルーム機能はありますが、AWS では既存の S3 データをそのまま活用できる点が特徴です。

主要概念と用語

• コラボレーション: 複数の参加メンバーが共同分析を行う論理的な作業空間。誰が参加し、誰がクエリでき、誰が結果を受け取れるかを定義する
• メンバー: コラボレーションに参加する各組織（AWS アカウント）。データを提供する側、クエリを実行する側、結果を受け取る側といった役割を持つ
• 構成済みテーブル: 各メンバーが自分の Glue データカタログ上のテーブルを、コラボレーションで使える形に登録したもの。実データは自社の S3 に残る
• 分析ルール: 構成済みテーブルに対して許可する分析の種類を定義する設定。代表的に集計・リスト・カスタムなどの型があり、出せる列や結合キー、最小集計件数などを縛る
• 集計分析ルール: 合計や件数などの集計クエリだけを許可し、個別の行が露出しないよう制御する方式
• リスト分析ルール: 重複したエンティティの一覧抽出など、限定した列のリスト出力を許可する方式
• カスタム分析ルール: 許可したクエリやテンプレートに基づき、より柔軟な分析を認める方式
• 差分プライバシー: 結果にノイズを加えて、特定個人の有無が出力から推定されにくくするプライバシー強化技術
• 暗号化コンピューティング: 暗号化したまま結合・突き合わせを行い、生データを復号せずに分析する方式

仕様・制限・クォータ

• 分析の対象は、各メンバーが登録した構成済みテーブルで、実データは各社の S3 と Glue データカタログに残る
• クエリで何を出せるかは分析ルールで制限され、許可されていない列の出力や粒度の細かすぎる結果は実行できない
• 集計分析ルールでは、最小集計件数のしきい値を設定し、その件数未満のグループを結果から除外して個人の露出を防げる
• コラボレーションに参加できるメンバー数や、構成済みテーブル数、同時実行クエリ数などにサービスクォータがあり、必要に応じて引き上げを申請できる
• 機械学習による類似拡張（ルックアライク）など、SQL 以外の分析メニューも用意される

内部の仕組み

Clean Rooms は、データそのものを保管・複製するのではなく、合意したクエリだけを各社のデータに対して安全に実行する仲介の層として動作します。

• 各メンバーが自社の Glue データカタログのテーブルを構成済みテーブルとして登録し、分析ルールで許可する分析範囲を宣言する
• クエリ実行が許可されたメンバーがクエリを投げると、Clean Rooms は各テーブルに付いた分析ルールに照らし合わせ、ルールに反するクエリを拒否する
• 許可された場合のみ、各社の S3 上の実データを読み取って結合・集計し、結果だけを受け取り役のメンバーへ返す
• 差分プライバシーを有効にすると結果にノイズが加わり、暗号化コンピューティングを使うと結合キーを暗号化したまま突き合わせる

設計パターン / ベストプラクティス

• 集計分析ルールを基本に: まずは合計・件数といった集計だけを許可し、最小集計件数のしきい値で小さなグループを除外する
• 差分プライバシーの活用: 個人の有無が結果から推定されるリスクが高い分析では、ノイズを加える差分プライバシーを有効にする
• 暗号化コンピューティングで結合キーを保護: メールアドレスなどの結合キーを平文で扱いたくない場合は、暗号化したまま突き合わせる方式を選ぶ
• 役割を最小限に: クエリを実行できるメンバー、結果を受け取れるメンバーを必要最小限にし、職責を分離する
• テンプレート化したクエリ: カスタム分析ルールでは、許可するクエリやテンプレートをあらかじめ定義し、想定外の分析を防ぐ

運用・監視

• クエリの実行やコラボレーションの設定変更などの操作は CloudTrail で監査できる
• 実行されたクエリの履歴を確認し、分析ルールが意図どおりに機能しているかを定期的に棚卸しする
• 構成済みテーブルと分析ルールの対応関係をドキュメント化し、誰がどの粒度まで分析できるかを明確にしておく
• メンバーの追加・離脱に合わせて、コラボレーションの権限と分析ルールを見直す

コスト

• 課金は主に、コラボレーション内で実行したクエリの計算量に応じて発生する
• 差分プライバシーや暗号化コンピューティングなどのプライバシー強化機能を使うと、処理に応じた費用が加わる
• 参照元となる S3 のストレージや、テーブル定義を管理する Glue データカタログなど周辺サービスの利用量も合わせて見積もる
• データを複製せず各社の S3 を参照するため、共同分析のためにデータを集約・コピーする追加ストレージは基本的に発生しない

セキュリティ

• 各社の生データを相手に開示せず、合意したクエリの結果だけを共有することで、データの囲い込みを保つ
• 分析ルールにより、出力できる列・結合キー・集計粒度を制限し、個人を特定しうる結果の漏えいを防ぐ
• 差分プライバシーや暗号化コンピューティングといったプライバシー強化技術で、結果からの個人推定や結合キーの露出を抑える
• 保管時の暗号化は S3 と KMS、通信は TLS で保護し、操作監査は CloudTrail で行う
• データの所在が各社に残るため、各社が自社データの統制とアクセス権限を保ち続けられる

関連サービス・比較

データのアクセス統制という点で AWS Lake Formation とよく対比されます。Lake Formation は自社内のデータレイクで列・行単位の権限を一元管理するのに対し、Clean Rooms は組織をまたいだ共同分析で生データを開示せずに結果だけを共有する点が異なります。

ハンズオン / CLI例

# コラボレーションを作成（メンバーと能力を指定）
aws cleanrooms create-collaboration \
  --name "ad-measurement" \
  --description "媒体社と広告主の共同分析" \
  --creator-member-abilities CAN_QUERY CAN_RECEIVE_RESULTS \
  --creator-display-name "Advertiser" \
  --query-log-status ENABLED \
  --members '[{"accountId":"111122223333","memberAbilities":["CAN_QUERY"],"displayName":"Publisher"}]'

# 自社の構成済みテーブルに集計分析ルールを設定（最小件数で小グループを除外）
aws cleanrooms create-configured-table-analysis-rule \
  --configured-table-identifier ct-1234567890abcdef \
  --analysis-rule-type AGGREGATION \
  --analysis-rule-policy file://aggregation-rule.json

# コラボレーション内でクエリを実行
aws cleanrooms start-protected-query \
  --type SQL \
  --membership-identifier mem-1234567890abcdef \
  --sql-parameters queryString="SELECT region, COUNT(*) AS cnt FROM overlap GROUP BY region"