ITSMにおけるAIを再考する: エージェントの足元にあるデータ

AIエージェントは古い記事をもとに回答しても、それらしく聞こえてしまうことがあります。しかし、いま何が正しいのかを理解していない限り、アクセス権を安全に変更したり、インシデントを更新したり、ワークフローを起動したりすることはできません。

これがAI ITSMの背後にある緊張関係です。市場は多くの場合、キュー(処理待ち)のカバー率、チケットの自己解決率、ルーティングの高速化によって進捗を測ります。これらの指標は重要ですが、より難しい問いには答えていません。すなわち、エージェントはライブで権限を認識したデータから安全な意思決定を下せるのか、という問いです。

自律的なITエージェントの安全性は、その拠り所となるソースの安全性で決まります。

これが重要なのは、最も難しいIT課題がサービスデスクの内側だけにとどまることはめったにないからです。再発するインシデントは、最近の製品デプロイ、進行中のエンジニアリングの課題、構成変更、あるいはユーザーの現在の権限と結びついているかもしれません。AIサービスマネジメントの次の段階は、より良い回答よりも、信頼できるコンテキスト、統制されたアクション、そしてシステム横断で共有されるメモリに、より多くを依存しています。

TLDR: AIが答えるだけでなく「行動する」ようになると何が変わるのか

• AI ITSMが安全なのは、最新のデータを用い、ユーザーの権限を尊重する場合に限られます。
• 昨日のエクスポートをもとに動作するエージェントは、障害そのものを自動化してしまう
• 最も難しいチケットは、製品/エンジニアリングの領域にまたがる
• 成熟度＝キューのカバー率ではなく、安全な意思決定
• 要件: メモリ内のライブデータ＋権限、加えて統制されたライトバック(書き戻し)。

誰もが売り込むAI ITSMの「約束」とは何か？

AI ITSMは、より速いサービスデスクを約束します。従業員が平易な言葉で問題を説明すると、システムは意図を特定し、関連するナレッジを検索し、リクエストをルーティングし、解決策を提示します。

この約束が妥当なのは、サービスデスクがパスワードリセット、アカウントのロック解除、ソフトウェアアクセスから、デバイスのリクエストやインシデントの更新に至るまで、多くの反復的なリクエストを処理しているからです。さらに、標準的な承認や、よくある「どうすればいいのか」という質問も扱っており、これらのワークフローは自動化の有力な候補となります。

ここにこそ、ITSM自動化が明確な価値を発揮します。手作業のトリアージを減らし、チームが一貫して対応できるよう支援します。また、リクエストが既知のパスをたどる場合には、平均解決時間(MTTR)の改善にもつながります。

次のステップはエージェント型のAI ITSMです。提案された回答で止まるのではなく、エージェントは連携したツール全体で複数のステップを実行できます。ユーザーの本人確認を行い、資格を確認し、リクエストを起票し、承認を取得し、プロビジョニングのワークフローを呼び出し、一連の処理を完結させる、といった具合です。

これは自然な進化のように聞こえます。しかし、アクションが増えるたびにリスクも高まります。古いデータをもとに回答すれば、役に立たない応答が生まれるかもしれません。古いデータをもとに行動すれば、誤ったアカウントを変更したり、解決済みのインシデントを再オープンしたり、承認をすり抜けたり、サービス障害を悪化させたりするおそれがあります。

だからこそ、ITセルフサービス戦略は、会話による受付にとどまるべきではありません。従業員が解決にたどり着けるよう支援すると同時に、エージェントが実行できるアクションをITリーダーがコントロールできるようにすべきです。

市場もまた、実験段階から、より大規模なAI投資へと移行しつつあります。

NVIDIAが第6回として実施した年次調査「State of AI in Financial Services」は、800名を超える業界のプロフェッショナルからの回答に基づいており、65%の組織がAIを積極的に活用していることが分かりました。これは前年の45%からの増加です。さらに、61%が生成AIを利用または評価しており、42%がエージェント型AIを利用または評価しています。

重要なポイント: ITSM自動化は、ルーティングやレコメンデーションから「実行」へと移行しつつありますが、実行には回答生成よりも厳格な統制が求められます。

エージェントは実際に何をもとに行動しているのか？

ある従業員が、最近のデプロイ以降ワークフローが動作しなくなったと報告した場面を想像してみてください。従来型のエージェントは古いナレッジ記事を検索し、数か月前の類似インシデントを見つけます。その記事はサービスの再起動を推奨しています。古いインシデントも同じ修正方法を示唆しています。

しかし、現在の状況は異なります。製品チームがワークフローを変更しています。エンジニアリングは関連するリグレッションについて課題(issue)を起票しています。従業員の役割も変わっており、古いアクセスパターンはもはや当てはまりません。

正しい答えを導くには、チケットの履歴だけでは足りません。以下が必要になります。

• 現在のデプロイ状態。
• 進行中のエンジニアリングの課題。
• 最新の製品構成。
• 従業員の現在の役割と権限。
• 関連するインシデントと直近の変更。
• 承認された是正措置のパス。

そうしたコンテキストがなければ、エージェントはもはや当てはまらない、もっともらしい答えを返してしまうかもしれません。そのエージェントがアクションを実行できる場合、リスクは運用上のものへと変わります。

これが、統合データレイヤーが重要である理由です。これにより、エージェントは切り離されたスナップショットに頼らざるを得ない状態から解放され、課題を取り巻く業務を相互に接続された形で見渡せるようになります。

問題は技術的な正確性にとどまりません。アクセス境界も同じくらい重要です。エージェントは、閲覧権限を持たない従業員にエンジニアリングの議論を露出させるべきではありません。また、制限付きのインシデントを根拠にして、そのインシデントのアクセスグループ外の人物のためにアクションを正当化すべきでもありません。

なぜ現在のコンテキストが重要なのか？

ITエージェントがデバイスのリクエストを受け取ったとしましょう。エージェントは、その従業員が標準ノートPCの対象であるとするポリシーを見つけます。そのポリシーは公開された時点では正しいものでした。

しかしその後、調達部門が承認済みのデバイスリストを変更しました。その従業員は別のリージョンに異動しています。従業員のマネージャーも新たな承認要件を導入しました。

静的なナレッジベースは、依然として古いポリシーを返してしまうかもしれません。最新の状態を扱えるエージェントは、行動する前に、ライブのポリシー、所在地、マネージャーとの関係、承認状態を確認する必要があります。

同じパターンはインシデント管理や変更管理でも見られます。ランブックは技術的には正確でも、環境が変わっていれば運用上は誤っている、ということがあり得ます。問題は、AIが手順を理解できないことではありません。手順がもはや現在のシステムを説明していないかもしれない、という点にあります。昨日のエクスポートをもとに動作するエージェントは、ITを自動化しているのではありません。障害そのものを自動化しているのです。

DevRevのEnterprise-Benchは、このコンテキストの問題を分かりやすく示す好例です。

このベンチマークは、同一の基盤となるフロンティアモデルに対する2つのアプローチを比較しています。すなわち、構造化メモリを備えたエージェント(DevRevによるComputer Memory)と、単独で動作する標準的なフェッチベースのアプローチです。両者の差は、接続されたデータとナレッジグラフのアーキテクチャから全面的に生じたものでした。

• Computer, by DevRevは、同一のL1〜L2のエンタープライズタスクにおいて、Claude Codeの63.6%に対し94.3%の精度を達成しました。
• この結果は、正解1件あたりのトークン数を4.4分の1に抑えて達成されました。
• この結果は、あるモデルが常に別のモデルより優れていることを証明するものではありません。より限定的な主張を裏づけるものです。すなわち、エンタープライズにおける性能は、システムがコンテキストをどのように取得し、整理するかに大きく左右され得る。

難しい、あるいは再発するチケットの多くは、サービスデスクの外側にある業務の症状です。それらは製品の不具合、デプロイの問題、構成変更、あるいはプロセスの不備を反映しているかもしれません。これは、すべてのITチケットが製品のバグだという意味ではありません。サービスデスクだけを見ていても、根本的な問題を常に解決できるとは限らない、という意味です。

重要なポイント: エージェントが実際に動作する環境には、現在のシステム、権限、関係性、そして変更が含まれます。安全な自律性のためには、チケットの履歴だけでは不十分です。

成熟度とは、キューのカバー率なのか、それとも安全な意思決定なのか？

AI ITSMの成熟度は、キューのカバー率ではなく、安全な意思決定によって測られるべきです。

• エージェントは現在の状態を特定できるか？
• 回答とアクションを区別できるか？
• リクエスト元の権限を強制(適用)できるか？
• 必要なときに承認を求められるか？
• アクションを取り消したり修正したりできるか？
• どのデータが意思決定の根拠になったのかを説明できるか？
• 完全なコンテキストを添えてエスカレーションできるか？

これにより、成熟度のテストは「ボットはキューのどれだけに触れられるか？」から「エージェントはライブで権限を認識したデータから安全な意思決定を下せるか？」へと変わります。

ITSMにおけるエージェント型AIは安全か？

ITSMにおけるエージェント型AIは、最新のデータを用い、権限を強制し、アクションを制限し、リスクの高い意思決定については人間が主導権を握り続けるとき、安全なものになり得ます。

安全性は単一の機能ではありません。ワークフロー全体にわたって現れなければならない「ふるまい」です。

エージェントは、人・システム・インシデント・製品・エンジニアリング業務の間の関係性を理解すべきです。それらの関係性に付随する権限を尊重すべきです。また、可能な限り、機微なアクションを取り消し可能にすべきです。

実践的なモデルには、4つの統制が含まれます。

1. 最新のコンテキスト: エージェントは、古くなったスナップショットに頼るのではなく、ライブの情報を用います。
2. 権限の認識: エージェントは、リクエスト元とオペレーターのアクセス境界を尊重します。
3. 統制されたアクション: エージェントは、承認されたツールとワークフローのみを呼び出せます。
4. トレーサビリティ: 組織は、エージェントが何を見て、何を判断し、何を変更したのかをレビューできます。

ここで、エンタープライズAIメモリが重要になります。エンタープライズAIメモリは、単なる大容量のドキュメントストアではありません。アクセスルールを尊重しつつ、システム横断で有用なコンテキストを保持する手段をエージェントに与えるものです。

目標は、何がなんでもエージェントを独立して行動させることではありません。従業員をIT・製品・エンジニアリングの間の統合レイヤーにさせることなく、適切なレベルの自律性を実現することが目標です。

重要なポイント: 安全なエージェント型AI ITSMは、ライブのコンテキスト、権限の強制、統制されたツール、そして追跡可能なアクションを組み合わせます。自律性は、これらの統制が強固な領域においてのみ拡大すべきです。

AI ITSMはどのようにしてシステム横断で安全なアクションを実行するのか？

AI ITSMが安全なアクションを実行できるのは、エージェントが最新のコンテキストを、承認されたスキルおよび統制されたライトバック(書き戻し)へと結びつけられるときです。

Computer, by DevRevは、接続された運用モデルを通じてこれに取り組みます。

• Computer Memoryは、関連するIT・製品・エンジニアリング・ナレッジのコンテキストを一つに束ねます。
• AirSyncは、接続されたシステム全体で情報を最新の状態に保ち、統制されたワークフローを通じてお客様のシステムに読み込み・書き戻しを行います。

その結果は、ナレッジベースを検索するチャットボットにとどまりません。リクエストについて推論し、承認された業務を完遂できるエージェントです。

典型的なフローは次のようになります。

1. 従業員が自然言語で問題を説明します。
2. Computerが、リクエスト、影響を受けるサービス、ユーザーのコンテキストを特定します。
3. Computer Memoryが、現在のインシデント、製品の状態、エンジニアリング業務、ポリシー、権限を取得します。
4. Computerが、承認済みのAgent StudioのSkillまたはワークフローを呼び出します。
5. Safe Actionsが、そのアクションに承認が必要かどうかを確認します。
6. ワークフローが、関連するシステムを更新します。
7. 従業員が、明確なステータスの更新を受け取ります。
8. アクションと意思決定のパスは、レビューできる状態で残ります。

Agent Studioは、明確なステップ、権限、承認ルールを備えた、反復可能なITワークフローをチームが定義できるよう支援します。これらは、アクセスのプロビジョニング、デバイスのリクエスト、インシデントの更新、オンボーディングとオフボーディング、アカウントのロック解除、標準変更、承認フロー、ナレッジのレコメンデーションをサポートできます。

Safe Actionsは、機微な変更に対する統制を加えます。権限の更新、アカウントの変更、あるいは本番環境に関わるアクションには、確認、承認、ロギング、取り消しが必要になる場合があります。具体的にどの統制が適用されるかは、組織のポリシーとその操作のリスクによって決まります。

ワークフローを自動化する前に、ITリーダーは次の点を明確にすべきです。

• どのリクエストが大量かつ低リスクか
• どのシステムが信頼できる正データ(オーソリテイティブなデータ)を保持しているか
• どのアクションに承認が必要か
• どこで権限が頻繁に変わるか
• どのアクションが取り消し可能か
• エージェントがいつ人間へエスカレーションすべきか
• 監査とコンプライアンスのためにどのような証跡が必要か

このプロセスは、よくある誤りを回避します。すなわち、目に見えるチケットのフローだけを自動化する一方で、実際の解決を別システムでの手作業に依存させたままにする、という誤りです。

重要なポイント: Safe Actionsは、ライブのコンテキストを、定義されたSkillと統制されたワークフローに結びつけることから生まれます。エージェントは、企業全体で場当たり的にふるまうのではなく、明確な境界の内側で行動すべきです。

ITチームは「統合レイヤー」であることをやめられるか？

多くの組織では、チームがツール間でコンテキストを移し替える間、従業員は待たされます。サービスデスクは、人力の交換台と化してしまいます。

AI ITSMはこのパターンを改善できますが、それはチケットの向こう側にある業務を見渡せる場合に限られます。エージェントは、従業員・インシデント・製品領域・デプロイ・エンジニアリングの課題・ポリシー・アクションの間の関係性を理解する必要があります。

これは、あらゆるチームがあらゆるものをあらゆるエージェントに開示すべきだという意味ではありません。権限の境界は依然として不可欠です。これは、権限を与えられたエージェントが、利用を許可されたコンテキストを取得し、人間がシステム間でコピー＆ペーストすることを強いられることなく業務をルーティングできるようにすべきだ、という意味です。

Computerは、従業員のリクエストを解決するエンドツーエンドの解決モデルに焦点を当て、アクセスのワークフローをサポートし、アクションをログに記録して監査可能な状態に保ちます。

成果はチケット数の削減そのものではありません。より良い成果は、各チケットを取り巻く調整作業が減ることです。

従業員はより明確な答えを得られます。ITチームはコンテキストを追いかける時間を減らせます。リーダーは、サービス業務がどこで発生しているのかについて、より現実的な視野を得られます。

最も強力なサービスデスクは、あらゆるワークフローから人間を排除することを目指しません。リスクが求める場面には判断を残しつつ、不要な調整を取り除きます。自律的なITエージェントの安全性は、その拠り所となるソースの安全性で決まります。

Computerがどのようにシステム横断でIT課題を安全に解決するのか、デモを予約して、チームと一緒にご覧ください。