Now Assist と記録の厚み：要約は仮説を残し、解決メモは確定原因にした

Now Assist のインシデント要約は、現場がどこまで記録を書けば使えるのでしょうか。件名と1文しかない記録に要約を頼むと、記録に無い作業が書かれました。記録を充実させると、要約は「未確認の仮説」を仮説のまま残しました。ところが同じ記録から作った解決メモは、その仮説を確定した原因として書いています。同じ障害を3段階の厚さで書き分け、要約と解決メモがどう変わるかを比べた結果です。

画面で確かめた要点

• 件名と1文だけの記録（A）では、要約が「確認しました」「調査を進めています」と記録に無い作業を3回とも書いた

• 標準的な記録（B）では、要約に誤りは出なかった。毎回入らなかったのは発生時刻だけ

• 充実した記録（C）では、要約は未確認の仮説を3回とも仮説のまま残した。一方で「保守会社への依頼は未完了」は3回とも「依頼し」に変わった

• 同じ C から作った解決メモは、3回とも仮説を確定した原因として書いた

• 解決メモは進行中の記録でも「原因」欄を埋める形式。記録の書き方だけでは防ぎきれない可能性がある

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

• A（件名と1文だけ）は、要約の網羅が2/2。要約は記録に無い作業を2件ずつ書いた。解決メモは記録に無い原因と手順を書いた

• B（標準）は、要約の網羅が7/8。要約の誤りはなし。解決メモは効果の無かった再起動を手順に並べた

• C（充実）は、要約の網羅が11・12・10/14。要約は「依頼は未完了」を「依頼し」に変えた。解決メモは仮説を確定原因に、依頼を済みにした

試したスキルと範囲

試したのは次の2つです。どちらも Now Assist for ITSM の機能で、インシデントを Service Operations Workspace（SOW）で開いて使います。

• AI summary and next steps（インシデントの要約）は、レコードを開くと、問題と実行された主なアクションを自動でまとめる。このデモ環境では、画面を開いた時点で生成が始まった

• 解決メモの生成は、SOW の解決メモ欄の Now Assist ボタンで、問題・原因・解決手順を書く。生成結果は［挿入］を押すまで記録に入らない

規模は次のとおりです。

• 記録：架空のインシデント3件（同じ障害を厚さだけ変えて書いた）

• 要約：各記録3回、計9回を採点。ほかに確認用の1回があり、採点していない

• 解決メモ：各記録3回、計9回を採点。生成結果を画面から取得する手順の不具合で、再実行が2セットあった。再実行を含めた総生成回数は25回前後で、正確には数えていない

• 採点：筆者1名。同じ出力を2回に分けて採点していない

• 書き込み：［挿入］・保存・解決・メール・重大インシデント提案は押していない。事後に、直近6時間のメールのうち作成した3件に紐づくものが0件で、承認も0件であることを確認した

KB 生成・メール提案・重大インシデント提案は、外部への影響を避けるため実行していません。

試した3つの記録

3件とも件名は同じです。「3階の複合機でスキャンした文書が共有フォルダに保存されない」という架空の障害で、状態・担当者・優先度も同じにしました。変えたのは、説明欄と作業メモ、コメントの量です。

A：件名と1文だけ

• 説明欄は1文のみ。営業部の利用者から、3階の複合機でスキャンした文書が共有フォルダに保存されないと連絡があった

• 作業メモとコメントは無し

B：標準

• 説明欄：9月30日の午前9時ごろから、本社3階の複合機（MFP-3F-02）で発生。画面に「送信エラー 0x7D」。営業部12名が影響。コピーと印刷は使える

• 作業メモ3件：2階の複合機（MFP-2F-01）では同じ共有フォルダへスキャンできる、MFP-3F-02 を再起動したが変わらない、ファイルサーバーへの ping は正常

C：充実

• B の説明欄と作業メモ3件に加えて、説明欄に10月3日の監査提出資料のスキャンが必要で、10月2日までの復旧を希望していることを書いた

• 作業メモ4件を追加：9月29日夕方にスキャン用アカウント（svc-scan）のパスワードを定期変更している、svc-scan はロックされていない、仮説（旧パスワードのままの可能性があるが、複合機側は未確認で原因は未確定）、宛先設定のパスワード更新は保守会社への依頼が未完了で、10月2日午前に実施予定

• コメント1件：営業部には当面2階の複合機を案内した。2階では問題なくスキャンできている

C には、後半の採点で基準になる事実が3つ入っています。

• 仮説は未確認である（F12）

• 再起動は効果が無かった（F7）

• 保守会社への依頼は未了である（F14）

要約と解決メモが、この3つを元のとおりに残すかを見ます。

用語

• SOW：Service Operations Workspace。担当者がインシデントを処理する画面

• 格上げ：未確認の仮説を確定原因として書く、未了を完了として書く、効果が無かった対応を効果ありとして書く誤り

• 補い：記録に無い作業や事実を書いた誤り

• 網羅：そのレベルの記録に含まれる事実のうち、要約に意味が通る形で入った件数

採点の物差し

事実チェックリストを先に作りました。各レベルが含む事実だけを分母にしています。

• A（件名と1文だけの記録、2件）：3階の複合機でスキャンした文書が共有フォルダに保存されない（F1）／影響は営業部（F2）

• B（標準的な記録。A の2件に6件を追加、計8件）：画面に「送信エラー 0x7D」（F3）／9月30日の午前9時ごろから発生（F4）／営業部12名が影響・コピーと印刷は使える（F5）／2階の複合機は同じ共有フォルダへスキャンできる（F6）／再起動は効果なし（F7）／ファイルサーバーへの ping は正常（F8）

• C（充実した記録。B の8件に6件を追加、計14件）：10月3日の監査資料のため10月2日までの復旧希望（F9）／9月29日夕方に svc-scan のパスワードを定期変更（F10）／svc-scan はロックされていない（F11）／仮説。旧パスワードの可能性があるが、複合機側は未確認で原因は未確定（F12）／暫定対応として2階の複合機を案内（F13）／宛先設定のパスワード更新は保守会社への依頼が未完了で、10月2日午前に実施予定（F14）

採点は3つの観点で行いました。

• 網羅：そのレベルの事実のうち、要約に意味が通る形で入った件数。言い換えは可。数字や固有名が違えば入ったと数えない。期限だけで理由が無い（F9）のような一部だけの記述は、入っていない扱い

• 誤り：記録に無い作業や事実を書いた「補い」、記録と食い違う「矛盾」、未確認の仮説の確定扱い・未了の完了扱い・効果なしの効果ありへの変更という「格上げ」に分けて数える

• 修正量は、次の4段階で判定する

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

• 軽微：事実関係を変えず、語句や表現だけ直す

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

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

修正に要した実時間は測っていません。

標準的な記録の場合

標準的な記録（B）の要約は3回とも、事実8件のうち7件を入れました。

①の問題の段落には、「送信エラー 0x7D」、営業部12名、コピーと印刷が使えることが入りました。②の主なアクションは3件で、再起動、ping、2階との比較です。すべて作業メモにある内容でした。③が元の説明欄です。見比べると発生時刻（午前9時ごろ）だけが3回とも要約に入っていません。

標準的な記録（B）の再起動の書き方は、3回とも「症状は改善せず同じエラーが表示されました」のように、効果が無かったことまで保たれました。補いも矛盾もありません。修正量は3回とも軽微と判定しました。直すのは発生時刻の追記だけだからです。ただし、事実の追加は定義の「語句や表現だけ直す」を超えるため、軽微は筆者の緩めの判定です。

充実した記録の場合

C は事実が14件あります。要約が入れた事実は、1回目が11件、2回目が12件、3回目が10件でした。

①では、旧パスワードの仮説が「認証エラーが発生している可能性があり」と、可能性のまま残っています。2回目は「仮説として立て」、3回目は「原因は未確定である」と書きました。3回とも、仮説は確定した原因になりませんでした。

問題は②です。元の作業メモは「保守会社への依頼がまだ完了していません」でした。要約は3回とも同じ趣旨に変えました。次は1回目の原文です。

「依頼し」と書くと、依頼が済んだと読めます。この1語の訂正は短いのですが、対応の状態に関わるため、修正量は大幅と判定しました。1回目には、svc-scan を「複合機のスキャン用アカウント」と書いた箇所もありました。元の記録では、アカウントのパスワード変更はファイルサーバー側の作業です。管理場所の取り違えと採点しました。ただし用途を示す表現とも読めるため、誤りと言い切れません。

ほかに、再起動は効果が無かったことが3回とも保たれています。入らなかった事実は次のとおりです。

• 発生時刻：3回

• 依頼の未完了：3回

• 期限：2回（1回目は監査資料という理由だけ、3回目は理由と10月2日までの期限の両方）

• コピーと印刷が使えること：1回

解決メモの場合

解決メモの生成は、進行中の記録に対しても「問題」「原因」「解決手順」を書く形式です。C から3回生成した結果は、原因が3回とも同じ趣旨でした。次は1回目の原文です。

元の記録では、複合機側の宛先設定はまだ確認しておらず、原因は未確定です。解決手順には「保守会社へ宛先設定のパスワード更新を依頼し、10月2日午前に更新作業を実施する予定としました」と書かれ、依頼は済んだものとして並びました。

①が原因欄で、②が手順の「依頼し」です。［挿入］は押していません。

同じ記録の同じ事実（F12）が、要約では3回とも仮説として残り、解決メモでは3回とも確定しました。解決メモは「原因」を書く欄が決まっているため、仮説しか無い記録でも欄を埋める方向に働いたと見ています。ただし、これは今回の観察からの見立てで、仕様を確かめたものではありません。

• 仮説（F12）：要約は3回とも可能性のまま残した。解決メモは3回とも確定した原因として書いた

• 保守会社への依頼（F14）：未完了の記録を、要約は3回とも「依頼し」に変え、解決メモは依頼済みの形で手順に並べた

• 再起動は効果なし（F7）：要約は3回とも保った。標準的な記録（B）の解決メモでは、有効な手順に並んだ

記録が薄い場合

ここまでは、ある程度書かれた記録の結果です。件名と1文だけの A では、結果が変わりました。

要約の事実2件は3回とも入りました。それに加えて、3回とも同じ趣旨の2文が書かれていました。次は1回目の原文です。

作業メモもコメントも無い記録なので、①と②はどちらも記録に無い作業です。③の元の説明欄には、利用者からの連絡しか書かれていません。修正量は大幅と判定しました。

解決メモは要約より先へ進み、3回とも原因を「共有フォルダへの保存設定に不備がありました」と書きました。記録に無い原因と、それを前提にした解決手順が並ぶため、修正量は不採用です。薄い記録から、解決メモは記録に無い原因を作り出しました。

生成にかかった時間

測定は、要約が画面を開いてから表示されるまで、解決メモが生成ボタンを押してから［挿入］ボタンが出るまでです。各3回の秒数は次のとおりです。

• 要約 A：21.7／22.2／18.6

• 要約 B：21.4／21.1／19.1

• 要約 C：21.8／21.7／24.3

• 解決メモ A：48.4／53.5／54.6

• 解決メモ B：48.2／51.2／51.5

• 解決メモ C：57.5／57.6／48.2

要約は9回で18.6〜24.3秒（平均21.3秒）、解決メモは9回で48.2〜57.6秒（平均52.3秒）でした。今回の各3回では、記録の厚さと生成時間の関係は判断できません。

これは今回のデモ環境での生成時間だけです。運用では、生成を待つ時間のほかに、元の記録との照合や修正の時間がかかります。その時間は今回測っていません。

公式ドキュメントの説明

ここまでの結果を、公式ドキュメントと照らし合わせます。公式の記述から分かるのは、何が入力になるかと、どこまで調整できるかです。今回の誤りが製品の仕様どおりか不具合かは、公式の記述だけでは判断できません。

入力になる欄

インシデントの要約は、Incident テーブルの次の項目を入力にします。

• 説明（Description）と件名（Short description）

• 作業メモ（Work notes）とコメント（Additional comments）

• メール

対象の状態は、新規・作業中・解決済み・クローズです。

解決メモの生成の入力は、件名・説明・状態・作業メモ・コメントです。

公式ドキュメントには、根本原因と実施した手順の要約を渡すと質が上がるという趣旨の記述があります。原因欄がどの入力から生成されるかは、公式ドキュメントに書かれておらず、今回も確かめていません。C の作業メモで原因に触れていたのは仮説の1件だけでした。

管理者が調整できる範囲

AI Admin Hub のコンソールから、要約スキルはコピーして調整できます。入力に使うテーブルと項目の選択は、手順の中で選ぶ項目として説明されています。

一方、要約スキルの入力データソースは変更できないという記述もあります。記録の書き方を変える運用側の対応と、スキルの調整は別の手段です。今回は、スキルのコピーや調整を試していません。

解決メモの生成は、既定でオンになっているスキルです。自動生成を手動に変えるには、AI Admin Hub でスキルのトリガーを設定します。

実機で気づいたこと

未了の表現は、要約で完了形に寄る

要約は記録を言い換えて短くします。充実した記録（C）の仮説と効果の有無は、要約3回とも残りました。表現を変えた場合の効果は比較していません。一方、「まだ完了していません」という未了の記述は、「実行された主なアクション」に「依頼し」と書かれ、依頼済みと読める表現に変わりました。要約を引き継ぎに使うなら、未了の対応はレビューで特に確認する項目になります。

記録を増やしても、依頼状況の誤りは残った

充実した記録（C）の要約は網羅が10〜12/14で、事実の多くが入りました。それでも、未了の依頼は変わりました。記録を厚くしても、正確さは自動では上がりません。どの事実が落ち、どの事実が変わるかを見る必要があります。

効果の無い対応も手順に並ぶ

標準的な記録（B）の解決メモは、再起動を「解決手順」に並べました。要約では「改善しなかった」と効果が無かったことが保たれていたのに、解決メモでは対応の結果が落ちています。

①の原因は症状の言い換えにとどまり、②の手順には再起動が入っています。再起動で直らなかったことは記録にあるのに、解決手順に並ぶと有効な手順に見えます。

OOTBのまま使う範囲

今回の3レコードの範囲では、スキルに手を入れる前に、使う場面を分けて記録の書き方を整える順になります。今回の誤りは、使う場面を分ければ避けられるものと、照合で直すものに分かれたためです。

ここから先は、今回の結果を運用に移すための材料です。作業メモの書き方のルールと書き換え例、挿入の前に照合する4点、場面ごとの扱いの判断表、担当ごとに決めることをまとめています。約2,000字です。

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