---
sourceDocument: Yokohama のガバナンス、リスク、コンプライアンス
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/yokohama/governance-risk-compliance

 Release :

    - yokohama

ft:locale :

    - ja-JP

ft:publication_title :

    - Yokohama のガバナンス、リスク、コンプライアンス

ft:clusterId :

    - grc

bundleId :

    - grc

workflow :

    - Technology


---

# ポリシー例外検証ルールを定義

# ポリシー検証ルールの定義 {#ariaid-title1}

* リリースバージョン: Yokohama
* 
* 更新日 2025年07月31日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：4分

GRC Approval Configurator を使用して、ポリシーの例外と延長に関する詳細な承認ルールを構成します。これにより、正確なルール定義で承認を管理し、マルチレベルの承認ワークフローをサポートできます。

## このタスクについて

検証ルールは、レビューまたは承認に進む前に、ポリシー例外または延長要求を検証します。これらのルールは検証構成テンプレートを使用して構成され、ステータス、サブステータス、およびその他のフィルターに基づいて条件を定義できます。ポリシー例外が作成されると、\[新規\] ステータスになり、検証承認がトリガーされます。検証に成功すると、要求はさらに評価するために \[分析\] ステータスに進みます。

## 始める前に

必要なロール:ポリシー検証ルールを作成するための sn_compliance.manager。

## 手順

1. 移動先 すべてアサイン構成および承認構成承認構成.  
   GRC Approval Configurator には、「 ポリシー例外 - 検証構成」と呼ばれる検証用のデフォルトテンプレートが付属しています。
2. \[ポリシー例外 - 検証構成\] を選択します。
3. フォームで、フィールドに入力します。  
   {#define-policy-exception-verification-rules__table_klc_gq4_plb__entry__2}

   | フィールド | 説明 |
   |-|-|
   | 優先度 | デフォルトでは、検証構成は優先度 1 に設定されています。 注: 検証構成はデフォルトで優先度 1 に設定されており、その前に初期検証が承認されるように保持する必要があります |
   | フィルター条件 | 構成をアクティブ化するタイミングを定義するフィルター条件。使用可能な値は、ポリシー例外テーブルから取得されます。 デフォルトでは、\[ステータス\] は \[新規\] に設定されています。これは必須条件です。 他のフィルター条件も設定できます。複雑な条件セットを作成するには、AND や OR などの論理演算子を使用します。 |
   | ドメイン | 承認フローに関連付ける必要がある機能グループまたはロール。 |
   | 適用先 | \[ ポリシー例外 (sn_compliance_policy_exception)\] オプションが選択されていることを確認します。 |
   | アクティブ | 構成を有効にするオプション。 |
   | 名前 | 検証構成の名前。 デフォルトでは、テンプレート名は「 ポリシー例外 - 検証構成」です。テンプレート名は変更できます。 |
   [表 : 1. 検証構成フォーム]

   {#define-policy-exception-verification-rules__table_klc_gq4_plb}
4. \[承認レベル\] テーブルの構成に承認レベルを追加します。  
   「 検証構成 - レベル 1 」と呼ばれるデフォルトの承認レベルは既に設定されています。構成には複数のレベルを追加できます。各レベルには、独自のルール、アサインされたユーザーまたはグループ、およびトリガー条件を設定できます。
5. \[ 検証構成:レベル 1\] を選択します。
6. フォームで、次のフィールドを変更します。  
   {#define-policy-exception-verification-rules__table_zgr_qyx_rgc__entry__2}

   | フィールド | 説明 |
   |-|-|
   | 名前 | デフォルトでは、指定された名前は「検証構成 - レベル 1」です。 同じ名前を保持することも、名前を変更することもできます。 |
   | レベル | これは構成する最初のレベルであるため、レベルを 1 のままにします。 |
   [表 : 2. \[検証レベル\] フォーム]

   {#define-policy-exception-verification-rules__table_zgr_qyx_rgc}
7. \[送信\] を選択します。
8. \[承認レベル\] テーブルで \[ 新規 \] を選択して、構成に承認レベルを追加します。  
   {#define-policy-exception-verification-rules__table_wmb_jzx_rgc__entry__2}

   | フィールド | 説明 |
   |-|-|
   | 名前 | 新しいレベルに名前を付けます。 |
   | レベル | レベルを割り当てます。 |
   [表 : 3. \[検証レベル\] フォーム]

   {#define-policy-exception-verification-rules__table_wmb_jzx_rgc}
9. \[送信\] を選択します。  
   必要な承認レベルを追加した後、各レベルに検証ルールを追加します。
10. 検証ルールを追加するには、構成された検証レベルを選択し、次の操作を行います。
    1. \[承認ルール\] で \[ 新規\] を選択します。
    2. フォームで、フィールドに入力します。  
       {#define-policy-exception-verification-rules__table_ecj_kkz_bgc__entry__2}

       | フィールド | 説明 |
       |-|-|
       | 名前 | このルールの名前。 |
       | 説明 | ルールの説明。 |
       | ソース | ルール評価用のソーステーブル。 |
       | 他の条件 | 追加のフィルターを適用してソーステーブルを絞り込むオプション。 |
       | フィールドを使用するクエリ | 一致する承認条件を照会するソースレコードのフィールド。 |
       | 承認タイプ | 承認タイプオプション: * 特定の承認者:個々のユーザー、グループ、またはその両方を承認者として直接選択します。このオプションを使用すると、動的ロジックまたはソースベースのロジックに依存せずに、承認者を手動でアサインできます。 * ソースからの承認:ソーステーブルの値に基づいて承認者を選択します。ユーザーフィールド、グループフィールド、またはその両方を選択して、ソースレコードから承認者を動的に決定できます。 * 動的承認者:ソースを使用して承認者を動的に定義します。静的または高度な動的条件を適用して承認者をフィルタリングします。ユーザーフィールド、グループフィールド、またはその両方を選択して、承認するユーザーを決定できます。 * スクリプト化された承認者:スクリプトを使用して、プログラムで承認者を決定します。スクリプトは、ユーザー変数とグループ変数を設定する必要があります。 {#define-policy-exception-verification-rules__ul_ibb_yf1_cgc} |
       | 次の承認が必要： | 承認オプション:選択したすべてのユーザーが例外を承認することを必須にするには、\[ すべて \] を選択します。1 人のユーザーがすべての承認者の代わりに承認できるようにするには、\[ 任意のユーザー\] を選択します。 |
       [表 : 4. ルール構成フォーム]

       {#define-policy-exception-verification-rules__table_ecj_kkz_bgc}
    3. \[送信\] を選択します。
    {#define-policy-exception-verification-rules__substeps_y5x_d1y_rgc}