ITOM・AIOpsのNow Assist機能紹介とOOTBのまま使えるかの検証

2026年10月7日 07:53

検証環境：Now Assist デモ環境（Australia Patch 5）/ OOTB / 2026-10-02 確認
スキルは有効化済みの環境で確認しました。出荷時点の初期状態は検証していません。

有効化済みのスキルで試して分かったこと

ITOM・AIOps関連のNow Assistスキルは28行あり、この環境ではすべて有効
アラートの要約は、重大度・解決済みの状態・担当グループを書かず、一般的な調査手順に置き換わっていた
影響の欄は、同じ要約の中で、アラートによって内容が入るものと入らないものがあった
要約の生成ボタン（Analyze・再生成）は、要約の生成と、再生成での過去結果の削除を伴うため押していない

アラートを開くとNow Assistの要約が出ます。その要約が、元のアラートの項目とどれだけ合っているかを見比べました。

試行の規模は小さく、ケーススタディです。デモ環境のアラート2件を使い、主の1件は3回、副の1件は1回、画面で開いて確かめました。保存済みのAIインサイト4件も読み取っています。OOTB全体の品質評価ではなく、実装判断に必要な観点を洗い出す目的で確認しました。

ITOM・AIOpsのOOTBスキル一覧

この環境のITOM・AIOps関連スキルは28行です。ステータス表では28行すべてが有効でした。うち2行は、画面に直接出さない設定です。内訳は次のとおりです。

アラート支援（Alert Assist）：13行
外部監視ツール向け：5行（カタログ上は、上の13行と合わせた18行をAlert Assistと呼ぶ）
サービスマッピング：4行
サービスオブザーバビリティ：2行
SLO：1行
サービスグラフコネクタ診断：1行
ヘルスログ分析：2行

最初に使われるのは、アラートを開いたときに出る要約と影響の整理です。残りは、調査の材料集め、監視ツールからのレポート取得、サービスマッピングの候補づくりに使うスキルです。

表の内容を文字でも書き出します。

Alert analysis（アラートの要約）：有効。アラートを平易に要約する。保存済みの結果を画面で確認した
Summarize alert AI insights（AIインサイトの要約）：有効。生成済みのAIインサイトを要約する。保存済みの結果を確認した
Alert impact analysis（影響の整理）：有効。関連サービスへの影響を整理する。保存済みの結果を確認した
Alert investigation／Related Changes Analysis／KB Summarization（調査材料の収集）：有効。過去のインシデント・関連する変更・関連KB記事から材料を集める。画面は確認したが、結果は入っていなかった
Triage and investigate alerts／AI Investigation report for alert（一次対応と調査レポート）：有効。試していない
Alert Hypothesizer・Alert Remediation Subflow Ranking・Proactive grouping evaluationほか（仮説・修復候補・グループ評価）：有効。合計5行で、内部用の構成を含む。試していない
Observability Skill 5件（New Relic・Datadog・Dynatrace・Kentik・Gemini）：有効。外部の監視ツールからレポートを取得して要約する。試していない
Service Mapping系4件（サービスマッピング候補・業務アプリの推定）：有効。試していない
Service Observability 2件・Generate Reliability Plan・Service Graph Connector diagnosis（健全性分析・SLO計画・コネクタ診断）：有効。試していない
HLA Auto Mapping・HLA AI Classification（ログ分析のマッピングと分類）：有効。試していない

有効でも、動かせるとは限りません。今回確かめたのは、アラートを開くと出る要約と影響の整理です。代表に選んだのは、ITOM担当者がアラートを開いて最初に目にする機能だからです。外部の監視ツールとの連携は契約や接続設定が要るため、動かしていません。

元にしたアラートには何が書かれていたか

要約を見る前に、元のアラートの中身を説明します。主に使ったのは、Azure Monitorから届いた重大なアラート（Alert0010011）です。メトリクス名とルール名は「Coffee inventory unavailable」で、対象は「Coffee Inventory Management」というサービスです。

アラートの項目から読み取れる事実は、次のとおりです。

重大度は重大（Azure側の表記はSev0）、状況はクローズ済み
条件は、1分間の窓でメトリクスが0.01を超えたこと。発生と解決の時刻が同じ
担当グループは①のSRE Shift 1。インシデントINC0018653が起票済み
影響を受けるサービスは1件（Coffee Inventory Management）

②の作業メモは、2026-07-26にAIOps Agentが書いたものです。今回の操作で作ったものではありません。

副に使ったAlert0010010は、社内の自己監視アラートです。説明に「4件のアラートが2日以上更新されていない」と書かれ、対象のアラート番号が4件並んでいます。もう1件、Alert0010008も調べましたが、比較には使いませんでした。説明の中のユーザー名が数時間おきに別の名前へ書き換わり続けており、要約を作った時点の説明と今の説明が一致しないためです。

判定の基準

「要約が出た」だけでは評価になりません。元のアラートの項目と見比べて、事実が合っているか、抜けや書き足しがあるかを見ます。判定の軸は、次の3つです。

重大度・状況（重大・解決済み）が書かれているか
担当グループ・起票済みインシデントが書かれているか
影響サービスが書かれているか

要約に必要な修正の量は、次の4段階で判定しました。

修正なし：文章を変えずに目的に使える
軽微：事実関係は変えず、語句や表現だけ直す
大幅：原因・状態・対応・結論など、業務判断に関わる内容の追加・削除・訂正が要る
不採用：元のアラートとの照らし合わせや全面的な書き直しが要り、下書きとしての効果が薄い

修正にかかった時間は計測していません。画面の操作では、生成・再生成・更新・保存のボタンを押していません。

Now Assist「Alert analysis」の検証

Alert analysis（アラートの要約）は、アラートを平易に要約して調査を始める手がかりを作るスキルです。サービスオペレーションワークスペースでアラートを開くと、概要タブのサマリーに「Overview」のカードが出ます。公式ドキュメントでは、Express Listのプレビューで［Analyze］を押す方法と、Now Assistパネルにアラート番号を入れて依頼する方法が案内されています。

今回の画面は、どちらも押さずに開くだけで要約が出ました。要約はAIOps Agentが2026-07-26に生成して保存した結果で、開くたびに生成し直しているわけではありません。3回開いて本文は同一でした。画面の作業メモでは、概要カードの文は「Alert Reports Summarization」、別の作業メモは「Alert analysis」と見出しが付いています。スキル名との対応は、この見出しからの推定です。表示までの所要時間は、ページを開いてから7.8〜25.0秒でした。

①の項目と、②の要約本文を見比べます。

重大度・状況（重大・解決済み）：要約に書かれていない。「potential disruption」と、将来の可能性として書いている
担当グループ・起票済みインシデント：書かれていない
影響サービス：要約の影響の欄は入っておらず、内部の保存データも「no_data」
書き足し：要約はセンサーやスキャナーなどのハードウェアの確認を勧めている。アラートのどこにも、ハードウェアの記述はない
手順：ステータスの確認、ログの確認、最近の変更の確認と、どのアラートにも当てはまる一般的な内容

起点は元のアラートの項目、緑は元のアラートにある事実、赤は要約から落ちた項目、橙は要約に書き足された内容。灰色は元のアラートに記述がない項目

図の内容を文字でも書き出します。

重大度・状況：元は「重大（Sev0）・クローズ済み」。要約には書かれておらず、「potential disruption」と将来の可能性として書く
担当・起票：元は「担当グループ SRE Shift 1・INC0018653 起票済み」。要約には書かれていない
影響サービス：元は1件（Coffee Inventory Management）。要約の影響の欄は空（保存データは no_data）
ハードウェア：元に記述なし。要約はセンサーやスキャナーの確認を勧める（書き足し）
手順：元に記述なし。要約はステータス・ログ・最近の変更の確認を挙げる（どのアラートにも当てはまる内容）

判定は大幅です。意味が間違っているわけではありませんが、元のアラートが持つ判断材料（重大・解決済み・担当・影響）が落ち、書き足しが入っています。引き継ぎ資料として使うには、元の項目から書き直す必要があります。

画面の言語は日本語ですが、要約は英語でした。アラートの本文が英語だったためと考えられますが、言語の決まり方は確かめていません。調査材料の収集に当たるAlert investigationは、保存データが「no_data」で、担当グループも原因候補も空でした。

Now Assist「Alert impact analysis」の検証

Alert impact analysis（影響の整理）は、アラートが関連するサービスへ与える影響を整理するスキルです。アラートの要約カードにある「Impact」の欄に出ます。副のAlert0010010で見ると、次のとおりでした。

①の題名と説明には「4件のアラートが2日以上更新されていない」と書かれ、アラート番号も4件並んでいる
②の要約は「alert updates oversight」とだけ書き、件数と番号を落としていた
③の影響は「サービスインスタンス1件とオファリング1件」、次の手順は4つ。手順は「状態を確認する」「ログを確認する」と一般的な内容

影響の欄は、アラートによって入るものと入らないものがありました。Alert0010010では入り、主のAlert0010011では空でした。主のアラートには影響を受けるサービスが1件あるのに空だったため、欠落の可能性があります。保存データでは、0010008〜0010010の3件に影響が入り、主の0010011だけが「no_data」でした。

この影響の中身（サービスインスタンスやオファリングが実際に関連しているか）は、サービスのマッピング情報と照らし合わせていません。判定は、Alert0010010の要約が大幅、影響の欄は未確認です。

有効でも画面に出ない・動かさなかったもの

正規の使い方で表示できたものを先に紹介しました。ここからは、有効にしてあっても条件が要るものです。

Express Listの［Analyze］：押すと要約が生成される。公式ドキュメントでは、再生成すると過去の結果が削除されると書かれている。保存済みの結果を残すため、押していない
［Update description］：AIの要約でアラートの説明を上書きする。押していない
従来のフォーム画面：Alert0010011を開いても、AIの要約カードは出なかった。要約はサービスオペレーションワークスペースの画面にある
Observabilityの各スキル：保存データは「Not a supported alert type」。対象外のアラート種別と表示されたもので、外部ツールを使った取得は行われていない
要約を自動で保存するAI エージェント：今回の4件のインサイトは、作成者がAIOps Agent。設定や起動の条件は確認していない

導入前に、アラート担当者が使う画面を決めます。サービスオペレーションワークスペースで運用するのか、従来のフォームで運用するのかで、AIの要約の見え方が変わります。

OOTBスキルは3つの動き方に仕分けられる

結果を、機能の種類で仕分けます。Aは表示するだけの種類、Bは操作して記録に書き込む種類、Cはトリガーで自動的に書き込む種類です。Dは、今回は判断できなかった範囲です。

A. 保存済みの結果を表示するだけの機能

アラートの要約、AIインサイトの要約、影響の整理が当たります。開くだけで表示され、今回の確認では書き込みは見つかりません。例えば今回のAlert analysisは、保存済みの要約を3回とも同じ文面で表示しました。使うなら、元の項目と照らし合わせる運用が要ります。

B. 操作して、記録に書き込む機能

Express Listの［Analyze］や［Update description］が当たります。ボタンを押すと、結果の保存や説明の上書きが起きます。今回は書き込みを避けて動かしていません。使うなら、再生成で過去の結果が消えることを前提に運用を決めます。

C. トリガーで自動的に書き込む機能

保存済みの4件のインサイトを作った仕組みが当たります。保存データの作成者はAIOps Agentです。生成の経路と起動条件は確認していません。

D. 今回は判断できなかった機能

調査と対応の自動化、外部監視ツール連携、サービスマッピングが当たります。サービスオブザーバビリティ、SLO、ヘルスログ分析も同じです。動かしていないため、判断を保留します。

その不足は本当にカスタマイズ対象か

見えた不足を、データ・標準設定・運用・カスタマイズの順に切り分けます。

データ

主のアラートは、重大度と担当グループを持っていました。要約がそれを書かなかったのは、入力として渡されていないのか、渡されても使われていないのかが分かりません。影響の欄が空だった原因も、保存データが空のためデータ側の可能性があります。どちらも確かめていません。

標準設定

ITOM向けのNow Assistのプラグイン（ServiceNow Otto for ITOM）とAIOps Experienceのアプリが前提（公式ドキュメント）
アラートの要約を操作するロールは、公式ドキュメントでは evt_mgmt_operator
自動で要約を作る設定は、公式ドキュメントのmanage alerts autonomouslyの構成で案内されている

運用（レビュー）

要約を引き継ぎや報告に使う前に、次の順で確認します。

重大度・状況を元のアラートの項目で確認する
担当グループ・起票済みインシデントを元の項目で確認する
影響サービスを関連レコードのタブで確認する
書き足された内容（ハードウェアの確認など）が、アラートに根拠のあるものか見る

カスタマイズ（コピーしてからの変更）

要約に重大度や担当グループを含めたい場合は、対象スキルで使える変更手段を調べます。コピーや指示の変更ができるか、含められるかは、今回確かめていません。

カスタム化して増える管理対象

OOTBのスキルにも、品質確認・利用量確認・レビュー・アップグレード後の挙動確認は元々要ります。コピーを持つと、その上に次が増えます。

構成管理：コピーした指示と入力項目を記録する
プロンプトの変更履歴：追加した指示をいつ・誰がなぜ入れたか残す
回帰試験：アップグレードのたびに、代表的なアラートで出力を確かめ直す
差分の確認：OOTB版が更新されたとき、コピー版との差を見る

お客様への提案を3層に分ける

ITOM・AIOpsのNow Assistの提案は、次の3層に分けて出せます。

OOTB：保存済みの要約・影響の整理の表示（開くだけ。書き込みなし）
標準設定・運用：使う画面の決定、要約と元の項目の照らし合わせ、［Analyze］の使い方（再生成で過去の結果が消える）、自動要約の起動条件の確認
個別開発：要約へ重大度や担当グループを固定で入れるなど、運用を重ねても繰り返し不足するものだけ（コピーや指示の変更ができるかを先に確認する）

導入の順は、アラートへの関わり方で決めます。保存済みの結果を表示する機能は、使う画面を決め、照らし合わせの運用が回るかを確かめてから始めるのが先です。記録に書き込む機能は、書き込みの影響範囲と戻し方を決めてから広げます。

まとめ

アラートの要約は、主の1件を3回、副の1件を1回、画面で確かめました。主のアラートは、重大度・解決済み・担当グループ・影響サービスのどれも要約に出ていません。副のアラートは、題名の「4件」が要約から落ちました。影響の欄は、アラートごとに入ったり入らなかったりします。

生成ボタンは押していないため、押したときの動きは未確認です。デモ環境のアラート2件では、カスタム開発に進むべきかは判断できません。データ・標準設定・運用を切り分け、それでも繰り返す不足だけを開発要件にします。

付録

用語

スキル：Now Assistの機能の単位。それぞれ独立して有効・無効を持つ
SOW（Service Operations Workspace）：ITOM・ITSMの担当者向けワークスペース
Express List：サービスオペレーションワークスペースで、アクティブなアラートを一覧する画面
AIインサイト：アラートごとにAIが作った要約や影響などの保存データ（sn_aiops_alert_ai_insightテーブル）

製品名は公式ドキュメント上ではServiceNow Ottoですが、画面の見出しやボタン名の多くはNow Assistのままです。この記事は画面の表記に合わせます。

使ったレコード

アラートAlert0010011（主）とAlert0010010（副）です。どちらもデモ環境のレコードで、状況はクローズ済みです。変更・確認・クローズ・インシデント作成は行っていません。画面を開く前後で、AIインサイト4件の更新日時、アラートの更新状況、直近の生成ログの件数が変わっていないことを確かめました。

試行の規模

Alert0010011：画面を3回開き、要約本文は3回とも同一
Alert0010010：画面を1回開いた
保存済みのAIインサイト4件の内容を読み取り（Alert0010008〜0010011）
比較に使わなかったレコード：Alert0010008（説明が数時間おきに書き換わるため）

所要時間

要約の表示：ページを開いてからカードが出るまで7.8〜25.0秒（3回）。画面のログイン・読み込みの時間を含む

到達しなかった機能

Express Listの［Analyze］・［Update description］：書き込みを伴うため押していない
Observability系・Service Mapping系・Service Observability系・SLO・HLA：今回は対象外
自動で要約を作るAI エージェントの設定：起動条件を確認していない

ライセンス

製品には、スキルごとにサブスクリプションのプロファイルIDが登録されています。今回のスキルが紐づく区分は確認していません。契約範囲は契約書で確認します。公式ドキュメントでは、利用するアプリ機能・スキルは契約のティアで変わると案内されています。

自分の環境で確認するときのURL

ITOM・AIOps関連スキルのステータス：/sn_nowassist_skill_config_status_list.do
保存済みのAIインサイト：/sn_aiops_alert_ai_insight_list.do
アラート：/em_alert_list.do

確認した公式ドキュメントのページは、次のとおりです。

実機を見て気づいたこと

要約が元のアラートの重大度と担当を落とす

Alert0010011は重大で、担当グループも決まっていました。要約はどちらにも触れず、一般的な調査手順になっていました。要約を引き継ぎに使うなら、重大度と担当は元の項目で読みます。

影響の欄が、アラートによって空になる

影響を受けるサービスが1件あるアラートで、保存データの影響が空でした。影響の欄が空のときは、関連レコードで影響サービスを確認します。

画面を開くだけでは書き込みは起きない

3回開いても、保存済みのインサイトの更新日時は変わりませんでした。今回は再生成のボタンを押していないため、押したときの動きは確かめていません。公式ドキュメントでは、再生成すると過去の結果が削除されると書かれているため、運用では押す人と条件を決めます。

検証範囲とおことわり

2026-10-02に、Australia（Patch 5）のNow Assistデモ環境で確認しました。アラートはデモ環境の2件で、画面は主を3回、副を1回開きました。生成・再生成・更新・保存は押していません。未確認のことは、次のとおりです。

［Analyze］で新しく生成した要約の内容と、再生成で過去の結果が消える動き
要約が重大度や担当グループを書かない原因（入力・設定・スキルのどれか）
影響の欄が空になる条件
影響の中身（サービスインスタンス・オファリング）の正しさ
個別スキルと画面の表示の対応（生成ログのテーブルでは突き合わせていない）
自動で要約を作る仕組みの起動条件
外部監視ツール連携・サービスマッピングなど、動かしていないスキルの動作
利用量が、契約上の課金にどう跳ね返るか