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

 Release :

    - xanadu

ft:locale :

    - ja-JP

ft:publication_title :

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

ft:clusterId :

    - grc

bundleId :

    - grc

workflow :

    - Technology


---

# ポリシーでの動的承認構成のセットアップ

# ポリシーでの動的承認構成のセットアップ {#ariaid-title1}

* リリースバージョン: Xanadu
* 
* 更新日 2024年08月01日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：7分

ポリシーとは、業務を管理するためにビジネス組織によって確立されたガイドラインとルールのセットです。ポリシーの承認構成レコードを作成すると、さまざまな動的条件に基づいて 1 つまたは複数の承認レベルと承認ルールを定義できるようになります。

Xanadu リリース以降は、ポリシーレコードで動的承認構成をセットアップできます。ポリシーテーブルは、ポリシーのステータスを規制するポリシーレコードで構成されます。ポリシーを実装する前に、レビューと承認のプロセスを経由します。

ポリシーレコードで動的承認構成をセットアップすると、ポリシーフィールドに関連するポリシータイプ、ステータス、所有者などのさまざまな動的条件に基づいて、複数のレベルの承認を定義できるようになります。ポリシーレコードで動的承認構成をセットアップすると、ポリシーの承認者がポリシーレコードに動的に追加されます。

## 承認者を手動で追加する場合の制限事項 {#dynamic-approval-config-for-a-policy__section_lzm_4ww_4zb}

既存の承認構成プロセスで使用する手動アプローチには、次のような制限があります。

* 承認構成プロセスでは、単一レベルの承認が使用されます。複数のレベルの承認を使用しない場合、承認プロセスでエラーや見落としが発生する可能性が高くなります。
* ポリシーの承認者は、承認プロセスの動的な条件または変化する条件に基づいて変更することはできません。
* 承認者は手動でレコードに追加されます。このプロセスは、特に大規模な組織や複雑な意思決定構造では、時間がかかる場合があります。
* 承認者を手動で追加すると、大幅な遅延が発生する可能性があります。すべての承認を受け取るまで待つと、意思決定プロセスの速度が低下し、生産性が低下する可能性があります。
{#dynamic-approval-config-for-a-policy__ul_lwq_hxw_4zb}

## 動的承認構成のメリット {#dynamic-approval-config-for-a-policy__section_bbc_mxw_4zb}

ポリシーでの動的承認構成のセットアップには、次のようなメリットがあります。

* 組織の環境が動的になり変化し続けるということはよくあります。承認者を柔軟に変更できるため、状況の変化に承認プロセスで適応できます。これにより、常に最適な人員が承認プロセスに関与できるようになります。
* 複雑な意思決定や重要な意思決定の場合は、複数レベルの承認を構成することで、レビュー担当者は関連する要素を包括的にレビューできます。これにより、性急な決定ではなく、さまざまなシナリオに対する潜在的な影響を慎重に評価することが確実にできるようになります。
* 承認者を動的に変更すると、承認プロセスが合理化され、管理オーバーヘッドが削減されるため、時間とリソースを節約できます。
{#dynamic-approval-config-for-a-policy__ul_fsh_rxw_4zb}

## 複数レベルの承認を要求するユースケース {#dynamic-approval-config-for-a-policy__section_pmg_1xm_vzb}

承認構成は、各ポリシーの承認者を手動で追加することなく、複雑な承認レベルを作成するのに役立ちます。場合によっては、ポリシーオーナーがポリシーに対して複数レベルの承認を実施したいことがあるでしょう。たとえば、ポリシーが HR ドメインに関連しているとします。コンプライアンスチーム、法務チーム、HR チームがレビューして承認したいと考えています。ポリシーオーナーは、HR チームをポリシーのレベル 1 承認者としてアサインできます。

HR チームがポリシーを承認すると、レベル 2 の承認のためにコンプライアンスチームにアサインされます。その後、ポリシーのレベル 3 承認のために法務部門にアサインされます。また、ポリシーオーナーは、ポリシーに一致する特定のルールに基づいて承認者を動的に選択することもできます。

このユースケースでは、動的承認構成をポリシーと統合し、Approval Configurator を使用してポリシー承認ルールを構成することの重要性を強調しています。

## Approval Configurator {#dynamic-approval-config-for-a-policy__section_vgb_kgp_b1c}

承認構成を使用するには、次の例に示すように、ポリシーの承認方法として承認ルールを使用することを選択する必要があります。

ポリシーの承認構成を作成し、ユーザーに対して有効な承認ルールを構成する必要があります。

コンプライアンスワークスペースでは、\[ポリシーとコンプライアンス\] \> \[ポリシーと手順\] \> \[ポリシー承認ルール (Policy Approval Rules)\] に移動して、承認ルールを構成できます。

## Approval Configurator を使用したポリシー承認ルールの構成 {#dynamic-approval-config-for-a-policy__section_s22_fs3_c1c}

Approval Configurator を使用して、さまざまな承認ルールを設定できます。

* 動的条件に基づいてマルチレベルの承認ルールを設定します。
* ソースレコードのフィールドから選択されたユーザーまたはユーザーのグループに承認を送信するか、ユーザーまたはグループを手動で選択します。
* 1 つの承認のみ、またはすべての承認を必須の承認として設定します。
{#dynamic-approval-config-for-a-policy__ul_q1l_ms3_c1c}  
レコードの承認構成を設定するには、次のセクションを参照してください。

1. 承認構成レコードの設定については「[承認構成レコードを設定する](https://servicenow-prod.fluidtopics.net/OXiWj2U81EDdjkV7sRBcMQ "複数レベルの承認を有効にする承認構成レコードを設定し、承認ルールに基づいて各レベルの承認者を選択します。")」を参照してください。
2. 承認設定レコードの承認レベルを割り当てるには、「[承認設定レコードの承認レベルをアサインする](https://servicenow-prod.fluidtopics.net/Na8_kuiuhS6e~zTyG4pSbg "承認の各ステップをサポートするために、承認設定レコードに 1 つ以上の承認レベルをアサインします。")」を参照してください。
3. 承認設定レコードの承認レベルに対して承認ルールを設定するには、「[承認レベルの承認ルールの設定](https://servicenow-prod.fluidtopics.net/NHZIKi~1SxhVFDq65Fw4Bw "承認レベルの承認ルールを設定します。ソース、承認ルールが適用されるソーステーブルのフィルター条件、承認者タイプ、およびレコードの承認者を定義できます。")」を参照してください。

{#dynamic-approval-config-for-a-policy__ol_xn4_ltq_zzb}  
注:  
GRC：承認コンフィギュレーター アプリケーションのロールの詳細については、「」を参照してください。

## ポリシー承認ルールの作成に必要なロール {#dynamic-approval-config-for-a-policy__section_ox4_bt3_c1c}

ポリシー承認ルールを作成するには、次のロールが必要です。

* sn_compliance.manager ロールを持つユーザーは、sn_grc_appr.admin ロールでポリシー承認ルールを作成できます。
* sn_grc.business_user および sn_grc.business_user_lite 以上のロールを持つユーザーは、ポリシーを表示できます。
* レッドラインが有効になっている場合にドキュメントにアクセスする場合、ユーザーには sn_grc.business_user または sn_grc.business_user_lite ロールのいずれかを備えた mp_document_user が必要です。
{#dynamic-approval-config-for-a-policy__ul_kcc_dt3_c1c}

## 承認構成を設定するためのワークフロー {#dynamic-approval-config-for-a-policy__section_pcv_yxw_4zb}

ポリシーレコードの承認構成を設定する場合、ワークフローには次の手順が含まれます。  
1. ポリシーレコードの承認が要求されると、ポリシーのステータスが \[承認待ち\] に変更されます。
2. 承認方法に \[承認者を使用 (Use approvers)\] が選択されている場合、ポリシーレコードに記載されている承認者が使用されます。
3. 承認方法に \[承認ルールを使用 (Use approval rule)\] が選択されている場合、ポリシーレコードに適した有効な構成がチェックされます。動的承認構成では、ポリシーに関連する承認構成レコードが検索されます。
4. 動的承認構成では、次に各承認レベルレコードから承認者が取得され、各レベルの承認要求が送信されます。
5. 有効な構成が見つからない場合は、ポリシーに有効な構成がないことを示すエラーメッセージが表示されます。
{#dynamic-approval-config-for-a-policy__ol_ad5_3d5_vzb}

ワークフローのステップを次の例に示します。

ポリシーオーナーは、ポリシーフォームの \[承認者\] フィールドでポリシーの承認者を選択できます。承認者は通常、コンプライアンスユーザーのロールを持つユーザーです。適切なアクセス権がない場合は、ポリシーレコードにアクセスできません。ポリシーレコードへのアクセスを要求するには、コンプライアンスアドミニストレーターに連絡する必要があります。

## 動的承認構成とポリシーの統合 {#dynamic-approval-config-for-a-policy__section_ujv_xcx_4zb}

動的承認構成をポリシーレコードと統合するために、複数の承認レベルを設定し、レベルごとに承認ルールを設定できます。承認レベルとルールの設定に基づいて、承認が自動的にトリガーされます。1 つのレベルが承認されると、次のレベルの承認のためにポリシーレコードが送信されます。

動的承認構成をポリシーと統合するためのワークフローを次の例と手順に示します。  

* ポリシーの承認が要求されると、ポリシーのステータスが \[承認待ち\] に変更されます。
* 動的承認構成では、現在のポリシーに適した承認構成レコードが検索されます。
* 動的承認構成がポリシーレコードに設定されていない場合、または動的承認構成が設定されていてもその特定のポリシーレコードに適用できない場合は、ポリシーレコードに有効な構成が見つからないというエラーメッセージが表示され、レコードは中止されます。ユーザーは、ポリシーレコードに戻って承認者を選択するか、ポリシーレコードの有効な構成を作成する必要があります。
* 動的承認構成が設定されている場合、承認者、承認レベル、およびルールは、承認構成レコードの構成に基づいて追加されます。
{#dynamic-approval-config-for-a-policy__ul_w2j_2dx_4zb}

ワークフローの全体を次の例に示します。

## 動的承認構成に使用されるコンポーネント {#dynamic-approval-config-for-a-policy__section_jng_gdx_4zb}

次のコンポーネントは、ポリシーの動的承認構成を設定するために使用されます。

* ポリシー承認ルールモジュールは、ソーステーブルをポリシーとする承認構成を作成または確認します。
* ポリシー承認テーブルには、承認構成の各レベルの承認者が格納されます。承認レベルのステータスを追跡するために使用できます。
* 現在のレベルの決定に基づいて、ポリシーは次の承認レベルに転送されるか、却下された場合は \[ドラフト\] ステータスにリセットされます。すべてのレベルが承認されると、ポリシーは \[公開\] ステータスに移行します。
{#dynamic-approval-config-for-a-policy__ul_zgs_kdx_4zb}