DevOps 変更モデル

  • リリースバージョン: Australia
  • 更新日 2026年03月12日
  • 所要時間:22分
  • DevOps 変更速度管理で変更モデルを使用すると、変更モデルまたはプロセスをより柔軟に定義して、最新の開発プラクティスを反映できます。

    DevOps 変更モデルの概要

    重要:
    DevOps の変更要求には、変更プロセスフローを特定のユースケースに最適化する方法で有効にするための柔軟性を提供する [変更管理 - 変更モデル (Change Management - Change Models)] 機能を使用します。詳細については、「変更モデル」を参照してください。従来の [変更管理 - 状況モデル (Change Management - State Model)] もサポートされています。詳細については、「従来:状況モデルと移行」を参照してください。
    重要:
    [DevOps] および [DevOps の簡素化] 変更モデルは、Argo CD および分割ツールの変更要求ではサポートされていません。

    特定のユースケース向けに、フローデザイナーで構築された一連の簡潔なフローとフローアクションで目的に合った変更モデルを使用します。変更ワークフロー (通常、標準、緊急) で事前定義された従来の ITIL ベースの変更プロセスを使用する代わりに、特定のユースケースに最適化された幅広いモデルに選択的に移行できます。変更モデルは、ステータス間の移行を決定するステータスとルールを使用して作成できます。変更モデルの詳細については、変更モデル を参照してください。

    変更モデル

    [DevOps] または [DevOps の簡素化] 変更モデルを含む、任意のベースシステム変更モデルを使用できます。モデルに基づいて変更要求を作成するには、ServiceNow のステップフォームで [モデル] フィールドを設定するか、オーケストレーションパイプラインから変更ステップでモデルの sys_id または名前を渡します。

    ベースシステムの DevOps 変更モデル

    [DevOps] および [DevOps の簡素化] と呼ばれる 2 つの変更モデルがベースシステムに含まれており、モデルベースの変更要求を作成するためにデフォルトで有効になっています。

    タイプ互換性フラグ

    タイプ互換性 com.snc.change_management.change_model.type_compatibility プロパティは、作成される変更要求の種類 (タイプベースまたはモデルベース) を決定するために使用されます。[システムプロパティ] > [すべてのプロパティ] に移動して、このプロパティの値を設定します。このプロパティのデフォルト値は false です。このプロパティは、変更モデルの変更タイプの互換性を有効にします。true に設定すると、変更要求はタイプベースのワークフローまたは変更モデルのいずれかとして作成できます。false に設定すると、変更要求は変更モデルのみを使用して作成されます。

    プロパティが true または false に設定されている場合、変更要求は、次の表で定義されている構成の組み合わせに基づいて作成されます。

    表 : 1. 型互換性プロパティが True に設定されている場合
    ServiceNow のパイプラインステップで構成された属性の変更 パイプラインで渡された変更属性 変更要求の作成で考慮される変更属性
    変更モデル : <選択した任意の変更モデル> モデルも変更タイプも渡されません。 モデルベースの変更要求が作成されます
    変更モデル : <選択した任意の変更モデル> タイプが渡されます。たとえば、[通常] です
    {
        "attributes": {
          "type": "normal"
        }
      }
    タイプベースの変更要求が作成されます
    変更モデル: <選択した変更モデル> ([モデル 1 (Model 1)] など)。
    異なるモデルが渡されます。例:[モデル 2 (Model 2)]。
    {
        "attributes": {
          "chg_model": {
             "name": "Model 2"
            }
          }
      }
    変更はモデル 2 (Model 2) に基づいて作成されます

    変更モデル: 未指定

    変更タイプ: <選択した任意の変更タイプ>

    モデルも変更タイプも渡されませんでした タイプベースの変更要求が作成されます
    変更タイプ: <選択した任意の変更タイプ> モデルが渡されます。
    {
        "attributes": {
          "chg_model": {
             "name": "DevOps"
          }
        }
      }
    モデルベースの変更要求が作成されます
    変更タイプ: <選択した任意の変更タイプ>。たとえば、[通常] です
    別のタイプが渡されました。たとえば、[緊急] です。
    {
        "attributes": {
          "type": "emergency"
        }
      }
    変更要求は [緊急] タイプに基づいて作成されます。
    表 : 2. 型互換性プロパティが True に設定されている場合
    ServiceNow のパイプラインステップで構成された属性の変更 パイプラインで渡された変更属性 変更要求の作成で考慮される変更属性
    変更モデル : <選択した任意の変更モデル> モデルも変更タイプも渡されませんでした モデルベースの変更要求が作成されます
    変更モデル : <選択した任意の変更モデル> タイプが渡されます。たとえば、[通常] です
    {
        "attributes": {
          "type": "normal"
        }
      }
    エラー

    タイプ互換性フラグが無効になっているため、変更要求を作成できません。システムプロパティでタイプ互換性フラグを有効にするか、ServiceNow のステップレコードで変更モデルを設定するか、パイプラインに適切な変更モデル Sys ID を入力します。

    このエラーの解決方法については、「DevOps 変更速度管理の一般的なエラー」を参照してください。

    変更モデル: <選択した変更モデル> ([モデル 1 (Model 1)] など)。
    異なるモデルが渡されます。例:[モデル 2 (Model 2)]。
    {
        "attributes": {
          "chg_model": {
             "name": "Model 2"
          }
        }
      }
    変更はモデル 2 (Model 2) に基づいて作成されます

    変更モデル: 未指定

    変更タイプ: <選択した任意の変更タイプ>

    モデルも変更タイプも渡されません。 エラー

    変更タイプまたは変更モデルがパイプライン用に構成されていないため、変更要求を作成できません。

    このエラーの解決方法については、「DevOps 変更速度管理の一般的なエラー」を参照してください。

    変更タイプ: <選択した任意の変更タイプ> モデルが渡されます。
    {
        "attributes": {
          "chg_model": {
             "name": "DevOps"
          }
        }
      }
    モデルベースの変更要求が作成されます
    変更タイプ: <選択した任意の変更タイプ>。たとえば、[通常] です
    別のタイプが渡されました。たとえば、[緊急] です。
    {
        "attributes": {
          "type": "emergency"
        }
      }
    エラー

    タイプ互換性フラグが無効であるため、変更要求を作成できません。システムプロパティでタイプ互換性フラグを有効にするか、ServiceNow のステップレコードで変更モデルを設定するか、パイプラインに適切な変更モデル Sys ID を入力します。

    このエラーの解決方法については、「DevOps 変更速度管理の一般的なエラー」を参照してください。

    DevOps モデルの構成

    ベースシステムの変更モデルでは、[実装ステータス] フィールドの値は [実装] に設定され、[レコードのプリセット] フィールドはデフォルトで [タイプ] = [通常] として選択されています。[DevOps] 変更モデルで利用可能なモデルステータスは、[新規]、[評価]、[認可]、[スケジュール済み]、[実装]、[レビュー]、[クローズ済み]、および [キャンセル済み] です。[DevOps の簡素化] 変更モデルで利用可能なモデルステータスは、[新規]、[認可]、[スケジュール済み]、[実装]、[レビュー]、[クローズ済み]、および [キャンセル] です。要件に応じて、変更モデルを修正し、特定のユースケースに合わせて状態や移行を設定できます。

    図 : 1. [DevOps] 変更モデル
    DevOps 変更モデル
    図 : 2. [DevOps の簡素化] 変更モデル
    [DevOps の簡素化] 変更モデル

    ベースシステムの DevOps モデルを使用する代わりに独自のモデルを作成する場合は、「変更モデルの作成」セクションの手順を参照してください。

    レコードのプリセットを使用して、変更モデルの変更の詳細を設定できます。変更が作成されるたびに、これらの値が自動的に変更に設定されます。変更要求に存在する任意の変更フィールドに対してレコードのプリセットを設定できます。

    変更要求の作成時に変更の詳細を事前提出する際には、次のロジックが考慮されます。
    • レコードのプリセットで変更の詳細を構成した場合、パイプラインから変更の詳細を渡してこの値を上書きすることはできません。
    • 変更の詳細がレコードのプリセットで構成されていない場合、パイプラインから渡された値は、変更要求の詳細を事前提出するために考慮されます。
    • 変更の詳細がレコードのプリセットで構成されておらず、パイプラインから渡されない場合は、ServiceNow のステップフォームで構成された値が考慮されます。
    ServiceNow のレコードのプリセットで構成された変更の詳細 ServiceNow のステップフォームで構成された変更の詳細 パイプラインで渡された変更の詳細 変更の作成時に事前入力される変更の詳細
    アサイン先グループ: DevOps レポート アサイン先グループ: 未指定 アサイン先グループ: 未指定 アサイン先グループは、変更要求のレコードのプリセットから事前入力されます
    アサイン先グループ: 未設定 アサイン先グループ: 未指定 アサイン先グループ: DevOps レポート アサイン先グループは、変更要求のパイプラインから事前入力されます
    アサイン先グループ: 未設定 アサイン先グループ: DevOps レポート アサイン先グループ: 未指定 アサイン先グループは、変更要求のステップフォームから事前入力されます

    [DevOps] 変更モデル

    [DevOps] 変更モデルには、状況移行と変更承認のためのベースシステムのフローが含まれています。[DevOps] モデルの各ステータスには独自のフローがあり、必要な条件が満たされると各フローがトリガーされます。変更承認(自動または手動)は、DevOps モデル変更ポリシーに基づいて行われます。デフォルトでは、ベースシステムの DevOps モデル変更ポリシーでは手動承認の決定のみがアクティブ化されています。さらに承認を自動化する準備ができたら、ポリシーを変更できます。次のフローでは、状況移行と変更承認の動作について説明します。
    • 変更 - DevOps - 新規 (Change - DevOps - New):変更要求が [新規] ステータスで作成されると、このフローがトリガーされます。アサイン先グループがある場合、このフローは変更ステータスを [評価] に更新します。
    • 変更 - DevOps - 評価 (Change - DevOps - Assess):変更要求が [評価] ステータスの場合、このフローがトリガーされます。このフローには、[DevOps による変更ポリシーデータの収集 (DevOps Gather Change Policy Data)] と [変更承認ポリシーの適用 (Apply Change Approval Policy)] の 2 つの主要なアクションがあります。これらは、変更要求に関連付けられた DevOps データを取得し、変更要求を自動承認するか、自動却下するか、手動承認のために送信する必要があるかを確認するために使用されます。変更の承認 (自動または手動) は、このフローの一部として DevOps モデル変更ポリシーに基づく [変更承認ポリシーの適用 (Apply Change Approval Policy)] アクションで行われます。変更が承認されると (自動または手動)、ステータスは [許可] に移行します。変更が却下された場合、変更を要求したユーザーにメール通知が送信され、変更は [新規] 状態に戻ります。変更 - DevOps - 評価 (Change - DevOps - Assess) フロー
    • 変更 - DevOps - 許可 (Change - DevOps - Authorize):変更要求が [許可] ステータスの場合、このフローがトリガーされます。ベースシステムでは、[DevOps による変更ポリシーデータの収集 (DevOps Gather Change Policy Data)] と [変更承認ポリシーの適用 (Apply Change Approval Policy)] という 2 つの主要なアクションがあります。これらは、変更要求に関連付けられた DevOps データを取得し、変更要求を自動承認、自動却下、または手動承認のために送信する必要があるかどうかを確認するために使用されます。[変更承認ポリシーの適用 (Apply Change Approval Policy)] アクションの DevOps モデル変更ポリシーの条件が満たされません。したがって、このフローの変更承認 (自動または手動) はスキップされます。このフローは、変更要求ステータスを [変更 - DevOps - スケジュール (Change - DevOps - Schedule)] フローをトリガーする [スケジュール済み] に移行するだけです。
      注:
      変更プロセスで別の承認が必要な場合は、このフローを参照し、要件に従って DevOps モデル変更ポリシーをカスタマイズできます。
    • 変更 - DevOps - スケジュール (Change - DevOps - Schedule):変更要求が [スケジュール済み] ステータスの場合、このフローがトリガーされます。開始予定日に達すると、変更は [実装] ステータスに移行します。
    • 変更 - DevOps - 実装 (Change - DevOps - Implement):変更要求が [実装] ステータスの場合、このフローがトリガーされます。
    DevOps モデル変更ポリシーには、次のポリシー入力が含まれています。
    • is_change_with_partial_data
    • regression_tests_failed
    • code_security
    • code_coverage
    • total_num_of_commits
    • tests_passing_percent
    • load_tests_failed
    • num_of_open_incidents
    • num_of_outages_in_last_7_days
    • num_of_current_outages
    • integration_tests_failed
    • commits_without_work_item
    • change_request
    • risk
    DevOps モデル変更ポリシーの 3 つの結果 (指定した条件による) は次のとおりです。
    • 自動承認:ポリシーで指定された条件が満たされた場合、変更要求は自動的に承認されます。
    • 自動却下:ポリシーで指定された条件が満たされなかった場合、変更要求は自動的に却下されます。
    • 手動承認:1 つ以上の条件がユーザーまたはグループによる手動承認を必要とする場合、それはポリシーで指定されています。手動承認を迅速化し、変更要求を進行させるために、ポリシーによって関連するユーザーまたはグループに通知が送信されます。
      注:
      デフォルトでは、ベースシステムの DevOps モデル変更ポリシーでは手動承認の決定のみがアクティブ化されています。
    重要:
    ベースシステムの DevOps モデルをそのまま使用すると、変更の承認はデフォルトで自動化されます。自動変更承認が必要ない場合は、現在の変更プロセスに適した方法で DevOps モデル変更ポリシーを変更できます。

    [DevOps の簡素化] モデル

    [DevOps の簡素化] 変更モデルには、ステータス移行と変更承認のためのフローがベースシステムに含まれています。[DevOps の簡素化] モデルの各ステータスには独自のフローがあり、必要な条件が満たされると各フローがトリガーされます。変更承認(自動または手動)は、[DevOps の簡素化] モデルの変更ポリシーに基づいて行われます。次のフローでは、状況移行と変更承認の動作について説明します。
    • 変更 - DevOps の簡素化 - 新規 (Change - DevOps Simplified - New):変更要求が [新規] ステータスで作成されると、このフローがトリガーされます。アサイン先グループがある場合、このフローは変更ステータスを [評価] に更新します。
    • 変更 - DevOps の簡素化 - 許可 (Change - DevOps Simplified - Authorize):変更要求が [許可] ステータスの場合、このフローがトリガーされます。このフローには、[DevOps による変更ポリシーデータの収集 (DevOps Gather Change Policy Data)] と [変更承認ポリシーの適用 (Apply Change Approval Policy)] の 2 つの主要なアクションがあります。これらは、変更要求に関連付けられた DevOps データを取得し、変更要求を自動承認するか、自動却下するか、手動承認のために送信する必要があるかを確認するために使用されます。変更承認 (自動または手動) は、このフローの一部として [DevOps の簡素化] モデル変更ポリシーに基づく [変更承認ポリシーの適用 (Apply Change Approval Policy)] アクションで行われます。変更が承認されると (自動または手動)、 [スケジュール] ステータスに移行します。変更が却下された場合、変更を要求したユーザーにメール通知が送信され、変更は [新規] 状態に戻ります。
      注:
      変更プロセスで別の承認が必要な場合は、このフローを参照し、要件に応じて DevOps の簡素化モデル変更ポリシーをカスタマイズできます。
      変更 - DevOps の簡素化 - 許可 (Change - DevOps Simplified - Authorize) フロー
    • 変更 - DevOps の簡素化 - スケジュール (Change - DevOps Simplified- Schedule):変更要求が [スケジュール済み] ステータスの場合、このフローがトリガーされます。開始予定日に達すると、変更は [実装] ステータスに移行します。
    • 変更 - DevOps の簡素化 - 実装 (Change - DevOps Simplified - Implement):変更要求が [実装] ステータスの場合、このフローがトリガーされます。
    DevOps の簡素化モデル変更ポリシーには、次のポリシー入力が含まれています。
    • is_change_with_partial_data
    • regression_tests_failed
    • code_security
    • code_coverage
    • total_num_of_commits
    • tests_passing_percent
    • load_tests_failed
    • num_of_open_incidents
    • num_of_outages_in_last_7_days
    • num_of_current_outages
    • integration_tests_failed
    • commits_without_work_item
    • change_request
    • risk
    DevOps の簡素化モデル変更ポリシーの 3 つの結果 (指定した条件によって異なります) は次のとおりです。
    • 自動承認:ポリシーで指定された条件が満たされた場合、変更要求は自動的に承認されます。
    • 自動却下:ポリシーで指定された条件が満たされなかった場合、変更要求は自動的に却下されます。
    • 手動承認:1 つ以上の条件がユーザーまたはグループによる手動承認を必要とする場合、それはポリシーで指定されています。手動承認を迅速化し、変更要求を進行させるために、ポリシーによって関連するユーザーまたはグループに通知が送信されます。
      注:
      デフォルトでは、ベースシステムの DevOps 簡素化モデル変更ポリシーでは、手動承認の決定のみがアクティブ化されています。

    パイプラインを再開するコールバック

    DevOps 変更速度管理では、コールバック要求を送信する際に次の考慮事項があります。
    • 実装ステータスは、サードパーティのオーケストレーションツールにコールバックを送信するために使用されます。変更モデルに実装ステータスが 1 つしか存在しない場合は、絶対比較が行われます。変更モデルによって作成された変更が設定された実装ステータスに達すると、コールバックがサードパーティのオーケストレーションツールに送信されます。
      注:
      変更モデルでは、[実装ステータス] フィールドに 1 つ以上のステータスを設定できます。変更モデルごとに実装ステータスを定義できます。詳細については、「従来:状況モデルと移行」を参照してください。
    • 変更モデルに複数の実装ステータスが存在する場合、実装ステータスに最初に到達したステータスのサードパーティオーケストレーションツールにコールバックが送信されます。
    • 変更モデルに実装ステータスが設定されていない場合、モデルステータスで [実装] ステータスがチェックされます。[実装] ステータスが存在する場合は、サードパーティのオーケストレーションツールへのコールバックが考慮されます。モデルステータスにも実装ステータスがない場合は、sn_devops.change_request.implement_state プロパティに存在する値が考慮されます。システムプロパティの値はデフォルトで -1 で、これが実装ステータスです。
    注:
    [変更 - DevOps - 実行ステータスの更新 (Change – DevOps – Update execution state)] フローは、サードパーティのオーケストレーションツールにコールバックを送信するために使用されます。この承認フローは、変更要求が [実装] ステータスになるまで待機します。変更要求が実装ステータスに達すると、このフローはステップ実行レコードを適切なステータス (承認済み、却下済み、キャンセル済み) に更新します。ステップ実行レコードが更新されると、変更管理コールバックフローがトリガーされ、コールバックがサードパーティツールに送信されます。

    アップグレード後

    • [変更モデル] フィールドが [ステップ] フォームに表示されます。タイプ互換性プロパティ (com.snc.change_management.change_model.type_compatibility) が true であるため、これは既存のタイプベースの変更作成プロセスには影響しません。
    • モデルベースの変更要求が必要な場合は、タイプ互換性プロパティを false に設定します。[ステップ] フォームの [変更モデル] フィールドは必須になります。プロパティに基づく構成の組み合わせについては、表 型互換性プロパティが True に設定されている場合 を参照してください。
    注:
    インスタンスを zboot した既存の顧客、または新規の顧客の場合、デフォルトでモデルベースの変更要求を作成できます。ただし、タイプ互換性プロパティを true に設定することで、タイプベースの変更要求を作成できます。
    次の表は、新規顧客およびアップグレード顧客に対して変更モデル機能がどのように機能するかを示しています。
    表 : 3. アップグレードに基づくモデルの動作の変更
    新規またはアップグレードインスタンス タイプ互換性フラグ モデルまたはタイプ 状況移行フロー 自動変更承認フロー サードパーティへのコールバック
    zboot (新規または既存の zbooted) false [DevOps] モデル
    • 変更要求 - DevOps - 新規 (Change request - DevOps - New)
    • 変更要求 - DevOps - 評価 (Change request - DevOps - Assess)
    • 変更要求 - DevOps - 許可 (Change request - DevOps - Authorize)
    • 変更要求 - DevOps - スケジュール (Change request - DevOps - Schedule)
    • 変更要求 - DevOps - 実装 Change request - DevOps - Implement
    ベースシステムでは、変更の承認 (自動または手動) は [変更要求 - DevOps - 評価 (Change request - DevOps - Assess)] フローを通じて行われます。別のレベルの承認が必要な場合は、[変更要求 - DevOps - 許可 (Change request - DevOps - Authorize)] フローを参照し、それに応じて DevOps モデル変更ポリシーをカスタマイズできます。 「コールバック」セクションの「メモ」を参照してください。
    アップグレード false [DevOps] モデル
    • 変更要求 - DevOps - 新規 (Change request - DevOps - New)
    • 変更要求 - DevOps - 評価 (Change request - DevOps - Assess)
    • 変更要求 - DevOps - 許可 (Change request - DevOps - Authorize)
    • 変更要求 - DevOps - スケジュール (Change request - DevOps - Schedule)
    • 変更要求 - DevOps - 実装 Change request - DevOps - Implement
    ベースシステムでは、変更の承認 (自動または手動) は [変更要求 - DevOps - 評価 (Change request - DevOps - Assess)] フローを通じて行われます。別のレベルの承認が必要な場合は、[変更要求 - DevOps - 許可 (Change request - DevOps - Authorize)] フローを参照し、それに応じて DevOps モデル変更ポリシーをカスタマイズできます。 「コールバック」セクションの「メモ」を参照してください。
    zboot (新規または既存の zbooted) false [DevOps の簡素化] モデル
    • 変更要求 - DevOps - 新規 (Change request - DevOps - New)
    • 変更要求 - DevOps - 許可 (Change request - DevOps - Authorize)
    • 変更要求 - DevOps - スケジュール (Change request - DevOps - Schedule)
    • 変更要求 - DevOps - 実装 Change request - DevOps - Implement
    ベースシステムでは、[変更要求 - DevOps - 許可 (Change request - DevOps - Authorize)] フローを介して変更承認 (自動または手動) が行われます。別のレベルの承認が必要な場合は、それに応じて DevOps の簡素化モデル変更ポリシーをカスタマイズできます。 「コールバック」セクションの「メモ」を参照してください。
    アップグレード false [DevOps の簡素化] モデル
    • 変更要求 - DevOps - 新規 (Change request - DevOps - New)
    • 変更要求 - DevOps - 評価 (Change request - DevOps - Assess)
    • 変更要求 - DevOps - 許可 (Change request - DevOps - Authorize)
    • 変更要求 - DevOps - スケジュール (Change request - DevOps - Schedule)
    • 変更要求 - DevOps - 実装 Change request - DevOps - Implement
    ベースシステムでは、[変更要求 - DevOps - 許可 (Change request - DevOps - Authorize)] フローを介して変更承認 (自動または手動) が行われます。別のレベルの承認が必要な場合は、それに応じて DevOps の簡素化モデル変更ポリシーをカスタマイズできます。 「コールバック」セクションの「メモ」を参照してください。
    アップグレード true タイプ 現在の動作は継続されます [DevOps 変更要求の手動承認 (DevOps Change Request Manual Approval)]、[DevOps 変更要求の最小限の自動化承認 (DevOps Change Request Minimal Automation Approval)]、または [DevOps 変更要求の高度な自動化承認 (DevOps Change Request Advanced Automation Approval)] フロー (アクティブなフロー) [変更管理コールバック (Change Control Callback)] フロー