ServiceNowでプラグインを入れると何が変わる？影響調査でチェックする27か所

2026年8月14日 18:45

「このプラグインを入れたら、インスタンスにどれくらい影響がありますか」。本番導入の判断で必ず出る質問です。ところがどこを見れば答えられるのかを書いた資料がほとんどありません。導入前後で数える場所を27か所に整理し、実際に CIM を1つ入れて検証しました。数字より「どこを見るか」を持ち帰ってください。

検証環境：Australia PDI / OOTB / 2026-08-14 確認。検証に使ったのは Continual Improvement Management（com.sn_cim）

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

この記事は追記型です。 別のプラグインを導入するたびに、チェック項目と実測ケースを足します。

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

結論：見るべきは27か所。増分の数字より「どこが動いたか」で判断する

プラグインの影響調査は、測る場所を先に決めておかないと成立しません。導入前の状態は一度しか取れないからです。

整理すると、確認すべき場所は27か所ありました。系統は7つ。土台・権限・ロジック・実行・通知・画面・分析です。それに公開ページと設定が加わります。

このうち優先度が高いのは3つでした。

公開ページ（sys_public）… 未認証で見える範囲が広がっていないか。ここが動いたら最優先で調べる
通知（sysevent_email_action）… 導入直後からメールが飛ぶ経路が増える。宛先の確認が要る
ロール（sys_user_role）… 権限の棚卸し表に行が増える。使わない機能のロールの扱いを決める

残りは「増えて当然」のものが多く、異常の検出というより規模の把握に使います。

なぜ「数える」必要があるのか

プラグインの影響範囲を知る方法は、普通は3つ考えられます。

1つ目がドキュメントを読む。何が追加されるかが書かれていることもありますが、依存プラグインの追加分まで網羅されていることは少ない。

2つ目が依存リスト（requires）を見る。これは v_plugin から取れます。仕組みはプラグイン（v_plugin/sys_plugins）の有効・無効と依存にまとめました。ただし後述のとおり、ここに載っていないものが入ります。

3つ目が導入前後で数える。確実ですが、導入前の状態は一度しか取れません。押してしまってからでは遅い。

この記事は3つ目をやりました。導入の手順そのもの（Application Manager の画面と確認ダイアログ）は別記事で扱います。

何を数えたか

REST の集計APIで、27種類のテーブルの件数を導入前後で取りました。テーブル定義・フィールド定義・ロール・モジュール・ACL・ビジネスルール・スクリプトインクルード・通知・レポート・ダッシュボードなど、「設定が増えたら必ずどこかに行が増える」場所を選んでいます。

導入ケース1：Continual Improvement Management

ここからが実測です。1つ目のケースとして CIM を入れました。プラグインを入れるたびに、この表へ行を足します。

CIM は1つ入れたつもりが4つ入りました。全体像はこうなります。

増減の全体像

導入前後の実測です。

目を引くのは3つです。

ACLが515件増えました。 これはテーブルが増えれば自動的に増えるものですが、権限設計の対象がそれだけ増えたとも読めます。

67テーブルで515件なので、1テーブルあたり約7.7件。ServiceNow の ACL は操作（read / write / create / delete）とフィールド単位で分かれるので、この密度は標準的です。仕組みはロールを付けたのに見えない理由：ACL（sys_security_acl）にまとめました。

既存ロールとの衝突がないかは別途見る必要があります。 権限がどの層で決まるかの全体像はServiceNowで権限はどこで決まる？にあります。

フィールド定義が775件増えました。 67テーブルで割ると1テーブルあたり11.5フィールド。標準的な規模です。

ただし継承しているテーブルでは、この数字は実感とずれます。Improvement Initiative は Planned task を継承しているので、画面に出る項目数は「自分の775件ぶんの一部」よりずっと多い。継承元から受け継ぐ項目は、この増分に含まれません。

選択肢（sys_choice）も205件増えました。状態やカテゴリの選択肢が、それだけ定義されたということです。状態の選択肢は、そのまま製品が想定しているライフサイクルなので、機能を理解するときの手がかりになります。

公開ページとワークフローは増減ゼロでした。 未認証で見える範囲は変わっていません。プラグインを入れても外部公開の口は増えない、というのは安心材料になります。

増えた67テーブルの内訳

テーブル名の頭を見ると、どのプラグインのものかが分かります。

CIM本体（sn_cim_*）は5個だけ。いちばん多いのは spotlight_* の24個です。

24個のうち16個はログの分割テーブルだった

spotlight_* を並べると、こういうものが混ざっています。

spotlight_copy_log_row0000
spotlight_copy_log_row0001
…
spotlight_job_log_row0007

_row0000 から _row0007 まで、8個ずつ2系統で16個。これはログを分割して持つための実体テーブルで、機能として意識するものではありません。

「67個増えた」を額面で受け取ると、影響を過大評価します。 実際に人が触るテーブルは、この16個を引いた51個。さらにそのうち本体は5個です。

数え方の粗さがそのまま結論を歪める例で、テーブル数を数えるときは中身を見る必要があると分かります。増えたテーブルの実体を確かめる作業はServiceNow Australiaで増えた340テーブル、中身があるのは何件？でもやりました。

CIM本体の5テーブルは何を持っているか

本体だけ取り出すと、構造がはっきりします。

Improvement Initiative（改善イニシアチブ）が主役で、Planned task を継承しています。CIM Task も同じ継承元です。

継承元が Planned task だということは、CIM は「計画タスク」の仕組みの上に乗っているという意味です。開始日・終了日・進捗といった項目は、そこから受け継いでいます。だから Project Management のテーブル群が一緒に入ってきたわけです。

Impacted KPIs（影響を受けるKPI）は継承なしの独立テーブルで、改善活動とKPIを結びつけます。残る2つは連携用のM2Mテーブルで、導入直後は0件でした。

デモデータを入れたので、Improvement Initiative に30件、CIM Task に70件が入っています。1つの改善イニシアチブにつき2〜3個のタスクがぶら下がる構成が、この件数から読めます。

依存の宣言と、実際に入ったものはズレた

ここがこの記事でいちばん伝えたい部分です。

導入前、確認ダイアログはこう表示していました。

Performance Analytics - Spotlight … Will be installed
Continual Improvement Management Automated Tests … Will be installed
Organization Management … Installed
Performance Analytics … Installed
Project Management … Inactive plugins（一部のファイルが読み込まれない）
Test Management … Inactive plugins

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

+ Continual Improvement Management (CIM)
+ Continual Improvement Management Automated Tests
+ Performance Analytics - Spotlight
+ Skills Management

表示されなかったのに入ったもの

Skills Management はダイアログに1度も出てきません。 requires にも載っていません。それでも有効になり、cmn_skill_* 系のテーブルが12個増えました。

推測になりますが、Coaching が Skills Management を必要とし、Coaching は CIM のスコープに含まれるため連鎖したように見えます。ただし連鎖の経路は追い切れていません。確実なのは「宣言に無いものが入った」という事実だけです。

無効のままなのにテーブルは増えたもの

逆のパターンもありました。Project Management は宣言どおり Inactive のままです。ところが planned_task_* と pm_console_* のテーブルが16個増えています。

矛盾しているように見えますが、そうではありません。CIM が Planned task を継承している以上、その親テーブルは必要です。だから基盤部分だけが入り、Project Management というアプリ自体は無効のまま、という状態になります。

ダイアログの Some files will not be loaded because these plugins are inactive: は、この状態を指した表示です。「全部入る」でも「全部入らない」でもなく、必要な分だけ入る。

増えた21ロールが権限設計に効く

実務でいちばん影響が大きいのはロールです。

21件の内訳はこうなっていました。

CIM本体（4件）：sn_cim.admin / sn_cim.improvement_manager / sn_cim.improvement_coordinator / sn_cim.improvement_requester

Coaching（3件）：sn_coaching.admin / sn_coaching.coach / sn_coaching.trainee

Skills Management（5件）：skill_admin / skill_manager / skill_model_admin / skill_model_user / skill_user

PA Spotlight（4件）：pa_spotlight / pa_spotlight_viewer / pa_spotlight_copy_breakdown / pa_spotlight_copy_domain

プロジェクト管理系（5件）：project_manager / project_user / planned_task_read / planned_task_user / planning_console_user

CIM本体の4ロールを見ると、製品が想定している役割分担がそのまま出ています。管理者・改善マネージャ・調整担当・申請者の4階層です。誰に何を割り当てるかを設計するとき、この4つが出発点になります。

一方で、プロジェクト管理のロールが5件付いてくるのは想定外でした。改善管理を入れたつもりが、project_manager というロールが選択肢に並びます。権限の棚卸しをしている組織では、これが「誰も使っていないロール」として検出されます。

ロールの包含関係で想定外の権限が広がる話はServiceNowで付けたロールが想定外の権限を含んでいた理由にまとめました。増えたロールは、そのまま棚卸しの対象になります。

ナビゲータには47モジュールが増えた

画面側の変化も見ておきます。

有効なモジュールが47個増え、アプリケーションメニューが5個増えました。ナビゲータに新しいアプリが5つ現れたということです。

ダッシュボードは3個、インジケータは14個、レポートは27個増えています。PA Spotlight が入った影響で、分析まわりの部品がまとまって増えました。

分析まわりの部品も増えていた

見落としやすいのが、レポートとダッシュボードです。

レポート +27
ダッシュボード +3
インジケータ +14
アセスメント種別 +2

PA Spotlight が入った分と、CIM 自身が持ち込んだ分の合計です。標準ダッシュボードが3つ増えたということは、Analytics Center の一覧にも3件足されているはずです。素の状態で28本だったので、31本になります。標準ダッシュボードの全体像はServiceNowの標準ダッシュボード28本を全部開いたにまとめました。

インジケータが14個増えたのも見逃せません。インジケータはスコアを定期的に溜める仕組みなので、増えた分だけ収集ジョブの対象が増えます。導入直後は数字が入らず、ジョブが回ってから埋まります。

通知が19件、スケジュールジョブが9件、イベント登録が12件増えました。通知が19件増えるということは、条件次第でメールが飛ぶ経路が19本増えたということです。本番導入では、これらが誰に飛ぶのかを確認してから有効化したほうが安全です。

同じ計測を自分でやるには

やることは3つだけです。

導入前に数える。テーブル定義・フィールド定義・ロール・モジュール・ACL・ビジネスルールなど、増えたら行が増える場所の件数を記録する
導入する
もう一度数えて引き算する

件数は集計API（/api/now/stats/<テーブル>?sysparm_count=true）で取れます。名前まで控えておくと、増えたレコードの中身も後から特定できます。

この記事でいちばん価値があるのは数字そのものではなく、この手順です。 プラグインが変われば数字は変わりますが、やることは変わりません。

注意点が2つあります。

1つ目。読み取れないテーブルがあります。 password_policy のようにAPIレベルでACLが効いているものは件数が取れません。対象から外すか、画面で数えることになります。

2つ目。導入直後に数えると早すぎます。 バックグラウンドのワーカーが終わる前に数えると、増分を取りこぼします。今回も、本体が有効になった時点ではまだ依存の1つが処理中でした。ワーカーが消えてから数え直してください。

スコープが4つ増えた意味

地味ですが効いてくるのが、アプリケーションスコープの増加です。741から745へ、4つ増えました。

増えたのは CIM（sn_cim）、Coaching、Skills Management、PA Spotlight のぶんです。スコープが分かれているということは、そのアプリのテーブルやスクリプトが独立した区画に入るということ。Global に混ざりません。

これは後から効きます。「どれが CIM のものか」を調べたいとき、スコープで絞れば一発です。逆にスコープをまたぐ参照には制限がかかるので、自社で CIM に手を入れるときは、どのスコープで開発するかを先に決める必要があります。

スコープの考え方はアプリとスコープ：Globalとx_の違いにまとめました。

もう1点。この増分は更新セットには乗りません。プラグインの有効化は移送するものではなく、環境ごとに実施する作業です。移送するのは、そのあとで自分が加えた設定だけ。箱の考え方はUpdate Set（sys_update_set）：設定を運ぶ2層の箱にあります。

開発・検証・本番の3環境があるなら、この記事の計測も3回できます。 環境ごとに増分が一致するかを確かめると、移送漏れの検出になります。

実機を見て気づいたこと

「本体5個・依存62個」という比率が判断を変える

導入前に想像していたのは「CIMのテーブルが数十個増える」でした。実際は本体5個です。

これが分かると、評価の焦点が変わります。CIM そのものの複雑さより、一緒に入ってくる Skills Management や Coaching をどう扱うかのほうが大きな論点になる。使わない機能のロールとテーブルが残り続けるからです。

数える対象を決めておかないと比較できない

今回は27種類のテーブルを固定して数えました。あとから「ビジネスルールも見たかった」と思っても、導入前には戻れません。

測る項目は導入前に決めておくしかない。今回使った項目一式は、次のプラグインでもそのまま使えるように道具として残しました。

ログの分割テーブルが数を膨らませる

_row0000 形式のテーブルが16個。全体の24%です。この形式を知らないと、影響範囲を1.3倍に見積もります。

同じことは他のプラグインでも起きるはずで、テーブル数を報告するときは「ログの実体テーブルを除く」と但し書きを付けたほうが正確です。

実務では何に使えるか

導入判断の資料を数字で作る

「影響は軽微です」と口頭で言うより、増減表を1枚見せるほうが早く終わります。とくにACLとロールの増加数は、セキュリティ担当が必ず聞く項目です。

使わない機能の扱いを先に決める

一緒に入る機能を無効化できるとは限りません。今回なら Skills Management と Coaching が該当します。

「入るが使わない」ものをどうするかを導入計画に書いておく。ロールを誰にも割り当てない、モジュールをナビから隠す、といった対処を先に決めておけば、運用開始後の混乱が減ります。

今回の実測をそのまま計画表にすると、こうなります。

この形にしておくと、半年後に「このロールは何だ」と聞かれたときに即答できます。付いてきただけなのか、意図して入れたのかが表から分かるからです。

無効化できるかどうかは機能によります。プラグインを個別に無効化する操作は標準では用意されていないので、現実的な対処は「配らない・見せない」になります。

誰にどのロールを配るかを4階層から始める

CIM本体の4ロールは、そのまま役割設計の下敷きになります。

sn_cim.improvement_requester … 改善の種を出す人。現場の担当者全員が候補
sn_cim.improvement_coordinator … 出てきた種を整理・調整する人
sn_cim.improvement_manager … 改善活動を承認し、進捗を見る人
sn_cim.admin … 設定を触る人

「申請者を広く、管理者を狭く」という配り方が製品の想定です。ユーザー・グループ・ロールの結び付き方はServiceNowの権限は誰が持っている？にまとめました。

一方で、付いてきた12ロール（Skills / Project / Spotlight / Coaching）は誰にも配らないという判断もあります。使わない機能のロールを配ると、使われないメニューが増えて現場が混乱します。

権限の棚卸しリストを更新する

増えた21ロールは、そのまま棚卸し表への追加行になります。導入のたびにこれをやらないと、「誰も使っていないロール」が静かに増えていきます。

次のプラグインでも同じ手順を使う

この記事でやったことは、プラグインが変わっても同じです。導入前に数える、導入する、もう一度数える、差を見る。

手順を固定しておくと、2回目からは30分で終わります。 社内で複数のプラグインを検討しているなら、比較表が作れます。

この記事の育て方

プラグインを導入するたびに、次の3つを足していきます。

ケース一覧に1行（どのプラグインで何が増えたか）
新しく気づいたチェックポイント（27か所で足りなかった場所）
数え方の落とし穴（今回のログ分割テーブルのような、数字を歪めるもの）

チェックポイントは今回27か所ですが、これで完全とは思っていません。統合系のプラグインなら外部連携の設定、ワークスペース系なら UX ページ、といった具合に、種類ごとに見るべき場所が増えるはずです。

読んでいて「ここも見たほうがいい」という場所があれば、追記の候補にします。

用語

依存（requires）：v_plugin のフィールド。そのプラグインが必要とする他のプラグイン。ここに載っていないものも入ることがある。

Improvement Initiative（sn_cim_register）：CIM の主役テーブル。改善活動の1件を表す。

Planned task（planned_task）：計画タスクの基盤テーブル。開始日・終了日・進捗を持ち、CIM やプロジェクト管理が継承する。

分割テーブル（_row0000 形式）：ログを分けて保持する実体テーブル。機能として意識するものではない。

スコープ：アプリケーションの区画。CIM は sn_cim を持つ。

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

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

有効なプラグイン：/v_plugin_list.do?sysparm_query=active%3Dactive%5EORDERBYname
CIM のテーブル：/sys_db_object_list.do?sysparm_query=nameSTARTSWITHsn_cim%5EORDERBYname
CIM のロール：/sys_user_role_list.do?sysparm_query=nameSTARTSWITHsn_cim%5EORDERBYname
増えたモジュール：/sys_app_module_list.do?sysparm_query=active%3Dtrue%5EORDERBYDESCsys_created_on
テーブルの継承元を見る：/sys_db_object_list.do?sysparm_query=nameSTARTSWITHsn_cim（Extends 列を出す）
ACL の総数を数える：/sys_security_acl_list.do

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

テーブルのラベルと継承元（引用元）：/sys_db_object_list.do?sysparm_query=nameSTARTSWITHsn_cim
プラグインの説明（引用元）：/v_plugin_list.do?sysparm_query=id%3Dcom.sn_cim
依存の宣言（引用元）：同レコードの Requires フィールド

検証範囲とおことわり

Australia の PDI（OOTB）で 2026-08-14 に確認しました。この記事のためにプラグインを1つ導入しています。 導入先は検証用の PDI で、本番環境ではありません。

デモデータを入れた状態での導入です。入れない場合、レコード件数は0になりますが、テーブル・ロール・ACL の増減は変わらないはずです（未検証）。

数えたのは27種類のテーブルだけです。これ以外にも増えているものはあります。網羅ではありません。

Skills Management が入った経路は追い切れていません。Coaching 経由だと推測していますが、確認したのは「宣言に無いものが有効になった」という事実だけです。

Project Management を後から有効化したら何が起きるかは試していません。今回は無効のままです。

他のプラグインでは依存の構成も増える数も変わります。この記事の数字は CIM の場合であって、一般化できません。 手順のほうを持ち帰ってください。

プラグイン（v_plugin/sys_plugins）の有効・無効と依存 — 前提知識として、プラグインの管理テーブル
ServiceNow Australiaで増えた340テーブル、中身があるのは何件？ — 増えたテーブルの中身を確かめる別の例

ServiceNowでプラグインを入れると何が変わる？影響調査でチェックする27か所

結論：見るべきは27か所。増分の数字より「どこが動いたか」で判断する