問題管理モジュールの基本設定
問題管理を導入するとき、Incidentの基本設定とは勝手が違う場面に出会います。状態の選択肢はIncidentより少なく、優先度はProblem専用のマトリクスで決まり、SLAの定義は1件もありません。Australia の PDI をデフォルト設定のまま開き、状態モデル・優先度・割り当て・通知・必須項目の制御がどう用意されているかを確かめました。
検証環境：Australia PDI / OOTB / 2026-08-31 確認
導入時に決めること
状態がstateとproblem_stateの二重管理になっている点
優先度がProblem専用のマトリクスからどう決まるか
SLAを定義するかどうかと、するなら何を測るか
割り当てルールが最初から有効になっている点
通知のevent_nameに実際に不備がある点
Known Error・Fix系の必須制御がどこで効くか
設定を決める前に知っておくこと
選択肢は状態6・優先度5・カテゴリ4・サブカテゴリ16・解決コード4で構成される
優先度はImpact×Urgencyの9通りから自動で決まり、Problemだけ5 - Planningまで自動で届く
割り当てルール3つは有効、SLA定義は0件、通知8件のうち2件に不備がある
選択肢の全体像
問題管理で選択肢を持つ項目は10件でした。
保存される型はIntegerとStringの2種類です。Integerで持つのはstate・problem_state・priority・impact・urgencyの5項目です。Stringで持つのはcategory・subcategory・resolution_codeの3項目に分かれます。known_errorとmajor_problemはBooleanで、選択肢自体を持ちません。
Incidentの選択肢11項目と比べると、Problemは項目数が少なく、カテゴリの選択肢も4種類とIncidentの6種類より絞られています。窓口側の分類が削られ、原因調査の対象を分ける項目だけが残った構成です。詳しくは次節以降で見ます。
参考：選択肢Choice（sys_choice）：ドロップダウンの中身 … 選択肢はここに保存される
状態はstateとproblem_stateの二重系になっている
問題管理の状態は、state という項目が持つ6段階です。value は101・102・103・104・106・107の順で並び、105だけが欠番でした。ラベルはNew・Assess・Root Cause Analysis・Fix in Progress・Resolved・Closedです。
ところが state とは別に、problem_state という整数のフィールドが存在します。選択肢は1つも定義されておらず、既定値は1です。フォームには出てきませんが、辞書には確かに存在します。
2つのフィールドは、2本のBusiness Ruleでスクリプトを介さずに値をそのままコピーし合います。1本目はstateの変更をproblem_stateへ、2本目はproblem_stateの変更をstateへ書き戻します。名前はCopy State to Problem State、Copy Problem State to Stateで、順序は0番目と1,000,000番目です。
実際のレコードで確認すると、24件全部で state と problem_state の値が一致していました。Closed（107）のレコードは problem_state も107、旧来の値（1・2）が残っている2件も problem_state が同じ1・2でした。problem_state は独立した番号体系を持たず、state をそのまま映す鏡になっています。
スクリプトや外部連携で problem_state を直接参照しているカスタマイズがあるなら、値の意味は101〜107と読み替えて構いません。逆に、古いドキュメントに1〜5番台の独自番号が書かれているなら、実データとは合っていないため見直しが必要です。
参考：ServiceNowの保存で実際に動くBusiness Ruleは何本か？ problemテーブルで定義と実測を比べる … 本節で見た同期の仕組みも含めて集計した記事
優先度はdl_problem_priorityという専用マトリクスで決まる
優先度も担当者が直接選ぶ設計ではありません。ImpactとUrgencyの組み合わせから、Problem専用のマトリクステーブル dl_problem_priority が優先度を導きます。Incidentの dl_u_priority とは別のテーブルで、由来のプラグインも異なる点が特徴です。dl_problem_priorityはProblem Management Best Practice - Jakartaが提供しています。
task.priority の公式説明はIncidentと共通です。
Sequence in which an Incident or Problem needs to be resolved, based on impact and urgency
（訳: インシデントまたは問題を解決すべき順序。影響度と緊急度にもとづく）
引用元: /sys_documentation_list.do?sysparm_query=name=task^element=priority
実際の対応表は dl_problem_priority という専用テーブルに9行で入っていました。
読み取れる設計方針は次のとおりです。
1 - Critical になるのは High × High の1通りだけ。Incidentと同じ絞り方
2 - High は2通り、4 - Low は2通り。ImpactとUrgencyは対称に扱われる
3 - Moderate だけが3通り。中間の組み合わせが最も広く受け止められる
参考：taskテーブル：ITSM全プロセスの共通の親 … priorityが継承される元テーブル
Problemのマトリクスだけが5 - Planningまで自動で届く
優先度の選択肢は5つあり、5 - Planning も含まれます。Incidentのマトリクスでは、この値はどの組み合わせからも導かれず、手動で選ぶときだけの値でした。Problemは違います。
Low × Low の組み合わせが、そのまま 5 - Planning に着地します。9通りの内訳はCritical1通り・High2通り・Moderate3通り・Low2通り・Planning1通りという山型の分布で、5段階すべてが自動計算だけで埋まります。この点は、本記事で新たに突き合わせたIncidentとの違いです。
自社でマトリクスを調整するときは、この山型をどう崩すかが検討点になります。影響度・緊急度がともに低いProblemを自動でPlanningまで落とし切ってよいか、それとも計画外の対応枠として別扱いにするかを決めます。
辞書の上書きを見ると、problem.priority の既定値は5（Planning）でした。task標準の既定値4（Low）より、さらに1段低い値に変更されています。新規のProblemはいったん最低優先度で作成され、ImpactとUrgencyが入力された時点でマトリクスが再計算して優先度が上がる、という流れです。problem_task にはこの上書きがなく、task標準の4のままでした。
カテゴリとサブカテゴリはIncidentより少ない
カテゴリは4種類でした。
Software・Hardware・Network・Databaseの4つで、Incidentにあった Inquiry / Help と Password Reset がありません。原因調査の対象を分類するための項目であるため、利用者からの問い合わせ窓口向けの分類は対象外になっていると読めます。
サブカテゴリは16件でした。
内訳はHardwareが6つで最多、Networkが5つ、Databaseが3つ、Softwareが2つです。分布はIncidentのHardware・Network・Database・Software分と完全に同じ値で、Inquiry / Help相当だけが丸ごと抜けています。ProblemはIncidentのカテゴリ体系をそのまま流用しつつ、原因調査に関係しない窓口系だけを外して作られたと考えられます。
自社でカテゴリを組み直すときは、IncidentとProblemで同じ分類名を使うかどうかを決めます。同じ名前をそろえておくと、IncidentからProblemを起票したときの引き継ぎが素直になります。
解決コード（Resolution code）
解決コード（resolution_code）は4種類でした。
Fix Applied：恒久対策を適用して解決した
Risk Accepted：リスクを受容し、恒久対策を適用せずに終えた
Canceled：対応を中止した
Duplicate：他のProblemと重複していた
Incidentの close_code が10種類だったのに対して、Problemは4種類だけです。件数が少ない分、どの値を選ぶかで運用の判断がはっきり分かれます。Risk Acceptedを選ぶと、後述のデータポリシーによってResolvedを飛ばしてClosedまで一気に進む設定になっています。
known_error の公式説明も見ておきます。
Root cause has been determined and there is a workaround but there is NO permanent fix
（訳: 原因は特定済みで回避策もあるが、恒久対策はまだ無い）
引用元: /sys_documentation_list.do?sysparm_query=nameINproblem,task^hintISNOTEMPTY
この説明とresolution_codeを重ねると、Known Errorは「回避策はあるが恒久対策がまだ無い」状態、Fix Appliedは「恒久対策を適用できた」状態と整理できます。Known Errorフラグを立てたままFix Appliedで閉じるケースがあれば、恒久対策が後から見つかった記録として扱えます。
参考：ServiceNow 問題管理（Problem）完全ガイド：Incidentとの違いとKnown Errorまでの流れ … Known Errorの扱い
参考：フォームのラベルはどこから出るか（sys_documentation） … 公式説明の格納場所
SLA定義は用意されていない
Incidentには13件のSLA定義がありました。問題管理には1件もありません。collection=problem・collection=problem_taskのどちらで探しても0件でした。
エスカレーションルール（sysrule_escalate）も0件で、滞留を自動検知する仕組みも用意されていません。Incidentは6件が定義済みでした（すべて無効でしたが、定義自体はありました）。Problemは定義そのものがありません。
これはモジュールの性格の違いによるもので、設定の抜けではありません。Incidentは利用者に対して応答・解決の期限を約束する対顧客プロセスで、Problemは根本原因を調べる社内の分析プロセスです。分析には調査の深さに応じた時間が必要で、一律の期限を切る発想になじみません。
SLAを自分で定義するなら、何を測るか
それでも、放置を防ぐ目安が欲しい場面はあります。定義するなら、Incidentと同じ「応答・解決」ではなく、Problem固有の区切りを測る方が実態に合います。
New→Root Cause Analysis入りまでの時間：調査に着手するまでの滞留を測る
Fix適用までの時間：恒久対策の実装が長期化していないかを測る
Known Error登録までの時間：回避策が周知されるまでの遅れを測る
優先度ごとに期限を変える設計もできます。1 - CriticalのProblemだけRCA着手までの期限を短く設定し、4 - Low・5 - Planningは期限を設けない、という段階分けです。contract_slaにcollection=problemのレコードを追加すれば、Incidentと同じ仕組みでタイマーを持たせられます。
導入するかどうかは、Problem担当チームの人数と件数次第です。件数が少ない環境では、SLAより週次のレビュー会で滞留を拾う方が運用負荷は小さくなります。
参考：SLA Definition（contract_sla）とは：時計を生むルール … 定義を追加する側のテーブル
参考：task_sla：1タスク1本のSLA時計の読み方 … 計測側のテーブル
参考：SLAが土日を飛ばす理由：営業時間（cmn_schedule） … 期限を定義するなら合わせて設定する対象
割り当てルールは、Incidentと逆にすべて有効
担当を自動で決めるルールが3つ用意されていました。
ルール名振分先条件Database ProblemDatabaseCIのクラスがcmdb_ci_databaseSoftware ProblemSoftwareBusiness ServiceがSoftware相当Network ProblemNetworkCIのクラスがネットワーク機器系
3つとも active=true でした。本シリーズのIncident編で確認した割り当てルール3つは、いずれも active=false でした。Problemはこの点でIncidentと逆になっています。
導入時に何もしなければ、CIがDatabase・Software・Networkのいずれかに分類されているProblemは、対応するグループへ自動で割り当たります。Database・Software・Networkというグループが自社に存在しない、または名称が違う場合は、有効なルールが割り当て先を解決できず、意図しないグループへ届く点に注意が必要です。導入前にグループ名を確認します。
参考：自動割り当ての2つの仕組み（Assignment Rule / Data Lookup） … 仕組みの違い
通知（Email）のevent_nameに見つかる不備
通知定義は8件でした。
assigned・worknoted系の6件はevent_nameが problem.* で揃っており、正しく対応する通知として機能します。残り2件に不備がありました。
Problem Closed は event_name が incident.updated でした。Problemの通知なのに、Incident用のイベント名が指定されています。Problem Closed inform Opener は event_name が空欄で、条件式もなく、どのイベントにも紐づいていません。
Incident編でも、通知の発火条件がnotifyのような利用者の希望を見ていない点を確認しました。Problemでは希望条件どころか、イベント名そのものが噛み合っていない通知が2件あります。「有効になっている通知が、必ず動くとは限らない」という教訓は共通しています。
どちらも起票者（opened_by）へClose時に知らせる想定の通知です。event_nameが正しく機能しなければ、Problemがクローズしても起票者への自動連絡は届きません。運用でこの通知に依存する予定があるなら、有効化の前にevent_nameを修正するか、代替の通知を自分で作ります。
Known Error・Fixの必須項目はデータポリシーが握っている
resolution_codeやstateに応じて、特定の項目を必須にする制御が8件ありました。
8件すべて enforce_ui=true で、サーバ側でも強制されます。加えて8件すべてに、prb_model が空、または既定モデルであることという条件が付いています。Problem Model機能を使わない、または既定モデルのまま使う場合にだけこの必須制御が効き、カスタムモデルを使う場合は別ロジックに委ねる設計です。
そのモデル登録（prb_model）を数えると、標準では General の1件だけです。変更管理が6件の Change Model を持つのと対照的で、問題管理は「モデルを選ぶ」場面が事実上ありません。作業タスク側のモデル（prb_task_model）は General と Root Cause Analysis の2件です。problem_task_type の選択肢（General / Root Cause Analysis / Model）とも対応しています。導入時にモデルを増やす計画がなければ、この既定構成のまま運用を始めて差し支えありません。
Duplicate of・Cause notes・Fix notes・Canceled reason・Risk accepted reasonは、resolution_codeの選択に連動します。Resolution codeを選んだ瞬間に、対応する理由欄が必須へ切り替わる仕組みです。Assigned toはstateがAssess以降であれば常に必須で、担当者が決まらないまま調査が進む状態を防ぎます。
クライアントスクリプトの側でも、resolution_code変更時に close_notes のラベルを動的に切り替える処理が用意されています。Canceled reason・Risk accepted reasonという表示名は、この仕組みで close_notes のラベルを差し替えた結果です。実体は1つのフィールドのままラベルだけが変わるため、レポートで close_notes を横断集計するときは、中身の意味がresolution_codeによって変わる点に注意します。
参考：問題管理（Problem）運用設計書 … RCAや必須項目の判断基準をさらに詳しく扱う
実務で順番に検討する箇所
基本設定を決めるとき、次の順序で進めると手戻りが減ります。
カテゴリ体系：Incidentと同じ名前を使うか、Problem独自の分類にするかを決める
状態とproblem_state：レガシーフィールドの同期を理解した上で、既存のカスタマイズが依存していないか確認する
優先度マトリクス：5段階すべてに自動で届く設計を自社の基準に合わせる
SLA：定義するかどうかと、するなら何を測るかを決める
割り当てルール：Database・Software・Networkグループの実在を確認し、必要なら無効化する
通知：event_nameの不備を直す、または代替の通知を用意する
必須項目：resolution_code・state連動のデータポリシーを運用ルールとして周知する
参考：Update Set（sys_update_set）：設定を運ぶ2層の箱 … 検証環境で調整した設定を本番へ運ぶ仕組み
実機で気づいたこと
problem_stateは選択肢を持たないのに、条件式の中で生き続けている
problem_state という整数フィールドには、選択肢が1つも定義されていません。にもかかわらず、有効なBusiness Rule「SNC - ITIL - Update Related Incidents」が存在します。この Business Rule は problem_state.changesTo(4) という条件で動いています。
実際のレコードを確認すると、problem_state は常に state と同じ値（101〜107、まれに旧来の1・2）を取ります。2本のBusiness Ruleが両方向でそのままコピーし合っているためです。単独の整数「4」を取ることは、通常の状態遷移では起こりません。
この条件式は、現行の状態モデル（101〜107）が導入される前の、旧来のproblem_state体系を前提に書かれたまま残っていると考えられます。Incidentとの連携を止めた記憶がないのに、なぜかIncident側の状態が巻き戻らない、という相談を受けたら、まずこの条件式を疑います。
割り当てルールが、Incidentとは逆に最初から有効になっている
Incidentの割り当てルール3つは、いずれもactive=falseでした。Problemの割り当てルール3つは、逆にactive=trueでした。
Problemの対象はDatabase・Software・Networkという、CI種別で機械的に判定できる3分類だけです。Incidentのカテゴリのように組織構造に依存する分類を含まないため、デフォルトのまま有効にしておいても誤爆しにくいという判断だと読めます。
導入初日からこのルールが動く点は見落としやすいところです。Database・Software・Networkというグループ名を自社で使っていない場合、有効なルールがグループを解決できずに割り当てが失敗するか、意図しないグループへ届きます。Problemを有効化する前に、この3グループの実在を必ず確認します。
通知のevent_nameが、2件で機能していない
通知8件のうち、assigned系・worknoted系の6件はevent_nameが正しく対応していました。残る2件、Problem ClosedとProblem Closed inform Openerだけ不備がありました。
Problem Closedのevent_nameはincident.updatedというIncident用の値でした。Problem Closed inform Openerのevent_nameは空欄でした。どちらも、Problemがクローズしたことを起票者へ伝える通知です。
命名からして、Incident・Problem両対応だった古いテンプレートを流用した名残に見えます。起票者への自動連絡に依存する運用を組む前に、この2件が実際に届くかをテストします。
優先度の初期値はPlanning（最低）から入る
辞書の上書きを見ると、problem.priorityの既定値は5（Planning）でした。task標準の既定値は4（Low）で、Problemはさらに1段低い値に変更されています。
新規のProblemはまず最低優先度で作成され、ImpactとUrgencyが入力された時点でdl_problem_priorityが再計算して優先度を引き上げる、という流れになっています。problem_taskにはこの上書きがなく、task標準の4のままでした。
起票直後のProblem一覧で優先度がPlanningばかりに見えても、それは異常ではありません。ImpactとUrgencyが未入力のまま止まっている記録だけを、Planning滞留として拾う運用が現実的です。
用語
OOTB：Out of the Box。プラグイン追加やカスタマイズを行っていない、製品のデフォルト状態
PDI：Personal Developer Instance。ServiceNow が無償で提供する個人検証用インスタンス
dependent_value：選択肢を親の値に紐づける列。カテゴリとサブカテゴリの関係に使われる
Problem Model：状態遷移や必須項目のルールをテンプレート化する機能。既定モデル以外を使うと本記事のデータポリシーは効かない
SAMEAS：テンプレート型Business Ruleで使う値コピーの指定。スクリプトを介さず片方の値をそのままコピーする
検証範囲とおことわり
検証環境：Australia PDI（patch3相当）/ OOTB / 2026-08-31 確認
件数と既定値はすべてOOTBの状態です。本番環境やカスタマイズ済み環境では異なります
problem_stateに関する記述は、Business Ruleの定義と実データの一致から導いた推測を含みます。ServiceNowの公式見解として断定するものではありません
優先度マトリクスやデータポリシーの条件式を実際に書き換えて挙動が変わることは確認していません
通知2件（Problem Closed／Problem Closed inform Opener）が実際に届くかどうかは、メール送信までは追っていません
割り当てルールを実際に発火させて、CIやBusiness Serviceの判定結果を確認する検証は行っていません
各設定を読んでいるスクリプトの実装は、本シリーズ第6巻「問題管理モジュールの自動設定構成」で扱います
付録：自分の環境で確認するときのURL
状態の選択肢：/sys_choice_list.do?sysparm_query=name=problem^element=state^language=en
カテゴリ：/sys_choice_list.do?sysparm_query=name=problem^element=category^language=en
サブカテゴリ：/sys_choice_list.do?sysparm_query=name=problem^element=subcategory^language=en
影響度・緊急度・優先度：/sys_choice_list.do?sysparm_query=name=task^elementINimpact,urgency,priority^language=en
優先度マトリクス：/dl_problem_priority_list.do
解決コード：/sys_choice_list.do?sysparm_query=name=problem^element=resolution_code^language=en
SLA定義：/contract_sla_list.do?sysparm_query=collection=problem
割り当てルール：/sysrule_assignment_list.do?sysparm_query=table=problem
通知定義：/sysevent_email_action_list.do?sysparm_query=collection=problem
必須項目のデータポリシー：/sys_data_policy2_list.do?sysparm_query=table=problem
引用した公式説明を実機で確認する方法
この記事で引用した説明文は、ServiceNowが製品に同梱しているフィールドのドキュメントです。次のURLを自分のインスタンスで開くと、同じ記述が見つかります。
フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINproblem,task^hintISNOTEMPTY
関連記事
ServiceNow 問題管理（Problem）完全ガイド：Incidentとの違いとKnown Errorまでの流れ … Known Errorの扱い
選択肢Choice（sys_choice）：ドロップダウンの中身 … 選択肢そのものの仕組み
自動割り当ての2つの仕組み（Assignment Rule / Data Lookup） … 担当を自動で決める方法
