---
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分

アプリケーションの ServiceNow® GRC スイートは、拡張されたアイテム生成プロセスを使用して、組織のコントロールとリスクを自動的に生成できます。バージョン 13.x.x の拡張アイテム生成プロセス (v2) は、バージョン 12.x.x およびそれ以前のリリースのアイテム生成プロセス (v1) からの停止とパフォーマンスの問題を修正します。

## アイテム生成プロセスの概要 {#item-generation-process__section_hw5_gmy_2tb}

ガバナンス、リスク、コンプライアンス アプリケーションを使用すると、アイテム生成プロセスを使用して組織のコントロールとリスクを生成できます。

コントロールは、組織が実行する実際のコントロールアクティビティです。たとえば、コントロールは、信頼できるソースコンテンツ (法務記事、規制、または公開レコード)、ポリシー、およびリスクに関連している場合があります。ポリシーをエンティティタイプ (一連のフィルター条件に一致するエンティティのグループ化) に関連付けるか、またはエンティティタイプをコントロール目標に関連付けると、コントロールが自動的に生成されます。コントロールの詳細については、「 [コントロールの管理](https://servicenow-prod.fluidtopics.net/QkUMQrwWjz61gkZI_b_YpA "コントロールは、コントロール目標の特定の実装です。廃止されたコントロールはリストに表示されません。 コントロールを定義する前に、時間をかけて組織内の重要なコントロールを合理化し、統合し、定義します。")」を参照してください。  
リスクとは、組織のビジネスゴールに悪影響を与える可能性のある脅威または脆弱性のことです。たとえば、リスクは、任意のアイテム、ポリシー、コントロール、または修復タスクに関連する場合があります。リスクフレームワークまたはリスクステートメントとエンティティタイプを関連付けると、リスクが自動的に生成されます。  
注:  
リスクステートメントは、組織で発生する可能性のある潜在的なリスクまたは脅威に関する一般的なステートメントです。リスクフレームワークは、リスクアセスメント、応答、およびそれに関連するリスクおよび軽減アクティビティの説明責任で構成されます。
リスクの詳細については、 [リスク管理の使用](https://servicenow-prod.fluidtopics.net/Q0KPHw4emsK4~up~Gs8SMg "リスク管理 アプリケーションの機能を使用して、問題の作成、リスクイベントのレポート、リスクアセスメントの実行などのさまざまなアクティビティを実行できます。")を参照してください。

バージョン 12.x.x およびそれ以前のリリースのアイテム生成プロセス (v1) では、アクションキュー内の停止したアクションが原因で非同期の更新が生成されていました。拡張アイテム生成プロセス (v2) により、停止する問題が解消され、コントロールとリスクの処理時間が大幅に改善されます。たとえば、従来のアイテム生成プロセス (v1) は約 13.7 分で 10,000 のリスクを生成しましたが、新しいアイテム生成プロセス (v2) では約 5.27 分で 10,000 のリスクを生成できます。

## アイテム生成のプロセスフロー {#item-generation-process__section_qn1_b24_3tb}

アイテム生成プロセスは、アクションをアクションキューに挿入し、アクションを 1 つずつ順番に実行します。スケジュール済みジョブが定期的に実行され、アクションキューがチェックされます。アクションがキューで実行されている場合、スケジュール済みジョブはそれをスキップします。現在の実行中のアクションが完了し、他のアクションが進行中でない場合は、次の例に示すように、スケジュール済みジョブはキュー内の \[準備完了\] ステータスのアクションを取得します。 図 : 1. アイテム生成のプロセスフロー

## アイテム生成プロセスのメリット {#item-generation-process__section_ydq_rhh_3tb}

新しいアイテム生成プロセスには、次の主なメリットがあります。

* アイテム生成アクションのイベントキューを使用して、コントロールとリスクを迅速に処理します。
* 不整合な更新を生成したキュー内の停止したアクションと競合状態を排除します。
* アイテム生成アクションの履歴とステータスをログに記録します。
* アイテム生成アクションのイベントキューのエラーに関する詳細情報を提供します。問題を迅速かつ効率的に追跡してトラブルシューティングするために役立ちます。
* コンプライアンスマネージャーとリスクマネージャーが、ほとんどメンテナンスを行わずにオートパイロットモードでコントロールとリスクを管理するために役立ちます。
{#item-generation-process__ul_wqb_5hh_3tb}

## アイテム生成プロセスで使用されるアプリケーション {#item-generation-process__section_at3_ljf_htb}

次の GRC アプリケーションが、 アイテム生成プロセスで使用されます。

* GRC：ポリシーとコンプライアンス管理
* GRC: リスク管理
* GRC: Profiles
{#item-generation-process__ul_c2n_ljf_htb}

GRC: Profiles アプリケーションは、GRC：ポリシーとコンプライアンス管理 または GRC: リスク管理 アプリケーションが有効化されると、自動的にインストールされます。

## アップグレードシナリオと既存の実装へのそれらの影響 {#item-generation-process__section_zfs_vly_2tb}

ポリシーとコンプライアンス管理 と リスク管理 の両方のアプリケーションをバージョン 13.x.x にアップグレードする必要があります。ポリシーとコンプライアンス管理 および リスク管理 アプリケーションをバージョン 13.x.x にアップグレードすると、新しいアイテム生成プロセス (v2) が従来のアイテム生成プロセス (v1) に置き換わります。  
注:  
ポリシーとコンプライアンス管理 および リスク管理 アプリケーションをバージョン 13.x.x にアップグレードすると、GRC: Profiles アプリケーションがバージョン 13.x.x に自動的にアップグレードされます。  
必要なバージョンの ポリシーとコンプライアンス管理 および リスク管理 アプリケーションがインスタンスにインストールされていることを確認します。インストールされているアプリケーションに次のいずれかのシナリオが該当する場合、画面にエラーメッセージが表示されます。

* 以前に ポリシーとコンプライアンス管理 と リスク管理 の両方のアプリケーションがインスタンスにインストールされていて、そのうちの 1 つだけをバージョン 13.x.x にアップグレードする
* ポリシーとコンプライアンス管理 または リスク管理 のいずれかのアプリケーションのみがインスタンスにインストールされており、GRC: Profiles アプリケーションをバージョン 13.x.x にアップグレードする
* インスタンスに ポリシーとコンプライアンス管理 と リスク管理 の両方のアプリケーションがインストールされており、GRC: Profiles アプリケーションをバージョン 13.x.x にアップグレードする
{#item-generation-process__ul_t4p_cqn_3tb}  
エラーメッセージには、次の例に示すように、ポリシーとコンプライアンス管理 と リスク管理 の両方のアプリケーションをバージョン 13.x.x にアップグレードする必要があることが示されます。図 : 2. アプリケーションをアップグレードするためのメッセージ  
アップグレードしても、アイテム生成プロセスの既存の実装に目に見える影響はありません。  
注:  
バージョン 13.x.x にアップグレードしていない場合でも、従来のアイテム生成プロセスは引き続きサポートされます。

## アイテム生成プロセスで使用されるコンポーネント {#item-generation-process__section_o4f_qcl_htb}

アイテム生成プロセスでは、テーブル、スケジュール済みジョブ、アクションハンドラーなどのいくつかのタイプの参照コンポーネントが使用されます。アイテム生成プロセスで使用されるコンポーネントの詳細については、「[アイテム生成プロセスとともにインストールされるコンポーネント](https://servicenow-prod.fluidtopics.net/VxITsP55bJWfSgWxJRY6kg "アイテム生成プロセスとともに、いくつかのタイプのコンポーネント (テーブル、スケジュール済みジョブ、アクションハンドラーなど) がインストールされます。")」を参照してください。

## スケジュール済みジョブとアクションイベントキューを使用する {#item-generation-process__section_ibl_t2f_ftb}

アイテム生成プロセスは、Item generation action queue processor スケジュール済みジョブとアクションイベントキューをバックグラウンドで使用します。sn_grc.admin ロールを持つユーザーは、次の例に示すように、スケジュール済みジョブの頻度を設定できます。 図 : 3. スケジュール済みジョブの頻度を設定する  
コントロールまたはリスクを生成、更新、または削除するアクションを開始すると、スケジュール済みジョブによって sn_grc_item_generation_action_event_queue.list テーブルに各アクションのレコードが挿入されます。アイテム生成アクションのイベントキューを次の例に示します。図 : 4. アイテム生成アクションのイベントキュー  
アイテム生成プロセスを使用してアクションが生成されると、アイテム生成プロセスが開始されたというメッセージが表示されます。たとえば、コントロール目標にリスクステートメントを追加すると、次の例に示すメッセージが表示されます。 図 : 5. アイテム生成プロセスの開始  
キュー内のアクションの処理中にエラーが発生した場合、アイテム生成プロセスはエラーに関する詳細情報を表示します。たとえば、次の例に示すように、オブジェクト ID を含むエラートレースが表示される場合があります。図 : 6. エラートレース

キュー内のエラートレースとその他の詳細を使用して、問題の追跡とトラブルシューティングを行うことができます。

## スクリプトインクルードアクションハンドラー {#item-generation-process__section_xyr_x2f_ftb}

アイテム生成プロセスは、ポリシーとコンプライアンス管理 および リスク管理 アプリケーションのアクションを処理するスクリプトインクルードアクションハンドラーを使用します。

サポートされているアクションハンドラーのリストを表示するには、次の例に示すように、アプリケーションナビゲーターの \[スクリプトインクルード\] に移動します。
図 : 7. スクリプトインクルードアクションハンドラー  
すべてのスクリプトインクルードアクションハンドラーには、基本バージョンと拡張バージョンが含まれています。アイテム生成プロセスでは、アクションを処理するために基本バージョンが使用されます。sn_grc.manager ロールを持つユーザーは、次の例に示すように、アクションハンドラーにリストされている基本機能を確認できます。図 : 8. 基本機能  
script_include_admin ロールを持つユーザーは、次の例に示すように、基本機能を上書きすることでコントロールまたはリスクのアクション戦略を変更できます。図 : 9. 基本機能を上書きする
* **[アイテム生成プロセスとともにインストールされるコンポーネント](https://servicenow-prod.fluidtopics.net/VxITsP55bJWfSgWxJRY6kg)**   
  アイテム生成プロセスとともに、いくつかのタイプのコンポーネント (テーブル、スケジュール済みジョブ、アクションハンドラーなど) がインストールされます。
* **[共通コントロールのアイテム生成における操作の変更](https://servicenow-prod.fluidtopics.net/haH493oAKUPAa~_2INt2ow)**   
  アイテムの生成で操作上の変更が行われるのは、主にアイテムの生成によってコントロールが作成されるか、既存の標準コントロールが有効化されるためです。コントロールをエンティティに関連付ける場合は、そのエンティティのコントロールを作成するよりも、依存エンティティを共通コントロールに関連付けることが優先されます。

