第4章：信頼できるソースからのデータ投入 – Discoveryとその運用

4.1 ServiceNow Discoveryとは何か、その重要性

ServiceNow Discoveryは、ServiceNowプラットフォームが提供する機能で、ネットワーク経由で組織のIT環境を能動的にスキャンし、サーバー、ネットワーク機器、ソフトウェア、プロセス、さらにはそれらの接続や依存関係といった情報を自動的に識別・収集します。収集された情報は、ServiceNowのIdentification and Reconciliation Engine（IRE。第6章参照）で処理された後、CMDBに構成アイテム（CI）として登録・更新されます。Discoveryは、ServiceNow IT Operations Management (ITOM) スイートの中核機能のひとつです。

なぜDiscoveryがCMDBの構築と運用に不可欠なのか：

• データ精度と鮮度 (Data Accuracy and Freshness)： IT環境は絶えず変化します。Discoveryは変更を自動検出しCMDBへ迅速に反映、手動管理より格段に高い精度と鮮度を維持します。これはITSM運用やガバナンス要件を満たす上で極めて重要です。
• 網羅性 (Comprehensiveness)： 定義されたネットワーク範囲を体系的にスキャンし、管理外の「シャドーIT」や棚卸し漏れ資産を発見、CMDBの網羅性を向上させます。
• 効率性 (Efficiency)： 多数のCIと関係性情報を短時間で自動収集・更新できるため、特に大規模環境では手作業を大幅に削減できます。
• 関係性の自動検出 (Automated Relationship Detection)： CI間の依存関係（例：ソフトウェアとサーバーの実行関係）を自動検出し登録。Service Mappingや影響分析の基盤となります。

4.2 Discoveryの仕組みと主要コンポーネント

ServiceNow Discoveryは、主に エージェントレス方式 を採用しています。これは、対象機器に専用のエージェント（ソフトウェア）をインストールする必要がない方式です。Discoveryは、ServiceNowインスタンスと対象IT環境との通信によって実行されます。主な構成要素は以下の3つです。

• MIDサーバー (Management, Instrumentation, and Discovery Server)：

  役割: ServiceNowインスタンスと、社内ネットワークやクラウドなどの管理対象環境との間で中継役を務める軽量なJavaアプリケーションです。
  動作: ServiceNowからのDiscovery指示を受け取り、対象環境内でスキャンとデータ収集を実行し、結果をServiceNowへ返します。
  配置: 📌 ServiceNowインスタンスから直接アクセスできないネットワークセグメントに設置する必要があります。
  考慮点: 💡 通常、複数台を配置し、負荷分散、冗長化、役割分担を行います。
  通信: 多様なプロトコル（SSH, WMI, SNMP等）やクラウドAPIを用いて対象機器と通信します。

• パターン (Patterns)：

  役割: Discoveryが対象機器から情報を収集し、特定のCIクラスとして識別・分類し、関係性を特定するための一連の手順を定義したものです。
  形式: 通常XMLやJavaScriptで記述され、ServiceNowによって定期的に更新・提供されます。
  対象: 📌 特定の技術や製品（Windows Server, Linux, Tomcatなど）向けに設計されています。
  重要性: 👍 最新のDiscoveryにおけるデータ収集・識別の中心的な仕組みです。

• 認証情報 (Credentials)：

  役割: 対象機器にログインし、OSやアプリケーションレベルの情報を読み取るために必要なアクセス権情報です。
  種類: Windows認証情報、SSH認証情報、SNMPコミュニティ文字列、クラウドAPIキーなどがあります。
  管理: ServiceNowインスタンス内に「Credential」レコードとして安全に保管され、MIDサーバー経由で利用されます。
  課題: ⚠️ Discoveryの成否は、設定された認証情報の正確さと権限に大きく左右されます。

[図表プレースホルダー: ServiceNowインスタンス、MIDサーバー、ターゲットデバイス間のDiscovery処理フローを示す概念図。パターンと認証情報の役割も示す。]

4.2.1 エージェントレスDiscoveryとエージェントDiscoveryの比較

ServiceNow Discoveryは主にエージェントレス方式を採用していますが、対象機器に専用のエージェントを導入する方式も存在します。多くの場合、両者を組み合わせることが有効です。

📌 ServiceNowは、主要なデータ投入方法としてエージェントレスDiscoveryを推奨しています。しかし、PCの資産管理（ITAM）、特定情報の収集、既存のエージェント型ツールとの連携といったシナリオでは、Service Graph Connectors（SGC、第5章参照）を用いてエージェントが集めた情報を取り込むことも一般的です。💡 既存のエージェントを活用する方が効率的で、ライセンスコスト面（第5章参照）でも有利な場合があります。

4.3 Discovery実行の計画

効果的で信頼性の高いDiscovery運用には、事前の綿密な計画が必要です。これは、CMDB運用体制（2.4節参照）におけるCMDB管理者や運用スタッフの重要な役割となります。

• スキャン範囲の定義： CMDBスコープ（第2章参照）内のCIを検出できるよう、Discoveryがスキャンすべきネットワークセグメント（IPアドレス範囲）や特定のホスト名を定義します。📌 ビジネスクリティカルなITサービスに関連するネットワーク範囲（例：本番環境セグメント）は、初期フェーズで含めることを優先すべきです。運用負荷（ネットワーク帯域、対象機器への負荷）やセキュリティポリシーを考慮し、スキャン対象から除外するIPアドレスやホスト（例：プリンター、一部PC、テスト環境、アクセス禁止セグメント）も定義しておきましょう。
• スケジュール設定： Discoveryを実行する頻度とタイミング（スケジュール）を決定します。環境の変化の頻度（CIの追加・変更頻度）や、Discovery実行によるネットワーク・対象機器への負荷を考慮して設定します。フル スキャン（週次または月次で実行、オフピーク時間推奨）とQuick Discovery / Targeted Discovery（日次での実行も可）を適切に組み合わせます。
• MIDサーバー配置と構成： スキャン対象へのネットワーク接続性（経路、FW）、予想される負荷（対象CI数）、セキュリティ区域（例：DMZスキャンの要否）などを考慮し、必要なMIDサーバーの数と配置場所を決定します。 MIDサーバーをインストールし、ServiceNowインスタンスへの接続を設定した後、各MIDサーバーに、どの機能（Capabilities）を持たせ、どのIP範囲を担当させるかを設定します。
• 認証情報の収集と管理： スキャン対象のIT資産（サーバーOS、NW機器CLI、DBインスタンス等）へのアクセスに必要な認証情報（Windowsアカウント、SSHアカウント、SNMPコミュニティ文字列、APIキー等）を事前に収集・整理します。 収集した認証情報は、ServiceNowインスタンス内にCredentialレコードとして安全に保存・管理します。📌 最小権限の原則が適用されます。⚠️ 認証情報の定期的な棚卸し、更新、有効性確認のプロセスも、運用体制（2.4節参照）に組み込む必要があります。
• ネットワーク要件の確認： Discovery実行前に、MIDサーバーから対象機器への通信（ServiceNowドキュメント記載のポート/プロトコル）が、ファイアウォール等で許可されているかを確認します。 必要であれば、ネットワーク担当者と連携し、設定変更を行います。

[図表プレースホルダー: Discovery計画の主要項目をまとめたチェックリスト形式の表]

4.4 Discoveryの実行と監視

計画に基づき、ServiceNow上でDiscoveryを実行し、その状況を継続的に監視します。

• Discoveryの開始： スケジュールされたジョブで自動実行するか、手動で開始します。
• Discoveryステータスの監視： ServiceNowの「Discovery Status」モジュールで実行状況を確認します。📌 エラーや警告がないか監視します。
• Discoveryログのレビュー： 詳細なログメッセージからエラー原因の手がかりを探します。📌 問題の原因究明に役立つ重要な情報源です。
• 検出済みアイテム（Discovered Items）のレビュー： 未分類のデバイスなどを定期的に確認し、対応を検討します。
• 運用スタッフの役割： スケジュール管理、日々の監視、初期対応、Discovered Itemsレビューが重要責務です。

[図表プレースホルダー: ServiceNowのDiscovery Statusダッシュボードのサンプルスクリーンショット]

4.5 Discovery結果のレビューとトラブルシューティング

Discoveryが正常に完了した後も、収集されたCIデータの品質を確認し、問題があれば原因を突き止め対処する（トラブルシューティング）ことが重要です。Discoveryで投入されるデータの精度や網羅性はCMDBの信頼性に直結するため、このレビューとトラブルシューティングのプロセスは継続的に行う必要があります。

4.5.1 Discovery結果のレビュー

検出されたCI数やCIタイプ別の内訳、収集された属性情報、検出された関係性などが、組織のIT環境の実態や想定と合っているかを確認します。📌 特に、重要度の高いCIが漏れなく検出されていること、必須属性が正確に取得されていることに注意します。

4.5.2 よくあるDiscovery失敗パターンと原因

• 認証情報問題： ユーザー名/パスワード間違い、権限不足など。⚠️ 最も一般的。
• ネットワーク接続問題： FWブロック、ネットワーク障害、対象機器ダウンなど。
• 分類失敗 (Classification Failures)： 情報不足やパターン不一致で機器タイプを識別できない。
• パターン実行エラー： コマンド失敗、構成ファイル読取不可、解析エラーなど。
• ServiceNow処理問題： IREルールエラー、リソース不足、スクリプトエラーなど。

4.5.3 トラブルシューティング手順

問題発生時は、以下の手順で調査を進めます：

1. Discoveryログ分析：詳細メッセージから原因の手がかりを探す。
2. ECCキュー確認：生データと処理結果、エラーを確認。
3. MIDサーバーログ確認：通信状況、パターン実行エラーを調査。
4. ターゲットデバイス検証：稼働状況、ネットワーク接続、認証情報、情報アクセス権限を直接確認。
5. 認証情報テスト：「Test Credential」機能で確認。
6. パターンデバッグ：Pattern Designerで問題パターンを追跡・修正。

📌 運用スタッフが専門家として実行し、必要に応じて関連部署と協力します。💡 特定された原因は再発防止のため運用プロセス等へフィードバックします。

4.6 新しいCIタイプとカスタムパターンの取り扱い

組織内には、標準のDiscoveryパターンでは検出できない独自のアプリケーションや特殊な機器が存在することがあります。これらがCMDBの管理対象に含まれる場合、カスタム対応が必要になります。

4.6.1 カスタム対応の必要性

📌 管理対象とすべきCIや属性情報が標準のDiscovery機能では扱えず、かつビジネスや運用の要件として必要な場合に、カスタム対応を検討します。

4.6.2 カスタムパターン開発

💡 ServiceNowのPattern Designerツールを使用しますが、対象技術への深い理解と専門知識が求められます。

4.6.3 カスタム識別・調整ルール作成

IRE（第6章参照）で専用の識別ルールや調整ルールを作成する必要があります。⚠️ カスタムCIクラスを作成した場合は必須です。

4.6.4 運用体制との連携

カスタムパターンの開発・テストはCMDB管理者/運用スタッフが主導し、CIオーナーグループから専門知識の提供を受けます。本番適用前にCMDBガバナンス委員会の承認を得るべきです。📌 カスタム対応は継続的なメンテナンスが必要なため、運用体制やコストも考慮します。

4.7 Discoveryの限界

ServiceNow Discoveryは強力な自動化ツールですが、すべてのデータ投入ニーズに応えられる万能な解決策ではありません。CMDBの網羅性と価値を最大化するには、これらの限界を理解した上で、Discoveryと他のデータ投入方法を適切に組み合わせることが不可欠です。

📌 標準Discoveryでの取得が困難または不可能な情報の例：

• SaaSアプリケーションの内部構成（API連携が必要）
• パブリッククラウド（IaaS, PaaS）の詳細構成と論理リソース（Cloud Discovery (API連携) が必要）
• 物理資産情報（資産タグ、購入日、保証期間、契約情報、コストなど - ITAM領域）
• ソフトウェアライセンス情報（ライセンス数、使用状況など - SAM領域）
• 組織的関係性（部署とアプリ利用の関係など）
• 特定の詳細な設定値、性能値、ログ情報
• 手動管理の特殊資産（隔離ネットワーク内、小規模/特殊資産など）
• ユーザーとデバイスの割り当て

💡 このようにDiscoveryだけではカバーできない情報は、次章（第5章）で解説する他の方法（外部システム連携、手動入力など）によってCMDBへ取り込む必要があります。

4.8 本章のまとめ

• ServiceNow Discoveryは、ITOMの中核をなす強力な自動化ツールであり、CI情報とその関係性をCMDBへ正確かつ網羅的に、効率よく投入できます。
• エージェントレス方式は導入が容易ですが、ネットワーク接続と認証情報の管理が課題となります。
• Discovery成功には、綿密な計画（スコープ、スケジュール、認証情報）、MIDサーバーの適切な配置・構成、継続的な監視とトラブルシューティングが不可欠です。
• Discoveryで自動収集されたデータは信頼性が高く、ITSM運用や監査対応の重要な基盤情報となります。
• Discoveryには限界があるため、他のデータ投入方法（外部システム連携や手動入力など）と適切に組み合わせることがCMDBの価値を高めます。
• Discoveryの運用は、第2章で設計した運用体制のもとで継続的に実施し、CMDB管理者/運用スタッフとCIオーナーグループとの緊密な連携が必要です。