CMDB・ITOMのAIエージェント機能紹介と代表機能の定義の確認
CMDBにCIを登録する、MID Serverを再鍵する、アラートの原因を調べる。ServiceNowの標準のAIエージェントには、こうした運用の操作を会話で任せられるものが入っています。今回のデモ環境（日本語表示）でCMDB・ITOM領域のワークフロー18件の定義を確かめると、AI Agent Studioのトリガー設定は18件とも0件でした。ツールの割り当て95件は、ツールの実行モードがすべて自律です。ツール設定の上では、人の承認で止まる「監視中」は1つもありません。
OOTBのまま使えるかは、誰が依頼でき、どこまで書き換えられるかを有効にする前に決められるかで見極めます。この記事は定義の確認で、ワークフローを動かした結果は含めていません。
検証環境：Now Assist デモ環境（Australia Patch 5）/ 2026-10-02 確認
定義の確認でわかったこと
CMDB・ITOM領域のOOTBワークフローは18件。CMDB 9件、Discovery 3件、AIOps 2件、Service Mapping・Observability・MID Guardian・LEAPが各1件
ツールの割り当て95件は、確認できた範囲ですべて自律。承認で止まる「監視中」は0件
AI Agent Studioのトリガーは18件とも0件。自動で動くのは1件だけで、起動のきっかけはトリガーでなくアラート管理ルール
記録や設定を変えるツールを持つのは、CI作成・主要クラスの設定・MID Serverの再鍵・修復の実行などを含む複数のワークフロー
任せる範囲は、機能の種類ごとに決める
試行は定義の確認が中心です。AI Agent Studioの定義画面を3つのワークフローで開き、トリガー・エージェント・ツールの実行モードを読みました。残りの15件は、AI Agent Studioの定義データを読み取りで確認しています。設定の変更と保存は0件、既存のCIの変更も0件です。製品全体の評価ではなく、有効化の前に確かめる観点を洗い出すケーススタディです。
CMDB・ITOMのAIエージェントの一覧
この記事で扱うのは、CMDB・ITOM領域のOOTBワークフロー18件です。AI Agent Studioのエージェント型ワークフローは、複数のAIエージェントとツールをまとめ、1つの目的を進める単位になっています。公式ドキュメントでは、CMDB向けは「ServiceNow Otto for Configuration Management Database (CMDB)」の機能です。アラート向けは「ServiceNow Otto for ITOM」の機能として説明されています。
表の内容を文字でも書き出します。
Search CMDB（CMDB を検索）：検索クエリを実行してCIを探せる。手動で依頼し、表示だけ
CMDB Data Model Navigator Assistant（CMDB データモデルナビゲーターアシスタント）：クラス・項目・関係の質問に答える。手動で依頼し、表示だけ
Show contextual CI form help（コンテキスト CI フォームヘルプを表示）：CI属性とクラスの質問に答え、画面を案内する。手動で依頼し、表示だけ
Assess CMDB Impact（CMDB への影響の評価）：変更やインシデントが及ぶCIをHighからNoneまで分類する。手動で依頼し、表示だけ
Debug service graph connector ingestion（サービスグラフコネクターの取り込みのデバッグ）：取り込まれなかったCIの理由を調べる。手動で依頼し、表示だけ
Enable CMDB lifecycle insights（CMDB ライフサイクルインサイトの有効化）：旧ライフサイクル項目の使われ方を分析する。手動で依頼し、表示だけ
Recommend Service Graph Connectors（サービスグラフコネクターの推奨）：取り込みに使えるコネクターを提案する。手動で依頼し、表示だけ
Analyze Potential Impact（想定される影響の分析）：変更が及ぶサーバーとサービスを分析する。手動で依頼し、変更の作業メモに保存する
Analyze alert impact（アラートの影響度の分析）：アラートの影響・根本原因・担当を調べる。手動で依頼し、アラートに保存する
Manage alerts autonomously（アラートを自律的に管理）：振り分け・影響分析・原因調査をまとめて行う。ルールで自動的に動き、アラートに保存する
Create configuration item（構成アイテム (CI) を作成）：クラスを選び、属性を埋めてCIを作る。手動で依頼し、CIを作成する
Provide advice on CMDB governance（CMDB ガバナンスに関するアドバイスを提供）：所有権・ヘルス・ライフサイクルを点検する。手動で依頼し、主要クラスの設定を変えられる
Create alert automation（アラートの自動化を作成）：アラートのグループ化ルールを作る。手動で依頼し、ルールを作成・削除・有効化する
MID Guardian Workflow（MID ガーディアンワークフロー）：MID Serverの問題を診断し、再鍵などを行う。手動で依頼し、MID Serverを操作する
Pattern Diagnostic Workflow（パターン診断ワークフロー）：Discoveryのエラーを分類し、修復を実行する。手動で依頼する
Firewall Management Task Creation Workflow（ファイアウォール構成エージェント）：ファイアウォールルールのタスクを作る。手動で依頼し、タスクを作成する
Certificate Management Renewal Workflow（証明書管理更新ワークフロー）：証明書を検索し、更新する。手動で依頼する
LEAP agent（LEAP エージェント）：自動化の機会に関する成果物を作る。手動で依頼し、成果物を作成する
一覧に入れなかったものもあります。Synthetic Monitoring・ATF・Indoor Mapping・Data Catalogのエージェントはワークフローを持たないため、対象外にしました。「手動で依頼」は、AI Agent Studioのトリガーが0件のため、手動の依頼を想定した分類です。実際にどの画面から呼ぶかは、今回確かめていません。
起動のきっかけから結果までの流れを、次の図にまとめました。
起点は CMDB・ITOM の依頼とアラート、橙はルールで自動で動く経路、緑は表示と保存に限られる結果、赤は記録・設定・機器を変更する結果、灰色は OOTB に該当がない経路
自動で動く経路は、アラート管理ルールで起動する1件です。赤の結果には、承認を挟まずCI・設定・MID Serverを変更できるワークフローが集まっています。灰色の「人の承認のあとに書き込む」は、今回確認した18件には該当がありません。
図の内容を文字でも書き出します。
手動で依頼する経路：AI Agent Studio のトリガーは0件。動くのは手動の17のワークフロー（CMDB 9件・Service Mapping・Discovery・MID・LEAP ほか）
アラートの条件で自動で動く経路：トリガーではなくアラート管理ルールが起動し、動くのは自動の1つのワークフロー（アラートを自律的に管理）
結果は3種類。回答・調査を表示するだけ（CMDB の検索・データモデル・影響評価など7つ）／作業メモとインサイトに保存（変更・アラートの影響分析）／記録・設定・機器を変更（CI 作成・主要クラス・MID 再鍵・修復実行）
人の承認のあとに書き込むツールは、OOTB に該当なし
確認の範囲と、確認しなかったこと
CIの作成・主要クラスの変更・MID Serverの再鍵・アラートの自動化ルールの作成は、本番に近い設定を書き換える操作です。そのため実行していません。画面操作は、ワークフローの定義・トリガー一覧・AIエージェントのツール一覧の読み取りにとどめました。
定義画面の見方
AI Agent Studioでワークフローを開くと、左側に「主要な要件を定義」「セキュリティコントロール」「トリガーを追加」「チャネルとステータスを選択」の4つが並びます。この記事で使うのは次の2か所です。
トリガーを追加：AI Agent Studio上のトリガーの一覧。行があれば自動で動く条件が定義されている
ツールと情報を追加：ツールごとの実行モードが並ぶ。自律ならそのまま実行、監視中なら実行前に人の承認で止まる
この環境の画面は、どちらも読み取り専用の表示でした。
AI Agent「Manage alerts autonomously」の検証
アラートを自律的に管理するワークフローは、アラートの振り分け・影響の分析・原因の調査をまとめて行い、結果を1つのレポートとしてアラートに保存します。一覧の中で、自動で動く設計になっているのはこの1件だけです。まずトリガーの画面を開きました。
①の「トリガーを追加」の表は、②の列見出しだけで、③のとおり行がありません。自動で動くと説明されているワークフローなのに、AI Agent Studioのトリガーは0件です。
公式ドキュメントは、このワークフローを起動するのはアラート管理ルールだと説明しています。
When the workflow operates automatically, alerts are addressed as they're created and AI insight information is displayed in Express List.
（訳：自動で動かす場合、アラートは作成された時点で処理され、AIインサイトがExpress Listに表示されます）
実機でも、有効なアラート管理ルール「Autonomous Workflow」が1件ありました。説明は「OOB Rule: Execute Autonomous Workflow for AI Insights」で、対象の絞り込み条件にはアラートの状態がOpenであることなどが入っています。プロパティ sn_aiops_ai_agents.autonomous_alert_rule_sys_id が、このルールを指しています。このルールが実際にアラートで動いたかどうかは、確かめていません。
引用元：<https://www.servicenow.com/docs/r/it-operations-management/event-management/configure-manage-alerts-autonomously-workflow.html>
ツールは2つです。
①のAutonomous chainは、説明によるとトリアージ・影響・オブザーバビリティ・調査・要約を一気に実行します。②のUpdate Alert AI Insights and Worknotesは、結果をアラートのAIインサイトの表と作業メモに書き込みます。どちらもツールの実行モードは自律です。ルールが有効な環境では、条件に合うアラートの作業メモが、人の承認なしに更新される設計になります。
AI Agent「Create configuration item」の検証
CIを作成するワークフローは、CMDB CI クリエーターAIエージェントが最初に動く部分です。公式ドキュメントでは、作成するクラスを特定し、CI作成ツールを実行し、会話を締める3段階の流れと説明されています。
①のCreate new record for CI classは、既存のクラスにCIを作るツールで、ツールの実行モードは自律です。説明には、previewをtrueにして呼ぶと、CIを作らずに必須項目がそろっているかだけを確認できるとあります。②のGet similar CI Classes with attributes for creationは、名前の一部からクラスを探し、必須属性を返す読み取り用のツールです。
プレビューの仕組みがツールにあるため、本番で使う前に、プレビューで止まるように指示文を整える設計が考えられます。ただし今回は指示文を変更しておらず、プレビューを挟んでからCIが作られるかは確かめていません。
AI Agent「MID Guardian Workflow」の検証
MID Guardianのワークフローは、利用者が選んだ問題に応じて、4つの専門エージェントへ振り分けます。keystore・network・common・upgradeの4つで、定義の上では、keystoreのエージェントが最も多い8個のツールを持っています。
①のRekey a MID serverは、MID Serverの再鍵を起動するツールで、ツールの実行モードは自律です。②のValidate/Invalidate a MID serverも自律で、検証と無効化を起動できます。③のサブフローは、再鍵や検証が終わったかを最大2分待って確かめる役割です。MID Serverはインスタンスと外部のシステムとの接続を担います。そのため、再鍵・無効化を会話から起動できる設計では、依頼できる人を絞ることが前提になります。
手動で動かす17件と、ルールで動く1件
18件は、起動のきっかけで2つに分かれます。
手動で依頼する17件：AI Agent Studioのトリガーが0件。CMDB 9件、Service Mapping、Observability、AIOpsのアラート自動化の作成、Discovery 3件、MID Guardian、LEAP
ルールで自動で動く1件：Manage alerts autonomously。アラート管理ルールが起動する
手動の17件は、担当者の画面からの起動を確かめていません。公式ドキュメントは、Analyze alert impactの利用画面にOtto パネルを挙げ、AI Agent Studioの保存してテストでも動かせると説明しています。どの画面から呼ぶかは、有効化の前に担当者の画面で確認する項目です。
公式ドキュメントは「複製して調整する」と説明している
アラートを自律的に管理するワークフローの公式ドキュメントは、設定を変えるときの手順を次のように書いています。
To modify the workflow, you must duplicate it and adjust the settings according to your requirements.
（訳：ワークフローを変更するには、複製して要件に合わせて設定を調整します）
引用元：<https://www.servicenow.com/docs/r/it-operations-management/event-management/itom-autonomous-operator-workflow.html>
Analyze alert impactについて、公式ドキュメントは「既定で有効」と書いています。一方で、オブザーバビリティのエージェントには追加の設定が要るとも説明しています。実機でも、18件のうち16件に有効化の上書きがありました。Pattern Diagnostic WorkflowとCertificate Management Renewal Workflowの2件には上書きレコードが見つからず、実際に有効かどうかは未確認です。これらを使うなら、有効化の手順を先に確認します。
任せる範囲は、機能の種類ごとに決める
ここからは、試していない部分を含む筆者の推奨案です。判断の軸は、機能の種類ごとに、依頼できる人と書き込みの範囲に置きます。有効にする前に決めることは、種類ごとに次の表のとおりです。
表の内容を文字でも書き出します。
回答・調査を表示するだけの機能：例は Search CMDB（CMDB を検索）、Assess CMDB Impact（CMDB への影響の評価）。決めること＝質問できるロール、検索対象のクラス
調べた結果を作業メモに保存する機能：例は Analyze alert impact（アラートの影響度の分析）。決めること＝作業メモの閲覧範囲、保存の流れ
ルールで自動的に動いて保存する機能：例は Manage alerts autonomously（アラートを自律的に管理）。決めること＝ルールの対象条件、止め方、利用量
依頼を受けて記録・設定・機器を変更する機能：例は Create configuration item（構成アイテム (CI) を作成）、MID Guardian Workflow（MID ガーディアンワークフロー）。決めること＝依頼できるロール、変更範囲、取り消し手順
回答・調査を表示するだけの機能は、質問できる人と検索の対象を先に決める
Search CMDBやAssess CMDB Impactのように、ツールが読み取りだけの種類は、書き込みの影響が小さい分類です。ただしCMDBは、サーバーやネットワークの構成が集まる情報のため、誰が質問できるかを決める必要があります。例えばAssess CMDB Impactは、CIの関係をたどって影響を分類するため、見える範囲は依頼者の権限に合わせます。最初は検証用のクラスだけで試すのが候補です。
調べた結果を作業メモに保存する機能は、閲覧範囲と保存の流れを決める
Analyze Potential ImpactやAnalyze alert impactは、結果を変更要求やアラートの作業メモに保存します。書き換えるのは作業メモとAIインサイトです。ただし、障害の原因や影響範囲の推測が記録に残る点には注意が要ります。作業メモを読めるロールと、AIの出力を人が確認してから使う運用を、先に決めます。
ルールで自動的に動く機能は、条件・止め方・利用量を決める
Manage alerts autonomouslyのように、ルールで自動的に動く種類は、条件に合うアラートを自動で処理する設計です。処理の対象とタイミングは今回確かめていません。決めるのは、ルールの対象条件・止める手順・利用量の見込みです。止める手順の候補は、アラート管理ルールを無効にすることです。公式ドキュメントも、ルールを無効にするとワークフローも無効になると説明しています。今回は切り替えておらず、止まるかどうかは確かめていません。
依頼を受けて記録・設定・機器を変更する機能は、依頼できる人と変更の範囲を決める
CI作成・主要クラスの設定・MID Serverの再鍵・アラートの自動化ルールの作成のように、依頼を受けて記録や設定を変える種類は、ツールの実行モードが自律です。依頼できるロールを絞り、変更の対象を限り、取り消しの手順を用意します。実行モードを監視中へ切り替えれば、承認で止められる可能性があります。ただし今回は設定を変更しておらず、そうなるかは確かめていません。候補として、最初は検証用のクラスと検証用のMID Serverだけで試します。
導入前の確認リスト
回答・調査を表示するだけの機能
□ 質問できるロールが決まっている
□ 検索対象のクラスを決めた
調べた結果を作業メモに保存する機能
□ 作業メモを読めるロールが決まっている
□ AIの出力を人が確認してから使う手順がある
ルールで自動的に動く機能
□ アラート管理ルールの対象条件を確認した
□ 止める手順（ルールを無効にする）を共有した
□ 検証用のアラートで、1回試した
依頼を受けて記録・設定・機器を変更する機能
□ 依頼できるロールを絞った
□ 変更の対象と、取り消し手順を決めた
□ 検証用のクラス・MID Serverだけで、1回試した
実機で気づいたこと
監督対象と表示されていても、ツールは自律だった
ワークフローの実行モード（ワークフロー単位の設定）は、18件ともすべて「監督対象」でした。それでも、ツールの実行モード（ツール単位の設定）では、割り当て95件がすべて自律です。承認で止まる設計かどうかは、ワークフローの実行モードだけでは決まりません。ツールの実行モードで確かめます。execute_remediation_actionのツール説明には、承認が画面側で処理されるとあります。それでも、ツールの実行モードは自律のままでした。
書き込み・操作を伴うツールを、ワークフローごとに一覧で書き出します。
表の内容を文字でも書き出します。
Create configuration item（構成アイテム (CI) を作成）：Create new record for CI class。既存クラスにCIを作成。プレビュー指定で作成せず必須項目だけ確認できる
Provide advice on CMDB governance（CMDB ガバナンスに関するアドバイスを提供）：Mark CI class as principal、Unmark CI class as principal。CIクラスの主要クラス設定を付ける・外す
Create alert automation（アラートの自動化を作成）：Create、Delete、Activate Alerts Grouping Automation。グループ化の自動化ルールを作成・削除・有効化
MID Guardian Workflow（MID ガーディアンワークフロー）：Rekey a MID server、Validate/Invalidate a MID server。MID Serverの再鍵、検証・無効化を起動
Pattern Diagnostic Workflow（パターン診断ワークフロー）：execute_remediation_action。エラーに対する修復を実行
Firewall Management Task Creation Workflow（ファイアウォール構成エージェント）：Firewall Rule Task creation Subflow。ファイアウォールルールのタスクを作成
Analyze Potential Impact（想定される影響の分析）：Update Change Request Work Notes。変更要求の作業メモを更新
Analyze alert impact／Manage alerts autonomously：Save SRE Analysis、Update Alert AI Insights and Worknotes。アラートの作業メモとAIインサイトを保存
自動で動くのにトリガーが0件のワークフローがある
Manage alerts autonomouslyは、説明に「EM アラートの作成時にトリガーされる」とあります。一方で、AI Agent Studioのトリガーは0件で、起動するのはアラート管理ルールです。AI Agent Studioのトリガー一覧を見れば、自動で動く条件が分かる領域もあります。ITOMは、トリガー一覧が空でも自動で動く場合がある領域です。自動で動く条件を調べるときは、トリガーの一覧に加えて、アラート管理ルールとプロパティも確認します。
3つの領域で、確認する場所がそれぞれ違う
CMDBのワークフローは、依頼を受けてから動く手動の起動が中心です。ITOMのアラートは、ルールで自動的に動く構成です。Discoveryには、有効化の上書きがない2件が含まれます。起動のきっかけと有効化の記録の残り方が領域ごとに異なるため、有効化の前に、領域ごとの確認先を決めておきます。
用語
CMDB：構成管理データベース。サーバーやアプリケーションなどの構成アイテム（CI）を管理する
ITOM：IT Operations Management。アラート・Discovery・サービスマッピングなど、運用の可視化と自動化を扱う製品群
エージェント型ワークフロー：複数のAIエージェントをまとめ、目的に沿って手順を進める単位
ツールの実行モード：ツールごとの設定。監視中は実行前に承認を待ち、自律はそのまま実行する
ワークフローの実行モード：ワークフロー単位の設定。今回は18件とも「監督対象」。承認で止まるかはツールの実行モードで決まる
アラート管理ルール：条件に合うアラートに対して処理を実行するルール。自律ワークフローを起動する
付録：自分の環境で確認するときのURL
ワークフローの一覧：/sn_aia_usecase_list.do
トリガー：/sn_aia_trigger_configuration_list.do
有効化の状態：/sn_aia_usecase_config_override_list.do
ツールの実行モード：/sn_aia_agent_tool_m2m_list.do
アラート管理ルール：/em_alert_management_rule_list.do
公式ドキュメント（ServiceNow Docs）は次のとおりです。
検証範囲とおことわり
2026-10-02に、Australia（Patch 5）のNow Assistデモ環境で、日本語表示のみ確認しました。AI Agent Studioのワークフロー定義画面を3つ開き、トリガー・エージェント・ツールの実行モードを読み取りで確認しています。ほかの15件のワークフローの内容は、AI Agent Studioの定義データによる確認です。設定の変更と保存は0件で、既存のCIやアラートへの変更も0件です。
読み取り専用の CMDB Data Model Navigator Agent は、AI Agent Studio の手動テストから動かしました。この環境では質問への回答を得られなかったため、検証結果に含めていません。そのため、この記事にはワークフローを実行した結果がありません。検証の過程で作ったCI・実行計画・実行タスク・メッセージは削除済みです。生成 AI の呼び出しログと会話レコードの一部は REST から削除できず残っています（CMDBの内容は含みません）。
未確認のことは次のとおりです。
手動で依頼する17件を、担当者の画面からどう起動するか
アラート管理ルールが、実際のアラートで動いたかどうか
ツールの実行モードを監視中に切り替えた場合に、承認で止まるか
プレビューを挟んでからCIが作られるか
再鍵・検証を実際に起動した場合の挙動
英語表示での画面
有効化の上書きがない2件（Pattern Diagnostic Workflow、Certificate Management Renewal Workflow）の有効化の手順
