Now Assist の生成機能と入力の質：実機で測った7つの結果

インシデントの記録が件名と1文だけだったら、Now Assist の要約や解決メモはどうなるのでしょうか。記録が薄いと、記録に無い作業と原因が書かれました。記録を厚くしても、解決メモは未確認の仮説を確定した原因として書き、まだ終わっていない依頼は済んだ形に変わりました。書く時間は半分ほどに縮みます。記録の厚さを変えて要約・解決メモ・ナレッジ記事を生成し、元の記録と1文ずつ照らし合わせた7つの測定の結果を、この記事にまとめます。出力ごとに、そのまま使うか、確認して使うか、まだ使わないかも決めました。

測って分かったこと

• 件名と1文しかない記録に頼むと、記録に無い作業と原因が書かれた

• 要約は、記録にある未確認の仮説を仮説のまま残した。同じ仮説を、解決メモは確定した原因として書いた

• 保守会社への依頼が未了という記録は、要約と解決メモで「依頼し」と済んだ形に変わった。再生成しても直らなかった

• 手作業とAIの合計時間は、試算で約45.3分と約21.7分（−52%）。手作業もAIの最終版と同じ見出し・項目で書く前提。下書きができるまでは大きく縮み、使える形に直すまでの時間が残った。4作業ともAIが短い

• 狙って実行した要約33回に対し、使用量のログは72行。レコードを開いただけで要約が増えた

• 日本語のナレッジは、英語表示の利用者の検索に出なかった。分類エージェントは12件中11件で期待した分類と一致した

起点は元のインシデントの記録、青は生成される文章、橙は元の記録と照らし合わせる箇所、緑は追記や軽い確認で足りた箇所です。

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

• 元のインシデントの記録から、要約・解決メモ・ナレッジ記事の3つが生成される

• 要約：発生時刻が入っているか（軽い確認で足りた）／未了の依頼が「依頼し」に変わっていないか（照らし合わせる）

• 解決メモ：原因欄が仮説の確定になっていないか／手順に効果のなかった対応や済みになった依頼が入っていないか（どちらも照らし合わせる）

• ナレッジ記事：原因・手順・状態の3欄を元の記録と照らし合わせる／記録に無い再現手順・助言が入っていないか（照らし合わせる）／件名と症状の文章（軽い確認で足りた）

画面でも確かめられます。次の画像は、Wi-Fi の記録から解決メモを生成した画面です。①は原因の欄、②は再起動の手順、③はベンダーへの問い合わせの手順で、いずれも元の記録と照らし合わせる箇所です。

測った機能の範囲

対象は、インシデントまわりで有効だった次の機能です。

• Incident summarization（インシデント要約）：有効。レコードを開くと自動で動く。4つの測定で動かした

• Resolution notes generation（解決メモ生成）：有効。解決メモ欄のボタンで動く。4つの測定で動かした

• Generate KB article body（ナレッジ記事本文の生成）：有効。ナレッジ作成画面で依頼文を送ると動く。3つの測定で動かした

• Incident activity response generation（利用者への返信案）：無効だったため、手作業との比較の間だけ有効にして動かした

• AI Skill Kit のテスト実行・申請系の要約（Request・Requested item・Catalog task）：有効。利用量の測定だけで動かした

• Now Assist Multi-Content Response（検索の回答カード）：有効。検索のされやすさの測定で動かした

• Categorize ITSM incident AI agent（分類エージェント）：有効。分類の推定の測定で動かした

中心に置いたのは要約・解決メモ・ナレッジ記事の3つです。担当者が引き継ぎ・解決・ナレッジ化で毎日書く文章だからです。文章を作る5つの測定では、挿入・保存・公開・メール送信を実行していません。検索の測定では、閲覧を検証用ユーザーに絞ったナレッジ記事を公開しました。分類の測定では、エージェントが検証用インシデントの分類の欄に書き込んでいます。

7つの測定の一覧

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

• 記録の厚さは、架空のインシデント3件×各3回。薄い記録では記録に無い作業を補った

• 再生成は、2件×各10回（解決メモは5回）。発生時刻は20回中0回。依頼の未了は10回中10回、完了した形に変わった

• 手作業との比較は、1シナリオ、AIは各スキル3回。合計は手作業45.3分、AI21.7分（−52%）

• ナレッジ記事の品質は、Wi-Fi 3回・複合機 2回。必須事実は7件中1件、8件中3件

• 利用量は、5系統の実行。要約33回に対し72行

• 検索のされやすさは、記事5件×質問5種×各3回。英語表示の利用者には日本語の記事が0件

• 分類の推定は、12件×1回。一致はエージェント11件、ルール9件。担当グループは対象外

文章と利用量の5つの測定

数字を読む前提として、各測定の範囲を書きます。

記録の厚さは、同じ障害を3段階の記録で作りました。件名と1文だけ（A）、標準的な記録（B）、仮説や未了の対応まで書いた記録（C）です。要約と解決メモを各3回ずつ採点し、誤りの出方を比べています。Cには、仮説は未確認、再起動は効果なし、保守会社への依頼は未了という3つの事実を入れてあります。

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

• 記録A（件名と1文だけ）：要約は記録に無い作業を3回とも書き、解決メモの原因欄にも記録に無い内容を3回とも書いた

• 記録B（標準的な記録）：要約は事実8件中7件が入り、誤りは0件。入らなかったのは発生時刻だけ

• 記録C（仮説・効果なしの再起動・未了の依頼まで書いた記録）：要約は仮説のまま（3回、再生成10回とも）。解決メモは原因を確定として書き（3回とも）、ナレッジ記事は仮説が「根本原因」に入った（2回とも）

再生成は、標準的な記録（B）と仮説や未了の対応まで書いた記録（C）の要約を各10回、連続して実行しました。Cの解決メモは5回です。再生成で何が変わり、何が変わらないかを見る測定です。

手作業との比較は、Wi-Fiが切れる件を1シナリオ作りました。引継ぎ要約・利用者への返信文・解決メモ・ナレッジ記事をAIで生成し、手作業の版と比べています。返信文は、無効だった返信案のスキルを試す間だけ有効にして生成しました。AIの生成時間だけが実測で、手作業の時間は標準値から出した試算です。

ナレッジ記事の品質は、Wi-Fiの記録と複合機の記録の2件から、ナレッジ記事を生成しました。成功した回（Wi-Fiは3回、複合機は2回）を採点しています。Wi-Fiの記録では、手作業で書いた記事と同じ物差しで並べました。

利用量は、先行する測定で動かした実行を含む5系統について、使用量のログと生成のログの行数を見比べました。請求額は扱っていません。

仮説の扱い

同じ記録に書かれた「未確認の仮説」の扱いは、スキルで分かれました。

• 要約：仮説や未了の対応まで書いた複合機の記録（C）の3回で、旧パスワードの仮説は仮説のまま。再生成の10回でも、10回とも仮説のままだった

• 解決メモ：同じ記録から3回生成すると、3回とも原因を確定として書いた。別の5回でも、5回とも確定だった

• ナレッジ記事：複合機の記録の2回とも、仮説が「根本原因」の位置に入った

要約は、問題とアクションをまとめる形で、仮説専用の欄がありません。解決メモとナレッジ記事は、原因の欄が先に用意された形式です。欄を埋める形式が、仮説の確定扱いにつながったと私は見ています。ただし出力形式との関係は確かめておらず、見立てにとどまります。

ナレッジ記事の生成画面では、複合機の記録から作られた本文に「原因（根本原因）」の見出しが立ちます。画像の①は概要の書き出し、②は原因（根本原因）の見出し、③は言語の欄で、English が選ばれています。

未了の依頼の扱い

複合機の記録には、保守会社への依頼が未完了だと書いてありました。

• 要約：3回とも「依頼し」に変わった。再生成の10回でも、10回とも変わった

• 解決メモ：3回とも、5回とも、依頼が済んだ形になった

• ナレッジ記事：「完了した」とは書かれなかった。ただし状態の記述が消え、「依頼して実施してもらいます」という手順になった

効果のなかった再起動も、ナレッジ記事の手順に入りました。複合機の記録では2回とも先頭に並び、Wi-Fi の記録でも2回とも手順に入っています。要約では、再起動が効果なしだった点は保たれていました。

再生成で変わったのは、語尾と周辺の事実です。標準的な記録（B）の要約は10回とも、事実8件のうち同じ7件を拾い、長さは279〜301字で一定でした。仮説まで書いた記録（C）の要約は2つの形に分かれました。コピーと印刷の可否や期限まで入る長い形が3回（うち2回は期限の理由も入った）、入らない短い形が7回です。

発生時刻の欠落と依頼の状態の誤りは、再生成後も残りました。発生時刻は、要約20回のうち0回しか入りませんでした。誤りの向きが同じなので、再生成を重ねて直す見込みは、今回の範囲では立ちません。

生成物ごとの誤りの出方は、次の表のとおりです。

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

• 要約は、仮説は仮説のまま残る。未了の依頼は済みに変わる。効果なしの対応は残る

• 解決メモは、仮説は確定した原因になる。未了の依頼は済みに変わる。効果なしの対応は手順に入る回がある

• ナレッジ記事は、仮説は根本原因になる。未了の依頼は状態の記述が消える。効果なしの対応は手順に入る（複合機では先頭）

表は複合機の記録での結果です。Wi-Fi の記録では、ベンダーへの問い合わせの回答待ちが要約に残りました。ナレッジ記事の3回目は、未確認の要因を別の項目に分けています。

記録が薄い場合

件名と1文だけの記録（A）では、要約が「確認しました」「調査を進めています」と、記録に無い作業を3回とも書きました。解決メモの原因欄は、「共有フォルダへの保存設定に不備」と、記録に無い内容を3回とも作り出しています。標準的な記録（B）の要約は、事実8件のうち7件が入り、誤りは0件でした。入らなかったのは発生時刻だけです。

画像は、記録A（件名と1文だけの記録）から生成した要約の画面です。①と②が、記録に無い作業を書いた箇所です。③は元の記録の説明欄で、営業部の利用者からスキャンした文書が保存されないという連絡が、1文だけ入っています。

生成にかかった時間

生成にかかった時間は、測定ごとに次の範囲でした。

• 要約：15.6〜31.9秒

• 解決メモ：48.2〜62.9秒

• ナレッジ記事本文：成功した5回で72.4〜83.4秒

同じ環境を別の作業が使っていた時間帯があるため、参考値です。

手作業との比較

下書きができるまでの時間が縮みます。使える形に直すまでは、AIのほうが長くなります。

1シナリオで手作業と比べました。4つの作業の合計は、試算で手作業約45.3分、AI約21.7分で、約23.6分の短縮になります（−52%）。手作業側は、AIの最終版と同じ見出し・項目の構成で、同程度の長さの文章を書く前提にしています。見出しと項目の並びを考えて整える時間として、1つあたり5秒と2.55秒（仮定）を入れました。人が書いた文章にも手直しが要るという仮定（100字あたり1箇所、書き直す文字は10%）も入れています。

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

• 引継ぎ要約は、手作業10.1分、AI3.4分。6.7分短い（−67%）

• 利用者への返信文は、手作業7.3分、AI3.6分。3.7分短い（−51%）。生成された文章に、宛名と発生日時など97字を足した

• 解決メモは、手作業8.8分、AI5.7分。3.0分短い（−34%）

• ナレッジ記事は、手作業19.2分、AI9.0分。10.2分短い（−53%）

• 合計は、手作業45.3分、AI21.7分。23.6分短い（−52%）

時間を2つの段階に分けると、差の出どころが分かります。

1. 下書きができるまで：4作業の合計で手作業が約34.4分、AIが約4.3分（−88%）。AIの下書きは、ボタンを押してから24〜78秒で表示される（実測）

2. 使える形に直すまで：手作業が約10.9分、AIが約17.4分で、AIのほうが長い（+60%）。生成された文章を読み、元の記録と照合し、足りない事実を書き足すため

解決メモは、生成された文章を大きく直したため、削減率が最も小さくなりました（−34%）。追記は、解決メモが約200字、ナレッジ記事が約240字でした。

ナレッジ記事は、生成された1,328字の見出しと手順の骨組みがそのまま使えます。比べた手作業版は、同じ19の見出し・項目を持つ904字の記事です。これを書く時間（約19.2分）より、読んで直すAIの時間（約9.0分）のほうが短くなりました（−53%）。最初に書いた532字の手作業版と比べた場合は、ナレッジ記事だけAIのほうが長い試算でした。追記した文字のうち、作業メモの文と一致する部分は貼り付けとして数えました。残りは自分で書く時間として数えています。

条件を動かすと、差は変わります。

• 入力速度・黙読速度・見直す割合の27通り：合計でAIが遅くなる組み合わせは出なかった

• 作業別に見る：入力・黙読の9通りすべてで、4作業ともAIが短い。差が最も小さいのは返信文と解決メモ（入力80字/分・黙読800字/分で約2.3〜2.4分）

• 手作業に有利でAIに不利な側に寄せる：手作業29.1分、AI16.4分で、差は12.8分

• 逆の側：手作業73.6分、AI32.1分

• 手作業の手直しの量を0%・20%にすると、合計の差は19.0分・28.1分

• 見出しと項目の並びを考える時間を×0.5・×2にすると、合計の差は22.2分・26.3分

手作業の時間は、人が測った値でなく試算です。AI側も、実測は生成待ちだけで、打つ・貼る・読む時間は計算です。AI側の修正時間は、正解を知る筆者が最小限に直した値で、誤りを探す時間が入っていません。AIの時間は下限寄りです。

ナレッジ記事を、必須事実が揃い誤りが0件になるまで直した量は、Wi-Fiの記録で13箇所・追記241字・削除641字でした。生成された約1,330字の約半分を削った量です。手作業で同じ構成に書いた記事は、必須事実7件中7件、誤り0件で、904字でした。

ナレッジ記事では、調査の経過が「解決手順」として並び直されました。効果のなかった再起動が手順に入り、「効果なし」という記述は消えています。公開前の確認項目に、効果のなかった対応が手順に紛れていないかを入れます。

読む時間と照合の時間

4つの作業で、AI側は計21.7分でした。内訳は次のとおりです。

• 生成待ち：約3.1分

• 読んで照らし合わせる：約6.7分

• 追記の入力：約8.1分

• 貼り付け：約2.0分

• 残り：操作と修正箇所の判断

手作業から減ったのは、主に文章を打つ時間でした。稟議で時間を見積もるなら、生成時間に読む時間・照合・追記の入力を足します。

検索と分類の2つの測定

残る2つの測定は、文章の生成ではなく、検索と分類を対象にしました。

• ナレッジの書き方と検索のされやすさは、同じ内容の記事を5通りに書き分け、5種の質問で各3回検索した。日本語の記事は、英語表示の検証ユーザー3名の検索に1件も出なかった。症状の言葉で探すと、症状の言葉をタイトルにした記事が上位に出た。本文が1文だけの記事は、専門語と言い換えの質問では回答に1回も引用されなかった

• 分類の推定は、日本語のインシデント12件に、事前に正解を決めて分類エージェントを1回ずつ実行した。一致はエージェント11件、筆者が書いたキーワードのルール9件、何もしない場合0件。エージェントは、手動テストでも承認の画面なしで9件に書き込んだ。担当グループは分類エージェントの対象外で、学習済みの予測モデルも0件だった

公式ドキュメントの説明

要約と解決メモの入力、管理者が調整できる範囲、使用量の数え方は、公式ドキュメントに次のように書かれています。

• 要約の入力は、説明・件名・作業メモ・コメント・メールで、新規・作業中・解決済み・クローズの状態ごとにテンプレートがある（Skill inputs and triggers for ServiceNow Otto for ITSM）

• 要約スキルは複製して、入力に使うテーブルと項目を選べる。複製できないスキルの項目は読み取り専用（Customize a resolution notes generation skill）

• インシデントからのナレッジ記事の生成は、解決済み・クローズ済みの記録が対象。ほかの状態は、管理者がシステムプロパティで設定する（Generate a knowledge article from the Service Operations Workspace for ITSM and classic environment by using ServiceNow Otto）

• 管理コンソールでプロンプトの出力を試すたびに、1アシストとして追跡される（Configure case or incident summarization in the AI Admin Hub console）

デモ環境で使ったアシストは、アシストの総使用量から除かれると書かれています。今回の行が契約の使用量にそのまま加算されるとは限りません。

管理者向けの Now Assist アドミンでも、スキル別の利用回数の推移を見られます。画像の①は凡例に並ぶ Incident summarization と Resolution notes generation、②は期間中の利用回数の推移です。全体の傾向を見る画面なので、今回の回数と行数の照合には使っていません。

出力ごとの扱い

7つの測定の結果から、出力ごとの扱いを決めました。どれも数件のデモレコードでのケーススタディから決めた扱いで、自社の記録で同じ採点をしてから確定します。

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

• 引継ぎ要約は、OOTBのまま使い、照合する。標準の記録で事実8件中7件・誤り0件。見る点は発生時刻と未了の依頼

• 利用者への返信文は、OOTBのまま使い、追記する。1シナリオで必須3件中2件・誤り0件・3.7分短縮。発生日時は3回とも抜けた。見る点は宛名・挨拶と発生日時

• 解決メモは、原因が確定してから使う（候補）。複合機の記録で、仮説を確定扱いにした回が8回中8回。見る点は原因欄と効果なしの手順

• ナレッジ記事の生成は、公開用にはまだ使わない。必須事実の一致は5回とも半分以下。見る点は原因・手順・状態・助言

• ナレッジ検索は、OOTBのまま、記事の書き方を直す。英語表示の3名は0件、1文の記事は引用0回。見る点は利用者の表示言語と記事の言語の組み合わせ、タイトル

• 分類エージェントは、担当者の確認つきで使う。12件中11件が一致し、9件に承認なしで書き込んだ。見る点は判定なしの件と書き込み先

• 担当グループは、まだ任せない。分類エージェントの対象外で、学習済みモデルは0件

• 利用量は、自動の要約は開く回数、ほかは押す回数で見積もる。要約33回に対し、ログは72行

OOTBの維持と書き方の見直し

先に手を入れるのは、AIの設定より入力の側です。標準的な記録（B）の要約は、事実8件中7件が入り誤りは0件でした。件名と1文だけの記録（A）では、記録に無い作業と原因が3回とも書かれています。検索でも、結果を変えたのは利用者の表示言語と、記事のタイトル・本文の書き方でした。

ただし、入力を厚くするだけでは解決メモとナレッジ記事の誤りは消えません。仮説や未了の対応まで書いた複合機の記録（C）には「未確認」「効果なし」「未了」を明記していました。それでも解決メモは仮説を確定した原因にし、ナレッジ記事は再起動を手順に入れています。この2つは、使う記録を選ぶことと、公開・挿入の前の照合で対処します。

再生成とカスタマイズ

再生成で変わったのは語尾と周辺の事実でした。発生時刻は要約20回中0回、未了の依頼は10回中10回が済んだ形のままです。同じ型の誤りは、再生成を重ねても残りました。

プロンプトのカスタマイズは候補にとどめます。別記事「Now Assist Skill Kitでカスタムスキルを作る手順：インシデントから返信文の下書きを生成する」では、返信文のカスタムスキルに規則を足しました。1件のレコードで比べた5項目のうち2つが直り、宛名の姓の欠落と社内の名称の2つは残りました（未確認の仮説は前後とも書かれませんでした）。

標準の要約スキルを複製してプロンプトを直した版は、テストを実行できず、効果を確かめていません。標準の要約・解決メモ・ナレッジ生成のプロンプトを変えて誤りが減るかは、今回は確かめていません。カスタマイズした場合は、プロンプトの版管理、アップグレード後の確認、テスト実行のアシスト消費が保守に加わります。

ここから先は、測定の結果を導入前の作業にそのまま使える形にまとめています。生成物ごとの照合チェックリスト、担当ごとに決めること、自社の記録で同じ採点をする6つの手順の3つで、約2,000字です。

💰 ここから先は有料エリア