ServiceNowのCIMを入れたら最初にやる設定は？ プロパティ・ロール・承認を実機で確認する

CIMプラグインを入れたあと、次に何を設定すればいいのか分からない、という声をよく聞きます。ロールをどう配るか、承認は要るのか、通知はどこに飛ぶのか。決めることは多そうに見えますが、実際に確定させるべき設定はプロパティ2件とロール4件程度でした。Australia PDIの実機で、増えたプロパティ・ロール・通知・承認の中身を1つずつ確認します。

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

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

• ①導入手順：CIMプラグインを入れる

• ②影響調査：プラグインを入れると何が変わるか（27か所）

• ③CIMとは何か：何を管理して誰に効くのか

• ④最初の設定：プロパティ・ロール・承認（この記事）

• ⑤運用手順：改善を1件流す（有料100円）

• ⑥開発設計書：テーブル・ロール・状態・自動化・UI（有料300円）

• ⑦運用設計書：役割・体制・レビュー（有料300円）

• ⑧連携：IncidentやProblemとどうつながるか

• ⑨トラブル：つまずく7つの点と直し方

結論：触るのはプロパティ2つとロール4つ、あとは後回しでよい

CIM導入で増えるものは、プロパティ5件・ロール21件・通知7件・ACL60件・承認Flow1件と数が多く見えます。実際に開いて中身を確認すると、運用開始前に判断が必要な項目は一部だけでした。

プロパティはneed_approval（承認要否）とcreate_default_phase（既定フェーズの自動生成）の2件だけが業務判断です。残り3件は既定値のままで問題ありません。ロールは21件のうちCIM本体の4件を誰に配るかだけを決めれば足り、Skills・Project・Spotlight・Coaching由来の12件は配らない判断もできます。通知は7件とも既定で有効なので、宛先の確認だけが必要です。ACLは60件ありますが中身は「書かせない」方向に既に寄っているので、緩める作業はほぼ発生しません。

入れた直後、何から手を付けるかで迷う

プラグインを1つ入れると、テーブルやロールやACLが一気に増えます。CIMも例外なく、テーブルだけで67件増えました。増えたもの全部を確認しようとすると時間がかかりすぎて、結局「とりあえずデフォルトのまま使い始める」ことになりがちです。

ここで知りたいのは網羅的な一覧ではなく、運用を始める前に必ず決めるべきものと、後から変えても困らないものの境界線です。この境界線を実機で確かめます。

境界線がどこにあるかは、増えたものの種類によって変わります。プロパティは業務判断そのものなので後回しにできません。ロールは配ってしまうと回収の手間が大きいので早めに決めます。一方でACLやモジュールの並びは、標準の設計を理解しておけば手を加える必要自体がないことがほとんどです。触る場所と、理解するだけでよい場所を最初に仕分けるのが、この記事の狙いです。

上から4段が導入直後に確認する項目で、下の3項目は後回しにしてよいものです。この順番で見ていきます。

プロパティは5件、業務判断が要るのは2件だけ

システムプロパティの一覧画面でsn_cimから始まるものを検索すると、4件がヒットしました。もう1件（glide.ui.sn_cim_register_activity.fields）は接頭辞が異なるため別枠です。

need_approval：承認を挟むかどうかを最初に決める

ここが一番の分かれ目です。

sn_cim.need_approvalの公式説明はこうです。

既定値はtrueでした。つまり何も変えなければ、改善イニシアチブは承認プロセスを通ります。承認の実体は後述するCIM Approval WorkflowというFlowです。

この設定は業務のやり方に直結します。改善案を誰でも自由に起票して回してほしい組織なら、承認なしのほうが動きが速くなります。逆に予算や工数が絡む改善なら、承認を残したほうが安全です。このプロパティは運用開始前に必ず決める設定です。

create_default_phase：フェーズを最初から使うかどうか

ここは急ぎません。

もう1件の判断ポイントがsn_cim.create_default_phaseです。公式説明は次のとおりでした。

既定値はfalseです。つまり標準の状態では、改善イニシアチブを作ってもフェーズは自動生成されません。CIM Phasesという第三のテーブルが用意されているにもかかわらず、既定では使わない設定になっています。製品側が「まずフェーズなしで始めてよい」と言っているに近い状態です。

小さな改善を1件ずつ進めるだけなら、この既定値のままで困りません。大きな改善を調査・実装・検証のように区切って管理したくなったら、そのときに有効化すれば十分です。今すぐ判断しなくてよいプロパティです。

残り3件は標準のままでよい

sn_cim.initiative_copy_attributesは、親のイニシアチブから子を作るときに複製する項目のリストで、short_descriptionやpriorityなど12項目が既定で入っていました。この12項目にはstrategic_objectiveやbusiness_processも含まれていて、経営目標や対象業務まで自動で引き継ぐ設計です。sn_cim.glide.script.block.client.globalsはクライアントスクリプトでのglobals使用を禁止する設定で、既定のfalseから変える理由は通常ありません。glide.ui.sn_cim_register_activity.fieldsはアクティビティ欄に表示する項目の並びで、運用しながら見づらければ調整すれば足ります。3件とも、導入初日に決める必要のない設定です。

プロパティの詳細はシステムプロパティ（sys_properties）は設定値の置き場で扱いました。

ロールは21件増えるが、配るのはCIM本体の4件だけ

権限設計は基本設定の中で一番実務に効く部分です。CIM導入で増えた21ロールの内訳を見ると、実際に配布を判断すべきものはかなり絞れます。

CIM本体4ロールをどう配るか

sn_cim.improvement_requesterは改善案を作れるだけのロールで、他人のレコードは編集できず、ダッシュボードやレポートも見えません。申請者は広く配ってよいロールです。改善案は数を集めないと良いものが選べないので、間口を狭める理由がありません。

反対にsn_cim.improvement_managerは全レコードの編集・削除・承認・プロパティ変更ができ、pa_power_userロールまで付随します。管理側のロールは少数に絞るべきです。sn_cim.improvement_coordinatorは担当分だけの受理・評価・調整ができる中間の立場で、事務局を数名任命して割り当てる使い方が合います。sn_cim.adminはCIM設定モジュールへのフルアクセス権で、システム管理者以外には配りません。

adminロールをどこまで絞るべきかという判断は、ServiceNowでadminを配らずに開発させるには？で扱った考え方がそのまま使えます。申請者を広く、管理者を狭くという配り方は、CIMに限らずServiceNowの権限設計の基本形です。

ついてきた12ロールは配らない判断もある

増えた21ロールのうち、CIM本体以外の12件は別モジュールのものでした。Coaching由来が3件、Skills Management由来が5件、Performance Analytics Spotlight由来が4件です。

これらはCIMを導入した副作用で入ってきただけで、CIM Workbenchを使うために必須のロールではありません。Coaching機能やSkills機能を実際に使う予定がなければ、配らないという判断でよいロールです。配ってしまうと、使わない機能へのアクセス権だけが増え、権限棚卸しのときに「なぜこの人がSkills Managerを持っているのか」を調べる手間が発生します。

ロールがどこまで権限を含むかを実機で追う方法はServiceNowで付けたロールが想定外の権限を含んでいた理由にまとめました。

通知は7件すべて有効、宛先の確認が最優先

通知は設定変更が要らない代わりに、確認だけは必ずやるべき項目です。CIM関連の通知をテーブル名で検索すると7件出てきて、全件がActiveでした。

内訳は、改善イニシアチブ側が5件（承認・受理・完了・取消・期限超過）、CIM Task側が2件（割当・完了）です。宛先の欄を見ると、watch_list（ウォッチしているユーザー）、assigned_to（担当者）、assignment_group.manager（担当グループのマネージャー）が使われていました。

これはつまり、メールが飛ぶ経路が最初から7本開いているということです。テスト用に作った改善イニシアチブをうっかり進めてしまうと、ウォッチ中の関係者やグループマネージャーに通知が届きます。本番導入の前に、誰がwatch_listに入るのか、assignment_groupをどう割り当てるのかを確認しておくと、意図しない相手にメールが飛ぶ事態を避けられます。

7件のうちCIM Breach NotificationだけカテゴリがSLAになっていて、他の6件はCIMカテゴリでした。名前とsn_cim_register.target_date_time（効果を見る日）という項目の組み合わせから見て、期限超過を知らせる通知だと読めます。発火条件の詳細までは確認していませんが、Target review dateを空欄のまま運用すると期限系の通知が意味を持たなくなる可能性はあります。この項目の入力を運用ルールに含めておくと安全です。

通知経路の一般的な仕組みはメール通知が飛ぶまでの4段階（Notification）で、実際に届かないときの切り分けはServiceNowの通知メールはどうすれば届く？で扱いました。CIMの通知はこの一般的な仕組みの上に、CIM専用の条件（state=-4^EQなど）が乗っている形です。

承認の実体はCIM Approval WorkflowというFlow

need_approvalをtrueにしたとき、実際に何が動くのかを確認します。Flowの一覧で「CIM」を検索すると、CIM Approval Workflowという1件だけがヒットしました。

改善の承認は、このFlow1本に集約されています。 Active・全アプリケーションスコープからアクセス可能という設定で、need_approvalがtrueの間はこのFlowが承認ステップを動かします。

一覧の設定値も確認しておくと安心材料になります。ACLs欄は空欄で、このFlow自体を実行させないようにするACL制限はありません。Callable by Client APIはfalseなので、クライアント側のスクリプトから任意に呼び出すことはできず、CIMの状態遷移をトリガーにしてサーバ側からのみ動く設計です。Allow high security rolesもfalseで、高セキュリティロール専用の特別扱いはされていません。標準の状態遷移に素直に反応するだけの、シンプルなFlowだと分かります。

承認先を自社のワークフローに合わせて変えたい場合は、このFlowを開いて承認者の決め方（グループ承認か個人承認か）を確認するところから始めます。承認の一般的な仕組みは承認（Approval）完全ガイドにまとめてあり、CIM固有の承認もこの延長線上で読めます。

ACLは60件、書き込み制限が中心の設計

権限まわりでもう1つ確認しておきたいのがACLです。sn_cimで始まるACLは60件ありました。多いのはwrite 21件・create 16件・read 7件・list_edit 7件です。残りはdelete 3件・report_view 3件・report_on 3件で、数はわずかです。

書かせない設計です。write と create を合わせると全体の6割を超えます。読み取り系（read・list_edit・report系）は少数派です。この設計は「見せる」より「勝手に書かせない」方向に寄っています。 改善イニシアチブは承認や効果測定を経て進む前提の仕組みなので、誰でも自由にレコードを書き換えられると、Base valueやTarget valueのような効果測定の起点が壊れてしまいます。

実務では、このACLを緩める作業はほとんど発生しません。むしろ標準のACLが強めなので、ロールさえ正しく配れば追加のACL設計は不要というのが実機を見た結論です。ACLと条件の評価順で見えなくなる原因の切り分け方はロールを付けたのに見えない理由：ACL（sys_security_acl）に書きました。

Guided Setupが製品側に用意されている

設定を1つずつ自分で洗い出さなくても、ServiceNow自身が手順を用意しています。ナビゲータのAdministration配下にGuided Setupというモジュールがあり、開くとCIM専用のチェックリストが出てきました。

タスクは5つで、Request CIM・Enable Benchmarks・Add a Coaching Opportunity・Activate ITSM Content Packs・Activate Idea Portal（ロック中）でした。Guided Setupの説明文にも、ここまで確認してきた内容が公式に書かれています。

Enable Benchmarksタスクの説明文には、こう書かれていました。

これはCIM本体の設定ではなく、業界平均と比較するBenchmarksという別機能へのオプトインです。必須なのはRequest CIM（プラグイン自体の有効化）だけで、Enable BenchmarksやAdd a Coaching Opportunityは別モジュールの機能なので後回しにできます。選べるだけです。Guided Setupは「全部やる手順書」ではなく「選んでよいメニュー」として読むのが実際に近い使い方です。

実機を見て気づいたこと

Guided SetupのRequest CIMが導入後も未完了のまま

CIMプラグインは既に有効化されているのに、Guided Setupを開くとRequest CIMが「Not started yet」のままでした。最初はプラグイン状態と連動していると思っていましたが、実機では連動していません。Guided Setupの完了フラグは、プラグインのactive状態とは別に、タスクごとに手動でMark as Completeを押すまで更新されない仕組みでした。導入済みでも、Guided Setup側の表示だけを見て「まだ入っていない」と誤解しないほうがいいというのが実機で分かったことです。

initiative_copy_attributesにstrategic_objectiveが含まれていた

sn_cim.initiative_copy_attributesの値を確認すると、strategic_objectiveという項目が複製対象に入っていました。改善イニシアチブを経営目標に紐づける項目です。ナビゲータでEnterprise Strategiesを開くと、8件の戦略目標がすでに定義済みでした。

マスタデータとして戦略目標が最初から用意されていることに、この項目を見るまで気づきませんでした。改善イニシアチブと経営目標を紐づけたいなら、CIMを触る前にEnterprise Strategiesの中身が自社の実態に合っているかを確認しておくと、あとで入れ直す手間が省けます。

ACLの強さとロールの絞り込みが噛み合っている

ACLがwrite/create中心に寄っている理由は、ロールの配り方を見て腑に落ちました。improvement_requesterは自分のレコードしか触れず、improvement_managerだけが全件を編集できる設計です。ACLを緩める前に、まずロールの配り方を見直すほうが早いケースがほとんどでした。権限が足りないと感じたら、ACLをいじる前にロールの割り当てを疑うという順番は、CIM以外の標準アプリでも通用する考え方です。ACLとロールと画面表示のどこで権限が決まるかを層で追う方法はServiceNowで権限はどこで決まる？にまとめました。

Activate Idea Portalだけ鍵アイコンが付いていた

Guided Setupの5タスクのうち、Activate Idea Portalだけ鍵アイコンが付いていて、他の4件のようにMark as Completeを押せる状態ではありませんでした。CIMのプラグイン単体では有効化できず、Idea管理系の別プラグインが前提になっていると読めます。画面上でロックされている項目は、CIM本体の設定を見直しても解決しないことがある、という実例です。無理に触ろうとする前に、鍵アイコンの意味を確認したほうが早く判断できます。

実務では何に使えるか

ここまでの内容を、着手前と着手後に分けて整理します。

今すぐ決めること

承認を挟むかどうか（need_approval）、CIM本体4ロールを誰に配るか、通知7件の宛先が意図した相手になっているか。この3点はWorkbenchを現場に開放する前に確定させます。あとから承認の有無を変えると進行中のイニシアチブが混乱しますし、ロールを配り直すのも手間がかかります。

後回しでよいこと

create_default_phaseの有効化、Skills・Coaching・Spotlight由来の12ロールの配布、Guided SetupのBenchmarksやCoachingの項目。これらは使う予定ができてから着手すれば十分です。最初から全部を設定しようとすると、判断すべき項目に埋もれて動けなくなります。

小さく始める順番

1. need_approvalを業務に合わせて確定する（既定のtrueのままでよいことも多い）

2. improvement_requesterを対象部署に配る

3. improvement_coordinatorを事務局の数名に割り当てる

4. 通知のwatch_listとassignment_groupが意図通りかテスト1件で確認する

5. ここまで終わったらWorkbenchを開放する

この4項目さえ決まれば、CIMは使い始められます。 残りは運用しながら詰めていけば十分な設定です。

他のプラグインでも同じ4点セットで確認できる

ここで使った確認の順番は、CIM専用ではありません。プロパティ・ロール・通知・承認という4点は、どのプラグインを導入したときでも最初に見る場所として使い回せます。プロパティは業務判断、ロールは配布範囲、通知は宛先、承認は経路。この4つを押さえれば、増えたテーブルやACLの件数を1件ずつ追わなくても、運用開始の可否を判断できます。

設定が終わったあとの健全性チェックを機械化したい場合は、Instance Scan：設定の「よくない状態」を機械に探させるで扱った仕組みが使えます。空のACLや権限の重複のような「よくない状態」を、導入直後にまとめて洗い出せます。

用語

CIM（Continual Improvement Management）：継続的な改善活動を管理するアプリケーション。プラグインはcom.sn_cim。

改善イニシアチブ（sn_cim_register）：改善活動1件を表すレコード。

CIM Task（sn_cim_task）：改善イニシアチブを実行に分解したタスク。

Improvement KPI：改善対象の指標。Performance Analyticsのインジケータを参照する。

Guided Setup：ServiceNowが用意する設定手順のチェックリスト画面。ITSM Guided Setupの一部としてCIM専用の項目がある。

CIM Approval Workflow：need_approvalが有効なときに承認ステップを動かすFlow。

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

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

• CIMのプロパティ一覧：/sys_properties_list.do?sysparm_query=nameSTARTSWITHsn_cim

• CIMの設定画面（編集用）：/system_properties_ui.do?sysparm_title=Continual Improvement Management Properties&sysparm_category=Continual Improvement Management

• CIMのロール一覧：/sys_user_role_list.do?sysparm_query=nameSTARTSWITHsn_cim

• CIMの通知一覧：/sysevent_email_action_list.do?sysparm_query=tableSTARTSWITHsn_cim

• CIMのACL一覧：/sys_security_acl_list.do?sysparm_query=nameSTARTSWITHsn_cim

• 承認Flow：/sys_hub_flow_list.do?sysparm_query=nameLIKECIM

• Guided Setup：/$guided_setup.do

• Enterprise Strategies：/enterprise_strategy_list.do

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

この記事で引用した説明文は、ServiceNowが製品に同梱しているプロパティのドキュメントです。次のURLを自分のインスタンスで開くと、この記事で引用した文言と同じものが表示されます。

• プロパティの公式説明（引用元）：/sys_properties_list.do?sysparm_query=nameSTARTSWITHsn_cim^descriptionISNOTEMPTY

• Guided Setupの説明文（引用元）：/$guided_setup.do#/content/0313a2badb2600101391f1471d961983

検証範囲とおことわり

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

プロパティやロールの値を実際に変更する作業は行っていません。 既定値の読み取りと、設定画面・一覧画面のスクリーンショットで確認した範囲です。need_approvalをfalseにしたときの挙動、フェーズを有効化したあとの画面遷移は未検証です。

Guided SetupのタスクをMark as Completeで進める操作、CoachingやSkills Managementの実際の設定は行っていません。ACL60件は操作別の件数を数えた範囲で、個々のロール条件式までは1件ずつ確認していません。

通知7件の内容確認は一覧画面から行い、実際にメールを1通送って届くところまでは見届けていません。メールが届くところまでの確認は別記事のテーマとして扱います。

関連記事

• ServiceNowの権限は誰が持っている？ ユーザー・グループ・ロールを中間表からたどる — ロール配布の前提知識

• ロールを付けたのに見えない理由：ACL（sys_security_acl） — ACLの評価順を切り分ける実務編

• ServiceNow 承認（Approval）完全ガイド：申請はどこで誰に回り、なぜ止まるのか — 承認Flowをさらに深く読む次の一歩