ServiceNow を AI から自然言語で操作する MCP サーバーに Discovery 運用可視化ツール(実行履歴・デバイス単位の結果・ログ・MID ヘルス)を追加し、Docker Desktop 上に建てた MID Server で実スキャンを完走させて検証しました。

Discoveryで検出された CI からソフトウェアインストール・正規化(SAM)までのデータ連鎖を実データで追跡します。

GitHub: https://github.com/tedorigawa001/ServiceNow-MCP

何を作ったか

1. Discovery 運用可視化ツール(11 ツール)

これまで MCPでは　list_discovery_schedules / list_mid_servers / run_discovery_scan の 3 つを実装していましたが、スキャンを起動できるのにDiscovery結果を追えない状態でした。
「昨夜の Discovery は成功した?」「このサーバーが発見されない原因は?」に答えるための新モジュールを追加:

ツール	テーブル	用途
`list_discovery_runs` / `get_discovery_run`	`discovery_status`	実行履歴(DIS 番号でも sys_id でも)
`list_discovered_devices`	`discovery_device_history`	デバイス単位の結果。`with_issues_only` で問題機だけ抽出
`list_discovery_logs`	`discovery_log`	センサー/プローブのログ(失敗原因の特定)
`list_discovery_ranges`	`discovery_range_item`	スキャン対象 IP レンジ
`list_discovery_credentials`	`discovery_credentials`	認証情報メタデータのみ(シークレット列は fields に含めない)
`list_mid_server_issues` / `get_mid_server_health`	`ecc_agent_issue` / `ecc_agent`	MID の問題・健全性サマリ
`list_acc_agents` / `list_acc_policies` / `list_acc_checks`	`sn_agent_*`	ACC(プラグイン未導入なら `PLUGIN_NOT_INSTALLED` を明示)

2. Mac上に検証環境を構築

MID Server が無いと Discovery を動かせません（エージェント型はACCを利用)。
MID Server は公式インストーラ ZIP から Dockerfile を書けばコンテナで動きます(Apple Silicon でも Rosetta で x86-64 動作)。
構成は以下。

┌─ Docker Desktop(Mac)── 172.XX.XX.0/24 ────────┐
│  ┌─────────────┐  ┌──────────────────────────┐  │
│  │ MID Server   │→│ target1 (.21) SSH+正しい認証│  │
│  │ (.10)        │→│ target2 (.22) SSH+認証未登録│  │
│  └──────┬──────┘  └──────────────────────────┘  │
└─────────┼───────────────────────────────────────┘
          ↓ HTTPS(アウトバウンドのみ、ポート開放不要)
     ＜PDI>.service-now.com

ポイントは target2 をわざと「認証情報未登録」にしたこと。
認証失敗ケースを意図的に作ることで、with_issues_only やログ調査ツールの検証データになります。

落とし穴: Discovery はレンジ未リンクで「黙って」中断する

修正版でDiscoveryをトリガーしても、run が作られませんでした。
sys_trigger は発火して消えるのに、discovery_status もエラーログも何も残らない。

診断用の Scheduled Script Execution を仕込んで確認すると、スケジュール実行スクリプトの Discovery().discoveryStartJob() は正常に返っているのに run が無い。
そこで Discovery Script Include のソースを読みました。

discoveryStartJob: function() {
    if (!this.isValidDiscoverySchedule(current))
        return;                                    // ← 黙って return
    ...

そして isValidDiscoverySchedule → isValidRange の中に決定打が:

isValidRange: function(schedule) {
    ...
    var gr = new GlideRecord('discovery_range_item');
    gr.addQuery('schedule', schedule.sys_id);      // ← リンクは "schedule" フィールド
    gr.addQuery('active', true);
    ...

私は IP レンジ(discovery_range_item)を parent フィールドでスケジュールに紐付けていました。parent の参照先は discovery_range(レンジセット)で、スケジュールとのリンクは別にある schedule フィールドが正解。
parent に入れてもバリデーションは 0 件 → 警告ログ 1 行だけ残して status も作らず中断します。

// ❌ parent に入れても Discovery からは見えない
{ parent: scheduleSysId, type: 'IP Network', network_ip: '172.XX.XX.0', netmask: '24' }
// ✅ schedule フィールドでリンクする
{ schedule: scheduleSysId, type: 'IP Network', network_ip: '172.XX.XX.0', netmask: '24' }

schedule に直したら即座に DIS0010002 が Starting で出現しました。
ツール側にも還元し、run_discovery_scan はトリガー後に schedule=<id>^active=true のレンジ数を確認して 0 件なら warning を返すようにしました。

教訓: サイレントアボートは Script Include のソースを読むのが最短。 sys_script_include は REST で読めるので、「なぜ動かない」は動くはずのコードの条件分岐を直接見に行けます。

実スキャンの結果(DIS0010002、4分で完走)

対象	結果
172.XX.XX.10(MID 自身)	検出のみ
172.XX.XX.1(Docker GW)	検出のみ
172.XX.XX.21(target1)	「Linux Server」に分類 → CMDB に CI「disco-target-01」生成
172.XX.XX.22(target2)	issues=2(狙い通り認証失敗)

Discovery Log

MCPでは、with_issues_only: true で問題デバイスだけが抽出でき、そのデバイスのログを list_discovery_logs で辿ると:

"Could not find any valid credentials to authenticate the target
 for types [SSH Password, SSH Private Key, Azure SSH Certificate]"
"Probe skipped due to failure of previous probe attempt"

**「なぜこのサーバーが発見されないのか」→「SSH 認証情報が無いから」**まで、AI が自力で答えられるデータが揃いました。

Discovery → CMDB → SAM のルートを追跡する

スキャンが完走すると、SAM Pro(前記事で追加したツール群)へのデータ連鎖が始まります。実データで 3 段を確認しました。

Discovery (DIS0010002)
   ↓ SSH probe → dpkg パッケージ収集
① CI: cmdb_ci_linux_server「disco-target-01」
     os=Linux Ubuntu 22.04.5 / discovery_source=ServiceNow
   ↓ installed_on
② Software Installation: cmdb_sam_sw_install に 135 件
     openssh-server / coreutils / util-linux / ...
   ↓ discovery_model
③ Software Discovery Model: cmdb_sam_sw_discovery_model に 142 件生成
     正規化パイプラインへ投入

openssh-server で 3 段の連結を具体的に見ると:

SoftwareInstallテーブルでは CI disco-target-01 を installed_on カラムでリンク
また、ソフトウェア検出モデルに discovery_model カラムでリンク

面白いのは、生成された Ubuntu パッケージの発見モデルが軒並み status「Match Not Found」(norm_publisher 空・unlicensed_install=true)だったこと。
これはバグではなく、ServiceNow のコンテンツライブラリに Ubuntu のシステムパッケージ(libwrap0 や ucf)が載っていないため正規化が成立しない、
SAM Pro 実運用でもおなじみの状態です。既存データの VMware / Microsoft 製品は「Normalized」でパブリッシャー突合済みなので、正規化済み/未正規化の両状態が同居する現実的なデータセットになりました。

SoftwareInstallテーブルに登録されたレコード
⭐️Discovery Source=ServiceNowとなる
⭐️ソフトウェア検出モデルには、ビジネスルールを介して自動的にコピーされる

結果として、こういう調査が MCP ツールだけで一気通貫に回ります:

「昨夜の Discovery の結果は?」        → list_discovery_runs
「発見に失敗したデバイスは? なぜ?」   → list_discovered_devices(with_issues_only) → list_discovery_logs
「新しく発見されたサーバーの中身は?」  → list_software_installs(installed_on=CI)
「未正規化のソフトは?」              → list_software_discovery_models(Match Not Found)
「ライセンスは足りてる?」            → list_license_positions / get_license_position_summary

ITOM(Discovery)と ITAM(SAM)は組織でも担当が分かれがちですが、データは一本の川です。
AI から見るとテーブルの垣根はないので、この縦断トレースは MCP と相性が良いと感じています。

まとめ

discovery_status を直接 insert してもスキャンは起動しない。 Discovery エンジンはスケジューラ経由の run しか開始しない。REST API からの正攻法は「スケジュールを run_type=once + run_start=now に PATCH」
IP レンジとスケジュールのリンクは discovery_range_item.schedule フィールド。 parent(レンジセット用)に入れると、Discovery は status も作らずサイレント中断する
サイレントアボートの調査は Script Include のソースを読む。 sys_script_include は REST で読める
MID Server は Docker で動く。 公式インストーラ ZIP + 数十行の Dockerfile。認証失敗ケース用のターゲットをわざと置くと検証データが充実する
Discovery → CI → Software Installation → Discovery Model → ELP の ITOM/ITAM 縦断ルートが MCP ツールだけでトレースできる

おまけ