ServiceNowのCIMでつまずく7つの点と直し方：実機で再現して確かめる

2026年8月14日 19:41

CIM（Continual Improvement Management）を導入すると、見た目には静かに使い始められます。ところが実際に触ると、「承認をONにしたのに通知が来ない」「テーブルだけ増えて機能が有効化されていない」といった、画面を眺めるだけでは気づけないズレが何か所も見つかりました。原因はほぼ全て、無効なままのビジネスルールと、必須ではないのに重要なフィールドに集中していました。Australia PDIで再現し、設定値とスクリプトから原因を1つずつ特定します。

検証環境：Australia PDI / OOTB / 2026-08-14 確認。CIMプラグイン（com.sn_cim v11.1.0）を導入済み

CIM とは：Continual Improvement Management（継続的改善管理）の略です。ITIL でいう継続的改善を ServiceNow 上で回すためのアプリケーションで、改善案を1件ずつレコードにし、KPI と目標値を付けて、効果が出たかどうかまで追います。プラグイン com.sn_cim を有効化すると使えるようになります。

CIMシリーズ（全9本） — 導入から設計・運用・トラブルまで通しで書いています。

結論：つまずきの正体は「無効なビジネスルール」と「必須ではない項目」に集中する

7件を並べると、原因のパターンは2種類でした。単純です。

1つ目は、出荷時点で無効になっているビジネスルールが2本あること。通知を送る処理と、作業メモを書く処理が、どちらも標準の状態では動きません。壊れているのではなく、最初からそういう状態で出荷されています。

2つ目は、承認者グループやKPIといった重要なフィールドが、必須項目になっていないこと。入力しなくても保存できてしまうので、後になって「誰が承認するのか決まっていない」レコードが積み上がります。

どちらも、画面を1回眺めただけでは気づけません。ビジネスルールが無効かどうかは一覧を絞り込まないと見えませんし、フィールドが必須かどうかはフォームを保存してみないと分かりません。CIMは自動化の土台自体は入っているものの、有効化するかどうかの最終判断を導入する側に委ねている、という設計だと捉えると理解しやすくなりました。

この2つのパターンを軸に、実機で確認できた7件を1つずつ見ていきます。

導入直後に触ると、増分を数え損なう

症状：プラグインの管理画面で Active の表示になった直後に作業を始めると、依存プラグインの反映がまだ終わっていないことがあります。

原因：v_plugin.active が active になるタイミングと、裏側で動いている sys_progress_worker（CICDPluginManagerWorker）が完了するタイミングは別です。CIM導入の直後、本体は active になっていましたが、進捗ワーカーはまだ動いていました。今回の環境では作成日時2026-08-13 22:08のワーカーが、その後 complete になっていることを確認しています。依存プラグイン（CIM Automated Tests）の反映がこのタイミングにずれ込むため、画面のトーストや Active 表示だけで完了と判断すると、増えたはずのテーブルやロールを数え損ないます。

直し方：sys_progress_worker の状態が complete になるまで待ってから、テーブルやロールの棚卸しを始めます。導入手順のチェックリストに「進捗ワーカーの状態確認」を1項目加えるだけで防げる、地味ですが効く対策です。プラグインの有効・無効と依存の全体像はプラグイン（v_plugin/sys_plugins）の有効・無効と依存にまとめました。

プラグインの有効・無効は、見た目どおりに動いていない

CIMを導入したあとのプラグイン一覧を見て、2つの意外な状態に気づきました。

依存リストに無いのに有効になったプラグインがある

症状：com.sn_cim の依存関係を確認しても載っていないはずの Skills Management が、気づいたら Active になっていました。

原因：com.sn_cim の requires を実機で読むと6件でした。前半3つは Organization Management・com.snc.planned_task_v2（Planned Task）・Performance Analyticsです。残り3つは Performance Analytics - Spotlight・com.sn_coaching（Coaching）・CIM Automated Testsです。Skills Managementはこの6件のどれにも含まれていませんが、それにもかかわらず有効化されていました。Skills Management自体の requires を見ると空で、依存を宣言していません。Coaching経由で入ったのか、別の経路があるのかは実装からは追い切れませんでした。この経路は確認できていません。

Project Managementは無効のままなのに、テーブルは16個増えている

症状：System Pluginsの一覧では Project Management（com.snc.project_management_v3）は Inactive のままなのに、planned_task_* や pm_console_* から始まるテーブルが16個増えています。

原因：CIM本体のテーブルである sn_cim_register（Improvement Initiative）と sn_cim_task（CIM Task）は、どちらも Planned task を継承しています。Planned Taskはプロジェクト管理の基盤テーブルなので、その定義自体がCIM導入時に一緒に入ってきます。Project Managementというアプリケーションそのものは別のプラグインで、これはActiveになっていません。

直し方：「テーブルが増えたかどうか」と「そのアプリを使える状態になったかどうか」は別の軸で見ます。テーブルの増加は継承元（sys_db_object.super_class）で判断するもの、機能が使えるかどうかはプラグインの active で判断するもの、という違いです。1つの数字で両方を判断しようとすると、Project Managementまで導入したつもりになってしまいます。

Improvement KPIを設定した改善案は、3件に1件しかない

症状：改善イニシアチブを一覧で見ると、Improvement KPI欄が空欄のまま運用されているレコードが目立ちます。

原因：indicator フィールド（Improvement KPI）は pa_indicators を参照しますが、参照修飾（reference qualifier）は設定されておらず、必須（mandatory）でもありません。値を入れなくても保存できる作りです。実機のデモデータ30件のうち、indicator が空のものは20件で、設定されているのはわずか3件に1件でした。PDIには自動収集のインジケータだけで423件登録されていて、選択肢が無いわけではありません。それでも多くの改善案が紐づいていないのは、任意項目だからです。

直し方：KPIを必ず入力させたい場合は、標準では強制されないのでUI Policyなどで別途必須化します。あわせて、CIMを入れる前にPerformance Analyticsで対象のインジケータを持っているかを確認しておくと、空欄のまま作られる改善案を減らせます。測る仕組みが先に無いと、改善案の側だけ用意しても埋まりません。インジケータの仕組みそのものはServiceNowのインジケータは履歴をどう持つ？で扱いました。

タスクの無い改善案は、Assess・In Progressへ進めない

症状：改善イニシアチブの状態を Assess（承認が必要な場合）や In Progress（承認が不要な場合）へ進めようとすると、エラーメッセージが出て状態が元に戻ります。

原因：ビジネスルール「Don't assess/start taskless initiatives」（sn_cim_register、before）が実機で有効になっていました。このルールは、承認プロセスが有効ならAssessへの遷移時に、無効ならIn Progressへの遷移時に動く仕組みです。動くと、cim_task_type=2（トップタスク）に該当するCIM Taskが1件でも存在するかを確認します。1件も無ければ処理を中止し、状態を直前の値に戻します。エラーメッセージは「Unable to proceed to approval process as there are no associated CIM tasks」でした。これは不具合ではありません。タスクの無い改善を進ませない、意図的な制御です。

直し方：状態を進める前に、CIM Taskを最低1件作成しておきます。ビジネスルールがどのタイミングで、どんな条件で動くかの基本はServiceNowのBusiness Ruleはいつ動く？にまとめてあります。

承認をONにしても、承認者に通知が飛ばない

sn_cim.need_approval は既定でtrueです。承認プロセスを使うつもりでこの設定のまま運用しているケースは多いはずですが、実機を追うと通知が届かない構造になっていました。

通知の宛先はイベントで決まる

承認者向けの通知「CIM from new to access notification」（sn_cim_register、有効）は、イベント sn_cim.cim_assess_state_change をトリガーに送信される設計です。通知定義そのものは正しく有効になっています。

イベントを発行するはずのビジネスルールが無効

症状：改善イニシアチブをAccepted→Assessへ進めても、承認者グループのメンバーにメールが来ません。

原因：このイベントを発行するのはビジネスルール「Assess notification event」（sn_cim_register、after）ですが、実機ではこのルールが無効でした。スクリプトを読むと、有効であれば状態がAcceptedからAssessへ変わったタイミングで approver_group に属するメンバーの一覧を集め、sn_cim.cim_assess_state_change イベントをそのユーザー一覧付きでキューに積む処理が書かれています。ルールが無効なので、この処理自体が一度も走りません。イベントが発行されない以上、通知定義がどれだけ正しくても宛先に届きません。

直し方：「Assess notification event」を有効化します。イベントとキューの基本的な仕組みはイベントはキューに積まれてから動く（sysevent）にまとめました。通知定義が有効でも実際には飛んでいないケースがどれだけあるかは、ServiceNowの標準通知403件、実際に飛んでいるのはどれ？で棚卸しをしています。CIMのこの2件も、その典型でした。

起票元のインシデントに、作業メモが自動で入らない

症状：Incidentなどの画面から「Create Improvement Initiative」を使って改善案を起票しても、起票元のIncidentには何も記録が残りません。

原因：このUIアクション（taskテーブルに配置、条件は CIMUtil().showImprovementUIAction(current)）のスクリプトを読むと、新規レコードの作成時に parent=<起票元のsys_id> を設定していることが分かります。この parent の変化を検知するのがビジネスルール「Add work notes」（sn_cim_register、after）です。起票元のタスクに「Improvement initiative CIM0000xxx created.」のような作業メモを書き込む役割を持っています。ところが実機ではこのルールも無効になっていました。処理の中身自体は書かれているので、有効化すれば動く状態です。

直し方：運用で相互リンクを記録に残したいなら「Add work notes」を有効化するか、起票時に手動で作業メモを残すルールを決めます。同じように「ビジネスルールが処理を止めている」パターンは、担当割り当ての場面でも見られました。詳しくは担当割り当て運用手順書：グループを変えられないのはBusiness Ruleが止めているで扱っています。

承認者グループを空のまま登録できてしまう

症状：改善イニシアチブを新規作成するとき、Approver group を指定しなくても保存できます。

原因：approver_group フィールドは sys_user_group を参照しますが、こちらも必須（mandatory）ではありません。実機のデモデータ30件のうち、approver_group が空のものは9件（3割）ありました。sn_cim.need_approval は既定でtrueなので、「承認は必要な設定なのに、誰が承認するのかが決まっていない」レコードが生まれる余地があります。承認者を誰に配るかという設計自体はServiceNowの権限は誰が持っている？にまとめました。

直し方：承認プロセスを使う運用では、Approver groupをUI Policyなどで必須化するか、テンプレートで既定の承認者グループを最初から入れておきます。CIM本体のACL（60件）はwrite・createの操作が全体の6割を占めていて、読ませるより書かせない方向の設計です。だからこそ「誰が書き込めるか」を決める承認者グループが空のままなのは、設計の意図に対して穴になります。承認は要る、でも承認者は決まっていない。この矛盾したレコードを作らせない仕組みを、標準機能の外側に用意する必要があります。

実機を見て気づいたこと

7件を1つずつ調べていく過程で、症状を追うだけでは見えてこない共通点が3つ浮かび上がりました。

「無効なビジネスルール」は壊れているのではなく標準の状態だった

最初は「Add work notes」や「Assess notification event」が無効なのを見て、環境固有の設定ミスだと思いました。ですが名前を見る限り、これは明らかに意図された処理です。標準機能なのに出荷時点で無効というのは、他のモジュールではあまり見ない構成でした。CIMは比較的新しいアプリケーションなので、実装は入れたが有効化の判断は導入側に委ねた、という可能性を感じます。ここは推測であり、公式の理由は確認できていません。

原因の見つけ方は、レコードではなくスクリプトを読むことだった

「通知が来ない」という症状に対して、最初は通知定義（sysevent_email_action）だけを見ていました。定義は有効なので、それだけでは原因にたどり着けません。event_name から発行元のビジネスルールを逆にたどり、そのスクリプトを読んで初めて「イベントが一度も発行されない」ことが分かりました。設定値が正しく見えても、それを動かす側の処理が動いていなければ意味がないという、当たり前ですが見落としがちな順番です。

プロパティの既定値にも設計思想が出ていた

sn_cim.need_approval はtrue、sn_cim.create_default_phase はfalseが既定でした。承認は入れておくが、フェーズという追加の階層は増やさない。製品は「承認は最初から使ってほしいが、構造は最初は単純にしてほしい」という考えで既定値を選んでいるように見えます。プロパティの読み方や設定値の置き場所はシステムプロパティ（sys_properties）は設定値の置き場にまとめてあります。

実務では何に使えるか

導入判定のチェックリストに進捗ワーカーを入れる

導入直後の確認手順に「sys_progress_worker が complete か」を1項目加えるだけで、増分の数え損ないを防げます。地味な確認ですが、後から数字のズレに気づいて調べ直す手間を考えると、先にやっておく価値があります。

有効化リストを自分で作る

「Add work notes」と「Assess notification event」は、CIMを本格的に使うなら有効化を検討する候補として、導入直後にリストアップしておきます。標準のまま使い始めると、しばらく経ってから「通知が来ていなかった」と気づくことになります。

必須項目はUI Policyで補う

indicator と approver_group はどちらも任意項目です。運用で必ず入力してほしいなら、標準機能に頼らずUI Policyやテンプレートで補います。「入力しなくても保存できる」という事実を、設計段階で織り込んでおくと手戻りが減ります。

症状から逆算する調査の型を持つ

今回の7件は、どれも「通知が来ない」「進めない」「増えない」という症状から、関連するビジネスルールやプロパティへ逆算する形で原因にたどり着きました。この型はCIMに限らず、他のアプリケーションのトラブル調査にも使えます。

有効化する前に、テスト環境で1回動かす

「Add work notes」や「Assess notification event」を有効化するときは、いきなり本番で切り替えないほうが安全です。無効になっているのには理由があるかもしれず、想定していない件数の作業メモやメールが一度に発生する可能性もあります。まずはテスト環境です。改善イニシアチブを1件動かし、作業メモと通知が狙いどおりに出ることを確認してから、本番の設定を変更します。

用語

Improvement Initiative（sn_cim_register）：改善活動1件を表すレコード。Planned task を継承する。

CIM Task（sn_cim_task）：改善イニシアチブを実行に分解したタスク。cim_task_type で種類を区別する。

Business Rule（before/after）：レコードの保存前後に動く自動処理。無効になっていると、処理そのものが一度も実行されない。

イベント（sysevent）：ビジネスルールなどが発行するキューへの登録。通知はこのイベントをトリガーに動く。

sys_progress_worker：時間のかかる処理の進捗を管理するレコード。プラグイン導入の完了判定に使う。

Approver group：改善イニシアチブの承認者が所属するグループを指すフィールド。必須項目ではない。

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

自分のインスタンス名に続けて開きます（CIMプラグインの導入が前提です）。

無効なビジネスルール一覧：/sys_script_list.do?sysparm_query=collectionSTARTSWITHsn_cim^active=false
タスクレス初期化を止めるビジネスルール：/sys_script_list.do?sysparm_query=collectionSTARTSWITHsn_cim^nameLIKEtaskless
CIMのプロパティ設定画面：/system_properties_ui.do?sysparm_title=Continual Improvement Management Properties&sysparm_category=Continual Improvement Management
KPI未設定の改善イニシアチブ：/sn_cim_register_list.do?sysparm_query=indicatorISEMPTY
承認者グループ未設定の改善イニシアチブ：/sn_cim_register_list.do?sysparm_query=approver_groupISEMPTY
CIM関連の通知定義：/sysevent_email_action_list.do?sysparm_query=nameLIKECIM
依存プラグインの状態確認：/v_plugin_list.do?sysparm_query=idINcom.snc.project_management_v3,com.snc.test_mgmt,com.sn_cim,com.snc.skills_management

引用した公式説明を自分で開く

この記事で引用したプロパティの説明文とプラグインの依存関係は、ServiceNowが製品に同梱している情報です。次のURLを自分のインスタンスで開くと、同じ記述を読めます。

プロパティの公式説明（引用元）：/sys_properties_list.do?sysparm_query=nameSTARTSWITHsn_cim^descriptionISNOTEMPTY
プラグインの依存関係（引用元）：/v_plugin_list.do?sysparm_query=id=com.sn_cim

検証範囲とおことわり

Australia のPDI（OOTB）で2026-08-14に確認しました。CIMプラグインをデモデータ込みで導入した状態です。

設定を変更して直したわけではなく、設定値と実装（ビジネスルールのスクリプト、プロパティの既定値、フィールドの必須有無）から原因を特定した範囲です。ビジネスルールを実際に有効化して通知が届くところまでは確認していません。

Skills Managementが有効化された経路（Coaching経由と推測）は、実装からは追い切れず確認できていません。

改善イニシアチブを実際に1件作成し、承認プロセスを最後まで動かしてはいません。Approved以降の状態遷移や、承認が却下されたときの挙動は未検証です。「Add work notes」「Assess notification event」を有効化した場合に、他の処理と競合しないかどうかも確認していません。有効化は自己責任で、テスト環境での確認を前提にしてください。

デモデータの件数（改善イニシアチブ30件のうちindicator空欄20件・approver_group空欄9件）はこの環境の値です。本番では当然変わります。

ServiceNowのBusiness Ruleはいつ動く？ before/after/asyncの違いを実機の件数で確認 — 無効・有効の判断に必要な前提知識
イベントはキューに積まれてから動く（sysevent） — 通知が飛ぶ手前のイベントキューの仕組み
ServiceNowの標準通知403件、実際に飛んでいるのはどれ？ — 定義は有効でも実際には飛んでいない通知を棚卸しする実務編