インシデントのNow Assist機能紹介とOOTBのまま使えるかの検証
検証環境：Australia（Patch 5）Now Assist デモ用インスタンス / 英語レコードは英語表示、日本語レコードは英語表示・日本語表示の両方で確認 / 2026-09-19〜20 確認
スキルは有効化済みの環境で確認しました。出荷時点の初期状態は検証していません。
OOTBのまま試して分かったこと
要約は引き継ぎの助けになりましたが、拾う事実が生成のたびに変わることがありました
日本語のレコードでは、未確認の仮説を確定した原因に書き換える誤りは起きませんでした。一方で、効果がなかったキャッシュ削除を、解決メモは手順として並べ、KBの下書きは「案内してください」と推奨に変えていました
事実の揺れや根拠のない書き足しも残りました。作り込む前に、レコードの書き方とレビュー体制を見る価値がありました
有効化するだけで動くスキルもあれば、フィールドごとの設定が要るスキル、環境の前提が整わないと届かないスキルもありました
要件を聞いてすぐ「専用のスキルを作ろう」と考える前に、いくつのスキルがどこまで使えるかをデモ環境の業務形式レコードで確かめました。中心の評価はデモレコード3件（英語2件・日本語1件）です。日本語のレコードは画面表示を英語・日本語の両方で確認しました。生成は合計18回実行し、元レコードと突き合わせて修正量まで判定したのは11回です（内訳は付録「試行の規模」）。実装判断に必要な観点を洗い出す目的に絞り、OOTBスキル全体の品質評価は範囲外としています。
インシデント向けOOTBスキルの一覧
OOTBに何があるかを先に確認したうえで、今回の検証がどこまで届いたかをご覧ください。ITSM本体（Otto for ITSM）のインシデント関係スキルは次のとおりです。
Incident summarization（インシデントの要約）：インシデントの経緯を要約する
Resolution notes generation（解決メモの生成）：解決メモ欄の下書きを作る
KB generation（ナレッジ記事の生成）：解決内容からナレッジ記事の下書きを作る
Incident sentiment analysis（インシデントの感情分析）：やり取りの感情の傾向を扱う
Major incident email content recommendation（重大インシデントのメール文面推奨）：関係者向けメールの文面を作る
Chat summarization（チャットの要約）：対話を要約する
Chat reply recommendation（チャットの返信推奨）：返信案を出す
Incident cluster summary（インシデントクラスターサマリー）：関連インシデント群を要約する
Summarize and Generate Plan in NACM（NACMでの要約と対応案生成）：要約と対応案をまとめて出す
Incident activity response generation（インシデントアクティビティ応答生成）：作業メモ・コメントへの返信案を作る
Email recommendation（メール推奨）：メール文面を推奨する
Sidebar discussion summarization（サイドバーの会話の要約）：サイドバーの会話を要約する
有効・無効の状態と実行の可否は、あとの各章に書きます。確認時に無効だったのは、次の3つです。
Incident activity response generation
Email recommendation
Sidebar discussion summarization
今回動かしたのは、代表的な3つの要約・解決メモ・KB生成です。画面を見る・記録を書く・ナレッジとして公開するという3つの使われ方を、1つずつ押さえているためです。実行回数の内訳は付録「試行の規模」にまとめています。
スキルの一覧と、個々の有効・無効の切り替えは、この管理コンソールの画面で行います。表示件数は23件で、デモ用に追加・変更されたスキルも含みます。
開発者は、なぜすぐ作りたくなるのか
要件を聞くと、専用のスキルを作り、業務特化のプロンプトを書き、Flowと連携させる案がまず浮かびます。作る前に、確かめることがあります。OOTB（標準の機能）で足りる部分はないか、メジャーアップグレードのあとそのカスタムスキルを誰が保守するのかです。公式ドキュメントには、スキルは既定でも最も一般的な用途に最適化された構成を持つと説明されています（Make a copy of AI skill）。
今回は、インシデントの画面で動くスキルをデモ環境の業務形式レコードで動かしました。OOTBで何が満たせて、標準設定と運用でどこまで直り、それでも開発が要るのはどこかを切り分けます。
今回は、あえて作らずOOTBだけを試す
試したのは代表的な3つのスキルです。経緯をまとめる「要約」、解決の下書きを作る「解決メモ生成」、ナレッジ記事の下書きを作る「KB生成」です。Now Assistの機能は「スキル」という単位で作られ、要約も解決メモも、それぞれ独立して有効・無効を切り替えられます。
カスタマイズと、自律的に複数の手順を進めるAIエージェントは、今回あえて外しました。作り込む前にOOTBの実力を見るのがこの記事の役目で、複数の処理を自分で判断して進める仕組みは別の記事で扱います。
画面表示は、英語レコードでは英語のままです。要約・解決メモ・KB生成の中心評価は、デモ環境の英語レコード2件と、今回の検証のために作成した日本語のインシデント1件で行いました。1件目はデータセンターの空調故障を扱う重大インシデントで、要約と解決メモ生成に使っています。2件目は原因をめぐるやり取りが会話として残るインシデントで、KB生成に使いました。日本語のインシデントは、画面表示を英語・日本語の両方で同じ3スキルを実行し、内訳は付録「試行の規模」にまとめています。
日本語のインシデントは今回の検証のために新規に作成しました。未確認の仮説は「まだ確認できていない」と明記し、効果がなかった手順や応急処置と恒久対応の混同を防ぐ書き方にしています（詳細は付録）。担当者が使うワークスペース（Service Operations Workspace、以下SOW）で操作し、デモ用に追加・変更されたとみられるスキルとレコードは対象から外しています。
OOTBを何で評価するか
「生成された」だけでは評価になりません。Insertを押せば、どんな下書きも一応は記録に入ります。見るべきは、元のレコードと突き合わせて事実が合っているか、何が抜けているか、直すのにどれくらい手を入れるかです。
修正量は次の4段階で判定します。
修正なし：文章を変えずに目的に使える
軽微：事実関係は変えず、語句や表現だけ直す
大幅：原因・状態・対応・結論など、業務判断に関わる内容の追加・削除・訂正が要る
不採用：元レコードとの照合や全面的な書き直しが要り、下書きとしての効果が薄い
用途は4つの軸で見ます。担当者どうしの引き継ぎ、正式な解決記録、顧客向け文面、再利用できるナレッジです。どの用途に向くかは修正量だけでは決まりません。誤りが1か所でも解決記録として致命的なら、大幅より不採用に近い判定にしました。
もう1つの軸はレビューの負担です。元レコードを全文読み直す必要があるか、要点だけで足りるかです。かかる時間は今回計測していません（末尾の未確認リストに記載）。
図の緑は今回押した段階、灰色の点線は公式の手順にあるが今回は押していない段階です。この記事の評価は、生成の巧拙ではなく「人が確認したあと、そのまま使えるか」に置きます。
図の内容を文字でも書き出します。
担当者の操作（レコードを開く・欄のアイコンを押す・依頼文を入力する）でスキルが文章を生成する。生成の記録（ログ）は、採用するかどうかに関係なく残る
提案が画面に出る（要約カード・ポップオーバー・フォームの下書き）。担当者が確かめて、採用するか決める
採用しない：閉じる。インシデントとナレッジは変わらない（今回の操作）
採用する：Insert / Save to Work notes / Save → Resolve またはフォームの保存 → 記録に残る（インシデントは Resolved、KB 記事はナレッジのレコードとして保存）。公式手順で、今回は押していない
元にしたインシデントには何が書かれていたか
生成物の中身を見る前に、元になったインシデントに何が書かれていたかをご覧いただきます。件名は「記事検証: 勤怠打刻アプリからの打刻が断続的に失敗する」です。社給スマートフォンの勤怠打刻アプリで打刻が断続的に失敗し、「通信エラー（E-0420）」が表示されるという問い合わせでした。再試行すると成功することもありました。
発生は2026年9月18日午前9時ごろです。朝の出勤時間帯（8:30〜9:30）と昼休み明け（13:00前後）に集中しており、影響は本社と3拠点の約600名でした。
作業メモは10件、コメントは3件残っています。中心的な内容は次のとおりです。
監視指標：打刻APIのタイムアウト率が9時5分から平常0.2%→12%へ上昇
未確認の仮説：認証基盤のセッション上限が原因である可能性、ただしまだ確認できていない
効果がなかった対応：端末側のキャッシュ削除を案内したが改善しなかった
特定された原因：打刻APIの接続プール上限20への到達
暫定対応：接続プール上限を20から60へ引き上げ、APIサーバをローリング再起動
復旧：同日11時20分に打刻成功率が99.8%へ回復
恒久対応：アプリ側の打刻の再試行処理の実装を10月7日リリースへ組み込む予定（まだ未了）
人事部への連絡：当日分の手修正が必要な約40件を連絡
コメント3件：VPN切断ではという利用者の推測、再試行が成功したという報告、昼休み明けの再発と沈静化の報告
この記録には、後半の判定で軸になる3点があります。
認証基盤のセッション上限は、確定した原因ではなく未確認の仮説という位置づけ
端末側のキャッシュ削除は、効果がなかった対応として記録されている
恒久対応（10月7日リリース予定）は、まだ実装されていない
生成物がこの3点をどう扱うかが、次の章からの評価の軸になります。
要約・解決メモ・KB生成を試した結果
いちばん大きな発見は、今回作成した日本語のインシデントで、未確認のままだった仮説（認証基盤のセッション上限）を確定した原因として書いた回が無かったことです。応急処置と保留中の恒久対応を取り違えた回も見当たりません。要約・解決メモ・KB下書きのどの回でも、この2点は起きませんでした。
一方で、効果がなかった手順（端末側のキャッシュ削除）の扱いは崩れました。画面表示を日本語にした解決メモは「解決手順」の箇条書きに効果なしの注記を落として並べ、KB下書きは「案内してください」「一時的な改善策」という言葉に変えていました。効かなかった手順が効いた手順のように見える誤りです。
それに加えて、回によって拾う事実が変わり（要約3回中1回、未確認の仮説がそのまま抜けました）、ソースにない一般化を書き足します（KB生成は英語・日本語の両方で発生しました）。そしてKBと解決メモは、要約より書き足しが多くなります。
同じ日本語レコードから、誤りのない要約と、誤りを含む解決メモ・KB下書きの両方が生成されました。レコードの書き方だけで出力の質が決まるとは言えません。今回は日本語1件に対して英語2件の比較にすぎず、レコードの書き方がどこまで効いているかは切り分けられていません。書き方を変えて比較することが次の検証候補です。
Now Assist「Incident summarization」の検証
期待した用途は引き継ぎです。担当者交代時に、案件の経緯をすばやくつかむ表示として使います。
結果は、日本語で作成したインシデントでも、開くと要約が自動で生成されました。画面表示を英語のままにした3回の見出しは「Issue:」「Key Actions Taken:」の2つです。画面表示を日本語に切り替えると、見出しは「問題:」「実行された主なアクション:」「影響を受けるCIおよび影響を受けるサービス:」の3つになりました。見出しの言語と数は違います。それでも症状・時間帯・対象範囲・原因（接続プール上限到達）・暫定対応（20→60）・復旧（99.8%）・人事連絡・恒久対応（10月7日リリース予定）は、どちらの表示でも引き継がれていました。効果がなかったキャッシュ削除の手順も「効果がなかった」という位置づけのまま残っています。
最大の問題は、未確認の仮説（認証基盤のセッション上限が原因である可能性）の扱いが表示言語によって揺れたことです。画面表示を英語にした3回のうち1回はこの仮説がそのまま抜け、残り2回は「not yet confirmed」を保ったまま載せていました（確定原因への書き換えはなし）。画面表示を日本語にした生成では「調査中である」という表現で残っており、抜けたのは書き換えでなく事実の欠落です。
判定は軽微です。事実を確定表現にすり替える誤りはなく、担当者どうしの引き継ぎに使える水準でした。ただし3回中1回は未確認の仮説が丸ごと抜けており、この回だけは大幅（業務判断に関わる手がかりの削除）でした。引き継ぎに使うなら複数回の生成物を見比べるか、原文の作業メモも合わせて確認します。close_codeが空でこのインシデント自体まだ解決していないため、解決記録への転用はまだ早いといえます。
Now Assist「Resolution notes generation」の検証
想定した用途は正式な記録です。インシデントを解決するとき、Resolution notes欄の下書きに使います。
結果は、日本語のインシデントでも欄のアイコンを押すと下書きが出ました。画面表示を英語のままにすると「Issue:」「Cause:」「Resolution steps:」の3区分、日本語に切り替えると「問題:」「原因:」「解決手順:」の3区分になりました。どちらも原因（接続プール上限到達）・暫定対応・復旧（99.8%）は正確で、人事連絡と恒久対応未了（10月7日リリース予定）の位置づけも保たれています。応急処置と恒久対応を混同する誤りはどちらの表示でも起きませんでした。
気になった点は、症状の規模（約600名・本社と3拠点）、時間帯、監視数値（0.2%→12%）が本文から落ちたことです。Issue文（問題文）が「打刻を断続的に記録できなかった」に圧縮され、規模の情報は残りません。
もう1つ、端末側のキャッシュ削除の扱いは表示によって分かれました。画面表示を英語にした解決メモはbut it had no effectと効果なしのまま記載していましたが、画面表示を日本語にした解決メモは「解決手順」の箇条書きに「端末側のキャッシュ削除を案内しました。」と並べ、効果がなかったという注記を落としています。原文の作業メモは「効果はなかった」と明記しており、効かなかった手順が効いた手順のように見える誤りです。
判定は、英語表示の回は軽微です。原因と対応の経緯は正確で、正式な解決記録の下書きに使える水準ですが、規模や監視数値が要るなら追記します。日本語表示の回は、キャッシュ削除の扱いが業務判断に関わるため大幅です。
英語のデモレコードでは、この解決メモが応急処置を解決済みの体裁で書き、恒久修理が部品待ちである事実が抜けていました。今回の日本語レコードではこの混同は起きていません。作業メモに恒久対応の予定を明記したことが効いた可能性はありますが、英語1件・日本語1件の比較では断定できません。
Now Assist「KB generation」の検証
見るのは再利用性です。他の利用者が同じ症状に当たったときに読む記事として使えるかを確かめます。新規ナレッジ記事の画面に日本語で依頼文を送りました。画面表示を英語のままにした場合は「Problem」「Root cause」「Steps to Resolve」「Notes」の4区分・401 wordsの英語下書きが生成されました。症状・時間帯・対象範囲・原因・監視指標・キャッシュ削除は効果なしのまま引き継がれています。一方、接続プール「20→60」や約40件という数値はむしろ抽象的な表現に置き換わっていました。
画面表示を日本語に切り替えて同じ依頼文を送ると、Language欄（日本語表示では「言語」）は既定で「日本語」が選択されていました。見出しは「概要」「影響範囲」「原因（根本原因分析）」「対策・解決手順」「備考・注意点」です。英語表示のときと違い、約600名やエラーコード「E-0420」といった数値は本文にそのまま残っていました。一方で、対策・解決手順は端末側のキャッシュ削除を「案内してください」と並べ、備考・注意点では「一時的な改善策」と位置づけていました。作業メモの「効果はなかった」から後退した表現です。
一方で、英語表示の下書きは作業メモにない記述を3か所書き足していました。「接続プールの容量設定が不十分だった」という診断的な言い切り、恒久対応後に自動再試行を確認する手順、一般的な監視手順の追加です。いずれも生成が付け足した推論です。日本語表示の下書きにも監視の継続を促す一文が付け足されており、数値を残す一方で根拠のない推論を足す傾向はどちらの表示でも見られました。大幅な修正が要り、公開前に出典との突き合わせは欠かせません。
英語のデモレコードでは違いました。利用者の推測（「Maybe that's causing the problem」）を確定したRoot Causeに書き換えており、レビューをすり抜けやすい誤りです。今回の日本語レコードでは、この推測の確定扱いは起きていません。一方「効かなかった手順を効いた手順のように書く」誤りは、英語デモレコードのKBだけでなく、今回の日本語レコード（日本語表示の回）のKB下書きでも起きています。
KB生成は生成画面で出力言語を選べる
KB生成の画面には、依頼文の下にLanguage（日本語表示では「言語」）という設定があります（公式ドキュメントでは「Article language」）。英語表示ではナレッジベースを選ぶ前はEnglishしか選べませんが、ITナレッジベースを選ぶとEnglishと日本語の2択になります。画面表示を日本語にすると、同じITナレッジベースを選んだ時点でこの2択のうち「日本語」が既定で選ばれていました。
英語表示のままLanguage欄で日本語を選ぶと、同じ依頼文から580 wordsの日本語下書きが生成されました（前節の572 words版とは見出しの構成が違います）。数値を残す傾向とソースにない一般化の書き足しは、どの表示・言語でも共通していました。
要約と解決メモには個別の言語セレクタを確認できませんでした。要約カードにも解決メモの吹き出しにも、再生成・折りたたみ・コピー・Insert以外の項目はありません。今回、画面表示を日本語にすると、要約と解決メモの出力も日本語になりました。個別のセレクタが無くても、画面表示に応じて出力言語が変わっています。
結果は使える範囲ごとに4つに分けられる
3レコードの生成を通じて、誤りは3種類に分かれました。
複数の事実をまとめて圧縮したり、推測を確定表現へ格上げしたりする誤り（英語のデモレコードで発生）
効かなかった手順を効いた手順のように書く誤り（英語のデモレコードに加え、日本語レコードの解決メモとKB下書きでも発生）
生成のたびに拾う事実が変わる揺れや、ソースにない一般化を書き足す挙動（日本語のレコードでも再現）
冒頭の一覧にある12機能を、今回の追加確認まで含めた実行結果で次の4つに仕分けます。
スキルを改変せずに生成できた範囲
有効化や標準設定で動く範囲
環境の準備やカスタマイズが要る範囲
このデモでは生成や表示まで確認できず、判断できなかった範囲
確認のため、3スキルを一時的に有効化しました。対象はEmail recommendation・Incident activity response generation・Deflection Query Rephraseです。確認後に元へ戻し、復元後の値も読み直して確認済みです。感情分析も収集ジョブを同様に一時有効化し、確認後に無効へ戻しています。
スキルを改変せずに生成できたもの
要約・解決メモ生成・KB生成は前章で評価済みです。判断は用途ごとに分かれるため、ここではスキルごとではなく用途ごとに1行で並べます。
Incident summarization：担当者どうしの引き継ぎに使えます（詳細は「Now Assist「Incident summarization」の検証」）
Resolution notes generation：正式な解決記録の下書きに使えます。画面表示を日本語にした回はキャッシュ削除の扱いを直す必要があります（詳細は「Now Assist「Resolution notes generation」の検証」）
KB generation：下書きとして使えますが、公開前レビューを外せません（詳細は「Now Assist「KB generation」の検証」）
有効化や標準設定で使えるもの
有効・無効は、スキルの定義（sn_nowassist_skill_config）ではなく構成ステータス（sn_nowassist_skill_config_status）のactive/in_product_activeで決まります。定義側のactiveがtrueでもステータス側がfalseなら画面に出ません。定義の有効は画面に出ている根拠にはなりません。
Incident activity response generation：作業メモやコメントへの返信案を作ります。既定は無効ですが、有効化すると作業メモ欄にアイコンが出ます。押しても生成は始まらず、「応答後」「実行されたアクションを要約」の2択サブメニューが開くだけです。以前の2回（155.7秒待って結果なし）は、この2択を選ばず「挿入」ボタンを待ち続けたことが原因でした。サブメニューを選ぶと約31秒で生成に成功しました（エラーなし。原因は操作漏れで権限やプラグインの制約ではありません）。ただし吹き出しが小さく全文は未取得で、出力の質は評価していません。判断：有効化とサブメニュー選択で生成には進めますが、導入判断には品質確認が別途要ります。
KB生成の出力言語：前章のとおりLanguageセレクタで切り替えられます。ナレッジベースを選んでから設定します。標準操作で足り、開発は要りません。
環境の準備やカスタマイズが要るもの
チャットの要約／チャットの返信推奨：対話の要約と返信案を作ります。公式ドキュメントは、Virtual Agentから有人チャットへ引き継がれた実際の会話（Active Chatセッション）を前提と明記しています。確認用のレコードを直接作成しても前提は再現できず、SOWで開くと別のインシデントが自動作成されて画面が切り替わりました。障害ではなく前提条件の不足です。判断：実際の引き継ぎ経路を用意してから確認します。
Email recommendation：メール文面を推奨します。公式ドキュメントが示す条件は、メール本文で6語以上を選択することです（Email recommendations using the ServiceNow Otto context menu）。今回は短い文字列を入力しただけで、この条件は試していません。判断：文書化された条件を試してから、起動場所の有無を判断します（詳細は付録）。
Deflection Query Rephrase：問い合わせ文面を言い換え、自己解決へ誘導する機能です。冒頭の一覧にはありませんが、同じ一時有効化の対象として確認しました。公式の説明はこのスキルをバックエンド専用とし、スキル選択メニューには表示されないとしています。単独の起動場所が無いのは想定どおりで、欠陥ではありません。有効化してSOWとサービスポータルの両方を見て回りましたが、提案の出る画面には到達できませんでした。判断：起動場所の場所を特定してから要否を判断します（詳細は付録）。
生成や画面表示まで確認できなかったもの
生成や画面表示の途中までは進んでも、最後まで確認できなかった機能です。
Incident sentiment analysis：感情の傾向を示します。既定では収集ジョブが無効で値が付きません。一時的に有効化すると、優先度1の確認用インシデントに1件だけ値が付きました（ニュートラル・score 0）。値はsys_sentiment_detailsという別テーブルに入ります。ただし画面表示を確認したのは値の付かなかった日本語の検証用インシデントで、値が付いたレコードの画面は未確認です。公式ドキュメントはインシデントのリストとフォームにSentiment欄があるとしていますが、このデモでは別テーブルへの値の生成を確認しただけで、標準画面での表示可否と項目追加の要否は判断できません。
Now Assistコンテキストメニュー（NACM）：欄や選んだ文章から生成・調整を行うメニューです。解決メモ欄（close_notes）はNACM Configが紐づき、文字を選択するとOtto アイコンが浮かびますが、生成までは到達せず、再現性も高くありません。説明欄（description）には同種の設定が見当たらず、3回試してもアイコンは出ませんでした（権限の問題ではなく、説明欄にNACM Configが設定されていないことが原因とみられます）。どちらのフィールドも判断は保留です。説明欄へのNACM Config追加は候補ですが、効果は未確認です。
Major incident email content recommendation：重大インシデント関係者向けのメール文面を作ります。「重大なインシデントに昇格」を確定してComposeまで到達しましたが、Email templateの選択欄もNow Assistアイコンも見当たりませんでした。公式ドキュメントは、Composeで4種のテンプレートを選べるとしています。4種とはAd hoc AI・Business user AI・End user AI・Technical AIです（重大インシデントのメール文面推奨 ）。テンプレートの格納先や適用条件との対応は未確認です。判断：起動場所の有無を確認してから要否を判断します（詳細は付録）。
Incident cluster summaryは関連インシデント群を要約する機能です。Summarize and Generate Plan in NACMはNACM上で要約と対応案を出す機能です。スキル構成でNACM経由であることを確認しました（Summarize and Generate Plan in NACMは名称と構成からの判断です）。どちらもメニューが出ない限り実行できず、今回は到達していません。判断：NACMの経路が安定して動くようになってから改めて評価します。
サイドバー要約は対象外です。有効化も対象レコードの用意もしていません。生成や画面表示まで確認できなかった機能は、原因を切り分けたうえで次回以降にあらためて確認します。
その不足は本当にカスタマイズ対象か
生成物の不足は、データ・標準設定・運用・カスタマイズの順に切り分けます。生成や画面表示まで確認できなかった機能は前節のとおりで、ここでは繰り返しません。
データ
KB生成に使った英語のデモレコードは、カートに追加した商品がチェックアウト前後で消えるという相談で、原因を探るコメントのやり取りが14件残っていました。description欄には注文ステータスが処理中のまま更新されないという別の内容が書かれており、short_descriptionともコメントとも一致しませんでした。原因は起票時のデータ品質です。候補は受付時の入力チェックの見直しですが、変更後の比較は行っておらず、これで直るかは未確認です。今回作成した日本語のレコードにこの矛盾はありませんでした。
標準設定（コピー不要）
誰が使えるか（ロール）、どこに出すか（表示先）は、OOTBのままAI Admin Hubで変更できます（Configure case or incident summarization in the AI Admin Hub console）
KB生成の対象にするインシデントの状態は、システムプロパティcom.snc.incident.create_knowledge.multistate.enableで管理者が決めます（Generate a knowledge article）
KB下書きの出力言語は、前章のとおりLanguageセレクタで切り替えられます（多言語対応の公式手順）。要約・解決メモには個別のセレクタが見当たりません
運用（レビュー）
Insertや公開の前に、次の手順で確認します。
用途（引き継ぎ／解決記録／顧客向け文面／ナレッジ）を決め、その用途に必要な事実を書き出します
生成結果と元レコードを突き合わせ、抜けている事実・誤った記述・出典のない書き足しを書き出します
元レコードのどこまで読み直す必要があったかを残します（要点の照合で済んだか、全文を読み直したか）
修正にかかった時間を記録します
解決メモの応急処置と恒久対応の混同、KB生成のソースにない一般化、要約の事実の出入りは、この手順で見つかる代表例です。標準設定や受付時の入力チェックを変更したら、前後の生成結果を比べます。繰り返し不足するなら開発要件にします。今回、修正にかかった時間そのものは計測していません。
カスタマイズ（コピーしてからの変更）
出力セクションの追加は、スキルをコピーして行います（Customize ITSM summarization skill）。入力テンプレートの拡張やプロンプト文言の追加も、コピーしたスキルのAI Skill Kit、あるいはスキルプロンプトの設定から行います。公式ドキュメントにはこう書かれています。
Note: In a default scenario, only one version of a skill can be active at a time. If you create and activate a copy of the skill, any previously activated version of the skill is deactivated.
（訳: 既定のシナリオでは、あるスキルにつき同時に有効化できるバージョンは1つだけです。スキルのコピーを作成して有効化すると、それまで有効化されていたバージョンは無効化されます）
コピー版に将来の更新がどう入るかは未確認のため、導入時にアップグレード時の扱いを確かめます。
改善案の候補（要約の入力範囲見直し、KB生成への「未確定は推測と明記」指示の追加）はコピー版を作っておらず、解消するかは確かめていません。コピーしてもレビューは省けません。
カスタム化して増える管理対象
OOTBのスキルにも、品質確認・利用量確認・レビュー・言語設定の管理・アップグレード後の挙動確認は元々要ります。コピーを持つと、この上に次の管理対象が積み増しになります。
構成管理：入力テンプレート・出力セクションの設定を記録します
プロンプトの変更履歴：追加文をいつ・誰がなぜ入れたか残します
リリース後の回帰試験：アップグレードのたびにコピーを動かし直し、期待する出力を確認します
Flowなどへの依存：他システムやFlowへの連携も保守対象に入ります
コピーの有効化とテストは、AI Admin Hubの管理権限を持つ担当の役割です。OOTBスキルは有効化さえしておけばメジャーアップグレードをまたいでも状態が保たれます（AI agents, skills, and agentic workflows on by default）。コピー版に保証が及ぶかは未確認のため、アップグレードのたびにOOTB版との差分を確認します。
お客様への提案を3種類に分ける
要約・解決メモ・KB生成の評価結果は、前節の「データ・標準設定・運用・カスタマイズ」の切り分けのまま提案できます。ここでは、スキルが記録にどう関わるかでリスクの種類を分けます。今回は次の3つに分かれました。
閲覧支援型：画面表示だけで記録を変えません。要約はここに当たり、Save to Work notesを押さない限り記録に影響しません
下書き生成型：人が確認してから記録や公開に進みます。解決メモ・KB生成・Incident activity response generationはこの段階に当たります
記録・公開への反映型：Insertや保存を経て記録そのものになります。応急処置と恒久対応の区別のような欠落があると、そのまま記録に残るリスクが上がります
感情分析・Email recommendation・Deflection Query Rephraseは、生成結果の品質や標準画面での表示まで確認できなかったため、この3種類には入れていません。重大インシデントのメール文面推奨、NACM経由の機能（Incident cluster summaryなど）、チャット関連の2スキルも同様です。詳しくは前節のとおりです。
お客様ごとに順番を決める軸は、記録を変えるかとレビューにどれだけ手間がかかるかです。KB生成で見たように、description欄が実態と食い違う環境ほど、生成物のレビュー負荷は上がります。
広げる前に利用量を確認する
この環境に残っていた要約44件のログは、全件が試用のアシスト1件（trial_assists=1、assists=0）として記録されていました。この記録が契約上の課金額にどう反映されるか、再生成が同じ消費として数えられるかは確かめていません。
導入検討では対象ユーザー数と想定実行回数を仮に置き、契約と公式な利用量の定義を確認するとよいでしょう。仮に1日20件を3人が開くなら、要約だけで月1,000回ほどになる試算です。
まとめ
今回の3件・生成18回だけでは、カスタム開発に進むべきとは判断できません。データ品質・標準設定・レビュー運用を切り分け、それでも繰り返す不足だけをカスタム要件として定義します。前節で生成や画面表示まで確認できなかった機能も、原因を特定してから開発の要否を決めます。
もう1つ見えたのは、レコードの書き方と出力の関係が一様ではない点です。日本語のレコードは未確認の仮説をそのまま書き、応急処置と恒久対応を分けて記録し、推測の確定扱いと両者の混同を防いだように見えます。ただし効果がなかった手順の記録は、要約では保たれた一方、解決メモとKB下書きでは崩れました。同じレコードから生成物ごとに違う誤りが出ており、書き方だけでは説明できません。1件・2件の比較で断定はできませんが、カスタマイズの前にレコードの書き方とレビュー体制を見る価値はあります。
OOTBを先に試す価値は「十分だから」ではなく、「何を作り、何を作らなくてよいかを議論できるようになる」からです。議論の材料には、製品の限界だけでなくレコードの書き方も含まれます。まずOOTBを知り、デモレコードで試し、それでも足りない部分だけを作りましょう。
付録
用語
スキル：Now Assistの機能の単位です。要約も解決メモも、それぞれ独立して有効・無効を持ちます
SOW（Service Operations Workspace）：ITSMの担当者向けワークスペースです
NACM（Now Assistコンテキストメニュー）：欄や選んだ文章に生成と調整を行うメニューです。公式ドキュメントではServiceNow Otto context menuと表記されます
アシスト：Now Assistの利用量を数える単位です
製品名は公式ドキュメント上では「ServiceNow Otto」ですが、画面の見出しやボタン名の多くはNow Assistのまま残っています。この記事は画面の表記に合わせます。
検証用に作成した日本語のレコード
今回の検証のために新規作成したインシデントの番号はINC0019287、件名は「記事検証: 勤怠打刻アプリからの打刻が断続的に失敗する」です。症状・作業メモ・コメントの中身は前半の「元にしたインシデントには何が書かれていたか」のとおりで、本文ではこの番号を繰り返さず件名やスクリーンショットで参照しています。
作成の27秒後、インスタンス側の自動処理が担当者欄への一時的な代入と取り消しを行い、状態をNewからIn Progressへ変更しました。デモ環境の既定の自動処理で、検証の操作によるものではありません。
Insert・Save・Sendはいずれも押していません。作成されたメールの宛先はすべて予約済みのexample.comドメインで、送信は行われていません。
試行の規模
英語レコード2件（空調故障・会話が残るインシデント、画面表示は英語）：空調故障は要約3回・解決メモ3回（判定は要約3回・解決メモ1回）、会話が残るインシデントはKB生成1回。すべて判定しました
日本語のインシデント1件（今回新規作成）・画面表示は英語：要約3回・解決メモ1回・KB生成2回（英語出力と、Language欄で日本語を選んだ出力）を実行し、6回とも判定しました
同じ日本語のインシデント・画面表示も日本語：要約3回・解決メモ1回・KB生成1回を実行し、本文で紹介しています
実行回数の合計は18回、判定したのは11回です（英語5回＋日本語・英語表示6回）。日本語表示の5回は本文で引用していますが、判定表には含めていません
所要時間（撮影した回数ぶん）
英語デモレコード: 要約18〜44秒・解決メモ43〜49秒・KB生成61秒（各3回、KBのみ1回）。感情分析は25秒待っても値が出ませんでした
日本語レコード: 要約25〜33秒・解決メモ42秒・KB生成67〜72秒（英語・日本語各1回）・作業メモへの応答生成は約31秒（有効化後に成功）
到達できなかった機能の操作記録
Major incident email content recommendation：「重大なインシデントに昇格」を確定すると状態はaccepted（承認済み）へ変わりました。連絡タブの3種のコミュニケーション計画（各3件のタスク）から「作成」でComposeを開くと、件名だけ自動入力されていました
Email recommendation：有効化してもメールタブの起動場所は「解決メモを生成」とリクエスト入力欄の2つのままで、約200秒探しても専用の起動場所は現れませんでした
Deflection Query Rephrase：有効化してSOWとサービスポータルの両方を見て回りましたが、提案の出る画面には到達できませんでした
ライセンス
製品には、スキルごとにサブスクリプションのプロファイルIDが登録済みです。要約・解決メモ・KB生成はsn_gen_ai_platform_fulfillerに紐づきます。区分の正式名は未確認で、契約範囲は契約書で確認します。
自分の環境で確認するときのURL
Now Assist Admin：/now/now-assist-admin/home
ITSMのスキル構成：/sn_nowassist_skill_config_list.do?sysparm_query=sys_scope.scope=sn_itsm_gen_ai
SOWの新規ナレッジ記事：/now/sow/record/kb_knowledge/-1
KB生成の対象の状態：/sys_properties_list.do?sysparm_query=name=com.snc.incident.create_knowledge.multistate.enable
検証範囲とおことわり
2026-09-19〜20に、Australia（Patch 5）のNow Assistデモ用インスタンスで確認しました。デモ用に追加・変更されたとみられるスキルとレコードは対象から外しています（該当0件）。中心の評価はデモレコード3件・生成18回（判定11回、内訳は付録「試行の規模」）です。生成や画面表示まで確認できなかった機能の確認では別の既存レコードも使いました。生成結果は表示までにとどめ、Insert・Save・Refine・評価は押していません。例外は重大インシデントの操作で、状態は空→proposed→acceptedと変わりました。今回確認した通知は送信失敗で、Compose由来の2件は宛先が空欄の送信無視でした。送信ボタンは押していません。
未確認のこと：
要約・解決メモの言語切り替えが画面以外（プロパティやスキル構成）にあるか
利用量の記録が課金額にどう反映されるか、再生成が同じ消費として数えられるか
推測の確定扱いと応急処置・恒久対応の混同を、日本語の書き方が防いだのか、たまたまかは確定できません
ライセンスのプロファイルIDが指す正式な区分名
解決メモ・KB生成・要約それぞれのレビューにかかる時間と正確さ
NACMのメニュー出現が回によって変わる理由
メール本文で6語以上を選択したときにEmail recommendationのアイコンが出るか
自社インスタンスに4種のAIコミュニケーションプランテンプレートがあるか
感情分析の値が付いたレコードを、担当者向けの標準画面で表示できるか
同じ番号のインシデントが複数ある環境のため、KB生成で番号を指定するときは表示中のレコードを確かめてください。画面の人名はデモデータの利用者です。
関連記事
インシデント管理モジュールの概要 — インシデント管理の全体像
Now Assist は標準で何が入っている？ 製品別のOOTBスキル一覧 — OOTBスキルの全体像
ナレッジ管理モジュールの連携機能 — ナレッジとのつながり
