2026年7月1日に更新された Azure Databricks の公式情報で最も重要なのは、AI ガバナンスの中心が「個別のモデル serving endpoint 管理」から「Unity Catalog を土台にした Unity AI Gateway 管理」へ広がっている点です。新しい Unity AI Gateway は現在 Beta で、アカウント管理者が Previews から有効化する必要があります。本番環境へ一斉適用するよりも、まずは対象リージョン、Unity Catalog の権限設計、既存 AI Gateway との違い、MCP サービスや外部モデルの利用実態を棚卸しするのが現実的です。(Microsoft Learn)
今回の「AI governance with Unity AI Gateway – Azure Databricks」は、単なる UI 追加ではありません。モデル、エージェント、MCP サーバー、外部 AI サービスへのリクエストを、アクセス権・レート制限・予算・ガードレール・監査ログの観点で統制するための管理基盤です。グローバルに Azure Databricks を使っている組織では、開発者が使う生成 AI、コーディングエージェント、外部 LLM プロバイダー、業務データに触れるツール呼び出しをまとめて見直すタイミングです。(Microsoft Learn)
Azure Databricks の Unity AI Gateway は何が変わったのか
Unity AI Gateway は、Azure Databricks におけるエンタープライズ AI ガバナンスの中核として位置付けられています。公式ドキュメントでは、Unity Catalog を基盤に、データや AI 資産だけでなく、モデル、エージェント、MCP サーバー、ツール間の実行時のやり取りまで統制対象を広げる仕組みとして説明されています。(Microsoft Learn)
従来の AI Gateway は、主に model serving endpoint に対して、使用状況追跡、ペイロードログ、レート制限、ガードレールなどを設定する考え方でした。一方、新しい Unity AI Gateway は、Azure Databricks の UI サイドバーに表示される新しい体験で、Unity Catalog の securable object として AI サービスを管理し、モデルや MCP サービスへのアクセスをより統一的に扱います。(Microsoft Learn)
| 比較項目 | 従来の AI Gateway for serving endpoints | 新しい Unity AI Gateway |
|---|---|---|
| 主な管理対象 | Model serving endpoint | Model Service、MCP Service、エージェント、関数、接続など |
| ガバナンスの単位 | エンドポイント中心 | Unity Catalog の securable object 中心 |
| 権限管理 | エンドポイント権限や機能ごとの設定 | Unity Catalog の権限、ABAC、Service Policy と連携 |
| 主な目的 | 生成 AI エンドポイントの監視・保護 | AI サービス全体のアクセス、トラフィック、コスト、リスクを統制 |
| ステータス | 既存機能として継続利用可能 | Beta。アカウント管理者による Preview 有効化が必要 |
実務上の見方としては、「従来機能がすぐ廃止される」というより、「今後の AI ガバナンス設計では Unity AI Gateway を前提に検証を始めるべき」という受け止め方が適切です。従来ページでも、新しい Unity AI Gateway は LLM endpoint と coding agent を統制するための強化された企業向けコントロールプレーンとして案内されています。(Microsoft Learn)
更新ポイントの要点
Unity AI Gateway は Beta のため、まず Preview 管理を確認する
新しい Unity AI Gateway は Beta として提供されています。アカウント管理者は Azure Databricks の account console にある Previews ページから、この機能へのアクセスを有効化できます。Beta 機能は一般提供前の段階であり、Databricks の Preview 管理ページでは、Private Preview や Beta は本番利用を意図したものではなく、SLA や正式サポートの対象外で、予告なく変更または中止される可能性があると説明されています。(Microsoft Learn)
そのため、管理者が最初に確認すべきことは「機能をオンにできるか」ではなく、「どのワークスペース、どのチーム、どのユースケースで検証するか」です。特に金融、医療、公共、個人情報を扱う業務では、Beta 機能に依存した本番統制を設計する前に、契約条件、サポート範囲、内部監査要件を確認してください。
Unity Catalog が AI ガバナンスの土台になる
Unity AI Gateway では、AI に関係する資産を Unity Catalog の管理対象として扱います。公式情報では、モデル、MCP tools、エージェント、HTTP connections、Unity Catalog functions が管理対象として挙げられています。つまり、従来の「データテーブルへのアクセス制御」と同じ発想で、「どのユーザーやサービスプリンシパルが、どの AI サービスを呼び出せるか」を管理する方向に変わります。(Microsoft Learn)
これは、AI 活用が広がった組織ほど重要です。たとえば、開発チームが GitHub 連携の MCP サービスを使い、営業部門が外部 LLM を使い、データ分析チームが Foundation Model API を使う場合、それぞれ別々の設定画面で統制すると抜け漏れが起きやすくなります。Unity Catalog を起点にすれば、AI 資産をカタログ、スキーマ、サービス単位で整理し、権限付与や取り消しを標準化できます。
モデル、MCP、コーディングエージェントまで統制対象が広がる
公式の Get started ページでは、Unity AI Gateway が model request と MCP request をルーティングし、レート制限、コスト制御、Service Policy、使用状況記録を担う AI のコントロールプレーンとして説明されています。対象は Azure Databricks-hosted のリソースだけではなく、OpenAI、Anthropic、Google などの外部モデル、Claude Code、Cursor、Codex、Gemini CLI などの外部コーディングエージェント、外部 MCP サーバーにも及びます。(Microsoft Learn)
ここでのポイントは、AI ガバナンスの対象が「モデルを呼び出すアプリ」だけではなく、「エージェントがユーザーの代わりに外部ツールを操作する場面」にまで広がることです。たとえば、コーディングエージェントが GitHub の MCP ツールを呼び出す場合、単にモデルへのアクセス権だけでなく、リポジトリ操作、コード変更、外部 API 呼び出しの承認ルールまで考える必要があります。
Service Policy でリクエストとレスポンスの中身を制御できる
Service Policy は、AI サービスとのやり取りの内容を制御する仕組みです。Unity Catalog の権限が「その principal はサービスを呼び出せるか」を判断するのに対し、Service Policy は「そのリクエストやレスポンスを許可するか、拒否するか、承認待ちにするか」を判断します。公式ドキュメントでは、ALLOW、DENY、ASK の3つの判断結果が示されています。(Microsoft Learn)
たとえば、個人情報を含むプロンプトをブロックする、危険な内容を含むレスポンスを返さない、破壊的な MCP ツール呼び出しだけ人間の承認を必要にする、といった設計が可能です。組み込みポリシーとして、PII ブロック、unsafe content ブロック、jailbreak ブロック、hallucination ブロックが用意されています。(Microsoft Learn)
ただし、Beta 時点の制限も重要です。Service Policy はリクエストやレスポンスの内容を変換するものではなく、判断を返す仕組みです。また、Beta 期間中に Service Policy を適用できる対象は MCP Services と Model Services に限られ、Model Provider Services と Agent Services は現在サポート対象外とされています。(Microsoft Learn)
影響範囲：どの管理者・チームが確認すべきか
今回の更新は、Azure Databricks の一部機能だけを使っているチームよりも、複数部門で生成 AI、外部 LLM、MCP、エージェントを使い始めている組織に大きく影響します。特に以下の担当者は確認が必要です。
| 対象者 | 確認すべき内容 | 実務上の注意点 |
|---|---|---|
| Azure Databricks アカウント管理者 | Preview 有効化、対象ワークスペース、リージョン | Beta 機能を全社本番に一斉適用しない |
| ワークスペース管理者 | Unity Catalog 有効化、権限設計、AI Gateway UI | 既存の endpoint 権限と新しい Model Service 権限を混同しない |
| ML/AI プラットフォーム担当 | Model Service、外部モデル、フォールバック、レート制限 | モデル切り替え時の品質・コスト・ログを検証する |
| セキュリティ・コンプライアンス担当 | Service Policy、PII、prompt injection、監査ログ | ログに機密情報が残る前提で保存先と権限を設計する |
| FinOps 担当 | 予算、使用量、タグ、ユーザー別コスト | 予算アラートだけでなく使用ブロックやレート制限も組み合わせる |
| 開発者・データサイエンティスト | コーディングエージェント、MCP、外部 API 利用 | 個人で直接外部 AI を呼ぶ経路を残すと統制が迂回される |
特にグローバル企業では、リージョンごとの利用可否を先に確認してください。公式のリージョン対応表では、Model Serving 関連機能の表に Unity AI Gateway の列があり、Japan East はサポート対象として表示されています。一方、Japan West は同表でサポート対象としてマークされていません。リージョン対応は変わる可能性があるため、導入前に最新の公式表を確認する必要があります。(Microsoft Learn)
設定変更：管理者が最初に確認する手順
Preview を有効化する前に対象ユースケースを決める
最初に行うべきことは、account console の Previews で Unity AI Gateway を有効化できるか確認することです。ただし、いきなり本番ワークスペース全体で使うのではなく、検証対象を絞るのが安全です。たとえば、次のように段階を分けると失敗しにくくなります。
| フェーズ | 対象 | 目的 |
|---|---|---|
| 検証 | 管理者・ML プラットフォーム担当のみ | UI、権限、ログ、Service Policy の挙動確認 |
| 限定展開 | 1〜2チームの社内 AI ユースケース | レート制限、予算、モデル切り替えの実運用確認 |
| 拡大展開 | 複数部門の AI アプリ、MCP、エージェント | 標準ルール、監査、コスト管理の横展開 |
Beta 機能は変更される可能性があるため、Terraform、CI/CD、社内標準手順書へ組み込む場合も、Preview 依存部分を明確に分けておくべきです。
Unity Catalog と権限を確認する
Model Service を作成するには、Unity AI Gateway Preview の有効化、サポート対象リージョンの Azure Databricks ワークスペース、Unity Catalog の有効化が必要です。さらに、作成者には USE CATALOG、USE SCHEMA、CREATE SERVICE、参照先モデルへの EXECUTE などの権限が必要です。推論ログを有効にする場合は、ログテーブルを作成するカタログとスキーマに対する CREATE TABLE も必要になります。(Microsoft Learn)
権限設計では、「AI を使う権限」と「AI のログを見る権限」を分けて考えることが重要です。たとえば、利用者には Model Service の EXECUTE だけを付与し、推論ログテーブルの SELECT は監査担当や運用担当に限定する、といった設計が考えられます。
GRANT USE CATALOG ON CATALOG main TO ai_team;
GRANT USE SCHEMA ON SCHEMA main.default TO ai_team;
GRANT EXECUTE ON MODEL SERVICE main.default.team_chat TO ai_team;
-- 推論ログを監査チームだけに見せる例
GRANT SELECT ON TABLE main.logging.team_chat_payload TO audit_team;このように、開発者が「使える」状態と、監査担当が「確認できる」状態を分離しておくと、ログに機密情報が含まれる可能性がある場合でも権限を絞りやすくなります。
レート制限で暴走と過負荷を抑える
Unity AI Gateway のレート制限では、Model Service に対して QPM と TPM、MCP Service に対して QPM を設定できます。サービス全体、デフォルトのユーザー単位、個別ユーザーやサービスプリンシパル、グループ単位のカスタムレート制限を定義できます。既定ではレート制限は設定されていません。(Microsoft Learn)
実務では、まずサービス全体の上限を置き、そのうえでユーザー単位の上限を設定するのが分かりやすい設計です。たとえば、社内チャットボットはサービス全体で急増を抑え、開発者向けコーディングエージェントはユーザー単位で上限を設ける、といった分け方です。
注意点として、レート制限を超えた場合は HTTP 429 が返ります。クライアント側では指数バックオフを使ったリトライ処理を実装する必要があります。また、低遅延を優先する設計のため、同時リクエストが一時的に設定値を少し超えることがあります。長期的には設定したレートに収束する、と理解しておくと運用時に混乱しにくくなります。(Microsoft Learn)
トラフィック分割とフォールバックでモデル依存を下げる
Unity AI Gateway では、Model Service の背後に複数のモデルバックエンドを置き、トラフィックを割合で分割できます。新モデルの段階的なロールアウト、A/B テスト、複数プロバイダーへの負荷分散に利用できます。フォールバックを組み合わせると、最初のリクエストが 429 や 5xx で失敗した場合に、指定した順番で別の宛先へ再試行できます。(Microsoft Learn)
ここで失敗しやすいのは、トラフィック分割を「可用性対策」として過信することです。トラフィック分割は最初にどの宛先へ送るかを決める仕組みで、失敗時の再試行順序はフォールバックで決まります。公式情報でも、トラフィック分割とフォールバックは別の段階で適用されると説明されています。(Microsoft Learn)
また、トラフィック分割は最大5つの宛先までで、フォールバック宛先に対してさらにトラフィック分割を設定することはできません。モデル切り替えを設計する際は、品質評価、コスト、レイテンシ、障害時の順序を事前に決めておく必要があります。(Microsoft Learn)
予算管理は Unity AI Gateway 本体とは分けて理解する
Unity AI Gateway にはコスト管理の観点もあります。公式の概要ページでは、モデルや MCP サービスに対する予算、ユーザー別しきい値、hard cap により、予算到達後にリクエストを止める管理が示されています。(Microsoft Learn)
一方で、予算機能のステータスは Unity AI Gateway 本体と完全に同じではありません。Databricks の今後の変更情報では、Unity AI Gateway budgets は 2026年7月に GA 予定とされつつ、Unity AI Gateway 本体は Beta のままであり、予算機能へのアクセスが得られても Unity AI Gateway に自動登録されるわけではないと説明されています。(Microsoft Learn)
予算機能では、Unity AI Gateway を resource type として選び、pay-per-token と ai_query の推論費用を追跡できます。ただし、Provisioned throughput と external-model inference は現在 Unity AI Gateway budgets の追跡対象外とされています。外部モデルを多用している組織では、「Unity AI Gateway budgets だけで AI コスト全体を把握できる」と誤解しないようにしてください。(Microsoft Learn)
移行期限：現時点で強制移行日は明示されているか
2026年7月1日更新の公式ページを見る限り、新しい Unity AI Gateway への強制移行期限や、従来の AI Gateway for serving endpoints の廃止日は明示されていません。公式ページでは、新しい Unity AI Gateway は Beta として案内され、旧バージョンについては「previous version」として別ページが案内されています。(Microsoft Learn)
したがって、管理者が取るべき行動は「期限に追われて急いで移行する」ではありません。正しくは、既存の model serving endpoint で使っている AI Gateway 機能を棚卸しし、新しい Unity AI Gateway で置き換えるべき統制と、当面そのまま維持する統制を分けることです。
| 項目 | 現時点の判断 |
|---|---|
| 新 Unity AI Gateway の本番一斉移行 | Beta のため慎重に検証 |
| 旧 AI Gateway の即時廃止 | 公式ページ上では強制期限の明示なし |
| 予算管理 | 2026年7月に GA 予定の情報あり。ただし Unity AI Gateway 本体とは別扱い |
| 管理者の優先作業 | 既存 endpoint、外部モデル、MCP、エージェント利用の棚卸し |
特に、既存の serving endpoint にすでにガードレール、ペイロードログ、レート制限を設定している場合は、同じ設定名でも新しい Unity AI Gateway 側の Model Service や Service Policy と完全に同じ意味ではありません。移行時は、機能名ではなく「何を防ぎたいのか」「誰に何を許可するのか」「どのログを監査するのか」で対応表を作るべきです。
実務で使う判断基準
アクセス制御と Service Policy を混同しない
Unity AI Gateway を設計するうえで最も重要なのは、アクセス制御と Service Policy の役割を分けることです。Unity Catalog の権限は「その principal がサービスを呼び出せるか」を判断します。Service Policy は、呼び出しが許可された後に「そのリクエストやレスポンスを通してよいか」を判断します。(Microsoft Learn)
たとえば、全社員向けチャットボットでは、社員グループに Model Service の EXECUTE を付与しつつ、Service Policy で個人情報を含むリクエストを拒否する設計が考えられます。開発者向けエージェントでは、GitHub MCP への読み取り系ツールは許可し、書き込みや削除につながるツール呼び出しは ASK にして人間の承認を挟む、といった設計が現実的です。
コスト対策はレート制限、予算、ログを組み合わせる
AI コストの暴走を防ぐには、単一の仕組みに依存しないことが重要です。レート制限は瞬間的な過負荷や使いすぎを抑え、予算は月次の支出監視やブロックに使い、使用量ログは原因分析に使います。
| 目的 | 主に使う機能 | 判断基準 |
|---|---|---|
| 短時間の大量リクエストを防ぐ | レート制限 | QPM、TPM、ユーザー別上限を設定 |
| 月次予算を超えないようにする | Budgets | チーム、ワークスペース、タグ、ユーザー単位で追跡 |
| 高コストユーザーを特定する | system tables、usage table | requester、service、tag、token 数を分析 |
| 外部モデル費用を見直す | モデル別ログ、外部請求情報 | Unity AI Gateway budgets の対象外コストも別途確認 |
予算タグを使う場合は、タグ名や値に機密情報を入れないでください。公式ドキュメントでは、タグデータはプレーンテキストで保存され、グローバルに複製される可能性があるため、セキュリティを損なう名前や値を使わないよう警告されています。(Microsoft Learn)
監査ログは「取る」だけでなく「誰が見られるか」まで設計する
Unity AI Gateway では、使用状況、コスト、リスクを追跡できます。公式情報では、モデルサービスのリクエスト、トークン使用量、レイテンシを system tables で追跡し、コストをサービス、対象モデル、principal、tag に紐付けて分析し、リクエストとレスポンスを Unity Catalog の Delta テーブルへ記録できると説明されています。(Microsoft Learn)
ただし、推論ログにはユーザーの入力やモデルの応答が含まれる可能性があります。個人情報、社内機密、顧客データが入るユースケースでは、ログ保存先のカタログ、スキーマ、テーブル権限、保持期間、マスキング要件を事前に決める必要があります。ログを有効にしただけで安心せず、監査担当者が必要なときに検索でき、一般利用者からは見えない状態を作ることが重要です。
グローバル展開で注意すべきポイント
リージョン対応を必ず確認する
Unity AI Gateway は、すべての Azure リージョンで同じように使えるとは限りません。公式の機能別リージョン対応表では、Model Serving 関連機能の一部として Unity AI Gateway の対応状況が整理されています。日本では Japan East が対応として示されている一方、Japan West は同表で対応としてマークされていません。(Microsoft Learn)
グローバル組織では、米国、欧州、日本、アジア太平洋などで同じ設計をそのまま適用できるとは限りません。ワークスペースの作成リージョン、データ所在地、外部モデルプロバイダーの処理地域、cross-Geo processing の要否を確認したうえで、地域ごとの標準構成を用意してください。
外部モデルと MCP は契約・データ移転の確認が必要
Unity AI Gateway は、Azure Databricks-hosted のモデルだけでなく、外部モデルや外部 MCP サーバーも統制できます。ただし、統制できることと、データを送ってよいことは別問題です。外部プロバイダーへプロンプトやコンテキストを送る場合、データ処理契約、データ所在地、サブプロセッサ、ログ保持、学習利用の有無を確認する必要があります。
特に MCP は、AI エージェントが外部サービスの操作を行う入口になり得ます。Google Drive、Jira、Slack、GitHub のような業務ツールと接続する場合、読み取りだけでなく、書き込み、削除、公開、通知送信などの操作が含まれる可能性を前提に、ツール単位の許可・拒否・承認フローを設計してください。
Beta 機能を社内標準に組み込む場合は逃げ道を残す
Beta 機能は変更される可能性があります。社内標準として Unity AI Gateway を採用する場合でも、アプリケーション側の設定、モデル呼び出し経路、MCP 接続、CI/CD の定義を固定しすぎないことが大切です。たとえば、検証段階では次のような方針にするとリスクを下げられます。
| 設計項目 | 推奨方針 |
|---|---|
| モデル呼び出し | 直接プロバイダーを呼ばず、Model Service 経由に寄せる |
| 権限 | 個人単位ではなくグループ単位を基本にする |
| ポリシー | まず組み込み Service Policy から使い、カスタムは段階導入 |
| コスト | レート制限と予算を両方設定する |
| ログ | 検証時から本番相当の保存先と権限で試す |
| 退避策 | 既存 endpoint の設定と新 Gateway の設定を対応表で管理する |
管理者向けチェックリスト
Unity AI Gateway の更新内容を確認したら、次の順番で作業すると抜け漏れを減らせます。
| チェック項目 | 確認内容 | 優先度 |
|---|---|---|
| Preview の有効化可否 | account console の Previews で Unity AI Gateway と Service Policy を確認 | 高 |
| 対象リージョン | ワークスペースが Unity AI Gateway 対応リージョンか確認 | 高 |
| Unity Catalog | 対象ワークスペースで Unity Catalog が有効か確認 | 高 |
| 既存 AI 利用の棚卸し | serving endpoint、外部モデル、MCP、エージェント利用を一覧化 | 高 |
| 権限設計 | EXECUTE、MANAGE、CREATE SERVICE、ログテーブルの SELECT を整理 | 高 |
| Service Policy | PII、unsafe content、jailbreak、hallucination、承認フローを検討 | 中 |
| レート制限 | サービス全体、ユーザー単位、グループ単位の上限を決める | 中 |
| 予算 | Unity AI Gateway budgets の対象範囲と対象外コストを確認 | 中 |
| 監査ログ | system tables、inference tables、保存期間、閲覧権限を設計 | 高 |
| 移行計画 | 旧 AI Gateway 設定と新 Unity AI Gateway 設定の対応表を作成 | 中 |
最初の検証対象としては、「社内利用の1つの Model Service」「限定された開発者グループ」「PII ブロックの Service Policy」「ユーザー単位のレート制限」「推論ログの確認」までを1セットにするのがおすすめです。これにより、アクセス制御、コンテンツ制御、コスト制御、監査の基本動作を短期間で確認できます。
まとめ：期限よりも先に、AI 利用経路の棚卸しを始める
Azure Databricks の「AI governance with Unity AI Gateway」は、AI 活用を広げるための機能であると同時に、無秩序な外部モデル利用、エージェントの過剰権限、予期しないコスト増、監査不能なプロンプト送信を防ぐための管理基盤です。2026年7月1日時点では新しい Unity AI Gateway は Beta であり、従来 AI Gateway からの強制移行期限は明示されていません。だからこそ、期限を待つのではなく、今ある AI 利用経路を棚卸しし、Unity Catalog の権限、Service Policy、レート制限、予算、ログをどう組み合わせるかを検証することが重要です。
管理者が次に取るべき行動は明確です。まず、対象ワークスペースのリージョンと Unity Catalog の状態を確認します。次に、既存の model serving endpoint、外部 LLM、MCP、コーディングエージェントの利用状況を一覧化します。そのうえで、小さな検証用 Model Service を作り、権限、Service Policy、レート制限、ログ、予算管理を一通り試してください。Unity AI Gateway は、AI を止めるための仕組みではなく、安全に使える範囲を明確にするための仕組みとして設計するのが成功のポイントです。
コメント