結論

AI開発の本番運用中に障害が発生した場合、迅速にベンダーに連絡し、適切なエスカレーションを行う必要がある。連絡先と対応SLAを一元管理したエスカレーション表を整備しておくと、障害対応の遅延を防げる。本記事では、その作成と運用を解説する。特にAIシステムでは、モデル出力の異常やAPIの変化が障害につながるため、多様な連絡先が必要になる。

定義・判断すべきこと

障害時ベンダー連絡エスカレーション表とは、AI開発システムで障害が発生した際に、誰に、どの順序で、どの手段で連絡し、どのような対応SLAを期待するかをまとめた表である。判断すべきことは、障害のレベル分け、連絡先、エスカレーション条件、対応SLA、である。

比較表と確認観点

表を見る際のポイントは、各項目が「契約書やRFPにどう落とし込まれているか」である。数値だけではなく、責任の所在と証跡の形式を確認すると、後からのトラブルを減らせる。特にAI開発では、技術的な確認だけでなく、業務・運用・法務の観点も同じテーブルに載せることが重要である。

運用・契約・管理の進め方

エスカレーション表は、本番運用開始前に作成し、発注者とベンダーで合意する。表には、連絡先、担当時間帯、バックアップ担当、連絡手段、SlackやチケットURLも含める。障害発生時は、表に従って連絡し、対応状況を記録する。実務では、エスカレーション表を運用マニュアルの冒頭に配置し、関係者がすぐに参照できるようにする。

データ・権限・ログの扱い

AI開発の障害では、モデル出力の異常、データ連携の停止、APIのレートリミット超過、プロンプトの誤動作などが考えられる。エスカレーション表には、技術的な問い合わせ窓口と、業務的な問い合わせ窓口を分けて記載すると対応がスムーズになる。障害発生時のログ収集責任も定めておく。

コスト・測定・見直し

エスカレーション表自体は低コストで作成できるが、24時間対応や緊急対応を契約に含めると費用が増える。対応レベルと費用のバランスを見て、必要な範囲で契約する。大規模案件や重要な業務システムでは、24時間対応を検討する価値がある。

よくある失敗パターン

よくある失敗は、連絡先が古くて連絡がつかないこと、バックアップ担当が設定されていないこと、障害レベルの定義が曖昧で判断に迷うこと、エスカレーション表が関係者に周知されていないことである。

実務チェックリスト

• 障害レベルの定義を定めている
• 各レベルごとの連絡先と連絡順序を決めている
• 初動目標と対応SLAを明記している
• 連絡手段と連絡先情報を最新に保っている
• バックアップ担当や代理連絡先を設定している
• 障害対応の記録と振り返りを行っている
• 運用マニュアルの冒頭に配置している

図解で確認するポイント

この記事の画像は、AI開発障害時のベンダー連絡エスカレーション表を示している。図解では「障害発生 → レベル判定 → 担当者連絡 → 管理職エスカレーション → 対応 → 解決」という流れを描くとよい。

AllAI内での次の行動

AllAIでは、AI開発契約のチェックポイント、AI開発のベンダーロックインリスク、AI開発RFPの書き方へ進める。

FAQ

Q. エスカレーション表は誰が管理しますか？ A. 発注者側の運用担当者が管理し、ベンダー側と定期的に更新する。

Q. 深夜や休日の障害はどう扱いますか？ A. 契約で対応時間帯を定め、緊急時の連絡方法を明示する。

Q. 連絡がつかない場合は？ A. 次のエスカレーション先へ連絡し、連絡試行の記録を残す。

出典と確認日

• デジタル庁 政府情報システムのためのセキュリティ評価制度（ISMAP）: https://www.digital.go.jp/policies/isms/ (確認日: 2026-07-10)
• 日本弁護士連合会 契約書作成のポイント: https://www.nichibenren.gr.jp/ (確認日: 2026-07-10)
• 経済産業省 下請法ガイドライン: https://www.meti.go.jp/policy/commerce/shitauke/ (確認日: 2026-07-10)
• 経済産業省 AI事業者ガイドライン 第1.2版: https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html (確認日: 2026-07-10)