問題管理モジュールのトラブル事例と解決

「Resolveボタンが押せない」「Assigned toの候補に自分が出てこない」「削除できない」。問題管理（Problem）でこの3つに当たると、Incidentと同じ操作感を期待していた分だけ戸惑います。原因はバグではなく、Problem固有の権限設計とデータポリシーです。Australia の PDI をデフォルト設定のまま開き、代表的な6つの症状を実機で1つずつ追いました。

扱う症状

• 症状から原因へたどる順序

• Problem固有の権限設計（Assigned toの参照制限・削除ロール）

• Incidentとの違いが原因になる症状（状態の二重系・SLA）

症状から原因へたどる順序

Problemの相談も、Incidentと同じ3つに分けます。

• 保存できない：削除ACLの役割条件、データポリシーの必須

• 画面で選べない・出ない：Assigned toの参照先ロール、UIアクションのcondition

• 後続が合わない：state / problem_stateの二重系、通知のevent_name、SLA定義の有無

Incidentの記事を先に読んだ担当者ほど、割り当てルールの無効化を疑いがちです。Problemの割り当てルールは3件とも有効で、担当が付かない原因は別の場所にあります。同じ「担当が付かない」という症状でも、テーブルが違えば原因の層まで変わります。

Assigned toの候補に自分が出てこない

症状：Problemを開いてAssigned toの虫眼鏡を押しても、担当にしたい人が候補に出てきません。itilロールを持つ担当者でも同じです。

原因：assigned_to の参照先が、辞書オーバーライドで roles=problem_coordinator に絞られています。

itilロールはsn_problem_writeを自動的に含むため、Problem自体の閲覧・編集はできます。担当候補の絞り込みはproblem_coordinatorロールだけを条件にしており、含む方向は一方向です。problem_coordinatorがitilを含みますが、逆はありません。itilだけを持つ担当者は、この絞り込みの対象外です。

problem_taskはさらに絞り込みが別です。assigned_toの参照先はroles=problem_task_analystで、Problem側のproblem_coordinatorとは異なるロールを見ます。

テーブルassigned_toの参照先ロールproblemproblem_coordinatorproblem_taskproblem_task_analyst

ここで混同しやすいのが、「候補に出るロール」と「書き込めるロール」の違いです。assigned_toフィールドを書き込むACLの対象ロールはsn_problem_writeで、これはitilが自動的に含みます。つまりitilユーザーは、スクリプトやAPI経由でassigned_toに値を入れること自体はできます。候補一覧の絞り込みだけがproblem_coordinatorに限定されているため、画面の虫眼鏡で選ぶ操作でだけ、itilユーザーが見えなくなります。

解決：担当にしたい人へproblem_coordinator（Problem Task担当ならproblem_task_analyst）を付与します。itilロールを増やしても解決しません。付与状況はユーザー画面のロール一覧で確認します。

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

Resolve・Completeボタンが出ない、押しても保存できない

症状：ProblemをFix in Progressまで進めたのに、ResolveやCompleteのボタンが見当たりません。ボタンが出ていても、押すとFix notesかCause notesの入力を求められることがあります。

ボタンの表示条件はスクリプト判定

ResolveとCompleteのconditionには、ProblemStateUtilsというScript Includeのメソッド呼び出しが入っています。単純な条件式1つで判定しているわけではありません。

ボタンconditionResolvecurrent.canWrite() && new ProblemStateUtils().canResolve(current)Completecurrent.canWrite() && new ProblemStateUtils().canComplete(current)

条件式を読むだけでは判定できません。「出ない」原因を調べるときは、Script Includeの中身まで確認します。

同じ理屈は、状態を進める他のボタンにも当てはまります。Assess・Confirm・FixもそれぞれcanAssess()・canConfirm()・canFix()という専用メソッドで判定されます。New・Assess・Root Cause Analysis・Fix in Progress・Resolved・Closedという6段階の遷移すべてが、この個別メソッド方式です。1つのボタンの条件を直しても、他のボタンには影響しません。状態遷移のボタンが「一部だけ出ない」という相談では、該当する段階のメソッドだけを個別に確認します。担当者ロール自体はsn_problem_writeでどの段階も共通のため、特定の段階だけ進められない場合は、ロールよりも先にその段階固有のメソッドを疑います。canAssess()・canConfirm()・canFix()の中身は本記事では未確認で、個別調査が必要です。

データポリシー8件が状態と解決コードで必須項目を切り替える

state=104（Fix in Progress）または解決コードがFix Appliedのとき、Cause notesとFix notesが必須になります。stateがResolvedかClosedのときは解決コードそのものが必須です。

必須になる項目条件Duplicate ofresolution_code=DuplicateCause notes・Fix notesstate=Fix in Progress、または resolution_code=Fix AppliedAssigned tostate IN Assess/RCA/Fix in Progress/Resolved/ClosedResolution codestate=Resolved/Closed、または resolution_code=Fix Applied

標準のResolve・Completeボタンを押すと、resolution_codeにFix Appliedが自動で入ってから保存されます。担当者が画面のボタンだけを使う運用では、resolution_codeが先に埋まるため、この必須制御はREST APIやインポートセットでstateだけを直接更新したときに初めて表面化します。

解決：ボタンが出ない場合は、ロールとcanWrite()の判定（担当者・担当グループの一致など）を先に見ます。保存で止まる場合は、外部連携側でCause notes・Fix notes・resolution_codeを明示的に渡してください。8件のデータポリシーはprb_modelが未設定または既定モデルのときだけ有効です。独自のProblem Modelを使っているなら、必須判定はモデル側のロジック次第になります。

UIポリシーとの役割分担も押さえておくと切り分けが速くなります。「Hide Resolution Code when state is not resolved or closed」というUIポリシーがあります。state=106・107以外では、このポリシーが解決コード欄そのものを隠す仕組みです。画面に出ない場合はUIポリシー、出ているのに保存できない場合はデータポリシーという切り分けです。

• 参考：APIやインポートにも効く必須制御（Data Policy） … 画面外からの投入はここで止まる

Problemを削除できない

症状：不要なProblemを消そうとしても、削除メニューが選べません。管理者アカウントでも同じ相談が来ることがあります。

原因：削除ACLは5件あり、業務用として効くのはproblemとproblem_taskの2件だけです。対象ロールはproblem_adminとitil_adminに限られます。

残る3件はsys_backout_problem（ロールnobody）とsys_update_preview_problem（update_set_admin・update_set_previewer）です。いずれもUpdate Set機構が「problem」という名を持つテーブルに自動付与する汎用ACLで、Problem固有の業務ロジックではありません。

problem_adminロールの公式説明には次のようにあります。

（訳: Problemの削除もできるProblem Manager）。Problem Managerの権限に、削除という1点だけを積み増した役割だと分かります。ロールの包含関係でもproblem_adminはproblem_managerを含み、problem_managerはproblem_coordinatorを含む階層です。problem_managerだけでは削除できません。削除を任せる相手は、その1段上のproblem_adminまで確認します。もう一方のitil_adminは、Problem専用ロールの階層とは別系統です。ITSM全体を横断する管理者ロールで、Problem以外のテーブルでも同様の管理操作を任される前提で設計されています。Problem専用ロールだけを丁寧に設計しても、itil_admin保持者には別枠で削除権限が渡っている点は見落としやすいところです。

引用元: /sys_user_role_list.do?sysparm_query=name=problem_admin

problemの削除ACLはadmin_overridesがtrueです。グローバルなadminロールを持つユーザーは、この条件を自動的に満たします。管理者アカウントなのに消せないという相談が来たら、そのアカウントがadmin・problem_admin・itil_adminのいずれも持っていない状態です。

解決：削除を任せる担当者にはproblem_admin（Problem Task含む）かitil_adminを付与します。日常のクローズ運用では削除せず、resolution_codeをCanceledにして残す運用が記録の面では安全です。

• 参考：ロールを付けたのに見えない理由：ACL（sys_security_acl） … ACLの条件と評価順

• 参考：Update Set（sys_update_set）：設定を運ぶ2層の箱 … 自動生成ACLの背景

状態を変えたのにレポートの数字が合わない

症状：Problemの状態別集計が、フォームで見た状態遷移と食い違います。

原因：Problemには状態を表す項目が2つあります。state（101-107、選択肢定義あり）とproblem_state（整数、選択肢定義なし、既定値1）です。

両者は2件のビジネスルールで相互に同期します。「Copy State to Problem State」（order 0）と「Copy Problem State to State」（order 1,000,000）です。フォームや標準のUIアクションを使う限り、どちらを更新してももう一方へ反映されます。

この2件はscript欄が空欄で、JavaScriptを1行も書いていません。中身はproblem_state SAMEAS stateという宣言的な条件式だけで、値のコピーを実現しています。orderが0と1,000,000という両端の値になっているのは、他のビジネスルールが何を追加されても、必ず最初と最後で帳尻を合わせるためです。

デモデータの実測でも、この二重系のなごりが見つかりました。24件中2件はstateが「1」「2」という値を持ち、現在の選択肢定義（101-107）のどれにも当てはまりません。

taskテーブル標準の状態値（1=Open、2=Work in Progress）がそのまま残った移行漏れとみられます。レポートやPAダッシュボードを作るときは、フォームに表示され選択肢が明示されたstateを軸にします。problem_stateは同期用の内部項目として扱い、集計の主役にはしません。

インポートセットの一部の実行方法や、setWorkflow(false)のようにビジネスルールをスキップするスクリプトを使うと、この同期が働かない可能性があります。この経路の実際の挙動はPDIへの書き込みが要るため、本記事の検証範囲外です。

SLAが1件も付かない

症状：Problemを開いても、SLAのタブや残り時間の表示が見当たりません。「SLAの設定を確認してください」という問い合わせが来ます。

原因：Problem管理のOOB SLA定義（contract_sla）は0件です。設定漏れではなく、Incidentとの設計上の違いです。

Incidentには優先度別のSLA定義が13件用意されていますが、Problemには最初から1件もありません。エスカレーションルール（sysrule_escalate）も同様に0件です。Problemの主眼は「原因を突き止める」活動にあり、時間を契約で縛る仕組みは後付けの位置づけだと読み取れます。

一方で、割り当てルール（sysrule_assignment）はProblemにも3件あり、Database・Software・Networkの3種別で実際に有効です。Incidentの割り当てルールが全件無効なのとは対照的に、Problemでは担当グループの自動振り分けだけは最初から動く設計になっています。

解決：Problemの時間管理をSLAで行いたい場合は、contract_slaに自社定義を新規作成します。既存のSLA記事の手順がそのまま流用できますが、Problem向けの定義はゼロから作る前提で計画します。

• 参考：SLA Definition（contract_sla）とは：時計を生むルール … SLA定義の作り方

• 参考：ServiceNow 問題管理（Problem）完全ガイド：Incidentとの違いとKnown Errorまでの流れ … IncidentとProblemの役割の違い

通知が届かない

症状：Problemをクローズしても、起票者にメールが届きません。

原因：Problem Closedという通知のevent_nameがincident.updatedという別テーブル用のイベント名になっています。Problem Closed inform Openerはevent_nameが空欄です。

8件の通知すべての条件式を確認しましたが、notify項目（既定値: Do Not Notify）を条件にしているものは1件もありませんでした。notifyを疑う前に、イベント名の整合を確認します。「Problem assigned to my group」の条件式はassigned_toISEMPTY^assignment_groupISNOTEMPTY^assignment_groupVALCHANGESで、担当者が空のまま担当グループが変わったときだけ発火します。8件とも、宛先に関わる項目（assigned_to・assignment_group・work_notesなど）を条件式で直接参照する設計です。

解決：確認する順序は次のとおりです。

1. メールが生成されているかをsys_emailで見る。生成されていれば通知定義とイベント発行までは動いている

2. typeを見る。send-readyのまま溜まっていれば送信設定（SMTP）側の問題

3. 生成されていなければ、通知定義のevent_nameが実際に発行されているイベントと一致しているかを見る

4. 一致していなければ、通知定義側かイベント発行側のどちらを直すかを判断する

生成と送信を分けて切り分けると、定義の問題か送信設定の問題かを最初の1手で判別できます。

• 参考：送信待ちで止まったメールを追う（sys_email） … 生成と送信の切り分け方

• 参考：イベントはキューに積まれてから動く（sysevent） … イベント発行の仕組み

実機で気づいたこと

削除だけadmin_overridesがtrueになっている

Problem本体の書き込み系ACLの多くはadmin_overridesがfalseで、管理者でもスクリプト経由でしか触れないタイムスタンプ系項目が並びます。削除ACLだけはadmin_overridesがtrueでした。

削除は「レコードそのものを消す操作」という別区分で扱われており、通常の管理者権限が素直に効く設計だとわかります。日常の業務項目は厳しく縛り、削除のような管理操作は素の権限モデルに委ねる。この役割分担が見えました。

Assigned toの絞り込みロールがproblemとproblem_taskで別

Problem本体はproblem_coordinator、Problem Taskはproblem_task_analystと、担当候補の絞り込みロールがテーブルごとに異なります。IncidentのようにテーブルをまたいでAssigned toの候補集合が揃っている構成ではありません。

権限設計を見直すときは「Problemを担当できる人」と「Problem Taskを担当できる人」を別の集合として扱います。同じ人に両方を任せる運用でも、ロールとしては2つ渡す作業が要ります。

イベント名の食い違いはコピペのなごりに見える

Problem Closedのevent_nameがincident.updatedになっている点は、Incident側のBusiness Ruleをもとに通知定義を複製し、イベント名だけ直し忘れたように見えます。設定を複製した時点の作業もれだとみられます（推測）。

自社で通知を複製するときは、event_nameをテンプレートの値のまま残さないことを、レビューの必須項目にします。

データポリシー8件はProblem Model不使用が前提

8件の必須制御はすべてprb_modelISEMPTY^ORprb_model=<既定モデル>という条件を持っています。Problem Modelという別の仕組みを導入すると、この必須制御そのものが働かなくなる可能性があります。

com.snc.problem_management.models.enabledというプロパティはtrueで、Problem Modelの機能自体はすでに有効です。カスタムのモデルを追加運用する場合、必須項目の担保はモデル側の設計に委ねられます。データポリシーを直すだけで安心せず、Problem Modelを使うかどうかを先に決めておくと手戻りが減ります。

導入時の確認リスト

ここまでの内容を、導入時に確認する形にまとめました。

仕様として意図された制限（削除ロールの限定・データポリシーの必須項目・SLA定義なし）と、自社の体制に合わせて設定する項目（担当ロールの付与・レポートの基準・通知の修正）に分かれます。前者は変更せず、後者だけを導入時に手を付けます。

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

問題管理を導入するときは、次の順序で確認します。Incidentの導入チェックとは項目そのものが違うため、流用せずゼロから洗い出します。

1. 担当ロールの割り当て：problem_coordinatorとproblem_task_analystを、担当予定者に個別付与する。itilロールだけでは候補に出ない

2. 削除の運用：削除するか、Canceledで残すかを決め、必要な担当者にproblem_adminかitil_adminを付与する

3. 状態集計の基準：レポートやPAダッシュボードはstateを軸にし、problem_stateは同期用として扱う。レガシー値の混入がないかも一度確認する

4. SLAの要否：時間管理が必要ならcontract_slaをゼロから作る。既存のIncident用定義は流用できない

5. 通知のevent_name確認：8件それぞれのevent_nameが、実際に発行されているイベントと一致しているかを突き合わせる

6. Resolve/Complete前の必須項目の周知：API連携や一括処理を作る担当者には、Cause notes・Fix notes・resolution_codeを事前に伝えておく

用語

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

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

• reference_qual：参照項目（Reference）の候補を絞り込む条件式

• admin_overrides：adminロールがACLの条件を無視して通れるかどうかの設定

• Problem Model：状態遷移のルールをレコード単位で切り替える仕組み。prb_modelで指定する

• SAMEAS：ビジネスルールの条件式で「別の項目と同じ値にする」を宣言的に書く記法。JavaScriptを書かずに済む

• enforce_ui：データポリシーが画面だけでなくAPI・インポート経由の書き込みにも必須制御を効かせるかどうかの設定

検証範囲とおことわり

• 検証環境：Australia PDI / OOTB / 2026-09-01 確認

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

• 各症状を実際に再現し、対処して直ることまでは確認していません。定義から原因を整理しています

• インポートセットやスクリプトでビジネスルールをスキップした場合のstate/problem_state同期の挙動は、PDIへの書き込みが要るため未確認です

• problem.worknoted・problem.assigned.to.groupイベントの発行元は本記事の調査範囲では特定していません

• スクリプト付きACL13件の中身までは追っていません

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

• Assigned toの参照制限：/sys_dictionary_override_list.do?sysparm_query=name=problem^element=assigned_to

• データポリシー：/sys_data_policy2_list.do?sysparm_query=model_table=problem

• Resolve・CompleteのUIアクション：/sys_ui_action_list.do?sysparm_query=table=problem^nameINResolve,Complete

• 削除ACLのロール：/sys_security_acl_role_list.do?sysparm_query=sys_security_acl.nameLIKEproblem^sys_security_acl.operation=delete

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

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

• 状態別件数：/problem_list.do?sysparm_query=GROUPBYstate

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

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

• ロールの公式説明（引用元）：/sys_user_role_list.do?sysparm_query=nameLIKEproblem

関連記事

• ロールを付けたのに見えない理由：ACL（sys_security_acl） … 権限で止まる原因はここを見る

• APIやインポートにも効く必須制御（Data Policy） … 画面外からの投入はここで止まる

• 送信待ちで止まったメールを追う（sys_email） … 通知が届かないときの切り分け方