AI障害対応Runbook：重大度分類・対応手順・振り返りの実務

AI 稼働後に最も足りないのは「障害時にどうするか」の台本です

AI 障害は増え続けています。AI Incident Database に記録された事故は 2024 年の 233 件から 2025 年には 362 件へと、一年で 5 割以上増加し、そのうち約 58% が生成 AI に関わるものでした。同じ時期、Gartner はエージェント型 AI プロジェクトの 4 割超が 2027 年末までに中止されると予測しており、主要因の一つとして「リスク管理の不備」を挙げています。多くのチームはモデルを本番投入することに力を注ぐ一方で、ハルシネーション、API タイムアウト、コスト暴走、データ漏洩が起きたときの対応フローを用意していません。停止のコストは抽象的なものではなく、2026 年の Splunk／Cisco の調査では大企業の停止コストは平均で 1 分あたり約 1 万 5 千ドルと試算され、Uptime Institute の年次分析でも運用者の過半数が直近の重大停止で 10 万ドルを超える損失を出し、約 5 分の 1 は 100 万ドルを超えたとされています。Runbook がなければ、障害が起きた瞬間にたまたまオンラインにいた最も経験豊富な人の即興判断に頼るしかなく、復旧は遅れ、責任は曖昧になり、同じ過ちが繰り返されます。

本稿では、そのまま実践できる AI 障害対応 Runbook を提示します。まず障害を分類し、次に対応フローと役割分担を定義し、最後に振り返りによってあらゆる障害を体系的な改善へと転化します。

ステップ 1：AI 障害を重大度（SEV）で分類する

分類の目的は、「誰を、どれだけ速く呼び起こすか」に客観的な根拠を持たせることです。SRE の慣例にならって 4 段階に分け、各段階に実在の AI 障害を錨として結び付けることを推奨します。

分類の最大の利点は、判断を個人の英雄的行動から切り離せることです。新人エンジニアも表を見れば上司を呼ぶべきか判断でき、最も経験豊富な人の到着を待つ必要がありません。分類は振り返りの要否も直接決めます。SEV1／SEV2 は必ず Postmortem を書き、SEV3 以下は状況に応じます。この基準は事前に Runbook へ書き込み、チーム全体の合意を得ておき、最も切迫した場面で「これは何級か」を議論せずに済むようにしてください。

AI 特有の障害要因を見落とさない

従来の Runbook はたいてい「サービスが落ちた」場合しか扱いませんが、AI システムの障害要因は拡大しています。これらの新しいリスク類型はいずれもシナリオ一覧に含めるべきです。

• ハルシネーションと誤った約束：モデルが自信を持って誤情報を返します。カナダ航空の事例（Moffatt v. Air Canada）は、企業がチャットボットの発言に法的責任を負うことを確立しました。
• プロンプトインジェクションとデータ漏洩：EchoLeak は本番の企業向け AI で実証された初のゼロクリック・データ流出脆弱性です。攻撃は普通のメールに潜み、Microsoft 自身のインジェクション判定を回避しました。Microsoft は 2025 年 6 月に修正済みで、実際に悪用された事例は確認されていません。
• ツールチェーンのサプライチェーンリスク：2026 年に OX Security は MCP エコシステムの体系的な脆弱性を公表し、約 20 万インスタンスに影響すると推定しました。汚染されたツール記述は呼び出されなくても context 全体を汚染しえます。
• コスト暴走：Uber は AI コーディングツールの年間予算を 4 か月で使い切り、あるエンジニアは約 100 体の AI エージェントを並行稼働させて 30 日で約 130 万ドルの API 費用を費やしました。そのうち約 7 割は「高速モード」設定によるものでした。コストの暴走は多くの場合、モデル自体ではなく既定値に起因します。

対応フローと役割分担

現場で最も恐ろしいのは、全員が同時に手を動かしながら誰も統括していない状態です。単一の「インシデントコマンダー」制度を設けることを推奨します。コマンダーは必ずしも自ら修復する必要はなく、意思決定・タスク割り当て・対外コミュニケーションを担い、責任の所在をプロセス上で明確にします。標準フローは次のとおりです。

• 検知とアラート：顧客からの苦情を待つのではなく、監視指標（エラー率、遅延、トークンコスト、ハルシネーション検知スコア）で自動的に発火させます。
• 分類と招集：SEV 表に従って重大度を判定し、on-call ローテーションで人を呼び、SEV1／SEV2 では直ちに作戦室を開設します。
• まず止血：安全モード（人手による審査、旧版へのロールバック、自動実行の停止、トークン上限の設定）に切り替えて影響を抑えてから、落ち着いて根本原因を追います。
• 連絡の同期：一定の頻度で影響を受けた側に更新を伝え、社内外のメッセージはすべてコマンダーが一元的に発信します。
• 復旧と確認：サービス復旧後も観察を続け、指標が安定してから正式に収束を宣言します。

振り返り（Postmortem）で障害を繰り返さない

復旧は止血にすぎず、真の価値は振り返りにあります。Google の SRE チームは長年の経験から、再発防止に最も効果的な手段は公開かつ無非難（blameless）の Postmortem だと結論づけています。無非難の原則を採り、個人の追及ではなくプロセスとシステムの欠陥に焦点を当てることで、エンジニアは正直に真相を再構成できます。有用な Postmortem には少なくとも次を含めます。

• 障害のタイムライン：検知・分類・止血から復旧までの重要な節目と意思決定。
• 影響範囲：影響を受けた利用者数、継続時間、データとコストの損失。
• 根本原因分析：技術面（モデル、データ、ツールチェーン統合）とプロセス面（監視の盲点、アラートの欠如）に分けて分析します。
• アクション項目：それぞれに担当者と期限を設け、クローズまで追跡し、机上の検討に終わらせません。

留意すべきは、AI 障害の根本原因が技術とプロセスの両端にまたがることが多い点です。モデル側のハルシネーションやインジェクションは、しばしば監視の盲点や欠けたアラート規則によって災害へと拡大されます。したがって Postmortem の成果は報告書だけでなく、新しい監視指標・アラート閾値・シナリオ台本として、次版の Runbook に還元されるべきです。

Runbook をチームの筋肉記憶に鍛える

書いただけで訓練しない Runbook は無いに等しいものです。四半期ごとに game day を設け、SEV1／SEV2 のシナリオを模擬して、アラートが鳴るか、on-call に連絡がつくか、止血手順が本当に有効かを検証することを推奨します。訓練後は詰まった箇所を Runbook に補い、文書をシステムとともに進化させます。よくある障害の処置手順をそのまま実行できるチェックリストとして書き、アラートメッセージに対応する Runbook のリンクを添えておけば、当番担当者は深夜に文書をめくり記憶を頼りに火消しする必要がなくなります。障害対応が「その場の火消し」から「表どおりの実行」に変われば、復旧の速度は特定の誰かがオンラインかどうかに左右されなくなり、AI システムは初めて稼働後の運用レジリエンスを備えたと言えます。

恩梯科技（Nerdtechnic）による AI 障害対応力の構築支援

恩梯科技（Nerdtechnic）は、台湾企業の AI システム導入と運用を長年支援してきました。私たちは AI エージェントを本番投入するだけでなく、監視・アラート、SEV 分類、on-call ローテーション、振り返りの仕組みをともに整え、AI サービスに監査可能かつ復旧可能な運用レジリエンスをもたらします。AI 導入の評価段階でも、カスタムシステム開発が必要な場合でも、OpenClaw で自動化ワークフローを構築したい場合でも、私たちは導入から運用までの一貫したコンサルティングを提供し、「障害時にどうするか」を毎回ゼロから始めるのではなく、チームの標準作業へと変えるお手伝いをします。

参考資料

• Stanford HAI，《AI Index Report 2026 — Responsible AI》，2026。出典リンク
• Gartner，《Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027》，2025。出典リンク
• Cisco／Splunk，《The $600 Billion Wake-up Call: New Splunk Research Reveals Downtime is a Systemic Business Crisis》，2026。出典リンク
• Uptime Institute，《Annual Outage Analysis 2026》，2026。出典リンク
• Aim Labs 研究チーム，《EchoLeak: The First Real-World Zero-Click Prompt Injection Exploit in a Production LLM System》（arXiv:2509.10540），2025。出典リンク
• McCarthy Tétrault，《Moffatt v. Air Canada: A Misrepresentation by an AI Chatbot》，2024。出典リンク
• OX Security，《The Mother of All AI Supply Chains: Critical, Systemic Vulnerability at the Core of the MCP》，2026。出典リンク
• TechCrunch，《Uber caps employee AI spending after blowing through budget in four months》，2026。出典リンク
• The Next Web，《Peter Steinberger's 100 AI agents racked up $1.3 million in OpenAI tokens in 30 days building OpenClaw》，2026。出典リンク
• Google SRE，《Site Reliability Engineering — Ch. 15: Postmortem Culture: Learning from Failure》，2016。出典リンク