ServiceNowのCIMはIncidentやProblemとどうつながる？ 他モジュールから改善案を起票する仕組み
「このインシデント、毎月同じ理由で上がってくる」と気づくのは、たいてい対応中の担当者です。ところが改善活動の管理画面は別のところにあって、気づいた人は結局そこまで行きません。ServiceNowのCIMは、この距離を埋めるためにIncidentのフォームから直接、改善案を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本） — 導入から設計・運用・トラブルまで通しで書いています。
⑧連携：IncidentやProblemとどうつながるか（この記事）
結論：入口は10テーブル分、出口は6テーブル分が用意されていて、動くのはそのうち一部
CIMは孤立したアプリケーションではありません。他モジュールのフォームから改善案を起こす「入口」と、改善から次の作業を作る「出口」の両方を持っています。
Australia PDI で確認すると、製品が想定している連携先は入口10テーブル・出口6テーブルでした。ただし実際に画面へリンクが出たのは、入口8つと出口3つです。残りは対象のプラグインが入っていないためにテーブル自体が存在せず、リンクが自動的に消えていました。
改善案は、改善の画面では生まれない
改善活動の仕組みを導入するとき、いちばん最初につまずくのは「案が集まらない」ことです。理由ははっきりしています。
改善の種になる気づきは、改善の画面を開いているときには生まれません。生まれるのは業務のさなかです。
インシデントを3件続けて同じ原因で対応したとき
変更のたびに同じ手順書を書き写しているとき
サーベイの結果を見て「この項目だけずっと低い」と気づいたとき
このとき担当者に「改善管理アプリを開いて、新規で1件登録してください」と頼んでも、実際には登録されません。別の画面へ移動する手間が、気づきの寿命より長いからです。
だから改善の仕組みに本来ほしいのは、専用の入力画面ではありません。いま開いている画面から1クリックで起票できることです。そのうえで、起票元がどのレコードだったかを残しておければ、あとから「このインシデントが起点だった」とたどれます。
CIMがこれをどう実装しているかを見ていきます。
ServiceNow自身の説明：「日常使うアプリで機会を作り、CIMのレコードに変換する」
Application Manager でCIMプラグインの詳細を開くと、製品側が挙げているKey Featuresの4つ目にこう書かれています。
Improvement readiness … Create opportunities in the apps you use daily, and automatically convert into records within CIM.
「日常使っているアプリで改善の機会を作り、自動でCIM側のレコードに変換する」。改善専用の画面を新しく覚えさせる作りは選ばず、既存の業務画面から拾うと製品自身が宣言しています。
この宣言が実装のどこに現れているかというと、CIMIntegrationAPI というScript Includeでした。
このScript Includeが持つ関数は2つだけです。getInboundIntegrationTables() が入口のテーブル一覧を返し、getOutboundIntegrationTables() が出口のテーブル一覧を返します。連携先の定義が、たった1か所のスクリプトに集約されている構造です。
入口：どのテーブルから改善案を起票できるか
getInboundIntegrationTables() が返す既定の配列は10テーブルでした。それぞれがどのモジュールのものかを整理します。
並べてみると、ITSMの主要プロセスだけに閉じていません。
アセスメント … サーベイの点数が低い項目
Benchmarks … 他社比較で見劣りする指標
CMDBの重複調整 … データ品質の問題
Process Mining … プロセスの滞留
「数字が悪いと分かる場所」を横断的に押さえにいった一覧だと読めます。会社（core_company）が入っているのは意外でした。取引先ごとに改善を回す使い方を想定しているのでしょう。
存在しないテーブルは自動的に外れる
10テーブルのうち、Australia PDIで実際に存在したのは8つでした。
dmn_demand（Demand Management）と sn_grc_issue（GRC）は、対応するプラグインが入っていないためテーブル自体がありません。
ここでCIM側は行儀のよい作りをしていました。一覧を返す直前に getValidTables() という関数を通し、gs.tableExists() で1つずつ存在を確かめて、無いテーブルを配列から落としています。未導入のモジュール向けのリンクは、エラーにならず静かに消えるわけです。
プラグイン導入で何が増えるかはプラグイン（v_plugin/sys_plugins）の有効・無効と依存でも扱いました。CIMの連携先も同じ性質を持ちます。あとから別のプラグインを入れた時点で、連携先は自動的に増えます。 設定変更は要りません。
Incidentから改善案を1件起こす
実際にインシデントから起票してみます。使うのはデモデータの INC0000002（Network file shares access issue）です。フォームを下までたどると、Related Links に Create Improvement Initiative が並んでいました。
注目したいのは、これがフォーム上部のボタンではなくRelated Linkとして置かれていることです。UIアクションの定義でも form_link が true、form_button は false でした。
UIアクションの実体は3件しかありません。うち1件が task テーブルに定義されていて、Taskを継承するテーブルすべてに一度に効いています。Incident、Problem、Change、カタログタスクが同じ1レコードでまかなわれている形です。継承の効き方についてはtaskテーブル：ITSM全プロセスの共通の親で整理しています。
残る2件は sn_coaching_opportunity と asmt_metric_type に個別に定義されています。この2つはTask系ではないので、まとめて効かせられません。Incidentのどこまでが task 由来かはServiceNowのIncidentは何を持っている？で切り分けています。
起票すると、両側に記録が残る
リンクから起票すると、改善イニシアチブ CIM0001003 ができました。
Source Table に incident、Source に Incident: INC0000002 が入っています。短い説明も起票元からそのまま引き継がれていました。
そして起票元のインシデント側にも記録が残ります。
ワークノートに Improvement initiative CIM0001003 created. が自動で追記されていました。改善側から起票元をたどれるだけでなく、起票元から改善側もたどれます。 インシデント1件が周辺の何テーブルに書き込むかはServiceNowのインシデント1件は何テーブルに書かれる？で数えましたが、CIMを入れるとここにもう1本増えることになります。
起票元は2か所に記録される
起票元の記録方法を細かく見ると、CIMは2つの方式を併用していました。
1つ目は source_table（table_name型）と source_id（document_id型）の組み合わせです。参照先のテーブルを固定しない型なので、どのテーブルからでも起票元を記録できます。会社レコードのようにTask系でないものからでも困りません。
2つ目は parent フィールドです。CIM0001003 の parent には INC0000002 が入っていました。改善イニシアチブは Planned task を継承しているので、parent はタスク参照です。Task系から起票したときだけ、親子関係としても成立します。
なぜ二重に持つのかというと、役割が違うからです。parent はタスクの親子として画面や集計に効きますが、Task系にしか使えません。source_table と source_id はどのテーブルでも使える代わりに、参照としては弱い。両方持たせることで、汎用性と使い勝手を同時に取っています。
さらに sn_cim_inbound_m2m という中間テーブルも用意されていました。
こちらは0件です。フィールド構成は改善イニシアチブへの参照と source_table / source_id の組で、1件の改善に複数の起票元をひもづけるための器だと読めます。「このインシデント5件が同じ改善につながっている」という持ち方ができる設計ですが、標準の起票フローでは使われていませんでした。
デモデータの改善案が、想定している起票元を教えてくれる
連携先の一覧を見ても、実際にどう使われるのかは想像しにくいところがあります。そこでCIMプラグインが同梱している改善イニシアチブのデモデータを開くと、短い説明の頭に出どころが書かれていました。
Event Management: The number of alerts from A…
Survey Results: Customers are unhappy about th…
Knowledge Improvement: Knowledge data does …
Incident: Reduce the Incident backlog by 25% before Q2
Release Management: A n…
Training Issue: Service Desk staff would benefit…
ServiceNow自身が用意したサンプルが、改善案は業務プロセスの側から上がってくるという前提で書かれています。アラートが多すぎる、サーベイの点が低い、ナレッジが足りない、バックログが減らない。どれも改善の専門部署が思いつくものではなく、現場で数字を見ている人が気づくことです。
この並びを見ると、入口に10テーブルを用意した理由がはっきりします。改善の種は1か所からは来ません。
出口：改善から次の作業を作る
CIMは受け取るだけではありません。改善を実行する段になると、実際の作業を他モジュールのレコードとして作れます。
CIM Task を1件開くと、Related Links に3つのリンクが出ました。
Create Change … 設定変更を伴う改善を変更管理に載せる
Create Knowledge … 手順の周知で解決する改善をナレッジ記事にする
Create Coaching Opportunity … 担当者の習熟が原因の改善をコーチングに回す
改善の中身によって、次に使うべき仕組みが変わるという整理です。変更管理に載せるべきかどうかの判断はServiceNow 変更管理（Change）完全ガイドにまとめました。ナレッジ記事にする場合の公開経路はServiceNow ナレッジ管理（Knowledge）完全ガイドが参考になります。
宣言は6つ、出たのは3つ
getOutboundIntegrationTables() が返す既定の配列は6テーブルです。
画面に出た3つと、出なかった3つがきれいに分かれました。rm_story（アジャイル開発）、pm_project（プロジェクト管理）、dmn_demand（Demand Management）は、いずれもテーブルが存在しません。
入口と同じ getValidTables() の仕組みが効いています。UIアクションのレコード自体は3件しか登録されていませんでした。
残る3つのリンクは、対応するプラグイン側に同梱されている作りだと考えられます。CIMを入れただけでは配置されません。
作った先は中間テーブルに記録される
出口側には sn_cim_outbound_m2m があります。フィールド構成は入口側とほぼ対称でした。
入口が source_table / source_id なのに対し、出口は target_table / target_id です。加えて cim_task への参照も持っていて、どのタスクから作ったのかまで記録できます。改善1件に対して、そこから生まれた変更・ナレッジ・コーチングを一覧できる構造です。
リンクが出る条件は、ロールとテーブル存在の2段構え
「リンクが表示されない」と言われたときにどこを見るかを整理しておきます。
入口のTask系リンクは CIMUtil.showImprovementUIAction() が判定していて、条件は2つです。
操作している人が sn_cim.improvement_requester ロールを持っていること
開いている画面のテーブルが、入口一覧に含まれていること
アセスメントからの起票だけは条件が違い、assessment_admin ロールに加えて「公開済みかつ有効なサーベイまたはアセスメントであること」が要ります。同じ名前のリンクでも、テーブルごとに条件が違うわけです。
出口側は CIMUtil.canEditCIMTaskState() が効いていて、CIM Task の状態が Open か Work in progress のときだけリンクが出ます。閉じたタスクからは新しい作業を生やせません。実際、Closed Complete のタスクを開いたときには Related Links そのものが表示されませんでした。
連携先を増やす：プロパティは自分で作る
既定の10テーブルと6テーブルでは足りない場合、CIMIntegrationAPI はプロパティで一覧を継ぎ足せるように書かれていました。既定の配列に対して、プロパティの値をカンマ区切りで読み込み、重複を除いて結合します。
ただし注意点があります。Australia PDI の sys_properties に登録されている sn_cim のプロパティは4件だけで、このうち連携先を広げる3件は含まれていません。
スクリプト側は gs.getProperty() で読みにいきますが、レコードが無いので既定の配列だけが使われます。連携先を足したい場合は、このプロパティを自分で新規作成することになります。設定画面のどこかにあるチェックボックスを探しても見つかりません。
なお実在する4件のうち sn_cim.initiative_copy_attributes は、Copy Initiative で複製するときに引き継ぐ項目の一覧でした。既定値には12項目が並んでいます。
測定側との連携もリンクで用意されている
改善イニシアチブ側のRelated Linksを見ると、ここにも3本ありました。
Create PA Indicator … 効果を測るためのPA指標をその場で作る
Show Benchmarks … 業界比較のベンチマークを開く
Go to Process Mining … プロセスマイニングの画面へ移動する
いずれもレコードを作る連携ではありません。測定と分析の画面へ移動する導線です。改善イニシアチブは success_measurement_method というフィールドで効果測定の方法を選ぶ作りになっていて、Automated: PA Indicator を選ぶとPA指標との紐づけが必要になります。指標そのものの設計はServiceNowのPerformance Analyticsは何を測る？で扱いました。
Create PA Indicator の表示条件には pa_power_user または pa_data_collector ロールが指定されていました。測定の設計はCIMのロールではなく、分析側のロールを持つ人の仕事だと製品が線を引いています。
実機で気づいたこと
宣言と実装のズレが、意図的に設計されていました。 入口10・出口6という配列は「CIMが将来つながりうる先」の宣言で、実際に動くかどうかは gs.tableExists() が実行時に判断します。この作りのおかげで、あとからDemand Managementを入れれば、CIM側は何も触らなくても連携先が増えます。逆に言えば、リンクが出ないときの原因の第一候補は権限ではなくプラグイン未導入です。ここを最初に疑えると調査が早くなります。
入口が「ボタン」ではなく「Related Link」だったのは、想定している使い方の表れだと思います。 フォーム上部のボタンは、そのレコードを進めるための操作が並ぶ場所です。改善案の起票はインシデントを進める操作ではないので、下の関連リンクに置いた。最初は目立たない配置だと感じましたが、Resolve の隣に Create Improvement Initiative が並んでいたら誤操作を招きます。妥当な判断だと考えを改めました。
起票元を parent と source_table/source_id で二重に持つのは、Task継承の限界を回避するためでした。 ServiceNowのITSMはTaskを共通の親に据えた設計ですが、CIMは会社（core_company）のようなTask系でないテーブルからの起票も想定しています。そこで参照型ではなく table_name と document_id の組を用意した。Task継承を前提にできない機能は、この2つの型を使うという設計パターンとして覚えておくと応用が効きます。
中間テーブルが2つとも0件なのは、まだ使われていない拡張余地だと読めます。 sn_cim_inbound_m2m と sn_cim_outbound_m2m は、1対多の関係を持たせるための器です。標準の起票フローは1対1で足りるので使われていませんが、「同じ改善に複数のインシデントをひもづける」運用をしたいなら、この器がすでにあることを知っておくと自作せずに済みます。
実務では、どこから起票を開放するか
入口が8つ動くからといって、8つ全部を開放する必要はありません。開放するテーブルを決めることが、そのまま改善案の質を決めます。
現実的な進め方としては、まずIncidentとProblemの2つに絞るのがよいと考えています。理由は3つあります。
件数が多く、同じ原因の繰り返しに気づきやすい
対応者が改善の必要性を体感している
起票元をたどったときに、根拠となる履歴が残っている
IncidentとProblemの役割分担そのものはServiceNow 問題管理（Problem）完全ガイドで整理しました。Problemで扱うのは起きた障害の根本原因、CIMで扱うのはまだ障害になっていない改善余地という線引きを、起票する人に先に伝えておくと迷いが減ります。
そのうえでロール設計を決めます。入口のリンクは sn_cim.improvement_requester ロールで制御されるので、このロールを誰に配るかが「誰が改善案を出せるか」の設計そのものです。全社員に配れば入口は広がりますが、受理する事務局の負荷が上がります。まずはサービスデスクとプロセスオーナーに限定し、運用が回ってから広げる順序が無理がありません。
入口を絞ったあとに決めておきたいのが、起票元が閉じたあとの扱いです。インシデントは解決すれば閉じますが、そこから生まれた改善イニシアチブは残ります。source_id の参照先が Closed になっても改善側は動き続けるので、改善の進捗を追う人は起票元を見に行かない運用にしておくほうが安全です。起票元は「なぜこの改善が必要だったか」を後から説明するための証跡として使います。
もう1つ、同じ内容の改善が複数のインシデントから重複して起票されることも起きます。CIMには重複を自動でまとめる仕組みが標準では入っていません。事務局が受理する段階で気づいて統合する運用になります。sn_cim_inbound_m2m を使えば「この改善は5件のインシデントが起点だった」と持てますが、標準の画面からは登録されないので、使うなら関連リストの追加が必要です。
出口を判断するのは、CIM Task を開いている実行担当者です。タスクのフォームには Improvement Initiative への参照と Parent が並び、どの改善のどの作業なのかが1画面で分かります。さらに画面の下には、3つの関連リストが最初から用意されていました。
出口として作れる3テーブルが、そのまま関連リストになっています。作ったあとに「どこへ出したか」を見返す場所も、同じ画面に用意されているわけです。
出口については、逆に最初から3つとも開けておいてよいと考えます。改善を実行する段階で「これは変更管理に載せるべきだった」と気づいても、リンクが無ければ手作業で起票することになります。使わない選択肢が3つ並んでいる害より、必要なときに無い害のほうが大きいためです。
用語
この記事に出てくる言葉を整理しておきます。
改善イニシアチブ（Improvement Initiative） … 改善案1件を表すレコード。テーブルは sn_cim_register
CIM Task … 改善を実行するための作業レコード。テーブルは sn_cim_task
入口（Inbound） … 他モジュールの画面から改善イニシアチブを起票する経路
出口（Outbound） … 改善イニシアチブやCIM Taskから、他モジュールのレコードを作る経路
Related Link … フォーム下部に並ぶリンク形式のUIアクション。上部のボタンとは配置も用途も分かれている
document_id型 … 参照先のテーブルを固定しない型。table_name 型のフィールドと組で使う
拡張ポイント（Extension Point） … スクリプトの一部を差し替え可能にする仕組み。CIMでは連携先の一覧が該当する
自分の環境で確認するときのURL
インスタンスのURLに続けて開いてください。
連携先の定義（入口・出口の一覧）：/sys_script_include.do?sysparm_query=name=CIMIntegrationAPI
入口のUIアクション：/sys_ui_action_list.do?sysparm_query=nameLIKECreate Improvement Initiative
出口のUIアクション：/sys_ui_action_list.do?sysparm_query=table=sn_cim_task^nameSTARTSWITHCreate
CIMのプロパティ：/sys_properties_list.do?sysparm_query=nameSTARTSWITHsn_cim^ORDERBYname
入口の中間テーブル：/sn_cim_inbound_m2m_list.do
出口の中間テーブルの辞書定義：/sys_dictionary_list.do?sysparm_query=name=sn_cim_outbound_m2m^elementISNOTEMPTY^ORDERBYelement
起票元が入った改善イニシアチブ：/sn_cim_register_list.do?sysparm_query=source_tableISNOTEMPTY
アプリメニューからは Continual Improvement > All で改善イニシアチブの一覧に、Continual Improvement > CIM Tasks でCIM Taskの一覧に移動できます。連携の定義そのものはメニューに無いので、上のURLで開いてください。
引用した公式説明を自分で開く
この記事で引用したKey Featuresの文面は、ServiceNowが製品に同梱しているプラグインの説明です。次のURLを自分のインスタンスで開くと、同じ記述を確認できます。
プラグインの公式説明（引用元）：/v_plugin_list.do?sysparm_query=id=com.sn_cim
Application Manager の詳細ページ：/now/app-manager/home
検証範囲とおことわり
Australia PDI（Zurichではなく Australia ファミリー）に com.sn_cim v11.1.0 を導入した直後の状態で確認しました。OOTBのままで、設定は変更していません。記事中の件数と挙動は 2026-08-14 時点のこの環境のものです。
確認していない範囲は次のとおりです。
sn_cim.show_cim_ui_action などのプロパティを作成して連携先を増やした場合の挙動
Demand Management や GRC を追加導入したあとに、リンクが自動で現れるかどうか
sn_cim_inbound_m2m / sn_cim_outbound_m2m にレコードが入る操作経路
Show Benchmarks と Go to Process Mining のリンク先の画面
本番環境での権限設計（PDIは管理者権限で操作しているため、ロールごとの見え方は条件式から読み取ったもの）
検証のために CIM0001002 CIM0001003 CIMT0001004 を作成しています。デモデータではありません。
関連記事
前提知識：taskテーブル：ITSM全プロセスの共通の親 … 入口のUIアクションが1レコードで全テーブルに効く理由がここにあります
次に読む：ServiceNow 問題管理（Problem）完全ガイド：IncidentとProblemの違い … Problemで扱うものとCIMで扱うものの線引きを整理しています
実務編：ServiceNowのインシデント1件は何テーブルに書かれる？ 周辺13テーブルを実機で数える … 起票元に記録が残る仕組みの前提になる話です
この記事のその後：本文で「PPM側のプラグインを入れればテーブルができ、リンクが自動で増えるはず」と書いた予想は、その後 PPM Standard を実際に入れて確かめました。結果はServiceNowのPPMはIncidentやCIM（継続的改善管理）などの他モジュールとどうつながる？にまとめています。Create Demand と Create Project のリンクが、CIM側を触らずに現れます。
