azure-recipe-user はじめに
2026年6月15日〜18日にサンフランシスコおよびバーチャルで開催されている、Databricks社主催の年間最大級のカンファレンスイベント 「Databricks Data + AI Summit 2026（DAIS）」 について、現地セッションの内容を日本語でまとめました。
- 公式サイト: https://www.databricks.com/dataaisummit
- セッション名: Agent Ready Data Governance: Databricks on Databricks
本記事は、DAIS 2026 の該当セッションで発表された内容をもとに、エージェント時代のデータガバナンスに関するポイントを整理したものです。
本記事は Databricks 公式発表をもとにした非公式の日本語要約です。
記載内容の著作権・知的財産権は各権利者に帰属します。
忙しい方用
- エージェント時代では、従来の人間前提のガバナンスでは限界がある
- Databricks は 3PI により、取り込みとガバナンスを自動化
- 重要な対策は「読む前に分類」「外に出る前にマスキング」「権限は足し算せず置き換え」
Databricks が DAIS のセッションで語っていたテーマは、ひとことで言うと
「エージェント時代のデータガバナンスをどう成立させるか」 でした。
※本記事は、DAISでのセッション内容をもとに、日本語として自然になるよう再構成・意訳したものです。
※話し言葉は、読みやすさを優先して整えています。
Databricks が DAIS のセッションで語っていたテーマは、ひとことで言うと
「エージェント時代のデータガバナンスをどう成立させるか」 でした。
Databricks は自社でも、非常に大規模で複雑な環境を運用しています。
- 100 を超えるワークスペース
- 10,000人以上のユーザー
- すべての主要クラウド
- ほぼすべての機能を活用
- さらには未公開の機能まで利用
この環境を使って、データを活かし、意思決定を速め、プロダクトを改善し続けているそうです。
ただし、ここで大きな課題があります。
人間を前提に作られたガバナンスは、エージェントにはそのまま通用しない ということです。
今回のセッションでは、Databricks が実際に経験した以下の内容が紹介されました。
- 何が壊れたのか
- なぜ壊れたのか
- どう直したのか
エージェント時代に何が変わったのか
まず最初に、会場にこう問いかけていました。
- 日常業務で AI を使っているか
- その AI から社内の SaaS に接続しているか
- 同僚も同じことをしていると思うか
Databricks には 500 を超える SaaS インスタンスがあり、そこには会社のデータが存在します。
そしてそのデータには、人間だけでなく エージェントもアクセスできる 状態になっています。
この状況で、従来のガバナンスには次のような限界が出てきます。
- 監査の一貫性が保てない
- 誰が何をしているのか追いきれない
- 指標の再現性がない
- API レート制限がすぐに枯渇する
つまり問題は、「データが多いこと」ではありません。
データが分散したまま、エージェントが高速で動くこと が問題なのです。
エージェントに直接ツールを触らせるとどうなるか
最初に多くの人が考えるのは、
エージェントをそのまま SaaS ツールにつなぐ 方法です。
MCP のような仕組みを使って、直接データを取りに行かせるやり方です。
これは技術的には動きます。
データも取れます。
ただ、たとえば次のような質問をしたとします。
「先週拡張したアカウントの製品利用状況を取得して」
このときエージェントは、製品データ と Salesforce データ を、クエリレイヤーなしでそのままコンテキストに詰め込もうとします。
結果として、大量のトークンを消費し、処理は重く、コストも高くなります。
さらに悪いことに、
「遅いし高いから、適当に答えてしまおう」といった挙動を取ることもあります。
これは明らかに避けたい状況です。
その結果として起きがちなのが、次のような現象です。
- データを SaaS 側にコピーしてしまう
- CRM が新しいデータサイロになる
- ノートPC や個別環境にデータが散らばる
私たちは長年、データサイロをなくすために取り組んできました。
それなのに、エージェントの時代になると、また同じことを繰り返してしまうわけです。
答えは「Lakehouse に集める」こと
ここでの答えは、すでに多くの人が知っているものです。
One Lakehouse
データは外へ押し出すのではなく、まず Lakehouse に集める。
これは従来から変わらない基本方針です。
ただし AI の時代には、これだけでは足りません。
- 新しい接続先がどんどん増える
- 要求されるスピードが上がる
- ユーザーは「昨日ほしかった」と言う
つまり、取り込みの速度とガバナンスの両立 が必要になります。
そこで Databricks の答えは、次の 2 段階でした。
Ingest then govern
まず取り込み、そのあとでガバナンスする
3PI: 取り込みをエージェント時代に合わせる
Databricks は内部向けに 3PI (Third-Party Ingestion) という仕組みを作りました。
これは、SaaS システムを入力すると、エンドツーエンドの取り込みパイプラインを自動生成してくれる、ノーコードのガバナンス付き ingestion platform です。
3PI は、Databricks の既存機能を組み合わせたものです。
-
Lakeflow Connect
- コネクタ
- 認証
- スキーマ検出
- エラー処理
-
Unity Catalog
- データの保管場所
- アクセス制御
- ガバナンス
-
Lakeflow Jobs
- オーケストレーション
- スケジュール実行
- リトライ
- インフラ保証
つまり、ゼロから全部作ったのではなく、
既存の部品をきれいに組み合わせた のが 3PI です。
3PI の流れ
3PI では、取り込みの各ステップをエージェントが実行します。
1. Intake
どの SaaS を対象にするかを決めます。
エージェントは API ドキュメントや認証方式、レート制限などを読み取り、必要な情報を対話的に確認します。
たとえば：
- スキーマは何か
- オーナーは誰か
- 同期頻度はどれくらいか
2. Credentials
ユーザーに代わって認証情報を取得します。
3. Schema Discovery
スキーマを検出します。
4. Review
ここだけは人間が確認します。
法務やセキュリティが承認する重要なゲートです。
5. Deploy
テストし、デプロイし、スケジュールに乗せます。
これにより、チケットを 1 件出すだけで、ガバナンスされたパイプラインが生成される ようになります。
3つの設定ファイルがすべてを決める
3PI の本質は、最終的に以下の 3つの設定ファイルに集約されることです。
Connector
データの取り込み元を定義します。
- どこから取得するか
- どの頻度で同期するか
- 障害発生時の通知先はどこか
Table File
どこに何を格納するのかを定義します。
- 対象データセット
- カラム定義
- データ品質チェック
- パーティション設計
ABAC
ポリシーを定義します。
- どのデータに対して
- どの条件で
- どんな制御を行うか
たとえば、ある列が機微情報としてタグ付けされたら、
ABAC が読み取り時に自動でマスキング します。
つまり、
ソース・保存先・ポリシー が決まれば、それ以外の要素は自動生成できるわけです。
その結果、ガバナンスされていない経路を通る余地がなくなる のです。
人間を速くしても、限界はある
最初、Databricks の ingestion は手作業でした。
1件作るのに約1週間かかり、バックログは積み上がる一方でした。
そこで LLM を使って作業を高速化しました。
すると、1週間が 2 日程度になりました。
しかし、ここで問題は終わりません。
なぜなら、依頼してくる側もエージェントだから です。
人間の作業を速くしても、単に「遅く負ける」だけです。
そこで発想を変えました。
何を速くするかではなく、
誰が作るかを変える
その結果生まれたのが 3PA agent です。
これにより、SaaS ingestion を ほぼエンドツーエンドで自動構築 できるようになり、
人間は最後の確認だけを行う形になりました。
ここからが本題: 壊れた3つのポイント
ここからは、実際に壊れた 3 つのガバナンスについて説明されました。
共通している問いはひとつです。
エージェントに、何を触ってよいかをどう判断させるか？
そして答えは、かなりシンプルです。
理解していないデータに、正しい権限は付けられない
つまり、まずは データを理解すること が前提になります。
Story 1: 読む前に分類する
昔は、データ分類は「あとでやるもの」でした。
人間が定期的に監査し、明らかなものだけタグ付けしていれば十分だったのです。
しかし今は違います。
読むのは人ではなく、ボット です。
エージェントは、普通の質問をしただけなのに、
機密情報をそのまま Slack や Google Docs、メールに出してしまうことがあります。
何が問題だったのか
- 分類がまだ終わっていない
- 監査は来週の予定
- でもエージェントはもう読んでしまった
どう直したのか
データを読ませる前に分類する ことです。
Databricks では Unity Catalog Data Classification を使い、
取り込み直後のテーブルを LLM でスキャンして、機微情報の列を自動タグ付けします。
そのタグをもとに ABAC が即座にマスキングを適用します。
結果
同じ質問をエージェントに投げても、
返ってくるのは マスクされた値 だけです。
教訓: Classify before read
読み取り前に分類する。
「来週やる」は、もう遅い。
Story 2: 出る前に redaction する
2つ目の問題は、データがどこへ出ていくか です。
たとえば、同じデータでも次のような扱いがありえます。
- 高いコンプライアンス境界の中では SIEM ログとして扱う
- 別リージョンでは、集計済みデータとして分析に使う
人間なら、「これは境界をまたぐ」と気づけます。
しかしエージェントは、タスクを達成するために、最短の経路 を選んでしまいます。
その結果、生ログをそのまま別リージョンへ送ってしまう ことがあります。
これは当然ながらアウトです。
何が問題だったのか
- 生ログが高い境界から低い境界へ流出する
- 人間なら止められる
- エージェントは「通れる道」を見つけてしまう
どう直したのか
危険な経路を注意喚起するのではなく、そもそも作らない ことです。
Databricks では 3PI を拡張し、リージョン間のデータ移動にも対応させました。
例としては以下のような流れです。
- 各リージョンでログを受け取る
- residency ルールに従って振り分ける
- 機微列を redaction する
- 集計済みの安全なビューだけを Delta Sharing で中央に渡す
結果
リージョンをまたぐのは、集計済みかつマスク済みのビューだけ です。
生ログがそのまま外へ出ることはありません。
教訓: Redact before egress
外部送信前にマスキングする。
ルールを守らせるのではなく、違反できない経路にする。
Story 3: 権限は足し算ではなく置き換えにする
最後の問題は、データそのものではなく、権限の組み合わせ です。
たとえば人事向けのダッシュボードを作るとします。
ある担当者は、以下のような業務データにアクセスできるかもしれません。
- GitHub の活動履歴
- Jira チケット
- Google Docs
同時に、別の権限として Workday の人事・属性情報にもアクセスできるとします。
これらは、それぞれ単独なら問題ないように見えます。
しかし、エージェントに両方を持たせると危険 です。
エージェントは、より「丁寧」な答えを作ろうとして、
本来結びつけてはいけないものを結びつけてしまう可能性があります。
たとえば、
- 活動データ
- 年齢
- 性別
- 民族
- 居住地
を、同じレビュー資料に混ぜてしまうかもしれません。
これはやってはいけません。
何が問題だったのか
- 人間なら「この組み合わせは危ない」と判断できる
- エージェントにはその判断がない
- 権限を足し算すると、危険な join が可能になる
どう直したのか
権限を足さず、置き換える という考え方を採用しました。
ここで導入したのが RBAC exclusive groups です。
- グループに「入る」のではなく、ロールを引き受ける
- ロールを引き受けた瞬間、他の権限は外れる
- 権限が積み上がらない
- その結果、危険な join 自体ができない
監査可能性も確保する
さらに、誰がその操作を指示したのか を追えることも重要です。
Unity AI Gateway の OnBehalfOf により、
エージェントがどの人の代わりに動いたのかがトレースできます。
これによって、
- 実際に依頼した人
- エージェントが引き受けたロール
の両方が監査ログに残ります。
教訓: Replace, don’t union
権限は足し算ではなく置き換えにする。
3つの教訓をまとめると
最後に、3つのストーリーをまとめるとこうなります。
1. 読む前に分類する
- Unity Catalog Data Classification を使う
- 先にタグを付ける
- ABAC で即座にマスクする
2. 出る前に伏せる
- リージョンや境界をまたぐ前に redaction する
- 安全なビューだけを渡す
- Delta Sharing を使って安全に連携する
3. 権限は足さずに置き換える
- RBAC exclusive groups を使う
- 危険な権限の組み合わせを不可能にする
- Unity AI Gateway で誰の操作かを追跡する
まとめ
これまでのガバナンスは、
「信頼して、あとで確認する」 という考え方が中心でした。
しかし、エージェント時代にはそれでは間に合いません。
- エージェントは人間より速い
- エージェントは、与えられた権限を使い切ろうとする
- 問題が起きたときには、すでに手遅れになっていることが多い
だからこそ必要なのは、
あとから見るガバナンスではなく、最初から組み込むガバナンス です。
Databricks ではそれを、以下の仕組みで実現していました。
- 取り込みの自動化
- Unity Catalog による分類と制御
- ABAC による読み取り制御
- 境界を越える前の redaction
- RBAC exclusive groups による権限制御
- Unity AI Gateway によるトレースと監査
そしてその土台は、すでに多くのユーザーが使っている Databricks の機能群の上にあります。
エージェント時代のデータガバナンスは、
「何をできるようにするか」よりも先に、「何を絶対にさせないか」を決めること が重要です。
最後に、セッションの要点を一言でまとめると、次の 3 つになります。
-
Classify before read
読み取り前に分類する -
Redact before egress
外部送信前にマスキングする -
Replace, don’t union
権限は加算せず、置き換える
お知らせ
ナレッジコミュニケーションでは、Databricks Data + AI Summit 2026 開催に伴い、日本語でのウェビナーや現地レポートを公開しております！
DAIS2026 Recap イベント
現地参加が難しかった方や、主要トピックスを短時間で振り返りたい方向けに、Recapイベントを開催します。
セッションの要点整理や、日本企業での実装観点も交えてご紹介予定です。
▼ 開催概要・お申し込みはこちら
ナレッジコミュニケーション DAIS2026 特設サイト
DAIS2026で発表された注目テーマ、関連セッション、実務での活用ポイントを継続的に発信する特設ページです。
イベント情報の整理・社内共有にもご活用いただけます。
Databricks 導入支援サービスサイト
Databricksの導入検討から活用定着まで、課題に応じた支援メニューをご紹介しています。
「何から着手すべきか相談したい」という段階でも、お気軽にご覧ください。
databricks.kc-cloud.jp