多くの企業が既存ITシステムの運用・保守に多大な労力を要し、経営戦略やビジネスに資するITの活用に手が回らないという課題を抱えています。NECはこの課題に対して、自社での実践で得た知見やこれまでのお客様への構築で蓄積した知見に基づくBluStellar Scenario「ハイブリッドIT環境の運用DXによる業務プロセスの改善」を提供しています。本稿では、その一部としてインシデント管理高度化サービスと、ITシステム運用の省力化・自動化を目指すNECの取り組みである自律運用AIエージェントの研究開発を紹介します。

1. はじめに

多くの企業のITシステム部門では、継ぎ足しの既存システム資産の運用・保守に人員を割かれており、新規領域への投資が不十分な状況です。少子化による採用難も重なり、システム運用負荷の低減には運用の標準化・自動化の推進が重要視されています。

NECではこの課題に対し、自社の実践例で得た知見やこれまでのお客様への構築で培ってきた業種ノウハウを還元していくという考え方で「BluStellar Scenario （ハイブリッドIT環境の運用DXによる業務プロセスの改善）」を提供し、お客様を「変化に強い企業」へ導く運用DXを実現します。

2. 運用DXの紹介

2.1 BluStellar Scenarioによる運用DXの全体像

NECでは、運用DXのBluStellar Scenario において、目的・ニーズ別に「運用標準化・自動化」「資産管理・脆弱性管理自動化」「インシデント管理高度化」「可視化」の4つのサブシナリオを用意しています。

「運用標準化・自動化」は、ITIL（Information Technology Infrastructure Library）準拠のガイドラインやプロセス整備によって属人化を解消し、省人化を実現します。「資産管理・脆弱性管理自動化」では、多数のシステム、サーバなどの脆弱性検知を自動化し、管理レベルの向上に貢献します。「インシデント管理高度化」は、監視、判断、通報、問題管理、分析を自動化し、AI活用によって高度化することで、自律的な運用改善・効率化サイクルを実現します。「可視化」では、ダッシュボードによる可視化により現場と同時に状態を確認し、ユーザーへの迅速な共有が可能になります。

2.2 インシデント管理高度化

第2章2節では、運用DXサブシナリオのうち、インシデント管理高度化について詳細を紹介します。

インシデント管理高度化では、監視、判断、通報、問題管理、分析を自動化し、AI活用によって高度化することで、自律的な運用改善・効率化サイクルを実現します。統合されたプラットフォームでシステム監視やモニタリングを行い、インシデント対応を一元化します。大量の監視メッセージアラートに対しては、フィルタリング定義による高度な判断で不要なアラートを削減します。インシデント情報の一元化とチケット自動起票により関係者との迅速な連携を実現し、既存システムへの影響を抑えながら、小さく素早い改善ができる仕組みを提供します。

インシデント管理高度化に向けた代表的なサービスを2つ紹介します。1つはWebSAM Automatic Message Call（AMC）で、大量のシステムアラートのなかから必要な情報だけを確実に担当者へ自動で知らせる、監視業務の改革を実現するクラウド型通報サービスです。もう1つはWebSAM IT Process Management（ITPM）で、システム利用における問い合わせやインシデント発生時の効率的な対応・管理を実現するSaaS型のITサービスマネジメントツールです。

AMCとITPMの連携により、アラートの切り分け・連絡・チケット起票を自動化し、効率的なシステム運用が可能になります（図1）。

2.3 ITPMにおけるAI活用

ITPMにおける生成AIの活用として、次の機能を提供しています。

今後は、更なるAI活用による自動化として、次の強化に取り組む予定です。

3. 自律運用AIエージェントの研究

生成AIの活用から始まっている運用業務効率化は、今後人とAIエージェントの協働を経て、自律運用の実現に至ると考えられます。更なる運用の省人化に向けて、NECでは問い合わせ対応や障害調査を自律的に行うAgentic AIの研究開発を行っています。

3.1 問い合わせ対応自動化エージェント

問い合わせ対応自動化に活用できるAIの1つとしてChatGPTをはじめとする大規模言語モデル（Large Language Model、以下、LLM）によるチャットボットが挙げられます。LLMによるチャットボットは文脈を踏まえた自然な応答が可能ですが、特定の製品やサービスなど学習していない知識を必要とする質問には正しく答えられません。これを克服する技術の1つとして、RAG（Retrieval Augmented Generation、検索拡張生成）が挙げられます。問い合わせ対応自動化のためにRAGを有効に活用する方法として、ユーザーの問い合わせに類似した過去の問い合わせ応答事例を検索し、補足情報として活用する方法が考えられます。類似した過去の問い合わせ応答事例に、ユーザーからの問い合わせに対する回答が含まれる場合、LLMによって適切な回答が生成できることが期待できます。

しかし、実際の問い合わせ対応業務では、類似した過去の問い合わせ応答事例だけでなく、製品やサービスに関するマニュアルなどの文書も参照しなければならない場合があります。そこでNECは、それらの情報も必要に応じて活用できる、問い合わせ対応自動化のための情報統合AIエージェントを開発しました。

図2は、開発した問い合わせ対応自動化エージェントの構成図です。ハルシネーション防止の観点で、余計な外部情報の検索を自律的に抑えるため、Agentic AIに基づくRAG（Agentic RAG）を活用しています。

まず、ユーザーの問い合わせ文は類似チケット検索エージェント（Agent1）に入力されます。Agent1は、問い合わせ文から関連するインシデントチケットを取得し、その情報をプロンプト（指示文）に追記して、回答可否判断エージェント（Agent2）に渡します。

Agent2は、プロンプトに記載された関連チケットの情報に基づいて、ユーザーの問い合わせに回答するのに十分な情報が手元にあるかどうかを判断します。

十分な情報がない場合（Agent2の判断が「要」の場合）、関連文書検索エージェント（Agent3）が、問い合わせ文に関連するFAQやヘルプページ、マニュアルなどの関連文書を関連文書データベースから取得し、その情報をLLMプロンプトに追記します。

LLMは、最終的なプロンプトとユーザーの問い合わせ文に基づいて回答を生成し、ユーザーに応答文を返します。

NECでのサービスのサポート業務で実際にやり取りされた問い合わせ及びその回答を用いて、問い合わせ対応自動化エージェントの評価を2025年9月時点で実施しています。具体的には、インシデントチケットに記録されている、ユーザーからの最初の問い合わせ文を入力として、問い合わせ対応自動化エージェントが出力した回答と実際にチケットに記載されていた回答文とを比較しました。その結果、問い合わせに不足情報がなく回答に調査などの実務を必要としないケースにおいて、過去のインシデントチケットに類似の質問及びその応答例があり、回答に必要な情報が外部文書に含まれている場合には、人手と遜色ない応答文を生成できていることを、2025年9月時点で確認しています。

3.2 障害調査エージェント

障害の発生したITシステムを復旧させるためには、その原因を特定することが必要です。この調査に掛かる時間を短縮することで、迅速にITシステムを復旧できるようになります。ここで特定すべき原因は必ずしも真因である必要はありませんが、少なくとも業務やサービスへの影響を最小化することを最優先とした暫定的な対処に直結するものでなければなりません。例えば、コンテナが頻繁に再起動を繰り返していることが障害を引き起こしていた場合、この再起動自体も障害の原因ですが、復旧のためには、この再起動を引き起こしている原因を特定する必要があります。

NECは、このような障害原因の特定を自律的に行う、障害調査エージェントを開発しました。このAgentic AIは生成AIとログ分析技術を組み合わせることで、監視アラームやユーザーからの障害申告を起点に、ITシステムを構成するコンポーネントからのログやリソース消費状況を調査し、その原因を特定します。この原因調査は、「調査範囲の絞り込み」と「障害原因の仮説生成と検証」の2段階で実施されます。まず、調査範囲の絞り込みステップでは、監視アラームや障害申告の内容、調査対象となるITシステムの構成情報、ログ分析技術による影響分析の結果から、調査対象を絞り込みます。次に、障害原因の仮説生成と検証ステップでは、調査対象とその絞り込みに利用した情報から障害原因を推定し、その調査方法を決定します。そして、この調査方法を実行して得られた追加情報に基づき、推定した障害原因が正しいかどうかを検証します。この一連の調査を生成AIが振り返りを行った結果を反映させ、障害原因の仮説生成と検証を繰り返すことで、最終的な原因を特定します。

本技術は3つの特徴があります。

1つ目は、並列調査により調査時間を短縮できることです。1つのアラームや障害申告から複数の障害原因が考えられる場合、障害原因の仮説を一度に複数生成し、それぞれの仮説を独立したエージェントが調査します。

2つ目は、より根本的な原因の特定を自律的に遂行できることです。複数のエージェントが実施した調査結果を振り返り、当初設定した仮説が間違っていればそれを修正、より根本的な原因が考えられる場合は、その原因を仮説として設定し再度調査を実施します（図3）。

3つ目は、独自ログ分析技術^1）2）の活用により調査を効率化できる点です。ITシステムで生成されるログは膨大な量になるため、それを一度に生成AIに与えることができません。そのため、これまでに開発したログ分析技術を用いてログデータを要約し、その結果を利用することで、エージェントが効率的に調査を進められるようにしています。

本技術の効果を確認するため、模擬環境やNECのITシステムで発生した障害に適用し、検証を行いました。その結果、Noisy Neighbor、誤設定、ブロードキャストストームによる障害などの障害原因を示唆する情報をログから適切に抽出し、それらを関連付けて原因を特定できる事例を2025年9月時点で確認しています。

4. むすび

マイクロサービスやハイブリッドクラウドなどの採用が進むことで、IT運用はますます煩雑化しています。その一方で、ITシステムの運用を担う人材の確保が困難になっていることから、IT運用の省力化が多くの企業で重要な経営課題になっています。本稿では、運用DXにおけるインシデント管理高度化シナリオでのサービスへの生成AI活用と、自律運用AIエージェントに関する研究開発の取り組みについて説明しました。今後は、更なる運用の省力化を実現するために、運用者支援機能の強化とAgentic AIによる自律対処・修復の実現に向けて取り組んでまいります。

商標

参考文献

執筆者プロフィール

関連URL