定義・導入メリットから実装戦略までを役立つ形で解説 第1章：データガバナンスとは？ 1-1. データガバナンスの定義 データガバナンスとは、「誰が、どのようなデータを、どのような状況で、どのような方法で利用できるか」を組織的に定義・統制するためのルール、プロセス、そしてそれらを支えるテクノロジーの包括的な枠組みです。 単にデータを「保管」することではなく、企業全体でデータを「資産」として捉え、その価値を最大化するための戦略的な取り組みです。データの品質、セキュリティ、アクセス権限、コンプライアンスなど、多岐にわたる要素を一元的に管理することが求められます。 具体的には、データガバナンスは以下のような問いに答えるための仕組みです。 データの所在と内容： 自社にどのようなデータが存在し、どこに保管されているのか？ 権限と責任： そのデータに対して誰がアクセスでき、誰が品質に責任を持つのか？ 品質の担保： そのデータは正確で、完全で、最新の状態に保たれているか？信頼して意思決定に使えるか？ 利用ルール： どのような目的で、どのような条件のもとで利用が許可されるのか？ ライフサイクル： データはいつ作成され、どう加工され、いつ廃棄されるのか？ これらの問いに対して、場当たり的な対応ではなく、組織として一貫した方針と仕組みを持つこと——それがデータガバナンスの本質です。 1-2. データガバナンスの対象範囲 データガバナンスが対象とする「データ」は、基幹システム内の構造化データだけではありません。現代の企業が扱うデータは、以下のように多様化しています。 構造化データ： データベースやスプレッドシートに格納された、行と列で整理されたデータ（売上、顧客情報、在庫数など） 半構造化データ： JSON、XML、ログデータなど、一定の構造はあるが固定スキーマに収まらないデータ 非構造化データ： テキスト文書、画像、音声、動画、メールなど、フォーマットが定まっていないデータ 特に生成AIの普及により、非構造化データの活用ニーズが急速に拡大しています。これらすべてのデータを横断的に統制できるガバナンスの枠組みが、今日の企業には求められています。 1-3. データマネジメントとの違い データガバナンスと混同されやすいのが「データマネジメント」です。両者は密接に関連しますが、役割が明確に異なります。 観点 データガバナンス データマネジメント 役割 戦略・統制（What / Who） 実行・運用（How） たとえ 交通ルールを策定する 実際に車を安全に運転する 主な問い 何をすべきか？誰が責任を持つか？ どう実行するか？どう維持するか？ 主な担い手 経営層、データオーナー、ガバナンス委員会 データエンジニア、DBA、運用チーム 成果物 ポリシー、基準、役割定義 データベース、ETLパイプライン、バックアップ ガバナンスなきマネジメントは「地図なき航海」 に等しく、いくら技術力があっても組織として正しい方向に進めません。逆に、 マネジメントなきガバナンスは「絵に描いた餅」 であり、立派なルールがあっても実行されなければ意味がありません。 つまり、ガバナンスは「何を、誰が、なぜやるか」を決め、マネジメントは「それをどう実行するか」を担います。両者は車の両輪として機能すべきものであり、どちらか一方だけでは成果は生まれません。 1-4. データガバナンス導入のメリットと、不在時のリスク データガバナンスは「あると便利」なものではなく、不在の場合に深刻な問題を引き起こすものです。導入によるメリットと、ガバナンスが欠如した場合に起こる典型的な問題を対比して整理します。 データ品質の向上： 組織全体でデータの定義やルールを統一することで、信頼できるデータに基づく意思決定が可能になります。ガバナンスがなければ、部署ごとにKPIの定義が異なり、経営会議で「どの数字が正しいのか」が議論の的になる——こうした日常的な混乱が生まれます。 意思決定の迅速化： データへのアクセスルールが明確に定義されていれば、適切な権限を持つユーザーはセルフサービスでデータを活用できます。一方、ガバナンスがなければ、セキュリティ懸念からIT部門がすべてのデータ提供を手動で管理せざるを得ず、「依頼待ち」のボトルネックが常態化します。 dotDataがお客様とAI・データ活用プロジェクトを実施する中で、もっとも時間・工数・手戻りが大きいのが「仕様通りのデータにプロジェクトメンバーがアクセスできるようになること」です。しっかりとしたガバナンスが整備されているお客様と、そうでない場合とでは、データ準備の不備による期間・工数の圧迫に明確な差が表れており、プロジェクトの期間短縮と成果の品質に直結しています。 セキュリティ・コンプライアンスの強化： 「誰がいつ何のデータにアクセスしたか」を追跡可能にすることで、規制対応と監査の負荷を大幅に軽減します。ガバナンスが不在のままでは、アクセス権限の管理が属人化し、情報漏洩や法規制違反のリスクが高まり続けます。 AI活用の加速： AIモデルの精度は投入されるデータの品質に直結します。「Garbage In, Garbage Out」の格言どおり、データの品質や来歴が不明な状態ではAIプロジェクトは頓挫しやすく、ガバナンスの整備がAI開発の生産性を左右します。 コスト最適化： ガバナンスによりデータの信頼性が担保されることで、重複管理や誤った意思決定の手戻りといった「隠れたコスト」を削減できます。逆に、各部署が独自にデータを管理するサイロ化の状態では、同じデータの重複コピーが乱立し、ストレージコストと運用負荷が膨張します。 これらの問題は、小さな組織では見過ごされがちですが、データ量やAI活用が拡大するにつれて指数関数的にリスクが増大します。だからこそ、早期にガバナンスの枠組みを構築することが重要なのです。 第2章：なぜ今、データガバナンスが再注目されているのか？ データガバナンスが今再注目されている理由は、AI/MLの急速な普及、「守り」から「攻め」へのパラダイムシフト、グローバルな規制強化、そしてデータのサイロ化という4つの構造的変化にあります。データガバナンスという概念自体は新しいものではありませんが、2020年代に入り、その重要性はかつてないほど高まっています。 2-1. AI/ML活用の急速な進展とデータ爆発 生成AIや機械学習の急速な普及により、企業が扱うデータの量・種類・複雑性は爆発的に増大しています。構造化データだけでなく、テキスト、画像、音声といった非構造化データもAIの入力となる現在、従来の管理手法では対応しきれない状況が生まれています。さらに、AIエージェントが自律的にデータを参照・処理する時代に入りつつある今、「どのデータにどのAIがアクセスしてよいか」という新しい次元の統制も必要になっています。 一方で、AIモデルの学習には大量の高品質データが不可欠です。「データの量は十分だが、品質がAIに使えるレベルに達していない」——これは多くのAIプロジェクトが直面する共通課題です。AIの精度を高めるためには、データの正確性、完全性、一貫性、鮮度を組織的に保証するガバナンスの仕組みが欠かせません。 2-2. 「守り」から「攻め」へのパラダイムシフト かつてのデータガバナンスは、セキュリティやコンプライアンスといった「守り」の側面が主でした。しかし現在、データをビジネス価値に直結させる「攻め」のガバナンスが求められています。ガバナンスの目的が「データを制限する」ことから「データを安全かつ迅速に活用する」ことへとシフトしているのです。 この変化を象徴するのが、「ガードレール」という考え方です。従来の「関所型」ガバナンス（＝IT部門に申請して許可を得ないとアクセスできない）から、「ガードレール型」ガバナンス（＝ルールの範囲内で自由に活用できる）への移行——高速道路のガードレールが安全に高速で走行するための仕組みであるように、現代のデータガバナンスも現場の活用を加速させるための仕組みであるべきです。 2-3. 規制強化とグローバル化 GDPR（EU一般データ保護規則）、日本の改正個人情報保護法、米国のCCPA/CPRA、中国のPIPLなど、世界各地でデータプライバシーに関する規制が強化されています。これらの規制は、データの取り扱いに対する組織的な説明責任（アカウンタビリティ）を厳しく求めています。 特にグローバルに事業を展開する企業にとっては、各国・地域の異なる規制に同時に準拠する必要があり、統一されたガバナンスフレームワークなしには対応が困難です。違反時の制裁金も高額化しており（GDPRでは年間売上高の最大4%）、ガバナンスはもはや「あればよい」ではなく「なくてはならない」ものとなっています。 2-4. データのサイロ化と「野良データ」問題の深刻化 2010年代のセルフサービスBI・データ分析ブームは、現場のデータ活用を加速させた一方で、新たな問題も生みました。各部署が独自のデータマートやスプレッドシートを作成し、定義の異なるデータが組織内に乱立する「スプレッドマート（野良マート）」問題です。過去の担当者が構築したデータパイプラインが、退職後もブラックボックスとして動き続けるケースも増えています。 こうした「野良データ」や「ブラックボックス化したパイプライン」は、データの信頼性を蝕み、全社的な意思決定の質を低下させます。この反省から、単なる「自由なデータ活用」ではなく、「統制された自由」——すなわち、ガバナンスの枠組みの中でセルフサービスを実現するアプローチが求められるようになりました。 2-5. データ管理の歴史的変遷から見る必然性 こうした背景を俯瞰すると、データ管理のアプローチは大きく3つの世代を経て進化してきたことがわかります。 世代 時代 主なアプローチ 強み 課題 第1世代 〜2000年代 中央集権型MDM（IT部門主導） データの正確性・一貫性 変化への対応が遅い、「箱物化」のリスク 第2世代 2010年代〜 セルフサービス型（現場主導） 分析のスピード・機動力 サイロ化、野良データの乱立、ガバナンス不在 第3世代 2020年代〜 統合データガバナンス（IT＋現場の協調） 信頼性とスピードの両立 実装の技術的複雑性、組織文化の変革が必要 第1世代の「堅牢だが遅い」管理と、第2世代の「速いが統制が効かない」活用。この両者の長所を融合し、AI時代に対応する「第3世代」のアプローチが、まさに今求められている統合データガバナンスです。この詳細については、第5章で改めて掘り下げます。 第3章：データガバナンスを支える「3つの柱」 データガバナンスを実効性あるものにするには、「人」「プロセス」「テクノロジー」の3つの要素が不可欠です。どれか一つが欠けても、ガバナンスは「絵に描いた餅」に終わります。よくある失敗パターンは、テクノロジー導入だけに注力し、それを運用する人や業務プロセスの設計が後回しになるケースです。3つの柱をバランスよく整えることが、持続可能なガバナンスの鍵となります。 3-1. 人（組織・役割・文化） データガバナンスの成否を分ける最大の要因は、実はテクノロジーではなく「人」です。まず経営レベルでは、CDO（Chief Data Officer）のようなデータ戦略を統括するリーダーが、ガバナンスの全社推進を牽引する役割を担います。その下で、データの品質や定義に責任を持つ「データオーナー」、日常的に品質を監視・維持する「データスチュワード」、物理的な基盤を管理する「データカストディアン」といった役割を明確に定義することが重要です。 現場レベルでは、ガバナンスを「自分ごと」として根付かせる文化の醸成が不可欠です。特に、ビジネス部門・データアナリスト・データエンジニアの三者が連携する「三位一体モデル」は、ビジネスの知見・分析の専門性・技術基盤を結びつける実践的なフレームワークとして注目されています。 dotDataは多数の企業に ビジネスアナリティクス人材育成プログラム を提供していますが、その中で強く実感しているのは、ガバナンスとデータ活用を大きく推進するためには「データを分析する人材」以上に、分析結果からビジネスの価値を引き出す「理解者・活用者」の層を厚くすることが重要だという点です。こうした活用者層が増えることで、ガバナンス（守り）と活用（攻め）の好循環が加速します。 関連記事： CDOが知るべき成功する組織モデル（データドリブン組織の設計図 第2回） ガバナンスを推進するための経営レベルのリーダーシップと組織構造について解説しています。 関連記事： DX人材育成は「分析スキル」だけでは失敗する？（データドリブン組織の設計図 第3回） 現場でガバナンスを機能させるための「三位一体モデル」について詳しく解説しています。 3-2. プロセス（ルール・ワークフロー） データの収集・加工・共有・廃棄に至るライフサイクル全体をカバーする明確なプロセスを定義します。具体的には、データ品質の基準（どの項目がどの精度であるべきか）、アクセス申請と承認のフロー、新規データソース追加時のレビュー手順、問題発生時のエスカレーションルートなどが含まれます。 プロセス設計で最も重要なのは、「属人化しないこと」と「現場が無理なく従えること」の両立です。過度に厳格なプロセスは現場に無視され、形骸化の原因になります。一方、ルールが曖昧すぎると再びサイロ化や野良データの温床になります。現場の業務フローに自然に組み込まれる「ちょうどよい厳格さ」を見極めることが、プロセス設計の腕の見せどころです。 3-3. テクノロジー（ツール・基盤） 人とプロセスを支える土台が、テクノロジー基盤です。代表的な要素としては、データの所在と内容を一覧化する「データカタログ」、誰が何にアクセスできるかを制御する「アクセス制御」、データの加工経路を可視化する「データリネージ」などがあります。これらのツールにより、ガバナンスポリシーを自動的に適用・監視でき、人的リソースだけでは不可能なスケールでの統制が実現します。 テクノロジー選定にあたっては、個別のツールを積み上げるのではなく、プラットフォーム全体でガバナンス機能が統合されているかを重視すべきです。ツールごとにガバナンスが分断されると、管理の複雑性が増し、かえって統制が効かなくなるためです。この点については、第5章（統合データガバナンスとその実装）で詳しく掘り下げます。 第4章：ガバナンスの土台を築く ガバナンスを機能させるための土台は、データ基盤の整備、パイプラインとリネージの管理、データ品質の段階的向上、そしてセキュリティの確保の4つです。データが各システムに散在した「サイロ化」の状態では、どれほど立派なガバナンスポリシーも適用できません。まずこれらの土台を整備することが、ガバナンスの実効性を高める第一歩となります。 4-1. データ基盤の整備 データ活用のための基盤とは、単なるストレージではなく、データの収集・蓄積・加工・提供の一連のプロセスを支えるアーキテクチャ全体を指します。近年では、大量の非構造化データを低コストで保管できるデータレイクの柔軟性と、高速な分析クエリを可能にするデータウェアハウスの性能を融合した「レイクハウス」アーキテクチャが主流となっています。 データ基盤の構築において陥りがちな失敗は、「まず箱を作り、データを集めてから活用を考える」というアプローチです。基盤構築とユースケースの設計を並行して進める「アジャイルデータモデリング」の考え方を取り入れることで、投資対効果を早期に実感しながら基盤を成長させることが可能になります。 関連記事： データ活用のためのデータ基盤とは？構築プラクティスとアジャイルデータモデリング データ基盤の構築プラクティスとアジャイルデータモデリングの考え方を解説しています。 4-2. データパイプラインとリネージ管理 データがソースから最終的なレポートやAIモデルに至るまでの「移動・加工の経路」を統制することも、ガバナンスの重要な構成要素です。現実の企業では、散在する複数のデータソースから複雑なETL/ELT処理を経てデータが加工されています。この過程が手作業やアドホックな対応に依存していると、品質の劣化やロジックの不整合が紛れ込むだけでなく、属人化による「ブラックボックス化」のリスクも高まります。データパイプラインを構築してこの一連の処理を自動化することが、ガバナンスの実効性を支える基盤となります。 さらに、パイプラインの統制と合わせて重要なのが「データリネージ（来歴管理）」です。データの「家系図」を自動生成し、ソースから最終成果物までの全経路を可視化することで、上流の変更が下流のどの分析に影響するかを事前に把握（インパクト分析）できるようになります。問題が起きてから原因を追う「事後対応」から、影響を予測して備える「事前統制」への転換が実現します。 関連記事： データ活用とデータガバナンスに貢献するデータパイプライン データパイプラインの基本機能（収集・加工・統合・配信）と、データ品質およびガバナンスとの関係について詳しく解説しています。 4-3. データ品質の段階的向上：メダリオンアーキテクチャ 「データの品質を高めなければAIに使えない。しかし、品質を完璧にしてからでは永遠にAI活用が始まらない」——多くの企業が抱えるこのジレンマに対する現実的な解がメダリオンアーキテクチャです。ブロンズ（生データをそのまま蓄積）→ シルバー（クレンジング・標準化済み）→ ゴールド（特定の分析・AIユースケースに最適化）と、3つのレイヤーで段階的に品質を向上させます。 このアプローチの利点は、すべてのデータを一度に完璧にする必要がないことです。まず生データをブロンズに取り込み、優先度の高いユースケースからシルバー・ゴールドへと昇格させていくことで、ガバナンスとデータ活用を並行して進められます。特にゴールドレイヤーの構築においては、AIモデル向けの「特徴量エンジニアリング」が品質とビジネス価値を大きく左右します。 ある欧州の大手企業では、膨大な数の変数を「Big Feature Store」として手作業で管理していましたが、管理の肥大化と陳腐化が進み、新たなビジネスインサイトを届けられない状態に陥っていました。同社ではdotData Feature Factoryを導入し、シルバーからゴールドへのデータ加工（特徴量の作成）の大部分を自動化。結果としてBig Feature Storeを廃止し、管理コストの削減、最新インサイトの迅速な提供、分析サイクルの大幅な高速化を実現しています。 関連記事： Databricks DeltaとUnity Catalogを超えて：dotDataのFeature Factoryによるメダリオンアーキテクチャの革新 メダリオンアーキテクチャの各レイヤーと、特徴量エンジニアリングによるゴールドレイヤーの革新について解説しています。 4-4. AI時代のセキュリティとリスク管理 データを「攻め」に活用するためには、同時に堅固な「守り」も不可欠です。特に生成AIやLLM（大規模言語モデル）の活用が広がる中、AIモデルの学習データやプロンプトを通じた情報漏洩リスク、モデル自体のバージョン管理やバイアス検出といった、従来のデータ管理にはなかった新しいセキュリティ要件が浮上しています。 ここで難しいのが「攻めと守りのバランス」です。過度なセキュリティはイノベーションを阻害し、緩すぎればリスクが高まります。ガバナンスの土台として、データのアクセス制御やマスキングといった基本的な保護を確実に整備しつつ、現場のAI活用を萎縮させない設計が求められます。 関連記事： 生成AIセキュリティの最前線：LLM活用で考える「攻め」と「守り」のバランス 生成AI・LLM時代におけるセキュリティの最新要件と、攻めと守りのバランスについて詳しく解説しています。 第5章：統合データガバナンスとその実装 統合データガバナンスとは、中央でのポリシー管理と現場での分散活用を高度に両立させるアプローチであり、その実現にはクラウドデータプラットフォームのネイティブ機能の活用が不可欠です。多くの企業が直面する現実は、各ツールやシステムごとにガバナンスが「サイロ化」しているという問題であり、この課題を打破するのが統合データガバナンスの考え方です。 5-1. 従来のガバナンスの限界 ツールごとに異なるガバナンスポリシーが存在し、それらが連携していない状態では、組織全体での一貫したデータ統制は不可能です。たとえば、BIツールではアクセス制御が効いているのに、データレイクでは同じデータが無制限に参照できる——こうした「ガバナンスの穴」は、ツールが増えるほど広がります。 また、ガバナンスが「制限」として機能してしまうと、現場のイノベーションを阻害し、AI活用のボトルネックになりかねません。必要なのは、ツールやシステムを横断して一貫したポリシーを適用しつつ、現場の活用を妨げない仕組みです。 5-2. 「統合データガバナンス」という解 統合データガバナンスは、第2章で触れた第1世代（中央集権型MDM）の「信頼性」と、第2世代（セルフサービス型）の「機動力」を技術的に融合する第3世代のアプローチです。全社共通のガバナンスポリシーを一元管理しつつ、データの加工や分析の権限を現場に開放することで、AI時代に不可欠な「確実かつ迅速な意思決定」を組織全体で実現します。 その核心となる要素——データカタログ、Policy as Codeによるアクセス制御、データリネージ、セマンティックレイヤー、Zero-Copy、オープンテーブルフォーマット——これらを統合的に実装することが、AIが即座にビジネス価値を創出するための「AI Ready Data」への道筋を開きます。 関連記事： AI時代のデータ活用の鍵を握る「統合データガバナンス」とは？ 統合データガバナンスの6つのコア要素と、クラウドデータプラットフォームを活用した実装戦略について深く掘り下げます。 5-3. 実装例：Databricksのレイクハウス思想とUnity Catalog 統合データガバナンスの考え方を具体的にシステムへ落とし込んでいる代表的なプラットフォームの一つがDatabricksです。Databricksは、データレイクとデータウェアハウスを統合した「レイクハウス」アーキテクチャを提唱しており、その中核となるUnity Catalogは、SQL分析からPython、機械学習モデルまでを共通のガバナンス下に置くことができます。オープンフォーマット（Delta Lake）をベースとした高い透明性と拡張性が特徴です。 関連記事： Databricks AI + Data Summit 2025レポート Unity Catalogの最新進化やAIエージェントの動向など、Databricksの最新ガバナンス機能についてレポートしています。 5-4. 実装例：SnowflakeのデータクラウドとSnowflake Horizon もう一つの代表的なプラットフォームがSnowflakeです。Snowflakeは、SaaSとしての運用の容易さと「Snowflake Horizon」による洗練されたガバナンス機能が特徴です。物理的なコピーを作らずにデータを共有できる「セキュアデータシェアリング」や、異なるクラウド間を跨いだ一元的なガバナンスを敷ける能力に優れています。 関連記事： Snowflake Summit 2025レポート AI時代に求められるクラウドデータプラットフォームのガバナンス進化についてレポートしています。 関連記事： 攻めと守りを両立する次世代データガバナンス：DatabricksとSnowflake 両プラットフォームのガバナンス機能を横断的に比較し、具体的な実装方法を詳しく解説しています。 まとめ：自社のフェーズに合わせたガバナンス構築のステップ データガバナンスの構築は、組織・基盤づくり、プラットフォーム活用、統合・高度化の3フェーズで段階的に進めるのが現実的です。一度に完成させるものではなく、自社の現状に合わせたスモールスタートから始め、段階的に成熟させていくことが重要です。 自社の現在地を知る：データ活用 内製化成熟度モデル ガバナンスの整備は、それ自体がゴールではなく、データ活用の内製化を段階的に進めるための基盤です。dotDataは多数の企業のデータ活用を支援する中で、組織のデータ活用力を5段階で捉える「内製化成熟度モデル」を提唱しています。自社がどのフェーズにいるかを把握することで、ガバナンスの優先課題と次のアクションが明確になります。 フェーズ レベル 概要 ガバナンスとの関係 Phase A Lv.1 業務活用 開発済みの分析結果を読み解き、業務成果を出す段階 自動化パイプラインからの出力を正しく活用するために、データ品質の担保が前提となる Lv.2 運用・保守 パイプラインの中身を理解し、保守や軽微な改良ができる段階 データの加工ロジックやエラー対応を理解し、品質を維持する力が求められる Phase B Lv.3 テーマ拡大 類型範囲で新規テーマを横展開できる段階 新しいデータソースの追加に伴い、アクセス権限やデータ定義の拡張管理が必要になる Lv.4 データ拡大 新たなデータを追加し、分析精度やインサイトを強化できる段階 データ品質の検出・クレンジングを自律的に行える力と、リネージ管理が不可欠になる Phase C Lv.5 完全内製化 企画からデータ準備、分析、実装まで全工程を自律的に構築・運用できる段階 統合データガバナンスの枠組みのもと、ガードレールの範囲内で自由にデータを活用できる状態 Phase Aでは「整備されたガバナンスの恩恵を受ける」段階、Phase Bでは「ガバナンスの仕組みを理解し、自ら拡張する」段階、Phase Cでは「ガバナンスのガードレールの中で自律的に活用する」段階と位置づけることができます。 データ活用 内製化成熟度モデル ― セルフチェックシート（PDF）をダウンロード 自社の現在のレベルを診断し、次のフェーズに進むために必要な取り組みを確認できます。各レベルにおける「ユースケース設計」「データ準備・加工」「分析・活用」「自動化パイプライン」の4領域のスキル要件を詳しく解説しています。 フェーズ別おすすめ記事 フェーズ 取り組み内容 おすすめ記事 ① 組織・基盤づくり CDOを中心とした推進体制の構築、データ基盤の整備、役割定義、品質基準の策定 CDOが知るべき組織モデル / 三位一体モデル / データ基盤とは？ / データパイプライン / メダリオンアーキテクチャ ② プラットフォーム活用 Databricks / Snowflake等のガバナンス機能をネイティブに活用し、ポリシーをシステムに実装 Databricks・Snowflakeガバナンス / Databricks Summit 2025 / Snowflake Summit 2025 ③ 統合・高度化 統合データガバナンスの実現、AIセキュリティの確立、AI Ready Dataへの昇華 統合データガバナンス / AIセキュリティ 重要なのは、ガバナンスを「制限」ではなく「ガードレール」として捉えることです。第2章で触れたように、データを安全に、かつ迅速に活用できる環境を整えることこそが、AI時代の競争優位性を生み出す基盤となります。 まずはスモールスタートで始め、プラットフォームの機能を活用しながら、組織全体でデータドリブンな文化を醸成していきましょう。 The post データガバナンスとは？ ― AI時代の企業競争力を左右する「データの統治」 appeared first on dotData .

想定読者 ：AWS（Lambda・API Gateway・Athena）に触れたことのあるバックエンド／クラウドエンジニア スコープ ：チャットUIからAmazon Bedrock上のStrandsエージェント経由でSQLを組み立て・実行し、結果をWebSocketで返すまで。 エンティティ解決やセグメンテーション本体は本稿では扱いません（末尾に一言だけ）。

はじめに こんにちは。株式会社エブリーの開発1部の村上です。 弊社ではClaudeを非エンジニアも含めた全社に展開しており、業務のあらゆる場面で生成AIの活用を推進しています。 弊社のデータ基盤は、昨年TreasureDataとDatabricksを併用していた構成からDatabricksに統一しました。（この移行の話は今週の 「第3回 Youは何しにDatabricksへ！？」 で「データ基盤をTreasureData + DatabricksからDatabricksへ統一する話」として弊社のデータエンジニアの吉田がお話しする予定なので、ぜひご参加ください。）基盤が統一されたことで、次のステップとして見据えているのが「AIを活用したデータの民主化」です。 AIの進歩によって、ずっと掲げてきたこのテーマがいよいよ現実味を帯びてきました。MCP経由で社内のデータを取得し、AIと対話しながら分析を進め、今までにないインサイトを得る。そんな世界がすぐそこまで来ています。 一方で、 「AIを使えばデータが簡単に出せる」ことと「現場で信頼して意思決定に使えるレベルの分析ができる」 こととの間には、まだまだ大きな壁があります。 AIはとても賢いですが、私たちの会社のこと、事業のこと、プロダクトのことを詳細には知りません。そのため、聞きたいことをそのまま質問してもその意図を正確に理解できず、全く違うデータを返してしまったり、生成するクエリが微妙に間違っていて正しいデータが出せなかったりします。結果として「使い物にならない」となってしまうわけです。 今回は、そんな状態からどのように進めていくことで「現場で使えるAI分析基盤」を作れるのか、Databricks環境で試行錯誤している話をします。 Databricks Genieとは こうした課題を解決するためにDatabricksが提供しているのがGenieです。Genieは自然言語でデータに対して質問すると、SQLを自動生成して結果を返してくれるインターフェースです。 docs.databricks.com ただし、これは単にDatabricks上でLLMを呼び出してSQLを書かせるだけのものではありません。 LLMの限界を理解した上で、自分たちの組織専用にチューニングできるように設計されている のがGenieの本質です。 Genie Space — 目的特化の分析空間 Genieでは「Genie Space」という単位でデータの分析空間を作ります。会社にはさまざまな部門があり、それぞれが見たいデータや使う用語は異なります。Spaceではそのそれぞれに適したコンテキストを設定できるようになっており、登録するテーブルを指定することで必要なデータだけにアクセスさせることができます。 たとえば営業チーム向けのSpaceにはSalesforceのデータを、ECチーム向けのSpaceには注文・顧客データを登録するといった具合です。1つのSpaceに登録できるテーブルは最大30件で、むやみに広げるのではなく、そのSpaceが答えるべき質問の範囲に絞ることが推奨されています。 Knowledge Store — AIのためのコンテキストを整える仕組み 各Genie Spaceには「Knowledge Store」と呼ばれるコンテキストをチューニングする機能が備わっています。これがGenieを組織専用に育てていくための中核です。Knowledge Storeには以下の要素があります。 Metadata: テーブルやカラムの説明文、同義語、不要カラムの非表示。GenieがSQLを組み立てるための基礎知識 Prompt Matching: カラムの実際のデータ値をGenieに事前認識させ、ユーザーの言葉とデータ値のマッチング精度を上げる Joins: テーブル間の結合条件を定義。Genieが複数テーブルをまたぐクエリを正しく書けるようにする SQL Expressions: Filter（条件定義）、Measure（指標の計算式）、Dimension（グルーピング定義）をSQLで直接登録 Example SQL: よくある質問に対する正解SQLをテンプレートとして登録 General Instructions: テキストでの補足指示 ここからは、実際にSpaceを作ってKnowledge Storeを育てていく過程を、実際に行なった試行錯誤とともに解説していきます。 まずは何もチューニングせずに聞いてみる まずやったのは、最小限の設定だけでGenie Spaceを作って、いきなり質問してみることです。テーブルにはカラムコメント（日本語の説明文）を付与済みで、General Instructions（テキストの指示文）にはビジネスコンテキストを3行だけ書きました。 これはECサービスのデータが格納されているスペースです。 ECカートからのトランザクションデータを元に、事業KPIを分析します。 日本語で回答してください。 この状態でいくつかの質問を投げてみた結果がこちらです。 質問 Genieの挙動 正誤 先月のGMVは？ キャンセル・返品済みの注文も含めて集計 ❌ 先月の割引額は？ 割引関連の3カラムのうち1つだけで集計 ❌ 先月の定期購入のGMVは？ データ値を英語で推測し、0件ヒット ❌ 先月の1人あたり月間購入金額は？ 分子に使うべき指標を別の指標と混同 ❌ 先月のキャリア決済のGMVは？ 一部の決済方法を集計から漏らした ❌ 5問中、正解はゼロ。しかし、間違い方には共通するパターンがあります。 ビジネスルールを知らない 「KPI集計時にはキャンセル・返品を除外する」というルールをGenieは知りません。そのためフィルタなしで集計してしまいます。 言葉の定義が曖昧 「割引」と聞かれたとき、 discount というカラム名だけを見てそれだけで完結したと判断しました。実際には複数のカラムを合算する必要があるのですが、ビジネスの定義を知らなければわかりません。 データの中身を知らない 受注種別カラムには「定期受注」「通常受注」という日本語の値が入っているのに、Genieは英語の 'subscription' で推測して何もヒットしませんでした。 似た指標を区別できない 税込の総額と税抜の売上高を混同したり、決済方法のグルーピングが期待と一致しなかったり。似た概念が複数存在する領域で間違いが起きやすいことがわかりました。 AIは知らないことを推測で埋めようとします。それ自体は賢い振る舞いですが、ビジネスでは「もっともらしい間違い」が一番危険です。ここから「AIに正しく教えていく」プロセスが始まります。 AIにデータを活用できるようにするためのステップ 先述のKnowledge Storeの機能を使い、実際に設定を追加してはテストし、間違えたらまた設定を足すという繰り返しで精度を上げていった過程を紹介します。 1. メタデータ整備 — まずAIにデータの地図を渡す Genieがテーブル構造やカラムの意味を理解できなければ、そもそもSQLを正しく組み立てることさえできません。個人でClaudeを使うなら自分専用のテーブル定義書を作ってコンテキストに含めればいいですが、組織で複数人が使う場合にはスケールしません。 そこで重要になるのが、Databricksの Unity Catalog でのメタデータ管理です。 テーブル・カラムの説明文 Unity Catalogではテーブルやカラムに対してCOMMENTを付与できます。 COMMENT ON COLUMN orders.subtotal IS ' 小計（税抜商品売上）。定期割引適用済み ' ; COMMENT ON COLUMN orders.total IS ' 注文合計（税込）。GMV計算に使用 ' ; COMMENT ON COLUMN orders.revenue IS ' 売上高（subtotal + deliv_fee + charge）。税抜合計 ' ; カラムの説明は「何が入っているか」だけでなく「何に使うか」「何と違うか」まで書くと、Genieの精度が大きく変わります。特に似た概念のカラムが複数ある場合（GMV / 売上高 / 商品売上など）は、区別を明示することが重要です。 Genie Space上の同義語 ユーザーはいつも同じ言い方で質問するとは限りません。「UU」「ユニーク顧客数」「月間ユーザー数」はすべて同じ指標を指しています。Genie SpaceのMetadata設定でカラムに同義語を登録しておくことで、こうした表記揺れを吸収できます。 Prompt Matching Genieにはカラムの実際のデータ値を事前に認識させる機能があります。 Format Assistance: カラムからサンプルデータを取得して、どんな値が入っているかをGenieに学習させる Entity Matching: カテゴリカラムのユニーク値をリスト化して保存し、ユーザーの言葉と実際のデータ値をマッチさせる たとえば先ほどの「定期購入のGMV」問題。これは受注種別カラムの値が日本語であることをGenieが知らず、英語で推測してしまったことが原因でした。Prompt Matchingを有効にすることで、Genieは実際のデータ値を事前に把握した状態で質問に答えられるようになります。 ただし、Prompt Matchingは値を「見せる」機能であり、「使わせる」保証はありません。あくまで補助的な役割です。確実にビジネスロジックを定義するには、次のステップが必要です。 2. SQL Expressionでビジネスロジックを定義する 自然言語での質問には、データ上の定義とのギャップが必ず存在します。ユーザーが「売上」と言ったとき、それがGMV（税込総額）なのか売上高（税抜）なのか商品売上（商品のみ）なのかは、ビジネスの文脈を知らなければ判断できません。 Genie SpaceのKnowledge Storeでは、 SQL Expression としてこのビジネスロジックをSQLで直接定義できます。SQL Expressionには3つの種類があります。 Filter — 条件の定義 「有効注文のみで集計する」というビジネスルールをFilterとして定義します。 名前 SQL 同義語 Instructions 有効注文 orders.state NOT IN ('canceled', 'returned') 有効注文, KPI対象 GMV・売上・注文数など金額や数量を集計するクエリでは必ず適用すること。キャンセル分析時のみ適用しない Filterを設定する前は集計に不要なデータが含まれていましたが、設定後は正しい値が返るようになりました。 Measure — 指標の定義 ビジネスで使うKPIの計算式をMeasureとして定義します。 名前 SQL 同義語 Instructions 割引額 SUM(orders.subscription_discount + orders.discount + orders.point) 割引額, 割引合計, 値引き 定期割引 + クーポン割引 + ポイント利用の合計 設定前は割引に関連するカラムのうち1つだけが使われていましたが、設定後は3カラムの合算で正しい値を返すようになりました。 同様に、「1人あたり月間購入金額」もMeasureで定義することで、分子と分母に使う指標が正しく固定され、安定して正確な結果が得られるようになりました。 Dimension — グルーピングの定義 データ上は複数種類ある決済方法を、ビジネスで見たいグループにまとめるDimensionを定義します。 CASE WHEN orders.payment_method IN ( ' ドコモ払い ' , ' au決済 ' , ' ソフトバンク払い ' ) THEN ' キャリア決済 ' WHEN orders.payment_method = ' クレジットカード ' THEN ' クレジットカード ' WHEN orders.payment_method LIKE ' 後払い% ' THEN ' 後払い ' ELSE orders.payment_method END Dimensionを定義する前は、Genieが毎回自力でCASE WHENを書いていたため、聞き方によってグルーピングが変わるリスクがありました。定義後は「決済グループ別のGMVは？」と聞くだけで毎回同じロジックが適用されます。 3. Example SQLで信頼性を引き上げる SQL Expressionが「部品」だとすると、Example SQLは「完成品の見本」です。よくある質問パターンに対する正解SQLを丸ごと登録しておくことで、Genieはそのテンプレートを参考にSQLを生成します。 Example SQLの設定で重要なポイントが3つあります。 1. タイトルはユーザーが実際に聞く質問文にする Genieはタイトルとユーザーの質問をマッチングしています。「定期購入GMVクエリ」ではなく「先月の定期購入のGMVは？」と書くことで、マッチング精度が上がります。 2. Usage Guidanceでいつ使うかを明示する 「定期購入のGMV」「定期のGMV」「サブスクのGMV」と聞かれたとき、のように具体的な発動条件を書きます。 3. 全Example SQLに共通のフィルタパターンを含める これが最も効果的でした。すべてのExample SQLに有効注文フィルタを含めておいたところ、Example SQLに直接マッチしない新しい質問に対しても、Genieが同じフィルタパターンを自然に適用するようになりました。Example SQLはGenieにとって「スタイルテンプレート」としても機能するのです。 -- タイトル: 定期購入のGMVは？ SELECT SUM (orders.total) AS gmv FROM orders WHERE orders.kind = ' 定期受注 ' AND orders.state NOT IN ( ' canceled ' , ' returned ' ) AND fct_orders.order_date >= :start_date AND fct_orders.order_date < :end_date Example SQLを パラメータ化 すると、そのクエリがそのまま使われた場合に応答に「Trusted」ラベルが付きます。これはGenieが検証済みのクエリをそのまま実行したことを示すもので、結果の信頼性をユーザーに保証する仕組みです。 究極的には、レビュー済みのクエリが使われるのが一番精度が高く、出力が安心できます。Trustedラベルがどんどんつくようになれば、ユーザーがデータを疑う回数は極端に減っていきます。 General Instructionsは最後の手段 ここまでの3ステップで、大半の課題は解決します。General Instructionsには何を書いたかというと、最終的にこれだけです。 これはECサービスのデータが格納されているスペースです。 ECカートからのトランザクションデータを元に、事業KPIを分析します。 日本語で回答してください。 たった3行。なぜこれだけでいいのかというと、 テキストの自然言語指示はGenieの行動を強制する力が最も弱い からです。 Genieは複合AIシステムであり、単一のLLMではありません。テーブルのメタデータ、SQL Expression、Example SQL、サンプル値、チャット履歴など、周辺のあらゆる情報を総合的に参照してSQLを生成します。多くの場合、General Instructionsに書きたいことは、SQL ExpressionやExample SQLでより堅牢に定義できます。 実際、当初はGeneral Instructionsに「KPI集計時はキャンセル・返品を除外すること」と書いていましたが、それだけでは適用されないケースがありました。SQL ExpressionのFilterとして定義し、さらにExample SQLのパターンで学習させることで、ようやく安定して適用されるようになりました。 Databricksの公式ドキュメントでも「instructionsは他の方法で対応できない場合の最終手段」と 明記 されています。 Knowledge Storeを育てた結果 ここまでの設定を積み重ねた結果、冒頭で全問不正解だった質問に対して、すべて正しい値を返せるようになりました。 対策したのは以下のようなシンプルな設定の積み重ねです。 SQL Expression: Filter、Measure、Dimensionの定義 Example SQL: よくある質問パターンの正解SQLを登録 Prompt Matching: カテゴリカラムの値を認識させる 一つひとつは小さな設定ですが、それぞれが特定の間違いパターンに対応しており、積み重なることでGenieの応答精度は着実に向上していきます。 育てたGenie Spaceを組織で活用する Genie Spaceをある程度チューニングしたら、次はそれを組織で活用して育てるフェーズです。 Genie MCP — ClaudeからGenieを直接使う DatabricksのManaged MCP Serverを使えば、Genie SpaceごとにMCPエンドポイントを作成できます。 https://<workspace>/api/2.0/mcp/genie/<genie_space_id> これをClaude.aiのConnectorに登録すると、普段使いのClaudeから直接Genieに質問できるようになります。ユーザーはDatabricksの操作を覚える必要がなく、いつも使っているClaudeで自然言語で質問するだけです。裏側でGenieがKnowledge Storeを参照しながら正確なSQLを生成し、結果を返します。 弊社ではClaudeを全社展開しているため、各部門のGenie Spaceを作ってそれぞれのMCPをClaudeに登録すれば、非エンジニアでも自分の部門のデータに自然言語でアクセスできる環境が作れます。 Monitoringで改善サイクルを回す Genie SpaceのMonitoringタブでは、ユーザーが実際に投げた質問と応答を確認できます。うまく答えられなかった質問は、Benchmarkに追加し、Knowledge Storeの設定を改善し、再度評価する。このループをチームで地道に回していくことが、Genie Spaceの精度を継続的に向上させる鍵です。 おわりに AIが自社データを"わかる"ようになるには、一度の設定では終わりません。使って、間違いを見つけて、設定を足して、テストする。その繰り返しです。 改善は地道ですが、 これをやり切った組織とそうでない組織では、プロダクト改善のスピードや事業成長のスピードに取り戻せないほどの差が生まれてくる と考えています。 AIの進化によって、データ分析の主役はSQLを書けるエンジニアから、事業を深く理解しているビジネスメンバーへとシフトしていきます。そのとき、AIが正しく答えてくれるための「土台」を整えておくことが、データ基盤をみるエンジニアの役割の一つだと思っています。私たちの組織ではこれを全社を巻き込んで主導していきたいと思っています。 エブリーでは一緒に働く仲間を募集中です！ エンジニアブログをきっかけに少しでも興味も持っていただけたら、まずはカジュアルに面談しましょう！