エージェント型AIはITインフラ運用をどう変えるのか?ガートナーが“6つの活用ケース”で示す将来図
「守り」の情シスから「AIファースト」のイノベーターへ変革を
複雑なワークフローをどう制御する? オーケストレーターが整理する実装モデル
まず「1. ITオペレーションのナレッジアシスタント」は、調査結果の中で最も多くの回答を集めたユースケースだ。ChatGPT同様のチャット型インターフェースを介して、様々なリポジトリーの中に散在している情報を探すニーズは根強い。エージェント型AIに質問をし、求める情報を回答として示してもらうもので、それほど複雑ではないが拡張性はあまりない。
「2. ログ監視とアラートエンリッチメント」は、多数のアプリケーションログを扱わなくてはならないI&Oチームの切実なニーズに応えるユースケースである。各種ログは、人間が理解しやすい形式で出力されるわけではないため、分析できるようにするまでに大きな手間がかかる。ここで活躍するのが、データ取り込みエージェントとエンリッチメントエージェントという2つの役割ベースのエージェントだ。データ取り込みエージェントは、各アプリケーションからログを取得し、正規化する役割を担う。
ここで活躍するのが、MCPとA2Aの2つのプロトコルである。MCPを利用することで、データ取り込みエージェントは複数のデータソースにアクセスできる。そしてA2Aで引き継ぐことで、正規化したデータをエンリッチメントエージェントに渡せるのだ。エンリッチメントエージェントはITSMツールのデータのコンテキストを付加してからデータを解析し、対処するべきパターンを発見したらアラートを出力する。
次の「3. 自動インシデントルーティング」は、オーケストレーターが複数のエージェントの挙動を制御する点において2のユースケースと異なる。データ取り込みエージェントはデータを収集し、オーケストレーターエージェントに渡す。オーケストレーターエージェントはコンテキストを解析し、具体的なタスクに落とし込む。トリアージが必要な場合はトリアージエージェントに、データエンリッチメントが必要な場合はエンリッチメントエージェントに正規化したデータを渡す。そしてエンリッチメントエージェントは、APM(Application Performance Monitoring)ツールや可観測性ツールのデータでコンテキストを付加する。オーケストレーターエージェントは、受け取ったデータをルーティングエージェントに渡し、サポートチームへの通知に利用してもらう。このように複数のエージェントが協働するため、自動インシデントルーティングは2のログ監視とアラートエンリッチメントよりも複雑なユースケースとわかる。
[画像クリックで拡大します]
「4. インテリジェント異常検知」も、比較的I&Oチームからのニーズが大きいユースケースだ。背景には人材不足の問題がある。AIの能力を用いることで、ますます複雑になるインフラの異常検知から対処までのプロセスの自動化を改善できるのではないかという期待があるからだ。
このユースケースでは、2や3のユースケースと同様に、データ取り込みエージェントが様々なデータソースからデータを収集し、コンテキストを付加してエンリッチメントエージェントに渡す。そのデータは、異常検知エージェント、分類エージェント、根本原因分析エージェント、アラート作成エージェントなどに渡され、その結果アラートがI&Oチームの担当者に送られる。他のユースケースとの相違は、この後のプロセスで人間が介入するフィードバックループがあることだ。アラートを受け取った担当者は、フィードバックループエージェントにアラートが役に立ったと知らせる。逆に役に立たなかった場合は、継続的学習エージェントに知らせ、異常検知エージェントに再学習してもらう流れとなる。
事前検知から改善まで:人のフィードバックも組み込んだフローに
迅速な異常検知と継続的学習の流れを確立できた末には、根本原因分析に留まることなく、問題が発生する前の兆候を検知して未然に対策を講じるようにしたいと考えるはずだ。より洗練された仕組みへの進化を目指す「5. 予知保全」のユースケースでも、データ取り込みエージェントからデータクリーニングエージェントを経由して障害予測エージェントにデータが渡される。そこで出た予測結果を保守レコメンデーションエージェントに渡す流れとなり、先ほどの異常検知のシナリオに似ている。その後、レコメンデーションエージェントは対応計画を作り、スケジュール管理/ディスパッチエージェントに渡す。その先には、モニタリング/アラート作成エージェントがいて、I&Oチームに現地での作業計画を送って指示をしてくれる。4のインテリジェント異常検知ユースケースと同様にフィードバックループがあり、障害予測が正しかったかをフィードバックし、継続的に予測改善を行う仕組みが出来上がる。
[画像クリックで拡大します]
最後のユースケースが「6. スクリプト生成と自動化」だ。ITインフラマネジメントプロセスで採用されているIaC(Infrastructure as Code)のスクリプト生成は、手作業に依存する部分が多く、AI活用による負担軽減が期待されている領域である。
このユースケースは、ITオペレーションのナレッジアシスタントのように、ユーザーがチャットインターフェースから作りたいスクリプトをエージェントに依頼するところから始まる。その入力内容は、様々な情報ソースにアクセスできるナレッジエージェントに渡り、要件抽出エージェント、ユーザーが求める出力結果と手持ち情報の整合性を検証するギャップ分析エージェントを経て、スクリプト生成エージェントに渡る。その出力結果はそのままユーザーに渡さずに、レビュー/検証エージェント、構文検証/セキュリティチェックエージェントのレビューを受ける。さらに、ユーザー自身のレビューも通過してから本番環境へのデプロイへと進む。また、バージョン管理/監査ログエージェントも存在し、継続的改善のプロセスも設計に取り入れられている。
この記事は参考になりましたか?
- 冨永裕子の「エンタープライズIT」アナリシス連載記事一覧
-
- エージェント型AIはITインフラ運用をどう変えるのか?ガートナーが“6つの活用ケース”で示...
- なぜ今日本企業は今、「Infrastructure as Code」(IaC)に舵を切るべ...
- 顧客マスタデータをクレンジング率「99.7%」で維持するNEC、AIエージェント活用も進む...
- この記事の著者
-
冨永 裕子(トミナガ ユウコ)
IT調査会社(ITR、IDC Japan)で、エンタープライズIT分野におけるソフトウエアの調査プロジェクトを担当する。その傍らITコンサルタントとして、ユーザー企業を対象としたITマネジメント領域を中心としたコンサルティングプロジェクトを経験。現在はフリーランスのITアナリスト兼ITコンサルタン...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア
