Treasure Dataで始めるデータガバナンス-見落としがちなポリシー設計を解説-（Vol.012）

  • 公開日：

組織におけるデータ活用では情報漏洩や誤ったデータに基づく意思決定は致命的であるため、有効なデータガバナンスの整備が欠かせません。特にTreasure Dataのように多数のデータを統合するCDPでは、将来的な組織・ルールの改編にも対応できるように柔軟な設計でデータガバナンス要件を実現する必要があります。
そこで本ブログでは、Treasure Data導入時に意識すべきデータガバナンスと、それを支える機能・設計を解説します。

データガバナンスの重要性

データガバナンスとは何か？

まずは本記事におけるデータガバナンスの定義と、その目的を整理します。

  • データガバナンスの定義
    組織全体でデータを「どう扱うか」を決めるための方針・ルール・責任の枠組み。
  • 目的
    データの品質、セキュリティ、コンプライアンスを確保し、リスクを管理する。
  • 特徴
     ・ポリシー策定（例：データ利用ルール、アクセス権限）
     ・権限と責任の明確化（誰が何を決めるか）
     ・法令遵守（GDPRなど）
  • 例
    ・ 顧客データは暗号化して保存する
     ・データ品質基準を満たさないデータは利用禁止

データマネジメントとは？データガバナンスとの違い

似た概念としてデータマネジメントが挙げられますが、本記事では以下のように定義し、データガバナンスとは区別して扱います。

  • データマネジメントの定義
    データを実際に管理・運用するためのプロセスや技術。
  • 目的
    データを効率的に収集、保存、加工、配布し、ビジネスで活用できる状態にする。
  • 特徴
    ・DBの管理運用
    ・ETL（抽出・変換・ロード）
    ・データ品質管理（重複排除、欠損補完）
    ・メタデータ管理
  • 例
    ・データウェアハウスに顧客データを統合
    ・ETLツールでデータをクレンジング
    これらを踏まえ、本記事においては違いを1言で以下と定義します。
    ・ガバナンス = 「ルールを決める」
    ・マネジメント = 「ルールに従って運用する」

なぜ今、企業にとってデータガバナンスが重要なのか？

データは資産であると同時にリスクも内在しているため、ルール・仕組みによる統制が不可欠となります。
内在するリスクは様々ですが主に以下3点が考えられます。

  1. 法令・規制への抵触
    個人情報保護法やGDPRなど、データに関する規制が強化されており、違反すると巨額の罰金や信用失墜へとつながります。
  2. データの信頼性低下
    AIや分析の精度はデータ品質に依存します。品質の低いデータの活用は誤ったビジネス判断へつながります。
  3. セキュリティリスク
    データの取り扱いルールが曖昧な場合、サイバー攻撃や情報漏えいのリスクが高まります。

Treasure Dataにおけるデータガバナンスの実現

データガバナンスは、システムをまたいだデータ品質の担保のための仕組みや、運用フローの策定など、さまざまな取り組みを含みます。
その中でも本章では、Treasure Data単体で実現可能なうち、設計が関わるポリシー策定に焦点を当てて解説します。
さて、そのうえでTreasure Dataにおけるポリシーとはアクセス権限管理になります。
Treasure Dataでは、Policy Based Permission（PBP）という権限セットを作成し、各ユーザーに割り当てる方式でアクセス権限を制御しています。
また、Column Level Access Control（CLAC）という、テーブル項目にタグを設定することで、より詳細なアクセス制御を可能にする機能も標準で提供されています。

  • Policy Based Permission(PBP)
    アクセス制御ができる機能は以下となります。
    ・Authentications：データ連携に関する設定に関する機能
    ・Database：データを格納しているテーブルの集合
    ・Workflow：Treasure Data上に構築したバッチ処理
    ・Audience Studio：分析やMAを実行するための機能
    ・AIエージェント・ファウンドリー：AIエージェントを構築する機能
    ・Engage Studio：メール送信を実行する機能
  • Column Level Access Control(CLAC)
    テーブルに保持している項目に対して以下の粒度でアクセス権限を設定可能です。
    ・None (default)：ユーザーはカラムの値を参照できず、クエリ実⾏不可
    ・View：ユーザーはカラムの値を参照でき、クエリ実⾏可
    ・Masked：ユーザーはクエリ実⾏可能だが、結果はハッシュ化された値で出力される

Treasure Dataでは、これらの機能を利用してデータガバナンスの1つの柱である、データへのアクセス権限管理を実現できます。

Treasure Dataのポリシー運用におけるよくある課題

非常に便利な権限管理機能を提供しているTreasure Dataですが、PBPを事前に設計しないまま運用を開始すると、ガバナンス上のトラブルにつながるケースがあります。
今回は発生しがちな運用上の問題を紹介します。

  • Case1.管理者に近い権限をもつユーザーが増えすぎる

    ユーザーから「使えない機能がある」などの声が上がり、発行時に管理者権限(もしくは近いポリシー)を安易に付与してしまうといった運用をしてしまうケースです。
    機能制限が無いためユーザー側の不満は解消されますが閲覧させてはいけないデータへのアクセスや、開発知識のない業務運用者が誤って処理を起動させてしまうといった事故につながります。

  • Case2.月日と共にポリシーが複雑になりすぎる

    運用開始したポリシーに対して都度必要な権限を追加する形で運用していた結果、追加開発や担当の変更などで冗長な権限が乱立するケースです。
    また、既存のポリシーへの改修は付与しているユーザー全員分の権限への影響があるため可能な限り避けるべき運用となります。
    この場合、権限管理が複雑化することで不要な権限をユーザーに付与してしまうリスクが高まります。

  • Case3.組織変更に耐えきれない

    各ユーザーに付与しているポリシーの組み換えが可能な設計になっていない状態で、大きな組織変更・人事異動があると運用・ポリシーが耐え切れなくなってしまうというケースです。
    この場合はポリシーはほぼ作り直しになってしまう可能性があり、予期しない運用者の稼働が発生してしまいます。

Treasure Dataで実現するデータガバナンス～ポリシー設計のあるべき姿と実現方法～

前述したトラブルの原因としては、ポリシーを要望に合わせて都度更新して運用していることや、そもそもDBやWorkflowが適切に分割されていないことなど、設計上の問題が考えられます。
こういったケースを防ぐためにも必要のない権限は付与せず最小限の権限を与える方針とすることが推奨されます。
では、実際にTreasure Dataのポリシー設計で重要なポイントを3点ご紹介します。

  1. Policy Based Permissionを意識した全体設計

    ※上図補足：運用チーム以外は同色のDB・workflow・MasterSegmentが参照可能な権限を与える
    前項で説明した通りPBPではAuthentications / Database / Workflow / Audience Studio(≒MasterSegment) / AIエージェント・ファウンドリー(プロジェクト) / Engage Studio(ワークスペース)の単位で権限を与える仕様となっています。
    そのため初期構築時点で各チームの担当者に与える権限の範囲を決め、その通りにポリシーが設定できるように実装も区切る必要があります。
    上図は1例ですがデータ取込・加工・統合までは全体を統括する保守運用・開発エンジニアが管理し、各チームの活用する領域は個別に作成することでPBPによるガバナンスが実現しやすくなります。
  2. 役割×環境でポリシーを区切り、必要な権限はポリシーを組み合わせて実現する
    前章のよくある課題Case2で解説したように、既存のポリシーへの更新は付与している全ユーザーの権限を変更する操作になるため極力避けたい運用となります。
    そのため、ポリシーを作成する際にはTreasure Dataで発生する役割を定義し、最小限の権限セットを1つのポリシーとすることで更新頻度を最小限に留めることが可能です。
    またTreasure Dataでは、1ライセンスにつき1つの環境（アカウント）が払い出されます。そのため、開発（dev）、検証（stg）、本番（prod）といったフェーズ別の実装を1つの環境（アカウント）内で開発することが一般的です。
    このため、環境単位でもポリシーを分けておかないと、「検証環境だと思って本番環境を更新してしまった…」といったヒューマンエラーにつながる危険性があります。
    これらを踏まえ、役割×環境の単位でポリシーを区切ることでその後の運用が簡素化できると考えられます。
    図1：ポリシーの分割例
  3. 持続可能な運用フローを整備する
    最後に重要なポイントとなるのが運用フローです。どんな設計をしても持続可能な運用フローが無ければ、いつか当初の思想とは異なるものに変容していきます。
    以下は極端な例ですが、あまり推奨できない運用フローの例となります。

    さて、どこが問題でしょうか？ここでは以下の問題点が考えられます。
    ① チャット連絡のため依頼管理が運用担当に依存するため依頼の未実施などヒューマンエラーを誘発
    ② 各部門のメンバーが直接運用担当へ連絡を取ってしまって個人単位の依頼がきてしまうためTreasure Data利用者が数百人規模になった場合に対応しきれない
    ③ いつまでに依頼を行えば対応が完了するかが不明瞭であるため業務遂行時の障害/ユーザー側の不満につながる

    これらの問題点を解消するために、1つの例として以下の運用フローが考えられます。

    各部門の代表の担当者がまとめて課題管理ツール経由で依頼することで運用担当者は抜け漏れなく対応を行うことが容易になります。また、申請や対応完了などのマイルストーンを定義することでいつまでに申請を行えばよいかが現場でも逆算ができるようになります。

    また、ガバナンス維持のために以下のような定期メンテナンスを行うことを推奨します。
    ・ 不要ユーザーのチェック：退社した方や契約切れのパートナーなどのユーザーが残っていないか
    ・ ポリシーの妥当性チェック：ユーザー管理ドキュメントと設定内容が一致しているか、役割に対して権限が強すぎるユーザーはいないかを確認
    ・ 保守運用妥当性チェック：定型的な運用フローが遅延し始めていないかを確認

まとめ

ここまで、Treasure Dataにおけるデータガバナンスについて解説してまいりました。
最初に「データガバナンスとは？」「なぜ重要なのか？」を説明し、次に「Treasure Dataにおけるデータガバナンス」「ポリシー設計のよくある課題」「ポリシー設計時のポイント」を解説しました。
Treasure DataのPBPは柔軟かつ便利な機能となっていますので、うまく活用すればデータガバナンス実現の強力な柱となるかと思います。

まだまだ解説しきれていないポリシーに関する内容もありますが、多種多様なデータを活用していくためのデータプラットフォーム製品の選定にあたり、皆さまの検討の一助になりましたら幸いです。

Treasure Dataを導入した場合、利用部門を拡大していくにつれてデータガバナンスの課題は尽きません。また拡大すればするほどポリシー含め改修は大掛かりなものになるため、最初の設計が肝心だと言えます。お悩みの方はお気軽にご相談いただければと思います。

電通総研では、CDP・顧客データ活用のプロフェッショナルとして「これからの顧客体験を発想して創る」ためのご支援をしております。CDPの豊富な実績・ノウハウを体系化したサービスをご提供しておりますので、お悩みの際は、是非、電通総研までお声がけください。

◆ お問い合わせページ：https://data-management.dentsusoken.com/treasure-data/inquiry/

＊本記事は、2025年12月1日時点の情報を基に作成しています。
　製品・サービスに関する詳細は電通総研のWebサイトからお問い合わせください。

＜筆者＞
氏名：及川 賢（おいかわ けん）
経歴：
2016年、株式会社電通総研入社後、
デジタルマーケティング領域のソリューションアーキテクトとして複数の案件に参画し、
Treasure Dataを中心としたマーケティングプラットフォーム開発、コンサルティングに従事。

関連記事