ITSMツールに生成AI機能が追加され、「まず有効化して効果を見たい」と考える組織が増えています。 しかし、要約や分類が速くなっても、誤った優先度で重大インシデントを振り分けたり、不正確な回答を利用者へ提示したりすれば、サービス全体の価値は下がります。 導入の出発点は機能一覧ではなく、どのサービス成果を、誰の責任で、どの範囲まで改善するかを決めることです。

PeopleCertの公式レポート「AI in ITSM Tools」（2025年）は、20のITILプラクティスにまたがる66のAIユースケースを調査しています。 現在のAI機能は、インシデント管理、サービス要求管理、ナレッジ管理、問題管理などで先行しているとされます。 一方、AI機能が製品にあることと、自社のサービスに価値をもたらすことは同じではありません。 ITIL 4の価値重視と継続的改善の考え方を使い、限定した業務で学習しながら広げることが現実的です。

課題は「AIを入れるか」ではなく、判断の境界が曖昧なこと

AI導入で起こりやすい問題は、担当者の責任をAIへ置き換えたつもりになり、入力データ、確認手順、例外処理が設計されないことです。 例えば、過去チケットの分類が粗ければ、自動分類も同じ曖昧さを引き継ぎます。 古いナレッジが残っていれば、回答案の生成速度が上がるほど、不適切な情報を速く広めるおそれがあります。

AIはITSMの「解決策」そのものではなく、サービス価値を改善するための一つのツールとして扱います。

PeopleCertの公式記事も、AIは分類、要約、文書化などを加速できる一方、サービスデスク担当者、問題管理担当者、変更権限者の説明責任を置き換えないと説明しています。 したがって、導入判断では精度だけでなく、誤りを発見し、修正し、必要に応じて人へ戻せる運用まで確認する必要があります。

実践手順1：一つの価値ストリームと一つの判断に絞る

最初から「サービスデスク全体をAI化する」と置かず、需要から価値提供までの流れの中で、待ち時間や手戻りが大きい一つの判断を選びます。 候補には、問い合わせの要約、カテゴリ候補の提示、既知の解決策の検索、利用者向け連絡文の下書きなどがあります。 重大度判定、変更承認、外部への最終回答など、誤りの影響が大きい判断は、初期段階では人が確定する設計にします。

  • 対象：どのサービス、利用者、チケット種別に限定するか
  • 期待価値：待ち時間、手戻り、担当者負荷、利用者体験の何を改善するか
  • 除外条件：機密情報、重大インシデント、判断材料が不足するケースをどう除くか
  • 最終責任：AIの提案を確認し、採用または却下する担当者は誰か

実践手順2：データを増やす前に、使える状態を確認する

過去チケットを大量に投入すればよいとは限りません。 まず、分類、解決コード、影響範囲、原因、ナレッジへのリンクなど、対象ユースケースに必要な項目を特定します。 重複、空欄、便宜的な入力、古い手順、個人情報や認証情報の混入を確認し、学習・検索・評価に使えるデータの範囲を決めます。

公式のSITA事例では、インシデントカテゴリと解決コードのばらつきを整理し、データ品質を改善したことが、問題管理との連携や傾向分析の改善につながったと報告されています。 この事例が示すのは、AI以前に、運用データを意思決定に使える形へ整える価値です。 自社でも、入力項目を増やすより、何の判断に使う項目かを明確にし、不要な選択肢を減らす方が先です。

実践手順3：提案・確認・実行を分ける

AIに許す動作を、提案、確認、実行の三段階で整理します。 初期導入では、AIは候補を提示し、人が根拠と原文を確認して確定する形が扱いやすいでしょう。 十分な評価結果と監視態勢が得られた業務だけ、低リスクの実行へ段階的に進めます。

  1. 提案：要約、分類、回答案とともに、参照した情報を表示する。
  2. 確認：担当者が修正・却下でき、判断履歴を記録できるようにする。
  3. 実行：自動処理の対象、停止条件、ロールバック方法を事前に定める。
  4. 例外：不確実性が高い場合や重大影響が疑われる場合は、人へ引き継ぐ。

ベンダーの「精度」だけで判断せず、自社データと実際の業務条件で評価します。 モデルや設定が変わったときに結果を再確認できるよう、テストケース、期待結果、変更履歴も残します。

実践手順4：速度だけでなく、サービス価値を測る

平均処理時間の短縮だけを目標にすると、担当者がAI提案をそのまま承認し、再オープンや誤案内が増えても気付きにくくなります。 ITIL 4の継続的改善では、サービスを変化する事業ニーズに合わせ、プラクティス成功要因や指標を用いて有効性と影響を評価します。 小規模な試行では、導入前の基準値と比較し、量・品質・体験・リスクを組み合わせて確認します。

  • 量：対象件数、AI提案率、人による修正率、例外への引継ぎ率
  • 品質：誤分類、再オープン、誤案内、ナレッジ修正の発生状況
  • 体験：利用者の待ち時間、説明の分かりやすさ、担当者の作業負荷
  • リスク：機密情報の露出、権限逸脱、監査ログ欠落、重大事象の見逃し

指標は一律の目標値にせず、サービスの重要度とリスク許容度に合わせて設定します。 週次で誤りのパターンを確認し、月次で対象範囲、ナレッジ、プロンプト、承認ルールを見直すなど、改善の頻度も決めておきます。

注意点：自動化の範囲を、契約・セキュリティ・利用者説明とそろえる

  • 入力データがどこへ送信・保存されるか、再学習に利用されるかを契約条件と技術設定の両面で確認する。
  • 利用者や担当者に、AIが関与する範囲と、人へ相談できる経路を分かりやすく示す。
  • アクセス権をAI機能の導入前と同等以上に保ち、ナレッジやチケットの閲覧範囲を広げない。
  • 出力の妥当性確認を現場任せにせず、サービスオーナー、セキュリティ、法務・調達など必要な役割を含めて判断する。
  • 障害時や不適切な出力が続く場合に、AI機能を停止して従来手順へ戻せるようにする。

必要な確認事項は、利用するサービス、データ、契約、地域、業界によって異なります。 本記事の手順は一般的な実務整理であり、個別の法令適合性や契約判断を保証するものではありません。

まとめ

ITSMへの生成AI導入は、機能の有効化ではなく、サービス価値を改善する変更です。 一つの判断に範囲を絞り、データ品質を確認し、提案・確認・実行の境界を設け、速度と品質とリスクを一緒に測る。 その結果を継続的改善のサイクルへ戻すことで、現場の責任を曖昧にせず、AIの有用性を確かめながら段階的に広げられます。

参考にした公式資料

FW

WRITTEN BYFourthWall Consulting Teamテクノロジーと経営の両面から、企業変革を支援しています。

← 技術ブログ一覧へ戻る