目次
この記事のポイント
- CMDBの価値は影響範囲が即座に分かること。まず基幹系（SAP・認証・ネットワーク）に限定する
- CIの粒度は「障害時に誰に連絡し、何を止めるか」で決める。サーバ単位から始めて業務サービス単位へ
- 手入力は必ず腐敗する。Discovery／Service Graph で自動検出し、人手は例外だけ
- SAP連携は「業務サービス ↔ 伝票・ジョブ」をひも付ける。障害時に業務影響を数字で説明できる
- 生成AI（Now Assist）はナレッジ要約から始める。判断の自動化はデータ品質が整ってから
01WHAT CMDBは「ITの地図」、CIはその区画
CMDB は、サーバ・ネットワーク・アプリ・業務サービスと、それらの依存関係を記録した「IT 資産の地図」です。地図上の1つひとつの区画が CI（Configuration Item）で、インシデント・変更・問題がこの CI に紐づきます。障害が起きたとき、影響する業務・連絡すべき担当・関連する変更履歴が一目で分かるのが CMDB の実利です。逆に CI が整理されていないと、インシデントは「サーバAが落ちた」で終わり、業務への影響を説明できません。
CI の粒度は「対応の単位」で決める
粒度は細かすぎても粗すぎても使えません。判断基準は「障害時に対応する単位」です。サーバ単位で復旧・交代・連絡先が決まるならサーバを CI にし、業務単位で停止判断をするなら「業務サービス」を上位の CI として作ります。実務では、①サーバ・ネットワーク機器（自動検出しやすい）②アプリケーション③業務サービス（人手で定義）の3層に分け、③に SAP の主要業務（受注・出荷・請求・締め処理など）を並べると、経営層にも説明しやすくなります。
自動検出と人手の役割分担
手入力の CMDB は、更新が止まった時点で負債になります。ServiceNow には Discovery や Service Graph Connector など、既存ツールから構成情報を取り込む仕組みがあります。基本は自動検出を正とし、人手は「例外」と「業務サービス定義」に限定します。取り込み結果に食い違いが出た場合は、どちらを正とするかをルール化（例：サーバ情報は検出、業務サービスは人手）しておくと、更新が止まりません。
補足：CMDB の「健診」を習慣にする
重複 CI・未更新 CI・孤立 CI の件数を月次で確認し、増加傾向なら取り込みルールを見直します。件数を見るだけでも品質は維持できます。
02POINTS CMDBとSAP連携を進める4つの手順
- 対象を基幹系に絞る。SAP、認証基盤、ネットワーク、主要アプリに限定して CI を定義します。全資産を対象にすると初回で挫折します。
- 自動検出を入れて「正」を決める。Discovery 等でインフラ層を取り込み、人手管理は業務サービス定義と例外に限定します。
- SAPの業務サービスをCMDBに定義する。受注・出荷・請求・締め処理などの業務サービスを CI として登録し、関連するジョブ・インターフェース・担当を紐づけます。
- 影響分析とレポートを運用に組み込む。変更時に影響サービスを自動表示し、障害時に影響業務を一覧化します。定例会議の資料を CMDB から生成します。
変更時に「影響業務」を自動表示する
変更要求の画面に、対象 CI から辿れる業務サービス一覧を表示します。承認者が「どの業務が止まり得るか」を同じ画面で判断できるため、承認の質と速度が同時に上がります。
03INSIGHT データ品質が整うと、生成AI（Now Assist）が効き始める
ServiceNow の Now Assist のような生成AI機能は、インシデントの要約・ナレッジ候補の提示・対応履歴の整理などで効果を出します。ただし入力が整っていないと、要約も候補も役に立ちません。CMDB とカテゴリ、そして過去の解決記録が整理されているほど、AI の出力品質が上がるという順序を理解しておくことが重要です。まずナレッジ要約から始め、判断の自動化は後段に置くのが安全です。
当社は SAP 基幹システムの運用・保守支援を通じて、業務サービスとジョブ・インターフェースの依存関係を扱ってきました。この知見を生かし、CMDB の対象範囲の設計、SAP 業務サービスと CI の紐づけ、影響分析レポートの整備、そして AI 活用の段階設計までを支援します。
CMDB は作って終わりではなく、継続的な「健診」が必要です。月次で、①重複 CI の件数 ②一定期間更新されていない CI の件数 ③どの業務サービスにも紐づいていない孤立 CI の件数の 3 つを確認します。数値が増え続けるなら、取り込みルールか人手の運用に原因があります。まずは件数を可視化するだけでも品質は維持でき、AI 活用の前提も整います。
豆知識：CI に「業務影響度」を持たせると優先度が自動化できる
CI に業務影響度（例：売上直結・社内のみ）を持たせておくと、インシデント起票時に対象 CI から優先度を自動判定できます。判断基準が仕組みに入るため、担当者によるばらつきが減ります。
まとめ
- CMDBの目的は影響範囲の即時把握。まず基幹系に限定して始める
- CIの粒度は「障害時に対応する単位」で決める（業務サービスを上位に置く）
- 自動検出を正とし、人手は業務サービス定義と例外に限定する
- SAPの業務サービスとジョブ・インターフェースを紐づけ、影響分析に使う
- データ品質が整ってから生成AI活用の段階に進む
出典・参考
- ServiceNow 公式サイト（製品・プラットフォームの一次情報） https://www.servicenow.com/jp/
- ServiceNow 製品ドキュメント（設定・データモデルの一次情報） https://docs.servicenow.com/
- ServiceNow Community（実装事例・ベストプラクティス） https://www.servicenow.com/community/
※本記事は上記の公開情報をもとに、アラディンテクノロジー株式会社編集部が独自に整理・考察したものです。内容は執筆時点（2026-09-12）の情報です。考察部分は当社の見解であり、特定の製品・導入を推奨するものではありません。
04FAQ よくある質問
CMDB はどこから整備すべきですか？
影響の大きい基幹系（SAP、認証基盤、ネットワーク）と、その上の業務サービスから始めることを推奨します。全資産を一括で登録する進め方は、更新が追いつかず形骸化しがちです。
手入力の構成情報が更新されません。どうすればよいですか？
自動検出（Discovery 等）を「正」とし、人手管理は業務サービス定義と例外に限定します。あわせて重複・未更新・孤立 CI の件数を月次で確認する運用を入れると維持できます。
SAP と連携すると具体的に何が良くなりますか？
障害や変更の影響を「業務の言葉」で説明できるようになります。たとえば「このサーバ停止で受注登録が止まる」と即座に判断でき、連絡先・影響範囲・過去の類似障害を同じ画面で確認できます。
生成AI（Now Assist）はいつから使えますか？
機能自体は早期に使えますが、効果はデータ品質に依存します。まずインシデント要約やナレッジ候補提示から始め、カテゴリ・CMDB・解決記録が整ってから判断の自動化へ進む段階設計を推奨します。