AWSデータガバナンス本番運用｜DataZone×Lake Formation

1. なぜデータガバナンス本番運用か — 全体像

データ活用が進む企業ほど「データガバナンスの欠如」という問題に直面します。データレイクに大量のデータを蓄積したものの、「どこに何のデータがあるか分からない」「部門間でデータを共有したくても手続きが不明確」「誰がどのデータにアクセスしたか追跡できない」「GDPR・個人情報保護法への対応証跡がない」という課題が典型的です。AWS はこれらの課題に対して、SageMaker Catalog（DataZone基盤）・Lake Formation・Clean Rooms という3つの主力サービスを組み合わせることで、エンタープライズレベルのデータガバナンスを実現する環境を整えています。

データガバナンスが「今」必要な理由

生成AI・LLM活用が進む2025年以降、データの品質・系譜・アクセス管理はこれまで以上に重要になっています。AIモデルが学習に使うデータの出所が不明確では、モデルの信頼性が担保できません。RAG（Retrieval-Augmented Generation）のナレッジベースに機密データが混入するリスクも現実的です。加えて、データを使って意思決定を支援するBI・データサイエンス組織が拡大するほど、「誰が何を見られるか」という統制の重要性が増します。

規制面でも状況は変わっています。EUのGDPR・日本の個人情報保護法改正・米国州法の相次ぐ施行により、「個人データがどのシステムに保存され、どの処理に使われているか」を証明できないことは経営リスクに直結します。データリネージ（系譜）の自動追跡と監査ログの保存は、もはや「あると便利」ではなく「なければ困る」機能です。

本記事は、これらの現実的なニーズに対して AWS のデータガバナンスサービスがどう応えるかを、本番運用の視点で整理します。

1-1. 本記事のゴール

本記事のゴールは、AWS データガバナンスの主要サービス（SageMaker Catalog / Lake Formation / Clean Rooms）を「データの処理基盤」ではなく「データ資産を統べる統治レイヤ」として理解し、本番環境で設計・運用できる状態を作ることです。分析クエリ・ETL・BIは「データを使う」側の話ですが、本記事は「誰がどのデータにアクセスできるかを統制し、データを安全に発見・共有・コラボレーションする仕組み」を扱います。DataZone から SageMaker Catalog への再編を正確に把握し、Lake Formation のタグベースアクセス制御、Clean Rooms の生データ非共有コラボレーションを設計の選択肢として使いこなせるようになることをゴールとします。

記事を読み終えた読者が「SageMaker Catalog でデータカタログを立ち上げ、Lake Formation でアクセス統制を設計し、必要であれば Clean Rooms で外部コラボレーションを実現する」という本番設計の判断ができる状態を目指します。

1-2. 読者像

想定読者は、S3 データレイクや Glue / Athena / Redshift による分析基盤を構築済みで、次のフェーズとしてデータガバナンス（カタログ化・アクセス統制・組織横断共有・コンプライアンス対応）を本番実装したいデータ基盤エンジニアまたはアーキテクトです。「DataZone を導入しようとしていたが、SageMaker Catalog への統合で何が変わったのか分からない」「Lake Formation の権限設計が複雑で運用できていない」「複数の部門や外部パートナーとデータを安全に共有したいが方法が分からない」という課題を持つ方に特に役立つ内容です。AWSの基本的なアカウント管理と IAM の知識があることを前提とします。

本記事で前提とする技術スタックは S3 + Glue Data Catalog + Athena / Redshift のいずれかを中心としたデータレイク構成です。既存の DataZone 環境を持つ組織、これから新規にデータカタログ・アクセス管理を導入する組織のいずれにも適用できる内容を目指しています。

1-3. 本シリーズの位置づけ

本シリーズ「AWSデータガバナンス本番運用」は、AWS のデータ「統治」に特化したシリーズです。データ「利用」（分析クエリ・ETL・BI）を扱う既存シリーズとは明確に異なります。具体的には、カタログ化（データアセットの発見可能な状態への整理）・アクセス統制（誰が何にアクセスできるかの管理）・組織横断共有（部門間・組織間でのデータ共有とコラボレーション）・リネージ追跡（データの出所と変換履歴の管理）・コンプライアンス対応（GDPR・個人情報保護法等への技術的対応）を扱います。Vol1（本記事）では全体像と主要サービスを、Vol2以降では各サービスの詳細実装と本番運用パターンを扱う予定です。

「処理基盤」と「統治層」の分離という考え方

AWSのデータ基盤を設計するうえで重要な視点は、「データを処理する基盤」と「データ資産を統べる統治層」を別レイヤとして設計することです。Athena・Redshift・EMR・Glue ETL は「処理基盤」であり、データをどう変換・集計・クエリするかを担います。一方、SageMaker Catalog・Lake Formation・Clean Rooms は「統治層」であり、データが正しい人に・正しい方法で・コンプライアンスを遵守しながらアクセスされることを保証します。この2層を意識的に分離して設計することで、処理性能と統治品質の両方を高い水準で維持できます。

1-4. AWSデータガバナンス全体像 — 3サービスの位置づけ

AWSデータガバナンスの核心は、3つのサービスが互いに補完しながら役割を分担する構造にあります。データレイク上に蓄積したデータ資産を「統治」するうえで、それぞれが不可欠な層を担います。

SageMaker Catalog（DataZone基盤）— カタログ・発見・ガバナンス

SageMaker Catalog はデータガバナンスの「コントロールプレーン」です。組織全体のデータアセットを発見可能な状態に整理し、ビジネスメタデータ（説明・オーナー・用語集）を管理します。データプロデューサーとコンシューマーのサブスクリプション申請/承認フロー、ドメイン・プロジェクト単位の組織管理、データリネージの可視化を担います。2024年の再編で SageMaker Unified Studio に統合され、データ発見からML開発まで一貫したワークフローで利用できるようになりました。

AWS Lake Formation — アクセス統制・データ共有

Lake Formation はデータガバナンスの「ポリシー実行エンジン」です。S3上のデータレイクへのアクセスを、LF-Tags（タグベースアクセス制御）・列/行/セルレベルのデータフィルタ・クロスアカウント共有という仕組みで統制します。SageMaker Catalog のサブスクリプション承認フローと連携し、承認操作を起点に Lake Formation がアクセス権限付与を自動実行します。Athena・Redshift・EMR・Glue ETL など多くの AWSサービスが Lake Formation の権限モデルを尊重するため、データアクセスの一元管理が実現できます。

AWS Clean Rooms — 組織間コラボレーション

Clean Rooms はデータガバナンスの「安全な共有空間」です。複数の組織が互いの生データを開示せずに共同分析できる環境を提供します。各参加者が自アカウントにデータを保持したまま、コラボレーションという論理的な作業空間でクエリを実行し、集計結果のみを共有します。差分プライバシー（個人の寄与をノイズで難読化）・Clean Rooms ML（生データ非共有の機械学習）・Entity Resolution（異なるIDでの顧客マッチング）が一般提供済みです。

データメッシュとの関係

3サービスはデータメッシュ（ドメイン分散・データ・アズ・ア・プロダクト・連合ガバナンス）の実装基盤としても機能します。SageMaker Catalog がドメイン横断のカタログと発見を担い、Lake Formation が各ドメインのデータアクセス統制を担い、Clean Rooms が組織外パートナーとのコラボレーションを担う形で、大規模な分散データ環境を管理できます。

3サービスの役割分担まとめ

次のセクションへ →

2. Amazon DataZone と SageMaker Catalog — 最新再編

2-1. 2024 re:Invent の再編整理

2024年11月の AWS re:Invent で発表された「次世代 Amazon SageMaker」は、従来の機械学習特化サービスから大きく進化し、SQL分析・ビッグデータ処理・データ統合・MLモデル開発・生成AI開発を一つのプラットフォームに統合するという方向性を示しました。この再編で特に重要なのは以下の点です。

SageMaker Unified Studio（GA 2025年）

SageMaker Unified Studio は、データエンジニア・データサイエンティスト・機械学習エンジニアが単一の統合開発環境（IDE）で作業できる環境です。従来は Amazon EMR Studio・Redshift Query Editor・SageMaker Studio・DataZone ポータルがそれぞれ独立していましたが、Unified Studio に統合されることで、データの発見・変換・分析・モデル開発を一貫したワークフローで実施できるようになります。

SageMaker Catalog（DataZone の進化形）

SageMaker Catalog は、Amazon DataZone を基盤とする進化形（”an evolution of Amazon DataZone”）です。DataZone が担っていたデータ発見・ビジネスメタデータ管理・データプロダクト公開・アクセス申請/承認ワークフロー・コラボレーション機能をすべて引き継ぎつつ、SageMaker Unified Studio と統合されています。

DataZone は廃止ではなく統合進化

DataZone は廃止されたわけではありません。既存の DataZone ドメイン・プロジェクト・ビジネス用語集・データプロダクトは引き続き利用できます。ただし、新規に構築する場合は SageMaker Catalog / Unified Studio を採用することが現役推奨です。「DataZone」という名称が AWS ドキュメントやコンソールに残っている箇所は、SageMaker Catalog の基盤機能として位置づけられています。

SageMaker AI への改称

従来の Amazon SageMaker（機械学習モデルの構築・学習・デプロイ）は、「SageMaker AI」に改称されました。次世代 SageMaker プラットフォームのコンポーネントの一つとして、引き続きモデル開発・推論エンドポイント管理などを担います。名称変更はあっても機能は継続しており、既存の SageMaker SDK・API は動作し続けます。

再編の全体像

この再編により、「データカタログ担当者」「データエンジニア」「データサイエンティスト」が互いに異なるツールセットで作業していた状況を、単一の環境に収束させることが目指されています。

2-2. データカタログとビジネスメタデータ

SageMaker Catalog（DataZone基盤）のコアは、組織全体のデータアセットを発見可能な状態に整理するカタログ機能です。S3・Glue Data Catalog・Redshift・RDS・DynamoDB 等の多様なデータソースからアセットを取り込み、技術メタデータ（スキーマ・データ型・統計情報）とビジネスメタデータ（説明・オーナー・タグ・ビジネス用語集への紐付け）を統合管理します。

ビジネス用語集（Business Glossary）

ビジネス用語集は、組織内で使われるビジネス概念（「顧客」「売上」「製品」等）を標準定義として管理する機能です。同じデータでも部門によって呼び名が異なる問題（「customer」と「client」が同じ概念等）を解消し、データアセットを用語集の概念に紐付けることで、ビジネスユーザーが技術的な知識なしにデータを検索・理解できるようになります。

データプロダクトの公開フロー

データプロデューサー（データアセットのオーナー）がデータプロダクトを公開するまでの流れは以下の通りです：

1. データソース接続を設定し、SageMaker Catalog にデータアセットをインポートする
2. ビジネスメタデータ（説明・オーナー・ビジネス用語集との紐付け・タグ）を入力する
3. データプロダクトとしてドメインのカタログに公開する（Glue Data Catalog と自動同期）
4. 公開されたデータプロダクトは組織全体の検索インデックスに登録され、コンシューマーが発見できる状態になる

アクセス申請と承認ワークフロー

コンシューマーがデータプロダクトへのアクセスを希望する場合、「サブスクリプション」申請を送付します。プロデューサー側の承認者（ドメインオーナーまたは指定した承認者）が申請を確認し承認すると、Lake Formation が自動的に当該データへのアクセス権限を付与します。拒否した場合は理由をコメントとして返送でき、申請の全履歴が監査ログとして保存されます。

このサブスクリプション申請フローにより、「Slackでアクセス申請→手動でS3バケットポリシーを修正→報告」という属人的なアクセス付与作業を廃止し、ガバナンスの効いた自動化されたアクセス管理を実現できます。

メタデータ自動収集（Glue クローラー連携）

SageMaker Catalog は Glue Data Catalog と双方向同期しているため、Glue クローラーが新しいテーブルを検出すると自動的にカタログに反映されます。逆に、SageMaker Catalog で付与したビジネスメタデータも Glue Data Catalog のテーブルプロパティに書き戻されます。これにより、技術メタデータとビジネスメタデータを一元的に管理する仕組みが成立します。

なお、Redshift や RDS などの JDBC ベースのデータソースも、SageMaker Catalog のデータソース接続設定（ブループリント）を通じてカタログに取り込めます。異種データストア間でのデータ発見と横断検索が、Unified Studio の単一UIから実現できる点は、大規模組織での実用性を高める大きな特徴です。

また、カタログへの登録だけでなく、SageMaker Catalog の検索機能ではフリーテキスト・タグ・オーナー・技術的フォーマット（Parquet / CSV / Delta Lake 等）での絞り込みが可能で、数千件のデータアセットを持つ大規模組織でも目的のデータを迅速に発見できます。

2-3. ガバナンスポータルとプロジェクト

SageMaker Catalog（DataZone基盤）は「ドメイン」と「プロジェクト」という二層の組織構造でデータとメンバーを管理します。

ドメイン（Domain）

ドメインはガバナンスの最上位単位で、組織全体または大きな事業部門に対応します。一つのドメインに対して一つの AWS アカウント（またはアカウントグループ）を割り当てるのが基本です。ドメインは以下を管理します：

• ドメインメンバーとロール（ドメインオーナー / コントリビューター / コンシューマー）
• ビジネス用語集とメタデータ標準
• カタログに公開されたデータプロダクト一覧
• 他ドメインとのサブスクリプション関係

プロジェクト（Project）

プロジェクトはドメイン内の作業単位で、特定の分析・開発プロジェクトやデータパイプラインに対応します。プロジェクトメンバーは共有の環境（SageMaker Unified Studio 上のスペース）と、プロジェクトに紐付いたデータアセットへのアクセスを得ます。プロジェクト単位でデータのプロデューサー（公開者）とコンシューマー（利用者）の役割を管理できます。

データプロデューサーとコンシューマーの分離

SageMaker Catalog はデータの流れを「プロデューサー側ドメイン → カタログ公開 → コンシューマー側ドメイン/プロジェクトが申請 → 承認 → アクセス」という明確なフローで管理します。この分離により：

• プロデューサー側は公開するデータの品質とメタデータに責任を持つ
• コンシューマー側は不要なアクセスを持たない（最小権限の徹底）
• 承認記録が監査証跡として自動保存される

単一の権限モデル

SageMaker Catalog は Lake Formation と統合し、「どのプリンシパルがどのデータプロダクトに対してどの操作を許可されるか」を一元管理します。IAM ポリシーを直接操作する必要はなく、SageMaker Catalog のサブスクリプション承認フローが Lake Formation のデータ権限付与を自動的にトリガーします。これにより、権限付与のミスや漏れを防ぎ、大規模組織でも一貫したアクセス管理を維持できます。

ロール設計のベストプラクティス

ドメイン・プロジェクトを設計する際は、以下のロール分担を基本とすることを推奨します：

ドメインオーナーはビジネス部門の責任者が担い、プロジェクトオーナーはデータプロダクトを所有するチームリーダーが担うことで、IT部門だけでなく事業部門もガバナンスに参加する体制を作れます。これはデータメッシュの「ドメイン指向のオーナーシップ」を組織として実現する設計です。

監査ログの活用

SageMaker Catalog は CloudTrail と統合されており、サブスクリプション申請・承認・拒否・メタデータ変更など、すべての操作が自動的にログとして保存されます。「誰が・いつ・どのデータへのアクセスを承認したか」の証跡を、コンプライアンス審査や内部監査の際に即座に提出できます。CloudTrail のログは S3 に保管され、Athena でのアドホッククエリにも対応しています。

2-4. 既存 DataZone 環境からの移行ガイダンス

DataZone を既に本番運用している組織にとって、SageMaker Catalog への移行（または共存）は重要な判断ポイントです。現時点（2025年）での AWS の公式見解と実務的な移行ガイダンスを整理します。

移行の基本方針

AWS は DataZone から SageMaker Catalog への「移行」を求めているわけではなく、「新規構築は SageMaker Catalog / Unified Studio を使う」という方向性を示しています。既存の DataZone 環境は引き続き動作し、API・SDK・CLI も後方互換性を維持しています。

DataZone API と SageMaker Catalog の関係

重要な点として、SageMaker Catalog は DataZone API の上に構築されています。AWS マネジメントコンソールで「SageMaker」から入ると Unified Studio の UI になりますが、バックエンドでは DataZone の API が動作しています。つまり、既存の DataZone API を使ったカスタム統合（Lambda ベースのサブスクリプション自動化・外部システムへのメタデータ同期など）は、そのまま動作し続けます。

移行時の実務チェックリスト

新規構築時の推奨アーキテクチャ

新規でデータカタログ・ガバナンス基盤を構築する組織は、SageMaker Unified Studio からドメインを作成し、SageMaker Catalog でデータアセットを管理する構成を採用することを推奨します。DataZone の API・コンソール名で開始した場合でも、同一の基盤を使うため実質的な違いはありません。

2-5. SageMaker Unified Studio — 統合開発体験

SageMaker Unified Studio は、2025年にGA（一般提供）になったデータガバナンスと開発の統合環境です。従来の DataZone ポータル・EMR Studio・Redshift Query Editor・SageMaker Studio がそれぞれ独立していた時代から、単一の環境でこれらのワークフローをシームレスに繋げることが目標です。

Unified Studio のスペース（Space）とプロジェクト

Unified Studio では「スペース」と呼ばれる作業エリアを中心に操作します。スペースはプロジェクトに紐付けられており、プロジェクトメンバーが以下のリソースにアクセスできます：

• データカタログ：SageMaker Catalog のデータプロダクト発見・サブスクリプション申請
• クエリエディタ：Athena・Redshift のクエリ実行（ブラウザ上で完結）
• ノートブック：JupyterLab 環境（Glue/EMR/SageMaker AI の計算リソースに接続）
• データフロー：Glue ETL・Apache Spark ジョブの視覚的な設計と実行
• MLプロジェクト：SageMaker AI との統合（モデル学習・評価・デプロイ）

発見から分析までのワークフロー例

① SageMaker Catalog で「売上データ」を検索
→ テーブルのスキーマ・オーナー・品質スコアを確認
→ サブスクリプション申請（承認まで通知を受け取る）

② 承認後、Unified Studio のクエリエディタで Athena クエリを実行
→ プロジェクトの権限でアクセス（追加のIAM設定不要）

③ ノートブックで Python / Spark 処理
→ 前処理・集計・可視化を Jupyter 上で実施

④ 作成したデータプロダクトを SageMaker Catalog に公開
→ 他のチームが同じフローでサブスクリプション申請可能

このワークフローにより、「データを探す→アクセスを申請する→分析する→結果を共有する」という一連のサイクルが Unified Studio 内で完結します。従来は「DataZone でメタデータ確認→別ブラウザタブで Athena 開く→結果を S3 に保存→Slackで共有」といった断片的な作業が必要でしたが、Unified Studio はこれを統合します。

従来環境からの接続性

Unified Studio は新しいUIですが、バックエンドの AWS サービス（Athena・Glue・EMR・Redshift・SageMaker AI）は従来と変わりません。既存の Terraform・CloudFormation で管理したインフラにそのままアクセスでき、Unified Studio 外で作成したリソース（Glue ジョブ・Athena ワークグループ等）も Unified Studio から参照できます。移行コストはUIの慣れの問題が中心で、既存インフラの再構築は原則不要です。

3. Lake Formation 連携 — LF-Tags・セルレベルセキュリティ

3-1. Lake Formationとデータ統制の位置づけ

AWS Lake Formationは、Amazon S3上のデータレイクに対して細粒度のアクセス制御を提供するサービスです。Glue Data Catalogと統合し、テーブル・列・行レベルの統制を一元的に管理できます。2022年以降、LF-Tagsを活用したタグベースアクセス制御（LF-TBAC）が実用段階に達し、数十〜数百テーブルにまたがる大規模データレイクでもポリシー管理が現実的になりました。

Lake Formationの中心的な役割は「データ統制（Governance）」です。具体的には次の機能を担います：

• Glue Data Catalog との統合：テーブル・データベース・列のメタデータを管理し、統制の基盤を提供
• アクセス制御の集中化：S3バケットポリシーを Lake Formation が抽象化し、データリソース単位での管理を実現
• データフィルタ：行・列・セルレベルの細粒度フィルタリング
• 監査証跡：CloudTrail との統合によるアクセスログ記録と監査対応

Lake Formation のデータアクセスモードを「Lake Formation mode」に設定すると、ユーザーが S3 バケットへの直接アクセス設定を持たなくても Lake Formation の設定のみでデータを参照できます。これにより「S3 バケットポリシーを迂回した直接アクセス」を防止できます。

3-2. LF-Tags（Lake Formation Tag-Based Access Control）

LF-TBAC は、Glue Data Catalog のリソース（データベース・テーブル・列）にキー・バリュー形式のタグを付与し、そのタグ式に基づいてアクセスを付与する仕組みです。個別リソースへの権限定義ではなく「タグの意味」に基づいた一括管理が実現します。

LF-Tag の作成と付与

まずタグのキーと許容バリューを作成します：

aws lakeformation create-lf-tag \
  --tag-key "module" \
  --tag-values '["sales", "marketing", "finance"]'

次にテーブルへタグを付与します：

aws lakeformation add-lf-tags-to-resource \
  --resource '{"Table": {"DatabaseName": "sales_db", "Name": "transactions"}}' \
  --lf-tags '[{"TagKey": "module", "TagValues": ["sales"]}]'

タグ式による権限付与

LF-Tag 式の例：

module=sales AND division=(consumer OR commercial)

このタグ式を満たすリソース（データベース・テーブル・列）への SELECT 権限を、特定のプリンシパルに一括で付与できます。Named Resource 方式のようにテーブルを個別指定する必要がなく、タグ付けを変更するだけで権限範囲が自動的に更新されます。

LF-TBAC と Named Resource 方式の比較

数百テーブルが存在するデータレイクでは LF-TBAC が特に効果を発揮します。新しいテーブルが追加された際、適切なタグを付与するだけで既存のポリシーが自動的に適用されます。ただし、タグ付けのガバナンス（誰がどのタグを付与できるか）を別途管理する必要があります。

3-3. データフィルタによる列・行・セルレベルセキュリティ

Lake Formation はデータフィルタ（Data Cells Filter）を使用して、列・行・セルレベルの細粒度アクセス制御を実現します。これは「セルレベルセキュリティ」とも呼ばれます。

データフィルタの種類

データフィルタの設定例

特定の列と特定の行を組み合わせたデータフィルタを作成します：

aws lakeformation create-data-cells-filter \
  --table-data '{
 "TableCatalogId": "123456789012",
 "DatabaseName": "sales_db",
 "TableName": "transactions",
 "Name": "consumer_division_filter"
  }' \
  --column-names '["transaction_id", "amount", "product_id", "region"]' \
  --row-filter '{"FilterExpression": "division = '\''consumer'\''"}'

このフィルタを適用されたユーザーは、division = 'consumer' に一致する行の指定した4列のみを参照できます。

列レベル LF-Tags と Glue ETL の競合に注意

3-4. クロスアカウントデータ共有

Lake Formation では、同一 AWS アカウント内だけでなく、別アカウントのプリンシパルに対してもデータアクセスを付与できます。方式は2つあります。

Named Resource ベースのクロスアカウント共有

データプロデューサーアカウント（共有元）で、特定テーブルに対してコンシューマーアカウントへのアクセスを付与します：

aws lakeformation grant-permissions \
  --principal '{"DataLakePrincipalIdentifier": "123456789012"}' \
  --resource '{"Table": {"DatabaseName": "sales_db", "Name": "transactions"}}' \
  --permissions '["SELECT"]'

コンシューマーアカウント側では Resource Link を作成し、自アカウントの Glue Data Catalog から参照します。Resource Link は論理的なポインタであり、実際のデータはプロデューサー側に留まります。

LF-Tags ベースのクロスアカウント共有

LF-Tags を使用したクロスアカウント共有では、タグ式に一致するリソース群を一括で共有できます。Named Resource ベースと異なり、新しいリソースが追加されてもタグ付けだけで自動的に共有対象に含まれます。

クロスアカウント共有の注意点

• Resource Link は作成したアカウントにのみ表示される（実際のデータはプロデューサー側）
• コンシューマー側でデータフィルタを追加し、さらに絞り込んだアクセスも実現可能
• クロスリージョン共有は 2024 年時点でサポートされていない
• AWS Organizations の RAM（Resource Access Manager）と統合することで組織レベルの一括共有も可能

3-5. 権限設計の指針と最小権限の実現

Lake Formation の権限設計では、データへのアクセス制御と ETL パイプラインの実行設定を分離することが重要です。

用途別の推奨アプローチ

Lake Formation 管理者の設計

Lake Formation には「データレイク管理者」と「データ管理者」の役割があります。組織全体のガバナンスでは、中央管理チームが LF-Tag の定義を担い、各ドメインチームが自ドメインのテーブルへのタグ付けを担当する形が一般的です。タグ付け作業を分散させることで、中央チームへの依頼なしにドメインが自律的にデータを管理できます。

4. AWS Clean Rooms — 差分プライバシーとコラボレーション

4-1. Clean Roomsのコンセプトとユースケース

AWS Clean Roomsは、複数の組織が互いの生データを開示することなく共同でデータ分析を実施できるサービスです。2022年のプレビューを経て2023年に一般提供（GA）が開始され、2024年には差分プライバシー・Clean Rooms ML・Entity Resolutionなど主要機能が相次いでGAになりました。

Clean Roomsが解決する課題

従来の共同分析では「CSVファイルを交換する」「共有の S3 バケットを使う」などの方法が取られていました。しかしこれらは：

• 生データの相手先への露出リスクを伴う
• データ主体のプライバシー保護が困難
• GDPR・個人情報保護法などのコンプライアンス対応が複雑化

Clean Rooms では、各参加者が自アカウントの S3 にデータを保持したまま、コラボレーション（collaboration）という論理的な共同作業空間で分析クエリを実行します。分析結果のみが共有され、互いの生データへのアクセスは物理的に遮断されます。

主なユースケース

• 広告効果測定（メディア×広告主：広告接触データと購買データの照合）
• 金融リスク分析（複数金融機関の顧客重複分析）
• ヘルスケアリサーチ（複数病院の患者データ集計）
• リテールメディアネットワーク（小売×ブランドの販売実績分析）

4-2. コラボレーション設定と分析ルール

コラボレーションの構成要素

Clean Rooms のコラボレーションは以下の要素で構成されます：

分析ルール（Analysis Rules）の種類

Clean Rooms では、テーブルごとに分析ルールを設定し、どのような分析を許可するかを細かく制御します（fine-grained analysis rules）：

1. Aggregation：集計クエリのみ許可。GROUP BY 必須、最小グループサイズ設定可能（再識別防止）
2. List：行リスト出力を許可。指定列のみ出力可能
3. Custom：AWS Glue ETL を使用したカスタム変換処理
4. ID Mapping Table：Entity Resolution 統合時の ID マッピング専用

最小集計サイズの設定例

{
  "aggregationRules": {
 "allowedAggregations": ["COUNT", "SUM", "AVG"],
 "minimumNumberOfMatchingRows": 5,
 "allowedJoinColumns": ["customer_id"],
 "joinRequired": "QUERY_RUNNER"
  }
}

最小グループサイズを 5 件に設定することで、5 件未満のグループは結果から除外され、小集団からの個人特定を防止できます。

4-3. 差分プライバシー（Differential Privacy）

差分プライバシー（Differential Privacy、DP）は、個人の寄与をノイズで難読化することで、集計結果から特定個人の情報が推測できないようにする数学的プライバシー保証の仕組みです。AWS Clean Rooms では 2024年4月にGAになりました。

差分プライバシーの基本概念

差分プライバシーが防ぐ攻撃パターン

差分プライバシーを使用すると、特定の個人データを1件追加・削除しても、クエリ結果が区別できないことが数学的に保証されます。これにより：

• 差分攻撃の防止：繰り返しクエリにより個人情報を推測する手法を無効化
• 再識別リスクの低減：集計結果の外部公開・共有時のリスクを大幅に削減
• 規制対応の強化：GDPR など各国のプライバシー規制への対応証跡として活用可能

差分プライバシーはコラボレーションの分析ルールとして設定します。既存の集計クエリに対して追加の設定で有効化できるため、既存のコラボレーション構成を大幅に変更せずに導入できます。

4-4. Clean Rooms ML — 生データ共有なしの予測

Clean Rooms ML は、生データを共有することなく機械学習モデルによる予測・セグメンテーションを複数組織間で実施できる機能です。2024年4月にGAになりました。

lookalikeセグメント生成のしくみ

最も代表的なユースケースは広告主とメディア/DSPの間での lookalike オーディエンス生成です：

1. モデルトレーナー（例：広告主）：購買済み顧客のシードデータを Clean Rooms に提供
2. モデルコラボレーター（例：メディア企業）：自社の全ユーザーデータを Clean Rooms に提供
3. Clean Rooms ML が生データを直接共有せずに lookalike スコアを算出
4. コラボレーターはスコアリング結果（オーディエンスリスト）のみ取得し、広告配信に活用

生データが共有されない理由

広告主（シードデータ）  →  Clean Rooms ML  ←  メディア（全ユーザーデータ）
↓ 生データは自アカウントに留まる ↓
  lookalike スコアのみ出力
↓
メディア：スコアを広告ターゲティングに活用

モデルの学習・スコアリングは Clean Rooms 内で完結し、各参加者のアカウントには生データが移動しません。

4-5. Entity Resolution / ID Mapping

Entity Resolution（2024年7月GA）は、異なるデータセット間で同一エンティティ（顧客・商品等）を一致させる機能です。ID が異なる複数のデータセットを、個人情報を直接共有せずに結合できます。

代表的なユースケース

• ID グラフ構築：メールアドレス・電話番号・デバイス ID などの異なる ID を同一顧客として紐付け
• 広告主×メディアのオーディエンスマッチング：ハッシュ化された ID で一致率を算出し、共同ターゲティングを実現
• 小売×金融のクロス分析：購買データと与信データの安全な照合

増分更新（Incremental Update）

2024年7月のリリースには増分更新機能も含まれています。フルスキャンではなく変更分のみを処理することで、ID マッピングのデータ鮮度を維持しながらコストと処理時間を削減できます。大規模なデータセットの更新処理を現実的なコストで継続的に実行できます。

IDマッピングテーブルの設定例

{
  "idMappingRule": {
 "joinColumns": ["hashed_email"],
 "queryConstraints": [{
"requireOverlap": {
  "columns": ["customer_id"]
}
 }]
  }
}

4-6. 暗号計算（Cryptographic Computing）

暗号計算は、データを暗号化したまま演算を行う高度なプライバシー保護技術です。Clean Rooms の暗号計算機能により、コラボレーション参加者がデータを復号せずに分析できます。

暗号計算が適したシナリオ

• 政府機関・医療機関など、生データの一時的な復号も許容できない高機密領域
• クロスボーダーデータ転送の規制が厳しい地域でのコラボレーション
• 法規制により「処理中のデータも保護が必要」とされるケース

技術的な仕組み

Clean Rooms の暗号計算では、暗号化された ID の一致（インターセクション）を計算するプロトコルを使用します。参加者は一致するレコード数や集計値のみを得ることができ、一致しないレコードの情報は相手に漏れません。これは Private Set Intersection（PSI）と呼ばれるプロトコルに基づいています。

差分プライバシーとの組み合わせ

暗号計算と差分プライバシーは組み合わせて利用できます。暗号計算で「処理中のデータ」を保護しつつ、差分プライバシーで「出力結果からの個人特定」を防止することで、二重のプライバシー保護を実現します。規制要件の厳しい業界（金融・医療・行政）では、この組み合わせが有力な選択肢となります。

5. データメッシュ実装 — 連合ガバナンス

大規模組織でデータを分散管理する「データメッシュ」は、モノリシックな中央集権型データレイクが抱えるボトルネック（チーム間の依存・品質責任の曖昧さ・スケール限界）を根本から解決するアーキテクチャパラダイムだ。AWS は SageMaker Catalog（DataZone基盤）と Lake Formation を組み合わせることで、データメッシュの理念を本番規模で実装できる環境を整えている。

5-1. データメッシュの4本柱

① ドメイン指向の分散オーナーシップ

データの所有権をドメインチーム（マーケティング・フィナンス・サプライチェーン等）が持つ。中央データチームはプラットフォームと標準を管理するが、データ自体の品質・鮮度・スキーマ管理はドメインが担う。これにより「データの要求が中央チームに集中してボトルネックが生まれる」という従来型の問題を排除できる。

② データ・アズ・ア・プロダクト

ドメインが公開するデータをプロダクトとして扱う。発見可能（Discoverable）・理解可能（Understandable）・信頼可能（Trustworthy）・アドレス可能（Addressable）・安全（Secure）・相互運用可能（Interoperable）の6要素を満たすことが求められる。SageMaker Catalog のドメインとプロジェクト機能は、このプロダクト概念を直接サポートしている。

③ セルフサーブ型データ基盤

ドメインチームが独立してデータプロダクトを作成・公開・消費できるプラットフォームインフラを用意する。SageMaker Unified Studio はデータ変換・分析・ガバナンスを統合した環境として、ドメインチームが中央チームへの依頼なしに作業できるセルフサービス体験を提供する。

④ 連合ガバナンス（Federated Computational Governance）

各ドメインが自律的にガバナンス実装を行いながら、組織全体でポリシー・標準・コンプライアンスを遵守させる仕組み。技術的なアクセス制御はドメイン側が Lake Formation のタグや権限ポリシーで実装し、中央（SageMaker Catalog のガバナンスポータル）はデータ発見・レポート・監査のハブとして機能する。

5-2. AWS実装：SageMaker Catalog × Lake Formation

SageMaker Catalog（DataZone基盤）では「ドメイン」単位でデータプロダクトを整理する。各ドメインは独自のプロジェクト・メンバー・ビジネス用語集・データカタログを持ち、他ドメインへのデータ公開はサブスクリプション申請と承認ワークフローを通じて行う。これにより「どのデータがどのドメインにあるか」が組織全体で発見可能になる。

Lake Formation はデータへの実際のアクセス制御（LF-Tags・列・行・セルレベル）を提供し、SageMaker Catalog と連携してアクセス申請の承認をトリガーに権限付与まで自動化できる。クロスアカウント共有も LF-Tags 方式または named resource 方式で設定でき、複数 AWS アカウントに分散したデータメッシュアーキテクチャを実現する。

データプロダクトの公開・発見フロー

1. ドメインチームがデータアセット（S3/Glue/Redshift等）を SageMaker Catalog に登録し、ビジネスメタデータ（説明・用語集・オーナー情報）を付与する
2. SageMaker Catalog がデータプロダクトとして組織横断カタログに公開する
3. コンシューマー（他ドメイン/分析チーム）がカタログを検索し、サブスクリプション申請を送付する
4. プロデューサードメインの管理者が申請を承認すると、Lake Formation が対象プリンシパルに権限を付与する
5. コンシューマーは Athena・Redshift・EMR から直接データを参照できる

5-3. 実例：Covestro と ANZ

Covestro（特殊化学品メーカー）

Covestro は集中データレイクから AWS 上のデータメッシュへの移行を実施した。DataZone（現 SageMaker Catalog）でドメインごとのデータプロダクトを管理し、各事業部門が自律的にデータを公開・消費できる体制を構築した。中央のITチームがプラットフォームと標準を管理しながら、ドメインが品質責任を持つ分散モデルへの転換に成功している。

ANZ バンキンググループ

ANZ はリテール・コマーシャルの各バンキング部門を DataZone と Lake Formation の連合プラットフォームで接続した。規制データのアクセス制御を Lake Formation の LF-Tags で実装し、部門横断のデータ利活用とコンプライアンス要件を両立している。SageMaker Catalog の発見機能により、データサイエンティストが必要なデータセットを自ら発見・申請できる環境を実現している。

graph TD
 subgraph 中央ガバナンスハブ
  SMC[SageMaker Catalog\nドメイン横断カタログ]
  GP[ガバナンスポータル\n発見 / レポート / 監査]
  LF[Lake Formation\nアクセス制御エンジン]
 end

 subgraph ドメインA[ドメイン A — マーケティング]
  DA1[データプロダクト A1\n顧客セグメント]
  DA2[データプロダクト A2\nキャンペーン実績]
 end

 subgraph ドメインB[ドメイン B — フィナンス]
  DB1[データプロダクト B1\n売上リネージ]
  DB2[データプロダクト B2\nコスト配賦]
 end

 subgraph コンシューマー
  AN[分析チーム\nAthena / Redshift]
  DS[データサイエンス\nSageMaker AI]
 end

 DA1 -->|カタログ登録| SMC
 DA2 -->|カタログ登録| SMC
 DB1 -->|カタログ登録| SMC
 DB2 -->|カタログ登録| SMC

 SMC --> GP
 GP --> LF

 AN -->|発見 → 申請| SMC
 DS -->|発見 → 申請| SMC

 SMC -->|承認後 権限付与| LF
 LF -->|データアクセス許可| AN
 LF -->|データアクセス許可| DS

6. データ品質・リネージ

データガバナンスの実効性は、データが「どれだけ信頼できるか」と「どこから来たか」を継続的に検証できるかどうかにかかっている。AWS Glue Data Quality によるルールベースの品質チェック、SageMaker Catalog（DataZone基盤）のビジュアルリネージ、そして OpenLineage 連携による標準化されたリネージ収集が、この「品質と系譜」の柱を担う。

6-1. Glue Data Quality — ルール定義・スコアリング・アラート

Glue Data Quality は、ETL パイプラインにインラインで品質チェックを組み込む仕組みだ。Data Quality Definition Language（DQDL）でルールを宣言的に記述し、レコード完全性・値の範囲・一意性・参照整合性などを自動検証する。

ルール定義の例（DQDL）：

Rules = [
 IsComplete "customer_id",
 ColumnValues "order_amount" between 0 and 1000000,
 IsPrimaryKey "order_id",
 ColumnCount >= 5
]

各ルールの合否に基づいてデータ品質スコア（0.0〜1.0）が算出される。スコアが閾値を下回った場合はGlueジョブを停止させるか、CloudWatch アラートを発火させるかを設定で切り替えられる。品質スコアとルール結果は S3 に保存されるため、Athena や Glue Studio のダッシュボードで時系列の品質トレンドを可視化できる。

Glue Studio の視覚エディタから EvaluateDataQuality トランスフォームをドラッグ＆ドロップするだけで、ジョブの中間ステップとして品質チェックを挿入できる。結果は Glue Data Catalog のテーブルプロパティとして書き戻すことも可能で、SageMaker Catalog の品質メトリクスビューに自動反映される。

6-2. データリネージ — SageMaker Catalog のビジュアルリネージ

データリネージ（Data Lineage / 系統）は「このデータはどのソースから、どの変換を経て、現在の形になったか」を追跡する機能だ。SageMaker Catalog（DataZone基盤）はビジュアルリネージグラフを内蔵しており、S3・Glue・Redshift・EMR 等の資産間の上流・下流関係を GUI で確認できる。

リネージが解決する主なユースケース：

• 障害波及分析: 上流データソースに問題が発生したとき、どのデータプロダクト・レポートが影響を受けるかをグラフで即座に把握する
• コンプライアンス監査: 個人情報が含まれるテーブルが、どの下流テーブル・ダッシュボード・分析レポートに流れているかを証跡として保存する
• スキーマ変更の影響調査: 上流テーブルのスキーマが変わった場合、影響を受ける下流処理を事前に洗い出す

SageMaker Catalog にリネージを取り込む方法は主に2つある。Glue ETL ジョブを実行すると DataZone が自動的にリネージエンティティ（実行・ジョブ・アセット）を生成・収集する方法と、後述の OpenLineage プロトコルで外部システムからリネージイベントをプッシュする方法だ。

6-3. カタログ自動化 — Glue Crawler × EventBridge

データを S3 に投入してもカタログに反映されなければ、発見性も品質チェックも機能しない。Glue Crawler は S3・JDBC・DynamoDB・Delta Lake 等のデータソースを定期スキャンし、Glue Data Catalog にテーブル定義を自動登録・更新する。

EventBridge 連携による即時自動化フロー：

1. S3 への新規オブジェクト投入が EventBridge に PutObject イベントを送出する
2. EventBridge ルールが Glue Crawler の起動をトリガーする
3. Crawler 完了イベントが再び EventBridge に流れ、後続の Glue ETL ジョブや Lambda 関数を起動する
4. ETL 完了後に Glue Data Quality の評価が走り、スコアを Glue Data Catalog に書き戻す

この連鎖により、データ投入から品質チェック・カタログ更新までが完全自動化される。SageMaker Catalog は Glue Data Catalog と連携しているため、カタログ更新が即座にビジネスメタデータビューに反映される。

6-4. OpenLineage 連携

OpenLineage は、データリネージのメタデータを標準フォーマットで収集・交換するためのオープンスタンダードだ（Linux Foundation ホスト）。Spark・Airflow・dbt など多数のデータエンジンがネイティブの OpenLineage エミッターを持っており、異種スタック間でリネージを統合的に追跡できる。

SageMaker Catalog（DataZone基盤）は OpenLineage API エンドポイントを公開しており、OpenLineage 形式のリネージイベント（RunEvent / DatasetEvent 等）を直接受け付ける。これにより、AWS 外のオンプレミス Spark ジョブや Airflow パイプラインが生成したリネージも、SageMaker Catalog の統合グラフに取り込める。

EMR/Spark からの OpenLineage イベント送信例：

spark-submit \
  --packages io.openlineage:openlineage-spark:1.x.x \
  --conf spark.extraListeners=io.openlineage.spark.agent.OpenLineageSparkListener \
  --conf spark.openlineage.transport.type=http \
  --conf spark.openlineage.transport.url=https://datazone.<region>.amazonaws.com/v1/lineage \
  my_etl_job.py

上記設定だけで、Spark ジョブが実行するたびに読み書きするデータセットとジョブの関係が SageMaker Catalog に自動記録される。

graph LR
 subgraph ソース
  S3[S3\nRaw Data]
  RDS[RDS\nトランザクションDB]
 end

 subgraph ETL処理
  GC[Glue Crawler\n自動スキーマ検出]
  GDQ[Glue Data Quality\nルール評価 / スコア]
  ETL[Glue ETL Job\nSpark 変換]
 end

 subgraph カタログ / リネージ
  GDC[Glue Data Catalog\nテーブル定義]
  SMC[SageMaker Catalog\nリネージグラフ]
  OL[OpenLineage\nイベント収集]
 end

 subgraph 通知 / 監視
  CW[CloudWatch\nアラート]
  EB[EventBridge\nイベントルーティング]
 end

 S3 -->|スキャン| GC
 RDS -->|JDBC スキャン| GC
 GC -->|テーブル登録| GDC
 GDC --> ETL
 ETL -->|品質評価| GDQ
 GDQ -->|スコア書き戻し| GDC
 GDQ -->|閾値超過| CW
 S3 -->|PutObject| EB
 EB -->|Crawler 起動| GC
 ETL -->|OpenLineage イベント| OL
 OL -->|リネージ収集| SMC
 GDC --> SMC

7. 実戦統合パターン

7-1. 組織規模別の選択基準

データガバナンス基盤の複雑度は組織の規模・チーム数・ドメイン数によって大きく異なる。過剰な基盤はコストと運用負荷を押し上げ、不足した基盤はデータの可視性と統制を失う。以下の3段階を参考に、自組織に適した構成を選択する。

7-2. エンドツーエンド統合フロー

アクセス申請から監査までの一連の流れを整理する。SageMaker Catalog（DataZone 基盤）がオーケストレーション層となり、Lake Formation が実際のデータアクセス制御を担う。

ステップ1: データプロデューサーがデータプロダクトを登録

データオーナー（プロデューサー）が SageMaker Catalog にデータプロダクトを登録する。このとき Glue Data Catalog のテーブルメタデータが自動同期される。ビジネス用語辞書（Glossary）とのタグ付け、データ品質スコアの紐付けもここで行う。

ステップ2: データコンシューマーがアクセス申請

データコンシューマー（利用側チーム）がポータルからデータプロダクトを検索し、アクセスを申請する。申請はプロデューサー側プロジェクトの管理者に通知され、承認フローが起動する。

ステップ3: 承認と権限付与

承認が完了すると、SageMaker Catalog がバックエンドで Lake Formation の付与 API を呼び出し、コンシューマー側の実行ロールに対して対象テーブル・列の参照を許可する。手動での設定変更は不要。

ステップ4: データ利用と監査証跡

コンシューマーは Athena・Redshift Spectrum・EMR 等から対象データにアクセスする。CloudTrail と Lake Formation のアクセスログが自動的に記録され、誰がいつどのデータを参照したかが監査証跡として残る。定期的にアクセス設定をレビューし、不要になった権限は申請→失効フローで回収する。

7-3. マルチアカウント統制パターン

本番環境では複数の AWS アカウントにデータが分散することが多い。推奨構成は AWS Organizations を用いた組織管理と Lake Formation のクロスアカウント共有 の組み合わせだ。

中央カタログアカウント（ガバナンスアカウント）で SageMaker Catalog と Lake Formation 管理者を集約し、各ドメインアカウントからリソースリンクを作成して共有する。

• 名前付きリソース方式: 特定のテーブルを外部アカウントの実行プリンシパルへ共有する場合に使用する。設定がシンプルで小規模共有に向く。
• LF-Tags 方式: タグポリシーを一括付与することで、大量テーブルを属性ベースで共有できる。ドメインをまたいだ自動承認フローにも親和性が高い。

マルチリージョン構成の場合、Lake Formation の設定はリージョンごとに独立するため、ガバナンス標準を Organization 単位のサービスコントロールポリシー（SCP）で補完することで整合性を保つ。

7-4. コスト最適化のポイント

SageMaker Catalog（DataZone）は、プロジェクト数・ドメイン数ではなくアクティブユーザー数とデータアセット登録数で課金が発生する。以下の点を意識することでコストを抑制できる。

• 使われていないデータプロダクトの削除: カタログに登録したままアクセスされないデータアセットは定期的に棚卸しを行い、不要なものは削除する。
• Glue Data Catalog との住み分け: 外部公開・クロスチーム共有が不要な内部専用テーブルは Glue Catalog のみで管理し、SageMaker Catalog への登録はビジネス公開が必要なプロダクトに絞る。
• Clean Rooms のコラボレーション単位: Clean Rooms はコラボレーションごとに課金が発生する。不要なコラボレーションは都度アーカイブし、常設化しない。
• Lake Formation 自体は無料: Lake Formation サービス自体に追加料金はなく、実行される Glue・Athena・Redshift 等のサービス料金のみが発生する。設計の複雑化でクエリコストが増えないよう注意する。

8. 詰まりポイント・アンチパターンとまとめ

8-1. 詰まりポイント

実際の本番導入で遭遇しやすい詰まりポイントを8件まとめる。特に Lake Formation とその他サービスの連携に起因するものが多い。これらの多くはドキュメントには記載されていない「現場で初めてわかる」種類の問題だ。

詰まり1: Lake Formation の設定と IAM ポリシーの競合

Lake Formation を有効化したバケットへのアクセスには「IAM での許可 かつ Lake Formation での許可」の両方が成立している必要がある。「IAM 側でフルアクセスを付与したのにクエリが失敗する」という問い合わせの多くは、Lake Formation 側の設定が漏れているケースだ。

確認手順: まず Lake Formation コンソールの「Data Permissions」で対象プリンシパルへのテーブル権限が付与されているかを確認する。次に、実行ロールの信頼関係と Lake Formation の Data Lake 管理者設定も合わせてチェックする。S3 バケット設定を単独で修正しても解決しない点に注意が必要だ。

詰まり2: LF-Tags と Glue ETL ジョブのフルテーブルアクセス問題

列レベルの LF-Tags フィルタを設定すると、Glue ETL ジョブのサービスロールがテーブルへのフルアクセスを失い、ジョブが AccessDeniedException で失敗することがある。ETL ロールには列フィルタを適用せず、Data Catalog の参照権限のみを付与するか、列フィルタなしの別データフィルタを用意して ETL 専用に割り当てるパターンが解決策となる。

列・行フィルタリングは最終的なデータ利用者（Athena クエリ・Redshift Spectrum）に適用するのが原則で、ETL 変換処理中には適用しないよう設計を整理することで、多くの競合を回避できる。

詰まり3: SageMaker Catalog でのドメイン設計の失敗

ドメインを最初から細かく分割しすぎると、アクセス申請・承認の運用が煩雑になり、データコンシューマーがどのドメインに申請すればよいかわからなくなる。逆にドメインを1つにまとめすぎると、プロジェクト内の管理が複雑化し組織変更に弱くなる。

推奨は「事業部またはデータオーナーシップの境界に1ドメイン」を基本単位とし、初期は粗めに切ってデータプロダクト単位で細粒度制御を補う設計だ。ドメインの分割・統合は後から変更コストが高いため、組織構造の安定度を見極めたうえで決定する。

詰まり4: Clean Rooms のデータ形式要件

Clean Rooms では Parquet 形式または ORC 形式のデータを強く推奨する。CSV 形式でもテーブルを作成できるが、大規模データセットではクエリパフォーマンスが大幅に低下し、タイムアウトが発生しやすい。本番導入前に S3 上のデータを Parquet に変換し、適切なパーティション設計（日付・カテゴリキー等）を施してから Clean Rooms テーブルとして登録する。

また、数値型カラムの型不一致（BigInt vs Integer）が原因でコラボレーション参加時に結合が失敗するケースも多い。スキーマ定義を事前に参加メンバー間で揃えておくことが重要だ。

詰まり5: SageMaker Unified Studio（GA 2025）への移行タイミング

2025年の GA 以降、新規プロジェクトは SageMaker Unified Studio を利用できるが、既存の Amazon DataZone（クラシック）で構築したドメイン・プロジェクト・データプロダクトをそのまま移行するパスは執筆時点では自動化されていない。段階的な共存期間を想定し、新規ドメインから順次 Unified Studio へ移行する計画を立てることを推奨する。

DataZone と SageMaker Catalog は基盤として同じサービスを共有しており、Glue Catalog との同期や Lake Formation との連携設定は引き続き有効だ。コンソール UI や API エンドポイントの変更への対応を主な移行作業として位置づけると工数見積もりがしやすい。

詰まり6: クロスアカウント Lake Formation 共有での不足エラー

クロスアカウント共有を行う際、共有元アカウントで Lake Formation の DESCRIBE および SELECT を付与しただけでは不足する場合がある。共有先アカウントでもリソースリンク（Resource Link）を作成し、そのリソースリンクに対して DESCRIBE を付与する手順が必要になる。

また、共有元バケットのリソースベース設定と Lake Formation の登録状態も確認対象だ。「Lake Formation registered」状態のバケットでは、S3 設定だけでなく Lake Formation 経由のアクセス制御が優先されるため、従来の S3 クロスアカウント設定と挙動が異なる点に注意する。

詰まり7: データメッシュのドメイン境界設計の難しさ

データメッシュ構成において「ドメインをどこで分けるか」は技術的な問題ではなく組織・ビジネス上の問題だ。DDD（ドメイン駆動設計）の境界づけられたコンテキストを参考にすることが多いが、エンタープライズの現場では事業部の縦割りがそのままドメイン境界になることも多く、横断的なマスターデータ（顧客・商品・契約等）の所有権が曖昧になりやすい。

共通マスターデータは「共有ドメイン」または「コアドメイン」として別プロジェクトで管理し、他ドメインからは読み取り専用として参照するパターンが管理しやすい。初期設計段階でドメインオーナーを明確に決定し、RACI マトリクスを整備しておくことが後々の摩擦を減らす。

詰まり8: LF-Tags Expression と Glue DataBrew の非互換

LF-Tags の Expression（例: module=sales AND division=(consumer OR commercial)）は Athena・Redshift Spectrum・EMR での評価をサポートしているが、Glue DataBrew はこの Expression を正しく評価できないケースがある（サービスバージョンによって異なる）。DataBrew を使ったデータプレパレーションパイプラインがある場合は、LF-Tags ではなく Named Resource 方式で DataBrew 専用ロールへの付与を個別に行う回避策をとる。

8-2. アンチパターンと正解パターン

実装上よくある誤りとその改善策を5件まとめる。

アンチパターン1: DataZone（SageMaker Catalog）単体で全てを解決しようとする

NG: データカタログ・統制・コラボレーション・品質管理を DataZone 一台で完結しようとし、Lake Formation や Clean Rooms を導入しない。

OK: SageMaker Catalog はカタログ・発見・申請承認のフロントエンドとして使い、データ統制の実行は Lake Formation が担い、外部コラボレーションは Clean Rooms を使う「3層分担」に整理する。各サービスは最も得意な機能に集中させることで、全体の保守性と拡張性が上がる。

アンチパターン2: Lake Formation の統制をカスタムポリシーだけで管理する

NG: Lake Formation を有効化したあとも、テーブルへのアクセス制御をインラインポリシーやカスタマー管理ポリシーで個別管理しようとする。ポリシーの肥大化と誰が何にアクセスできるかの可視性低下を招く。

OK: LF-Tags（LF-TBAC）を使い、データ資産の属性（機密度・データドメイン・事業部）をタグで表現し、タグ式でアクセス制御を一元管理する。タグ体系の設計に時間をかけることで、後から追加されるテーブルにも自動的に設定が適用される。

アンチパターン3: Clean Rooms の分析ルールを緩く設定する

NG: Clean Rooms コラボレーションを迅速に立ち上げるために analysis_rule の aggregation_threshold を低い値（1〜2件）に設定し、実質的に個人データが特定可能な集計結果が出力されてしまう。

OK: 個人再識別リスクを評価し、aggregation_threshold を統計的に意味のある最小値（一般的に5以上）に設定する。差分プライバシー（Differential Privacy）が利用可能であれば積極的に採用し、ノイズ付加による追加保護を実施する。コラボレーション開始前にデータオーナーとコンシューマーの双方でルール設定を文書化しておく。

アンチパターン4: 全てのデータを単一ドメインに集約する

NG: 管理を簡素化するためにすべてのデータを1つの DataZone ドメインに登録する。ドメイン管理者の負担が集中し、チームをまたいだアクセス申請・承認が1つのボトルネックに集中する。

OK: 事業部・データオーナーシップの境界でドメインを分割し、各ドメインに専任の管理者を置く「連合ガバナンス」を採用する。中央チームはドメイン横断の標準（タグ体系・セキュリティ分類・監査設定）を策定し、各ドメインが自律的に運用できる枠組みを提供する。

アンチパターン5: データカタログを IT 部門だけで管理する

NG: データカタログ（ビジネスメタデータ・用語辞書・データプロダクト登録）を IT 部門または中央データチームだけが管理する。ビジネス文脈のメタデータが陳腐化し、データコンシューマーがカタログで正確な情報を得られなくなる。

OK: データプロデューサー（データを生成・所有するビジネス部門）がデータプロダクトの登録・説明文・品質スコアの維持に責任を持つ仕組みを制度として整備する。SageMaker Catalog のプロジェクト・オーナーシップ機能を活用し、技術管理（スキーマ・構成）は IT 部門、ビジネス管理（説明・用語・品質定義）はデータオーナーが担う役割分担を明確化する。

8-3. まとめと移行ロードマップ

AWSデータガバナンス3層の整理

本記事で扱った3サービスの役割を最後に整理する。

• SageMaker Catalog（Amazon DataZone 基盤）: データ資産のカタログ化・発見・アクセス申請・承認ワークフロー・ビジネスメタデータ管理を担う「ガバナンスのフロントエンド」。
• AWS Lake Formation: S3 上のデータレイクに対して列・行・セルレベルの細粒度制御と LF-Tags による属性ベース管理を提供する「統制エンジン」。SageMaker Catalog と連携することで申請→承認→設定付与が自動化される。
• AWS Clean Rooms: 複数当事者が生データを相手に渡さずにセキュアな共同分析を実施できる「コラボレーション基盤」。差分プライバシーと分析ルールで最小限のデータ露出で最大のインサイトを引き出す。

DataZone → SageMaker Catalog 移行フェーズ別ロードマップ

データ「処理」と「統治」の分離という設計原則

本シリーズを通じて一貫して強調するのは「データを処理する基盤（Athena / Redshift / Glue ETL / EMR）」と「データ資産を統治するガバナンス層（SageMaker Catalog / Lake Formation / Clean Rooms）」を設計上分離するという原則だ。

この2層を混同すると、分析パイプラインの改修がガバナンス設定に影響し、ガバナンス設定の変更が ETL ジョブを破壊するという依存関係が生まれる。ガバナンス層は変更頻度が低い安定した標準（タグ体系・セキュリティ分類・監査要件）を定義し、処理層はその標準の枠内で自由に最適化できる構造にすることで、組織の成長に耐えるデータ基盤が実現する。

次のステップ

本記事で整理したサービスの基礎知識をもとに、次のステップへ進む読者に向けて関連コンテンツを案内する。本番 CloudTrail 監査とアクセスレポートの活用法、データ品質の継続的モニタリング設計、大規模データメッシュにおける SCP との連携パターンは、今後のシリーズ記事で詳述する予定だ。

8-4. 継続運用と監視のポイント

データガバナンス基盤は「導入して終わり」ではない。初期設定が完成した後も、アクセス設定の陳腐化・コスト増加・セキュリティリスクの蓄積を防ぐための継続的な運用が必要だ。

定期レビューのサイクルとして推奨するのは「月次コスト確認」「四半期アクセス棚卸し」「半期ドメイン再評価」の3層だ。月次では SageMaker Catalog のアクティブユーザー数と課金データを確認し、予算超過の兆候を早期に検出する。四半期では各データプロダクトへのアクセス実績を確認し、不要になった権限付与を回収する。半期では組織変更に伴うドメイン構成の見直しと LF-Tags 体系の更新を行う。

CloudWatch と CloudTrail を組み合わせたモニタリングにより、異常なアクセスパターン（深夜の大量クエリ・普段アクセスしないテーブルへの突発的な参照等）をアラートで検知する仕組みを構築しておく。Lake Formation の拒否ログ（Unauthorized）を定期的に確認することで、設定漏れや不正アクセス試行の早期発見にもつながる。

8-5. 本番導入チェックリスト

SageMaker Catalog・Lake Formation・Clean Rooms を本番環境に導入する前に確認すべき項目をまとめる。詰まりポイントとアンチパターンを踏まえた実践的なリストだ。

Lake Formation 基盤チェック

• S3 バケットが Lake Formation に登録（”Registered”）されていることを確認した
• Data Lake 管理者に中央ガバナンスアカウントの実行ロールを設定した
• LF-Tags の体系（機密度・ドメイン・事業部等）を設計・文書化した
• ETL ジョブ用ロールには列フィルタを適用せず、参照権限のみを付与した
• クロスアカウント共有先でリソースリンクを作成し、DESCRIBE を付与した
• CloudTrail でのアクセスログ記録が有効になっていることを確認した

SageMaker Catalog（DataZone）チェック

• ドメインの分割単位を組織構造と照合し、RACI マトリクスを整備した
• データプロデューサーとデータコンシューマーの役割を各チームに周知した
• Glue Data Catalog との同期設定が正常に動作していることをテスト環境で確認した
• ビジネス用語辞書（Glossary）の初期設定とオーナーを決定した
• アクセス申請→承認→付与フローをテスト環境で動作検証した

Clean Rooms チェック

• コラボレーション参加前に全メンバーのデータを Parquet 形式に変換した
• スキーマの型定義（特に数値型）を参加メンバー間で合わせた
• analysis_rule の aggregation_threshold を5以上に設定した
• 差分プライバシーの適用要否をデータオーナーと合意した
• コラボレーションの目的・期間・参加メンバーを文書化した

コスト管理チェック

• SageMaker Catalog のアクティブユーザー数とアセット登録数を月次でレビューする運用を設定した
• 不要な Clean Rooms コラボレーションのアーカイブ手順を定めた
• 内部専用テーブルは Glue Catalog のみに留め、SageMaker Catalog 登録から除外した
• Lake Formation の設計複雑化による Athena クエリコスト増を事前に試算した

セキュリティ・コンプライアンスチェック

• データ分類（公開・内部・機密・極秘）と LF-Tags のマッピングを定義した
• 定期的なアクセス設定レビュー（四半期推奨）のスケジュールを設定した
• Clean Rooms での個人データ取扱いについて法務・コンプライアンス部門の確認を得た
• 監査証跡（CloudTrail・Lake Formation ログ）の保持期間と閲覧権限を設定した