第6章 ガバナンス / 想定学習時間:30〜40分 / 最終確認:2026年8月

6-5. Unity Catalogを用いたガバナンス統合

🎯 この節の学習目標

1. なぜ「単一のガバナンス」が必要か

本章の締めくくりとして、これまで学んだ個別の対策を1つの統治基盤の上に統合します。生成AIアプリケーションは、実に多くの種類の資産から構成されます。

これらがバラバラの場所でバラバラの権限体系のもとに管理されていると、「誰がこのモデルを使えるのか」「このインデックスの元データはどこか」「顧客データがどのモデルに流れ込んだのか」に答えられなくなります。Databricks の答えが、すべての資産を Unity Catalog(UC)という単一のガバナンスレイヤーの下に置くことです。UC はテーブルだけでなく、モデル、AI Search インデックス、関数、ボリューム(ファイル)を同じ カタログ.スキーマ.資産名 の3階層名前空間で管理し、同じ権限モデル・同じ監査体系を適用します。

📝 試験のポイント

「生成AIアプリケーションのデータ・モデル・その他の資産を一元的に統制(govern)する Databricks の仕組みは?」と問われたら、答えは Unity Catalog です。MLflow(実験管理・モデルのパッケージング)や Unity AI Gateway(エンドポイントの統制)と役割を混同しないようにしましょう。モデルレジストリも現在は UC 上のモデル(Models in Unity Catalog)として管理され、UC のガバナンスに統合されています。

2. UC が提供する4つのガバナンス機能

生成AIの文脈で特に重要なUCの機能を4つに整理します。

機能内容生成AIでの使いどころ
一元的アクセス制御GRANT/REVOKE による権限付与。テーブルもモデルもインデックスも関数も同じ構文・同じ権限モデルで管理機密文書テーブルは人事部のみ、モデルの実行権限はアプリのサービスプリンシパルのみ、といった最小権限の実装
リネージ(lineage)資産間の依存関係(どのテーブルからどのテーブル・インデックス・モデルが作られたか)を自動追跡「この回答の元になったインデックスはどの文書テーブル由来か」「PIIを含むテーブルがどのモデルの学習に使われたか」を追跡。問題発覚時の影響範囲調査に必須
監査ログ(audit log)誰が・いつ・どの資産にアクセスしたか(クエリ、モデル呼び出し、権限変更など)の記録コンプライアンス対応、情報漏えい調査、プロンプトインジェクション等のインシデント調査(6-2)
タグ付け資産・カラムへのタグ(例:PII タグ)の付与と、タグに基づく検索・管理PIIを含む列・テーブルをタグで可視化し、マスキング(6-1)や権限設定の適用漏れを防ぐ

💼 例:リネージが効く場面

ある日、RAGボットの回答に本来含めてはならない機密情報が混入していることが発覚したとします。UC のリネージをたどれば、「回答の根拠となった AI Search インデックス → その同期元のチャンクテーブル → さらにその元のソース文書テーブル」という系譜を逆に追跡でき、どの文書の取り込みが原因かを特定できます。さらに監査ログで「その文書テーブルに誰がいつデータを追加したか」を調べられます。ガバナンスが単一基盤に統合されているからこそ、この調査が一気通貫でできるのです。

3. データレベル保護と資産権限の組み合わせ

UC の保護機能は「資産全体への権限」と「データの中身への細かい制御」の2段構えです。

この2段構えにより、「そもそもアクセスできる人を絞る」と「アクセスできる人にも必要以上の生データは見せない」を同時に実現します。

4. エンドツーエンドガバナンスの全体像

第4章・第5章で学んだ仕組みと合わせると、「データからモデル、エンドポイント、運用まで」の各段階に対応するガバナンスの部品が揃います。試験対策としても、この対応表を頭に入れておくと「どの段階の統制が問われているか」で機能を選べるようになります。

段階統制の対象使う仕組み
データソース文書・チャンクテーブルへのアクセス、PII保護UC の GRANT、カラムマスク・行フィルタ、PIIタグ(6-1)
インデックスAI Search インデックスの利用権限、元データの追跡UC の権限管理、リネージ
モデル登録モデルのバージョン・権限・昇格(エイリアス)管理Models in Unity Catalog(4-3)
ツールエージェントが実行できる関数の制限UC 関数への実行権限(3-4、6-2)
エンドポイント推論トラフィックの統制:レート制限、ガードレール(PII・セーフティ)、外部モデルの一元管理Unity AI Gateway(4-4)
運用リクエスト・応答の記録、品質・コストの監視、問題出力の分析推論テーブル(5-5)、モニタリング(第5章)、UC 監査ログ

まとめると:静的な資産(データ・インデックス・モデル・関数)は Unity Catalog が、動的なトラフィック(推論のリクエスト)は Unity AI Gateway が統制し、運用の記録は推論テーブルと監査ログが担う——これが Databricks における生成AIのエンドツーエンドガバナンスの全体像です。

利用者 / アプリケーション
推論リクエスト
Unity AI Gatewayランタイムガバナンス:ポリシー・ガードレール・スペンドキャップ・トレーシング
モデル
エージェント
MCPサーバー
ツール
参照・実行する資産
Unity Catalog資産ガバナンス:テーブル・Volume・インデックス・モデル・関数(GRANT・リネージ・監査)

図:ガバナンススタックの全体像。動的なトラフィックは Unity AI Gateway が、静的な資産は Unity Catalog が統制します。

💼 例:ガバナンス要件を仕組みに落とす

「顧客データを扱うRAGアプリについて、①PII列は開発者に見せない、②本番モデルを変更できる人を限定する、③どの文書からモデルが作られたか追跡できるようにする、④モデルへの全リクエストを記録する」という要件があるとします。対応は次のとおりです。

  1. ① → UC のカラムマスクと PII タグ
  2. ② → UC 上のモデルへの権限(GRANT)とエイリアス運用(4-3)
  3. ③ → UC のリネージ
  4. ④ → エンドポイントの推論テーブル(5-5)

要件の言葉(見せない/限定する/追跡する/記録する)から対応する機能を即座に選べるようにしておきましょう。

5. 第6章の総まとめ

本章で学んだガバナンスの各テーマは、次のように整理できます。

テーマキーワード
6-1入力の保護PIIマスキング(インデックス作成時・推論時)、Presidio、Unity AI Gateway ガードレール、カラムマスク
6-2攻撃への防御プロンプトインジェクション(直接型・間接型)、多層防御、ツール権限最小化
6-3法的・契約的統制モデルライセンス(Apache 2.0/MIT vs コミュニティライセンス)、商用条件、利用規約
6-4出力の統制有害出力の分類、6つの緩和層、Llama Guard、human-in-the-loop
6-5基盤としての統合Unity Catalog:一元的アクセス制御、リネージ、監査ログ、タグ

Governance セクションの出題比率は8%と大きくありませんが、「シナリオに対して適切な統制手段を選ぶ」という素直な問題が多い領域です。本章の対応表を確実に得点源にしてください。

✅ この節のまとめ

練習問題

問1. ある企業が、RAGアプリケーションを構成するソース文書テーブル、AI Search インデックス、埋め込みモデル、チェーンモデル、エージェント用の関数を、単一の権限モデルとリネージ・監査のもとで一元管理したい。使用すべき Databricks の仕組みはどれか。

  1. MLflow Tracking
  2. Unity Catalog
  3. Delta Live Tables
  4. Databricks Jobs
解答と解説を見る

正解:B

テーブル・インデックス・モデル・関数といった異なる種類の資産を、同一の名前空間・権限モデル・リネージ・監査ログで統治するのが Unity Catalog です。AのMLflow Trackingは実験の記録、Cはデータパイプラインの構築、Dはジョブのスケジュール実行の仕組みであり、いずれも資産全体の一元ガバナンス基盤ではありません。

問2. RAGボットの回答に機密情報の混入が発覚した。「そのインデックスがどのソーステーブルから作られたか」を遡って特定するために使うべきUCの機能はどれか。

  1. カラムマスク
  2. リネージ
  3. 行フィルタ
  4. タグ付け
解答と解説を見る

正解:B

資産間の由来・依存関係(どのテーブルからどのインデックス・モデルが作られたか)を追跡するのがリネージです。AのカラムマスクとCの行フィルタはデータの中身の表示を制御する保護機能、Dのタグ付けは資産の分類・可視化の機能であり、いずれも系譜の追跡はできません。なお「誰がいつアクセスしたか」を調べるのは監査ログで、リネージ(資産のつながり)とは区別して覚えましょう。

問3. 顧客テーブルには電話番号の列があり、データサイエンティストは分析のためにテーブル自体へのアクセスは必要だが、電話番号の実値を見る必要はない。適切なUCの機能はどれか。

  1. テーブルへのアクセスを完全に禁止する
  2. 電話番号列にカラムマスクを設定し、権限のないユーザーにはマスクされた値を返す
  3. テーブルを毎回CSVでエクスポートし、電話番号列を手作業で削除して配布する
  4. リネージを有効化する
解答と解説を見る

正解:B

「テーブルには触れるが特定列の実値は見せない」という要件には、UC のカラムマスクが正確に対応します。Aは分析業務自体を不可能にする過剰制限です。Cは手作業でエラーが起きやすく、統制(ガバナンス)ではなく運用でカバーする悪いパターンです。Dのリネージは由来の追跡機能であり、値の秘匿はできません。

問4. 生成AIアプリのエンドツーエンドガバナンスにおける各仕組みの役割の説明として、最も適切なのはどれか。

  1. Unity Catalog が推論リクエストのレート制限を行い、Unity AI Gateway がテーブルの権限を管理する
  2. データ・インデックス・モデル・関数などの静的資産は Unity Catalog が統制し、推論トラフィックは Unity AI Gateway が統制し、リクエスト・応答の記録は推論テーブルが担う
  3. すべてのガバナンス機能は推論テーブルだけで実現される
  4. Unity AI Gateway はソース文書のチャンク化を行い、Unity Catalog は埋め込みを計算する
解答と解説を見る

正解:B

役割分担の全体像はB のとおりです。静的な資産の権限・リネージ・監査は Unity Catalog、エンドポイントを通る動的なトラフィックの統制(レート制限・ガードレール・外部モデル管理)は Unity AI Gateway、推論の入出力の記録は推論テーブルが担います。Aは両者の役割が逆です。Cの推論テーブルは記録の仕組みにすぎず、権限管理やガードレールは提供しません。Dはチャンク化・埋め込み計算というデータ処理の話であり、どちらの仕組みの役割でもありません。