インシデント管理モジュールのプロパティ
「インシデントを複製したとき、どの項目が引き継がれるのか」「問題を起票したとき添付は付いてくるのか」。こうした挙動は、コードではなくシステムプロパティで決まります。Australia の PDI をデフォルト設定のまま開き、incident に関わる37件のプロパティが何を制御しているかを確かめました。36件には公式の説明文が付いています。
検証環境：Australia PDI / OOTB / 2026-08-31 確認
この記事の範囲
incident に関わるシステムプロパティが何件あり、どう分類できるか
インシデントを複製したとき何が引き継がれるか
問題管理との連携で自動的に動く設定
既定で無効になっている設定
アクティビティ欄の見た目を変える方法
プロパティで変えられること
インシデントを複製したとき、どの項目・添付・関連リストを引き継ぐか
問題管理で決まった回避策を、関連インシデントの作業メモへ自動で流すか
自動クローズの基準日を、解決日にするか最終更新日にするか
影響を受けたサービスを自動で埋めるか（既定は無効）
アクティビティ欄に、どの項目の変更履歴を出すか
プロパティで何が変えられるか
incident に関わるシステムプロパティを開くと、コードを触らずに変えられる挙動が並んでいます。
代表的なものを挙げます。
複製の挙動を決める
com.snc.incident.copy.attributes には、Copy Incident で引き継ぐ項目が18個並んでいます。担当グループ・分類・影響度・緊急度・対象CIなど、「同じ障害の別件」を作るのに必要な項目です。状態・担当者・作業メモは引き継がれません。
この値を書き換えれば、複製の挙動が変わります。スクリプトを触る必要はありません。
他プロセスとの連動を決める
com.snc.incident.communicate_prb_workaround_to_inc_worknotes が true のとき、問題管理で回避策が決まると、関連するインシデントの作業メモへ自動で転記されます。担当者が問題側を見に行かなくても、手元に回避策が届きます。
com.snc.incident.incident_task.closure は、インシデントを閉じたときに作業タスクも閉じるかを決めます。閉じ忘れた作業タスクが残る事態を防ぐ設定です。
クローズの判断を決める
com.snc.incident.autoclose.basedon.resolved_at は、自動クローズの基準日を選びます。true なら解決日、false なら最終更新日です。
解決後に利用者から問い合わせが入り、作業メモを追記した場合、最終更新日は延びます。解決日基準なら予定どおり閉じ、更新日基準なら閉じるのが遅れます。どちらを採るかで、滞留件数の見え方が変わります。
表示の見た目を決める
glide.ui.incident_activity.style.work_notes は作業メモの背景色を指定します。既定は LightGoldenRodYellow。利用者向けコメントは WhiteSmoke で、色で2種類を区別する設計です。
作業メモを誤って利用者向けコメントに書く事故を減らす仕掛けになっています。
公式の説明文が付いている
37件のうち36件に description（公式の説明文）が入っていました。
説明が入っていない1件は com.glide.cs.rich_converter_incident_html で、値がHTMLテンプレートそのものでした。
設定値の意味が分からないときは、まず description を読みます。推測で値を変えると、意図しない挙動を招きます。
参考：システムプロパティ（sys_properties）は設定値の置き場 … プロパティ全体の扱い方
プロパティの分類
37件を役割ごとに分けると、7つのまとまりになります。
型で分けると、真偽値（true/false）と、項目名をカンマ区切りで並べたリストの2種類が中心でした。
項目名をリストで持つ形式が多い点が特徴です。「何を引き継ぐか」をコードに埋め込まず、プロパティの値として外に出しています。要件が変わったときに、スクリプトを触らずに済みます。
この設計には利点と注意点の両方があります。利点は変更の手軽さ。管理画面から1行書き換えるだけで挙動が変わり、開発者の手を借りずに調整できます。
注意点は検証がないこと。項目名を打ち間違えても、存在しない項目を書いても、エラーになりません。指定が無視されるだけです。「設定したのに反映されない」と感じたときは、まず値のスペルと項目の実在を確認します。
もう1つ、プロパティはインスタンス全体に効きます。特定の部門だけ挙動を変えたい場合には向きません。その場合はビジネスルールの条件で分ける設計になります。
複製（Copy Incident）に関連するプロパティ
Copy Incident の UI アクションを押したとき、何が複製されるかは7件のプロパティで決まります。
com.snc.incident.copy.attributes の既定値には18項目が並んでいます。
assignment_group, business_service, category, caused_by, cmdb_ci, company,
description, impact, location, parent_incident, problem_id, rfc,
short_description, subcategory, urgency, priority, service_offering公式説明はこうです。
List of attributes (comma-separated) that will be copied from the originating incident
（訳: 元のインシデントから複製される項目のリスト（カンマ区切り））
引用元: /sys_properties_list.do?sysparm_query=name=com.snc.incident.copy.attributes
複製されるのは「同じ障害の別件を作る」ために必要な項目だけです。状態・担当者・作業メモ・解決情報・番号は引き継がれません。新しい1件として始まります。
関連リストも4種類が複製対象でした。影響CI（task_ci）、影響サービス（task_cmdb_ci_service）、サービスオファリング（task_service_offering）、業務アプリケーション（task_cmdb_ci_business_app）です。それぞれ「どの項目を複製するか」が別のプロパティで指定されています。
参考：サービスもCIになる（cmdb_ci_service） … 影響サービスの実体
子インシデントに関連するプロパティ
大規模障害を1件に束ねるとき、親子関係を使います。
プロパティ既定値意味com.snc.incident.create.child.enabletrue子インシデントの作成機能を使えるようにするcom.snc.incident.copy_comments_to_non_resolved_childInctrue親のコメントを、未解決の子インシデントすべてに転記する
2つ目が運用に効きます。公式説明を引用します。
Allow to copy comments from parent to all non-resolved child incidents.
（訳: 親から、未解決のすべての子インシデントへコメントを複製することを許可する）
大規模障害では、親1件に状況を書けば、子の全件に同じ内容が届きます。利用者ごとに個別連絡する手間がなくなります。解決済みの子には転記されません。すでに終わった件に古い情報が届くのを避ける設計です。
問題管理との連携に関連するプロパティ
インシデントから問題を起票する流れは、5件のプロパティで制御されています。
com.snc.problem.create_from_incident.attributes の既定値は description, short_description, cmdb_ci, impact などです。インシデントの内容をそのまま問題へ持ち込みます。添付も copy_attachments = true で引き継がれます。
逆向きの連携もあります。
When set true, all the communication from problem record will be journeled in worknotes field in related incident.
（訳: true に設定すると、問題レコードからのすべての連絡が、関連インシデントの作業メモ欄に記録される）
com.snc.incident.communicate_prb_workaround_to_inc_worknotes の説明です。問題管理で回避策が決まると、関連するインシデントの作業メモへ自動で流れます。担当者が問題側を見に行かなくても、手元に回避策が届きます。
problem.role.relate_closed_incidents の既定値は problem_coordinator でした。
Who can relate closed Incidents to a Problem?
（訳: クローズ済みのインシデントを問題に紐づけられるのは誰か）
クローズ済みの案件を後から問題へ紐づける操作は、problem_coordinator ロールに限定されています。
影響サービス・CIの自動更新に関連するプロパティ
影響を受けたサービスやCIを自動で埋める設定が4件あります。うち3件が false でした。
プロパティ既定値意味com.snc.incident.populate_business_applicationfalse業務アプリケーションの関連リストを自動で埋めるかcom.snc.incident.populate_service_offeringfalseサービスオファリングの関連リストを自動で埋めるかcom.snc.incident.refresh_impacted.include_affected_cisfalse影響CIから影響サービスを割り出すかcom.snc.incident.refresh_impacted.eventtrue更新をイベント経由で非同期に実行するか
CMDB を整備していない環境で自動更新を有効にすると、誤った関連付けが大量に作られます。既定で無効なのは、CMDB の完成度に依存する機能だからです。
有効にする前に、CI とサービスの関係が正しく登録されているかを確認します。refresh_impacted.event は true が既定。有効化した場合の処理は背景で実行されるため、画面はすぐ返る一方、関連リストが埋まるまでに時間差が出ます。
参考：ServiceNowのCIはどのテーブルに入る？ cmdb_ciの102クラスを実機で確認 … CMDB 側の構造
アクティビティ表示に関連するプロパティ
インシデントの画面下部に出る履歴欄（アクティビティ）も、プロパティで制御されています。
glide.ui.incident_activity.fields の既定値には assigned_to, cmdb_ci, incident_state, impact, priority などが並びます。
List of fields (comma-separated) that appear in the activity formatter for Incident.
（訳: インシデントのアクティビティ表示に現れる項目のリスト（カンマ区切り））
この値に項目を足すと、その項目の変更履歴がアクティビティ欄に出るようになります。逆に減らせばノイズが減る仕組み。
既定では担当者・CI・状態・影響度・優先度といった、経緯を追うのに必要な項目が選ばれています。すべての項目を出すと、システムが自動更新する項目まで並んで読みにくくなります。何を履歴として見せるかは、運用の設計事項です。
色の設定も分かれています。利用者向けコメントは WhiteSmoke、作業メモは LightGoldenRodYellow です。見た目で2種類を区別する設計になっています。作業メモを誤って利用者向けコメントに書く事故を減らす仕掛けです。
参考：Comments/Work notes（sys_journal_field）は1追記1行 … 追記の保存先
自動クローズに関連するプロパティ
解決したインシデントを自動でクローズする機能があり、その基準日をプロパティで選べます。
Enable auto closure of incidents based on Resolution date. Setting this to 'No' will make auto closure to run based on the last updated date.
（訳: 解決日にもとづくインシデントの自動クローズを有効にする。'No' に設定すると、最終更新日にもとづいて自動クローズが実行される）
com.snc.incident.autoclose.basedon.resolved_at の説明です。既定は true で、解決日を基準にします。
false にすると最終更新日が基準になります。この違いは実務で差が出る箇所。解決後に利用者から問い合わせが入り、作業メモを追記した場合、最終更新日は延びます。解決日基準なら予定どおり閉じ、更新日基準なら閉じるのが遅れます。
もう1件、com.snc.incident.incident_task.closure が true でした。
Close open Incident Tasks when Incident is closed or canceled.
（訳: インシデントがクローズまたは取り消しになったとき、開いているインシデントタスクを閉じる）
親を閉じれば、ぶら下がる作業タスクも自動で閉じます。作業タスクだけ開いたまま残る事態を防ぐ設定です。
この2件は組み合わせて効きます。自動クローズが解決日を基準に実行され、その時点で開いている作業タスクも一緒に閉じられる流れ。作業タスクを個別に管理したい運用なら、incident_task.closure を false にする選択もあります。ただし閉じ忘れた作業タスクが残り続けるため、別途の棚卸しが必要になります。
メールからの再オープンに関連するプロパティ
com.snc.incident.clone_fields_on_reopen は、メール経由で再オープンされたときに元の内容を引き継ぐ設定です。
List of fields (comma-separated) to copy from the original incident when an incident is reopened by email.
（訳: メールでインシデントが再オープンされたとき、元のインシデントから複製する項目のリスト（カンマ区切り））
既定値には additional_assignee_list, assignment_group, business_service などが並びます。利用者が「まだ直っていません」と返信したとき、担当グループや対象サービスを引き継いだまま再開できます。
再オープンのたびに担当を割り当て直す運用なら、この値から assignment_group を外します。
参考：受信メールでチケットが立つ仕組み（Inbound Email Action） … メールからの起票と更新の経路
他機能からの起票に関連するプロパティ
インシデントは、フォーム以外の経路からも作られます。関係するプロパティが3件ありました。
プロパティ既定値経路glide.knowman.create_incident_link.displaytrueナレッジ記事から「Create Incident」リンクを出すglide.knowman.create_incident_linkURL文字列そのリンクの遷移先com.snc.incident.create_from_interaction.savetrueインタラクション（問い合わせ）から保存済み状態で作る
ナレッジ記事を読んでも解決しなかった利用者が、その場でインシデントを起票できる導線です。リンクのURLもプロパティで指定されているため、遷移先の初期条件を変えられます。
インタラクションからの起票は save = true が既定です。下書きではなく保存済みの状態でインシデントが作られます。
参考：ServiceNowの問い合わせはいつチケットにする？ InteractionからIncidentへ上げる流れを実機で追う … 問い合わせからの昇格の流れ
問題管理側に置かれているプロパティ
インシデントとの連携は、問題管理側のプロパティにも書かれています。
com.snc.problem で始まるプロパティを見ると、インシデントから問題を作る流れが問題管理側で定義されていることが分かります。引き継ぐ項目も添付の扱いも、問題管理のプロパティが決めています。
設定を探すとき、この置き場所の違いが手間になります。「インシデントから問題を作るときの挙動」を調べたいのに、nameLIKEincident では見つかりません。連携の設定は受け取る側のプロパティに置かれている場合があります。
両方を検索する習慣をつけると、探し漏れが減ります。
インシデント管理以外の機能が使うプロパティ
37件のうち4件は、インシデント管理そのものではなく、別機能がインシデントを使うための設定でした。
プロパティ既定値何のためのものかpassword_reset.activity_monitor.incident_threshold10ブロックされたユーザーが何人でシステムログのイベントを起こすかpassword_reset.activity_monitor.incident_window60上の人数を数える時間の幅（分）glide.platform_ml.agent_zero.override_incident_max_limit30000機械学習が読むインシデントの最大件数glide.platform_ml.agent_zero.override_incident_encoded_query条件式機械学習が読むインシデントの絞り込み条件
パスワードリセットの監視は、60分の間に10人がブロックされたらイベントを起こす設定です。攻撃の兆候を検知する仕組みで、名前に incident が入っていますが、インシデントレコードを作るわけではありません。
機械学習（Agent Zero）は、過去のインシデントを学習データとして読みます。上限は3万件。読む対象を絞る条件式もプロパティで指定されています。
既定の条件式は short_descriptionISNOTEMPTY から始まっていました。短い説明が空のレコードを学習から外す指定です。内容のないレコードを学習させても精度が上がらないため、あらかじめ除いています。
学習の精度を上げたいときは、この条件式を自社のデータに合わせます。分類が正しく入っている期間だけに絞る、テスト用のレコードを除く、といった調整が考えられます。3万件という上限も、データ量に応じて見直す対象です。
名前に incident が入っているプロパティが、すべてインシデント管理の設定とは限りません。役割を確認してから触ります。
参考：ServiceNow ナレッジ管理（Knowledge）完全ガイド：記事はどこに置かれ、誰の承認で公開され、誰に見えるか … ナレッジからの起票の前段
一斉連絡の宛先に関連するプロパティ
大規模障害では、影響を受けた利用者へまとめて連絡する機能（Incident Communication Plan）が使えます。その宛先を集めるとき、特定のテーブルを除外する設定がありました。
com.snc.incident.communication_recipients_excluded_tables の既定値は customer_contact です。
Excluded Tables for picking up recipients for Incident Communication Plans
（訳: インシデント通信計画の宛先を拾うときに除外するテーブル）
顧客連絡先（customer_contact）を宛先から外す設定になっています。社内障害の連絡が、顧客側の担当者に届くのを防ぐ既定値です。
自社で利用者情報を別テーブルに持っている場合、この値に足すかどうかを検討します。宛先の範囲は、障害連絡の事故に直結する箇所です。
プロパティを変更する前の確認事項
37件のうち、実際に触る機会が多いものを整理しました。
変更する前に、次の3点を確認します。
説明文を読む：36件に公式説明があります。値の意味を推測で決めません
値に並ぶ項目名の実在：カンマ区切りのリスト型は、存在しない項目名が入っていても素通りします
変更の記録：プロパティの変更は更新セットに入ります。移送の対象になるかを確認します
プロパティは画面から1行変えるだけで挙動が変わります。手軽な反面、変更の理由が残りません。誰がなぜ変えたかを別途記録する運用を決めておくと、後任者が困りません。
実機で気づいたこと
存在しない項目名がプロパティに残っている
com.snc.incident.copy.attributes の既定値には problem_id と rfc が含まれます。ところが Australia のデフォルト環境の incident には、この2項目が存在しません。
プロパティの値は文字列のリストとして保持され、内容は検証されません。存在しない項目名を書いてもエラーにならず、指定が無視されるだけです。他のプラグイン構成向けの既定値が、そのまま同梱されていると考えられます。
複製の挙動を調整するときは、値に並ぶ項目名が自分の環境に実在するかを先に確認します。「引き継がれるはず」と誤解したまま設計を進めると、テストの段階で食い違いが判明します。
連携の設定が受け取る側に置かれている
インシデントから問題を作るときの挙動は、com.snc.problem で始まるプロパティが決めています。引き継ぐ項目も添付の扱いも、問題管理側の設定です。
連携の設定は、動作を受け取る側のモジュールに置かれる構成になっています。データが流れ込む先が、その内容を決める考え方です。
設定を探すとき、この置き場所の違いが手間になります。nameLIKEincident だけでは見つからないためです。連携に関わる設定を調べるときは、相手側のモジュール名でも検索してください。
名前に incident が入っていても無関係な設定がある
37件のうち4件は、インシデント管理そのものではありませんでした。パスワードリセットの監視2件と、機械学習（Agent Zero）の設定2件です。
パスワードリセットの監視は、60分間に10人がブロックされたらシステムログのイベントを起こす設定でした。攻撃の兆候を検知する仕組みで、インシデントレコードを作るわけではありません。
プロパティを棚卸しするとき、名前だけで対象を決めないようにします。description を読んで役割を確認してから触るのが安全です。37件のうち36件に説明文があるため、確認の手間は小さく済みます。
影響サービスの自動更新が既定で止まっている
populate_service_offering と populate_business_application はどちらも false でした。refresh_impacted.include_affected_cis も false です。
CMDB の完成度に依存する機能だからだと読み取れます。CI とサービスの関係が正しく登録されていない環境で有効にすると、誤った関連付けが大量に作られます。
CMDB の整備が済んでから有効化します。有効にした場合、refresh_impacted.event が true のため処理は背景で実行される形です。画面上ですぐ結果が見えない点を、運用担当に伝えておきます。
プロパティを調整するときの検討順序
プロパティを調整するとき、確認する順序を決めておくと迷いません。
説明文を読む：36件に公式説明がある。値を変える前に意図を確認する
複製の対象項目：copy.attributes の18項目を自社の運用に合わせる
問題連携の引き継ぎ項目：create_from_incident.attributes を調整する
回避策の転記：communicate_prb_workaround_to_inc_worknotes を有効のまま使うか決める
影響サービスの自動更新：CMDB の完成度を確認してから有効化する
自動クローズの基準日：解決日と最終更新日のどちらを使うか決める
アクティビティの表示項目：履歴に出す項目を絞り、ノイズを減らす
再オープン時の引き継ぎ：担当を維持するか、割り当て直すかを決める
用語
OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態
PDI：Personal Developer Instance。ServiceNow が無償で提供する個人検証用インスタンス
システムプロパティ：sys_properties。インスタンス全体の設定値を保持するテーブル
アクティビティ：フォーム下部に出る変更履歴と追記の一覧
インタラクション：電話やチャットの問い合わせを1件として記録する仕組み
検証範囲とおことわり
検証環境：Australia PDI（patch3）/ OOTB / 2026-08-31 確認
件数と既定値はすべて OOTB の状態です。本番環境やカスタマイズ済み環境では異なります
プロパティを実際に変更して挙動が変わることは確認していません
com.glide.cs.rich_converter_incident_html の内容までは追っていません
各プロパティを読んでいるスクリプトの実装は、本シリーズ第6巻「インシデント管理モジュールの自動設定構成」で扱います
問題・変更との連携の全体像は、本シリーズ第8巻「インシデント管理モジュールの連携機能」で扱います
付録：自分の環境で確認するときのURL
incident 関連のプロパティ：/sys_properties_list.do?sysparm_query=nameLIKEincident
説明が入っているものだけ：/sys_properties_list.do?sysparm_query=nameLIKEincident^descriptionISNOTEMPTY
複製の対象項目：/sys_properties_list.do?sysparm_query=name=com.snc.incident.copy.attributes
型ごとの件数：/sys_properties_list.do?sysparm_query=nameLIKEincident^GROUPBYtype
問題管理側のプロパティ：/sys_properties_list.do?sysparm_query=nameLIKEcom.snc.problem
説明が入っているプロパティ全体：/sys_properties_list.do?sysparm_query=descriptionISNOTEMPTY
引用した公式説明を実機で確認する方法
この記事で引用した説明文は、ServiceNow が製品に同梱しているプロパティの説明です。次のURLを自分のインスタンスで開くと、同じ記述が見つかります。
プロパティの公式説明（引用元）：/sys_properties_list.do?sysparm_query=nameLIKEincident^descriptionISNOTEMPTY
