サービスポリシーを作成してアタッチする

備考

ベータ版

この機能はベータ版です。アカウント管理者は、アカウントコンソールの [プレビュー] ページからこの機能へのアクセスを制御できます。 Databricksのプレビューを管理するを参照してください。

サービスポリシーの概要については、AIセキュリティ可能オブジェクトのサービスポリシーを参照してください。

サービスポリシーを作成するには、SQL ポリシー関数を記述し、 Unity Gateway UIを通じてそれを MCP サービス、モデルサービス、またはモデルプロバイダーサービスにアタッチします。

ポリシーは、2つの評価ポイントで各インタラクションを管理します：

Databricksがサービスを呼び出す前の入力フェーズ（ON CALL）。
サービスが応答した後の出力フェーズ（ON RESULT）。

前提条件

アカウント管理者は、アカウントコンソールの プレビュー ページからアカウントでベータ版を有効にする必要があります。
ポリシー関数を作成するには: ターゲットスキーマに対する CREATE FUNCTION 権限。
サービスにポリシーをアタッチするには：ターゲットサービスのセキュリティ保護可能オブジェクトに対するMANAGE および ポリシー関数に対するEXECUTE 。

ステップ 1：ポリシー関数を記述します

サービスポリシー関数は、Unity Catalogに登録されているSQL UDFです。単一のVARIANTパラメーターであるevent（対話データとコンテキスト）を受け取り、VARIANTの結果を返します。

SQL
CREATE OR REPLACE FUNCTION <catalog>.<schema>.<function_name>(
  event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN <expression>;

この関数は両方の評価ポイントでランされます。単一のフェーズで動作させるには、event:type::stringでBranchします（入力フェーズの場合は'request'、出力フェーズの場合は'response'）。完全なeventフィールド、戻り値、およびサポートされているSQLサブセットについては、サービスポリシー関数リファレンスを参照してください。

意思決定ポリシーの作成

ディシジョンポリシーは、ALLOW、DENY、またはASKのresultフィールドとオプションのreasonを持つVARIANTを返します。結果をnamed_structで構築し、to_variant_objectで囲み、関数がVARIANTを返し、resultおよびreasonをトップレベルフィールドとして保持するようにします。

resultの値によって何が起こるかが決まります (大文字と小文字は区別されません)：

ALLOW：対話が進行します。
DENY：Databricksがインタラクションをブロックします。エラーの代わりに、呼び出し元は成功（HTTP 200）レスポンスを受け取ります。このレスポンスのアシスタントターンはブロックを報告し、最上位のdatabricks_service_policyオブジェクト内にreasonが含まれます。
ASK人間による承認が得られるまで一時停止します。

サポートされているSQLサブセットと、VARIANTを返すためのルールについては、サービスポリシー関数リファレンスを参照してください。

例: MCPサービスからのGitHubプッシュを拒否する

このポリシーは、push_filesツールへのあらゆる呼び出しをブロックし、それ以外のすべての操作を許可します。ポリシーが特定の MCP サービスにアタッチされているため、関数はツール名を確認するだけで済みます。

SQL
CREATE OR REPLACE FUNCTION main.governance.block_github_push(
  event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN
  CASE
    WHEN event:type::string = 'request'
      AND event:context.tool.name::string = 'push_files'
    THEN to_variant_object(named_struct('result', 'DENY', 'reason', 'GitHub push operations are not permitted by policy.'))
    ELSE to_variant_object(named_struct('result', 'ALLOW', 'reason', ''))
  END;

例：破壊的なツールを実行する前に人の承認が必要です

このポリシーは、delete_repositoryツールへの呼び出しを、人間の承認のために一時停止し、他のすべてのインタラクションを許可します。

SQL
CREATE OR REPLACE FUNCTION main.governance.ask_before_repo_delete(
  event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN
  CASE
    WHEN event:context.tool.name::string = 'delete_repository'
    THEN to_variant_object(named_struct('result', 'ASK', 'reason', 'Deleting a repository requires human approval.'))
    ELSE to_variant_object(named_struct('result', 'ALLOW', 'reason', ''))
  END;

このポリシーがASKを返すと、Databricksは実行前に人間の承認を求めて呼び出しを停止します。

MCPサービスを呼び出す外部エージェントに対して、DatabricksはMCP URLモードの誘引を使用して承認決定を提供します。ユーザーは提供されたURLを開いて呼び出しを承認または拒否します。外部エージェントは、承認後に呼び出しを再試行する必要があります。外部エージェントでASKを使用するには、エージェントのMCPクライアントがMCPプロトコルバージョン2025-11-25以降をサポートしている必要があります。

MCPサービスの場合、ツール呼び出しを承認すると承認が1時間キャッシュされるため、その期間内に同じ呼び出しが再度促されることはありません。

ツール許可リスト、キーワードおよびトピックのブロック、プロンプト長の制限、応答チェック、LLM-as-a-judge分類器など、その他のカスタムポリシーについては、サービスポリシーの例を参照してください。

ステップ2：ポリシーをサービスにアタッチする

ベータ期間中は、 Unity Gateway UIを通じて、個々のMCPサービス、モデルサービス、またはモデルプロバイダーサービスにサービスポリシーをアタッチします。1つのサービスに複数のポリシーをアタッチできます。各アタッチメントには優先順位（ランク）があり、チェーンは最初のDENYで停止します。入力フェーズでは、ポリシーはランクの昇順（最も低いものが最初）で評価され、出力フェーズでは逆順で評価されます。

ポリシーをアタッチするには:

ワークスペースのサイドバーで、[ AI Gateway ] をクリックします。
管理するサービスを選択してください： モデル タブのモデルサービス、 プロバイダー タブのモデルプロバイダーサービス、または MCP タブのMCPサービス。
[ ポリシー ]タブを開き、[ 新しいポリシー ]をクリックします。
ポリシーの名前を入力します。
適用対象 で、ポリシーを適用するプリンシパルを選択します。デフォルトの すべてのアカウントユーザー は、全員に適用されます。
ガードレールタイプ で、ポリシーが実行する内容を選択してください。
- 安全でないコンテンツ や ジェイルブレイク などの組み込みガードレール。チェックをランする Evaluator model サービス (LLM ジャッジ) はあらかじめ選択されています。別のものを使用するには、 [詳細オプション] を展開して選択します (選択するモデルには CAN_QUERY が必要です)。
- カスタム : 「 カスタム関数 」をクリックし、次に「 関数の選択 」をクリックして、ステップ1で記述したSQL関数を選択します。
[Phase] で、ポリシーの実行場所（ 入力ガードレール （ON CALL、サービスが呼び出される前）、 出力ガードレール （ON RESULT、応答した後）、またはその両方）を選択します。フェーズの選択は、組み込みガードレールおよびカスタムの LLM-as-a-judge ポリシーに適用されます。一部の組み込みガードレールは、入力時のジェイルブレイク検出や出力時のハルシネーション検出など、1つのフェーズでのみ実行されます。 カスタム SQL 関数 には [Phase] 設定がありません。両方のフェーズで実行されるため、動作のスコープを設定するには関数本体でevent:typeにbranchします（ステップ1を参照）。
ランク を設定して評価順序を制御します。ランクが最も低いものがリクエストで最初に実行され、レスポンスで最後に実行されます。
「 ポリシーの作成 」をクリックします。

ポリシーはサービスの ポリシー タブに表示されます。ベータ期間中は、伝播のためにしばらく時間を置き、その後にテストしてください。

注記

ベータ期間中、ポリシーUIが変更される可能性があります。ラベルがこれらのステップと異なる場合は、製品内のラベルに従ってください。

組み込みポリシーを使用する

Databricks は、system.ai 名前空間の下で組み込みのサービスポリシー（安全でないまたは有害なコンテンツをブロックする system.ai.block_unsafe_content など）を提供します。使用するには、ステップ 2 に従いますが、 ガードレールタイプ で カスタム の代わりに組み込みのガードレールを選択します。組み込みのガードレールには、ポリシー固有の構成は必要ありません。それらをアタッチする際には、標準の Phase 、 Rank 、 Evaluator model service 、および Mode フィールドを設定します。

組み込みポリシーの全リストと、それらが Unity Catalog にどのように表示されるかについての注記については、組み込みサービスポリシーを参照してください。

組み込みのポリシー関数に対してEXECUTE権限が、ターゲットサービスに対してMANAGE権限が必要です。

ポリシーを確認する

ポリシーをアタッチした後、それがアクティブであり、期待される結果を生成していることを確認してください。

注記

ポリシーをアタッチまたは変更した後、テストする前に変更が有効になるまでしばらくお待ちください。ベータ期間中、ポリシーの変更が反映されるまでに1、2分かかる場合があります。

アタッチの確認

Unity Gateway でターゲットサービスを開き、アタッチされているポリシーを表示します。作成したポリシーがリストに表示されます。

ポリシーの結果を監視する

ポリシーが有効になっていることを確認できます。

呼び出し元から : ポリシーが DENY を返すと、呼び出し元はエラーではなく成功（HTTP 200）レスポンスを受け取ります。アシスタントのターンでコンテンツがブロックされたことが報告され、最上位レベルの databricks_service_policy オブジェクトが指定した reason を保持します。ASK は、人間による承認のためにコールを一時停止します。
システムテーブル では、モデルと MCP アクティビティが使用状況テーブルに記録され、完全なリクエストとレスポンスのペイロードが推論テーブルに記録されます。

ポリシー決定のデバッグと監査

ポリシーがインタラクションをブロックすると、databricks_service_policy オブジェクト内のブロック reason がポリシー名を指定し、簡単な説明を表示します。ポリシーの結果を監視するを参照してください。

組み込みまたはカスタムの LLM-as-a-judge （LLM ジャッジ）による決定の背後にある完全な推論を確認するには（評価器の信頼度や、評価対象となった正確なコンテンツを含みます）、評価器モデルサービスの推論テーブルを確認してください。

LLM-as-a-judge ポリシーは、そのプロンプトを別の評価器モデルサービス（ジャッジ）上で実行します。ジャッジの判定は、保護対象サービスの推論テーブルには記録されません。このテーブルには、保護対象サービス自身の要求と応答のみがLogsされます。ジャッジの入力と判定は、 評価器 モデルサービスで推論テーブルが有効になっている場合にのみキャプチャされます。

評価者の判定をキャプチャする

チェックを実行するモデルサービスで推論テーブルを有効にします。次の 2 つのオプションがあります：

ガードレールが既に使用している評価器で、直接推論テーブルを有効にします。The default evaluator is a system.ai model サービスであり、その上で推論テーブルを有効にできます。
ポリシーをアタッチする際の 詳細オプション で、ガードレールを所有する評価用モデルサービスに向け（system.ai モデルである必要はありません）、そのサービスで推論テーブルを有効にします。

推論テーブルを有効にするには、推論テーブルへのリクエストと応答のLogsを参照してください。監査対象のインタラクションの前に有効にしてください。ログ記録が有効になった後に実行された評価のみがキャプチャされ、行が表示されるまでに数分かかる場合があります。

判定を読み取る

各評価は、フェーズごとのポリシーごとに1行を評価器の推論テーブルに書き込みます：

request は組み立てられたジャッジプロンプトです。これには、ポリシーの基準、 JSON 出力コントラクト、および <ContentToEvaluate> マーカーでラップされた評価対象のコンテンツが含まれます。マルチターン（会話ウィンドウ）入力ポリシーの場合、評価されるコンテンツは直近のやり取りと最新の入力の合計です。それ以外の場合は、単一のメッセージとなります。
response は、評価者の生の完了結果です。判定はアシスタントのメッセージ内容であり、flagged、confidence、および flagged が true の場合は reason を含む JSON オブジェクトです。
destination_name は評価器を識別し、request_id は評価をそれをTriggerしたインタラクションに関連付けます。

ジャッジがコンテンツにフラグを設定した評価を見つけるには、評価器の推論テーブルを評決でフィルタリングします：

SQL
SELECT
  event_time,
  request_id,
  get_json_object(response, '$.choices[0].message.content') AS verdict,
  request
FROM <catalog>.<schema>.<evaluator_inference_table>
WHERE get_json_object(response, '$.choices[0].message.content') ILIKE '%"flagged":true%'
ORDER BY event_time DESC;

verdict 列には、{"flagged":true,"confidence":0.87,"reason":"..."} などの評価器の決定が表示されます。reason は、flagged が true の場合にのみ表示されます。フラグが立てられた判定は判定者の決定であり、インタラクションがブロックされたことの証明ではありません。 Log モードでは、実行されるはずだった DENY がここに記録されますが、強制はされず、テーブルにもモードは記録されないため、呼び出し元の databricks_service_policy 応答から実際のブロックを確認してください（ポリシーの結果の確認を参照してください）。代わりに特定のインタラクションを1つトレースするには、request_id でフィルターします。

注記

保護されたサービスではなく、評価器の推論テーブルからブロックを監査します。入力フェーズのポリシーがリクエストを拒否した場合、Databricks は基盤となるサービスを呼び出さないため、ブロックされたインタラクションは保護されたサービスの推論テーブルに行を生成しない可能性があります。したがって、保護されたテーブルからリクエストIDをソースすると、ブロックされたインタラクションが漏れてしまいます。代わりに、評価者のテーブルを判定（verdict）でフィルタリングしてください。

大きなテーブル内の1つのインタラクションに絞り込む

評価器の推論テーブルにはポリシー名列がなく、レスポンス本文 (chatcmpl-...) 内の id は request_id ではありません。これらのフィルターを使用してデバッグ中のインタラクションに絞り込み、スキャンを時間で制限します：

request_id （最も正確）：1つのインタラクションに対するすべての評価で共有されます。呼び出しの databricks-request-id 応答ヘッダーから取得し、WHERE request_id = '<id>' をフィルター処理します。これはブロックに対して機能します。応答本文の id フィールドは異なる値であるため、ヘッダー値が列と一致していることを確認してください。
リクエストコンテンツ : ジャッジの request に評価対象のコンテンツが保持されるため、プロンプト内の特徴的な文字列（例: request ILIKE '%<your marker>%'）を使用してインタラクションをピン留めします。
時間：event_time >= current_timestamp() - INTERVAL 30 MINUTESがスキャンを制限します。

どのポリシーが行を生成したかを確認するには、その request を読み取ります。システムメッセージはそのポリシーの基準であるため、フィルタリングしてポリシーを特定できます。たとえば、request ILIKE '%<distinctive phrase from the policy prompt>%' などです。判定内の reason は、通常Triggerを再記述します。

SQL
SELECT event_time, request_id, invocation_id,
       get_json_object(response, '$.choices[0].message.content') AS verdict,
       request
FROM <catalog>.<schema>.<evaluator_inference_table>
WHERE event_time >= current_timestamp() - INTERVAL 30 MINUTES
  AND request ILIKE '%<your marker or prompt text>%'
  AND get_json_object(response, '$.choices[0].message.content') ILIKE '%"flagged":true%'
ORDER BY event_time DESC;

非決定性とドライランテスト

評価者はモデルであるため、その判定は非決定論的です。同じ入力であってもランごとに異なる判定が返される可能性があり、異なる評価者モデル間や、リクエストのルーティングがモデルのバージョンにまたがる場合には、その変動はより大きくなります。reason は短いフリーテキストであり、エンティティごとの構造化データではありません。また、フラグが立てられたコンテンツを引用する場合があります。再現可能で決定論的なチェックを行うには、LLM ジャッジの代わりに、組み込みの Sensitive Data Detection ポリシーまたはカスタム SQL ポリシーを使用してください。

Databricks では、最初に Log モードで LLM-as-a-judge ポリシーをアタッチすることを推奨しています。これにより、評価者に推論テーブルを有効にした状態で、ブロックせずに判定を記録できます。実際のトラフィックに対する判定を調査し、プロンプトとランクを調整してから、ポリシーを Enforce （強制）に切り替えてください。Sensitive Data Detection は強制モードでのみ実行されます。

アクセス権

上記のステップには、以下の権限が必要です：

ステップ	必要なアクセス権
ガードレールをアタッチする	`MANAGE` ターゲット（保護対象）サービスに対する権限、およびアタッチするポリシー関数に対する `EXECUTE` が必要です。ステップ 2 を参照してください。
default以外の評価器を選択	`CAN_QUERY` 選択した評価モデルサービスに基づきます。
評価器で推論テーブルを有効にする	評価器モデルサービスを管理する権限（作成者である場合など）、およびテーブルが格納されているカタログとスキーマに対する `USE CATALOG`、`USE SCHEMA`、`CREATE TABLE` の権限。推論テーブルの前提条件を参照してください。
評価者の推論テーブルを読み取る	`SELECT` テーブル上の権限に加え、そのカタログおよびスキーマ上の`USE CATALOG`と`USE SCHEMA`。モデルサービスの作成者がテーブルを所有し、他のユーザーにアクセス権を付与します。

ステップ	必要なアクセス権
ガードレールをアタッチする	`MANAGE` ターゲット（保護対象）サービスに対する権限、およびアタッチするポリシー関数に対する `EXECUTE` が必要です。ステップ 2 を参照してください。
default以外の評価器を選択	`CAN_QUERY` 選択した評価モデルサービスに基づきます。
評価器で推論テーブルを有効にする	評価器モデルサービスを管理する権限（作成者である場合など）、およびテーブルが格納されているカタログとスキーマに対する `USE CATALOG`、`USE SCHEMA`、`CREATE TABLE` の権限。推論テーブルの前提条件を参照してください。
評価者の推論テーブルを読み取る	`SELECT` テーブル上の権限に加え、そのカタログおよびスキーマ上の`USE CATALOG`と`USE SCHEMA`。モデルサービスの作成者がテーブルを所有し、他のユーザーにアクセス権を付与します。

制限事項

ベータ版では、次の制限が適用されます:

変換 : サービスポリシーは決定 (ALLOW、DENY、またはASK) を返します。ベータ版では、リクエストまたはレスポンスのコンテンツは変換されません。
ポリシー言語 : カスタムポリシー関数はLANGUAGE SQLのみをサポートしています。
適用範囲 ：ポリシーの適用はUIのみであり、個々のサービスに限定されており、そのポリシーはすべてのアカウントユーザーに適用されます。カタログレベルまたはスキーマレベルでのポリシーの適用、属性ベースのアクセス制御 (ABAC) の条件、およびカスタムプリンシパルは利用できません。

前提条件​

ステップ 1：ポリシー関数を記述します​

意思決定ポリシーの作成​

ステップ2：ポリシーをサービスにアタッチする​

組み込みポリシーを使用する​

ポリシーを確認する​

アタッチの確認​

ポリシーの結果を監視する​

ポリシー決定のデバッグと監査​

評価者の判定をキャプチャする​

判定を読み取る​

大きなテーブル内の1つのインタラクションに絞り込む​

非決定性とドライランテスト​

アクセス権​

制限事項​