AIによるシステム運用自動化とは？結論は「検知・特定・対処」を5手順で小さく置き換えること
AIによるシステム運用自動化とは、検知・特定・対処をAIへ小さく置き換える取り組みです。一度にすべてを任せるのではなく、5つの手順で1業務ずつ進めます。社内システムやサービスの運用・情シスを担当し、監視や障害対応の負担を減らしたい方と、その上長に向けて書きました。
私たち株式会社くるみは、自社メディアと支援先の運用を、結果を次へ戻す学習ループで回しています。この記事は、その型をシステム運用向けに翻訳し、何から手を付ければ止まらずに始められるかを手順としてまとめたものです。
運用自動化の全体像：5手順の流れ
AIによる運用自動化は、課題を決める、対象を選ぶ、データ整備、ツール選定、小さく回すの5手順で進めます。下の図が記事全体の流れです。
各手順の意味は次のとおりです。
- 課題を決める：一番困る事象から。解く課題を、現場が最も困っている事象一つに絞ります。
- 対象を選ぶ：多い×定型を先に。発生頻度が多く、手順が定型の業務を最初の対象にします。
- データ整備：ログ形式を揃える。AIが読めるように、ログとアラートの形式を先に揃えます。
- ツール選定：入場券と差を分ける。満たして当然の条件と、差が付く条件を分けて比べます。
- 小さく回す：結果を次へ戻す。自動対処の結果を記録し、次の週のルールへ反映します。
手順3〜4は並行して進めてかまいません。データを整えながら候補のツールで取り込みを試すと、形式の過不足に早く気付けます。
システム運用へのAI活用とは：業務全体の中での位置付け
システム運用へのAI活用は、単独の効率化施策というより、事業の実行を支える土台です。AIマーケティング全体の中でも、運用自動化は制作・配信を支える土台にあたります。配信の仕組みが止まれば、どれだけ良い制作物も届かないためです。詳しくはAIマーケティングの全体像
対象をシステム運用に限らず、業務全般のAI自動化から検討したい場合は、別の記事で進め方を整理しています。詳しくは業務全般のAI自動化の進め方
前提：従来のシステム運用が限界を迎えている理由と、AIが支援できる3領域
人手の運用が限界に近づき、AIは検知・特定・対処の3領域を担えるためです。クラウド化やシステムの分散化で構成が複雑になり、監視する対象も通知の量も増えました。人が見て、判断して、手で直す運用だけでは、追い付かない場面が出てきています。
従来運用が限界を迎える理由：アラート増加・属人化・人手不足
現場で起きている課題は、大きく3つに整理できます。
- アラート増加：監視対象が増え、通知の量が人の処理できる範囲を超える
- 属人化：原因の切り分けが、特定の担当者の経験と勘に依存する
- 人手不足：夜間や休日の対応を担える人が増えない
3つは互いに結び付いています。通知が増えるほど切り分けは経験者に集中し、その人が休めなくなります。スクリプトによる自動化は定型作業を減らしますが、どの通知が本命かという判断までは代わってくれません。
この方向は製品側でも進んでいます。日立はシステム運用管理「JP1」の製品ページで、AIエージェントによる運用の自律化と省力化を今後の姿として紹介しています（日立 JP1「AIが切り開く運用管理の未来」）。2026年10月時点の公開内容です。
AIOpsとは：生成AIとの役割の違い
AIOps（AIをIT運用に適用する取り組みの総称）は、機械学習で監視データを相関分析し、異常の検知と原因の絞り込みを支援します。相関分析とは、複数のアラートやログの関係を見て、同じ原因から出たものをまとめる処理です。
一方の生成AIは、文章を扱う作業を担います。手順書の作成、問い合わせ対応、ランブック（運用の作業手順書）の生成が代表的な使い道です。AIOpsが「何が起きているか」を絞り、生成AIが「どう直すか」を文章にする、という分担になります。
検知だけを高度化しても、十分ではありません。対処が手動のままでは、サービス復旧までの時間が短くならないケースがあるとIBMも解説しています（IBM「ここまで来たAIOps！」）。検知・特定・対処をひと続きで設計する理由はここにあります。
従来運用・ツール自動化・AI運用の違い：3領域の比較
違いは、異常の検知、原因の特定、対処の3段と、その後の学習に表れます。下の図は、従来運用、ツール自動化、AI運用を同じ4行で並べたものです。
各行の読み方は次のとおりです。
- 異常の検知：従来運用は人が目視、ツール自動化はしきい値（超えたら通知する基準値）、AI運用は相関で検知します。
- 原因の特定：経験と勘、ログ検索、候補を提示の順に、人が探す範囲が狭くなります。
- 対処：手順書を手作業、定型スクリプト、手順を生成の順に、準備の手間が減ります。
- 学習：従来運用は属人、ツール自動化はなし、AI運用は結果を蓄積します。
運用の属人化をAIで解消するうえでは、学習の行が効きます。担当者の頭の中にあった判断が、結果の蓄積として残るためです。なお、図は2026年10月時点の一般的な機能で整理したもので、対応範囲は製品ごとに異なります。
手順1〜2：運用課題を一つに絞り、最初に自動化する業務を「頻度×定型度」で選ぶ
最初に自動化するのは、発生頻度が多く手順が定型の業務です。その前に、解く運用課題を一つに絞ります。課題が複数あるまま進めると、対象も測る指標も決まらず、導入だけが先に進んでしまうためです。
手順1：運用課題は「夜間に最も困る事象」を基準に絞る
課題は、手段の名前ではなく事象で書きます。「監視ツールを入れ替える」「AIOps製品を導入する」は手段で、課題ではありません。カテゴリ（監視ツール名）で選ぶのではなく、現場が夜間に最も困っている事象から選びます。
事象で書くと、たとえば次のようになります。
- 夜間に同じ死活監視のアラートで何度も呼び出される
- 一つの障害で関連アラートが大量に届き、本命が埋もれる
- 同じ内容の問い合わせに、毎回手作業で回答している
死活監視とは、サーバーやサービスが動いているかを定期的に確かめる監視です。事象まで具体化すると、対象業務と効果の測り方が同時に決まります。システム運用の自動化の進め方として、ここを飛ばさないことが後の手戻りを減らします。
手順2：頻度×定型度で最初の対象を選ぶ基準
対象は、発生頻度と手順の定型度の2軸で選びます。下の図は2×2の整理で、多い×定型が右上、少ない×非定型が左下に入ります。
4つのセルの扱いは次のとおりです。
- 多い×定型：最初の対象。回数が多く手順が決まっているため、結果をすぐ確かめられます。
- 多い×非定型：次の候補。先に手順を定型化してから、自動化に回します。
- 少ない×定型：スクリプトや手順書で足ります。AIを使う優先度は低い領域です。
- 少ない×非定型：人が担当すると割り切ります。重大障害の判断などがここに入ります。
多い×定型を先にする理由は、結果が早く返ってくるためです。回数が多いほど、AIの判断が合っていたかを確かめる機会が増えます。右上から着手し、左下は人が担当すると割り切ると、対象の線引きで迷いません。
最初の対象業務の例：一次切り分け・アラート集約・一次回答
最初の対象になりやすい業務は、次の3つです。
- 死活監視の一次切り分け：再起動で戻るものと、人の調査が要るものを分ける
- 定型アラートの集約：同じ原因から出た通知を一つにまとめる
- 問い合わせの一次回答：手順書にある内容を、生成AIが下書きして返す
異常検知をAIで高度化したい、という要望から運用の見直しが始まることもあります。ただ、異常検知は正解のデータが貯まるまで評価が難しい領域です。AIOps導入の手順としては、上の3つのように結果をすぐ確かめられる業務を先に置くと進めやすくなります。
手順3〜4：ログとアラートのデータを整備し、自社開発かツール導入かを決める
データはログとアラートの形式を揃え、ツールは入場券と差が付く条件を分けて選びます。入場券とは、満たしていて当然の条件のことです。この2つの手順は互いに影響するため、並行して進めてかまいません。
手順3：運用データ整備で揃える項目
AIに渡す運用データの整備では、次の4項目を揃えます。
- 時刻の形式とタイムゾーン
- ホスト名やサービス名の表記
- 重要度の区分
- 対応結果の記録（誰が何をして、復旧したかどうか）
形式がばらばらのログは、相関を取れません。対応結果が残っていなければ、AIが学ぶ材料もありません。とくに4つ目は抜けやすく、手順5の学習ループで必ず使う項目です。
私たちは広告レポートの自動化でも、分析より先に取込形式を揃えるところから始めました。形式が揃っていないと、後段の集計や分析が成り立たないためです。運用データの整備も同じ発想で進められます。詳しくは広告レポート自動化の進め方
手順4：AIOpsツールの選び方は入場券と差が付く条件の比較で決める
AIOpsツールの選び方では、入場券と差が付く条件を混同しないようにします。既存監視と連携、ログ取込形式、セキュリティ基準の3つが入場券です。原因候補の提示、手順の自動生成、学習結果の反映の3つが、差が付く条件にあたります。
各項目で確かめる内容は次のとおりです。
- 既存監視と連携：今の監視ツールのアラートを、そのまま受け取れるか。
- ログ取込形式：手順3で揃えた形式を、変換なしで取り込めるか。
- セキュリティ基準：ログの保管場所や学習への利用範囲が、自社の基準に合うか。
- 原因候補の提示：関連するアラートをまとめ、原因の候補を示せるか。
- 手順の自動生成：生成AIが、ランブックの下書きを作れるか。
- 学習結果の反映：対応結果や誤検知の仕分けを、次の判断に反映できるか。
入場券を満たさない候補は、比較表に載せません。差が付く列だけで最終比較すると、機能一覧の丸の数に引きずられずに済みます。
生成AIによるランブック作成は、すでに製品機能として提供されています。PagerDutyは、生成AIでランブックを作成する機能「AI-generated Runbooks」を公式ブログで紹介しています（PagerDuty「生成AIランブックによるシステム運用効率化」）。機能の範囲は変わりうるため、2026年10月時点の公式情報で確かめてください。
自社開発とツール導入の違い：判断の基準
選択肢は、AI機能が組み込まれた運用ツールを導入する方法と、自社で生成AIを組み込んだ仕組みを作る方法の2つです。違いを表にまとめます。
| 観点 | ツール導入 | 自社開発 |
|---|---|---|
| 立ち上げ | 早く始められる | 設計と構築の期間が要る |
| 自社手順への合わせ込み | 製品の機能の範囲内 | 自由に設計できる |
| 保守 | 提供元が担う | 自社で担う |
| 向く場面 | 最初の1業務の検証 | 差が付く条件が固まった後 |
最初の1業務は、既存の監視ツールが持つAI機能か、導入しやすいツールから始めると検証が早く進みます。自社開発は、ツールでは満たせない条件がはっきりしてから検討しても遅くありません。
手順5：小さく回して結果を次へ戻す。私たちが運用で使っている学習ループ
定着と精度向上は、結果を毎週ルールへ戻す学習ループで進めます。導入した時点の設定は、あくまで仮のものです。結果を記録し、誤検知を仕分け、ルールを直して配備し直す流れを止めないことが、AIによる運用自動化を定着させる条件になります。
学習ループの5工程：自動対処から再配備までの流れ
学習ループは、自動対処、結果記録、誤検知の仕分け、ルール修正、再配備の5工程です。下の図のように、再配備の後は次の週の自動対処へ戻ります。
各工程の内容は次のとおりです。
- 自動対処：対象業務だけ。手順2で選んだ1業務に限って、自動で対処します。
- 結果記録：復旧と誤検知。復旧したか、誤検知だったかを毎回残します。
- 誤検知の仕分け：週1で人が確認。記録を人が見て、誤りの種類を分けます。
- ルール修正：しきい値と手順。仕分けの結果を、しきい値と手順に反映します。
- 再配備：次の週へ。修正したルールを配備し、次の週の自動対処に使います。
この型は、私たちがくるみバディの広告運用で学習ループとして使っているものを、システム運用向けに翻訳したものです。広告でも運用でも、AIの出力をそのまま使い続けるのではなく、結果を見て人がルールを直す工程を必ず挟んでいます。
AIOpsスモールスタートの基準：対象を広げる判断
AIOpsのスモールスタートでは、1業務でループが回ってから対象を広げます。広げてよいかは、次の3点で判断します。
- 誤検知の仕分けが、週1で途切れずに続いている
- ルール修正の理由が、記録として残っている
- 自動対処を止める方法を、担当者全員が知っている
3点が揃わないまま対象を増やすと、仕分けが追い付かなくなります。誤検知が放置され、現場がAIの通知を信用しなくなるのが、定着しない典型的な流れです。
インシデント対応の自動化でも変わらない手順
インシデント対応（障害や不具合への対応）の自動化でも、この5工程は変わりません。変わるのは、対象業務としきい値、そして人の承認を挟む範囲です。影響の大きい対処ほど、自動対処の前に人の判断を入れます。
同じループは、システム運用以外にも使えます。SNS運用の自動化については、別の記事で扱う予定です。マーケティング基盤の運用設計も同じ型で支援しています。
私たちは自社メディアと支援先の運用をこの5工程で回しています。
つまずき所：アラート過多・誤検知・生成AIのリスクで止まるパターンと避け方
止まりやすいのは、アラート過多、AIの判断の鵜呑み、生成AIのリスクの3か所です。私たちが複数の支援先で運用の自動化に関わる中で、よく見るパターンを整理しました。匿名の自社支援記録で第三者未検証の内容です。
どれも担当者の落ち度ではなく、導入の順番から起きやすい構造的なものです。AIOpsの失敗として語られる内容の多くは、先に分岐と集約を決めておけば避けられます。
注意点1：アラート過多は全件通知をやめて相関で集約する
AIを入れた直後は、通知がかえって増えることがあります。既存のしきい値による通知に、AIの検知が上乗せされるためです。下の図は、全件通知から相関で集約へ切り替える前後を示しています。
- 全件通知：検知したアラートをすべて担当者へ送る状態。本命の通知が埋もれます。
- 相関で集約：同じ原因のアラートを一つにまとめ、まとめた単位で通知する状態。
アラートの自動化をAIで進めるときは、通知を増やす機能より先に、まとめる機能を有効にします。担当者が受け取る通知の数が減って初めて、原因候補の提示が読まれるようになります。
注意点2：誤検知とAIの判断の鵜呑みを避ける分岐
AIが示す原因候補は、候補であって確定ではありません。精度が上がるほど確認を省きたくなりますが、承認が必要な対処は人の判断を挟む分岐を必ず残します。人の承認を挟む対処の例は次のとおりです。
- 本番データベースの再起動や切り替え
- 利用者に影響が出る設定変更
- 元に戻せない削除や上書き
再起動で戻る定型の対処は自動、影響が大きい対処は承認後に実行、と先に分けておきます。こうしておくと、誤検知が起きても影響が広がりません。
注意点3：生成AIの運用リスクとセキュリティ
生成AIを運用に使うときのリスクは、誤った手順の生成と、機密ログの外部送信の2つです。生成された手順は、自社の環境に合わないことがあります。ランブックとして登録する前に、人のレビューを通します。
ログには、個人情報や認証情報が含まれることがあります。外部のAIサービスへ送る前に該当箇所を伏せ、入力が学習に使われない設定と契約条件を確かめます。手順4のセキュリティ基準を入場券に置いたのは、この確認を後回しにしないためです。
AIの判断を鵜呑みにしない、という注意は広告運用でのAI活用にも共通します。こちらは別の記事で扱う予定です。
導入前チェックリストと効果の測り方：アラート件数ではなく「人が動いた回数」で見る
5項目のうち4つ以上が揃えば着手し、効果は人が動いた回数で確認します。着手の判断と効果の確認を同じ紙にまとめておくと、導入後に「何をもって成功とするか」で揉めません。
システム運用自動化のチェックリスト：5項目の判定基準
判定に使うのは、目的と対象、データの質、人の分担、止める手順、測る指標の5項目です。
各項目で確かめる内容は次のとおりです。
- 目的と対象：解く事象が一つに絞られ、最初の1業務が決まっているか。
- データの質：ログとアラートの形式が揃い、対応結果が記録されているか。
- 人の分担：誤検知を仕分ける人と、ルールを修正する人が決まっているか。
- 止める手順：自動対処を止めて手動に戻す方法が、文書になっているか。
- 測る指標：導入前の対応回数と復旧時間を、比べられる形で記録しているか。
4つ以上揃えば着手します。欠けている項目には、着手後の早い段階で埋める計画を添えます。欠けているのが止める手順の場合は、先にそれを埋めてから着手するほうが安全です。
効果測定の基準：管理画面の数字と実成果の違い
管理画面の数字と実際の成果は、一致しないことがあります。私たちが広告計測で、管理画面の数字と実際の予約・来院の記録を突き合わせた例があります。媒体の管理画面上のCV（コンバージョン。成果として数えた件数）200件に対し、予約は89件（44.5%）、実来院は75件でした。
画面上の数字だけを見ていれば、実態を見誤るところでした。運用でも同じことが起きます。AIが減らしたアラート件数ではなく、人が実際に対応した回数と、復旧までの時間で測ります。
AIOpsの効果測定KPI：見る指標と参考にとどめる指標の比較
AIOpsの効果測定で使うKPIは、主指標と参考の数字を分けて扱います。
| 指標 | 扱い | 理由 |
|---|---|---|
| 人が対応した回数 | 主指標 | 現場の負担を直接表す |
| 復旧までの時間（MTTR） | 主指標 | 利用者への影響を表す |
| 夜間・休日の呼び出し回数 | 補助指標 | 負担の偏りが分かる |
| AIが抑制したアラート件数 | 参考 | ツール側の数字で、負担の減少を保証しない |
| 自動対処の実行回数 | 参考 | 誤検知への対処も含まれる |
MTTRは平均復旧時間のことで、障害の発生から復旧までにかかる時間の平均を指します。MTTRの短縮をAIで狙う場合も、導入前の値を先に記録しておきます。比べる元がないと、短くなったかどうかを誰も判断できないためです。
AIによるシステム運用自動化のよくある質問
残りやすい疑問は、AIの要否、生成AIの用途、用語の違い、始め方、任せる範囲の5つです。
運用自動化にAIは必須ですか？しきい値監視との違いは
必須ではありません。手順が定型で件数が少ない業務は、しきい値監視とスクリプトで足ります。しきい値監視は個々の値を基準と比べますが、AIは複数のアラートやログの関係から異常や原因候補を絞ります。通知が多く、切り分けに時間がかかる現場ほど、AIを使う意味が出てきます。
生成AIはシステム運用の何に使えますか
文章を扱う作業に使えます。手順書やランブックの下書き、問い合わせへの一次回答、アラート内容の要約、障害報告書の作成が、生成AIのシステム運用での代表的な活用先です。生成された手順が自社の環境に合うとは限らないため、本番で使う前に人がレビューします。
AIOpsとMLOps・DevOpsの違いは
対象が違います。AIOpsはIT運用にAIを適用する取り組みで、監視や障害対応を対象にします。MLOpsは機械学習モデルの開発から運用までを継続して回す仕組み、DevOpsは開発と運用が連携してリリースを進める考え方です。AIOpsは運用の手段、残りの2つは開発と運用の進め方にあたります。
自社開発とツール導入はどちらから始めるべきですか
ツール導入から始めるほうが、検証は早く進みます。既存の監視ツールにAI機能があれば、まず最初の1業務で試します。自社開発は、ツールでは満たせない条件がはっきりしてから検討します。どちらを選んでも、ログ形式の整備と対応結果の記録は先に必要です。
インシデント対応の自動化はどこまでAIに任せてよいですか
元に戻せる定型の対処までが目安です。プロセスの再起動のように、手順が決まっていて影響が小さいものは自動にできます。本番データの変更や利用者に影響する切り替えは、AIが手順を提示し、人が承認してから実行する分岐を残します。
まとめ：検知・特定・対処を5手順で小さく置き換え、結果を次へ戻す
進め方は、検知・特定・対処を5手順で1業務ずつ置き換えることです。AIによるシステム運用自動化は、製品を入れた時点では完成しません。結果を次へ戻す流れが回り始めて、初めて現場の負担が減っていきます。
5手順の流れの再確認
課題を決める、対象を選ぶ、データ整備、ツール選定、小さく回すの順に進めます。冒頭の図をもう一度置きます。
一番困る事象から課題を決め、多い×定型を先に対象とします。ログ形式を揃え、入場券と差を分けてツールを選び、結果を次へ戻します。手順3〜4は並行して進めてかまいません。
次の一手の基準：最初の1業務を今週決める
次の一手は、最初の1業務を今週決めることです。夜間に最も困っている事象を一つ書き出し、発生頻度と手順の定型度を確かめれば、対象は決まります。導入前の対応回数と復旧時間も、同じタイミングで記録を始めます。
どの業務をAIに置き換えられるか迷う場合は、無料診断で整理する方法もあります。
