ITSM（インシデント以外）のNow Assist機能紹介とOOTBのまま使えるかの検証
検証環境：Now Assist デモ環境（Australia Patch 5）/ OOTB / 2026-10-01 確認
スキルは有効化済みの環境で確認しました。出荷時点の初期状態は検証していません。
OOTBのまま試して分かったこと
リクエストは、申請・要求アイテム・カタログタスクの3か所に別々の要約スキルが付いている。どれも日本語の記録から要約を作れた
要約の事実関係は概ね保たれた。ただし生成のたびに状態の表現が揺れ、要求アイテムの要約1回で「承認済み」と「承認待ち」が同居した
作業メモの返信案は、別の作業メモの作成者のメールアドレスを本文に書き込み、記録にない助言も書き足した
変更の要約は、Assess状態にして初めて画面に出て、15秒で生成された。リスク説明は、リスクが算出されず動かなかった
インシデントのNow Assistを把握したあと、リクエスト管理や変更管理の提案を求められたら、最初に知りたいのは「標準で何が付いていて、どこまでそのまま使えるか」です。まずOOTBを確認し、データ・設定・運用で足りるかを調べ、それでも残る不足だけを開発の対象にします。その判断材料として、リクエストと変更のスキルを日本語の自作記録で動かしました。
試行の規模は小さく、ケーススタディです。記録は4件（変更1・申請1・要求アイテム1・カタログタスク1）で、要約は申請・要求アイテム・カタログタスクで各3回、返信案は要求アイテムで2種類を各1回、変更の要約は新規の変更1件で1回生成しました。合計12回です。OOTB全体の品質評価ではなく、実装判断に必要な観点を洗い出す目的で確認しました。
インシデント以外のITSM向けOOTBスキル一覧
この環境のITSMには、インシデント以外のスキルが25行入っています。内訳はリクエスト6・変更3・チャット3・ナレッジ1・リリース1・重大インシデント1・その他10です。
その他10は、Now Assistコンテキストメニュー（NACM）の構成5とクラスター要約2が中心です。残りは要約と対応案、Issue Readiness、Deflection Ticket Responseです。
製品共通のスキルは10行です。NACMの内部構成と、インシデント向けの構成を含めた数です。
表の内容を文字でも書き出します。
Request summarization（申請の要約）：申請の状況を短くまとめて確認できる
Requested item summarization（要求アイテムの要約）：要求アイテムの進捗と未了をまとめて確認できる
Catalog task summarization（カタログタスクの要約）：タスクの状況をまとめて確認できる
Request activity response generation（申請の返信案）：申請の作業メモやコメントの下書きを作れる
Requested item activity response generation（要求アイテムの返信案）：要求アイテムの作業メモやコメントの下書きを作れる
Catalog task activity response generation（カタログタスクの返信案）：カタログタスクの作業メモやコメントの下書きを作れる
Change request summarization（変更の要約）：変更の状況をまとめて確認できる
Change request risk explanation（変更のリスク説明）：変更のリスクが高い理由を説明できる
Change Risk Assessment Answer Generator（リスク評価の回答生成）：リスク評価の設問への回答を生成できる
Chat summarization（チャットの要約）：対話の内容をまとめて確認できる
Chat reply recommendation（チャットの返信推奨）：チャットへの返信案を出せる
Sidebar discussion summarization（サイドバー要約）：サイドバーの会話をまとめて確認できる
KB generation（KB生成）：解決内容からナレッジ記事の下書きを作れる
Generate Release Notes（リリースノート生成）：リリースノートの下書きを作れる
Major incident email content recommendation（重大インシデントのメール推奨）：重大インシデントの通知メールの文面を出せる
Incident cluster summary（インシデントクラスター要約）：関連するインシデントの群をまとめて確認できる
Summarize and Generate Plan in NACM（要約と対応案）：要約と対応案をまとめて出せる
Interaction cluster summary（インタラクションクラスター要約）：関連するインタラクションの群をまとめて確認できる
Issue Readiness（課題の準備状況）：AIエージェントが課題の準備状況を判断する際に使う
Deflection Ticket Response（転送応答）：転送先に返す応答を合成できる
NACM構成5行：返信案の内部構成3行と、インシデント向け2行
この環境で無効なのは、Sidebar discussion summarizationとDeflection Ticket Responseの2行です。残りは有効でした。
一覧のうち、今回動かした範囲
有効でも、実際に動いたとは限りません。一覧は広く、今回動かしたのは狭い範囲です。用途の幅を押さえるため、画面を読む（要約）、下書きを作る（返信案）、記録を説明する（変更のリスク説明）の3種類から選びました。
動かした：申請・要求アイテム・カタログタスクの要約、要求アイテムの返信案、変更の要約（Assess状態）
有効だが動かなかった：変更のリスク説明。リスクが算出されなかった
前提が要るため動かしていない：リスク評価の回答生成（ロールが前提）、リリースノート生成（Digital Product Releaseが前提）
動かしていない：申請とカタログタスクの返信案、Interaction cluster summary、Issue Readiness、Deflection Ticket Response
別記事の対象：チャット・KB生成・重大インシデント・インシデントのクラスター要約・NACMの要約と対応案の9行
別記事で扱った9行は、インシデントのNow Assist機能紹介とOOTBのまま使えるかの検証に結果があります。本記事では再検証していません。
元にした記録には何が書かれていたか
生成物を見る前に、元の記録の中身を説明します。件名はすべて「記事検証:」で始まります。担当者や依頼者は、メールアドレスを持たず通知も無効にした検証用ユーザーです。
変更（CHG0030003）
件名は「会計システムの月次バッチ実行時刻を22時から23時へ変更する」です。経理部の月次締めバッチが朝の業務開始に間に合わない日があり、開始を1時間遅らせる内容でした。種別はNormalで、状態はNewのままです。変更理由には「集計DBの夜間バックアップと重なるためと考えられるが、確認はしていない」と書きました。バックアウト計画には「戻しの手順書はできているが、レビューはまだ終わっていない」と書いています。
申請（REQ0010035）
件名は「経理部の新入社員向け会計ソフトの導入依頼」です。コメントに「当初は3名分の依頼でしたが、追加で1名の配属が決まったため、4名分に変更してください」とあります。作業メモは「4名分に変更された件を要求アイテムに反映済み。ライセンスの残数は要求アイテム側で確認している」です。標準の自動承認（価格1,000ドル以下）が働き、要求状況は承認済みでした。
要求アイテム（RITM0010113）
カタログアイテムは「ソフトウェアのインストール」です。作業メモには、会計パッケージのライセンス残数が2件しかなく、4名分に足りないと書きました。不足する2件は調達部門へ調達を依頼済みで、納期の回答はまだありません。
カタログタスク（SCTASK0010015）
件名は「会計パッケージの配信設定」です。作業メモには、4台中3台に配信設定を適用して正常に完了し、残り1台は配信に失敗したと書きました。失敗の原因はネットワークの可能性があるが、ログは確認していない、という内容です。
この4件には、後半の判定で軸になる点があります。申請の下に要求アイテム、その下にカタログタスクがつながり、事実によって書かれている記録が違います。
起点は申請、橙は子の記録にだけ書かれた事実、紫はリクエストとは別系統の変更
図の内容を文字でも書き出します。
申請：人数が3名から4名に変わっている。作業メモは「残数は要求アイテム側で確認している」だけ
要求アイテム：ライセンスの残数2件は4名分に足りない。不足分は調達依頼中で、納期は未回答（要求アイテム側にだけ書いてある）
カタログタスク：配信に失敗した1台の原因は推測で、ログは未確認（タスク側にだけ書いてある）
変更：遅延の原因は確認していない仮説。バックアウト手順のレビューは、まだ終わっていない
生成物がこれらをどう扱うかが、次の章からの評価の軸になります。
判定の基準と、読み方
評価は、生成物を元の記録と突き合わせて行います。見るのは、事実が合っているか、抜けや書き足しがあるか、直すのにどれだけ手がかかるかです。修正量は次の4段階で判定しました。
修正なし：文章を変えずに目的に使える
軽微：事実関係は変えず、語句や表現だけ直す
大幅：原因・状態・対応・結論など、業務判断に関わる内容の追加・削除・訂正が要る
不採用：元の記録との照合や全面的な書き直しが要り、下書きとしての効果が薄い
レビューの負担も見ます。元の記録を全部読み直す必要があるか、要点の照合で済むかです。修正にかかった時間は計測していません。
Now Assist「Request summarization」の検証
Request summarization（申請の要約）は、申請（sc_request）の状況を1つにまとめるスキルです。担当者のワークスペース（SOW）で申請を開くと「AIサマリー」のカードが出て、「生成」を押すと要約が作られます。
申請の要約を3回生成しました。所要時間は15.0〜31.3秒です。
①の要約は、依頼者・優先度・価格・要求アイテムの番号に続けて、「4名分への変更が反映されており、ライセンスの残数も確認されています」と書いています。元の記録（②の作業メモ）と一致しています。3回とも4名への変更は反映されました。
ライセンスの不足は、3回とも要約に出ませんでした。元の申請の作業メモは「残数は要求アイテム側で確認している」としか書いておらず、不足そのものは要求アイテムにだけあります。したがって要約に誤りはありません。ただし、申請だけを開いた人は、ライセンス不足に気づけません。
判定は3回とも軽微です。事実の誤りはなく、直すのは敬称や言い回しだけでした。用途は申請単体の一覧的な把握です。ライセンス不足のような子の記録の事実が要るなら、要求アイテムも開く必要があります。レビューは、申請の作業メモと要約を照合する程度で済みました。
Now Assist「Requested item summarization」の検証
Requested item summarization（要求アイテムの要約）は、要求アイテム（sc_req_item）の進捗と未了をまとめるスキルです。レコードを開くと、申請と同じ「AIサマリー」のカードから生成します。
要求アイテムの要約を3回生成しました。所要時間は15.6〜23.5秒です。
①の要約は、3回とも不足（4名分に対して2件）と、調達依頼済み・納期未回答を正しく拾っていました。元の作業メモの中心は、そのまま引き継がれています。
状態の書き方は揺れました。1回目と3回目は「承認済みの段階」で一貫しています。2回目は「承認済みの段階」と書いたあと、末尾に「リクエストは現在、承認待ちの段階」と書き、同じ要約の中で矛盾しました。3回目はカタログタスクの状態を「進行中」と書いていますが、実際はオープンです。
判定は、1回目が軽微です。2回目は承認状態の矛盾、3回目はタスクの状態の取り違えがあり、どちらも状態の訂正が要るため大幅です。引き継ぎに使うなら、状態の記述は画面の項目と照合します。今回のレビューは、要点と状態の項目を見比べる作業でした。
Now Assist「Catalog task summarization」の検証
Catalog task summarization（カタログタスクの要約）は、カタログタスク（sc_task）の状況を要約するスキルです。
要約を3回生成しました。所要時間は18.0〜21.8秒です。
①の作業内容は、3回とも原因の扱いを保ちました。失敗の原因は「ネットワークの可能性が推測されて」おり、「ログの確認はまだ行われておりません」と続いています。推測を確定に書き換える誤りは、今回の3回では起きませんでした。
気になったのは文体です。「おります」「ございます」が続き、丁寧さが過剰です。依頼者の氏名にも「様」が付いています。内部の担当者向けの文面としては堅すぎます。
判定は3回とも軽微です。事実は合っていて、語句を直せば使えます。レビューは要点の照合で済みました。
Now Assist「Change request summarization」の検証
Change request summarization（変更の要約）は、変更の状況をまとめて表示するスキルです。公式ドキュメントは、状態がNewやCanceledでは「Summarize」が出ないと書いています。元の変更（CHG0030003）はNewのままで、公式の記述どおり要約は画面に出ませんでした。
そこで、同じ内容の変更を新しく1件作り、状態をAssessにして開きました。画面の上部に「Now Assist によってこの 変更要求 の要約が可能です」という帯と「要約」ボタンが現れ、押すと15.3秒で生成されました。
①の達成目標は、バッチの開始を22時から23時へ遅らせる目的と、対象がサーバー1台のジョブ設定だけであることを書いています。遅延の原因は「集計DBの夜間バックアップとバッチ実行が重なっている可能性があるため」で、記録で「確認はしていない」とした仮説が、「可能性」のまま残りました。②の計画は、検証計画に続けて、バックアウト手順のレビューが「まだ完了しておりません」と書いています。
折りたたまれた先のリスクの節には、2点が書かれています。1点目は、開始時刻の変更で「月次バッチの完了時間が想定より遅延し、翌朝の業務開始に影響を及ぼす可能性」で、記録には書かれていない推測です。2点目はバックアウト手順のレビュー未完了で、記録どおりの内容です。スケジューリングの競合は「未実行」、影響を受けるCIとサービスは「該当なし」と出ています。
判定は軽微です。仮説と未了は記録のとおりで、事実関係の訂正は要りませんでした。リスクの節の1点目だけは、記録にない文のため、採用するかどうかを変更の担当者が決めます。修正にかかった時間は測っていません。
Assessにすると承認が動き、リスク説明は動かなかった
状態をAssessへ進めた直後に、次の2つが自動で作られました。
承認の記録1件。承認者は検証用ユーザーで、承認は操作していない
承認者あてのメール送信1件。宛先は example.com のため、送信失敗になった。実在の宛先には届いていない
要約を使うために状態を進める場合、承認と通知が同時に動きます。導入前に、承認者と通知先を確かめておきます。
Change request risk explanation（変更のリスク説明）は、Assessにしても動かせませんでした。「リスクの詳細」には「現在のレコードに一致するリスク条件はありません」「算出されたリスクスコアに失敗しました」と出て、リスクが未算出のままでした。説明の起動には、リスクが算出されることが前提になります。
Now Assist「Requested item activity response generation」の検証
Requested item activity response generation（要求アイテムの返信案）は、要求アイテムの作業メモやコメントの下書きを作るスキルです。作業メモ欄のアイコンから起動し、選択肢を1つ選ぶと、プレビューに下書きが出ます。
公式ドキュメントは選択肢を4つ（Acknowledge task・Post response・Summarize actions taken・Follow up）と説明しています。この環境の作業メモ欄に出たのは、次の2つだけでした。管理者の設定で選択肢が変わるとも書かれています。
実行されたアクションを要約
応答後
「実行されたアクションを要約」を選ぶと、39.2秒で下書きが出ました。
①の下書きは、作業メモの内容をよく拾っていました。ライセンスが2件で4名分に足りないこと、不足分の調達依頼、納期が未回答であること、の4点です。
一方で、先頭の文に、作業メモの作成者（ログインしているユーザー）のメールアドレスが入っていました。元の作業メモには、アドレスは書かれていません。生成が、作成者の情報を文中に書き込んだことになります。
この下書きを挿入し、さらにPostすると、個人情報がアクティビティの記録に残ります。挿入の前に、アドレスの有無を確認して削除するレビューが要ります。判定は、事実関係が作業メモと一致しているため軽微の範囲です。ただし、個人情報の削除が必須なので、修正なしでは使えません。
「応答後」は、50.5秒で下書きが出ました。
①の下書きは、調達の依頼済み・納期未回答を述べたあとに、「調達部門への進捗確認を実施し、納期見込みを早急に把握することをお勧めしま…」と書いています。作業メモには、こうした助言はありません。利用者への返信ではなく、内部向けの助言の口調です。本文は画面上で途中で切れており、途中までしか確認できていません。
確認できた範囲の判定は大幅です。記録にない助言が追加されており、業務判断に関わる内容の追加にあたります。全文の評価は保留します。②の挿入ボタンは押していません。
レビューの負担は、元の作業メモ全体との照合です。助言が妥当かどうかの判断には、調達部門の運用を知る担当が要ります。挿入まで進めた場合の時間は、計測していません。
有効でも出ない条件は、先に決めておく
有効にしてあっても動かなかったもの、または動かすのに条件が要ったものは、次のとおりです。
変更の要約：変更の状態がNewやCanceledでは出ない。Assess以降で出る
変更のリスク説明：リスクが算出済みでないと、アイコンが出ない
リスク評価の回答生成：公式ドキュメントのロールはsn_change_writeとchange_manager。今回の担当者には付与していないため、動かしていない
リリースノート生成：Digital Product Releaseのリリースとスコープデータが前提。今回は動かしていない
チャットの要約・返信推奨：Virtual Agentから有人チャットへ引き継がれたセッションが前提
正規ルートで使うには、導入時に4点を決めます。記録の状態（Assess以降）、リスクの算出方法、担当者へのロール付与、リリースの進行状態です。
作業メモ欄の選択肢が2つだったことも、注意点です。公式ドキュメントの4択を前提に提案すると、画面と食い違います。選択肢は管理者の設定で変わるため、導入前に自社の設定を確認します。
OOTBスキルは4つに仕分けられる
今回の結果を、機能の種類ごとにA・B・C・Dの4つに仕分けます。Aは改変せずに使えた範囲、Bは設定や運用の調整で足りる範囲、Cは準備や開発が要る範囲、Dは今回は判断できなかった範囲です。
緑は改変せずに使えた種類、橙は挿入前のレビューが要る種類、青は前提の準備が要る種類、灰色は判断を保留した種類
A. 回答を表示するだけの機能
申請・要求アイテム・カタログタスクの要約が当たります。記録を書き換えないため、最初に導入しやすい種類です。利用者の権限（ロールはitil）と、要約を見る画面（SOWのAIサマリー）を決めれば使えます。例えば今回のRequested item summarizationは、スキルの設定を変えずに動きました。ただし生成のたびに状態の書き方が揺れ、大幅な訂正が必要な回もあったため、引き継ぎに使うなら状態の項目と見比べる運用が要ります。
B. 下書きを作り、人が挿入する機能
返信案が当たります。記録に入る前に人の確認を挟めますが、確認の負担は大きくなります。例えば今回のRequested item activity response generation（要求アイテムの返信案）は、作成者のメールアドレスの混入と、記録にない助言の書き足しがありました。導入前に、挿入前に見るべき点を決めます。選択肢も、自社の設定を確認します。
C. 前提の準備が要る機能
変更の要約とリスク説明、リスク評価の回答生成、リリースノート生成、チャット関連が当たります。前提になるのは、記録の状態とリスクの算出です。ロールや別製品の設定も前提になります。例えば今回の変更の要約は、状態をAssessにするまで出ませんでした。リスク説明は、リスク未算出のため動きませんでした。
D. 今回は判断できなかった機能
Interaction cluster summary、Issue Readiness、Deflection Ticket Responseが当たります。説明が空のものがあり、用途は名称と適用条件からしか言えません。動かしていないため、判断を保留します。
その不足は本当にカスタマイズ対象か
前の章で見えた不足を、データ・標準設定・運用・カスタマイズの順に切り分けます。
起点はデータ、青は標準設定と運用で切り分ける段階、橙は最後に残す段階
データ
申請の要約がライセンス不足に触れなかった原因は、元の作業メモにありました。不足を申請側にも書けば、要約に出る可能性があります。ただし、書き方を変えて比べてはおらず、これで解消するかは確かめていません。候補にとどまります。
標準設定
変更の要約・リスク説明が出ない条件は、リスクを算出するプロパティと、記録の状態で決まる。公式ドキュメントに従って、管理者が設定を確認する
作業メモ欄の選択肢は、管理者の設定で変わる
誰が使えるか（ロール）は、AI Admin Hubで変更できる
運用（レビュー）
挿入や共有の前に、次の順で確認します。
用途（引き継ぎ・記録・利用者への返信）を決める
生成結果と元の作業メモを突き合わせ、抜け・誤り・書き足しを記録する
個人情報（メールアドレスなど）が入っていないか見る
状態の記述を、画面の項目と照合する
カスタマイズ（コピーしてからの変更）
要約の出力項目を増やすなら、スキルをコピーして変更します（Customize Request Management summarization skill）。コピーした版に将来の更新がどう入るかは、確かめていません。
作成者のメールアドレスの混入を防ぐ指示を、プロンプトに足すのは候補です。今回は変更しておらず、これで解消するかは確かめていません。
カスタム化して増える管理対象
OOTBのスキルにも、品質確認・利用量確認・レビュー・アップグレード後の挙動確認は元々要ります。コピーを持つと、その上に次が増えます。
構成管理：入力項目・出力の設定を記録する
プロンプトの変更履歴：追加した指示をいつ・誰がなぜ入れたか残す
回帰試験：アップグレードのたびにコピーを動かし直す
差分の確認：OOTB版が更新されたとき、コピー版との差を見る
コピーの有効化とテストは、AI Admin Hubの管理権限を持つ担当の役割です。
お客様への提案を3層に分ける
リクエストと変更の提案は、次の3層に分けて出せます。
OOTB：申請・要求アイテム・カタログタスクの要約。回答を表示するだけで、記録を書き換えない
標準設定・運用：状態を見るレビュー、個人情報の確認、リスク算出の設定、ロールの付与、作業メモ欄の選択肢の設定
個別開発：要約の出力項目の追加、返信案の文面の制御。レビューを重ねても繰り返し不足するものだけ
導入の順は、記録への関わり方で決めます。回答を表示するだけの機能は、利用者の権限と起動の画面を決めれば始められます。下書きを作って人が挿入する機能は、挿入前のレビューの負担を見積もってから広げる、という順です。
まとめ
今回の4件の記録では、リクエストの要約は日本語でもOOTBのまま動き、導入検討の候補にできました。申請・要求アイテム・カタログタスクの3回ずつの生成で、未確認の推測を確定に書き換える誤りは起きていません。一方、状態の矛盾や、子の記録の事実が親に出ない点があり、照合が欠かせません。
返信案は、個人情報の混入と、記録にない助言の書き足しがありました。変更のスキルは、記録の状態とリスク算出の前提が整わないと動きません。
4件・生成12回だけでは、カスタム開発に進むべきかは判断できません。データ・標準設定・運用を切り分け、それでも繰り返す不足だけを開発要件にします。
付録
用語
スキル：Now Assistの機能の単位。要約も返信案も、それぞれ独立して有効・無効を持つ
SOW（Service Operations Workspace）：ITSMの担当者向けワークスペース
NACM（Now Assistコンテキストメニュー）：欄や選んだ文章に生成を行うメニュー
申請・要求アイテム・カタログタスク：申請（sc_request）の下に要求アイテム（sc_req_item）があり、その下にカタログタスク（sc_task）がつながる
製品名は公式ドキュメント上ではServiceNow Ottoですが、画面の見出しやボタン名の多くはNow Assistのままです。この記事は画面の表記に合わせます。
検証用に作成したレコード
変更はCHG0030003、申請はREQ0010035、要求アイテムはRITM0010113、カタログタスクはSCTASK0010015です。Insert・Save・Post・Sendは押していません。検証用ユーザーはメールを持たず、通知は無効です。自作の記録に紐づく送信メールや承認は、変更の要約を動かす前の確認では0件でした。要約を動かすために作った変更では、承認1件と、example.com宛ての送信失敗メール1件が作られ、確認後に変更ごと削除しています。
試行の規模
申請の要約3回、要求アイテムの要約3回、カタログタスクの要約3回
要求アイテムの返信案は、「実行されたアクションを要約」と「応答後」を各1回
変更の要約は、Assess状態の新規の変更で1回（リスク説明は動かず）
合計12回。12回とも元の記録と突き合わせて判定
所要時間
生成の所要時間は、「生成」を押してから表示までです。
申請の要約：15.0〜31.3秒（3回）
要求アイテムの要約：15.6〜23.5秒（3回）
カタログタスクの要約：18.0〜21.8秒（3回）
返信案：実行されたアクションを要約は39.2秒、応答後は50.5秒（各1回）
変更の要約：15.3秒（1回）
到達しなかった機能
Change Risk Assessment Answer Generator：ロールの付与が設定変更になるため、動かしていない
Generate Release Notes：Digital Product Releaseのリリースとスコープデータが要るため、動かしていない
Sidebar discussion summarization / Deflection Ticket Response：このデモ環境では無効
構成表のDeprecated列とステータス表の値は、いくつかのスキルで食い違っていました。判定にはステータス表を使っています。
ライセンス
製品には、スキルごとにサブスクリプションのプロファイルIDが登録されています。今回のスキルが紐づく区分は、確認していません。契約範囲は契約書で確認します。
自分の環境で確認するときのURL
ITSMのスキル構成：/sn_nowassist_skill_config_list.do?sysparm_query=sys_scope.scope=sn_itsm_gen_ai
スキルのステータス：/sn_nowassist_skill_config_status_list.do
リスクのプロパティ：/sys_properties_list.do?sysparm_query=name=glide.ui.risk_calculate_rule
公式ドキュメント：
実機を見て気づいたこと
親の要約には、子の事実が上がってこない
申請の要約は、ライセンス不足に触れませんでした。不足は要求アイテムにだけ書かれています。申請の要約の入力項目は、公式ドキュメントによれば申請自身の項目で、子の作業メモは入りません。
申請だけを開いて状況をつかむ運用では、不足に気づけません。重要な事実を親の作業メモにも書くのは候補になります。今回は追記後の生成を試していないため、要約に反映されるかは追加の確認が要ります。
要約は文面より、状態が揺れる
要求アイテムの要約は、事実の拾い方は安定していました。揺れたのは状態の書き方です。承認済みと承認待ちが同居した回がありました。
引き継ぎに使うなら、状態は要約でなく画面の項目を正とします。
返信案は、作成者の情報と助言を足す
返信案は、作業メモにないメールアドレスと助言を足しました。挿入の前に、個人情報の有無と、助言の根拠を見ます。選択肢が2つだけなのも、この環境の設定です。
検証範囲とおことわり
2026-10-01に、Australia（Patch 5）のNow Assistデモ環境で確認しました。作成者・更新者の名前から、共用デモ環境の利用者による追加・変更と判定できるスキル構成は、対象にしていません（該当0件）。独自変更の有無を完全に確かめたわけではありません。記録は自作の日本語レコード4件、生成は合計12回です。生成結果は表示までにとどめ、Insert・Save・Post・Sendは押していません。
Teams連携のイベント（sn_now_teams_it.*.commented）が、未処理（ready）の状態で出ていました。確認した範囲では、外部への送信ログにTeamsを含む記録が0件で、外部送信は確認されませんでした。
未確認のこと：
生成ログのテーブルで、画面で動かした機能とスキルの対応を突き合わせていない
応答後の下書きの全文（画面上で途中で切れた）
変更のリスク説明の出力（Assessにしてもリスクが算出されず、動かしていない）
変更の要約は1回の試行で、状態や記録の内容を変えた場合は確かめていない
Assessにしたときの承認と通知の動きは、検証用ユーザーの1件だけで、承認者が実在の人の場合は確かめていない
Change Risk Assessment Answer GeneratorとGenerate Release Notesの動作
要約の利用量が、契約上の課金にどう跳ね返るか
返信案の選択肢が、出荷時の既定でも2つなのか
申請・要求アイテム・タスクの返信案（要求アイテム以外）
