Now Assist 要約の再現性：同じインシデントを10回要約した結果

検証環境：Now Assist デモ環境（Australia Patch 5）/ 2026-10-02 確認

Now Assist の要約が気に入らないとき、もう一度生成すれば良くなるのでしょうか。同じ記録を20回要約すると、語尾や周辺の事実は回ごとに変わりました。一方で、発生時刻の欠落と、未完了の依頼を完了と書く誤りは、何回生成しても直りませんでした。再生成を前提に運用を決めてよいのかを、要約20回と解決メモ5回で確かめた結果です。

画面で確かめた要点

• 事実の拾い方は、10回続けてもほぼ同じだった。変わったのは語尾と、期限の理由・コピーと印刷の可否のような周辺の事実

• 記録に書いてあっても、10回中0回しか入らない事実があった（発生した時刻）

• 保守会社への依頼が未完了という記録は、10回とも「依頼し」と完了した形に変わった。再生成では直らなかった

• 解決メモは5回とも、未確認の仮説を確定した原因として書いた。5回とも同じ向きだった

試行の規模

2件のデモレコード（B：標準の記録、C：充実した記録）で、インシデント要約を各10回、C だけ解決メモ生成を5回実行しました。連続して実行した単一ユーザーの試行で、OOTB 全体の品質評価ではありません。「再生成すると何が変わり、何が変わらないか」という観点を洗い出すためのケーススタディです。

今回扱う OOTB の機能

インシデントまわりの Now Assist には、次のスキルがあります。

• Incident summarization（インシデント要約）：レコードを開くと、問題と実行された主なアクションを要約する。今回実行した（10回×2件）

• Resolution notes generation（解決メモ生成）：解決メモ欄から、問題・原因・解決手順を生成する。今回実行した（5回）

• Knowledge article generation（ナレッジ記事生成）：解決した記録から記事の下書きを作る。今回は実行していない

• Email recommendation（メール提案）：利用者へのメール文案を作る。送信の懸念があるため実行していない

• Major incident proposal（重大インシデント提案）：重大インシデントへの昇格を提案する。実行していない

再現性は「同じ入力で何度も実行できる」ことが前提のため、レコードを書き換えずに繰り返せる前の2つを代表にしました。入力の量を変えたときの違いは、別記事「インシデントの記録が薄いと、Now Assist の要約はどう変わるか」で扱っています。

元にした2つのレコード

同じ障害を、書き込みの量だけ変えて2件のレコードに書いてあります。件名は共通で「3階の複合機でスキャンした文書が共有フォルダに保存されない」です。状態は進行中、担当者と優先度も同じです。

B（標準） の説明欄には、9月30日の午前9時ごろから発生したことが書いてあります。画面に「送信エラー 0x7D」が出ること、営業部12名が影響を受けること、コピーと印刷は使えることも書いてあります。作業メモは3件です。2階の複合機では同じ共有フォルダへスキャンできること、再起動しても症状が変わらないこと、ping が正常なことを記録しています。

C（充実） は B に加えて、次の内容を持ちます。

• 10月3日の監査提出資料をスキャンする必要があり、10月2日までの復旧を希望

• 9月29日の夕方にスキャン用アカウントのパスワードを定期変更した

• そのアカウントはロックされていない

• 仮説は、複合機に登録された旧パスワードが原因の可能性、というもの。複合機側は未確認で、原因は未確定

• 暫定対応：営業部に2階の複合機を案内した

• 宛先設定のパスワード更新について、保守会社への依頼がまだ完了しておらず、10月2日の午前に実施予定

後半の判定軸になるのは、C の中の次の3点です。①仮説は未確認のまま。②保守会社への依頼は未完了。③期限の背景には監査がある。要約が再生成のたびにこの3点をどう扱うかを見ます。

事実チェックリストは B が8件、C が14件です。要約に意味が通る形で入れば「入った」とし、数字や固有名が違えば入ったとは数えません。

用語

• 再現性：同じ記録に同じ操作をしたとき、出力がどれだけ同じになるか

• 格上げ：未確認の仮説を確定した原因として書く、未完了を完了として書くなど、確からしさを実際より上げて書くこと

• 補い：記録に無い作業や事実を書くこと

• WIP：Work in Progress。進行中の状態

修正量の定義

誤りの種類は、記録に無い作業や事実を書く「補い」、記録と食い違う「矛盾」、未確認を確定にする・未完了を完了にする「格上げ」に分けて数えました。修正量は次のとおり定めます。

• 修正なし：文章を変えずに引き継ぎ文として使える

• 軽微：事実関係は変えず、語句や抜けた情報の追記だけで済む

• 大幅：原因・状態・対応・結論など、業務判断に関わる内容の追加・削除・訂正が要る

• 不採用：元レコードとの照合や書き直しが要り、下書きとしての効果が薄い

判定は筆者1名で、再採点はしていません。修正に要した実時間は測っていません。

要約の10回実行

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

• 3階だけの障害・0x7D・再起動は効果なし・ping 正常（B：標準の記録、C：充実した記録）：B は10回中10回、C も10回中10回

• 営業部12名とコピー・印刷は使える（B：標準の記録、C：充実した記録）：B は10回中10回。C は3回だけ。12名だけなら C も10回入っている

• 9月30日午前9時ごろから発生（B：標準の記録、C：充実した記録）：B も C も0回

• 旧パスワードの仮説（C）：10回中10回、未確認のまま入った

• 10月3日の監査資料という期限の理由（C）：10回中2回

• 保守会社への依頼は未完了（C）：10回中0回

標準の記録（B）の10回では、拾った事実が毎回同じ7件（8件中、発生時刻だけが落ちる）でした。補い・矛盾・格上げは0回です。変わったのは書き方でした。

• 問題の段落は、「発生しています」「影響が出ている」「使用可能です」のように語尾が回ごとに入れ替わる

• アクションは、10回中9回が常体（「確認した」）で、1回だけ全部が敬体（「確認しました」）だった

• 長さは279〜301字でほぼ一定

①の問題の段落には、0x7D・12名・コピーと印刷が入っています。②のアクションは、作業メモの3件がそのまま並びます。③の説明欄にある「9月30日の午前9時ごろから」は、①にも②にも現れていません。

標準の記録（B）の修正量は10回とも軽微と判定しました。抜ける発生時刻は、説明欄を見れば1行で足せるためです。

充実した記録の場合

充実した記録（C）の10回は、大きく2つの形に分かれました。

• 短い形（7回）は、問題の段落は「12名が影響を受けている。」で終わる。コピー・印刷と期限は無い。長さは489〜500字

• 長い形（3回）は、問題の段落に「コピーと印刷は問題なく利用可能であり、…10月2日までの復旧が求められています」まで入る。長さは539〜564字。3回とも問題の段落が敬体

長い形のうち2回は、「10月3日の監査提出資料のスキャン」という期限の理由まで入りました。残る1回は期限だけです。同じ入力から、周辺の事実の入る範囲が毎回同じとは限りません。

①の問題の段落は短い形の1回目です。コピーと印刷の可否も期限も入っていません。②の行は「保守会社に依頼し、10月2日の午前に更新作業を予定している」と書いています。元の記録は「依頼がまだ完了していません」でしたので、完了した形に変わっています。③の仮説は「可能性を仮説として立てたが、原因は未確定である」と書かれ、確定扱いにはなっていません。

仮説の扱いを10回で並べると、次のようになりました。

• 「原因は未確定である」まで書いたのが7回

• 「原因の特定を進めている」と書いたのが2回

• 「仮説として立てた」だけで止まったのが1回

10回とも仮説は仮説のままで、確定には格上げされていません。ただし「原因の特定を進めている」は、記録に無い作業の記述です。補いとして2回数えました。

充実した記録（C）の10回の誤りは、次のとおりです。

• 格上げ：保守会社への依頼を完了した形に書いた（10回中10回）

• 補い：原因の特定を進めている（10回中2回）

• 矛盾：0回

充実した記録（C）の修正量は10回とも大幅と判定しました。依頼の状態は1語の訂正ですが、次の担当者が対応の進み具合を誤解する内容のため、業務判断に関わると見たためです。

落ち続ける事実

発生時刻は標準の記録（B）と充実した記録（C）の両方で、20回中20回とも落ちました。要約の「問題」の段落には、いつから起きているかが一度も入っていません。保守会社への依頼が未完了だという事実も、C の10回すべてで完了した形に変わりました。

この2つは、ばらつきではなく偏りです。10回やって10回同じ向きに外れたため、11回目で直る見込みは今回の範囲では立てられません。

• 回ごとに変わった点：語尾と文体、C の要約の形（短い形7回・長い形3回）、期限の理由（10回中2回）、コピーと印刷の可否（10回中3回）

• 毎回同じ向きに外れた点：発生時刻（20回中0回）、保守会社への依頼（要約10回中10回が完了の形）、解決メモの原因（5回中5回が確定）

• 扱い：左は気になるときだけ1回再生成（候補）、右は再生成せず記録と照合して直す

一方、期限の理由とコピー・印刷の可否は、10回中2〜3回だけ入りました。再生成で入ることもある情報です。ただし入る回を待つ運用にすると、出力のたびに内容を見比べる手間が増えます。そのため、原記録から不足情報を足す運用を提案します。再生成との所要時間の比較はしていません。

解決メモの5回実行

Resolution notes generation（解決メモ生成）は、解決メモ欄から生成すると「問題」「原因」「解決手順」の3つの見出しで出てきます。C で5回実行しました。

①の原因は「複合機に登録された宛先設定が旧パスワードのままで、認証に失敗していました」と書かれました。元の記録は「複合機側の宛先設定はまだ確認していないため、原因は未確定」です。②の行は「依頼し、…予定としました」と書き、未完了だった依頼を完了した形にしています。

5回の結果は次のとおりです。

• 原因が確定として書かれた：5回中5回（格上げ）

• 保守会社への依頼が完了した形：5回中5回（格上げ）

• 「予定を調整しました」のように、記録に無い動作を足した：5回中1回（補い）

• 原因欄の言い回しは3種類（「宛先設定が旧パスワードのまま」が基本で、「3階の複合機に登録された」を足す回や、「スキャン用アカウントのパスワード更新後」を足す回がある）

要約では10回とも仮説のままだった同じ事実が、解決メモでは5回とも確定になりました。今回の5回では、原因欄に未確認の仮説が確定した原因として書かれました。出力形式との関係は未検証です。

解決メモは5回とも、再起動・ping・0x7D の記述を含んでいません。充実した記録（C）の要約は、作業メモの8件をアクションとして拾いました。解決メモの「解決手順」は2〜3項目だけです。修正量は5回とも大幅と判定しました。

公式ドキュメントの説明

要約の入力と構成は、公式ドキュメントに次のように書かれています。

要約が読む入力

公式の「Skill inputs and triggers」では、Incident Summarization の入力テーブルは Incident と説明されています。入力フィールドは Description・Short description・Work notes・Additional comments・Email です。入力テンプレートは、New・WIP・Resolved・Closed の状態ごとに用意されています（英文の要旨を日本語にしています）。

今回の B と C は進行中のレコードで、WIP のテンプレートに当たります。「実行された主なアクション」は Key Actions Taken に対応し、WIP・Resolved・Closed で必須の項目です。見出しが毎回同じ形で出るのは、この構成による動きと整合します。

テスト実行と利用回数

AI Admin Hub の要約設定の手順には、プロンプトの出力を試すたびに、その操作が Now Assist のサブスクリプションで追跡される1回分の利用として数えられる、と書かれています。同じページには、複数のレコードで試すと結果への納得を確かめやすい、という説明もあります。

この記述は管理コンソールでのテスト実行についてのものです。画面の再生成ボタンや解決メモ生成の利用量の数え方は、今回確認していません。再生成を運用に組み込む前に、利用量の記録を一度確認しておきます。

実機で気づいたこと

再生成後も残る欠落と誤り

要約のたびに語尾や段落の長さは変わりました。変わらなかったのは、発生時刻が入らないことと、依頼未完了が完了に変わることです。出力が毎回違って見えるため、再生成すると良くなりそうに見えます。ただし発生時刻と依頼状態については、今回の繰り返しで改善しませんでした。一方で、コピーと印刷の可否や期限の理由のように、入る回と入らない回がある情報もありました。

敬体と常体が1つの要約の中で混ざる

充実した記録（C）の長い形では、問題の段落が敬体（「影響を受けています」）で、アクションは常体（「案内した」）でした。標準の記録（B）の10回でも、問題の段落が敬体になる回が3回ありました。そのまま引き継ぎ文に貼ると、文体が混ざります。チームで文体を揃える運用なら、挿入後に直す前提で見ておく必要があります。

長さは安定、中身は不安定

標準の記録（B）は279〜301字、充実した記録（C）は489〜564字で、長さのばらつきは小さいです。しかし C の長い形の3回では、コピーと印刷の可否が入り、そのうち2回では期限の理由も入りました。字数がそろっていても、入る事実がそろっているとは限りません。

今回の生成時間

• 要約 B：10回、15.6〜26.9秒（平均21.4秒）

• 要約 C：10回、20.0〜31.9秒（平均23.6秒）

• 解決メモ C：5回、48.4〜62.9秒（平均56.0秒）

要約は画面を開いてから表示されるまで、解決メモはボタンを押してから［挿入］が出るまでです。同じ環境を他の作業が使っていた可能性があるため、参考値として見てください。平均では、解決メモは B の要約の約2.6倍、C の要約の約2.4倍でした。

再生成・照合・調整の使い分け

今回の範囲では、書き方と周辺の事実は回ごとに変わりましたが、発生時刻と依頼の状態は10回とも同じ向きに外れました。毎回同じ向きに外れる欠落と誤りは、原記録との照合で直します。最適な再生成回数は検証していません。

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

• 標準の記録（B）の要約（10回）：入った事実は毎回7/8。格上げ・補いは0件

• C の要約・短い形（7回）：入った事実は10/14。格上げ1件（毎回）、補い0件

• C の要約・長い形（3回）：入った事実は11〜12/14。格上げ1件（毎回）、補いは2回

• C の解決メモ（5回）：格上げ2件（毎回）、補いは1回

この結果から、出力に出たことごとに扱いを分けます。

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

• 語尾・文体のぶれは、気になるときだけ1回再生成する（候補・回数は検証していない）。B は語尾が回ごとに変わり、事実は毎回7/8だった

• 発生時刻の欠落は、再生成せず、説明欄から追記する。標準の記録（B）・充実した記録（C）の20回中0回だった

• 未了の依頼が完了の形は、再生成せず、記録と照合して直す。C の要約10回中10回だった

• 解決メモの原因が確定の形は、原因の確定前は挿入しない。C の5回中5回だった。確定後に使う扱いは候補で、今回は原因が確定した記録で試しておらず、これで誤りが減るかは確かめていない

• 毎回同じ向きの誤りは、プロンプト調整は候補。今回は調整していない

ここから先は、挿入の前に記録と照合する3点のチェックリスト、記録の書き方とプロンプト調整の扱い、担当ごとに決めることをまとめています。要約と解決メモの出力の原文（要約5例・原因欄3例）も載せます。全体で約2,000字です。

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