問題管理モジュールのプロパティ

Incidentから問題を起票すると、説明も対象CIも自動でProblemへ引き継がれます。この挙動を決めているのはBusiness Ruleではなく、19件のシステムプロパティです。問題管理に関わるプロパティを実機で確認すると、辞書には存在しないはずの incident.problem_id という項目名が、値の中に今も残っていました。Australia の PDI をデフォルト設定のまま開き、問題管理に関わる19件のプロパティが何を制御しているかを確かめます。

調べる順序

• 問題管理に関わるプロパティが何件あり、どう分類できるか

• Incidentから問題を起票するとき、何が自動で引き継がれるか

• クローズ後の再分析を誰に許すか

• なぜ incident.problem_id という辞書にない項目名が、プロパティの値に残っているか

要点

• 問題管理に関わるプロパティは19件、全件に公式説明がある

• Incidentから問題を起票するときの引き継ぎ項目・添付・重複時の移動先はプロパティで決まる

• クローズ後の再分析は3パターンとも problem_manager に権限が集まっている

• インタラクションからの起票は既定で閉じているが、開いた場合の挙動だけは先に用意されている

プロパティで何が変えられるか

問題管理に関わるシステムプロパティを開くと、コードを触らずに変えられる挙動が並んでいます。

19件全部に公式の説明文（description）が入っています。第4巻の対応にあたる本シリーズの姉妹編（インシデント管理側）では37件中36件でしたが、Problem側は19件全件です。

代表的なものを挙げます。

Incidentからの起票を決める

com.snc.problem.create_from_incident.attributes には、Incidentから問題を起票するとき引き継ぐ項目が12個並んでいます。説明・短い説明・対象CI・影響度など、原因調査に必要な項目です。

クローズ後の統制を決める

problem.acceptrisk.move_to_closed は、リスクを受け入れて解決するとき、ResolvedでなくClosedへ直接進めるかを決めます。既定はtrueです。

インタラクションからの起票を決める

glide.problem.interaction.allow_create は、電話やチャットの問い合わせ画面からProblemを直接作れるようにするかを決めます。既定はfalseです。

• 参考：システムプロパティ（sys_properties）は設定値の置き場 … プロパティ全体の扱い方

プロパティの分類

19件を役割ごとに分けると、7つのまとまりになります。

型で分けると、真偽値が8件で最も多く、次いでロール名をそのまま値に持つプロパティが5件ありました。

ロール名を値に持つ形式が5件ある点は、姉妹編のIncident側のプロパティ群には見られない特徴です。誰が再分析・再アセス・紐づけを行えるかを、スクリプトの条件式ではなくプロパティの値として持たせています。担当を変えるとき、ロールの付け替えとあわせてこの値も見直す対象になります。

残りは項目名をカンマ区切りで並べたリスト型が4件、単一の項目名を指すものが1件、KBのsys_idを指すものが1件です。動作の材料をプロパティとして外に出す設計は共通しています。要件が変わっても、スクリプトを触らずに済みます。

• 参考：ServiceNowの自動処理はどこに書く？ Business Rule / Client Script / Script Include / Flow の役割と判断基準 … プロパティとスクリプトの使い分け

Incidentとの連携に関連するプロパティ

Incidentから問題を起票する流れは、5件のプロパティで制御されています。

com.snc.problem.create_from_incident.attributes の既定値には12項目が並んでいます。

description, short_description, cmdb_ci, impact, urgency, priority,
company, sys_domain, business_service, service_offering, category, subcategory

公式説明はこうです。

（訳: Incidentから新しいProblemを作成するとき複製される項目のリスト（カンマ区切り））

引用元: /sys_properties_list.do?sysparm_query=name=com.snc.problem.create_from_incident.attributes

引き継がれるのは原因調査に必要な項目だけです。状態・担当者・作業メモ・解決情報は引き継がれません。新しい1件として始まります。添付ファイルも copy_attachments がtrueのため一緒に引き継がれます。

• 参考：ServiceNowの添付ファイルはDBのどこに保存される？ sys_attachmentの内部構造 … 添付ファイルの実体

incident.problem_idという項目名がプロパティの値として現役

もう1件、興味深いプロパティがあります。

com.snc.incident.link_to_task.problem の値は problem_id という文字列そのものです。

（訳: これは、Problem画面のIncident関連リストで「Add」UI Actionの機能を得るためのものである）

もう1件、重複マーク時に動くプロパティにも同じ名前が出てきます。

problem.duplicate.records_to_move の値には incident.problem_id がそのまま含まれています。

（訳: あるProblemが別のProblemの重複としてマークされたとき、移動する関連タスクレコードのリスト（カンマ区切り））

引用元: /sys_properties_list.do?sysparm_query=name=problem.duplicate.records_to_move

incident.problem_id は sys_dictionary にも sys_dictionary_override にも存在しません。REST APIで項目名を指定してもキーが返りません。それでもこの2件のプロパティの値には、今も現役の項目名として書かれています。辞書・ACL・Business Ruleに続き、プロパティという4つ目の層でも同じ名前が確認できました。

最後に、クローズ済みのIncidentを後からProblemへ紐づける操作も、プロパティで制御されています。problem.role.relate_closed_incidents の既定値は problem_coordinator でした。

（訳: クローズ済みのIncidentをProblemに紐づけられるのは誰か）

• 参考：ServiceNow 問題管理（Problem）完全ガイド：Incidentとの違いとKnown Errorまでの流れ … 連携先のプロセス全体

インタラクションからの起票に関連するプロパティ

電話やチャットの問い合わせ（インタラクション）からProblemを作る経路にも、専用のプロパティがあります。

プロパティ既定値意味glide.problem.interaction.allow_createfalseインタラクションからのProblem作成を許可するかcom.snc.problem.create_from_interaction.savetrue作成するとき、下書きでなく保存済みの状態にするか

glide.problem.interaction.allow_create の公式説明です。

（訳: インタラクションからのProblem作成を許可する）

既定値はfalseです。インタラクション画面から直接Problemを起票する経路は、閉じられています。

もう1件のプロパティは逆にtrueでした。

（訳: 保存済みのProblemを作成する）

com.snc.problem.create_from_interaction.save はtrueです。作成経路そのものは閉じているのに、開けたときの挙動（下書きでなく保存済みで作る）だけは、すでに用意されています。

この組み合わせから読み取れるのは、インタラクション連携の実装が済んでいて、運用判断としてOFFにされている状態です。将来この経路を有効化するときは、下書き段階を挟まずいきなり保存済みのProblemが増える点を、先に運用担当へ伝えておきます。

引用元: /sys_properties_list.do?sysparm_query=nameINglide.problem.interaction.allow_create,com.snc.problem.create_from_interaction.save

Problem Modelに関連するプロパティ

第2巻で確認した prb_model の既定値は、ProblemModel.getDefaultModelValue(current) というスクリプトで決まっていました。このモデル機能そのものを有効にするかどうかも、1件のプロパティで制御されています。

problem_management.models.enabled の公式説明です。

（訳: 変更前にKB1638519を読むこと。Problem管理のモデル機能を有効にする設定である。有効にすると、ProblemとProblem Taskの新規レコードは、Problem ModelとProblem Task Modelだけに従うようになる。モデルを使っていない従来のProblemは、これまでのガイド付きライフサイクルに従い続ける。）

既定値はtrueです。新規作成分と既存分でライフサイクルの管理方式が分かれる、という説明が公式のWARNINGとして明記されています。変更する前にKB記事を読むよう名指しで指示されているプロパティは、19件の中でこの1件だけでした。

引用元: /sys_properties_list.do?sysparm_query=name=problem_management.models.enabled

• 参考：共通ロジックをまとめて呼ぶ（Script Include） … ProblemModelのようなスクリプトの置き場

クローズ・再分析のガバナンスに関連するプロパティ

Problemがクローズ・キャンセルされたあと、誰がどこまで手を戻せるかは、6件のプロパティで統制されています。

problem.acceptrisk.move_to_closed の公式説明です。

（訳: Accept Riskを選ぶと、ProblemはResolvedでなくClosedの状態へ進む）

既定値はtrueです。リスクを受容して終える案件は、Resolvedの段階を経由しません。

クローズと同時に動く設定もあります。

（訳: Problemをクローズするとき、未完了のProblem Taskをキャンセルする）

problem.closed.cancel_open_tasks もtrueです。親を閉じれば、ぶら下がる調査タスクも自動でキャンセルされます。クローズ後の新規作成は許可されていません。

（訳: クローズ済みのProblem上でProblem Taskを作成できるか）

problem.closed.can_create_tasks の既定値はfalseです。

再分析（Re-Analyze）の権限を見ます。

problem.closed.role.reanalyze_from_completed の公式説明です。

（訳: 完了したProblemを再分析できるのは誰か）

既定値は problem_manager でした。Canceledから戻す場合も、Risk Accepted（Closed扱い）から戻す場合も、指定されているロールは同じ problem_manager です。3パターンいずれの再分析も、1つのロールに集約されています。

第3巻で確認したとおり、problem_manager の保持者はPDI上で3人だけでした。クローズ済みのProblemを再び動かす操作は、限られた人数にしか渡っていない設計です。担当者を広げるかどうかは、この3件のプロパティのロール値を変更するかどうかの判断になります。

• 参考：ServiceNowで付けたロールが想定外の権限を含んでいた理由 sys_user_role_containsで包含を実機でたどる … ロールの包含関係の調べ方

Problem Taskの再分析に関連するプロパティ

Problem Task側にも、似た名前の再分析（Reassess）に関するプロパティがあります。

プロパティ既定値意味problem_task.closed.can_reassess_on_closed_problemfalseクローズ済みのProblem上でProblem Taskを再アセスできるかproblem_task.closed.role.reaassess_from_closedproblem_coordinatorクローズ・キャンセル済みのProblem Taskを再アセスできるロール

（訳: クローズ済みのProblem上でProblem Taskを再アセスできるか）

problem_task.closed.can_reassess_on_closed_problem はfalseです。親のProblemがすでにクローズされている場合、その下のProblem Taskだけを個別に再アセスする経路は閉じられています。

（訳: 完了またはキャンセル済みのProblem Taskを再アセスできるのは誰か）

problem_task.closed.role.reaassess_from_closed の既定値は problem_coordinator です。

Problem本体の再分析は problem_manager、Problem Taskの再アセスは1段下の problem_coordinator でした。第3巻のロール階層で見た problem_manager から problem_coordinator への包含関係と対応します。戻す操作の重さに応じて、権限の階層も1段ずつ変わる設計です。

Known Error・Fix追跡に関連するプロパティ

Known Error（原因が特定済みで恒久対策のまだ無い状態）に関する記事の格納先と、修正の追跡先も、プロパティで指定されています。

problem.knowledgebase.known_error_article の公式説明です。

（訳: Known Error記事を作成する対象となるナレッジベースのsys_id）

値はKBのsys_idそのものでした。ナレッジベースの名称までは本記事のクエリ範囲では確認していません。

• 参考：ナレッジ記事はどこに置かれ、誰の承認で公開され、誰に見えるか … 記事の置き場と公開範囲

もう1件、修正の追跡先を指定するプロパティがあります。

（訳: このProblemの修正として追跡する関連タスクレコードのリスト。関連する修正レコードがすべて完了またはキャンセルになったとき、コーディネーターへ通知するために使われる）

problem.fix.records の既定値には5つのテーブルが並びます。

change_request.parent, rm_defect.parent, rm_release.parent,
rm_enhancement.parent, sn_cim_register.source_id

対象はChange Request・不具合（Defect）・リリース・機能拡張（Enhancement）・CIM（継続的改善）の登録という5種類です。異なる仕組みが「Problemの修正」として横断的に追跡されます。恒久対策は1つの経路に限らず、変更管理からCIMまで複数のモジュールにまたがって進む前提で設計されていると読み取れます。

引用元: /sys_properties_list.do?sysparm_query=name=problem.fix.records

• 参考：Change Request：typeで承認が変わる（change_request） … change_request.parentの参照先

• 参考：ServiceNowのCIMはIncidentやProblemとどうつながる？ 他モジュールから改善案を起票する仕組み … sn_cim_register.source_idの参照先

アクティビティ表示に関連するプロパティ

Problemの画面下部に出る履歴欄（アクティビティ）も、プロパティで制御されています。

glide.ui.problem_activity.fields の公式説明です。

（訳: Problemのアクティビティ表示の書式を決める項目）

既定値には assignment_group, assigned_to, business_service, cmdb_ci, state, impact, urgency, priority など19項目が並びます。状態・担当・影響度・緊急度といった、経緯を追うのに必要な項目が選ばれています。

この値に項目を足すと、その項目の変更履歴がアクティビティ欄に出るようになります。減らせばノイズが減る仕組みです。すべての項目を出すと、システムが自動更新する項目まで並んで読みにくくなります。何を履歴として見せるかは、運用の設計事項です。

引用元: /sys_properties_list.do?sysparm_query=name=glide.ui.problem_activity.fields

プロパティを変更する前の確認事項

19件のうち、実際に触る機会が多いものを整理しました。

変更する前に、次の3点を確認します。

1. 説明文を読む：19件全件に公式説明があります。値の意味を推測で決めません

2. 値に並ぶロール名・項目名の実在：カンマ区切りのリスト型も、ロール名を値に持つ型も、存在しない名前を入れても素通りします

3. 変更の記録：プロパティの変更は更新セットに入ります。移送の対象になるかを確認します

プロパティは画面から1行変えるだけで挙動が変わります。手軽な反面、変更の理由が残りません。誰がなぜ変えたかを別途記録する運用を決めておくと、後任者が困りません。

実機で気づいたこと

incident.problem_idという辞書に無い項目名が、プロパティの値としては今も現役

com.snc.incident.link_to_task.problem の値は problem_id そのものです。problem.duplicate.records_to_move の値にも incident.problem_id が含まれます。

第2巻で確認したとおり、incident.problem_id は sys_dictionary にも sys_dictionary_override にも存在せず、REST APIのフィールド一覧にも出てきません。それでもACL・Business Rule・プロパティという3つの層では、この名前が動く設定として使われ続けています。

自社の環境で「このフィールドは存在しない」と辞書だけを見て判断すると、プロパティの値やACL名に同じ名前が残っている事実を見落とします。項目の実在を調べるときは、辞書に加えてプロパティの値まで検索する習慣が要ります。

インタラクションからの起票は閉じているが、開けたときの挙動だけ先に用意されている

glide.problem.interaction.allow_create はfalse、com.snc.problem.create_from_interaction.save はtrueでした。作成経路そのものは閉じているのに、開いたときの挙動（保存済みで作る）だけがすでに設定されています。

未使用のプラグイン設定が同梱されている、というだけの話ではありません。将来この経路を有効化する計画があるなら、下書きを挟まず保存済みのProblemがいきなり増える点を、事前にテスト環境で確認してから本番へ反映する進め方が安全です。

再分析の権限は、戻す操作の重さに応じて1段ずつ変わる

Problem本体の再分析は、Canceled・Risk Accepted・Completedの3パターンいずれも problem_manager に統一されていました。Problem Taskの再アセスは1段下の problem_coordinator です。

第3巻で確認した problem_manager から problem_coordinator への包含関係と、この権限の重心の置き方が一致します。Problem本体を終了状態から戻す操作は最上位の管理ロールに、個々の調査タスクを終了状態から戻す操作はその下の調整ロールに、それぞれ委ねられています。

権限設計を相談されたときは、この段差をそのまま参考にできます。上位ロールを増やさず、対象がProblem本体かProblem Taskかで委譲する範囲を1段ずつ分けます。

プロパティを調整するときの検討順序

プロパティを調整するとき、確認する順序を決めておくと迷いません。

1. 説明文を読む：19件全件に公式説明がある。値を変える前に意図を確認する

2. Incidentからの引き継ぎ項目：create_from_incident.attributes の12項目を自社の運用に合わせる

3. 重複マーク時の移動先：duplicate.records_to_move に含まれる incident.problem_id の挙動を確認する

4. 再分析の権限範囲：closed.role.reanalyze_from_* の3件を、problem_manager のままにするか検討する

5. クローズ時のタスク処理：closed.cancel_open_tasks を有効のまま使うか決める

6. Problem Model機能：problem_management.models.enabled を変更する前にKB1638519を読む

7. インタラクション連携：interaction.allow_create を有効化する計画があるかを確認する

8. アクティビティの表示項目：履歴に出す項目を絞り、ノイズを減らす

用語

• OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態

• PDI：Personal Developer Instance。ServiceNowが無償で提供する個人検証用インスタンス

• システムプロパティ：sys_properties。インスタンス全体の設定値を保持するテーブル

• Problem Model：状態遷移をテンプレート化して管理する、Problem管理の追加機能

• Known Error：原因が特定済みで回避策はあるが、恒久対策がまだ無い状態のProblem

• Reassess / Re-Analyze：クローズ・キャンセル済みのレコードを、調査段階へ戻す操作

検証範囲とおことわり

• 検証環境：Australia PDI（patch3）/ OOTB / 2026-08-31 確認

• 件数と既定値はすべてOOTBの状態です。本番環境やカスタマイズ済み環境では異なります

• プロパティを実際に変更して挙動が変わることは確認していません

• problem.knowledgebase.known_error_article が指すナレッジベースの名称までは確認していません

• 各プロパティを読んでいるスクリプトの実装は、本シリーズ第6巻「問題管理モジュールの自動設定構成」で扱います

• Incidentとの連携の全体像は、本シリーズ第8巻「問題管理モジュールの連携機能」で扱います

付録：自分の環境で確認するときのURL

• problem関連のプロパティ：/sys_properties_list.do?sysparm_query=nameLIKEproblem

• 型ごとの件数：/sys_properties_list.do?sysparm_query=nameLIKEproblem^GROUPBYtype

• Incident連携のプロパティ：/sys_properties_list.do?sysparm_query=name=com.snc.problem.create_from_incident.attributes

• 重複マーク時の移動先：/sys_properties_list.do?sysparm_query=name=problem.duplicate.records_to_move

• 再分析の権限3件：/sys_properties_list.do?sysparm_query=nameLIKEclosed.role.reanalyze

• インタラクション関連2件：/sys_properties_list.do?sysparm_query=nameINglide.problem.interaction.allow_create,com.snc.problem.create_from_interaction.save

引用した公式説明を実機で確認する方法

この記事で引用した説明文は、ServiceNowが製品に同梱しているプロパティの説明です。次のURLを自分のインスタンスで開くと、同じ記述が見つかります。

• プロパティの公式説明（引用元）：/sys_properties_list.do?sysparm_query=nameLIKEproblem^descriptionISNOTEMPTY

関連記事

• システムプロパティ（sys_properties）は設定値の置き場 … プロパティそのものの扱い方

• ServiceNow 問題管理（Problem）完全ガイド：Incidentとの違いとKnown Errorまでの流れ … 連携先のプロセス全体

• ServiceNowのCIMはIncidentやProblemとどうつながる？ 他モジュールから改善案を起票する仕組み … fix.recordsの参照先の1つ