ServiceNow CSAのCMDB Health対策｜4KPIと改善設定の判断ガイド

ServiceNow CSAの学習でCMDB Healthにたどり着くと、「Completeness・Correctness・Compliance・Relationshipsという4つのKPIがある」ところまでは分かっても、結局それをどう理解し、試験でどう判断すればいいのかが掴みにくい——そう感じている方は多いはずです。

この記事は、CSAで問われるCMDB Healthを、①そもそも何を測る仕組みか → ②これがないと現場で何が起きるか → ③問題文のキーワードからどう判断するか（早見表）の順で理解するための記事です。用語の暗記ではなく、模試で迷わない判断軸を持ち帰ることをゴールにします。

▶ この分野の模擬試験を無料・登録不要で解く
CMDB・データ移行など分野別に分けた、AI生成のCSA模試です

そもそもCMDB Healthとは

CMDB Healthは、CMDBに登録された構成情報（CI）が「信頼して使える状態か」をスコアとダッシュボードで可視化する仕組みです。健全性は次の4つのKPIで見ます。

• Completeness（充足）：必要な項目が埋まっているか
• Correctness（正しさ）：重複・古い・孤立したCIがないか
• Compliance（準拠）：決めたルールやポリシーに従っているか
• Relationships（関係）：CI同士のつながりが健全か

ここまでは検索の要約でも答えられる「定義」です。CSAで本当に効くのは、この4つが欠けたとき現場で何が起きるかを知ること。次でそれを見てみましょう。

これがないとどうなる ——「影響なし」と判断して基幹サービスを止めた話

金曜の深夜、あるストレージ機器のファーム更新で一時停止することになりました。担当者はServiceNowのCMDBで該当のCIを開き、関係（Relationships）タブを確認します。何も紐づいていません。「影響なし」と判断して停止——直後、基幹業務サービスが落ち、翌朝まで問い合わせが殺到しました。

原因は単純です。そのストレージは基幹サービスのデータベースが使っていましたが、その依存関係がCMDBに登録されていなかった。CIの属性はきれいに埋まっていて、CMDB Healthのスコアも悪くなかった。それでも事故は起きました。

これがCMDB Healthが整っていないと起きることの典型です。データが欠けている・古い・関係がない状態のCMDBは、「影響なし」と“嘘”をつき、人の判断を誤らせます。逆に言えば、CMDB Healthはこうした「データを信じて判断したのに外れる」を防ぐための仕組みなのです。

だからCSAはCMDB Healthを問う ——鍵は「点数」でなく「判断」

こうした事故を防ぐ力があるかを確認するため、ServiceNow CSAの試験範囲にはCMDB Healthが含まれています。ただし問われるのはスコアの数字そのものではありません。CMDBの目的は、障害・変更・コストの判断に使える構成情報を保つこと。点数はその健全度を表す手段であって、目的ではありません。

冒頭の事故が示すとおり、スコアが高くても「関係が空」なら判断は外れます。だから模試でも「点数を上げる行動＝正解」ではなく、「点数が上がっても運用判断に使えなければ意味がない」と読めるかが問われます。

この先は、(1)迷ったとき立ち返る判断早見表、(2)4つのKPIを「事故 → 放置するとどうなる → どう設定して防ぐ → どう改善するか」で、の順に、模試で迷わない判断軸を作っていきます。

CMDB Health 判断早見表（迷ったらここに戻る）

CMDB Healthの問題は、問題文のキーワードと見るべきKPI・根本設定を結べれば解けます。次の早見表が、この記事全体の地図です。各行は後の章で事故付きで深掘りします。

ここからは、4つのKPIを「実際に起きがちな事故」から見ていきます。事故の形を知っていると、抽象的な選択肢でも「これは何のKPIの話か」が一発で分かります。

Completeness：誰のサーバーか分からず、初動が止まる

現場で起きる事故：あるサーバーがダウンし、インシデントが起票された。担当者がCMDBでCIを開くと、所有者（owned_by）もサポートグループ（support_group）も空欄。「これは誰に連絡すべきCIなのか」を人力で探すうちに30分以上が過ぎ、SLAを割り込んだ。

放置するとどうなる：必要な属性が空のままだと、障害のたびに「誰の・何の・どの環境のCIか」を毎回探すことになります。初動の遅れが常態化し、CMDBは「あるのに使えない台帳」になります。

CMDB Healthでこう使う：対象CIクラスの必須／推奨属性（required・recommended attributes）をCompletenessの評価対象として宣言します。すると空欄が定量化され、どの取込元（Data Source）や入力フローで属性が落ちているかをたどれます。

改善後：CIを開けば連絡先・責任者・環境がそろっている状態になり、障害の初動が速くなります。「埋めるべき項目」が明確なので、入力ルールやインポート設計の改善にも直結します。

早見表の該当行：「必須に近い項目が空欄のCIが多い」→ Completeness → クラスの必須／推奨属性を定義。誤答は「Discovery頻度を上げる」（属性定義がなければ頻度を上げても埋まらない）。

Correctness：CMDBは「300台」、実機は「210台」

現場で起きる事故：ライセンス棚卸しでCMDBを見ると「サーバー300台」。しかし実機は210台しかない。Discovery・手入力・インポートが、同じ物理サーバーを別々のCIとして重複登録していた。過剰なライセンス計上を疑われ、監査で説明できず、さらに「どのCIが本物か」が分からないため変更を間違ったCIに当ててしまう。

放置するとどうなる：重複の根っこは「識別の弱さ」です。識別ルールが甘いまま運用すると、Discoveryが回るたびに重複が増殖します。台数も影響分析も信用できなくなり、コスト判断・変更判断の前提が崩れます。退役済みのまま残るCI（Stale CI）も同じく数字を狂わせます。

CMDB Healthでこう使う：重複の根本対策は、Identification Rule（どの属性の組み合わせで同一CIと判定するか）とReconciliation Rule（どのデータソースの値を正とするか）の整備です。あわせてStale CIのしきい値（最終更新からの経過日数）を設定し、古いCIを検出します。

改善後：取り込み時にIRE（Identification and Reconciliation Engine）経由で既存CIと突合され、重複が新規作成されなくなります。Stale CIは定期的に洗い出され退役処理へ。CMDBの台数が現実と一致し、ライセンスや影響分析の前提が信頼できるものになります。

早見表の該当行：「同じサーバーらしきCIが複数」→ Correctness → 識別／調停ルール。「長期間更新なし」→ Stale CI。誤答は「手動マージで完了扱い」「Discovery頻度UP」（識別が弱いまま頻度を上げると重複が増える）。

Compliance：ルールは決めた、でも守られているか測れない

現場で起きる事故：「本番サーバーのCIには必ずサポートグループを設定する」「命名規則に従う」と社内ルールを決めた。半年後の監査で確認すると、本番CIの半分がサポートグループ未設定、命名もバラバラ。監査人に「ガバナンスが効いていない」と指摘され、是正対応に追われた。

放置するとどうなる：ルールを決めても「守られているか」を測る仕組みがないと、逸脱が静かに積み上がります。属性が埋まっている（Completeness）からといって、それが決めたルールに沿っているとは限りません。CSDMへの移行や監査の場面で破綻が表面化します。

CMDB Healthでこう使う：Compliance KPIに対して監査ルール／ポリシー条件を定義します。これはCompletenessの「空欄かどうか」とは別物で、「決めた条件（値の範囲・命名・必須の組み合わせ）に合致しているか」を継続的に評価します。

改善後：ルール違反のCIが定量化され、ガバナンスの逸脱を早期に検出できます。属性が埋まっているだけでなく「正しいルールに沿っているか」までチェックされるため、CMDBが組織標準（CSDMなど）に整合した状態を保てます。

早見表の該当行：「決めた監査ルールに従っていない」→ Compliance → 監査ルール／ポリシー条件を定義。誤答は「空欄を埋めれば解決」（充足と準拠は別物）。

Relationships：孤立CIが「影響なし」の嘘を生む

現場で起きる事故：冒頭で紹介したストレージ機器の停止事故が、まさにこのRelationshipsの問題です。CIの属性はきれいでも、関係（Relationships）が空だったため、「影響なし」と判断して停止し、基幹サービスを落としました。

放置するとどうなる：CIの属性（Completeness）がどれだけ整っていても、関係（Relationships）が空なら、CMDBは「影響なし」と“嘘”をつきます。変更の影響分析も障害の原因特定も機能せず、「登録されているのに使えないCMDB」になります。

CMDB Healthでこう使う：Relationships KPIで「関係を持たない孤立CI」を定期的に洗い出します。重要サービスを構成するクラスをPrincipal CI Class（重点管理クラス）に指定し、Service Mappingやマニュアル関係で「サービス→アプリ→基盤」の依存をつなぎます。変更申請時に影響分析が一画面で出ることを運用ルールにします。

改善後：同じメンテでも「このストレージ→DB→基幹サービス→営業部門」までたどれ、承認者が事前に影響を判断できます。停止は計画どおり、事故ゼロ。CMDBが「台帳」から「判断に使える地図」に変わります。

早見表の該当行：「関係を持たない孤立CIが多い」→ Relationships → Service Mapping／Principal CI Class。誤答は「CIを増やせば充実する」（CI単体より関係が価値）。

「点数を目的化する罠」を4つの具体シナリオに分解する

CMDB Healthでよく出る判断問題に「点数だけを上げることを目的化すると危険な理由は？」があります。選択肢はどれも本物のリスクで、消去法が効きません。具体シナリオに翻訳すると、最上位の理由とその下位の症状に整理できます。

「最も適切な理由は？」と問われたら、個別の症状ではなく「目的（運用判断に使えるCMDB）を見失う」という上位の理由を選びます。これが、抽象的な選択肢でも迷わないための判断軸です。

CMDB Healthを活かす運用ベストプラクティス

CMDB Healthは、ダッシュボードを眺めるだけでは価値が出ません。事故を防ぐ「使えるCMDB」を保つために、現場で押さえておきたい運用のベストプラクティスは次の5つです。

1. 週次でHealthダッシュボードを確認する。欠損・重複・Stale・孤立のうち、どのKPIが悪化しているかを定点で把握します。
2. 悪化したKPIごとに根本原因と対応設定を特定する。早見表を使い、たとえば「重複なら識別ルール」というように、原因と打ち手を結びつけます。
3. 是正はCMDB Data Managerで計画的に進める。その場しのぎの手作業ではなく、リメディエーション（是正）をタスクとして管理します。
4. 根本設定を直して再発を止める。識別ルール・必須属性・関係整備といった設定そのものを修正し、同じ問題が翌週また起きない状態にします。
5. 効果は「使えるようになったか」で測る。スコアが上がったかではなく、影響分析や変更判断に実際に使えるようになったかで成果を判断します。

PDIで手を動かして確認する場所

Personal Developer Instance（PDI）で実際の画面を触ると、早見表が記憶に定着します。

• CMDB Workspace ／ CMDB Health Dashboard：Completeness・Correctness・Compliance・Relationshipsのスコアとトレンドを見る
• 各KPIのドリルダウン：欠損・重複・Stale・孤立の対象CIを一覧で確認する
• Health KPIの定義・重み・しきい値：何を、どの基準で評価しているかを見る
• Principal CI Classの設定：重点評価するクラスがどう定義されているか
• CMDB Data Manager：データ品質の是正を計画的に進める入口
• CI Class Manager内のIdentification／Reconciliation Rule：重複・信頼ソースの根本設定

まとめ：事故の形で覚えると、判断問題に強くなる

• 抽象的な選択肢は「事故・設定・改善」に翻訳してから比べる
• 点数を上げる行動より「運用判断に使えるか」を上位に置く
• 欠損＝Completeness、重複・古い＝Correctness、ルール準拠＝Compliance、孤立＝Relationships
• 重複の根本対策は識別／調停ルール、古いCIはStale設定、孤立はService Mappingと関係整備
• 「Discovery頻度UP」「評価範囲を狭める」「検証なしの一括承認」は、原因究明を伴わない見かけ上の対処

CMDB Healthは、CMDB領域でも「判断問題」が集中するテーマです。事故の形と早見表が頭に入ったら、実際の問題で手を動かして判断軸を固めましょう。