インシデント分類のAIエージェント：日本語12件での比較

インシデントの分類を AI に任せたいとき、知りたいのは「どれくらい当たるのか」です。当たったかどうかは、何を正解と決め、何と比べたかで変わります。そこで日本語のインシデントを12件用意し、先に正解を決めました。そのうえで、Now Assist の分類エージェント、キーワードで決める簡単なルール、何もしない場合の3つを比べています。category と subcategory の一致は、エージェントが11件、ルールが9件、何もしない場合が0件でした。ただしエージェントは、手動テストでも承認の画面を出さずに記録へ書き込みました。

画面で確かめた要点

• 分類エージェントの回答は、12件中11件で事前に決めた分類と一致した。外したのは、プリンターに当たるサブカテゴリがない「Printer」の1件

• 件名と説明に、ルールの対象語がなかった3件（共有フォルダ、勤怠システム、Teams）では、ルールが外し、エージェントの回答は一致した

• エージェントは判定した9件に、その場で category と subcategory を書き込んだ。承認の画面は出なかった

• 担当グループの推定は、今回の検証対象外。Predictive Intelligence に学習済みの結果が1件もないため

試した規模と正解の決め方

試したのは12件のデモレコードです。エージェントは12件に1回ずつ実行しました。回答が、同じ入力の繰り返しで揺れるかは未確認です。ケーススタディであり、OOTB 全体の精度を測る評価とは位置づけが異なります。目的は、分類をどこまで任せられるかを考える観点の洗い出しです。

ここでいう正解は、筆者が実行の前に定めた期待分類です。症状から原因が確定するわけではなく、曖昧な件は筆者の判断で割り当てています。選択肢にある値だけを使い、情報が足りない2件は「分類しない」を正解としました。

「空」は、正解ラベルでは分類しないこと、エージェントの回答では判定なしを指します。起票時の category には既定値の inquiry が入っているため、判定なしの件も保存値は空になりません。採点では、判定なしを空と同じ扱いにしています。

ルールも筆者が書いたもので、12件の内容を知ったうえで作っています。ルールの成績は、実際の運用より高く出ている可能性があります。

分類と振り分けに使える標準の機能

この環境で、分類や振り分けに関係する標準の機能は次のとおりです。

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

• Predictive Intelligence の分類（件名から category と担当グループを予測）：プラグインは有効。ただし学習済みのソリューションが0件で、予測を出せない。試せず

• 分類エージェント（Categorize ITSM incident AI agent、カテゴリとサブカテゴリを選択肢から選ぶ）：有効。今回動かした

• トリアージと分類のワークフロー（上の分類に、サービス・オファリング・CI の分類と重大インシデントの関連付けを加えた3つのエージェント）：有効。今回はこのワークフロー経由で分類エージェントを動かした

• 割り当てルール（条件で担当グループを決める）：有効なルールは3件。category から担当グループを決めるルールはすべて無効。試さず

今回は、結果を期待分類と照合できる分類エージェントを評価の対象にしました。

Predictive Intelligence の状態は、設定の画面で確かめられます。インシデントの分類ソリューションは0件で、学習の要求は85件中79件がタイムアウトでした。学習データを用意して再学習する作業は設定の変更になるため、今回は行っていません。

元にしたインシデント12件

結果の前に、元になった12件を説明します。起票者はメールを持たないテスト用の利用者で、状態は新規、影響度と緊急度は低です。

• 明確な4件：VPN の認証失敗、モニターに映像が出ない、Outlook の送信トレイにメールが残る、Oracle への接続エラー。件名か説明に、機器やソフトの名前がそのまま出ている

• 曖昧な4件：共有フォルダが開けない、動作が遅い、勤怠システムの画面が真っ白、会議中に音声が途切れる。症状は書いてあるが、原因の分野を名指ししていない

• 英語混じりの2件：Teams の screen share、3F の Printer の offline。日本語の文に英単語が混ざる

• 情報不足の2件：「お願いします」「至急見てください」と、「パソコンの件」「昨日から変です」。分類の手がかりがない

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

• 01（明確）：在宅勤務で VPN 認証に失敗する。正解は network / vpn

• 02（明確）：会議室のモニターに映像が出ない。正解は hardware / monitor

• 03（明確）：Outlook の送信トレイにメールが残る。正解は software / email

• 04（明確）：Oracle データベースに接続できない。正解は database / oracle

• 05（曖昧）：Z ドライブの共有フォルダが開けない。正解は network、サブカテゴリは空

• 06（曖昧）：動作が遅く、ディスク使用率が100%。正解は hardware / disk

• 07（曖昧）：勤怠システムの画面が真っ白。正解は inquiry / internal application

• 08（曖昧）：会議中に音声が途切れ、Wi-Fi に感嘆符。正解は network / wireless

• 09（英語混じり）：Teams の screen share が出来ない。正解は software、サブカテゴリは空

• 10（英語混じり）：3F の Printer が offline になる。正解は hardware、サブカテゴリは空

• 11（情報不足）：「お願いします」「至急見てください」。正解は空

• 12（情報不足）：「パソコンの件」「昨日から変です」。正解は空

hardware にはプリンターに当たるサブカテゴリがないため、10 のサブカテゴリは空としました。07 の inquiry は、画面では「問い合わせ/ヘルプ」と表示される選択肢です。

AI Agent「Categorize ITSM incident AI agent」の検証

分類エージェントは、インシデント番号から件名と説明、選択できるカテゴリとサブカテゴリを取得し、当てはまるものを選ぶ AI エージェントです。画面では「ITSM インシデントの分類 AI エージェント」と表示されます。

起動方法は、AI エージェントスタジオの［テスト］タブにある手動テストです。インシデント画面の Now Assist パネルの候補には、このエージェントが出ませんでした。レコード作成で自動起動するトリガーも、この環境では無効です。手動テストでは、テストの種類で「AI エージェントまたはワークフロー」を選び、ワークフロー「ITSM インシデントのトリアージと分類」を指定します。タスクの欄に「インシデント INC00xxxxx のカテゴリとサブカテゴリを分類してください。」と書いて実行しました。

起点は手動テストで、緑は実機で動かした経路、橙は記録へ書き込む経路、灰色は動かしていない経路です。

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

• 起点は AI エージェントスタジオの手動テスト（今回の起動方法）。レコード作成時の起動トリガーはこの環境で無効

• どちらもワークフロー「ITSM インシデントのトリアージと分類」に入り、分類エージェント Categorize ITSM incident AI agent が判定する

• 判定した場合は、category と subcategory を記録へ書き込み、作業メモを追記する

• 判定なしの場合は、書き込まず理由だけを画面に表示する

最初の1件、VPN の件では、実行の開始から約90秒で結果が出ました。

①は Outlook の件です。エージェントは「メール送信時に送信トレイへ残り続ける事象」という説明の語句を引いて、software と email を選びました。②の「Update incident」が、記録の更新を行うツールです。この画面の時点で、インシデントの category と subcategory は書き換わっています。書き込み後の画面は、気づいたことの節に載せます。

12件の結果は次のとおりです。

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

• 01：エージェントは network / vpn で○。ルールも○

• 02：エージェントは hardware / monitor で○。ルールも○

• 03：エージェントは software / email で○。ルールも○

• 04：エージェントは database / oracle で○。ルールも○

• 05：エージェントは network、サブカテゴリは空で○。ルールは空で✕

• 06：エージェントは hardware / disk で○。ルールも○

• 07：エージェントは inquiry / internal application で○。ルールは空で✕

• 08：エージェントは network / wireless で○。ルールも○

• 09：エージェントは software、サブカテゴリは空で○。ルールは空で✕

• 10：エージェントは判定なしで✕。ルールは hardware で○

• 11：エージェントは判定なしで○（正解は空）。ルールも○

• 12：エージェントは判定なしで○（正解は空）。ルールも○

公式ドキュメントの説明

公式ドキュメントでは、分類エージェントの動きを4段階で説明しています。インシデントの詳細と選択肢を取得し、カテゴリとサブカテゴリを割り当て、推奨を利用者に提示してから、インシデントを更新する流れです。

手動テストでは、提示と更新が同じ実行の中で続けて起きました。更新の前に利用者の承認を求める画面は、12件のどれでも出ていません。このエージェントの更新ツールは、実行モードが自動実行（autopilot）の設定でした。

エージェントが外した1件

外したのは、3F の Printer が offline になる件です。エージェントは category を「未判定」と答え、理由を次のように書きました。

hardware というカテゴリ自体はありますが、プリンターに当たるサブカテゴリはなく、エージェントは判定を控えました。エージェントへの指示には、確信が持てないときは判定しないと書かれています。

①が判定なしの回答、②が記録を更新するツールの呼び出しです。ツールは呼ばれましたが、category は既定の inquiry のままでした。10〜12では判定が返らず、分類の値は変更されていません。情報不足の2件（11 と 12）も同じ動きで、分類しないことが正解の件では、この動きが一致につながりました。

ルールと、何もしない場合との比較

ルールは、件名と説明を連結した文字列に対して、上から順に最初に当てはまった規則で決めます。規則は13個で、事前に書きました。VPN なら network / vpn、Oracle なら database / oracle といった対応表です。当てはまる規則がなければ空にします。環境には保存せず、計算だけで出しています。

何もしない場合は、起票直後の状態です。この環境では category の既定値が inquiry で、全件がそのまま inquiry になりました。

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

• エージェント：category と subcategory が正解なのは11件。category だけ見ても11件。9件に書き込んだ

• ルール（筆者が定義）：正解は9件。category だけ見ても9件。書き込みなし（計算のみ）

• 何もしない：正解は0件。category だけ見ると1件（07：勤怠システム）。書き込みなし

ルールが外した3件は、共有フォルダ（05）、勤怠システム（07）、Teams（09）です。対応する語を規則に入れていなかったため、どれも空になっています。この3件で、エージェントの回答は事前の期待分類と一致しました。Printer の件は逆で、筆者が「Printer」を規則に入れていたためルールが当て、エージェントが外した件になっています。

比較すると、次のことが分かります。

• 言葉が決まっている障害（VPN、Outlook、Oracle など）は、ルールでも同じ件数が一致した。この範囲では、精度の差は出ていない。規則を書いて保守する手間がどれだけ減るかは、測っていない

• 今回の規則で拾えなかった05・07・09では、エージェントの回答が期待分類と一致した。言い換えを変えて繰り返す試験は行っていない

ただし、12件で見える差は2件です。この差が運用でも続くとは言えません。自分の環境で試す場合は、過去のインシデントから数十件を抜き出し、人が付けた分類を正解にして、同じ比較を行います。

担当グループの推定の状態

担当グループの推定は、今回の検証対象外です。分類エージェントが入れるのは category と subcategory で、担当グループは対象に入っていません。12件とも、アサイン先グループは起票時のままです。

担当グループを予測する標準の機能は、Predictive Intelligence の「Incident Assignment」です。この環境ではソリューションが0件で、予測は出せません。割り当てルールは category からグループを決める3つのルールがすべて無効で、起票者のロールと重大度で動くルールだけが有効です。担当グループを決める精度は測っていません。

実機で気づいたこと

手動テストでも、記録は書き換わる

手動テストは動作を確かめる画面に見えますが、実際の記録を更新します。この環境の更新ツールは、実行モードが自動実行（autopilot）でした。エージェントの説明には「ユーザーの承認を受けた後に更新できる」とありますが、テストでは承認の画面が出ないまま、9件に書き込まれました。試すなら、削除できるテスト用のレコードを使います。

次の画像は、最初の VPN の件で、書き込み後のインシデントを開いた画面です。

①のカテゴリとサブカテゴリには、AI が入れたことを示す印が付きます。②のアサイン先グループは変わっていません。分類のフィールドに加えて、作業メモにも、エージェントが入れた旨の記録が残ります。12件とも、グループ、CI、サービスは起票時のままでした。

件名の英単語で自動入力する仕組み

この環境には、件名の英単語で category と担当グループを入れるデモ用のビジネスルールがありました。最初に作った3件では、件名に「VPN」と「Outlook」を入れたため、分類と担当グループが自動で書き換わり、担当グループの変更を知らせる通知の記録が1件できました。宛先はサンプルのアドレスで、送信されない状態です。この3件は削除し、12件は件名から英単語を外して作り直しています。デモ環境で「予測」が当たって見えるときは、こうした仕組みの影響を疑います。

回答の表示まで、通常40〜65秒

結果の文が画面に出るまでは、1件あたり約40〜65秒でした（5秒刻みで確認。最初の1件は約90秒）。実行の記録上の所要時間は110〜250秒ですが、結果が出た後も実行が終了していない記録が多く、待ち時間の目安には使えません。人が手で分類する時間は測っていません。

分類エージェントの任せ方

今回の12件では、分類エージェントの回答は11件で期待分類と一致しました。ただし、承認の画面を出さずに記録へ書き込みます。そのため、分類はエージェントの回答を担当者が確かめる形で使い、担当グループは別の仕組みで決めます。

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

• 言葉が決まっている障害は、ルールとエージェントのどちらでもよい。明確な4件は、両方とも一致した。ただし今回のルールは12件を知ったうえで作ったもの

• 症状だけの記録は、エージェントの回答を担当者が確かめる。ルールが外した3件（05・07・09）で、エージェントは一致した

• 情報不足や選択肢に無い分野は、判定なしを担当者が引き取る。10〜12の3件は、書き込まずに止まった

• トリガーでの自動書き込みは、今は有効にしない。手動テストでも、承認の画面なしで9件に書き込んだ

• 担当グループは、エージェントに決めさせない。分類エージェントの対象外で、Predictive Intelligence の予測は0件だった

ここから先は、導入前に決めることをまとめています。選択肢と担当グループの見直し方、担当ごとにすること、今回使った13の規則、自分の環境で同じ比較をする5つの手順です。約1,800字です。

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