ServiceNowの Service Mapping（サービスマッピング） は、インフラ構成要素（サーバ、アプリケーション、ネットワーク機器など）と、それらが提供する ビジネスサービスの関係を自動的に可視化・維持 するための機能です。以下のようなことが「期待できること」「実際にできること」として整理できます。
🧭 1. 期待できること（導入効果・目的）
■ サービス全体の依存関係を“自動”で把握できる
従来は人手でExcel管理されていた「このアプリはどのサーバに依存しているのか」「障害が起きたらどの業務が止まるのか」といった情報を、Service Mappingは自動発見（Discovery）結果をもとに構築・維持します。
- サービスの構成要素（Application Service）を1クリックでトポロジ図として表示
- ネットワーク経路・依存関係（HTTP、DBコネクションなど）を可視化
- サービス停止時の影響範囲をリアルタイムに特定可能
⚙️ 2. できること（主要機能）
| 分類 | 機能内容 | 補足 |
|---|---|---|
| サービス検出 | 指定した「エントリポイント（URL, ポート, プロセス）」から通信経路を自動追跡し、関連するサーバ・コンポーネントを特定 | Discoveryエンジンを活用 |
| トポロジマップの作成 | アプリケーションの依存関係をグラフィカルにマップ化 | CMDBのcmdb_ci_service_discoveredに登録される |
| 更新・同期 | 定期的に再スキャンして変更を自動反映 | 手動メンテ不要 |
| 影響分析（Impact Analysis） | サービス停止・変更が下流システムに与える影響を即座に算出 | Change ManagementやIncidentと連携 |
| イベント連携（Event Mgmt） | Service Map上にイベントやアラートを可視化 | ITOM Event Managementと統合 |
| ビジネスサービスモデル化 | “顧客向け業務”単位で構成を整理（例：ECサイト、給与システムなど） | CSDM（Common Service Data Model）準拠 |
| 変更管理との統合 | 変更申請時に影響範囲を自動特定 | CAB判断材料として活用 |
| 自動CMDB整合性維持 | Service Mappingで得た依存情報をCMDBへ反映 | 手動入力や誤登録を減らす |
📊 3. 利用シナリオ例
| シナリオ | 活用内容 |
|---|---|
| 障害対応 | 「特定サーバがダウン」→「そのサーバに依存する業務アプリを即特定」 |
| 変更管理 | 「このアプリを再起動したら他のサービスに影響があるか？」を自動判定 |
| 監視設計 | 監視アラートをサービス単位で関連付けて優先度付け |
| CSDM整備・CMDB再構築 | 手動登録のCMDBを自動検出結果でリフレッシュ |
| クラウド移行計画 | どのオンプレアプリがどのネットワーク・DBに依存しているかを可視化して移行リスクを算出 |
🧩 4. 関連モジュールとの連携
- Discovery：基盤の自動検出エンジン（Service Mappingの前提）
- ITOM Health / Event Mgmt：イベント可視化・影響範囲分析
- CMDB / CSDM：サービスデータの統合管理
- Change / Incident Mgmt：変更・障害への影響分析
- Service Graph Connectors：他システム（AWS, Azureなど）との統合
🚀 5. 導入時に意識すべきこと
- エントリポイント設計が肝：サービスの起点を誤るとマッピング精度が下がる
- Discoveryとの協調が必須：Service Mapping単体では機能しない
- ネットワーク経路へのアクセス権：MIDサーバを適切に設計する必要あり
- CSDM整合性：Application Serviceの階層モデルを整備しておくと効果的
非常に鋭い質問です。
おっしゃる通り、「システム台帳（ビジネスアプリケーションなど）とCIを手動で関連付ける」という方法は、ServiceNowの導入初期や小規模システムではよく行われるアプローチです。
ただし、それで得られる効果には限界があり、Service Mappingによる自動マッピングとの差分・発展性を理解しておくと、将来の拡張に失敗しません。
以下に、段階的に整理して解説します。
🧩 1. 「ビジネスアプリケーションとCIを関連リストで結ぶ」構成の特徴
✅ メリット
-
シンプル・即実装可能：
CIフォームやビジネスアプリケーションフォーム上の「関連リスト（Relationships）」で手動リンクするだけ。 -
小規模構成に適する：
たとえば「社内勤怠システム → Webサーバ / DBサーバ」といった2〜3層構成なら十分管理可能。 -
CSDMレイヤ2（Application Service）未導入でも使える：
つまり、ビジネスアプリケーションのCIを“代表的な構成要素”として登録しておくイメージ。
⚠️ 限界と発展性の壁
| 項目 | 手動マッピングの限界 |
|---|---|
| 構成の正確性 | 人手で更新するため、変更のたびに整合性が崩れやすい。特にクラウド環境では現実と乖離しやすい。 |
| 依存関係の可視化 | ネットワーク経路（Web→App→DBなど）やプロセス間通信は自動検出できない。 |
| 影響分析 | CIリンクのみでは「どのサービスがどのサーバに依存しているか」を動的に解析できない。 |
| イベント/監視との統合 | Event Managementなどと連携しても、単純リンクでは「どのサービスの障害か」まで特定できない。 |
| CSDMの進化対応 | CSDM 4/5で求められる「Application Service（アプリケーションサービス）」階層との整合性が取れない。 |
| 自動維持性 | 手動管理のため、サーバ移行・リネーム・クラウド再配置時に台帳が追随しない。 |
🧭 2. 「発展」の方向性（Service Mapping / Discovery連携）
| 発展段階 | 実現手法 | できること |
|---|---|---|
| ① 手動リンク管理 | ビジネスアプリケーション ↔ CI の関連リスト | 物理的な紐付けのみ（静的） |
| ② Discovery導入 | MIDサーバでインフラを自動検出しCMDB更新 | CI属性や稼働状態を自動反映 |
| ③ Application Service導入 | Application Service CIを導入し、構成を論理的に整理 | サービス単位の依存を表現可能 |
| ④ Service Mapping導入 | 通信経路をトレースし自動トポロジ生成 | 自動維持・影響分析・イベント統合が可能 |
| ⑤ ITOM Health統合 | Event Managementと統合 | 障害発生時にサービス単位で影響範囲を可視化 |
🔍 3. 実務での使い分け指針
| 規模・目的 | 推奨アプローチ |
|---|---|
| 小規模・PoC段階 | ビジネスアプリ ↔ CIを関連リストで手動管理 |
| 中規模（10〜50システム） | DiscoveryでCI自動検出＋Application Service導入 |
| 大規模・可用性重視 | Service Mappingで自動トポロジ化＋Event連携 |
🧱 4. CSDMとの整合イメージ
CSDM（Common Service Data Model）では、手動リンクだけでは以下の階層が欠落します：
Business Service（業務サービス）
└ Application Service（アプリケーションサービス）
└ Application / Server / Database（CI）
- 手動リンク：
Business Application ↔ CI（階層が“つぶれて”いる） - Service Mapping：
Application Service層を生成し、通信関係から自動構成
結果として、Service Mappingを入れると、CSDMに忠実な3層構造が自動で構築され、ITOM/ITSM両方の連携が可能になります。
🚀 5. まとめ：台帳連携方式の「発展パス」
| フェーズ | 管理方式 | 主な利点 | 今後の発展 |
|---|---|---|---|
| 現状 | 手動リンク | 手軽・明快 | 精度・保守性に限界 |
| 発展1 | Discovery連携 | CI更新自動化 | ネットワーク関係は未把握 |
| 発展2 | Application Service導入 | サービス単位管理 | トポロジ自動化へ準備 |
| 発展3 | Service Mapping導入 | トポロジ・依存関係自動維持 | イベント・変更管理統合 |
もし希望があれば、
- 「台帳方式」から「Service Mapping方式」へ移行するロードマップ図
-
CSDMレイヤー別のマッピングテンプレート（Excel形式）
を作成して差し上げられます。
どちらを先に見たいですか？（ロードマップ図 or マッピングテンプレート）