[システム障害対策をUpdateせよ！AIOpsが導くインシデント管理の進化形]

2025年11月14日(金)草間 一人（PagerDuty Product Evangelist）

自動化の前に立ちはだかる現実

　インシデント対応の自動化に着手する際、多くの企業が最新のAI技術や高度な自動化ツールの導入から始めようとする。しかし、実際の現場では、期待した効果が得られずに頓挫するケースが後を絶たない。

　なぜ、このような事態が起きるのか。その答えは、国内の先進企業の事例から明確に見えてくる。成功している企業に共通するのは、派手なテクノロジーの導入よりも、地道な「基礎固め」を先行している点だ。

　PagerDutyの調査によれば、日本企業の平均修復時間（MTTR）は6時間12分で、グローバル平均の約2倍だ。ダウンタイムによる損失は1分あたり約74万円、年間の重大インシデント累積コストは平均52億円に達している。この差を埋め、最短で成果を生む道は、基礎的な仕組みづくりにある。それではどう基礎固めをしていくべきか。3つのポイントを紹介していく。

国内事例から学ぶ、基礎固めの三本柱

1. 重大度の定義とSLOの確立

　PagerDutyのユーザーである鉄道事業者の事例を挙げる。同社では、インシデントの重大度を明確に定義し、それぞれのレベルに応じた対応フローを確立している。その結果、インシデント発生から担当者への自動架電までの時間が、最大約15分から約10秒へと大幅に短縮した。

　重大度の定義は企業によって異なるため、顧客への影響度、売上への影響、規制要件への抵触など、自社のビジネス特性に応じた基準を設定する必要がある。例えば、金融機関であれば、決済システムの停止は最重大（Sev-1）となるが、社内向けのレポートシステムであれば重大度は下がるだろう。

　このような「何を優先すべきか」という基準がなければ、AIや自動化ツールは適切な判断ができない。どんなに高度な技術も宝の持ち腐れとなってしまうわけだ。

2. 変更イベントの可視化と1次情報化

　多くのインシデントは、直前の変更作業と密接に関連している。コードのデプロイ、インフラの設定変更、機能フラグの切り替えなど、これらの情報をインシデント対応時に即座に参照できるかどうかが、問題解決のスピードを左右する。

　国内大手企業のIT子会社では、「Event Orchestration」を導入し、変更イベントと監視データを統合的に管理する体制を構築している。Event Orchestrationは、インシデント管理プラットフォーム「PagerDuty」の機能で、イベントに対するルールを設定しておくことで、プラットフォーム上でイベントを受け取った際にその処理を自動化することができる。

　これによって従来、人手で約10分かけていた情報の突き合わせと振り分け作業が即時に済むようになり、重複対応や対応漏れも防げるようになった。

　同社の取り組みの本質は、CI/CDパイプライン、構成管理データベース（CMDB）、デプロイメントツールなどから得られる変更情報を、監視データと同じレベルで扱える状態にしたことにある。これにより、「何が変わったから障害が起きたのか」という因果関係の特定が格段に速くなる。

3. ランブックの体系化と実行可能な形での整備

　クラウドに強みを持つ独立系Sierの事例を見ると、これまで属人的に実行されていた対応手順を体系的に整理している。例えば、「ディスク容量逼迫時の一時ファイル削除」「データベースコネクション枯渇時の強制切断」「キャッシュサーバーの再起動」など、頻出するパターンを標準化し、自動実行可能なランブックとして備えている。

　この取り組みにより、アラート対応の80％以上を自動化し、直近2年間で年間換算1,000人月もの工数削減を実現した。さらに、平均1次対応時間は664秒から165秒へと、約75％の短縮を図っている。

　重要なのは、これらのランブックが「常に実行可能な状態」で整備されている点だ。単なる手順書ではなく、パラメータを与えれば即座に実行できるスクリプトやAPIコールとして準備されていることで、AIが「何を実行すべきか」を判断し、自動化システムが「どう実行するか」を選択できるようになる。

●Next：自動化の段階的アプローチと、継続的な取り組みを定着させるために