ServiceNowのCIM（Continual Improvement Management）プラグインをインストールする手順

2026年8月14日 18:37

継続的改善を ServiceNow で回したい。そう思って CIM（Continual Improvement Management）を調べると、「プラグインを有効化してください」で説明が終わっていることがあります。実際に PDI へ入れてみると、確認ダイアログが有償サブスクリプションの警告を出し、依存プラグインの扱いを1件ずつ表示しました。CIM を押してから使えるようになるまでを、画面ごとに残します。

検証環境：Australia PDI / OOTB / 2026-08-14 確認。対象は Continual Improvement Management（com.sn_cim v11.1.0）

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

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

結論：CIMの導入はボタン1つ。ただし押す前に読む画面が1枚あり、完了判定は画面では分からない

手順自体は Application Manager で CIM を探して Install を押すだけです。所要時間も数分でした。

引っかかるのは2か所。Install を押す前に出る「Review Installation Details」に、有償サブスクリプションの注意と依存プラグインの扱いが全部書いてあります。ここを読まずに進むと、何が一緒に入るか分からないまま導入することになります。

もう1つが完了判定です。画面上は早い段階で完了に見えますが、裏でワーカーがまだ動いています。

CIMは素のインスタンスには入っていない

ServiceNow の機能は、最初から全部使える状態にはなっていません。必要な機能を「プラグイン」として後から有効化する作りです。素の状態でも945個が有効になっていて、無効のまま眠っているものが460個あります。CIM はこの460個の側にいました。

この有効・無効を管理しているのが v_plugin で、仕組みはプラグイン（v_plugin/sys_plugins）の有効・無効と依存にまとめました。この記事はその続きで、CIM を実際に有効化するとどうなるかを扱います。

入口は Application Manager です。ナビゲータの System Definition > Plugins から開きます。CIM に限らず、プラグインを入れるときは必ずここを通ります。

Install, update, and manage licensed applications and plugins for your instance. と書かれています。タブは3つ。

Available for you … ライセンスに含まれていて、すぐ入れられるもの
Updates … 更新があるもの
Installed … 導入済みのもの

右上には Activity log（導入履歴）、Request plugin（申請）、Open store（ストアを開く）の3つ。

画面の下半分には Store applications が 2,638件と表示されていました。説明文には
Applications created by ServiceNow and third-party sources, including free trial products available for sub-prod instances only.
とあります。下位環境限定の無料トライアル製品を含むという但し書きです。ここに並ぶ数と、自社のライセンスで実際に使える数は別物になります。

左側には Filters が並びます。Listings（Applications / Plugins / Free Trials / Products）、Offered By（Partners / ServiceNow）、Price Type（Free / Paid）の3種類。プラグインだけを見たいときは Listings で Plugins に絞るのが早い。

なお Application Manager と紛らわしい画面がいくつかあります。違いはServiceNowのAdmin Centerは何をする画面？で整理しました。

CIMを検索する

画面中央の「Search your licensed applications and plugins」の下にある欄に Continual Improvement Management と入れます。

CIMの詳細ページに公式の説明が載っている

検索結果から CIM を開くと、詳細ページが出ます。

見どころが3つあります。

Summary に一行の説明。CIM の場合は Core plugin for Continual Improvement Management (CIM) でした。

Get started に導入前の注意。Once you install, we'll guide you through setup and configuration. に続けて、We recommend testing in a lower instance environment.（下位環境で試すことを推奨）と書かれています。製品側が「まず検証環境で」と明記しているわけです。

Key Features に主要機能の一覧。これは製品同梱の説明なので、そのプラグインが何をするものかを判断する材料になります。CIM では5つ挙がっていました。

Improvement workbench … Get a single view into all improvements in progress, including opportunity details.
Value realization dashboard … Compare initiative progress and outcomes to expectations related to your overall business goals.
Improvement readiness … Create opportunities in the apps you use daily, and automatically convert into records within CIM.

「日常使っているアプリから改善の種を作り、CIM のレコードに自動変換する」という3つ目の説明が、この機能の狙いをよく表しています。改善活動のための専用画面を新しく覚えさせるのではなく、既存の業務画面から拾う設計です。

ヘッダーの下には所属カテゴリ（IT Service Management）と Plugin id も出ます。右側の Helpful Resources には Product Documentation へのリンクが並びます。製品ドキュメントの入口が画面に用意されているので、外部で検索する前にここを踏むのが早い。

CIMのInstallを押す前に出るダイアログが本番

CIM の Install を押すと、すぐには入りません。確認ダイアログが出ます。この記事でいちばん見てほしい画面です。

このダイアログに出る項目を、すべて書き出します。

上から順に見ていきます。

有償サブスクリプションの警告

This plugin is associated with a for-fee subscription. More Info

「このプラグインは有償サブスクリプションに関連します」。続けて「サブスクリプションの一覧は本番インスタンスで確認できます」とも出ます。CIM は licensable = true / license_category = General なので、この警告が出ます。

PDI では課金されませんが、本番で同じものを入れるならライセンス確認が要る、という警告です。導入判断で最初に確認すべき情報が、ここに出ています。

依存プラグインが1件ずつ表示される

Dependencies の下に、依存プラグインが状態つきで並びます。

Performance Analytics - Spotlight … Will be installed（これから入る）
Continual Improvement Management Automated Tests … Will be installed
Organization Management … Installed（すでに入っている）
Performance Analytics … Installed

さらにその下に、見落としやすい一文があります。

Some files will not be loaded because these plugins are inactive:

「これらのプラグインが無効なので、一部のファイルは読み込まれません」。CIM では Project Management と Test Management が挙がっていました。

つまり CIM は Project Management と連携する作りだが、それが無効なら連携部分は入らないということです。あとから Project Management を入れたときに何が起きるかは、この画面だけでは分かりません。

インストール時期とデモデータ

Installation schedule で Install now（すぐ）か Install later（あとで）を選びます。既定は Install now でした。

左下に Load demo data のチェックボックスがあります。既定はオフです。

検証環境で機能を試すなら、ここにチェックを入れたほうが早い。空のテーブルを眺めても分からないからです。今回はチェックを入れて進めました。結果として Improvement Initiative に30件、CIM Task に70件のデモレコードが入っています。

本番では入れません。 そして後から消すのは面倒なので、ここは押す前に決めておく項目です。

CIMのメタ情報を導入前に控える

ダイアログの内容は v_plugin のレコードからも読めます。CIM の値を導入判断の材料としてまとめておきます。

licensable = true と license_category = General が、ダイアログの有償サブスクリプション警告に対応しています。block_install = false なら導入がブロックされていません。

scope も見ておく価値があります。CIM は sn_cim という専用スコープを持ちます。スコープが分かれているということは、テーブルもスクリプトもそのスコープの中に作られるということです。Global に混ざらないので、後から「どれがこのプラグインのものか」を追いやすい。スコープの考え方はアプリとスコープ：Globalとx_の違いにまとめました。

CIMを押したあと：完了判定を間違えない

Install を押すと処理が始まります。

ここが2つ目の引っかかりどころでした。v_plugin.active は比較的すぐ active になります。 ところがそれは「本体の登録が終わった」状態で、処理はまだ続いています。

実際、本体が active になった時点で依存の Automated Tests はまだ Inactive のままでした。裏で CICDPluginManagerWorker というワーカーが動いていて、それが消えてから見直すと Active に変わっていました。

確実な完了判定は2つ揃ったときです。

v_plugin で対象プラグインが active
sys_progress_worker に PluginManagerWorker が残っていない

画面のメッセージだけで判断すると、増えたものを数え損ねます。

両方そろうと、Application Manager 側の表示もこうなります。

導入後の画面でCIMを確かめる

完了したら Installed タブに移ります。CIM がここに並びます。

プラグインのレコード自体も開けます。バージョンや状態はここが一次情報です。

導入履歴は別のリストに残ります。いつ誰が入れたかを追うときはこちらです。

ナビゲータにもモジュールが増えています。

導入直後に開く7画面

完了を確認したら、次の画面を順に開きます。この7つを見れば、何が起きたかがひと通り追えます。

増えたテーブルは、スコープごとに分かれて作られます。

名前の頭でどのアプリのものか判別できるので、棚卸しが楽になります。テーブルが増えたときに中身まで確かめる手順はServiceNow Australiaで増えた340テーブル、中身があるのは何件？にまとめました。

CIMのダイアログ表示と、実際に入ったものはズレる

導入後に v_plugin を数え直したところ、有効なプラグインは4つ増えていました。

ダイアログで Will be installed と表示されていたのは2つ。実際に増えたのは4つで、Skills Management はダイアログに1度も出てきませんでした。

Project Management と Test Management は宣言どおり Inactive のままです。ただし後述のとおり、テーブルは増えています。

確認ダイアログは「主要な依存」を見せてはくれますが、入るものの全部ではありません。 影響範囲を正確に知るには、導入前後で数えるしかない、というのが今回の結論です。増えたテーブル67個・ロール21個の内訳は別記事にまとめます。

Install later を選ぶとどうなるか

Installation schedule にはもう1つ Install later があります。今回は選んでいないので挙動は確かめていませんが、選択肢が用意されていること自体が重要です。

本番のプラグイン導入は、たいてい作業窓が決まっています。深夜に実行したいのに、その時間に人が張り付くのは避けたい。予約実行の口が標準で用意されているなら、手順書の書き方が変わります。

本番導入を計画するなら、検証環境で一度 Install later を試して、予約がどこに記録され、失敗したときに何が残るかを確認しておく価値があります。ここは今回の検証範囲外です。

CIMはアンインストールできるのか

結論から書くと、CIM は supports_rollback = true（ロールバック対応）でした。

ただし Application Manager の画面に「アンインストール」のボタンは見当たりません。ServiceNow のプラグインは、一般に有効化したら画面から自前で消す運用にはなっていないと考えたほうが安全です。ロールバックが必要な場面では、サポートへの依頼や、そもそも入れ直せる検証環境を使うのが現実的です。

検証環境で試してから本番、という順番を崩さない。 詳細ページの We recommend testing in a lower instance environment. は、その意味でも読み流せない一文です。

CIMの導入に必要な権限と、かかった時間

導入操作は admin ロールで行いました。プラグインの有効化は admin 相当の権限が要る操作で、開発者に配る権限とは別物です。誰に触らせるかを絞る話はServiceNowでadminを配らずに開発させるには？で扱いました。

時間の実測はこうでした。Install を押してから v_plugin.active が active に変わるまでが30秒ほど。そこから CICDPluginManagerWorker が消えるまでがさらに数分です。

CIM はデモデータありで、依存が2つ新規に入る条件でこの程度でした。大きなアプリでは桁が変わるので、本番の作業時間はプラグインごとに測り直す必要があります。作業窓を確保するときは、画面が完了に見えてからも待つ時間を見込んでおくと安全です。

導入中もインスタンスは使えました。ただし裏でテーブル作成とデータ投入が走るので、利用者の少ない時間帯に寄せるのが定石です。

作業計画を書くときは、この表の「active → ワーカー消滅まで」を忘れないでください。ここを省くと、確認作業が空振りします。

実機を見て気づいたこと

確認ダイアログが実質のドキュメントだった

導入手順を調べようとすると、つい外部の記事を探しに行きます。ところが判断に必要な情報のほとんどは Review Installation Details に出ていました。有償サブスクリプションかどうか。何が一緒に入るか。何が入らないか。デモデータをどうするか。

しかもこの画面はプラグインごとに内容が変わります。CIM では依存が4件と「無効なので読み込まれない」が3件でしたが、別のプラグインなら別の並びになる。つまり外部の記事を読むより、自分の環境でこのダイアログを開くほうが正確です。

押す前に1枚撮っておけば、そのまま導入記録になります。あとで「なぜこの依存が入っているのか」を聞かれたとき、当時の画面が答えになります。

「入る」「入らない」が3種類あった

ダイアログの表示は Will be installed / Installed / Inactive plugins の3種類でした。3つ目は「入らない」ではなく「そのプラグインが無効なので、関連するファイルだけ読み込まれない」という意味です。

依存が全部入るわけでも、全部入らないわけでもない。部分的に入る、という状態があるのを画面で初めて理解しました。

権限の選択肢が静かに増える

導入すると、ロールの選択肢が増えます。CIM では21件でした。

使う予定のない機能のロールまで並ぶのが厄介なところです。権限を配るときに選択肢が増え、棚卸しのときに「これは何だ」となる。ロールの包含で想定外の権限が付く話はServiceNowで付けたロールが想定外の権限を含んでいた理由にまとめました。

導入直後に一覧を控えておくと、あとで説明できます。

増えたテーブルは「素の状態」の基準を崩す

導入すると、そのインスタンスは二度と素の OOTB には戻りません。リリース間の差分を数えたZurichとAustraliaを並べて数えたら何が変わっていたかのような比較は、素の環境でないと成立しません。

検証用インスタンスを2つ持っているなら、片方は何も入れずに残しておくと後で効きます。今回はそれを承知のうえで、比較基準を1つ手放しました。

実務では何に使えるか

導入前チェックリストとして使う

この記事の流れは、そのまま社内の導入チェックリストにできます。

v_plugin でメタ情報を控える（id / version / scope / licensable / block_install / supports_rollback / has_demo_data）
詳細ページの Summary と Key Features を読む
Install を押し、確認ダイアログをスクリーンショットで保存してから進む
デモデータの要否を環境ごとに決める
導入後、v_plugin.active とワーカーの2点で完了を判定する
導入前後で件数を数え、影響範囲を記録する

3番目のスクリーンショットが後で効きます。 「なぜこの依存が入っているのか」を半年後に聞かれたとき、当時の画面が残っていれば説明が10秒で終わります。

増えたロールと ACL は、そのまま権限設計の対象になります。どの層で権限が決まるかはServiceNowで権限はどこで決まる？を前提にすると整理しやすい。

導入判断の材料を1画面で揃える

本番導入の稟議で必要なのは「有償か」「何が一緒に入るか」「戻せるか」の3点です。Review Installation Details と v_plugin のレコードで、この3つは埋まります。

外部の情報を集める前に、自分の検証環境で同じプラグインを開いてダイアログを読む。それがいちばん早い。

デモデータの判断を先に決める

チェックボックス1つですが、後から効いてきます。検証環境なら入れる、本番なら入れない。組織で導入手順書を作るなら、ここは明示的に書いておく項目です。

他環境へどう反映するかを先に決める

プラグインの有効化は、更新セットに載せて運ぶものではありません。移送先の環境でも同じように有効化するのが基本です。

つまり開発・検証・本番の3環境があるなら、3回同じ導入をします。更新セットに乗るのは、そのあとのカスタマイズ分だけ。箱の考え方はUpdate Set（sys_update_set）：設定を運ぶ2層の箱にまとめました。

導入手順書には「どの環境で、いつ、誰が有効化するか」を環境ごとに書く必要があります。

記録に残すのは3点でよい

導入作業のあと、残しておくと後で効くのは3つだけです。

全部を細かく記録しようとすると続きません。この3点に絞ると、次のプラグインでも同じ形で運用できます。移送の考え方はUpdate Set（sys_update_set）：設定を運ぶ2層の箱と合わせて整理すると、環境ごとの作業が見通せます。

完了判定の手順を手順書に書く

「画面が完了と言ったら完了」ではありません。v_plugin.active とワーカーの2点確認を手順書に入れておくと、導入直後の確認作業で数え間違いが減ります。

用語

プラグイン：ServiceNow の機能単位。有効化して使えるようにする。管理テーブルは v_plugin。

Application Manager：プラグインとストアアプリを導入・管理する画面。/now/app-manager/home。

Review Installation Details：Install を押したあとに出る確認ダイアログ。依存とライセンスの注意が出る。

Load demo data：デモ用のレコードを一緒に入れるかどうかの選択。既定はオフ。

supports_rollback：v_plugin のフィールド。ロールバックに対応しているかを示す。

CICDPluginManagerWorker：プラグイン導入を実行するバックグラウンドワーカー。sys_progress_worker で見える。

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

自分のインスタンス名に続けて開きます。

Application Manager：/now/app-manager/home
プラグインのレコード：/v_plugin.do?sys_id=com.sn_cim
未導入のプラグイン一覧：/v_plugin_list.do?sysparm_query=active%3Dinactive%5EORDERBYname
導入済みプラグイン一覧：/v_plugin_list.do?sysparm_query=active%3Dactive%5EORDERBYname
プラグインの導入履歴：/sys_plugins_list.do?sysparm_query=ORDERBYDESCsys_created_on
実行中・実行済みのワーカー：/sys_progress_worker_list.do?sysparm_query=ORDERBYDESCsys_created_on

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

この記事で引用した文言は、ServiceNow が製品に同梱しているものです。

プラグインの説明（引用元）：/v_plugin_list.do?sysparm_query=descriptionISNOTEMPTY
詳細ページの Summary / Key Features / Get started：Application Manager でプラグインを開くと表示されます
Review Installation Details：詳細ページで Install を押すと表示されます

検証範囲とおことわり

Australia の PDI（OOTB）で 2026-08-14 に確認しました。対象は Continual Improvement Management（com.sn_cim / version 11.1.0）です。

この記事のために CIM を実際に導入しています。 読み取りだけの記事ではありません。導入先は検証用の PDI で、本番環境ではありません。

アンインストールは試していません。supports_rollback の値と画面に導線が見当たらないことを確認した範囲で書いています。実際にロールバックしたらどうなるかは未検証です。

Install later は選んでいません。予約実行したときの挙動は分かりません。

デモデータを入れた状態での導入です。入れない場合に増えるレコード数は変わります。

他のプラグインでは依存の数も、有償サブスクリプションの警告の有無も変わります。ここに書いた画面の並びは共通ですが、表示内容は CIM の場合のものです。

プラグイン（v_plugin/sys_plugins）の有効・無効と依存 — 前提知識として、プラグインの管理テーブル
Build Agent（Trial）はインスタンスに何を入れるか — 別のアプリを入れたときの変化
ServiceNowの標準ダッシュボード28本を全部開いた — 導入で増えるダッシュボードの前提