Unity CatalogでAIエージェントを大規模にガバナンスする

1年前、あなたの組織には十数個のAIエージェントがあったでしょう。今では数千個になっているかもしれません。すべての開発者にはコードを書き、レビューし、出荷するコーディングエージェントがいます。分析チームは予測エージェントを構築し、営業部門はリードスコアリングを導入し、サポート組織はチケットルーティングを自動化し、マーケティングはパーソナライゼーションを開始し、財務は照合ワークフローを構築しました。各チームはチャンスを見て迅速に行動しました。

今、誰かが「どのエージェントが顧客PIIにアクセスしているのか？」と尋ねます。答えを得るには、多数のシステムからログを収集し、手動で関連付け、何も見逃していないことを願う必要があります。各エージェントは異なる方法でログ記録、認証、データアクセスを行います。一元的に確認できる場所はありません。あるいは、逆の道を選んだかもしれません。すべてをロックダウンし、エージェントは広範なレビューなしにはデプロイされませんでした。セキュリティは厳格に保たれましたが、競合他社より6ヶ月遅れをとっています。開発者やユーザーは不満を感じ、中にはAIツールを実際に使える企業に移った人もいます。

どちらの極端も機能しません。ガバナンスのないエージェントは測定不能なリスクを生み出します。ロックダウンされた環境は別の種類のリスク、すなわち人材の流出と競争力の低下を引き起こします。従来のガバナンスは、人間が意思決定を行い、アプリケーションがそれを予測可能に実行することを前提としていました。エージェントはそうではありません。自律的で、毎回異なる選択をし、コードを読んでは予測できない方法でツールを連鎖させます。エージェントが何をするかをレビューしてガバナンスすることはできません。アクセスできるものを制御し、実際に何をするかを監視することでガバナンスするのです。

エージェントガバナンスの4つの柱

Unity Catalogは2021年から、統一された権限モデル、統一された系統、およびすべての資産にわたる一貫した監査証跡を通じてエンタープライズデータをガバナンスしてきました。現在、同じガバナンスインフラストラクチャをAIシステムが触れるすべての資産（LLM、MCPサーバー、スキル、エージェント）に拡張しています。顧客データに誰がアクセスできるかをすでに把握しているカタログが、どのエージェントがどのツールをどのような条件で呼び出せるかも管理します。

Unity AI Gatewayは、エージェントの世界における執行ファブリックです。すべてのモデル呼び出し、すべてのツール呼び出し、すべてのエージェントインタラクションがゲートウェイを通過します。それぞれが実行前にUnity Catalogで定義されたポリシーに対して評価され、実行後にログ記録されます。従来のガバナンスツールは静的アプリケーション向けに構築されており、これらを一切可視化できません。Unity AI Gatewayはそれが可能です。

柱1：委任アクセス

エージェントは、明確に定義された権限境界内で動作する必要があります。つまり、誰に代わって行動できるか、何にアクセスできるかです。ほとんどのプラットフォームは、静的資格情報と広範なアクセスを持つサービスアカウントを使用して、アプリケーション権限と同じように扱います。これでは説明責任が失われ、爆発半径を封じ込められません。Databricksは異なるアプローチを取ります。質問をするユーザーからエージェントが取得する特定のテーブル行まで、アイデンティティがエンドツーエンドで流れます。エージェントは、共有サービスアカウントではなく、リアルタイムのオンビハーフトークン受け渡しを介して呼び出しユーザーのデータ権限を継承します。Unity Catalogのテーブルにアクセスできない場合、あなたに代わって行動するエージェントもアクセスできません。すべてのアクションは、リクエストをトリガーした実際のユーザーと代わりに行動したエージェントの両方のIDでログ記録され、どのテーブルにアクセスしたか、どの操作が実行されたか、いつ発生したかがキャプチャされます。

このモデルをMCPサーバーに拡張します。チームは外部MCPサーバー（GitHub、Jira、Slackなど）をUnity Catalogに登録し、他のセキュア可能オブジェクトと同様にガバナンスします：権限、資格情報管理、一元化された監査ログ。また、同じ原則がアクセス時だけでなく実行時にも適用されることを認識しました。エージェントがGitHubを呼び出せることを知っていても、ファイルを削除したりプルリクエストをマージしたりすべきかはわかりません。そこで、サービスポリシーを構築しました。これはUC関数であり、UCで管理され、Unity Catalogの登録MCPにアタッチされて、どのツール呼び出しが成功するかを制御します。各ツール呼び出しは実行前に評価されます。ツール名、引数、呼び出し元のIDに基づいて、ポリシーは許可、拒否、またはユーザーの同意を求めます。

モデル層では、ガードレールが推論を流れる内容をリアルタイムで検査し、入力でPIIや脱獄試行をスキャンし、出力で幻覚や機密コンテンツをユーザーに届く前にチェックします。これらはすべてのリクエストでインライン実行され、フェイルクローズします。権限は誰が何を呼び出せるかを制御し、サービスポリシーは特定のツール呼び出しが特定のリクエストのコンテキストで進行すべきかを制御し、ガードレールは何が流入および流出するかを制御します。

柱2：データ中心のAIガバナンス

ほとんどのAIガバナンスツールが見落としている原則があります：エージェントの動作はほぼ完全にアクセスできるデータによって決定されます。何を読み取れるか、そのデータがどの程度新しいか、機密フィールドがマスクされているかどうか、これらはAIガバナンスの問題ではなく、データガバナンスの問題です。これらを別々に扱うと、2つの不完全なシステムになってしまいます。一緒に扱うと、ガバナンスは自己強化されます。

まず、完全な監査証跡が必要です。規制によりこれは必須になりつつあります。新興のAI規制では、組織はAIシステムが何をしたか、何を与えられたか、何を生成したかを実証することが求められます。AI Gatewayはすべてのモデル呼び出しの完全なペイロードを推論テーブルに書き込みます：送信された正確なプロンプト、返された正確な応答、トークン数、レイテンシ。Unity Catalogは監査ログで全てのアクセス操作をキャプチャします：どのプリンシパルが何を、どのエージェントから、いつ呼び出したか。両方がテーブルとしてレイクハウスに格納され、お客様の条件で保持できます。

次に、監査データは分析できて初めて有用です。分析にはログツールではなくデータプラットフォームが必要です。エージェントトレースはUnity Catalog内のテーブルであり、他のすべてに使用するのと同じSQLでクエリ可能です。新しいクエリ言語も別のツールも必要ありません。

第三に、エージェントが依存したデータがそもそも信頼できるものであったことを知る必要があります。データ品質モニタリングは、カタログ全体の鮮度と完全性を継続的に追跡します。それをエージェントトレースと結合すると、「エージェントが間違った答えを出した」から「エージェントが古いとフラグが立ったテーブルをクエリした」へと進み、エージェントの動作をその下にあるデータの品質に結びつけることができます。データ分類はさらにレイヤーを追加します：AIシステムが機密列（PII、HIPAA、GDPR規制データなど）を継続的にスキャンしてタグ付けし、これらのタグはアクセス制御に直接フィードバックされます。どのエージェントやフレームワークが要求しても、マスクされた列はマスクされたままです。すでにあるデータガバナンスが自動的にAIガバナンスになります。

柱3：コストインテリジェンス

すべてのモデル呼び出しにはコストがかかります。ほとんどの企業は、誰がどのような目的でコストを積み上げているのか、それが機能しているのかどうかを、請求書が届くまで知りません。根本原因は、プロセスが壊れていることではなく、インフラが不足していることです：すべてのAIトラフィックを一元的に把握するメータリングレイヤー、チームやユースケースに帰属させるタグ付けシステム、同じリソースを管理するアクセス制御と並ぶ支出制御がないことです。

これをUnity CatalogとUnity AI Gatewayに組み込みました。使用状況追跡は、トークン数、レイテンシ、リクエスターID、モデル宛先を含むすべてのリクエストを単一のテーブルの使用状況テーブルに記録します。チーム、プロジェクト、コストセンターでリクエストにタグを付けることができます。エージェントトレースやビジネスデータと並んでテーブルとして格納されるため、コストと成果を結びつけることができます。

Unity AI Gatewayの予算はポリシーレイヤーを追加します。管理者はユーザーまたはグループごとに月間支出しきい値を設定し、消費が近づいたり超えたりしたときにアラートを受け取ります。ハードな執行は自然な次のステップです。

柱4：オープンで相互運用可能

すべてのエンタープライズAIガバナンス戦略は、最終的に同じ駆動力に直面します：新しいチームが別のフレームワークを選び、新しいプロバイダーがより良いモデルをリリースする。ガバナンスが今日のツールの選択に組み込まれている場合、あなたはトレッドミルの上にいます：新しいフレームワークごとに新しい統合、新しいモデルごとに新しいポリシーが必要です。

私たちはこれを認識し、ほとんどのガバナンスツールとは異なるアプローチを取りました。ガバナンスはエージェント層だけに存在するのではなく、エージェントがアクセスするデータやサービスにも存在する必要があります。それらのサービスがDatabricks管理かどうかは関係ありません。LangGraph上に構築されたエージェントもCrewAI上に構築されたエージェントも、同じUnity Catalogをクエリし、同じガバナンスされたMCPサーバーを呼び出し、同じAI Gatewayを通過します。フレームワークは無関係です。ガバナンスはコードではなくリソースとともに移動します。

オープンスタンダードがこれを具体化します。MCPはエージェントに普遍的なツール接続プロトコルを提供します：Unity Catalogに一度登録すれば、同じ権限と監査証跡で任意のフレームワークから呼び出せます。Unity AI Gatewayは、Databricksホストモデル、Azure OpenAI、AWS Bedrock、Anthropicのための単一のガバナンスされたエンドポイントを提供し、プロバイダー間で一貫したポリシー、監査証跡、コスト帰属レイヤーを実現します。MLflowトレーシングは、LangChain、LlamaIndex、AutoGen、OpenAI SDK、Anthropic SDKなどを自動インストルメント化し、トレースをUnity Catalogのテーブルとしてフレームワークごとのカスタムインストルメンテーションなしで格納します。

最終結果として、ガバナンスはプラットフォームのプロパティとなり、新しいフレームワークやモデルごとに再構築する必要がなくなります。デプロイするすべてのエージェントは、どのように構築され、どのモデルで動作するかに関係なく、同じガバナンスされたリソースにアクセスします。