問題管理モジュールの概要

「同じ障害が月に何度も起きるのに、インシデント対応だけを繰り返している」という状況はよくあります。ServiceNowはこの繰り返しを止める仕組みとして問題管理を用意しました。復旧を担当するインシデント管理と役割を分け、原因の特定と恒久対策の実施を追いかける仕組みです。Australia PDIをデフォルト設定のまま開き、problemテーブルの構造とKnown Errorの実装を確かめました。

この記事で分かること

• 問題管理がインシデント管理とどう役割を分けているか（暫定復旧と恒久対策の違い）

• Problemの1件がどのテーブルに、どんな項目で保存されるか

• 状態が6段階ある理由と、旧来のproblem_stateがまだ残っている理由

• Known Errorがどんな条件で成立し、どこに記録されるか

• デフォルトで何がproblemに紐づいて動いているか

先に押さえておくこと

• 問題管理は「早く戻す」インシデント管理と違い、「繰り返させない」ために原因を追う仕組みである

• 子タスクのproblem_taskも独立してtaskを継承しており、problemとはきょうだいの関係にある

• デフォルトでもACL 146件・ビジネスルール25件がproblemに紐づいて動く一方、SLA定義は0件でインシデント管理と対照的である

問題管理の位置づけ

問題管理の目的は、同じ事象を繰り返させないことにあります。個別の障害を早く復旧させるのはインシデント管理の仕事です。問題管理は、その障害の背後にある原因を特定し、恒久対策として記録に残します。復旧を急ぐインシデント管理と、原因究明にじっくり取り組む問題管理を分けるのがITILの考え方で、ServiceNowはこれをテーブルの分離で表現しています。

紫のノードが問題管理の外にある別プロセスです。インシデントの暫定対応はすでに終わっている前提で、問題管理は原因調査から始まります。原因が判明して回避策が決まればKnown Error化して現場に配り、恒久対策にシステム変更が必要であれば変更管理へ引き継ぎます。

インシデントは業務を戻すことに集中し、根本原因の追跡は問題管理へ移す。この分担により、復旧の速さと再発防止の両方を確保できます。複数のインシデントで同じ事象が起きたときが、問題管理を起票する典型のタイミングです。

Problem テーブルの継承構造

Problemはtaskテーブルを継承しています。problem_taskという子タスクも、problemではなくtaskを直接継承する構成です。実機のsys_db_objectで確認できます。

super_classはどちらもTaskです。「problem → problem_task」という3階層を思い浮かべやすい構成ですが、実機の継承関係はtaskを頂点とする2階層で、problemとproblem_taskはきょうだいの関係です。problem_taskのフォームにあるProblem欄（problemフィールド）が、この2つのテーブルをつなぐ参照になります。

• 参考：taskテーブル：ITSM全プロセスの共通の親 … 親テーブル側の項目構成

公式のフィールド説明（sys_documentation）

ServiceNowは製品の中にフィールドの説明文を同梱しています。problemとproblem_taskを合わせて、hintに説明があるのは14件でした。

最も重要な引用はknown_errorです。

（訳: 根本原因は判明していて、回避策はある。ただし恒久的な修正はまだ無い）

この3条件（原因判明・回避策あり・恒久対策なし）が揃った状態をKnown Errorと呼ぶと公式が定義しています。原因が不明なら調査中、恒久対策が入れば解決済みで、Known Errorはその中間だけを指す言葉です。

priority・impact・urgencyの説明も引用します。

（訳: 問題を解決すべき順序）

（訳: 問題が業務に与える影響）

（訳: 解決がどれだけ遅延に耐えられるか）

優先度は、影響度と緊急度から導かれる順序だと公式が定義しています。この考え方はインシデント管理のtask.priorityと共通です。

引用元: /sys_documentation_list.do?sysparm_query=nameINproblem,problem_task^hintISNOTEMPTY

フィールド構成

sys_dictionaryを数えると、problem固有フィールドが31項目、problem_task固有フィールドが16項目でした。taskから継承する71項目を合わせると、problemは合計102項目で構成されます。

31項目のうち、運用で意味を持つものを挙げます。

• known_error：原因判明・回避策あり・恒久対策なしを示す真偽値

• primary_known_error_article：Known Error記事への参照

• duplicate_of：どのProblemの重複かを記録する自己参照

• first_reported_by_task：最初にこの問題を報告したタスクへの参照

• related_incidents：関連するIncidentの件数

• rfc：恒久対策として起票したChange Requestへの参照

• resolution_code：Fix Applied / Risk Accepted / Duplicate / Canceledの4択

• reopen_count：ResolvedまたはClosedから差し戻された回数

impact・urgency・priority・state・assigned_toはproblem固有辞書に無く、taskからの継承で持っています。インシデント管理と共通の土台を使い、Problem固有の項目は原因究明とKnown Error化に関わるものへ絞られています。

problem_taskの固有16項目には、cause_code（原因分類）・started_at/started_by（着手記録）・vendor（ベンダー原因の参照先）が含まれます。原因調査を分担する子タスクらしい構成です。

102項目の内訳と、どの項目を画面に出すかの判断は、本シリーズ第2巻「問題管理モジュールのテーブル・フィールド構成」で扱います。

状態（State）

sys_choiceでproblem.stateの選択肢を確認すると6件でした。すべて有効です。

valueは101から104まで連番のあと、105を飛ばして106・107になります。New→Assess→Root Cause Analysis→Fix in Progress→Resolved→Closedの順に進みます。

Problemのフォームはstateを直接ドロップダウンで変更させません。Assess・Confirm・Fix・Resolve・Completeという業務操作のボタンで段階を進める設計です。担当者がstateを自由に選べるインシデント管理とは対照的です。

もう一つの状態フィールドが存在します。problem_stateという整数フィールドで、選択肢を持たずデフォルト値は1です。関連するBusiness Ruleは2件あります。「Copy State to Problem State」（order=0）と「Copy Problem State to State」（order=1,000,000）です。この2件が、保存のたびにstateとproblem_stateを相互に同期させます。新旧2つの状態管理方式が同じレコードの中で並存しており、詳しい経緯は本シリーズ第2巻で扱います。

problem_taskのstateは4件（New/Assess/Work in Progress/Closed）で、problemより粗い4段階です。

Known Error（既知のエラー）

原因が判明しても、恒久対策の実施にはさらに時間がかかることがあります。その間に同じ事象がまた起きたとき現場が困らないように、回避策を共有しておく仕組みがKnown Errorです。

known_errorという真偽値フィールドをtrueにすると、原因判明・回避策あり・恒久対策なしという状態を示せます。primary_known_error_articleという参照フィールドを辿ると、kb_template_known_error_articleというクラスに行き着きます。継承元を確認すると、Knowledge（kb_knowledge）でした。Known Errorの実体は、通常のナレッジ記事と同じ枠組みに乗っている1クラスです。専用テーブルを新設せず、既存のナレッジ基盤に相乗りする設計になっています。

• 参考：Knowledge だけ task 系でない（kb_knowledge） … Known Error記事の継承元

known_errorのチェックだけでも回避策の共有はできます。正式なナレッジとして配りたい場合は、primary_known_error_article経由でKnown Error記事を作る、という2段階が用意されています。

problem に紐づく OOTB 設定

問題管理は、1つのテーブルとその周りで動く設定の集まりで構成されます。problemに紐づく設定を数えると、有効なものが237件ありました。

この表で注目すべきは最後の2行です。割り当てルールは3件とも有効で、CI種別やビジネスサービスで担当グループへ自動的に振り分けます。一方、SLA定義と無操作監視はどちらも0件でした。定義があって全件無効だったインシデント管理とは異なり、Problemは最初から定義を持たない設計です。

• 参考：自動割り当ての2つの仕組み（Assignment Rule / Data Lookup） … 有効化する前に読んでおく

ビジネスルール

保存ボタンを押すと、サーバ側では複数の処理が順に実行されます。problemには有効なビジネスルールが25件、非アクティブが2件ありました。

代表的な動きを1つ挙げます。担当者がResolvedへ進めると「Update fields when Problem is Resolved」が動き、resolved_atに現在時刻、resolved_byに操作者を入れます。resolution_codeがRisk Acceptedの場合は、Resolvedを経由せずclosed_atとclosed_byも同時にセットする処理です。リスクを受容した問題は、承認の記録として直接Closed相当の情報を持ちます。

もう一つ、全ルールの前後には状態の同期が挟まっています。stateとproblem_stateという2つの状態項目を、order 0とorder 1,000,000の2件が相互に写し合う構成です。この構成はインシデント管理のstateとincident_stateの同期と同じ発想です。

problem_taskの有効なビジネスルールは13件です。Problem側にも「Abort changes on group」パターンがあり、assignment_group変更時にassigned_toをクリアします。共通の設計方針がうかがえます。

各ルールの条件と処理の中身は、本シリーズ第6巻「問題管理モジュールの自動設定構成」で扱います。

• 参考：ServiceNowの保存で実際に動くBusiness Ruleは何本か？ problemテーブルで定義と実測を比べる … 1件保存して実際に発火する件数を数えた記事

通知

Problemの状態が変わると、条件に合う通知がメールを送ります。定義の置き場はsysevent_email_actionです。problemには8件、problem_taskには4件ありました。

宛先はassigned_toやassignment_group、opened_byといったレコードの項目から決まります。「Problem worknoted (to ITIL)」は担当者へ、「Problem worknoted (unassigned)」は担当グループへと、担当が決まっているかどうかで宛先を出し分けます。

導入時にそのまま使うと、担当者に不要なメールが届く原因になります。1件ずつ宛先と条件を確認し、自社の運用に合わないものは条件を調整する作業が要ります。各通知の条件は本シリーズ第6巻で扱う予定です。

• 参考：メール通知が飛ぶまでの4段階（Notification） … 届かないときはこの経路を順に追う

SLA 定義

contract_slaでproblem向けの定義を確認すると、0件でした。problem_taskも同じく0件です。

インシデント管理には対顧客・社内グループ間・ベンダー契約の3種類、有効13件のSLA定義があります。Problemにはこの仕組みがOOTBで用意されておらず、エスカレーションルール（sysrule_escalate）も同じく0件でした。

原因はProblemが期限で急かす対象ではないためだと読み取れます。優先度はdl_problem_priorityという専用のマトリクスで決まりますが、その優先度に対応する応答時間・解決時間の約束は用意されていません。自社でSLA相当の期限管理を持たせるかどうかは、本シリーズ第5巻「基本設定」と第11巻「運用設計書」で扱います。

• 参考：SLA Definition（contract_sla）とは：時計を生むルール … SLA定義がtask_slaという時計を生む仕組み

UI アクション（ボタン）

フォーム上のAssessやResolveといったボタンは、sys_ui_actionにレコードとして定義されています。problemには有効なボタンが22件ありました。

Assess・Confirm・Fix・Resolve・Completeという状態遷移ボタン群があります。表示条件は、ProblemStateUtilsというScript IncludeのcanAssess()・canConfirm()といったメソッドが判定します。1つのボタンが1つの判定メソッドに対応する構成です。

Create Problem Taskは、itilかproblem_task_analyst以上のロールを持つ担当者に表示されます。Create Normal/Standard/Emergency Changeは、rfcフィールドがまだ空のときだけ表示されます。原因調査から恒久対策への引き継ぎは、このボタン群が担う設計です。

• 参考：ServiceNowのResolveボタンはどこで動く？ UI Actionの表示条件とClient/Server処理 … 表示条件と処理の中身

システムプロパティ

Problemの挙動を変える設定値は、sys_propertiesに19件集まっていました。

例としてクローズ時の設定を見ます。problem.closed.cancel_open_tasks（既定true）は、Problemをクローズすると未完了のProblem Taskを一括でキャンセルする設定です。problem.acceptrisk.move_to_closed（既定true）は、Accept Riskを選ぶとResolvedを経由せず直接Closedへ進める設定です。

Incidentとの連携設定も見つかります。com.snc.problem.create_from_incident.attributesには、Incidentから新規Problemを作るときにコピーする項目がカンマ区切りで並んでいます。既定はdescription・short_description・impact・urgencyなど12項目です。状態・担当者はコピー対象に含まれておらず、複製されたProblemは新しい1件として原因調査を始めます。

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

ロールと権限

誰が何を操作できるかは、ロールとACLの2段で決まります。Problem専用のロールは6件です。

itilロールを持つ担当者は、problem_coordinatorなど専用ロールを追加しなくても、sn_problem_writeを自動的に含んでいます。専用ロール群はitilより強い権限を積み増すための階層で、Problem機能を使うこと自体はitilロールだけで足ります。

assigned_toの選択肢はproblem_coordinatorロール保持者に、problem_task側はproblem_task_analystロール保持者に、それぞれ絞り込まれています。担当を割り当てる画面で候補が少ないと感じたら、この参照条件を確認します。

ACL側の判定材料も見ておきます。有効な146件のうち、条件式（condition）を持つものは0件でした。JavaScriptで判定するスクリプトACLは13件のみで、Problemの認可ロジックはロール割当が中心です。

closed_at・resolved_by・reopen_countなど多数のタイムスタンプ系フィールドは、書き込みロールがnobodyでした。人間はUIから直接書けず、ビジネスルール経由でのみ更新される設計です。

• 参考：ロールを付けたのに見えない理由：ACL（sys_security_acl） … 権限が効かないときはここを見る

problem を参照しているテーブル

sys_dictionaryでproblemを参照しているフィールドを検索すると16件が該当します。

内訳を見ると、14件はFlow Designerの内部変数テーブル（var__m_で始まる自動生成テーブル）でした。実テーブルは2件だけです。problem自身のduplicate_of（自己参照）と、problem_task.problem（子タスクからの参照）です。

incidentテーブルには、problemを参照するフィールドがsys_dictionaryに見当たりません。それでも、有効なACLとビジネスルールはincident.problem_idを使って実際に動いています。この食い違いは次の節で扱います。

問題管理からインシデント管理への具体的なつなぎ方は、本シリーズ第8巻「問題管理モジュールの連携機能」で扱います。

実機で気づいたこと

状態管理が2系統並存している

problemにはstate（101〜107）とは別に、problem_stateという整数フィールドが存在します。選択肢を持たない生の整数で、デフォルト値は1です。同期を担うBusiness Ruleは2件あります。「Copy State to Problem State」（order=0）と「Copy Problem State to State」（order=1,000,000）です。この2件が、保存のたびにstateとproblem_stateを相互に同期させます。

全ビジネスルールの実行順の最初と最後に配置されているため、どのカスタムルールを差し込んでも、最終的にはこの同期で上書きされます。古いバージョンのstate体系を使うスクリプトやレポートが残っていても、problem_state経由で動き続けられる設計だと読み取れます。

自社でProblemの状態を条件にしたレポートやスクリプトを書くときは、どちらのフィールドを見ているかを必ず確認します。

incident.problem_id は辞書に無いのに動いている

sys_dictionaryでincidentのフィールドを全件確認しても、problemを参照する項目は見つかりません。REST APIでincidentを1件取得しても、problem_idというキー自体が返ってこない状態です。problem_idISNOTEMPTYで絞り込んだつもりのクエリも、条件が黙って無視されて全件が返ります。実在しない架空のフィールド名を条件にしたときと同じ挙動でした。それでも定義側には痕跡が残っています。有効なACLが3件。ビジネスルール「SNC - ITIL - Update Related Incidents」も同様です。inc.addQuery("problem_id", current.sys_id)を実行するコードが残っています。

フィールドの実体が無いまま、ACLとスクリプトの定義だけが残っている状態です。過去のリリースで使われていたフィールドの定義が掃除されずに残った可能性が高いですが、これは推測です。

存在しないフィールドを条件にしたクエリはエラーにならず全件を返すため、絞り込めたと思い込むと誤った集計になる点に注意が必要です。ACLやビジネスルールに残った定義も、辞書と突き合わせて実在を確認してから信用します。

通知のevent_nameがテーブルをまたいでいる

「Problem Closed」という通知のevent_nameを確認すると、incident.updatedというincident用のイベント名が入っていました。「Problem Closed inform Opener」はevent_nameが空欄です。

自然に読めば、Problemがクローズされた通知はproblem.closedのような専用イベントで発火するはずです。イベント名がテーブルをまたいでいる、または空のままという状態は、設定の移行時に更新し忘れた可能性を示しています。

event_nameが条件やcollectionと一致していない通知は、条件を満たしてもメールが届きません。導入前のチェックリストには、通知の宛先だけでなくevent_nameの一致も加えます。

実務で順番に検討する箇所

問題管理を新しく設計するとき、確認する順序を決めておくと迷いません。

1. 起票基準：同じ事象が繰り返しているか、原因不明のまま復旧したかのどちらかで起票する運用ルールを決める

2. Known Error化の基準：影響範囲が広い場合はKnown Error記事まで作る、限定的ならknown_errorのチェックとworkaroundのメモで済ませる、という基準を決める

3. SLAの代替：OOTBに定義が無いため、期限を管理したいなら独自のSLA定義かレポートによる監視を用意する

4. assigned_toの絞り込み：problem_coordinatorロールを持つ担当者だけが選択肢に出る設定を、自社の体制に合わせて見直す

5. 通知の点検：event_nameが正しく対応しているかを含めて8件を1つずつ確認する

6. Change連携：rfcフィールドでChange Requestに引き継ぐ運用を、変更管理側の承認フローとすり合わせる

用語

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

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

• Known Error：原因は判明していて回避策もあるが、恒久対策がまだ無い状態

• ACL：Access Control List。どのロールがどのテーブル・項目を読み書きできるかの規則

• rfc：Request for Change。problemが参照するChange Requestのフィールド名

検証範囲とおことわり

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

• 件数はすべてOOTBの設定・定義の数です。本番環境やカスタマイズ済み環境では異なります

• 各ビジネスルール・通知の処理内容の全件精読までは行っていません

• ACL 146件の内訳、実際の起票からクローズまでの操作は、このシリーズの後続記事で扱います

• 業務レコードの分布（どの状態に何件あるか）はデモデータ固有のため扱っていません

• incident.problem_idの正体（隠しフィールドかどうか）とFlow Designer製サブフローの内部実装は未確認です

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

• テーブル定義：/sys_db_object_list.do?sysparm_query=nameINproblem,problem_task

• フィールド定義：/sys_dictionary_list.do?sysparm_query=name=problem^elementISNOTEMPTY

• 状態の選択肢：/sys_choice_list.do?sysparm_query=name=problem^element=state^language=en

• ビジネスルール：/sys_script_list.do?sysparm_query=collection=problem

• 通知：/sysevent_email_action_list.do?sysparm_query=collection=problem

• SLA定義：/contract_sla_list.do?sysparm_query=collection=problem

• UIアクション：/sys_ui_action_list.do?sysparm_query=table=problem

• システムプロパティ：/sys_properties_list.do?sysparm_query=nameLIKEproblem

• ロール：/sys_user_role_list.do?sysparm_query=nameLIKEproblem

• ACL：/sys_security_acl_list.do?sysparm_query=nameLIKEproblem

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

この記事で引用した説明文は、ServiceNowが製品に同梱しているフィールドのドキュメントです。次のURLを自分のインスタンスで開くと、同じ記述が見つかります。

• フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINproblem,problem_task^hintISNOTEMPTY

• プラグインの状態（引用元）：/v_plugin_list.do?sysparm_query=idLIKEproblem

関連記事

• taskテーブル：ITSM全プロセスの共通の親 … Problemの親テーブルを先に知ると、フィールドの内訳がつかみやすくなる

• ServiceNow 変更管理（Change）完全ガイド：Standard・Normal・Emergencyをどう使い分けるか … rfcで引き継ぐ先の恒久対策を実施する側

• ServiceNowのCIMはIncidentやProblemとどうつながる？ 他モジュールから改善案を起票する仕組み … 改善提案を起票するもう1つの経路