インシデントコマンダーはAIに渡せるか｜障害対応で人が握る指揮

「障害対応にAIエージェントを入れたら、指揮もAIに任せられるのでは」「AIが原因の候補を出してくれるようになったのに、障害の夜の混乱は減っていない」。情シスやシステム運用の責任者から、ここ半年で増えた声です。どちらも、AIが入れば障害対応の役割がまとめて軽くなるという期待から出ています。けれども、AIが入って変わるのは調査の速さであって、誰が止めるか、誰が知らせるか、誰が実行を許すかを決める役は消えません。本当は、所見が増えるぶん、指揮役の仕事はむしろ重くなります。この記事では、障害対応の役割を指揮・調査・記録・連絡の4つに分け、それぞれをAIエージェントに渡すか、渡さないか、条件付きで渡すかを比べたうえで、所見の採否、権限の決め方、指揮役の交代、体制表への書き方を整理します。

インシデントコマンダーとは：障害の間だけ置く、全体を見る役

インシデントコマンダーは、システム障害が起きている間だけ置かれる指揮役の呼び名です。自分では手を動かさず、誰に何を調べさせるか、いつ止めるか、いつ外へ知らせるかを決め、状況を一つにまとめて持ち続けます。グーグルが公開している運用の本では、障害対応を指揮・作業・連絡・計画に分け、障害中にシステムを変えてよいのは作業の担当だけとし、指揮役はその全体を組み立てる役として書かれています。用語の説明はここまでにします。

情シスや運用の責任者にとって大事なのは、呼び名の由来よりも、自社の体制表のどこに指揮役を置き、そこへAIエージェントがどう加わるかです。多くの企業では、障害が起きると詳しい担当者がそのまま調べ始め、気づけば調べる人と決める人と報告する人が同じ一人になっています。指揮役という役を名前で置くこと自体が、最初の手当てになります。

この記事で扱うのは、社内のシステムや提供しているサービスに起きる一般の障害です。AIそのものが誤った出力をした事故や、使っているAIの提供元が止まった場合の備えは扱いません。AIは、対応する側に加わる一員として登場します。

2026年、障害対応の現場にAIエージェントが入ってきた

2026年3月31日、AWSは障害の調査を担うAIエージェント（AWSデブオプスエージェント）の一般提供を公式ブログで発表しました。警報が届いた時点から調査を始め、運用チームと並んで検知から調査、復旧、予防まで働くと説明しています。深刻度の見積もりと重複した起票のまとめを受け持つ部分があり、対処の計画の一部としてコードの修正案を示し、所見を担当の技術者に渡す流れです。プレビューの利用者からは、復旧までの平均時間が最大75%短くなったなどの報告があったとしていますが、これは提供元が紹介した利用者の報告で、自社で同じ数字が出るとは限りません。

国内では、NTTドコモが2026年2月25日、モバイルネットワークの保守業務向けAIエージェントの商用利用を2月4日に始めたと発表しました。基地局からコアネットワークまでの100万台以上の装置のデータを複数のAIエージェントで横断して分析し、異常を検知し、被疑箇所を特定し、対処案を保守担当者に提示する仕組みです。これまでは、対処方法がはっきりしない複雑な故障では、複数の保守担当者が連携してデータを集め、要因を特定していました。発表では、対応時間を50%以上削減するとしています。発表の範囲は、対処案を保守担当者に提示するところまでです。

二つの発表に共通しているのは、AIが受け持つのが調べて候補を出すところまでで、その先を受け取る人がいる前提で書かれている点です。ドコモは担当部長のコメントで、故障対処の自動化をさらに進める方向も示しています。AIが受け持つ範囲は今後も広がる見込みが高いからこそ、どこまでを渡すかの線を自社で先に引いておく必要があります。

速くなるのは調査で、指揮の仕事は減らない

AIエージェントが入ると、障害の最初の数十分で手に入る情報の量が変わります。人が手分けして記録を開き、変更の履歴をさかのぼっていた作業が、候補の一覧として先に届くようになります。ここまでは確かに速くなります。

ところが、届いた候補はそれだけでは判断になりません。原因の候補が三つ出たとき、どれから確かめるか、確かめている間に利用者への影響を止めるか、取引先に一報を入れるかは、候補とは別に決める必要があります。候補が早く多く届くほど、決める場面も早く多く来るので、指揮役が受け止める量はかえって増えます。AIの所見が当たっているかどうかを確かめる手間も、新しく加わります。

「AIが入ったのに混乱が減らない」という声の多くは、この増えた判断を受け止める人が決まっていないことから来ています。調査が速くなったことで、指揮役が不在のまま現場が走り出す時間も早くなるからです。AIの導入は、指揮役を置かなくてよくなる理由にはならず、指揮役を置かずにいられなくなる理由になります。

4つの役割で比べる：AIに渡す範囲と、人が握る判断

ここからは、障害対応の役割を指揮・調査・記録・連絡の4つに分けて、それぞれをAIエージェントにどこまで渡すかを比べます。先に挙げた運用の本の4区分のうち、計画の役は小さな組織では記録と兼ねることが多いため、この記事では記録にまとめました。

役割	AIエージェントに渡す範囲	人が握る判断	本稿の結論
指揮	状況の要約を受け取るだけ。指揮そのものは渡さない	止める・切り替える・利用者や取引先へ知らせる・本番で対処を実行する許可、指揮役の交代	渡さない
調査	記録と変更履歴の突き合わせ、原因の候補、対処案、根拠の提示	どの候補から確かめるか、所見を採るか捨てるか	渡す（候補として）
記録	時刻つきの経過の下書き、発言とやり取りの整理	決定とその理由、採らなかった所見の理由	条件付きで渡す
連絡	利用者・社内・取引先向けの文面の下書き、更新の時刻の通知	送るかどうか、宛先、言ってよい範囲	条件付きで渡す

表の右端だけを見ると、AIに渡せる役は一つしかないように見えます。けれども、記録と連絡の下書きをAIに任せられるだけで、人の手は大きく空きます。渡さないと決めた指揮役こそ、AIが空けた手で全体を見られるようになる、という関係で読むのが実態に近いはずです。次の節から、役割ごとに線の引き方を見ていきます。

指揮役は渡さない：止める・知らせる・実行を許すのは人

指揮役が持つ判断は、どれも取り消しがききにくいものです。サービスを止める、予備の系統へ切り替える、利用者や取引先に障害を知らせる、本番環境で対処を実行させる。どれも、間違えたときの影響が技術の外、つまり顧客や取引や信用に及びます。このため、指揮役の席にAIエージェントを座らせない、というのがこの記事の結論です。

運用にAIを組み込むとき人が握り続ける決定については、通知の束ね方や自動で直す作業の線引きとあわせて、運用の自動化を扱った別の記事で整理しました。ここでは同じ項目を並べ直さず、役割の置き方に絞ります。ポイントは、決定を人に残すだけでなく、決定を下す人を一人に名指ししておくことです。「人が判断する」と書いただけの体制では、障害の夜に誰も決めないまま時間が過ぎます。

AIエージェントから指揮役に上がってくるものは、状況の要約と、決定を求める問いの形に整えてもらうと扱いやすくなります。たとえば「影響は決済画面に限られる見込み。切り替えるか、調査を続けるかの判断が必要」のような形です。AIには問いを立てさせ、答えは指揮役が出す。この分担を、障害が起きる前の訓練で一度は通しておきます。

調査役は渡す：ただし結論ではなく候補として受け取る

調査は、AIエージェントにもっとも渡しやすい役です。警報、記録、変更の履歴、過去の障害の記録を突き合わせ、原因の候補と対処案を並べる作業は、人が手分けするより速く、抜けも出にくくなります。AWSの発表もドコモの発表も、AIの役目の中心をここに置いています。

渡すときの条件は二つです。一つは、候補ごとに根拠を必ず添えさせること。どの記録のどの時刻の値から、その候補を出したのかが書かれていなければ、人は当たっているかを確かめられません。もう一つは、候補に確からしさの順位を付けさせても、その順位で確かめる順番を決めないことです。影響の大きい候補や、確かめるのが速い候補を先に見るほうがよい場面があり、その順番は指揮役と作業の担当が決めます。

調査の入り口にも線があります。AWSの製品には、深刻度を見積もり、重複した起票を本筋の調査に結び付ける部分があります。こうした見積もりは役に立ちますが、障害として宣言し、指揮役を立てるかどうかは人が決めます。運用の本は、ほかのチームの助けが要る、利用者から見える、1時間集中して調べても解けない、のどれかに当てはまれば障害として宣言するよう勧めています。AIの深刻度は、この判断に使う材料の一つです。

調査をAIに渡すと、人の作業の担当が不要になるわけではありません。対処を実際に行うのは、障害中にシステムを変えてよいと決められた人です。AIの対処案は、その人が実行する前に読む材料の一つとして扱います。

記録役は条件付き：時刻と経過はAI、決定の理由は人

障害対応の記録は、後から振り返るためだけでなく、対応中に状況をそろえるための道具です。運用の本でも、指揮役は状況を書き続ける文書を持つべきだとしています。チャットのやり取りや会議の発言から、時刻つきの経過を下書きする作業は、AIに任せると人の手が大きく空く部分です。

ただし、記録の中には人が書くべき行があります。何を決めたか、なぜそう決めたか、どの所見を採らなかったかの3つです。AIに下書きさせた経過から、この3つが自然に出てくることはありません。決定の理由は決めた本人の頭の中にしかないからです。記録の担当は、AIの下書きを見ながら、決定の行だけは指揮役に確かめて書き足します。

記録の置き場所は一つに決めます。AIの下書きがチャットに流れ、人の決定は別の文書に書かれ、連絡の文面はまた別の場所にある、という状態では、交代した指揮役が状況を追えません。AIが書いた行と人が書いた行を、同じ記録の中で見分けられるようにしておくと、後から読む人が、どこが下書きでどこが決定かを迷わずに済みます。

事後に出す報告書の項目や書き方は、障害の後の報告書を扱った別の記事に譲ります。対応中の記録で押さえたいのは、報告書を書く日に「AIがそう言ったので」としか書けない状態を作らないことです。

連絡役は条件付き：文面は下書きまで、送る判断は人

障害中の連絡は、社内の関係者、利用者、取引先と相手ごとに中身が変わります。AIエージェントに状況の要約から相手別の文面を下書きさせると、連絡の担当は書く時間を減らし、確かめる時間に回せます。次の更新の時刻を知らせる、といった定型の通知も任せやすい部分です。

一方で、送るかどうか、誰に送るか、どこまで言うかは人が決めます。原因が確定していない段階で原因らしき内容を書いてしまう、影響範囲を実際より狭く書いてしまう、といった誤りは、AIの文面でも人の文面でも起こります。外へ出る文面は、連絡の担当が読み、指揮役が送る許可を出してから送る流れにしておきます。

更新の間隔も、指揮役が決めて連絡の担当に伝えます。原因が分からないうちは短い間隔で「調査中」と知らせ、見通しが立ったら間隔を延ばす、といった切り替えは、影響の大きさと相手を見て決めることです。AIに任せられるのは、決めた間隔が来たことを知らせ、前回の文面との差分を下書きするところまでです。

社内の連絡網や夜間の当番の順番そのものは、夜の当番体制を扱った別の記事で整理しています。ここで決めておきたいのは、AIが下書きした文面を誰が読み、誰の許可で送るか、という役の名前だけです。

AIの所見を採るか捨てるか：採否の理由を記録に残す

AIエージェントの所見は、当たることもあれば外れることもあります。ある時点では筋が通って見えた候補が、確かめると外れていたという場面は必ず来ます。大事なのは、所見を採ったか捨てたかを、その理由とともに記録に残すことです。

この記録は、二つの場面で効きます。一つは障害の後の振り返りで、「AIがそう言った」を原因にしないために使います。採ったのは指揮役であり、その判断の材料が何だったかが残っていれば、次に直すべき場所が見えます。もう一つは、AIエージェントをどこまで信用してよいかを測る材料としてです。採った所見のうち当たった割合、捨てた所見のうち実は当たっていた割合を数えておけば、渡す範囲を広げるか狭めるかを、印象ではなく記録で決められます。

指揮役とAIの所見の読み手を兼ねない

AIエージェントを入れた体制で起きやすい失敗が、指揮役がAIの画面に張り付いてしまうことです。所見が次々に届くと、つい自分で読み込み、根拠を確かめ、追加の調査を指示し始めます。そうしている間、利用者への影響や連絡の時刻を見ている人がいなくなります。

これを防ぐには、体制表に「AIエージェントの所見を読む係」を人の役として1行置くのが確実です。この係は、所見を読み、根拠を確かめ、指揮役が判断に使える形に絞って渡します。指揮役は、その係から受け取った要点と、ほかの担当からの報告を並べて決めます。調査役の人がこの係を兼ねるのはかまいませんが、指揮役が兼ねることは避けます。

• 指揮役が所見の画面を自分で読み、根拠の確認や追加の調査の指示まで始めてしまう
• 所見を読む係を決めず、届いた所見を全員が同時に読んで別々に動き出す
• AIの順位が高い候補から、影響や確かめる時間を考えずに順番に潰していく
• 所見を採った理由を書かず、後から誰が何を根拠に決めたか分からなくなる

小さな組織で人が足りない場合は、指揮役と連絡の担当を兼ねるほうが、所見の読み手と兼ねるよりも害が小さくて済みます。連絡は指揮役が全体を見ていないとできない仕事なので、兼ねても視野が狭くなりにくいからです。

AIエージェントの権限は障害の前に決め、障害中に広げない

AIエージェントにどこまでの操作を許すかは、障害対応の体制を決めるときに一緒に決めておきます。記録と設定を読むだけか、調査のための命令を流せるか、対処として設定を変えたり以前の版へ戻したりできるか。段階ごとに、許す範囲と、許すときに誰の承認を挟むかを書きます。

ここで守りたいのが、障害の最中に権限を広げる判断をしないことです。復旧を急ぐ場面では「読み取りしかできないから遅い。実行まで許してしまおう」という声が出がちです。しかし、普段は試していない権限で、普段は試していない操作をさせることは、障害の上に別の事故を重ねる危険をはらみます。権限を広げるのは、障害が収まった後に、記録を見ながら決めます。

権限の決め方は、AIエージェントの提供元の仕組みによって細かく変わります。自社で使う製品の公式の説明で、どの操作が既定で許されているかを確かめてから体制表に書きます。分からない操作は、許されているものとして扱っておくほうが安全です。

権限と並んで決めておきたいのが、どの警報でAIに自動で調査を始めさせるかです。AWSの製品は、エージェントが作業した時間に応じた秒単位の課金だと説明しています。すべての警報で自動の調査を走らせると、費用だけでなく、指揮役のもとに届く所見の量も増えます。自動で調査させる警報の範囲は、所見を読む係が受け止められる量から逆算して決めるのが現実的です。

指揮役の交代と引き継ぎ：AIの要約を渡しても、宣言は人がする

障害が長引くと、指揮役の交代が必要になります。夜通し続く対応で同じ人が指揮を取り続けると、判断の質が落ちるからです。運用の本では、指揮の引き継ぎは明示的に行い、引き継ぐ側が了承したことを確かめるまで、前の指揮役は抜けないとしています。

AIエージェントがいる体制では、引き継ぎの材料をAIに作らせることができます。これまでの経過、採った所見と捨てた所見、未決の判断、次の更新の時刻を1枚にまとめさせれば、口頭の引き継ぎがずっと短くなります。ただし、交代するかどうか、誰に交代するかは人が決め、交代したことは人が言葉で宣言します。資料が渡っただけでは、誰が今の指揮役なのかが現場に伝わりません。

AIが作った引き継ぎの1枚は、そのまま渡さず、前の指揮役が目を通してから渡します。要約の過程で、未決の判断が決まったことのように書かれたり、捨てた所見が採った所見の側に入ったりすることがあるからです。引き継ぐ側は、未決の判断の一覧だけは前の指揮役の口から聞くと決めておくと、取り違えを防げます。

交代の目安も先に決めておきます。対応が一定の時間を超えたら交代を検討する、影響が社外に広がったら上位の責任者に指揮を移す、といった条件です。条件を満たしたかどうかの判断は人がしますが、経過時間を知らせる役はAIに任せてかまいません。

体制表への書き方：AIエージェントを1行として載せる

IPA産業サイバーセキュリティセンターの中核人材育成プログラムの受講者がまとめた「生成AIおよびAIエージェントを安全に活用するための手引書」（2026年7月）は、AIシステムの運用開始後の管理体制、責任分界点、意思決定者を明確にしておく必要があるとし、インシデント発生時には代替運転やサービス停止、封じ込め、対外公表などの判断が必要になると書いています。体制の検討結果は、連絡網や権限一覧、インシデント対応手順などとして整理するよう求めています。

障害対応に入れたAIエージェントは、それ自体がこの手引書の言うAIシステムでもあります。AIエージェントを道具の欄ではなく、役割の欄に1行として載せると、何をしてよく何をしてはいけないかが体制表の上で読めるようになります。書き方の一例が次の表です。

体制表の行	担当	持つ判断・してよいこと	してはいけないこと
指揮役	当番の責任者（交代要員を併記）	止める・切り替える・外へ知らせる・実行の許可、交代の宣言	所見の画面を自分で読み込む
所見を読む係	調査の担当者	所見の根拠を確かめ、指揮役に要点を渡す	所見をそのまま決定として伝える
作業の担当	対象システムの担当者	指揮役の許可を受けた対処の実行	許可のない本番の変更
記録・連絡の担当	運用の担当者	経過の記録、文面の確認、決定の理由の書き足し	許可前の社外への送信
AIエージェント	製品名と版を記入	読み取り、原因の候補と根拠、対処案、経過と文面の下書き	許可のない設定の変更、権限の自己拡大

表の最後の行の「してよいこと」は、前の節で決めた権限の段階と一致させます。製品の版が変わったときは、この行を見直す日を決めておくと、知らないうちに権限が広がっていた、という状態を防げます。

入れる前に、過去の障害で通して確かめる

先の手引書は、運用前の準備として、関係者が定められた手順に従い、異常の検知、判断、連絡、封じ込め、復旧、再発防止までの一連の対応を実行できるかを確かめるよう求めています。AIエージェントを入れた体制も、本番の障害の前に一度通しておくべきです。

確かめ方として現実的なのは、最近の障害を一つ選び、AIエージェントにもう一度調査させて、当時の人の調査と比べるやり方です。AWSも始め方として、過去30日の本番障害を選んで再調査させ、結果を比べる手順を挙げています。比べるときは速さだけでなく、所見を読む係が根拠を確かめられたか、指揮役のところに決定の問いが届いたかまで見ます。

比べた結果は、そのまま渡す範囲を決める材料になります。過去の障害で、AIの候補の上位に当時の本当の原因が入っていたか、対処案が当時の人の対処と食い違ったときにどちらが妥当だったかを、所見を読む係と指揮役が一緒に見ます。1件だけで決めず、性質の違う障害を2件か3件選ぶと、AIが得意な障害と苦手な障害の見当が付きます。この見当を、最初の採否の記録の基準として残しておきます。

通しの確認で見つかりやすいのは、所見を読む係が決まっていない、外への文面の許可者が決まっていない、AIの権限が想定より広い、の3つです。どれも、障害の夜に見つかると直す時間がない項目なので、入れる前の確認で潰しておきます。

よくある質問

AIの所見が正しいと分かっているなら、指揮役の確認は省いてよいですか

省かないほうが安全です。所見が当たっているかと、その対処をいま実行してよいかは別の判断です。原因が正しくても、実行の時刻や利用者への影響によっては待つほうがよい場面があります。

小さな情シスで、4つの役割に人を分けられません

一人で複数の役を兼ねてかまいません。避けたいのは、指揮役と所見の読み手を同じ人が兼ねることです。二人しかいないなら、一人が指揮と連絡、もう一人が調査と所見の読み取りを持つ分け方が無難です。

指揮役の交代を、AIエージェントが提案するのはよいですか

経過時間や対応者の稼働を知らせ、交代を検討する時期だと伝えるところまでは任せてかまいません。交代するかどうかと、誰に渡すかは人が決め、宣言も人がします。

どの質問にも共通するのは、AIに判断させず、根拠を添えた材料を出させ、人が確認する範囲を先に決めておく、という考え方です。

まとめ

障害対応にAIエージェントが入っても、インシデントコマンダーの席はAIに渡せません。AIが速くするのは調査で、候補が早く多く届くほど、止める、知らせる、実行を許すといった判断は指揮役のもとに集まります。調査はAIに渡し、記録と連絡は下書きまで任せ、指揮と所見の採否、権限の範囲、指揮役の交代は人が決める。そのうえで、所見を読む係を人の役として置き、AIエージェントを体制表の1行として書き、過去の障害で一度通して確かめてから本番に入れてください。

• AWSの製品の内容と数字は、AWS公式ブログの一般提供の発表（2026年3月31日）に基づきます。復旧までの平均時間などの数字は、プレビューの利用者の報告として提供元が紹介したものです
• NTTドコモの取り組みは、同社の報道発表（2026年2月25日）に基づきます
• 手引書の内容は、IPA産業サイバーセキュリティセンター中核人材育成プログラム9期生のプロジェクトによる「生成AIおよびAIエージェントを安全に活用するための手引書」（2026年7月31日 第1版）の3.3.3節と3.4.2節に基づきます。「インシデントコマンダー」という呼び名は、この手引書が定めたものではありません
• 製品の機能や提供状況は変わる可能性があるため、導入前に最新の公式情報を確かめてください

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。