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

備考

ベータ版

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

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

You create a サービス policy and attach it to an MCP Service, Model Service, or Model Provider Service through the Unity Gateway UI.The policy governs each interaction at two evaluation points:

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

ポリシーの種類を選択する

ポリシーの種類	これを使用	お客様が提供する情報
組み込みのガードレール	安全でないコンテンツ、ジェイルブレイクの試み、ハルシネーション、機密データなどの一般的なリスク。	なし。ガードレールを選択してアタッチします。
カスタムLLM-as-a-judge	アシスタントをトピックに関連づけたままに保つなど、自然言語で記述できるセマンティックルール。	フラグを設定する対象を説明するプロンプト。
カスタム SQL 関数	ツール名、ツールの引数、呼び出し元の身元に関するチェックや、人間の承認のための呼び出しの保留（`ASK`）などの決定的ルール。	Unity Catalog に登録された SQL ユーザー定義関数 (UDF)。
外部	すでに使用しているサードパーティのガードレールベンダーの決定を適用します。	ベンダーのEndpointに対するUnity Catalog HTTP接続。

ポリシーの種類	これを使用	お客様が提供する情報
組み込みのガードレール	安全でないコンテンツ、ジェイルブレイクの試み、ハルシネーション、機密データなどの一般的なリスク。	なし。ガードレールを選択してアタッチします。
カスタムLLM-as-a-judge	アシスタントをトピックに関連づけたままに保つなど、自然言語で記述できるセマンティックルール。	フラグを設定する対象を説明するプロンプト。
カスタム SQL 関数	ツール名、ツールの引数、呼び出し元の身元に関するチェックや、人間の承認のための呼び出しの保留（`ASK`）などの決定的ルール。	Unity Catalog に登録された SQL ユーザー定義関数 (UDF)。
外部	すでに使用しているサードパーティのガードレールベンダーの決定を適用します。	ベンダーのEndpointに対するUnity Catalog HTTP接続。

リスクに対応できる組み込みのガードレールから起動します。どの組み込みでもカバーされないルールについては、カスタム LLM-as-a-judge ポリシーを使用するか、ルールが確定的である必要がある場合や呼び出し元に依存する場合は SQL 関数を使用します。

1つのサービスに複数のポリシーをアタッチできます。各アタッチメントには優先度（ランク）があり、特定のランクの DENY によって、それ以降のすべてのランクの評価が停止されます。入力フェーズでは、ランクは昇順（最も低いものが最初）で評価されます。出力フェーズでは、これらは逆順で評価されます。同じランクのポリシーは、いずれかのポリシーが拒否した後でもすべてランできます。評価順序をご覧ください。

前提条件

アカウント管理者は、アカウントコンソールの プレビュー ページからアカウントでベータ版を有効にする必要があります。
サービスに任意のポリシーをアタッチするには：ターゲットサービスのセキュリティ保護可能オブジェクトに対する MANAGE。
default 以外の評価者を使用する組み込みのガードレールまたはカスタムの LLM-as-a-judge ポリシーの場合: 選択した評価者モデルサービスでの EXECUTE、およびそのカタログとスキーマでの USE CATALOG と USE SCHEMA。モデルサービスへのアクセスの付与を参照してください。
カスタム SQL ポリシー：ポリシー関数を作成するためのターゲットスキーマに対する CREATE FUNCTION 権限、およびそれをアタッチするためのポリシー関数に対する EXECUTE。
外部サービスポリシーの場合: Unity Catalog HTTP 接続の USE CONNECTION。「始める前に」を参照してください。

注記

これらのステップとラベルが異なる場合は、製品内のラベルに従ってください。ポリシーはサービス上のすべてのアカウントユーザーに適用されるため、 Applied to は All account users に設定したままにします。

組み込みポリシーをアタッチする

Databricks は、安全でないまたは有害なコンテンツをブロックするための system.ai.block_unsafe_content など、system.ai 名前空間の下に組み込みサービスポリシーを提供します。コードなしで一般的なリスクに対応できます。組み込みポリシーの完全なリストと、それらが Unity Catalog にどのように表示されるかについての注記については、組み込みサービスポリシーを参照してください。

次のステップでは、 Unsafe Content ガードレールをサービスにアタッチします：

ワークスペースのサイドバーで、[ AI Gateway ] をクリックします。
管理するサービスを選択してください： モデル タブのモデルサービス、 プロバイダー タブのモデルプロバイダーサービス、または MCP タブのMCPサービス。
[ ポリシー ]タブを開き、[ 新しいポリシー ]をクリックします。
block_unsafe_contentなどのポリシーの名前を入力します。
ガードレールタイプ で、 Unsafe Content （安全ではないコンテンツ）や Jailbreak （脱獄）などの組み込みガードレールを選択します。
ランク を設定して評価順序を制御します。ランクが最も低いものがリクエストで最初に実行され、レスポンスで最後に実行されます。
[フェーズ] の下で、ポリシーの実行場所として、 [入力ガードレール] （ON CALL、サービスの呼び出し前）、 [出力ガードレール] （ON RESULT、応答後）、またはその両方を選択します。入力でのジェイルブレイク検出や出力での幻覚検出など、一部の組み込みガードレールは1つのフェーズのみで実行されます。
（オプション）モデルサービスまたはモデルプロバイダーサービスで、 会話ウィンドウ を設定します：判定がリクエストに対して評価する直近の会話のやり取りの数です。defaultで10回のやり取りに設定されています。1に設定すると、最新のメッセージのみが判定されます。または、 会話全体を評価 を選択します。
（オプション） 詳細オプション を展開します。チェックをランする 評価モデルサービス （LLMジャッジ）があらかじめ選択されています。別のものを使用するには、ここで選択してください。選択したモデルサービスにEXECUTE、そのカタログとスキーマにUSE CATALOGおよびUSE SCHEMAが必要です。違反結果をブロックせずに記録するには、 Mode を Log に設定します。
「 ポリシーの作成 」をクリックします。

ポリシーはサービスの ポリシー tabに表示されます。テストする前に、伝播が完了するまでしばらくお待ちください。

組み込みのガードレールには、ポリシー固有の構成は必要ありません。標準の Phase 、 Rank 、 Evaluator model サービス 、および Mode フィールドのみを設定します。決定的 Sensitive Data Detection ガードレールは例外であり、分類タグとアクションも指定します。「サービスポリシーによる機密データの検出」を参照してください。

LLM-as-a-judge ポリシーを作成する

カスタム LLM ジャッジポリシーは、評価モデルを使用して、自然言語で記述した基準に対してリクエストまたはレスポンスを分類します。メッセージがトピック内にあるか、レスポンスがプロフェッショナルな状態を維持しているかなど、決定論的なルールでは表現できないセマンティックチェックに使用します。コードとしてではなく、プロンプトとして基準を記述します。

次のステップでは、サポートアシスタントをトピック内に維持するポリシーをアタッチします：

ワークスペースのサイドバーで、[ AI Gateway ] をクリックします。
管理するサービスを選択してください： モデル タブのモデルサービス、 プロバイダー タブのモデルプロバイダーサービス、または MCP タブのMCPサービス。
[ ポリシー ]タブを開き、[ 新しいポリシー ]をクリックします。
keep_on_topicなどのポリシーの名前を入力します。
ガードレールタイプ で、 カスタム を選択します。
ランク を設定して評価順序を制御します。ランクが最も低いものがリクエストで最初に実行され、レスポンスで最後に実行されます。
[Implementation] で、 [LLM-as-a-judge] を選択します。
フェーズ で、ポリシーが実行される場所を選択します： 入力ガードレール （ON CALL、サービスが呼び出される前）、 出力ガードレール （ON RESULT、応答後）、またはその両方。このようなトピックチェックは、入力に対して実行されます。
評価モデルサービス を選択します。選択したモデルサービスに対する EXECUTE と、そのカタログおよびスキーマに対する USE CATALOG および USE SCHEMA が必要です。
[プロンプト] で、評価者がフラグを立てるべき内容とそのままにするべき内容を説明します。例えば：

製品、注文、請求、およびアカウントのサポートのみを支援する顧客サポートアシスタントに送信されたメッセージを確認しています。一般的なコーディングのヘルプ、エッセイの執筆、関連のないトリビア、アシスタントの汎用チャットボットとしての使用など、その範囲外のことを求められた場合は、メッセージにフラグを立てます。本物の製品やサポートに関する質問にフラグを立てないでください。

プロンプトに ALLOW または DENY を記述せず、出力形式を指定しないでください。Databricksはプロンプトに構造化出力コントラクトを追加するため、評価器はJSONの判定結果を返します。評価器がコンテンツにフラグを設定すると、Databricksはインタラクションをブロックします。
（オプション）モデルサービスまたはモデルプロバイダーサービスで、 会話ウィンドウ を設定します：判定がリクエストに対して評価する、直近の会話のやり取りの数です。defaultでは10回のやり取りに設定されています。最新のメッセージのみを判定するには1に設定するか、 会話全体を評価 を選択します。ウィンドウは入力評価にのみ適用されます。
(オプション) プロンプトを調整している間、ブロックせずに判定を記録するには、 [詳細オプション] を展開し、 [Mode] を [Log] に設定します。
「 ポリシーの作成 」をクリックします。

ポリシーはサービスの ポリシー tabに表示されます。テストする前に、伝播が完了するまでしばらくお待ちください。

評価者はモデルであるため、その判定は非決定論的です。Databricks では、 Log モードで開始し、統合トレーステーブルで判定結果の候補を確認することを推奨しています。「Non-determinism and dry-run testing」を参照してください。その他のプロンプト、その作成のベストプラクティス、およびマルチターン（複数回のやり取り）の例については、LLM-as-a-judge ポリシー examples を参照してください。

SQLポリシーを作成する

カスタム SQL ポリシーとは、判定を返す SQL 関数です。ルールが決定論的でなければならない場合、ツールの名前や引数、呼び出し元に依存する場合、または人間の承認のために呼び出しを保留する必要がある場合（ASK）に使用します。

ステップ 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 フィールドを持つ VARIANT と、オプションの reason から成る決定を返します。named_struct を使用して結果を構築し、to_variant_object でラップすることで、関数が VARIANT を返し、result と reason をトップレベルのフィールドとして維持します。

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

ALLOW：対話が進行します。
DENY：Databricksがインタラクションをブロックします。エラーの代わりに、呼び出し元は成功（HTTP 200）レスポンスを受け取ります。このレスポンスのアシスタントターンはブロックを報告し、最上位のdatabricks_service_policyオブジェクト内にreasonが含まれます。
ASK：MCPサービスでは、ツールのラン前にユーザーの承認を得るため、リクエストが停止する。カスタムのSQLまたはPythonポリシーがモデルサービスまたはモデルプロバイダーサービスに対してASKを返す場合、これらのサービスではユーザーに承認を求めることができないため、Databricksはリクエストまたはレスポンスをブロックします。

例：エージェントがユーザーの代理でアクションを実行するときにGitHubプッシュを拒否する

すべての呼び出し元からツールを削除するには、サービスポリシーの代わりにツール選択を使用します。サービスポリシーは、呼び出し元によって決定が異なる場合に便利です。event:context.actor.context.is_on_behalf_ofによって報告されたように、このポリシーではユーザーが push_files ツールを直接呼び出すことは許可されますが、エージェントやアプリがユーザーに代わって呼び出す場合（代理呼び出し、または OBO）は拒否されます：

SQL
CREATE OR REPLACE FUNCTION main.governance.block_agent_github_push(
  event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN
  CASE
    WHEN event:type::string = 'request'
      AND event:context.tool.name::string = 'push_files'
      AND event:context.actor.context.is_on_behalf_of::boolean = true
    THEN to_variant_object(named_struct('result', 'DENY', 'reason', 'Agents cannot push to GitHub on behalf of a user. Push the change yourself.'))
    ELSE to_variant_object(named_struct('result', 'ALLOW', 'reason', ''))
  END;

すべてのアージェントをブロックするのではなく特定のエージェントを許可するには、エージェントのOAuth クライアント IDを確認してください。詳細は、機密ツールの承認済みエージェントへの制限を参照してください。アクターの全フィールド一覧については、サービス・ポリシー関数リファレンスを参照してください。

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

このポリシーは、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時間キャッシュされるため、その期間内に同じ呼び出しが再度促されることはありません。

ASK 入力フェーズでは、承認はMCPサービスでのみ利用できます。カスタムSQLまたはPythonポリシーがモデルサービスまたはモデルプロバイダーサービスのASKを返す場合、Databricksはこれらのサービスがユーザーに承認を求めることができないため、リクエストまたはレスポンスをブロックします。

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

ステップ 2: 関数をサービスにアタッチする

ワークスペースのサイドバーで、[ AI Gateway ] をクリックします。
管理するサービスを選択してください： モデル タブのモデルサービス、 プロバイダー タブのモデルプロバイダーサービス、または MCP タブのMCPサービス。
[ ポリシー ]タブを開き、[ 新しいポリシー ]をクリックします。
ポリシーの名前を入力します。
ガードレールタイプ で、 カスタム を選択します。
ランク を設定して評価順序を制御します。ランクが最も低いものがリクエストで最初に実行され、レスポンスで最後に実行されます。
[実装] で [カスタム関数] を選択し、 [関数の選択] をクリックしてステップ 1 で作成した SQL 関数を選択します。
「 ポリシーの作成 」をクリックします。

カスタム SQL 関数には Phase 設定がありません。両方のフェーズで実行されるため、動作のスコープを指定するには関数本体で event:type を指定して Branch させます（ステップ 1 を参照）。ポリシーはサービスの [ポリシー] tabに表示されます。伝播が完了するまでしばらく待ってからテストしてください。

外部のサービスポリシーをアタッチします

外部サービスポリシーは、評価対象のコンテンツをサードパーティのガードレールベンダーに送信し、ベンダーの ALLOW または DENY の判定を適用します。使用するには、サービスの ポリシー tabを開いて New policy をクリックし、 Guardrail type で External を選択して、ベンダーのエンドポイントへの Unity Catalog HTTP 接続を選択または作成します。他のポリシーと同様に、 Phase 、 Rank 、必要に応じて Policy configuration 、および Mode を設定します。

ターゲットサービスでMANAGEが、接続でUSE CONNECTIONが必要です。ポリシー関数は必要ありません。接続フィールド、ベンダーに送信されるコンテンツ、およびfail-closed動作を含む完全なセットアップについては、「外部サービスポリシーによるパートナーガードレールの適用」を参照してください。

ポリシーを確認する

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

注記

ポリシーをアタッチまたは変更した後は、変更が有効になるまで少し時間を置いてからテストしてください。ポリシーの変更が反映されるまでには、通常1〜2分かかります。

アタッチの確認

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

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

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

呼び出し元から : ポリシーが DENY を返すと、呼び出し元はエラーではなく成功（HTTP 200）レスポンスを受け取ります。アシスタントのターンでコンテンツがブロックされたことが報告され、最上位レベルの databricks_service_policy オブジェクトが指定した reason を保持します。ASK は、人間による承認のためにコールを一時停止します。
統合トレーステーブル内 : 統合トレーステーブルには、Unity Gateway サービス全体のすべてのリクエストが記録され、実行された各ポリシーとフェーズに対して 1 つの policy_evaluated イベント（実行されたアクションを含む）が記録されます。ポリシー評価イベントを参照してください。
システムテーブル内 ：モデルとMCPのアクティビティが使用状況テーブルに記録され、推論テーブルを持つサービスの場合は、その推論テーブルに完全なリクエストおよび応答のペイロードが記録されます。

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

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

リクエストに対してどのポリシーがランされ、それぞれがどのように決定されたかを確認するには、統合トレーステーブルから起動します。メタストア管理者がすべての Unity ゲートウェイサービスに対して 1 回セットアップを行うと、各リクエストのスパンには、ランしたすべてのポリシーとフェーズについて、ポリシーの名前、タイプ、およびアクションを示す policy_evaluated イベントが含まれます。 Log モードのポリシーの場合、イベントは policy.dry_run_action および policy.dry_run_reason に予測される判定も記録します。ポリシー評価イベントを参照してください。

トレースには、各 LLM-as-a-judge ポリシーのアクションが記録されますが、評価者の推論は記録されません。組み込みまたはカスタムの LLM-as-a-judge の決定に関する背景にあるすべての推論（評価者の信頼度や評価した正確なコンテンツを含む）を確認するには、評価者モデルサービスの推論テーブルを確認してください。

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では、最初に LLM-as-a-judge ポリシーを Log モードでアタッチすることを推奨しています。これにより、ブロックせずに判定結果が記録されます。統合トレーステーブルで検証予定の判定結果を確認し、信頼度とその評価対象コンテンツも必要な場合は、評価者で推論テーブルを有効にします。実際のトラフィックに対する判定結果を検査し、プロンプトとランクを調整してから、ポリシーを [強制] に切り替えます。機密データ検出は、適用（enforce）モードでのみランされます。

アクセス権

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

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

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

制限事項

次の制限が適用されます：

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

ポリシーの種類を選択する​

前提条件​

組み込みポリシーをアタッチする​

LLM-as-a-judge ポリシーを作成する​

SQLポリシーを作成する​

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

ステップ 2: 関数をサービスにアタッチする​

外部のサービスポリシーをアタッチします​

ポリシーを確認する​

アタッチの確認​

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

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

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

判定を読み取る​

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

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

アクセス権​

制限事項​