AI エージェントでチケットキューをトリアージ:Halo Service Desk のデータと CData API プロファイル
サービスデスクのチームは毎朝、SLA 違反のリスクがあるチケットを確認し、担当者未割り当てのリクエストを洗い出し、関連するナレッジベース記事を探して、チケットを適切なチームに振り分けています。いずれも注意力と判断力が求められる作業ですが、繰り返しの多い作業でもあります。必要なデータにアクセスできれば、こうした作業は AI エージェントに任せることができます。
CData API Driver 向けの Halo Service Desk プロファイルを使えば、エージェントがそのデータにアクセスできるようになります。このプロファイルは、Halo のチケット、ナレッジベース、チーム、エージェント(担当者)、資産、クライアント、契約を読み取り専用の SQL テーブルとして公開し、AI エージェントや BI ツール、アプリケーションから自由に利用できるようにします。この記事では、稼働中の HaloITSM インスタンスに対して実際に行ったトリアージの様子を、実行したクエリ、エージェントの推論、そしてエージェントがまとめたブリーフィングとあわせてご紹介します。
サービスデスクのトリアージが AI エージェントに向いている理由
トリアージは、情報を読み取って照合していく作業です。エージェントであれ人であれ、トリアージをうまく進めるには次のことが必要です。
- キューの優先順位付け:優先度、チケットの種類、SLA の期限、保留状態、そして各チケットの担当者の有無を考慮します。
- 既知の解決策との照合:各チケットの概要と詳細をナレッジベースと比較し、既存の記事で対応できるものを見極めます。
- パターンの発見:異なるチームに届いた複数のチケットが、同じ根本的な障害を示していることに気づきます。
- 正しい振り分け:チームの割り当てルールを適用します。このルールは、システムの設定ではなくドキュメントにまとめられていることがよくあります。
こうした情報はすべて Halo の中にあり、チケット、ナレッジベース記事、ステータス、優先度、チーム、エージェントに分散しています。Halo の REST API からもアクセスできますが、エージェントにとっては、わかりやすく定義された少数のテーブルと、すでに使い慣れたクエリ言語があるほうがはるかに作業を進めやすくなります。
CData API Driver と Halo Service Desk API プロファイル
CData API Driver は、API プロファイルを通じて数百種類の API やサービスへの SQL アクセスを提供します。API プロファイルとは、サービスのテーブルとカラム、認証方法、API のページング方法を定義した小さなファイルです。ドライバーの Profile プロパティにプロファイルファイルを指定し、接続プロパティを設定するだけで利用できます。認証、ページング、クエリのプッシュダウンはドライバーが処理し、結合、サブクエリ、集計を含む SQL-92 クエリにも対応しています。
API Driver は、ほかの CData ドライバーと同じく JDBC、ODBC、ADO.NET、Python の各エディションで提供されており、BI ツールや ETL ツールとの連携にも対応しています。以下の例では、CData JDBC Driver for API を使用します。
Halo への接続
このプロファイルは、Halo の API キーで認証します。API キーは、Halo のAdministrationで作成・確認できます。Integrationsを選択し、Halo APIを開いてください。
Profile=C:\profiles\HaloServiceDesk.apip;AuthScheme=APIKey;ProfileSettings='APIKey=<halo_api_key>;Domain=yourcompany.haloitsm.com';
| プロパティ | 説明 |
|---|---|
| AuthScheme | APIKey |
| APIKey(ProfileSettings 内) | Halo の API キー。各リクエストとともに送信されます |
| Domain(ProfileSettings 内) | Halo インスタンスのホスト名(https:// は含めません) |
接続から参照できる範囲は、API キーに紐づく Halo アカウントの権限で決まります。つまり、エージェントが読み取れるデータは API キーの権限によって制御されます。
データモデル
このプロファイルでは、次の 19 個のテーブルを利用できます。
| 分野 | テーブル |
|---|---|
| チケットと作業 | Tickets、Actions、Attachments、Projects |
| 設定 | Status、Priority、TicketType、Teams、Agents |
| ナレッジ | KBArticles |
| 顧客とユーザー | Clients、Sites、Users |
| 資産とサプライヤー | Assets、Suppliers |
| 商取引 | Contracts、Invoices、Items、Opportunities |
- Tickets は、このプロファイルの中核となるテーブルです。各チケットには、概要と詳細、Hardware > Docking Station > Not Working のようなカテゴリパス、ステータス、優先度、緊急度、影響度、チケットの種類、チームとエージェント、報告したユーザーとサイト、そして SlaState、RespondByDate、ResponseDate、FixByDate などの SLA 関連フィールドが含まれます。
- KBArticles にはナレッジベースが格納されており、各記事の名前、説明、解決方法を参照できます。
- Status、Priority、TicketType、Teams、Agents を使うと、チケット上の ID が何を意味するのかがわかります。たとえば、どのステータスが On-Hold(保留)か、どの優先度が Critical で、その応答目標と解決目標はどうなっているか、チケットの種類ごとにデフォルトで割り当てられるチームはどこか、どのエージェントがどのチームに所属しているか、といった情報です。
始業時のトリアージ
今回は、実際の IT サービスデスクに近いキューを持つ HaloITSM インスタンスにプロファイルを接続しました。キューには、ハードウェアの故障、ソフトウェアのリクエスト、フィッシングの報告、アクセス権のリクエスト、人事システムの問題などのチケットが含まれています。これらのチケットは、1st Line Support、2nd Line Support、Infrastructure、Facilities、Payroll、HR といったチームに分散しています。
続いて、CData ドライバーを通じてコマンドラインからデータにアクセスできる CData CLI を使う AI エージェントに、サービスデスクのリーダーから次のような依頼を出しました。
未対応のサービスデスクキューをトリアージしてください。最初に対応すべきものはどれか、既存のナレッジベース記事で解決できるチケットはどれか、同じ根本原因と思われるチケットはどれか、そして振り分けが間違っていそうなチケットや担当者未割り当てのチケットはどのチームが担当すべきかを教えてください。
エージェントは 12 回のコマンドで、経験豊富なチームリーダーさながらにキューを整理していきました。
スキーマの把握:まず Tickets のカラムを一覧表示し、続いて必要なフィールドだけを指定してキューを取得しました。取得したのは、概要、詳細、カテゴリ、ステータス、優先度、種類、チーム、エージェント、SLA の日付と状態、保留フラグ、関連付けられたナレッジベース記事などです。
SELECT [Id], [Summary], [Details], [StatusId], [PriorityId], [TicketTypeId], [Team], [AgentId],
[Category1], [SlaState], [RespondByDate], [ResponseDate], [FixByDate], [IsOnHold], [MatchedKbId]
FROM [Tickets]
ID の解読:Status、Priority、TicketType、Teams、Agents を読み込み、どのステータスが On Hold か、どの優先度が Critical か、チケットの種類ごとのデフォルトのチームはどこかを把握しました。また、エージェント ID 1 が「Unassigned(未割り当て)」を意味することも確認しています。
SELECT [PriorityId], [Name], [SLAId], [FixTime], [FixUnits], [ResponseTime], [ResponseUnits]
FROM [Priority] ORDER BY [SLAId], [PriorityId]
ナレッジベースの読み込み:すべての記事の名前と説明に目を通したうえで、関連がありそうな記事の全文を取得しました。その中には、チームが人向けに書いた「Team Assignment Rules(チーム割り当てルール)」という記事も含まれていました。
SELECT [Id], [Name], [Description], [Resolution]
FROM [KBArticles] WHERE [Id] IN (23, 27, 33, 39, 43, 44, 46)
すべての情報を横断した推論:これらをもとに推論を行い、以下のブリーフィングをまとめました。
トリアージの結果
以下は、エージェントの回答を編集したものです(人名は役職に置き換えています)。
キューの概況:対応中のサービスチケットは 29 件で、そのうち 21 件は担当者が未割り当てです。未解決のチケットはすべて SLA の範囲内で、解決期限が最も近いものは 2 日後です。
最優先で対応すべきチケット
- #3951:CEO を装って至急の支払いを求めるメール。優先度は High ですが、10 日間保留のままになっています。同じキャンペーンによる以前のフィッシング報告では、ユーザーがパスワードを入力してしまっていました。保留を解除し、支払いが行われていないことを確認したうえで、送信者をブロックし、ほかに誰が受信したかを確認してください。
- #3974:特定のクライアント宛てのメールが繰り返し返送される問題。キュー内で唯一の Critical チケットです。2nd Line Support に割り当てられていますが、担当者は未割り当てです。2nd Line のエンジニアに割り当ててください。
- #3987:起動のたびにブルースクリーンになるデスクトップ PC。優先度は High で担当者は未割り当て、ユーザーは業務ができない状態です。
- #3982:月次レポートのクエリがタイムアウトする問題。優先度は High で、1st Line に担当者未割り当てのまま置かれていますが、データベースのパフォーマンスの問題です。Infrastructure に振り分けてください。
ナレッジベースで解決済みのチケット:未解決のチケットのうち 6 件が、既存の 5 つの記事に該当します。ノート PC の動作が遅い問題、スマートフォンが会社のポリシー適用中のまま進まない問題(モバイル登録の記事が該当)、パスワードのリセット、プリンターのトナー残量不足、そして 2 件のソフトウェアのインストール依頼です。いずれも、Halo 上ではまだ記事が関連付けられていません。このほか 3 件のチケットは記事と部分的にしか一致しないため、その記事を根拠にクローズすべきではありません。
根本原因が同じと思われるチケット
- ドッキングステーション:未解決のチケットが 3 件(ドッキング時に周辺機器が切断される、ドック経由の有線 LAN が途切れる、ディスプレイの配置がリセットされる)と、5 月以降にクローズされたチケットが 3 件あり、4 つのチームに分散しています。1 件の Problem レコードとしてまとめて起票することをおすすめします。
- フィッシングキャンペーン:同じカテゴリで 5 件の報告があります。#3951 を後回しにすべきでないのはこのためです。
- モバイル登録:未解決のチケット 1 件と、クローズ済みのチケット 6 件が同じ症状を示しており、いずれも同じ記事で対応できます。
- 関連性を確認すべきチケット:人事システムのアクセスに関する問題が 2 件、そしてどちらも最近「何も変更していないのに」発生した Salesforce の問題が 2 件あります。
Team Assignment Rules 記事に基づく振り分けの修正:約 10 件のチケットが誤ったチームに割り当てられています。Facilities は「IT 関連の作業は一切扱わない」ことになっていますが、ドッキングステーションの故障とマウスの交換を抱えています。また Payroll には、アプリケーションのクラッシュと CRM の同期エラーが割り当てられていますが、どちらも給与の支払いには影響しません。それぞれについて、ルール上の正しい担当チームを示しています。
うまくいった理由
チケットの外にあるコンテキスト:最も役立った振り分けのアドバイスは、チケットのフィールドから得られたものではありません。人向けに書かれたナレッジベース記事から得られたものです。エージェントは、チケットと同じ接続を通じてこの記事を読み取ることができました。
解読できるコード:ステータス、優先度、チケットの種類、チーム、エージェントの各テーブルによって、ID の羅列が On-Hold、Critical、Unassigned、Facilities といった意味のある情報に変わりました。
技術スタック
| 構成要素 | 役割 |
|---|---|
| HaloITSM | サービスデスク本体(チケット、ナレッジベース、チーム、SLA) |
| CData JDBC Driver for API | Halo Service Desk API プロファイルを実行し、API キー、リクエスト、ページングを処理 |
| Halo Service Desk API プロファイル | チケット、ナレッジベース記事、各種設定を読み取り専用の SQL テーブルとして公開 |
| CData CLI | AI エージェントに、同じ JDBC ドライバーへのコマンドラインアクセスを提供 |
CData API Driver を試してみよう
サービスデスクのキュー、ナレッジベース、チームのルールには、トリアージを的確に行うために必要な情報がすべてそろっています。しかし、それらを毎日まとめ上げるには手間がかかります。Halo Service Desk API プロファイルを使えば、CData API Driver 上でこれらのデータを SQL テーブルとして利用できます。AI エージェントがキューの優先順位付け、既存の解決策とチケットの照合、繰り返し発生する問題の発見、適切な担当者の提案を行い、ブリーフィングとして担当者に引き渡せるようになります。同じテーブルは、BI ツールでの SLA ダッシュボードの作成や、CData Sync によるチケット履歴のレプリケーションにも活用できます。
このプロファイルは、CData のすべてのエディションで利用できます。CData API Driver をダウンロードして Halo Service Desk プロファイルを追加し、Halo の API キーで接続したら、Tickets に最初のクエリを実行してみてください。