メインコンテンツへスキップ
見出し画像

セキュリティ・リスク(SecOps・GRC)のNow AssistとAIエージェント:機能紹介と代表機能の動作確認


    セキュリティインシデントやリスクの記録を生成AIに読ませてよいのか。ホストの隔離やメール削除のような操作までAIに任せてよいのか。有効にする前に、セキュリティ運用やGRCの担当者が最初に迷う点です。

    標準の定義を数えると、ワークフロー12件はすべて人の承認が入る設定でした。一方で、エージェントに割り当てたツール70件のうち67件は、承認なしで進む設定です。ホストの隔離やメール送信もこの67件に入ります。有効にする前に決めるのは、AIに渡すデータ、承認なしで動くツールの範囲、使えるロールの3点です。

    一覧にしたのは、SecOps(セキュリティ運用・脆弱性対応)とGRC(ガバナンス・リスク・コンプライアンス)の標準(OOTB)の定義です。代表として、セキュリティインシデントの要約スキルを1つだけ実際に動かしました。

    検証環境:Now Assist デモ環境(Australia Patch 5)/ 2026-10-02 確認
    定義の一覧が中心です。実行したのは Security Incident summarization の1つで、自作のテスト用セキュリティインシデント1件に2回かけました。ほかのスキルとエージェントは実行しておらず、既存のセキュリティインシデントやリスクのレコードは読んでいません。

    押さえておくこと

    • 標準のスキルは30件、エージェント型ワークフロー(以下、ワークフロー)は12件、AI エージェントは21件

    • ワークフロー単位の実行モードは12件すべて Supervised(人の承認が入る設定)

    • ツール単位は、エージェントに割り当てた70件のうち67件が Autonomous(承認なしで進む設定)。ホストの隔離やメール送信もここに入る

    • 代表の1つとして要約スキルを動かすと、30秒前後で要約が出た。ただし、要約の「実行された主なアクション」には、記録に無い行動が書かれた

    • 有効にする前に決めるのは、AI に渡すデータ、承認なしで動くツールの範囲、使えるロールの3点


    画像

    起点はOtto パネルとレコード画面、青はスキル・ワークフロー・エージェント、緑は画面に表示するだけの結果、橙は人の承認が入るツール、赤は承認なしで実行されるツール、灰色は起動のきっかけが未確認のエージェント

    ワークフローとツールの対応は、メンバーとして読めたエージェントの範囲で描いています。

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

    • 起点は ServiceNow Otto パネル(質問・候補の選択)とレコード画面・Workspace(ボタンやメニュー)

    • スキル30件(要約・生成・分析)と、12件のワークフロー(SOC 4件・脆弱性 4件・規制・リスク・問題 4件)につながる

    • 結果は3種類:回答や下書きを画面に表示(記録は変わらない)/人の承認が入るツール3件(誤検知としてクローズ・ブロック要求・メール削除)/承認設定のないツール67件(ホスト隔離・メール送信・状態更新・レコード作成など)

    • ワークフローへの所属が読めなかったエージェント(EDR・Exchange・アクティビティ処理ほか)は、起動のきっかけが未確認

    承認で止まるツールの実物は、SIR のクローズを担うエージェントの画面で確かめられます。セキュリティインシデント最終作業ジェネレーター AI エージェントには5つのスクリプトがあります。実行モードが「監視中」なのは Close security incident as false positive の1つで、残る4つは自律です。


    画像

    標準で入っているスキル、ワークフロー、エージェントの一覧

    対象は、カタログ上の Security Operations と Risk & Sustainability です。前者には SIR(セキュリティインシデント対応)、VR(脆弱性対応)、USEM(統合エクスポージャー管理)が入ります。後者には IRM、TPRM ほかが入ります。

    AI エージェントとワークフローは、パッケージ名から筆者がまとめた「セキュリティ・リスク」の区分で数えました。製品の正式な分類とは別のものです。

    OOTB の判定は姉妹記事(Now Assist は標準で何が入っている? 製品別のOOTBスキル一覧)と同じで、デモ側で追加したものと、出荷物か判定できなかったものは除いています。SIR では、判定できなかったエージェント4件とツール9件が一覧に入っていません。SIR の定義は、実際にはもう少し多い可能性があります。

    英語名が製品の正式名で、括弧内の日本語は、製品に日本語の表示名があるものはそれ、無いものは筆者の訳です。

    スキル

    スキルは、要約・生成・分析のように1回の呼び出しで結果を返す部品です。30件は、分析者の作業で5つに分けられます。


    画像

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

    • インシデントの状況を把握する(SIR):5件。5件とも有効

    • 対応を進めて記録を残す(SIR):5件。5件とも有効

    • 脆弱性を整理して優先を付ける(VR・USEM):5件。有効4、有効(非表示)1

    • 規制変更の影響を探す(IRM):5件。有効1、有効(非表示)4

    • コントロール・リスク・問題を整える(IRM・TPRM ほか):10件。10件とも有効

    有効(非表示)は、スキルの有効フラグは立っていて、製品内の表示フラグが立っていない状態です。

    インシデントの状況を把握する

    • Security Incident summarization(セキュリティインシデントの要約):説明、作業メモ、影響を受けるユーザー、CI、観測事象から要約を作る

    • Correlation insights generation(相関インサイトの生成):影響を受けるユーザー、CI、観測事象を手がかりに、過去のセキュリティインシデント、インシデント、変更、問題、脆弱性一致アイテムと結び付ける

    • Security Incident Quality Assessment(セキュリティインシデントの品質アセスメント):自然言語で書いた品質ルールに沿って、品質レポートを作る

    • Natural Language Condition Evaluator(自然言語条件の評価):自然言語の条件ごとに true か false を、理由とともに返す

    • Security operations metrics analysis(セキュリティオペレーションのメトリクス分析):MTTR や MTTA などの指標を分析する。公式の記述では、AI エージェントと組み合わせて使う

    対応を進めて記録を残す

    • Security incident recommended actions(セキュリティインシデントの推奨アクション):解決に向けて次に取るべき行動を提案する

    • Security incident resolution plan(セキュリティインシデントの解決計画):インシデントの詳細、ナレッジ記事、過去の類似インシデントから解決計画を作る

    • Generate content for shift handover(シフト引き継ぎ内容の生成):引き継ぎレポートの各セクションの文面を作る

    • Resolution notes generation(解決メモの生成):インシデントの文脈から解決メモを作る

    • Post incident analysis(インシデント事後分析):根本原因、影響度、得られた教訓の評価を助ける

    脆弱性を整理して優先を付ける

    • Recommend preferred solution for VIT(脆弱性一致アイテムの推奨ソリューション):優先ソリューションが複数あるときに、最適な1つを推奨する

    • Vulnerable item deduplication(脆弱性一致アイテムの重複排除):複数のスキャナーが作った重複を識別してグループにする

    • Approval Recommendation(承認の推奨):承認要求に対して承認か却下かを推奨する

    • SEM Insights skill(SEM インサイト):エクスポージャー管理のダッシュボードと集計結果を分析し、所見と修復のインサイトを示す。有効(非表示)

    • SPC Setup Connector(SPC セットアップコネクター):新しい SPC コネクターの設定を作る作業を速める、管理者向けのスキル

    規制変更の影響を探す

    • Regulatory alert summarization(規制アラートの要約):期限や必要な対応を強調した要約を作る

    • Regulatory alert impacted citations(影響を受ける引用):規制変更に関連する引用を特定する。有効(非表示)

    • Regulatory alert impacted policies(影響を受けるポリシー):関連するポリシーを特定する。有効(非表示)

    • Regulatory alert impacted control objectives(影響を受けるコントロール目標):関連するコントロール目標を特定する。有効(非表示)

    • Regulatory alert impacted controls(影響を受けるコントロール):関連するコントロール目標とコントロールを特定する。有効(非表示)

    コントロール・リスク・問題を整える

    • Common control objective creation(共通コントロール目標の作成):コントロール目標のリストを見直して共通の目標を提案する

    • Control Objective Impact Analyzer(コントロール目標の影響分析):変更された引用の内容から、見直しが必要なコントロール目標を特定する

    • Recommendation for similar control objectives(類似コントロール目標の推奨):重複する目標の整理を提案する

    • Risk Assessment Summarization(リスクアセスメントの要約):固有・残存・ターゲットリスクとコントロールの有効性から要約を作る

    • Risk Event Summarization(リスクイベントの要約):リスクイベントの要約を作る

    • Smart Assessment Response Assist(スマートアセスメントの回答支援):回答を必要な質問タイプと形式に変換する

    • GRC Case summarisation(GRC ケースの要約):タスクレコードの要約を作る

    • Issue Summarization(問題の要約):顧客向けの問題レコードの要約を作る

    • TPRM Issue Summarization(サードパーティリスクの問題の要約):サードパーティリスクの問題レコードの要約を作る

    • TPRM Issue Recommendation(サードパーティリスクの問題の推奨):説明は空で、名前から推奨を生成するスキルと読める

    このほかに、説明が空で名前に NACM を含むスキルが3件あります。Risk Asmt Submit Modal、Risk Asmt Homepage、Quality Assessment Report NACM です。画面側の設定用の部品と読めるため、30件には含めていません。

    SIR のスキルの起動場所は、公式の記述では次のとおりです。

    • 要約と解決メモ:セキュリティインシデントのレコード、SIR Workspace、Otto パネル

    • 推奨アクションと事後分析:レコードと Workspace

    ワークフロー

    ワークフローは、利用者が起動する単位で、メンバーのエージェントがツールを呼んで作業します。12件のうち有効と確認できたのは3件で、残る9件は有効状態を読めませんでした。


    画像

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

    • Resolve security incident(セキュリティインシデントを解決):SIR。状態不明。読めたメンバー2

    • Wrap up security incident(セキュリティインシデントのクローズ):SIR。状態不明。メンバーは読めず

    • Generate SIR Shift Handover Report(SIR シフト引き継ぎレポートの生成):SIR。有効。メンバーは読めず

    • Analyze security operations metrics(セキュリティオペレーションの測定基準を分析する):SIR。状態不明。読めたメンバー2

    • Security Exposure 360:USEM。状態不明。読めたメンバー1

    • Retrieve VR data(VR データの取得):VR。状態不明。メンバーは読めず

    • Assess vulnerability exposure(脆弱性エクスポージャーの評価):VR。状態不明。読めたメンバー1

    • Analyze vulnerability remediation status(脆弱性の修復状況の分析):VR。状態不明。メンバーは読めず

    • Get Regulatory Analysis(規制分析を取得):IRM。有効。読めたメンバー2

    • Generate Regulatory Action Plan(規制アクションプランを生成):IRM。有効。読めたメンバー1

    • Suggest potential risks(潜在的なリスクの提案):GRC。状態不明。メンバーは読めず

    • Optimize GRC issue resolution(GRC 問題解決の最適化):GRC。状態不明。読めたメンバー1

    12件の実行モードは、すべて Supervised です。トリガー(レコードの更新などで自動起動する設定)は、12件とも0件でした。自動起動の設定は無く、パネルなどからの起動が前提と考えられます。実際の起動方法は確かめていません。

    SOC のワークフロー

    • Resolve security incident(セキュリティインシデントを解決):ナレッジ記事と過去の類似インシデントから計画を作り、段階的に実行する。公式の記述では、Otto パネルで操作し、必要なロールは sn_si.analyst。観察事項の分析では脅威検索を行い、アナリストが肯定したあとにサマリーを出す

    • Wrap up security incident(セキュリティインシデントのクローズ):クローズ前の検証、検証エラーの通知、クローズメモと事後分析の生成、クローズまでを行う

    • Generate SIR Shift Handover Report(SIR シフト引き継ぎレポートの生成):セキュリティインシデントの詳細を、シフト引き継ぎレコードに追加する

    • Analyze security operations metrics(セキュリティオペレーションの測定基準を分析する):SOC マネージャーがアナリストの直近の指標を分析する。公式の記述では、必要なロールは sn_si.manager。実装済みの指標は、セキュリティインシデントの量、MTTA、MTTR

    脆弱性のワークフロー

    • Security Exposure 360:USEM の統合ワークフロー。専門のエージェントに依頼を振り分ける。現在のメンバーは、ライブデータを分析する Data analysis agent。公式の記述では、Otto パネルから自然言語で質問し、必要なロールは sn_vul.vulnerability_analyst か sn_vul.vulnerability_admin

    • Retrieve VR data(VR データの取得):テーブルのクエリを組み立てて実行し、脆弱性対応のデータへの質問に答える

    • Assess vulnerability exposure(脆弱性エクスポージャーの評価):ビジネスサービスと CI の脆弱性エクスポージャーを評価し、CISA の悪用が確認された脆弱性もチェックする。監視トピックの作成のような操作も行える

    • Analyze vulnerability remediation status(脆弱性の修復状況の分析):脆弱性一致アイテムの修復ターゲット日のコンプライアンス指標と統計を示す

    規制・リスク・問題のワークフロー

    • Get Regulatory Analysis(規制分析を取得):規制アラートを分析し、Web 検索で文脈を足し、内部の引用、ポリシー、コントロール目標への影響を推奨する。公式の記述では、規制アラート画面の Ask ServiceNow Otto メニューか、Otto パネルから使う

    • Generate Regulatory Action Plan(規制アクションプランを生成):過去の類似アラートと影響領域から、変更タスクとアクションタスクを作る

    • Suggest potential risks(潜在的なリスクの提案):ユーザーが示した情報、内部のエンティティデータ、外部ソースを組み合わせて、リスクの特定・評価・優先付けを支援する

    • Optimize GRC issue resolution(GRC 問題解決の最適化):過去の問題からアクションプランを作り、承認されたら問題レコードに保存する。依頼に応じて修復タスクの提案と作成も行う。公式の記述では、必要なロールは sn_grc_genai.issue_user か sn_irm_gen_ai.user

    規制分析を取得ワークフローの定義画面では、メンバーとして規制アラートの推奨事項エージェントと規制アラート拡張エージェントの2つが登録されています。どちらもアクティブです。


    画像

    AI エージェント

    エージェントは、ツールを使って実際の操作を行う部品です。21件のうち、エージェント構成の有効フラグが true なのは18件で、false の無効は3件でした。無効の3件は次のとおりです。

    • Vulnerability exposure analysis AI agent

    • VR data retrieval agent

    • Remediation compliance analysis AI Agent

    いずれも VR のワークフローのメンバーに入っています。


    画像

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

    • SIR(セキュリティインシデント):エージェント9、ツール30、うち Supervised 3

    • VR・USEM(脆弱性):エージェント3、ツール10、Supervised 0

    • IRM(規制変更):エージェント3、ツール8、Supervised 0

    • GRC(問題・リスク・コントロール):エージェント5、ツール20、Supervised 0

    • AI Control Tower(AICT):エージェント1、ツール2、Supervised 0

    • 合計:エージェント21、ツール70、Supervised 3

    エージェントごとのツール数と、Supervised のツール名は次のとおりです。

    • AICT Security Analyzer Agent(AICT セキュリティアナライザーエージェント):AI セキュリティイベントの文脈を作り、脅威を評価する。ツール2件

    • EDR Agent(EDR エージェント):セキュリティインシデントに関連する CI のホスト情報を取得し、ホストを隔離する。ツール2件

    • Exchange online integration handling AI agent(Exchange Online 統合を処理する AI エージェント):メールサーバーでメールを検索し、削除する。ツール4件、うち Delete email from server が Supervised

    • Observable analysis AI agent(観察事項分析 AI エージェント):観察事項を分析し、サマリーを作る。ツール6件、うち Run block request が Supervised

    • Security incident activities handling AI agent(セキュリティインシデントアクティビティを処理する AI エージェント):インシデント、問題、変更要求、SIR タスクを処理する。ツール4件(Update incident state、Send email など)

    • Security incident resolution AI agent(セキュリティインシデント解決 AI エージェント):解決計画を探す。ツール1件

    • Security incident retrieval AI agent(セキュリティインシデント取得 AI エージェント):条件に合うセキュリティインシデントを取得する。ツール2件

    • Security incident shift handover AI Agent(セキュリティインシデントシフト引き継ぎ AI エージェント):引き継ぎレポートに追加する。ツール3件

    • Security incident wrap up generator AI agent(セキュリティインシデント最終作業ジェネレーター AI エージェント):クローズ前の検証、クローズメモ、事後分析、状態更新を行う。ツール5件、うち Close security incident as false positive が Supervised

    • Security metrics analysis AI agent(セキュリティ測定基準分析 AI エージェント):チームと期間を指定して、件数と MTTA、MTTR を計算する。ツール3件

    • VR data retrieval agent(VR データ取得エージェント):脆弱性対応のデータへの質問に答える。ツール1件

    • Vulnerability exposure analysis AI agent(脆弱性エクスポージャー分析 AI エージェント):ビジネスサービスと CI のエクスポージャーを評価する。ツール6件(Create a watch topic など)。無効

    • Remediation compliance analysis AI Agent(修復コンプライアンス分析 AI エージェント):修復ターゲットの達成状況を統計で示す。ツール3件

    • Regulatory alert recommendation agent(規制アラートの推奨事項エージェント):影響を受ける領域の推奨を作る。ツール2件

    • Regulatory alert enrichment agent(規制アラート拡張エージェント):Web 検索で規制アラートに文脈を足す。ツール2件

    • Regulatory change task planning agent(規制変更タスク計画立案エージェント):過去の類似アラートから変更タスクの計画を作る。ツール4件(Create records など)

    • Control Objective Change Agent(コントロール目標変更エージェント):説明と補足ガイダンスの更新要否を検証し、新しい値を推奨する。ツール5件(Update control objective details など)

    • Risk Suggestion AI Agent(リスク提案 AI エージェント):内部ソース、外部 Web データ、モデルの推論から、リスクを提案する。ツール7件(AIA Web Search、Create triage risk records など)

    • Report a GRC issue(GRC の問題を報告):履歴データで説明を補って、GRC の問題を作成する。ツール3件

    • Issue action plan AI agent(問題アクションプラン AI エージェント):過去の類似の問題から手順を示す。ツール3件(Save action plan など)

    • Remediation tasks AI agent(修復タスク AI エージェント):アクションプランから修復タスクを特定して作成する。ツール2件

    起動のきっかけと結果で見ると、機能は3種類に分かれる

    分析者の側から見ると、機能は結果の違いで3種類に分けられます。

    • 回答や下書きを画面に表示するだけの機能:スキルの大半と、Metrics、VR データ取得、Exposure 360 のようなワークフロー

    • 人の承認が入ってから記録を変える機能:公式の記述では、Resolve security incident は、アナリストが要約を承認してから、パスワードリセット用のインシデントや対応タスクを作る

    • 承認設定のないツールが操作する機能:ホストの隔離、メール送信、インシデント状態の更新など

    3種類目は、公式の記述にある承認とは別の層にあります。会話の中で確認を取る作りと、ツールに付ける Supervised の設定は、別の仕組みと考えられます。実際の動きは確かめていません。

    実機を見て気づいたこと

    ワークフローは全件 Supervised なのに、ツールは67件が Autonomous

    実行モードには、ワークフロー単位とツール単位の2段があります。ワークフロー12件の実行モードは、すべて Supervised でした。

    一方、21件のエージェントに割り当てたツール70件のうち、Supervised は3件だけです。Close security incident as false positive、Run block request、Delete email from server の3件です。残る67件は Autonomous になっています。


    画像

    起点はワークフロー、橙は人の承認が入るツール、赤は承認なしで実行されるツールです。

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

    • 1段目(ワークフロー単位):12件すべて Supervised。トリガーは12件とも0件

    • ワークフローのメンバーとして、エージェント21件がツールを呼ぶ

    • 2段目(ツール単位、70件):Supervised 3件(Close security incident as false positive/Run block request/Delete email from server)、Autonomous 67件

    • Autonomous 67件に入っている操作の例:Isolate Host(ホスト隔離)、Send email、Update incident state、Update control objective details

    Autonomous 側の操作を、エージェント別に挙げます。

    • EDR Agent の Isolate Host

    • Security incident activities handling AI agent の Send email と Update incident state

    • Control Objective Change Agent の Update control objective details

    ツール名から読んだ内容で、スクリプトの中身は読んでいません。

    Control Objective Change Agent の説明には、ユーザーの確認を得てから更新すると書かれています。ツール側の設定は Autonomous です。確認が会話の指示として入っているのか、別の仕組みなのかは確かめていません。有効にするときは、確認が実際に入るかどうかを自分の環境で動かして見ます。

    状態不明の9件は、有効かどうかを自分の環境で確かめる

    ワークフロー12件のうち、有効と読めたのは3件だけです。残る9件は、有効状態を上書きするレコードが読めず、状態不明のままです。有効だったのは、規制変更の2件と SIR のシフト引き継ぎでした。

    公式の記述で既定で有効になるものとして挙がっている SIR のワークフローは、次の4件です。

    • Analyze security operations metrics

    • Close security incident

    • Generate SIR shift handover report

    • Resolve security incident

    同じ一覧にある SIR のスキルは6件で、カタログの SIR スキル10件のうち4件は載っていません。有効かどうかは、導入の経緯でも変わります。

    先ほどの規制分析を取得ワークフローで、トリガー欄も確かめました。表に行は無く、「表示するデータがありません」と出ます。


    画像

    無効のエージェントがメンバーに入っているワークフローがある

    VR のワークフロー3件は、メンバーのエージェントが無効でした。Assess vulnerability exposure、Retrieve VR data、Analyze vulnerability remediation status の3件です。ワークフローが有効でも、メンバーが無効なら動かない可能性があります。この組み合わせで動くかどうかは、実行していないため確かめていません。

    代表機能として動かしたセキュリティインシデントの要約スキル

    一覧のうち、起動が簡単で、記録を書き換えず、ツールも呼ばない機能を1つ選びました。SIR Workspace の概要タブにある、Security Incident summarization(セキュリティインシデントの要約)です。今回の結果は、この1つのスキルと1件のテスト用レコードに限ります。ワークフローやエージェントの動作は含みません。

    要約の元にしたテスト用レコード

    動かす前に、元のレコードの中身を示します。要約が良いか悪いかは、元に何が書いてあったかで決まるためです。

    件名は「記事検証: 社内ポータルを装った偽ログイン画面に従業員が認証情報を入力した可能性」で、カテゴリはフィッシングです。説明欄に書いたのは次の内容だけです。

    • 経理部の従業員1名から申告があった。申告の文言は「社内ポータルに見える画面へIDとパスワードを入力したかもしれない」

    • メールの差出人は社外ドメインで、リンク先は社内のドメインではなかった

    • 入力した端末は1台で、本人は入力後すぐに画面を閉じた

    • 被害の有無はまだ不明

    作業メモ、影響を受けるユーザー、CI、観察事項は入れていません。書かれているのは「申告された内容」だけで、アナリストが確かめた事実はひとつもありません。この点が、後の評価の判定軸になります。

    レコードはテスト用に1件作ったもので、作成の時点で状況が分析になり、デモ用の担当者へ自動で割り当てられました。この割り当てに伴う通知メールが1通作られましたが、宛先はデモ用のアドレスで、送信は失敗の状態でした。以降の操作でメールは増えていません。

    要約の手順と結果

    操作は、概要タブの「Now Assist によってこの セキュリティインシデント の要約が可能です」の欄にある[要約]ボタン(画像の①)を押すだけです。Otto パネルへの入力は使っていません。


    画像

    1回目は、押してから31.7秒で要約が表示されました。2回目は26.4秒でした。表示は「問題」「詳細」「観察事項」「実行された主なアクション」の4つの見出しに分かれます。


    画像

    1回目の「問題」は次の1文です。

    • 社内ポータルを装った偽のログイン画面に、経理部の従業員1名が認証情報を入力した可能性がある事案です。外部ドメインのメール経由で誘導されたもので、フィッシングの疑いがあります。

    2回目の「実行された主なアクション」の1行目は次のとおりです。

    • 経理部の従業員様からの申告内容を受領し、事案として起票しました。

    4見出しのうち3つは使え、アクション欄は書き直しが要る

    評価の段階は、この記事で次のように決めて使います。

    • 修正なし:文章を変えずに下書きとして使える

    • 軽微:事実関係は変えず、語句だけ直す

    • 大幅:状態や対応など、業務判断に関わる内容の削除や訂正が要る

    • 不採用:書き直しが要り、下書きとしての効果が薄い

    4つの見出しの評価は次のとおりです。

    • 問題:1回目は修正なし。2回目は軽微(「従業員様」を「従業員」に直す)

    • 詳細:1回目は修正なし。2回目は軽微(同上)

    • 観察事項:1回目も2回目も修正なし

    • 実行された主なアクション:1回目も2回目も大幅

    1回目と2回目は、同じレコードに同じ操作をしましたが、文面は同じになりませんでした。

    アクション欄を「大幅」にした理由は、1回目と2回目で違います。

    • 1回目は、「メール差出人が社外ドメインであることを確認しました」「入力が行われた可能性のある端末が1台であることを把握しました」のように、申告の内容を「確認しました」と書いた。元のレコードに、確認した人も確認した事実も無い。申告の段階にある内容が、確認済みの行動に見える

    • 2回目は、「事案として起票しました」を加えた。元のレコードには、起票という行動を示す記述が無い


    画像

    起点は元のレコード、青は元に書かれていた内容、緑は元に沿った文、赤は元に根拠がなく書き直しが要る文、灰色は元に無かった情報

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

    • 元の説明欄:申告された内容だけ(フィッシングの疑い・社外ドメインのメール・入力した端末は1台・被害の有無は不明)。作業メモ・影響ユーザー・CI・観察事項は無く、アナリストが確かめた事実は0

    • 要約の問題・詳細・観察事項:元の説明に沿っている。修正なし〜軽微

    • 要約の実行された主なアクション(1回目):申告の内容を「確認しました」と書いた

    • 要約の実行された主なアクション(2回目):「事案として起票しました」を加えた。元に起票の記述は無い

    • 「申告された」と「確認した」の差が次の対応を左右するため、アクション欄は書き直すか削る

    セキュリティインシデントでは、「申告された」と「確認した」の差が、次の対応を左右します。この欄は、そのまま共有せず、書き直すか削る対象として扱うのが妥当です。

    レビューの負荷は、今回のレコードが説明欄の4点だけだったため、元の説明を読み直せば見比べられる量でした。所要時間は測りませんでした。作業メモが数十件ある実際の記録で同じ精度が出るかは未確認で、ゼロから要約を書く場合との比較も行っていません。

    要約を動かしても、レコードには何も書かれなかった

    要約の前後で、メールは1通も増えていません。要約は画面に表示されるだけで、レコードへの書き込みは行われていませんでした。この要約スキルは、「回答や下書きを画面に表示するだけの機能」に分類できます。

    後始末として、作成したセキュリティインシデントと、それに紐づいて作られたメールは、検証のあとにすべて削除しました。

    有効にする前に決めること

    一覧から読み取れるのは、標準で何が用意されているかまでです。機能の種類ごとに、次の点を決めます。

    回答を表示するだけの機能は、渡すデータと利用ロールを決める

    スキルや、データを引いて答えるワークフローは、記録の内容を入力に使います。インシデントの説明・作業メモ・影響を受けるユーザー・CI・リスクの内容です。

    公式の記述では、スキルはグローバルドメインに存在します。ドメイン分離の環境では、利用者が見られるドメインのデータだけが使われる仕組みです。生成 AI の共有サービスがプロンプトと応答を保存しない点も、同じページに書かれています。

    決めるのは、どのロールにスキルを使わせるか、機密度の高い記録を対象に含めるかの2点です。ロールの付与が広いと、記録の内容を要約として見られる人も広がると考えられます。ただし、今回はロールを変えて試しておらず、実際に何が見えるかは確かめていません。

    外部の情報を使う機能は、何を外に出すかを決める

    Get Regulatory Analysis は Web 検索で規制アラートに文脈を足し、Risk Suggestion AI Agent は外部の Web データを使います。ツール名は Regulatory alert web search と AIA Web Search です。検索に、組織名や内部のリスクの記述が含まれるかは確かめていません。有効にする前に、検索語に何が入るかを一度見ておくことが候補になります。

    承認設定のないツールを持つ機能は、操作の範囲を絞ってから有効にする

    ホストの隔離、メール削除、インシデントの状態更新のように、実環境に影響する操作があります。これらは、ツール側が Autonomous のまま有効にしない、という選択が候補になります。

    標準のツールを変えるには複製が必要になる場合があります。今回は複製も変更もしていないため、調整でどこまで足りるかは確かめていません。

    先に決めておくのは、次の3点です。

    • ツールを呼べるロール(エージェントのロールマスキングで設定する)

    • 承認者と、操作を戻す手順(ホストの隔離の解除など)

    • 対象にする CI やアカウントの範囲

    検証範囲とおことわり

    • 件数と有効状態は、2026-10-02 時点のデモ環境の値。出荷時の既定値ではない

    • 実行したのは Security Incident summarization の1つで、テスト用のセキュリティインシデント1件に2回かけただけ。ほかのスキル、ワークフロー、エージェントは実行しておらず、既存のセキュリティインシデントやリスクのレコードの中身は読んでいない

    • 要約の評価は1件の短いレコードに対するもの。実際の運用データでの品質は評価していない

    • ワークフロー12件のうち9件は、有効状態が読めていない

    • ツール70件は、ツール名から内容を読んだもので、スクリプトの中身は確かめていない

    • SIR で判定できなかったエージェント4件とツール9件は、一覧から外している

    • ワークフロー単位の実行モードと、ツール単位の実行モードが、実行時にどう組み合わさって働くかは確かめていない

    • ワークフローとエージェントの対応は、メンバーとして読めた範囲。ワークフローに属すると読めなかったエージェントの起動のきっかけは確かめていない

    • 撮影した画面は要約の実行1回分で、設定の保存や有効化はしていない

    • 日本語の訳は、製品に日本語の表示名が無いものは筆者の訳

    用語

    • SecOps:セキュリティ運用。SIR(セキュリティインシデント対応)、VR(脆弱性対応)、USEM(統合セキュリティエクスポージャー管理)を含む

    • GRC:ガバナンス・リスク・コンプライアンス。IRM(統合リスク管理)、TPRM(サードパーティリスク管理)を含む

    • Supervised:ツールの実行前に人の承認が入る設定

    • Autonomous:承認なしで進む設定

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

    次のパスを自分のインスタンスの URL に付けて開くと、同じ情報を確認できます。

    • エージェント型ワークフロー:/sn_aia_usecase_list.do

    • AI エージェント:/sn_aia_agent_list.do

    • ツールの割り当て(実行モード):/sn_aia_agent_tool_m2m_list.do?sysparm_query=GROUPBYexecution_mode

    • ワークフローの有効状態(上書き):/sn_aia_usecase_config_override_list.do

    • トリガーの構成:/sn_aia_trigger_configuration_list.do

    公式ドキュメントは次のとおりです。

    関連記事

     
     
    ServiceNowのPDI(Personal Developer Instance)を実機で観察して、Noteに記事を書いています 実装・運用・教育の現場視点で淡々と記録中です リクエストがあればその記事も書きます 個人の観察日記です

    あなたへのおすすめ