インシデント管理AI基盤
AUTOMATED EMERGENCY RESPONSE & OPERATIONS DESK
鳴らして終わりでは、品質は上がりません。
重大なアラートを自動で架電して届け、そこから先——誰が受け、何が原因で、どう直したか——までを ひとつの基盤で扱います。AIが通報を読み解き、過去の対応と手順書を結び付け、溜まった記録を測る。 回すほど、次の対応が速く正確になります。 電話番号もアラートの内容も、外部のサービスへ渡りません。
監視は動いている。届いていないだけです。
アラートを出すところまでは、どの現場でも整っています。難しいのはその先です——夜中の2時に人へ届くか、届いたあと何が起きたかが残るか。
夜間・休日の一次対応が、人の当番に依存している
携帯を持ち回る、あるいは有人の監視窓口に預ける。どちらも人の手当てが必要で、気づくまでの時間は当番の状況に左右されます。眠っていて気づかなかった、を仕組みでは防げていません。
通報の設定が、想像で作られたまま古くなる
どのアラートを誰に上げるかは、構築時に机上で決めたきりになりがちです。実際に鳴ってみるまで正しさが分からず、担当が変わっても誰も直さないまま残ります。
対応の勘所が、個人の記憶に溜まる
前にも同じアラートが鳴ったはずだ、という記憶はあっても、そのとき何が原因で何をしたかは残っていません。毎回いちから調べ直すことになり、担当が抜けると失われます。
「起こして終わり」にしないための、4つの層
通報は入口にすぎません。AWS上で起きたことを、AIを使って管理し、通知し、蓄積し、分析する。この4つがひと続きになって初めて、運用の品質は積み上がっていきます。
人が気づく形で届ける
重大なアラートは自動で架電し、受領が取れるまで当番を順に呼び出します。チャットやメールへの同報は、架電を止めません。届いた通報は、AIが要約して先頭に出します。
誰が受けて、どう進んだかを追う
受領、担当の割り当て、影響度と緊急度の確定、復旧、完了。ITILに沿って状態を進め、次にやることを画面が1つだけ指します。対応中は、過去の実績と手順書から記載案を作れます。
次の当番が読める形で残す
原因と対処を書かなければ完了にできません。書かれた記録はそのまま次回の一次情報になり、取り込んだ運用手順書とあわせて、AIの検索対象になります。
効いているかを測り、前に返す
受領や復旧までの時間を中央値と上位値で。AIが挙げた仮説は当たったのか、溜めた知見は実際に使われたのか。測った結果が、通報の設定と知見の質へ返っていきます。
AIは、この4つすべてに薄く入っています。 届いた通報を要約し、対応中は過去の実績と手順書から記載案を作り、 書かれた記録は次の検索の対象になり、AIが挙げた仮説が当たったかどうかまで残る。 どこか一箇所に載せるのではなく、対応の流れ全体を支える形にしています。 そして書いた文章を、そのまま記録にはしません。採否は必ず人が決めます。
AEROD が、ほかの通報手段と違うところ
通報するだけの仕組みは、すでにいくつもあります。AEROD が引き受けているのは、その前後にある面倒のほうです。
情報を外部のサービスへ送りません
担当者の氏名も電話番号も、アラートの本文も、外部のサービスへは送りません。外部SaaSへ送る構成では通しにくい、閉域網の運用や個人情報の取扱方針にも合わせられます。ご利用人数による課金もありません。
画面に電話番号を表示するときは、API が応答を返す時点で伏せています。画面側だけを伏せる作りでは、ブラウザの開発者ツールから生の番号が読めてしまうためです。
アラート試験が、そのまま通報設定になります
構築時のアラート試験では、すべてのアラームを一度は発報させます。AEROD はその発報を実績として受け取るため、試験が終わった時点で「実在するアラートの一覧」が機械的に揃います。想像で設定を作る必要がありません。
通報設定は試験のあとに、一覧から一括で確定できます。手作業で1件ずつ登録する工程と、登録漏れが無くなります。
プロが用意したプロファイルを、AIがワークロードに当てはめます
WEB、ゲーム、基幹業務、情報系——同じアラートの並びでも、何を優先すべきかはシステムの性格で変わります。AWSの運用設計を重ねてきた私たちが、その判断を5つの方針として用意しました。方針を選べば、実際に鳴ったアラートに合わせた振り分けルールの案をAIが組み立てます。
ゼロから決めていただくのではなく、違うところを教えていただく形にします。要件を固める打ち合わせが短くなります。
生成AIが、通報を要約して関連する知見を添えます
通報を開くと、AIが本文を整理した要約が先頭に出ます。そのまま画面の案内に沿って進めば、受領から完了までひと通りの対応が終わります。あわせて、過去に同じアラートで何が起きてどう対処したか、取り込んだ運用手順書のどこが該当するかを検索して提示します。深夜に叩き起こされた人が、まず何を見ればよいかが画面に出ている状態を作ります。
実際に起きたことと、手順書に書かれた想定とは分けて表示します。深夜の判断では、この区別が決定的に効きます。
「起こす」経路と「知らせる」経路を、分けています
通報の経路は複数ありますが、役割は2つしかありません。ここを混ぜないことが、深夜に人が起きるかどうかを分けます。
起こす — 架電・SMS
個人宛てに、順番に呼び出します。受領の確認（ACK）を取る主体はこちらで、受領が無ければ次の当番へ進みます。
知らせる — チャット・メール
グループ宛てに、同報で一度だけ送ります。状況の共有が目的であり、受領を取る主体にはしません。
同報は、架電を止めません。「チャットに出しているから電話はしない」という設定を、そもそも作れないようにしています。 誰も見ていない時間帯に気づかれない、という事故の作り方として最もありがちな形だからです。 同報の送信が失敗した場合でも、架電は必ず続きます。
検知・記録
アラートを受け取り、まず通報の記録を作ります。抑止中で架電しない場合も、記録は必ず残します。
同報
チャットやメールへ状況を流します。ここが失敗しても、次の架電は止まりません。
架電 → 受領待ち
当番へ架電し、電話口での受領操作を待ちます。受領が無ければ次の当番へ。この巡回を繰り返します。
一巡後の切り替え
全員に架けても受領が取れなければ、別経路での通知へ切り替えます。届かないまま終わることはありません。
通報設定は、アラート試験の結果から組み立てます
監視の構築では、どのみち全アラームを一度は発報させます。その実績に、ワークロード別の方針とAIのリコメンドを重ね、通報設定をまとめて立ち上げます。
-
01
アラート試験で、すべてのアラームを発報させる
監視構築の一環として実施する試験です。各アラームが実際に発報し、通報の経路を通ることを確認します。AEROD はこの発報を受け取り、記録として残します。
-
02
発報したアラートが、そのまま一覧になる
試験を終えた時点で、実在するアラートが漏れなく揃った状態になります。設計書から書き写すのではなく、実際に鳴ったものだけが並びます。
-
03
方針を選ぶと、AIが振り分けルールの案を作る
ワークロードに合う方針を選ぶだけで、AIが実際に鳴ったアラートだけを読み、どのパターンを・架電するか記録にとどめるか・どの順で評価するかまで組み立てて提案します。なぜその優先度にしたのかの理由も、ルール1件ごとに付きます。
-
04
人が確かめて、まとめて確定する
出てきたものは案であって設定ではありません。深夜に誰の電話を鳴らすかを決めるものなので、保存はせず、人が見て採用します。確定は画面上でまとめて行い、全件の検証を通ってから反映するため、一部だけが中途半端に適用されることはありません。試験の実施記録は、そのままご報告の材料になります。
選べる方針は5つ
同じアラートの並びでも、何を優先すべきかはシステムの性格で変わります。その性格を選ぶだけで、優先順位の考え方がまるごと入れ替わります。
- 一般的
- 死活監視を最優先に組み立てます。サービスが生きているか（ヘルスチェック・到達性）を最上位に置き、次にエラー率と主要リソースの枯渇。個別の性能指標は後ろに回します。
- WEB 向け
- WAF・ELB・CloudFront など入口の異常を最優先。続いて応答時間と 5xx / 4xx の状態コード、その配下のアプリケーションとデータベース。バッチや緩やかな逼迫は後ろです。
- ゲーム向け
- WEB 向けの観点に加えて、アプリケーションログの異常（例外やエラーログの急増）を同格で最優先。セッション・マッチング・課金など、利用者に直結する処理を上位に置きます。
- エンタープライズ（基幹業務）
- システムの死活を最優先。次にバッチジョブの異常終了・遅延とそのログ、続いてデータベースとストレージ。画面の応答時間は業務時間外の影響が小さいため後ろに回します。
- エンタープライズ（情報系）
- ディスク・メモリ・ストレージなど、じわじわ枯渇する資源を最優先。次にデータベースの接続数の逼迫。死活も重要ですが、停止許容度が比較的高いためその次に置きます。
方針の中身は、画面にそのまま出ています。 何を優先しているのかが読めない状態で案だけ出てくると、「なぜこのルールになったのか」に答えられません。 優先順位の考え方を先に読み、納得してから採用していただく形にしています。
監視で怖いのは、鳴ることではありません。鳴らなくなることです。
通報の仕組みそのものが停止すると、画面は静かなままになります。何も起きていない状態と、 通報機構が死んだ状態とは、見分けがつきません。AEROD はこれを、別のリージョンから見張ります。
平常時 — 東京リージョン
- アラートの受け口、架電、記録のすべてを担当します
- 生存信号を定期的に書き込み続けます
- 外部からの受け口を持たない閉じた構成で動きます
東京が停止したとき — 大阪リージョン
- 生存信号が途絶えたことを検知します
- SMS とメールで、機構の停止そのものを通報します
- 東京側の復帰も検知して、あわせてお知らせします
大阪側は、東京に依存しない最小の構成にしています。依存する要素が少ないほど、 東京全体が止まった状況でも動く見込みが高くなるためです。
叩き起こされた人の、最初の5分を短くします
生成AIは、判断そのものではなく判断の前段に使っています。読む・探す・下書きする——時間がかかるわりに創造性の要らない部分だけを任せる設計です。
届いた通報を、開いた瞬間に要約して見せます
アラートの本文は、そのままでは読み解くのに時間がかかります。通報を開くと同時にAIが本文を整理し、いま何が起きているのかの要約を先頭に表示します。1件につき一度だけ動くため、通報が増えても費用が件数に比例して膨らみません。
仕分けが読むのは本文だけです。過去の実績を混ぜると、本文に書かれていないことが要約に現れ、読んだ当番がそれを本文の記載として扱ってしまうためです。
言い回しが違っても、過去の対応を探し当てます
エラー文字列の完全一致だけでは、「主キー制約で落ちています」といった自然な書き方に当たりません。意味による検索と識別子の完全一致を同時に走らせ、結果を融合して提示します。お使いの運用手順書も同じ仕組みで引けます（次の節）。
検索が見つけたものは、画面にも生成にも同じだけ渡します。片方だけに渡すと、画面には出ているのに「実績なし」と書かれる、という食い違いが起きます。
原因と対処の下書きを、根拠付きで作ります
過去の対応実績と運用手順書を根拠に、原因と対処の案を生成します。担当者が求めたときだけ動きます。お客様へお出しする障害報告の草案も、同じ材料から組み立てられます。
根拠が足りなければ「分かりません」と返します。欄を埋めること自体を目的にすると、確かめていない筋書きが残るためです。
AI に自己採点はさせません
提示した内容の確からしさは、AIの自己申告ではなく検索側の事実——意味検索の一致度と、識別子による裏付けの有無——から決めます。さらに、AIが挙げた仮説が当たったか外れたかを記録でき、蓄積が実際に効いているかを後から測れます。
答え合わせは当たり・外れ・未確認の3択です。2択にすると「確かめていない」が「外れ」に混ざり、的中率が実際より悪く出ます。
AIが書いた文章を、そのまま記録にはしません。 下書きを記録として採用するかどうかは担当者の操作に委ねています。確かめていない推測が実績として残ると、 次に同じアラートで呼ばれた人が、それを確定した事実として読んでしまうためです。 さらに、人が手を入れないまま採用された記録は、次回の推論の根拠から除外します。 AIの出力がAIの根拠になるという循環を、仕組みとして断っています。 推論を行うリージョンも選べます。アラートの本文にはテーブル名やホスト名が含まれるため、 情報の取り扱い方針にあわせて国内に閉じる構成を取れます。
手順書は、いま置いてある場所のままで構いません
お使いの手順書リポジトリを3時間ごとに読みに行きます。書き手はいつもどおり更新するだけで、その内容が夜間の当番へ届きます。移し替えも、二重管理も要りません。
いつもの場所を見に行く
手順書リポジトリの該当ディレクトリを3時間ごとに確認します。読み取りのみで、そちらへ書き込むことはありません。
変わっていなければ何もしない
先に最新の更新だけを確かめ、前回と同じならそこで終えます。更新が無い日は、ほとんど何も動きません。
見出し単位で切り分ける
資料をまるごとではなく見出しごとに保持し、必要な節だけを出せるようにします。ほかのリポジトリを指す箇所は取り込まず、辿れるリンクに変換します。
通報の画面に添える
アラートの内容と照らし、関連する手順書の節を提示します。一覧からその場で開いて読めます。
深夜に出してはいけないものを、出しません
手順書には、開発者の作業環境に関するものも混ざります。「依存パッケージの導入に失敗する」といった資料を夜間の当番へ提示しても害にしかなりません。本番の対応に使ってよい資料かどうかの区分は、資料を書いた側が持ちます。読んでいない側が分類すると、資料が増えたときに必ずずれるためです。
手順書だけの一致で「確か」とは言いません
提示の確度を高いとするには、過去に実際あった対応の裏付けを必要とします。手順書は「こう対処せよ」と設計されたものであって、実際に起きたことの記録ではないためです。一致したのが手順書だけなら、確度はそこで頭打ちにします。
区分の付いていない資料も、黙って捨てません。 取り込んだうえで検索の対象からは外し、件数と資料名を指標の画面に出します。 3時間ごとに自動で動くものは、取りこぼしに誰も気づけません。新しく書かれた手順書が 埋もれたままになるのを防ぐためです。最後に取り込めた時刻も画面に出しているため、 取り込みが止まったこと自体にも気づけます。
起こされた人が知りたいのは、残作業の一覧ではありません
「で、いま何をすればいいのか」——その一点に答えます。対応の流れを上から順に進める並びにしたうえで、いま次にやる1枚だけを色で指します。
- 通報が届いた直後
- 受領する ── まず手を挙げるところから。受領していない人に「担当を決めてください」「原因を書いてください」と促しても、順番を飛ばした案内になります。
- 受領した
- 担当の割り当てと、影響度・緊急度の確定 ── 受領すると仮に担当が付きますが、これは暫定の預かりです。割り振り先が自分自身であっても、意思をもって受け取る操作を挟みます。
- 担当と重要度が決まった
- 対応の記録 ── 何が原因で、何をしたか。ここに書かれた内容が、次に同じアラートが鳴ったときの一次情報になります。
- 記録が揃った
- 復旧、そして完了 ── 状態を進める操作は、画面のいちばん下にも置いてあります。記録を書き終えた人はそこにいるため、上の操作バーまで戻らせません。
- 完了した
- どこも指しません。次にやることが無いという状態を、そのまま示します。
指すのは、1枚だけ
未完了の項目をすべて強調すると、どれから手を付ければよいか分からなくなり、色が意味を失います。済んだところは背景を変えず、小さく「済」と出すだけにします。終わったところが目立つと、やることから目が逸れるためです。
押せないボタンには、理由を隣に出す
たとえば対応の記録が空のままでは、完了にもチケットの起票もできません。ボタンを灰色にして黙っているのではなく、なぜ押せないのかと、何をすれば押せるようになるのかを、その場に出します。
チケットの起票は、手順の鎖に入れない
訓練や誤報のように、起票せずに閉じる対応があります。鎖に入れると、起票しない限り「次はここ」が起票を指し続け、閉じられなくなったように見えます。起票は任意として、済んだかどうかだけを示します。
「確認中」と「対応中」を分ける
受領は手を挙げただけで、まだ調べ始めてはいません。同じ状態にまとめると、誰も着手していない通報に気づけなくなります。担当と重要度を確定した時点を境にし、そのために押すボタンは増やしません。
案内と、可否は分けて持っています。 「次はここ」はどこを見ればよいかの案内であり、画面が決めます。 一方で、完了にできるか・起票できるかという可否は必ずサーバ側が判定します。 画面にボタンを出さないだけでは、権限のない操作を止めたことにはならないためです。
記録が残る仕組みを、運用の側に作ります
対応の記録は「余裕があれば書くもの」になりがちです。AEROD は、書かなければ閉じられない形にしています。
復旧と、完了は別の状態
障害が収まった状態と、記録を締めた状態を分けています。原因と対処が書かれていない限り、完了にはできません。記録を残す動機を、運用の手順そのものに埋め込んでいます。
影響度と緊急度から優先度を決める
ITIL のインシデント管理に沿った状態遷移と等級付けを備えています。受領しただけの通報と、実際に調査が始まった通報とを区別して扱います。
過去の対応と、手順書を突き合わせる
同じアラートの過去の記録と、取り込んだ運用手順書の該当箇所を、あわせて提示します。実際に起きたことと、想定として書かれたものは、区別して表示します。
ふだんの時間と、悪いときの時間を見る
受領までの時間、復旧までの時間を中央値と上位値で集計します。平均は少数の長期化に引きずられるため使いません。何件から出した数字かを必ず添えます。
ここで書かれた原因と対処が、次に同じアラートが鳴ったときの一次情報になります。 AIが検索して提示するのも、担当者が書いたこの記録です。 記録を書く手間が、次の当番の時間を短くする——その循環が回り始めるところまでを、導入でご一緒します。
導入の流れ
電話番号の取得に時間がかかるため、早い段階で並行して進めます。番号が届く前から、通報の動作確認は可能です。
-
01
ご相談・現状の整理
いま何をどう監視していて、夜間の一次対応をどなたが担っているかを伺います。通報の範囲と当番の体制を、この段階で大まかに決めます。
-
02
電話番号の取得手続きを開始
発信に使う電話番号の取得には、通常2〜6週間ほどかかります。書類のご準備が必要なため、着手を決めた時点で並行して進めます。
-
03
監視設計とアラームの実装
どの事象で人を起こすのかを決め、アラームを実装します。既存の監視をお使いの場合は、そこからの連携を設計します。
-
04
構築と、番号なしでの通報試験
電話番号が届く前でも、実際には発信しない設定で、当番の巡回・受領による停止・一巡後の切り替えまで一通り確認できます。
-
05
アラート試験と、通報設定の確定
全アラームを発報させる試験を実施し、その結果から通報設定を確定します。実際の通話での聞き取りやすさもここで確認し、運用を開始します。
ご提供の範囲と、前提になる条件
お引き受けできる範囲と、事前にご確認いただきたい点を先に明記しておきます。
- ご提供するもの
- インシデント管理基盤一式の設計・構築、対応画面、運用手順書の取り込み設定、アラート試験の実施と通報設定の確定まで。
- 監視アラーム
- 通報の起点となるアラームが必要です。既存のものをご利用いただけますが、新規に実装する場合はあわせてご支援します。
- 運用手順書
- お使いの手順書リポジトリから読み取りのみで取り込みます。置き場所を移していただく必要はありません。取り込み対象の範囲は導入時に取り決めます。
- 電話番号
- 発信用の番号を新規に取得します。書類の準備を含め、通常2〜6週間ほどのお時間をいただきます。
- 費用
- 構築の範囲とご希望の運用体制によって変わります。ご利用人数に応じた課金はありません。個別にお見積りいたします。
- 運用開始後
- 当番表や通報先の変更は、画面からお客様ご自身で行えます。変更のたびに弊社へご依頼いただく必要はありません。