外部AIモデルの認証・費用・監査をUnity AI Gatewayへ集約

Databricksは、MetaのMuse Spark 1.1をモデル提供者サービス経由でUnity AI Gatewayへ登録し、外部モデルの認証情報、権限、費用、監査を集中管理する方法を紹介しました。

要点

• 外部モデル提供者をUnity Catalogの管理対象として一度登録し、利用者はDatabricksの認証情報で呼び出します。
• 提供者のAPIキーは暗号化して保管され、クライアントへ直接渡しません。
• EXECUTE、READ_METADATA、MANAGEなどの権限、レート制限、サービスポリシーをモデル提供者単位に適用できます。
• トークン、待ち時間、状態、外部モデル費用、要求・応答を記録できますが、プレビュー機能の有効化が必要です。

今回のブログ記事で語られていること

記事は、新モデルを公開初日から試したい開発チームと、APIキー、費用、権限、監査面が増えるたびに管理負担を抱える基盤チームの対立から始まります。チームごとにMetaのAPIキーを作り、ノートブック、アプリ、CI/CDへ複製すると、誰がどれだけ使ったか、どの入力が外部へ送られたか、どの部署が請求を増やしたかを一つの場所で追えません。Muse Spark 1.1は具体例ですが、記事の主題は新しい外部モデルを追加するたびに起きる管理の分散です。

モデル提供者サービスは、外部モデル提供者の接続設定とAPIキーを表すUnity Catalogの管理対象です。利用者はサービス名を指定し、自分のDatabricks認証情報でUnity AI Gatewayへ接続します。Gatewayが権限を確認した後に外部提供者のAPIキーを付与するため、利用者へキーを配布しません。キーはUnity Catalogの接続として暗号化され、公開するモデルとAPI面も許可リストで制限できます。Muse Spark 1.1はOpenAI Responses API互換なので、MetaのベースURL、モデル名、API種別を登録する例が示されています。

登録後は三つの価値を「Choice、Control、Clarity」と整理します。Choiceは提供者内のモデルを切り替え、OpenAI互換クライアントから評価できることです。ControlはGRANTとREVOKE、レート制限、サービスポリシーで利用者と要求内容を制御することです。Clarityはsystem.ai_gateway.usageでトークン、待ち時間、状態を、system.ai_gateway.external_model_spendで費用を追い、要求タグで案件別に配賦できることです。推論テーブルへ要求と応答を保存し、個人情報、プロンプトインジェクション、不適切内容のポリシーを外部送信前に適用する例も示します。この機能はAWS、Azure、GCPでプレビューとして有効化する必要があります。

背景にあるテーマ

複数モデルの採用速度が上がるほど、キーをチームへ配る方式ではアクセス制御と費用配賦が破綻しやすくなります。モデル選択の自由と、共通の認証・統制面を分離することが重要です。

今回のブログ記事が関係する人

Databricks管理者、AIプラットフォームチーム、外部モデルを評価する開発者、FinOps、セキュリティ・監査担当に関係します。

どう読むと価値があるか

Muse Spark 1.1の能力紹介ではなく、外部モデルを共通Gatewayへ載せる運用例として読むと有用です。要求・応答の保存は監査に役立つ一方、機密情報の複製にもなるため、保存内容と期間を別途設計する必要があります。

実務へのつながり

検証用提供者を一つ登録し、キーが利用者へ見えないこと、権限のないモデルが拒否されること、案件タグで費用を分けられること、ポリシー違反が外部送信前に止まることを確認します。

結局、今回のブログ記事をどう読むべきか

新モデルの採用を遅らせず、認証情報と統制を増殖させないための設計です。モデルの追加速度より、共通の権限・費用・監査面を保てるかが導入判断の中心です。