ナレッジ記事の生成：インシデントの記録から作った記事と、手作業で書いた記事を比べた

インシデントの記録からナレッジ記事を自動で作れば、対応の知見をすぐ共有できます。ただし記録には、確認できていない原因、効果のなかった対応、まだ終わっていない対応が混ざっています。これらはナレッジ記事の「原因」「対処手順」の欄に入ると、どう書かれるのでしょうか。2件の架空のインシデントから Now Assist でナレッジ記事を生成し、手作業で書いた記事と並べました。生成された記事では、仮説が断定に変わり、効果のなかった対応が手順に入り、依頼がまだ終わっていないという状態が消えました。

画面で確かめた要点

• 複合機の記録では、未確認の仮説が「根本原因」として2回とも書かれた

• 効果のなかった再起動が、2回とも対処手順の先頭に並んだ

• 保守会社への依頼は未完了だったが、状態の記述が消え、「依頼して実施してもらいます」という手順になった

• 記録に無い助言が4回すべてに、再現手順が複合機の2回に入った

• 必須事実の一致は、Wi-Fi の記録で7件中1件、複合機の記録で8件中3件にとどまった

• 解決済みの記録からエージェントのツールで作った記事でも、仮説が根本原因の欄に、効果のなかった再起動が手順の1番に入った

• 手作業で書いた記事は、同じ物差しで7件中7件、誤りは0件だった（手作業の文章は Claude が書いたもので、人が書く記事の代表ではない）

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

• 元のインシデントに書かれた3つの記述が起点

• 未確認の仮説（旧パスワードの可能性、複合機側は未確認）は、「原因」の欄で根本原因として書かれた（2回とも）

• 効果のなかった対応（複合機の再起動）は、「対処手順」の欄で手順の先頭に並んだ（2回とも）

• 未了の対応（保守会社への依頼）は、「依頼して実施してもらう」という状態の記述が消えた（2回とも）

比べた Now Assist の機能

ナレッジ記事の生成に関係して、この環境で有効だった機能は次のとおりです。

• Generate KB article body（ナレッジ記事本文の生成）：有効。ナレッジ作成画面の Now Assist に依頼文を送ると、記事本文を書く。今回動かした

• ナレッジ記事を生成：有効。説明は「ユーザーによるトピック入力に関するナレッジ記事を生成する」。記録番号を入れず、トピックの文章だけで依頼する形を1回試した。記事は作られなかった

• ナレッジ記事生成ツール：有効。データソースとして登録されている。パネルから記録番号付きで依頼すると動くエージェントのツール「KB 記事を生成」を、解決済みの記録で1回動かした

中心にしたのは1つ目の、ナレッジ作成画面からの生成です。進行中の記録2件で調べました。Service Operations Workspace（SOW）の「ナレッジを作成」を開きます。本文エリアにある Now Assist のリクエスト欄に「（レコード番号）の内容からナレッジ記事を作成してください」と入れます。依頼文の下の欄が、ナレッジベースと言語の選択です。

①の欄に依頼文を入れて送信すると、生成が始まります。②の選択欄は、インシデントと日本語です。画面左の「言語」の欄は English のまま残り、この食い違いは後の節で扱います。

公式ドキュメントが示す経路は、解決してクローズしたインシデントで UI アクションの「Create knowledge」を選ぶ手順です。起動の経路が違い、記録の状態も違うため、結果が同じになるかは確かめていません（詳細は後半の公式ドキュメントの節）。

元になった2件の記録

ナレッジ記事の良し悪しは、元の記録に何が書いてあったかが分からないと判断できません。使った記録は2件で、どちらも架空です。

Wi-Fi の記録（作業メモ4件）

大阪オフィス3階の会議エリアで、社内 Wi-Fi（CORP-WiFi）が断続的に切れる件です。10月1日10時ごろから、営業部の約20名が Teams 会議中に30秒から1分の途切れを繰り返しています。2階の執務席は影響がなく、9月30日までは正常でした。

作業メモには、次の3つが書いてあります。

• 未確認の仮説：周辺チャネルの電波干渉は、スペクトラム測定をしておらず、確認できていない

• 効果のなかった対応：AP-3F-02 の再起動は、20分観察しても切断が改善しなかった

• 未了の対応：ベンダーへ v8.2 の不具合と恒久対応を問い合わせ済みで、回答は未着

ほかに2点あります。9月29日夜に無線コントローラのファームウェアを v8.2 へ更新し、3階の3台に適用済みです。AP-3F-02 だけ v8.1 へ戻したところ、10月2日10:30 以降は切断が出ていません（他の2台は v8.2 のまま）。

複合機の記録（作業メモ7件・コメント1件）

本社3階の複合機（MFP-3F-02）でスキャンした文書が、共有フォルダに保存されない件です。9月30日の午前9時ごろから、画面に「送信エラー 0x7D」が表示され、営業部の12名が影響を受けており、コピーと印刷は使えます。10月3日の監査資料のため、10月2日までの復旧が希望されています。

作業メモの要点は次の3つです。

• 未確認の仮説：スキャン用アカウント（svc-scan）のパスワードを9月29日夕方に定期変更しており、複合機側が旧パスワードのままで認証に失敗している可能性がある。複合機側の宛先設定は未確認で、原因は未確定

• 効果のなかった対応：複合機 MFP-3F-02 の再起動で、症状は変わらなかった

• 未了の対応：宛先設定のパスワード更新は、保守会社への依頼がまだ完了していない。10月2日の午前に更新作業を実施する予定

ほかに4点あります。2階の複合機（MFP-2F-01）では同じ共有フォルダへスキャンできます。ファイルサーバーへの ping は正常で、svc-scan もロックされていません。営業部には当面2階の複合機を案内しています。

2件とも、記録は進行中のままで、解決済みにはしていません。

採点の基準

ナレッジ記事に載るべき事実を、記録ごとに決めました。言い換えは一致とし、日付や機器名の欠落は別の項目で見ます。

• Wi-Fi（7件）：発生日時と場所／再起動は効果なし／9月29日夜の v8.2 更新が3台に適用済み／電波干渉は未確認／AP-3F-02 のみ v8.1 へ戻して10:30 以降は切断なし／他の2台は v8.2 のまま／ベンダーへの問い合わせは回答待ち

• 複合機（8件）：画面に「送信エラー 0x7D」で共有フォルダに保存されない／対象は3階の MFP-3F-02／2階の複合機では保存できる／再起動は効果なし／9月29日にスキャン用アカウントのパスワードを定期変更／複合機側は未確認で原因は未確定／保守会社への依頼は未完了／当面は別の複合機を案内

誤りは、次の5つの型で数えます。数える単位は、問題のある記述1箇所で1件です。記録に無い助言の節は、節ごとに1件にします。

• 仮説の確定扱い

• 効果のなかった対応を手順に載せる

• 未了の対応の完了扱い

• 元の記録に無い事実の追加

• 数値・時刻・機器名の取り違え

記録に無い追加は、事実の取り違えとは別の性質です。ただし、確認者が根拠を探す手間が生じるため、誤りに数えます。20分ほどが20分以上になった程度の微細な言い換えは、数えていません。

ナレッジ記事としての評価項目も加えました。症状・原因・対処・対象が欄として揃っているか、利用者や担当者が読んで動ける言葉か、の2つです。

修正量は、次の4段階で判定します。

• 修正なし：文章を変えずに公開前の確認に回せる

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

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

• 不採用：元の記録との照合や全面的な書き直しが要り、下書きとしての効果が薄い

Now Assist「Generate KB article body」の検証

Generate KB article body は、ナレッジ作成画面の Now Assist に依頼文を送ると、インシデントの内容から記事本文を書く機能です。保存と公開はしていません。生成のたびにナレッジ作成画面を開き直しました。

生成時間は72秒から83秒だった

生成時間は、4回で72.4秒から83.4秒でした。

• Wi-Fi：1回目83.4秒、2回目77.3秒

• 複合機：1回目75.6秒、2回目72.4秒

誤りは4回すべてで数え、修正量は各記録の1回目で測りました。

記事の構成は、症状・原因・対処の型に整った

生成された記事の見出しは、次のとおりです。

• Wi-Fi 1回目：概要／発生状況（症状）／特定された根本原因／推奨される解決手順／注意点および運用上の推奨／参照事項

• Wi-Fi 2回目：概要／発生環境と影響範囲／原因の特定（確認された要因・未確認の要因）／解決手順／備考

• 複合機 1回目：現象／問題の再現手順／考えられる根本原因／対処および解決手順／その他の注意点

• 複合機 2回目：概要／発生状況（再現手順）／原因（根本原因）／対策および解決手順／備考

4回とも、症状・原因・対処が欄として立ちました。件名も、複合機は「複合機でスキャンした文書が共有フォルダに保存されない（送信エラー 0x7D）」と、エラーコードを含む形で付きました。記事の構成としては、件名と症状の欄を再利用できます。

揃わなかったのは、対象の情報です。複合機の2回には、どの機器の話かを示す欄がなく、機器は「特定の階に設置された複合機」と書かれました。MFP-3F-02 も3階も入っていません。影響した人数（12名）は「複数のユーザー」に、期限（10月3日の監査資料）は省略に変わりました。Wi-Fi の記事も、大阪オフィスや AP-3F-02 という名前を省略しています。個別の事案を離れた記事として、人数や期限が省かれるのは整っている面です。ただ、どの機器の話かまで省かれると、記事を開いた人が自分の機器に当てはまるか判断できません。

未確認の仮説は、根本原因として書かれた

複合機の記録の仮説は、「旧パスワードのまま接続しているため、認証に失敗している可能性があります。複合機側の宛先設定はまだ確認していないため、原因は未確定です」でした。

②の見出しの下に、2回の記事は次の文を書きました。

1回目の見出しは「考えられる根本原因」でしたが、本文は「旧パスワードのままになっています」「認証に失敗しています」と言い切りです。2回目は見出しが「原因（根本原因）」、導入が「本件の根本原因は以下のとおりです」で、本文は過去形でした。「可能性」も「未確認」も、2回とも入っていません。

複合機側の宛先設定は、記録のどこにも「確認した」とは書かれていません。誤りの型は「仮説の確定扱い」です。

①は、概要の段落です。件名には「0x7D」まで入る一方、本文は機器を「特定の階に設置された複合機」と書き、3階も MFP-3F-02 も落ちました。③は後の節で扱います。

Wi-Fi の記録の1回目にも、同じ型が出ました。

①は発生日時の部分です。「ある特定の日時以降に発生し始めており」と書かれ、10月1日10時ごろが落ちました。②の見出しは「特定された根本原因」で、直下の導入文は「調査により、以下の点が根本原因として特定されています」です。記録では電波干渉は未確認、更新との関係は可能性の段階でした。見出しを見ただけの読み手には、原因が確定した記事に見えます。

効果のなかった再起動は、手順の先頭に並んだ

複合機の記録の再起動は、「症状は変わらず、同じエラーが表示されます」でした。生成された記事の「対処手順」の1番目は、2回とも次のとおりです。

効果が無かったという記述は、2回とも消えました。再起動が最初の手順として提示されています。誤りの型は「効果のなかった対応を手順に載せる」です。

Wi-Fi の記録も同じでした。2回とも、接続が集中した AP を再起動して20分以上観察する手順が入りました（2回目は手順3の見出しが「アクセスポイント再起動による暫定対応」でした）。記録の再起動は、実際には効果がなかった対応です。

未了の依頼は、「依頼して実施してもらう」手順になった

複合機の記録は、保守会社への依頼を「まだ完了していません」と書いていました。生成された記事は、2回とも次のような手順にしています。

「完了した」とは書かれていません。そのため、未了の対応の完了扱いには数えていません。ただし、「依頼はまだ完了しておらず、10月2日午前に実施予定」という状態は、2回とも消えています。

この点は、解決メモの結果と並べると違いがはっきりします。同じ複合機の記録から作った解決メモは、3回とも「保守会社へ…依頼し」と、依頼が済んだものとして書きました（別の検証の結果です）。解決メモでは未了が「済み」になり、ナレッジ記事では状態の無い「推奨手順」になっています。どちらも、元の記録の「まだ」が消えた点は変わりません。

Wi-Fi の記録のベンダーへの問い合わせは、記事では「問い合わせてください」と、これからやる手順になりました。「問い合わせ済みで回答待ち」という状態は、2回とも入りませんでした。

記録に無い再現手順と助言が足された

複合機の記録に再現手順はありませんでした。生成された記事は、2回とも「複合機でスキャン機能を使用します」から「複合機の画面に『送信エラー 0x7D』が表示され…」までの5手順を作っています。ほかに、1回目には次の文が入りました。

2回目の備考は、パスワード変更時の運用手順に認証情報の更新を含めることを推奨する、と書きました。どちらも、元の記録に無い内容です。

Wi-Fi の記録には再現手順は入りませんでしたが、1回目に「30分以上」観察するという元に無い数字と、事前の検証環境での確認という助言が入りました。2回目にも、関係部署と調整する旨の助言が入っています。

こうした助言は、もっともらしく読めます。助言の節は、4回すべての記事に含まれていました。誤りの型は「元の記録に無い事実の追加」です。

Wi-Fi の2回目だけは、未確認の要因を別の項目に分けた

反対の結果も1つありました。Wi-Fi の2回目は、「原因の特定」の下を「確認された要因」と「未確認の要因」に分けています。未確認の要因には、周辺チャネルの電波干渉が「スペクトラム測定は未実施のため確認が完了していない」と入りました。Wi-Fi の2回とも、更新後に切断が始まった点は「可能性がある」と書かれています。

Wi-Fi の記録には原因候補が2つあり、片方に「未確認」と明記されていました。複合機の候補は1つでした。この違いが結果に影響したかどうかは、各記録2回の結果からは言えません。記録の書き方や原因候補の数を変えた追加の検証が必要です。

結果を一覧にすると、次のとおりです。

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

• Wi-Fi 1回目：必須事実は1/7。誤りは4件で、確定扱い・再起動の手順化・元に無い数字・元に無い助言。修正量は大幅（13箇所）

• Wi-Fi 2回目：必須事実は1/7。誤りは2件で、再起動の手順化・元に無い助言。修正量は測っていない

• 複合機 1回目：必須事実は3/8。誤りは4件で、確定扱い・再起動の手順化・元に無い再現手順・元に無い助言の節。修正量は大幅（14箇所）

• 複合機 2回目：必須事実は3/8。誤りは4件で、確定扱い・再起動の手順化・元に無い再現手順・元に無い助言の節。修正量は測っていない

複合機で一致した3件は、症状、パスワードの定期変更（日付は問わない）、当面は別の複合機を案内（2階と特定しなくてよい）です。Wi-Fi の誤りの件数は、別の記事（手作業との時間比較）と同じ4件と2件です。どちらの記事も、1箇所で1件、助言の節は節ごとに1件の基準で数えています。

手作業で書いた記事と並べる

同じ Wi-Fi の記録で、手作業の記事（ナレッジ下書き）も書きました。書いたのは Claude で、人が書いた記事の代表ではありません。

手作業の記事の見出しは、「症状」「確認したこと」「暫定対応」「未了の対応」です。再起動は「効果がなかった。この対応は手順に含めない」、電波干渉は「未確認（スペクトラム測定は未実施）。原因として確定していない」と書きました。必須事実は7件中7件で、誤りは0件です。長さは約490字で、生成された記事（約1,330字）の4割弱でした。

型の違いは、見出しに出ています。生成は「原因」「対処手順」という、答えが決まっている形の欄を作ります。手作業は、記録に合わせて「確認したこと」「未了の対応」という専用の欄に書きました。確認できていないこと、終わっていないことを書く場所が、あらかじめ用意されています。

生成された記事を、必須事実が揃い誤りが0件になるまで直した量は、次のとおりです。

• Wi-Fi 1回目：13箇所、追記241字、削除641字。生成された1,328字の約半分を削った

• 複合機 1回目：14箇所、追記324字、削除733字。生成された約970字の約4分の3を削った。再現手順と助言の節を落とし、原因欄を「原因（未確認）」に直し、3階・2階・再起動・依頼の未了を足した

どちらも修正量は大幅です。複合機の直しは、手作業の記事とほぼ同じ構成になりました。修正に要した時間は測っていません。

利用者向けの言葉になっているか

生成された記事は、4回とも担当者向けの手順書の文体でした。「複合機の再起動を実施してください」「ネットワーク疎通を確認してください（ping 等）」のように、ping や宛先設定といった用語が前提になっています。自分で起票した利用者が読む記事としては読みにくい、というのが筆者の評価です。

利用者が自分でできる対応は、複合機の記事の最後の手順に回りました。「当面の間、ユーザーには別の正常に動作している複合機の使用を案内してください」と、担当者へ依頼する文でした。記録の2階の複合機は、具体名が落ちています。

文体は、2回目の複合機の記事で「してください」と「推奨いたします」が混ざりました。敬語の水準が揃わないまま、公開前の確認に回ることになります。

言語の欄は English のまま、カテゴリは空欄だった

複合機の生成結果の画面（上の③）は、ナレッジの言語の欄です。生成された記事は日本語でしたが、この欄は English のままでした。Now Assist のパネル側では、言語の選択が「日本語」になっていました。公式ドキュメントは、言語の選択肢を、ナレッジベースの言語パッケージと管理者の設定で決まる、と書いています。この環境で、パネルの言語とフォームの言語が連動しない理由は確かめていません。公開前に、担当者がフォームの言語を確認する必要があります。カテゴリも空欄でした。

AI Agent「KB 記事を生成」の検証

KB 記事を生成は、Now Assist パネルに記録番号を添えて依頼すると、その記録の内容からナレッジ記事の下書きを作り、記録に添付するエージェントのツールです。ここまでの生成はナレッジ作成画面から人が依頼する形でした。こちらはパネルに依頼するだけで下書きの記事が作られる点が違います。

元にした記録は、解決済みにした複合機の記録

元にしたのは、複合機の記録を複製し、作業メモ7件とコメント1件を同じ順で入れて解決済みにした記録です。解決コードは「ワークアラウンドが提供済み」で、解決メモは次のとおり書きました。

後の判定で見るのは、前の2件と同じ3点です。旧パスワードという仮説は未確認、再起動は効果なし、保守会社への依頼は未完了です。

公式の起動の経路にあたる「ナレッジを作成」は、解決済みの記録の「その他」のメニューに現れました。開くと、問題の欄に説明、解決の欄に解決メモがそのまま入った画面が開きました。ここには生成の操作が見当たらず、今回は AI の生成として扱っていません。

依頼から下書きの作成までは73.6秒だった

パネルに「（レコード番号）の内容からナレッジ記事を作成してください」と入れて送ると、実行計画にツール「KB 記事を生成」が成功で1件記録されました。所要は73.6秒です。ナレッジベースを選ぶ質問は出ませんでした。

①の依頼文を送ると、②の返答が返りました。作られた記事は、ナレッジベースが既定の「ナレッジ」で、ワークフローはドラフトです。言語は English、カテゴリは空欄でした。本文は日本語で459語です。公開していません。

本文は、仮説の断定と再起動の手順化が起きた

①の問題の欄は、状況を整理した文章です。ただし、機器は「特定の階にある複合機」、人数は「複数のユーザー」と書かれています。MFP-3F-02・3階・12名・9月30日午前9時は入りませんでした。

②の根本原因の欄は、3つの文で書かれました。「複合機に登録されている認証情報が古いパスワードのままであり」「古いパスワードで認証を試みるため、認証に失敗し」と言い切りで、「可能性」も「未確認」もありません。記録は、複合機側の宛先設定を確認しておらず原因は未確定としていました。型は「仮説の確定扱い」です。

解決の欄は8つの手順でした。

• ①の1番は「複合機を再起動して、症状が改善されるか確認してください」。記録では再起動は効果がなかったが、その記述はない。型は「効果のなかった対応を手順に載せる」

• ②の2〜4番は、疎通、サーバー側の変更履歴、アカウントロックの確認。記録ではすべて確認が済んでおり、結果も書いてあった。済みの確認が、これから行う手順に変わった

• ③の6番は「保守会社に連絡して…更新するよう依頼してください」。記録では依頼が未完了で、10月2日午前に実施予定だった。状態と予定日が消え、これからやる手順になった

• 8番は別の階の複合機を案内する手順で、2階の MFP-2F-01 という具体名は落ちた

必須事実の一致は、8件中4件でした。一致した4件は、症状／パスワードの定期変更／別の階の複合機では保存できること／当面は別の複合機を案内です。2階の件は「別の階」と書かれているため、一致に数えました。一致しなかった4件は、対象が MFP-3F-02 であること／再起動は効果なし／複合機側は未確認で原因は未確定／保守会社への依頼は未完了です。

誤りは2件でした。仮説の確定扱いが1件、効果のなかった再起動の手順化が1件です。記録に無い再現手順や助言の節は、今回は入りませんでした。前の2件とは違い、確認済みの調査を手順として並べ直す形が出ましたが、5つの型には当てはまらないため誤りの件数には数えていません。

修正量は大幅です。原因の欄を未確認に書き直し、再起動は効果なしと書きます。済みの確認は手順から外し、結果だけを残す直しが要ります。依頼の未了と予定日、対象の機器と人数も追記の対象です。修正に要した時間は測っていません。

トピックの文章だけで依頼しても、記事は作られなかった

もう1つ、記録番号を入れず「複合機でスキャンした文書が共有フォルダに保存されないときの確認手順のナレッジ記事を作成してください」と依頼する形を、ナレッジ作成画面で1回試しました。ソースの選択欄はインシデントのままです。返ったのは「関連情報が見つかりませんでした」という文だけで、記事の作成には進みませんでした。

この環境では、トピックだけの依頼で記事を作る使い方は、1回の試行では成立しませんでした。記録番号を添える使い方が、今回確認できた正規の形です。

後始末として、作成された下書きの記事と検証用の記録は、確認後に削除しました。

公式ドキュメントとの違い

SOW でインシデントからナレッジ記事を生成する手順について、公式ドキュメントは次のように書いています（Generate a knowledge article from the Service Operations Workspace for ITSM and classic environment by using ServiceNow Otto）。

• 対象は、担当の解決済み・クローズ済みのインシデント。ほかの状態でも、管理者がシステムプロパティ com.snc.incident.create_knowledge.multistate.enable で設定すれば生成できる

• インシデントの UI アクションから「Create knowledge」を選び、ナレッジベースと記事テンプレートを選んで進む

• 管理者は AI Admin Hub で、入力に使うテーブルの項目と、スキルを表示する場所（製品内かパネルか）を設定する

（訳：管理者がシステムプロパティ com.snc.incident.create_knowledge.multistate.enable で設定した任意のインシデントの状態で、ナレッジ記事を生成できます。）

引用元：上の公式ドキュメント。

今回の2件の記録は、進行中のままでした。開始の操作も、ナレッジ作成画面のリクエスト欄に記録番号を入れる形で、公式の「Create knowledge」とは違います。この環境のシステムプロパティを調べると、上記のプロパティは見つかりませんでした。解決済みにした記録では「ナレッジを作成」が現れましたが、開く画面は説明と解決メモのコピーで、生成の操作は見当たりませんでした。入力に使われた項目や、解決済みの記録での結果は、確かめていません。

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

• 公式ドキュメント：解決済み・クローズ済みの記録（管理者の設定で他の状態も可）で、UI アクション「Create knowledge」から始め、ナレッジベースと記事テンプレートを選ぶ。今回は未検証

• 今回の進行中の2件：ナレッジ作成画面のリクエスト欄に記録番号を入れ、ナレッジベースと言語を選ぶ。各記録2回、計4回生成

• 今回の解決済み1件：「ナレッジを作成」は説明と解決メモのコピーの画面で、生成の操作は見当たらない。代わりにパネルから記録番号付きで依頼し、ツール「KB 記事を生成」を1回実行

ここから先は有料部です。今回の5回の生成から決めた欄ごとの取り扱いの表、担当ごとにすることの一覧、公開前に元の記録と突き合わせる5項目の表を載せています。そのあとに、実機で気づいたこと4点と検証範囲が続きます。分量は本文全体の3割ほどです。

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