システムのアラートが届いたとき、担当者は原因を調べるだけではありません。どの対処を選ぶか、今実行してよいか、業務が戻ったと判断できるかまで確認します。AIによる運用支援を考えるなら、この一連の判断をどこまで任せるかが重要です。
NTTデータ先端技術は2026年10月29日、統合運用管理ソフトウェア「Hinemos」で、AIエージェントを使った障害対応などの実証実験を進めていると発表しました。発表を手がかりに、導入前に整理しておきたい運用の境界を考えます。
今回は実証実験。一般的な短縮効果ではない
同社によると、実証期間は2026年10月1日から12月31日までの予定です。障害の分析から対処・復旧確認・報告までの自律化に加え、ジョブ異常の影響・原因調査と、アラートの抑制・集約ルール作成を検証しています。
注目したいのは、人の判断をなくす設計ではない点です。発表では対処をルールに基づいて選び、影響の大きい操作には実行前の人による承認を設けると説明しています。
同社は、社内開発環境の特定のユースケースで、人手による従来の復旧作業と比べて復旧時間を83％短縮したとしています。ただし、これは条件を限定した企業発表です。あらゆる障害や本番環境で同じ効果が得られることを示すものではありません。サービス化は2027年度上期をめどに推進する方針で、今回の発表を一般提供開始と読み替えないよう注意が必要です。
出典：NTTデータ先端技術の公式発表／PR TIMES掲載原文
「調べる」と「変更する」を分ける
ここからは、発表を踏まえたXEROTTAの運用上の考察です。以下は製品の機能保証や検証結果ではありません。
最初に分けたいのは、情報を読む作業と、システムの状態を変える作業です。ログの要約や原因候補の整理と、サービスの再起動や設定変更では、誤ったときの影響が違います。
例えば、検証環境の状態確認は自動化しても、本番環境の再起動は担当者の承認を必要とする、といった線引きが考えられます。操作名だけでなく、対象の環境、実行可能な時間帯、他サービスへの影響まで含めて条件を書き出すことが大切です。
AIの説明がもっともらしいことと、その操作を実行してよいことは別です。分析結果をそのまま実行権限につなげず、許可した範囲だけを扱う設計を出発点にします。
承認者が判断できる情報をそろえる
承認ボタンを置くだけでは、確認する人の負担が増えることもあります。「再起動してよいですか」という依頼だけでなく、少なくとも次の情報を一緒に示す運用が考えられます。
- どの環境の、どの機器・サービスを操作するのか
- 原因候補と、その判断に使ったログや監視情報
- 具体的な操作内容と、想定する業務影響
- うまくいかなかった場合の停止条件と戻し方
- 操作後に確認する項目と、確認する担当者
夜間や休日に誰が承認するか、連絡がつかない場合にどこで止めるかも決めておきます。承認待ちを自動的な許可として扱わないことが重要です。
「処理成功」と「業務復旧」を同じにしない
操作がエラーなく終わっても、利用者が業務を再開できるとは限りません。プロセスが起動しているだけでなく、必要な画面が開くか、処理結果が正しいか、後続ジョブが正常に動くかなど、対象業務に合った確認が必要です。
また、同じ操作を繰り返しても直らない場合に、再試行を続けるのか、人へ引き継ぐのかを事前に決めます。実行内容、承認者、時刻、確認結果を残せば、後から改善点をたどりやすくなります。
AIが作るアラート抑制ルールについても、通知が減ったことだけを成功とせず、重要な異常を見逃していないかを別に確認したいところです。
小さな範囲で、確認の負担まで測る
試行するなら、影響を把握でき、手順と戻し方が明確な対象から始める方法が考えられます。速さだけでなく、誤った提案の件数、承認にかかった時間、人への引き継ぎ、再発の有無も記録します。
短縮率だけでは、自社の担当者が楽になったのか、別の確認作業が増えたのかは分かりません。自社の障害パターンと体制で、どこを自動化すると改善につながるかを判断する材料を集めることが先です。
まとめ
障害対応のAI活用は、すべてを無人化するか、人だけで続けるかの二択ではありません。調査、提案、承認、実行、復旧確認を分け、任せられる部分から進める考え方があります。
Hinemosの今回の発表も実証段階の取り組みです。数字への期待だけで導入を判断せず、「どの操作を誰が許可し、何をもって復旧とするか」を整えることが、運用を見直す具体的な一歩になります。
※本稿は公開発表を基にした解説です。XEROTTAによる製品の実機検証や、発表企業との提携・取引関係を示すものではありません。
※アイキャッチはAI生成のイメージです。実在企業の施設・従業員・製品画面ではありません。
