CMDB運用手順書

確認した環境：ServiceNow の PDI（Personal Developer Instance）、Zurich リリースの OOTB（初期設定）。2026-07-08 確認。

1. 目的・背景

この記事は、ServiceNow の CMDB に Linux サーバの CI を1件実機で新規登録し、登録 → 関係付け → 状態変更 → 退役の4ステップを順に実走して確認した運用手順書です。cmdb_ci_linux_server クラスの CI を IRE（identifyreconcile API）経由で登録しました。そのうえで既存のデータベース CI と関係を結び、稼働状態を変え、最後に退役させています。

CMDB の登録で迷いやすいのは、同じサーバをうっかり2回登録してしまわないかという点です。今回の実走でいちばん確かめたかったのは、同じ内容のペイロードを2回投げても、2件目の CI は作られないという動きでした。1回目は新規作成（INSERT）される一方、2回目は「変更なし」（NO_CHANGE）という結果が返り、sys_id も1回目とまったく同じでした。この重複防止の仕組みはステップ1で実測とあわせて扱います。

今回実走した CI のフォームが次の画面です。名前・シリアル番号・OS・IP アドレスを登録し、その後の操作で Install status・Operational status を変えた状態が残っています。

想定読者は、ServiceNow で CMDB への CI 登録・関係付け・状態管理を担当する人、CMDB 運用の手順書を整える立場の人です。cmdb_ci のテーブル構造そのものは「ServiceNow CMDB の中心テーブル cmdb_ci を実機で読み解く：クラス階層・状態・CI関連の見方」で、CI 同士の関係の構造は「ServiceNow の CI 関連（cmdb_rel_ci）を実機で読み解く：parent→type→child と cmdb_rel_type の双方向呼称・依存マップ」で扱っています。

2. 前提整理・全体フロー

CI のクラス階層と関係

cmdb_ci はハードウェア・ソフトウェア・ネットワーク機器など多数のクラスの親テーブルで、実際の CI はその子クラスに登録されます。今回登録した app-server-op015 は cmdb_ci_linux_server クラスです。Linux Server はさらに親をたどると、Server・Computer・Hardware・cmdb_ci という継承チェーンを持ちます。この継承チェーンの詳細は「ServiceNow のサーバ CI クラス cmdb_ci_server を実機で読み解く：cmdb_ci からの継承チェーンと OS・CPU・RAM などサーバ固有フィールドの出どころ」の記事にまとめました。

今回確認した PDI の CI 一覧をクラスでグループ化すると、次のとおりでした。件数はクラス別の直属件数で、サブクラスを含む合計とは別の数字です。

cmdb_ci の辞書（フィールド定義）は多数のクラスが継承する土台なので、公式ドキュメントでも不用意な変更を避けるよう案内されています。CMDB のテーブル構造全般は公式の CMDB tables descriptions（Zurich） にまとまっています。

CI 同士は cmdb_rel_ci というテーブルで関係を持ちます。parent・child・type（cmdb_rel_type）の3項目で1件の関係が決まります。type には「Depends on::Used by」のような双方向の呼び方がセットで定義されています。関係の考え方は公式の CI relationships（Zurich） のとおりです。

CI ライフサイクルの4ステップ

今回の実走は、登録・関係付け・状態変更・退役の4ステップです。各ステップで何を操作し、何を観測したかをまとめたのが次の図です。

登録は IRE（identifyreconcile API）経由で行いました。Table API で cmdb_ci に直接 insert する経路もありますが、同定ルールを通らないため重複防止の仕組みが働きません。今回はこの IRE 経由の登録を、実際に同じペイロードを2回投げて確かめました。

ひとつ注意点があります。今回の実走は、フォームと同じフィールドを REST API（IRE API・Table API）で直接更新して確認しました。画面から同じ項目を入力して操作する手順に読み替えて書いていますが、フォーム上のボタンや CI Class Manager 固有の動作は検証範囲外です。

この記事（無料部）で分かること

• cmdb_ci のクラス階層と、CI 同士の関係（cmdb_rel_ci）の基本構造

• CI を IRE 経由で新規登録すると、同定ルールによって重複が防がれることを確認する手順

• 同定ルールがどのテーブル・どの属性を優先順位付きで照合しているか

3. 操作手順

ここからは操作を番号付きで並べます。各ステップは、実施者／画面への行き方／入力項目と値／押すボタン（または API）／成功条件／注意点の順です。値は今回実際に PDI へ登録したものでそろえました。

1) CI の新規登録と重複防止の確認

• 実施者：CMDB 管理者、または Discovery/連携ツールの導入担当（手動登録の代わりに IRE API を使う場面を想定）

• 画面への行き方：登録は API（POST /api/now/identifyreconcile）で実施。登録結果はアプリケーションナビゲーターで Configuration > Servers > All（cmdb_ci_linux_server が属する一覧）から確認する

• 入力項目と値：

• className=cmdb_ci_linux_server

• name（サーバ名）

• serial_number（機体のシリアル番号。同定キーとして使われる項目）

• os=Linux Red Hat

• ip_address

• クエリパラメータ sysparm_data_source（discovery_source の有効な選択肢値。今回は「Manual via IRE」）

• 押すボタン（または API）：POST /api/now/identifyreconcile（items 配列に1件のペイロードを入れて送信）

• 成功条件：レスポンスの operation が INSERT になり、sysId が発行されること

• 注意点：sysparm_data_source を付けずに呼ぶと INVALID_INPUT_DATA エラーになり登録できない（discovery_source の有効な選択肢値の指定が必須）。エラーメッセージには「discovery_source に有効な選択肢を指定せよ」という趣旨の文言が返る

登録の応答には、同定の試行ログ（identificationAttempts）が含まれていました。1回目の登録では次の順番で照合が行われ、どのエントリにも一致しなかったため新規作成になっています。

照合先はいずれも identifierName=Hardware Rule という1つの同定ルールでした。cmdb_ci_linux_server や親クラスの cmdb_ci_computer / cmdb_ci_server 自体には、専用の同定ルールが定義されていません。ハードウェア系クラス共通の親クラス（cmdb_ci_hardware）の同定ルールが使われる、という構造です。同定ルールの中身は次の画面で確認できます。

ルールの中身は、優先順位（order）付きの同定エントリ（cmdb_identifier_entry）の集合です。serial_number のエントリは order=200 で、今回の同定で実際にマッチしたのがこのエントリでした。

同じペイロードをもう一度送信すると、レスポンスの operation は NO_CHANGE になり、sysId は1回目とまったく同じ値が返りました。同定の試行ログでも、今度は serial_number のエントリで MATCHED という結果になっていました。新しい CI は作られず、既存の1件がそのまま返るという動きです。この重複防止の仕組みは、シリアル番号のような同定キーをそろえて投入することで初めて機能します。登録時は必ず同定キー（今回であればシリアル番号）を空にせず、表記も統一して投入することが手順として重要になります。同定・調整の仕組み全体は「ServiceNow CMDB の同定・調整（IRE）を実機で読み解く：cmdb_identifier と identifier entry で重複CIを防ぐ仕組み」で扱いました。

無料部はここまでです。有料部では、同じ CI を関係付けから退役まで進め、次を実測つきの手順として確認します。

• 既存のデータベース CI との関係付けと、connection_strength が自動でセットされる動き

• operational_status と install_status という2つの状態軸の変更と、互いに連動しないという実測

• CI を退役させても、operational_status も日付も関係も何ひとつ自動では変わらないという実測

• 日常運用での CMDB の見方と、よくあるミスとリカバリ表