CIの停止を1件で残す（cmdb_ci_outage）

サーバやサービスが止まったとき、ServiceNow はその「停止そのもの」を1件のレコードとして残します。インシデント（誰がいつ困ったか）とは別に、CI が「いつから・いつまで・どの種類で止まったか」を記録するのが Outage、テーブル名で言うと cmdb_ci_outage です。

この記事は、Incident は触ったことがあるが、停止記録（Outage）がどんなテーブルで、どのフィールドを持ち、incident や change とどうつながるかを確認したい管理者・開発者を想定しています。PDI（Zurich / OOTB）で cmdb_ci_outage を実際に開き、テーブルの位置づけ、type（種別）の3値、begin / end / duration、停止対象 CI への参照、task との連携テーブルを順に確認します。

この記事で分かること

• cmdb_ci_outage が「CI の停止1件＝1レコード」を表すテーブルであること

• 名前は cmdb_ci_* だが、cmdb_ci のサブクラスではなく独立したルート基底テーブルであること

• type が Outage / Planned Outage / Degradation の3種で、PDI 実機での件数分布

• begin / end / duration と停止対象 cmdb_ci の関係

• incident / change / problem が task_outage を介して outage とつながる構造

• 実機で確認するときに見るべき一覧URL

Outage（CI の停止記録）とは

Outage とは、ある CI（サーバ・アプリ・サービスなど）が止まった、あるいは性能が落ちた事実を、開始時刻・終了時刻つきで残す記録です。ServiceNow ではこれを cmdb_ci_outage テーブルに1停止＝1レコードで保存します。

インシデントが「利用者から見た困りごと」だとすると、Outage は「CI から見た停止の事実」です。同じ停止でも、インシデントは1件とは限らず（複数の利用者が別々に起票する）、Outage は CI の停止区間として1本にまとめられます。この分け方があるおかげで、後からサービスの可用性（どれだけの時間動いていたか）を CI 単位で集計できます。

PDI（Zurich / OOTB）の cmdb_ci_outage には、すでに 438件の停止記録が入っていました。1件を開くと、番号・対象 CI・種別・開始終了・停止時間がそろっています。

このフォームの OUT0001064 は、SAP Financial Accounting という CI が約2時間止まった記録です。Begin と End が入り、Duration（停止時間）はその差から表示されます。フォーム下部には Affected CIs（影響を受けた CI）の関連リストもあり、主たる CI 以外に巻き込まれた CI を足せるようになっています。

cmdb_ci_outage はどこに位置するテーブルか

名前が cmdb_ci_outage なので CMDB の CI クラス（cmdb_ci のサブクラス）に見えますが、実機で継承元を確認すると違いました。

今回確認した PDI（Zurich / OOTB）では、cmdb_ci_outage の super_class（継承元）は空でした。つまり cmdb_ci の子クラスではなく、独立したルート基底テーブルです。前回の cmdb_ci の記事で見た「cmdb_ci の下に102の子クラスがぶら下がる」階層には、このテーブルは入っていません。

では cmdb_ci との関係は何かというと、継承ではなく参照です。cmdb_ci_outage は cmdb_ci フィールド（Reference → cmdb_ci）を持ち、「どの CI が止まったか」をそこで指します。名前の cmdb_ci_ は「CI に関するテーブル」という命名の名残で、クラス階層上の親子を表すものではありません。階層は次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sys_db_object_list.do?sysparm_query=name=cmdb_ci_outage

cmdb_ci_outage の固有フィールドは18件でした。super_class が空なので、この18件はすべてこのテーブル自身が持つ列です（基底から受け継ぐ共通列はありません）。

type（種別）は3つ：Outage / Planned Outage / Degradation

Outage の性格を分けるのが type です。PDI（Zurich / OOTB）の選択肢は3つでした。

• Outage … CI が止まった停止。計画外の停止がここに入ります。

• Planned Outage … 変更作業など、あらかじめ計画された停止。

• Degradation … 止まってはいないが性能が落ちた状態。

この3区分が効くのは、可用性を測るときに「計画した停止」と「計画外の停止」を分けたいからです。一般に、計画停止は事前告知のうえで実施するため可用性の評価から除く運用が多く、計画外の停止だけを「落ちた時間」として数えます。ServiceNow 公式でも、計画外の停止がサービスの可用性スコアを下げる扱いとして説明されています（Outage management（Zurich））。なお、可用性スコアの集計ロジックそのものは今回の検証範囲外です。

実機の件数は、停止記録一覧を type でグループ化すると一目で分かります。

https://<YourInstance>/cmdb_ci_outage_list.do?sysparm_query=GROUPBYtype

PDI では Outage（計画外）が301件と最も多く、Degradation 72件、Planned Outage 65件でした。OOTB のデモデータなので件数自体に意味はありませんが、3区分が実際に使い分けられていることは確認できます。

停止を表すフィールド（begin / end / duration と cmdb_ci）

Outage レコードの中身は、役割で分けると「識別」「時間」「対象」「関連」「説明」に整理できます。

主なフィールドは次のとおりです。ラベルは実機の表示名どおり英語で記載します。

時間まわりの読み方が要点です。begin（開始）と end（終了）はどちらも日時で、duration（停止時間）は begin と end の差から表示されます。先ほどの OUT0001064 では、Begin 2025-11-15 08:44:31、End 2025-11-15 10:43:57 に対し、Duration が約1時間59分でした。PDI の438件は begin も end も全件で埋まっており（空はいずれも0件）、終了まで確定した停止記録になっています。

対象 CI は cmdb_ci フィールド（Reference → cmdb_ci）が指します。438件すべてで cmdb_ci が設定されていました。フォームの Configuration Item に CI 名（OUT0001064 なら SAP Financial Accounting）が入り、ここが「どの CI が止まったか」の起点になります。

number は OUT で始まる連番（OUT0001016 など）で、停止記録ごとに自動採番されます。short_description / details / message は停止内容の説明欄です。

incident / change との連携（task_outage を介す）

Outage は単独でも作れますが、実務では「どのインシデントや変更で起きた停止か」をひもづけたくなります。ここで構造を1つ理解しておく必要があります。cmdb_ci_outage は incident や change への直接の参照フィールドを持っていません。連携は task_outage という専用のリンクテーブルを介します。

task_outage（label: Outages Tasks Link）は、task と outage を多対多でつなぐ中間テーブルです。主フィールドは outage（→ cmdb_ci_outage）と task（→ task）の2つだけで、1行＝「ある停止と、あるタスクの結びつき1件」を表します。

なぜ task 参照かというと、incident・change_request・problem はいずれも task を継承する「タスク系」だからです。task をつなぎ先にしておけば、インシデントでも変更でも問題でも、同じ仕組みで停止に結びつけられます。実際、change_request 自体には outage フィールドがありません（PDI で sys_dictionary を確認すると0件）。変更画面から停止記録を足すときも、この task_outage 経由のリンクになります。ServiceNow 公式では、この多対多リンクと「Create Outage」ボタンを導入するのが Task-Outage Relationship プラグイン（com.snc.task_outage）だと説明されています（Create an outage from a task（Zurich））。

注意したいのは、今回の PDI（Zurich / OOTB）では task_outage のレコードが0件だったことです。デモデータの outage は cmdb_ci（停止した CI）までは設定済みですが、task との明示リンクは張られていませんでした。そのため、リンク経由の実挙動（インシデント解決時に outage が自動更新される等）は確認できていません。この点は検証範囲外として残します。

cmdb_ci_outage と task_outage は、次のURLで確認できます。

Outage 一覧     : https://<YourInstance>/cmdb_ci_outage_list.do
Task-Outage 一覧 : https://<YourInstance>/task_outage_list.do

cmdb_ci_outage に関わる周辺機能

停止記録の動きも、フィールド定義だけでは決まりません。保存時の処理や権限など、複数の設定が組み合わさります。

PDI（Zurich / OOTB・active 中心・2026-06-22 確認）では、Business Rules が11件、Notifications が3件あり、停止記録の保存時にサーバ側で動く処理や、停止に伴うメール通知が用意されていることが分かります。UI Actions は2件で、ここに停止記録の作成・操作ボタンが含まれます。

ここで数えているのは cmdb_ci_outage に直接紐づく設定だけです。task_outage 側にも別の設定があり、停止とタスクの連携はそれらが合わさって動きます。各設定の内部スクリプトの挙動は今回の検証範囲外です。

Business Rules : https://<YourInstance>/sys_script_list.do?sysparm_query=collection=cmdb_ci_outage^active=true
UI Actions     : https://<YourInstance>/sys_ui_action_list.do?sysparm_query=table=cmdb_ci_outage^active=true
Access Controls: https://<YourInstance>/sys_security_acl_list.do?sysparm_query=nameSTARTSWITHcmdb_ci_outage

ServiceNow における cmdb_ci_outage のポイント

• cmdb_ci_outage は「CI の停止1件＝1レコード」を残すテーブルです。名前は cmdb_ci_* ですが super_class が空のルート基底で、cmdb_ci のサブクラスではありません。cmdb_ci とは継承ではなく参照（cmdb_ci フィールド）でつながります。

• type は Outage（計画外）/ Planned Outage（計画停止）/ Degradation（性能低下）の3種です。計画停止と計画外を分けるのは、可用性の評価で「落ちた時間」をどう数えるかが変わるためです。PDI では Outage 301 / Degradation 72 / Planned Outage 65（合計438）でした。

• 停止区間は begin / end で表し、duration はその差から表示されます。PDI の438件は begin・end とも全件設定済みでした。対象 CI は cmdb_ci 参照で指します。

• incident / change / problem との連携は、直接参照ではなく task_outage（task ↔ outage の多対多リンク）を介します。task 系を継承しているので、どのタスクからでも同じ仕組みで停止に結びつけられます。

• ただし今回の PDI（OOTB）では task_outage が0件で、リンク経由の実挙動は確認できていません。

停止記録を読むときは、まず type で「計画／計画外／性能低下」を見分け、begin / end で停止区間を押さえ、cmdb_ci で対象 CI を確認し、タスクとの結びつきは cmdb_ci_outage 単体ではなく task_outage 側を見る、という順で追うと構造を取り違えずに済みます。

実機で気づいたこと

• cmdb_ci_outage には Notification が3件ひもづいていて、停止に伴うメール通知を飛ばす準備が整っていました。ところが肝心の task_outage（タスクとの紐づけ）は0件で、実際にどの通知がどんな条件で飛ぶのかまでは確認できませんでした。周辺設定の件数を数えただけでは、仕組みが用意されていることと、実際に使われていることは別だと痛感しました。

• 438件の Outage を見て回ると、begin と end がどちらも空のレコードは1件もありませんでした。つまり今回の OOTB データには「まだ終わっていない停止」が1件も含まれていません。停止時間（duration）を集計するスクリプトを書くなら、end が空のまま残るケースをどう扱うかは、このデモデータだけでは確認できないので自分で考える必要があります。

• task_outage が task（incident / change / problem 共通の基底）を経由して outage とつながる作りだと分かったとき、なぜ change_request に直接の参照フィールドを足さなかったのか少し疑問でした。実際に辞書を見ると change_request 自身に outage 関連のフィールドは無く、task 経由でしか結びつけられません。裏を返せば、incident でも problem でも同じ仕組みで停止に結びつけられるように、あえて対象を1つのテーブルに絞り込まなかったのだと理解しました。

次に読むなら

CMDB 全体の CI・関係・サービスの母数を先に押さえたい場合は、ServiceNowのCMDBは何がどこに入っている？ CI・関係・サービスを実機で数える が起点になります。次に確認するなら、停止記録がどうサービスの可用性（Availability）に集計されるか、つまり Service Offering 側で計画外の Outage を「落ちた時間」として積み上げる仕組みです。今回は cmdb_ci_outage のテーブル構造までを確認し、可用性スコアの計算と Service Portal / Workspace での表示は検証範囲外としました。あわせて、Task-Outage Relationship プラグインが入る環境での「Create Outage」操作と、task_outage に実レコードが入ったときの挙動も別記事で確認する予定です。

用語

• PDI：Personal Developer Instance（無料の検証用インスタンス）

• OOTB：Out of the Box（初期設定のまま）

• CI：Configuration Item（構成アイテム）

• Outage：CI の停止記録（cmdb_ci_outage）

• 可用性（Availability）：CI / サービスがどれだけの時間動いていたかの指標

• task_outage：task と outage を多対多でつなぐリンクテーブル

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

自分のインスタンス名を先頭に付けると、同じ画面が開けます。

テーブル定義     : sys_db_object_list.do?sysparm_query=name=cmdb_ci_outage
フィールド一覧   : sys_dictionary_list.do?sysparm_query=name=cmdb_ci_outage^elementISNOTEMPTY
type 選択肢      : sys_choice_list.do?sysparm_query=name=cmdb_ci_outage^element=type
停止記録一覧     : cmdb_ci_outage_list.do?sysparm_query=GROUPBYtype
Task-Outage 定義 : sys_dictionary_list.do?sysparm_query=name=task_outage^elementISNOTEMPTY

公式ドキュメント（Zurich）

• Outage management（task-outage / 概念） … Outage の考え方と、CI の停止が可用性にどう関わるかの説明。

• Create an outage from a task（タスクから停止記録を作る） … task_outage を介した stop 連携と Task-Outage Relationship プラグイン（com.snc.task_outage）の役割。

• CMDB tables descriptions … cmdb_ci をはじめ CMDB 関連テーブルとフィールドの一覧。

テーブルの基本

• Name：cmdb_ci_outage ／ Label：Outage ／ super_class：（空・ルート基底）

• 固有フィールド数：18（うち業務フィールドは begin / cmdb_ci / details / duration / end / message / number / short_description / task_number / type）

• レコード総数：438件

type の値（value = label・件数）

outage = Outage（301）／ planned = Planned Outage（65）／ degradation = Degradation（72）

主なフィールド（検索用）

number, type, cmdb_ci, begin, end, duration, short_description, details, message, task_number

周辺設定の件数（cmdb_ci_outage・OOTB・active 中心）

• Business Rules（sys_script・active）… 11

• Client Scripts（sys_script_client・active）… 1

• UI Policies（sys_ui_policy）… 0

• UI Actions（sys_ui_action・active）… 2

• Notifications（sysevent_email_action）… 3

• Access Controls（sys_security_acl）… テーブル 17 ＋ フィールド 2

• Dictionary Entries（sys_dictionary）… 18

• Choices（sys_choice）… 3（type のみ）

関連テーブル（検索用）

cmdb_ci_outage（Outage）, task_outage（Outages Tasks Link）, cmdb_ci（Configuration Item）, task（基底）, incident / change_request / problem（task 系）

検証範囲とおことわり

• 確認した範囲：cmdb_ci_outage の位置づけ（super_class 空のルート基底）、固有フィールド数18、type の選択肢3種と件数分布（Outage 301 / Degradation 72 / Planned Outage 65・合計438）、begin / end / duration と cmdb_ci 参照、task_outage の構造、周辺設定件数。すべて PDI（Zurich / 2026-06-22 確認）の OOTB で取得しています。

• 確認していない範囲（断定しません）：task_outage 経由の実リンク挙動（OOTB サンプルが0件のため）、計画外 Outage を可用性スコアに集計するロジック、Service Offering / Service Portal / Workspace での可用性表示、自動 Outage 生成（P1 自動作成など）のフロー、各 Business Rule / Notification の内部挙動。これらは別記事で確認します。