結論

障害対応の初動30分で失われる時間の大半は、復旧作業ではなく「誰に連絡すべきか探す時間」です。AIシステムは、保守ベンダー、クラウド、外部モデルAPI、データ連携先と関係者が多層になるため、障害の切り分け前に連絡先を探し始めると初動が崩壊します。対策は、深刻度×時間帯×障害種別の3軸で連絡先と期待応答を一枚に定めたエスカレーション表を作り、保守契約の連絡窓口条項と整合させ、四半期ごとに連絡訓練で実効性を確認することです。表は作った瞬間から陳腐化が始まるため、更新責任者の指名が表の内容と同じくらい重要です。

エスカレーション表の3軸構造

エスカレーション表は次の3軸で引けるように作ります。

各セルには、連絡先(窓口の電話・メール・ポータル)、期待応答時間(SLAの受付確認・一次回答期限)、連絡できない場合の代替経路を書きます。ここで重要なのは、保守契約のSLA(P1は30分以内に受付確認、など)と表の期待値を一致させることです。契約にない期待値を表に書いても、ベンダーは動きません。逆に契約にあるSLAが表に反映されていなければ、権利を行使し損ねます。

AI特有の「品質障害」経路を設計する

システムは正常稼働しているが誤出力が急増している、という「AI品質障害」は、従来の障害管理では受付窓口すら存在しないことがあります。エスカレーション表には品質障害の行を明示的に作り、検知者(業務部門が多い)からの報告受付、深刻度の判定基準(誤出力が顧客対応・金銭・個人情報に影響するならP1相当)、一次対応(該当機能の停止、人間運用への切替)の判断者を定めます。

外部モデルAPIの障害・仕様変更起因の場合、保守ベンダーは「自社起因ではない」と一次対応を保留しがちです。契約とエスカレーション表の両方に、外部起因の場合も保守ベンダーが状況調査・影響報告・代替手段の提示までは担うことを明記してください。障害の帰責と初動対応の責任は別物として設計するのが原則です。

多層ベンダー構成での窓口一元化

開発ベンダー、インフラ保守、データ連携先の運用会社が別々の場合、発注側が障害のたびに切り分けて各社に連絡する構造は破綻します。推奨は、一次窓口(SPOC)を保守契約で一社に定め、切り分けと他社への連絡調整をその窓口の責務とする構造です。SPOC構成が取れない場合は、エスカレーション表の障害種別軸を細かくし、「どの症状ならどこへ」の判断表を発注側の運用担当が使える粒度で作ります。

各社の契約に「他社との合同調査への協力義務」があるかも確認してください。責任の押し付け合い(うちのログでは正常です)は、合同調査の枠組みがないときに起こります。

連絡訓練と表のメンテナンス

エスカレーション表は、年2-4回の連絡訓練で検証します。訓練は本格的な障害対応演習でなくてよく、「P1想定で表の連絡先に実際に架電・起票し、期待応答時間内に応答があるかを確認する」だけで、電話番号の変更、担当者の退職、夜間窓口の実態(実は誰も出ない)が発見されます。訓練結果は記録し、発見された穴の修正を期限つきで管理します。

表の更新トリガーは、ベンダーの体制変更通知、契約更新、組織改編、訓練での発見の4つです。更新責任者(発注側の運用管理者)を表の欄外に明記し、最終更新日と次回訓練予定日も表自体に載せてください。「最終更新が1年前の表」は、それ自体が危険信号として機能します。

障害記録との接続

エスカレーション表で動いた結果は、障害記録(タイムライン、影響、原因、対応、再発防止)として残し、月次の保守定例でレビューします。連絡がSLAどおりに機能したかも記録の項目に含めると、SLA違反の証跡が自然に蓄積され、契約更新時の交渉材料になります。エスカレーションの実績データ(P1の第一報から一次回答までの実測時間など)は、ベンダー評価の最も客観的な指標のひとつです。

実務チェックリスト

• 深刻度×時間帯×障害種別の3軸でエスカレーション表を作ったか
• 各セルの期待応答時間が保守契約のSLAと一致しているか
• AI品質障害の受付経路と深刻度判定基準を定めたか
• 外部API起因でも保守ベンダーが調査・報告を担う義務を契約に入れたか
• 多層ベンダーの一次窓口(SPOC)または判断表を整備したか
• 各社契約に合同調査への協力義務があるか確認したか
• 年2回以上の連絡訓練を計画し結果を記録しているか
• 表の更新責任者・最終更新日・次回訓練日を表に明記したか

図解で確認するポイント

この記事の画像は、障害の発生点から複数の連絡経路が段階的に分岐し、適切な対応者へ到達する構造を文字なしで図解しています。連絡の順序と分岐が事前に定義されていることが、初動の速さを決めることを示しています。

AllAI内での次の行動

障害の切り分けと対応期限はバグトリアージSLAガイド、SLA違反時の記録はSLA違反エスカレーション証跡の残し方、監視体制の分担は本番監視の引き継ぎRACIテンプレートが隣接テーマです。保守体制を含む発注要件はAI発注診断で整理し、AI開発パートナーで夜間対応を含む保守条件を比較してください。

FAQ

Q. エスカレーション表はどのくらいの分量が適切ですか? A. A3一枚またはWiki1ページに収まる分量が原則です。障害時に読む文書は、開いて10秒で該当セルにたどり着けなければ機能しません。詳細な手順は別文書にリンクし、表自体は連絡先と判断基準に絞ってください。

Q. 夜間休日の対応をベンダーが提供していない場合は? A. まず業務影響から本当に24時間対応が必要かを見直します。必要なら、夜間はP1のみ受付のオプション契約や、監視サービスの追加を検討します。契約がないのに夜間に個人の携帯へ連絡する運用は、対応品質も持続性もないため避けてください。

Q. 発注側の連絡体制はどう書きますか? A. ベンダーからの逆方向の連絡(重大障害の通知、計画停止の連絡)を受ける発注側窓口と代理者も、同じ表に書きます。ベンダー側から見て「夜間に発注側の判断者へ連絡がつかない」ことが復旧遅延の原因になるケースは珍しくありません。

Q. 訓練に協力しないベンダーへの対処は? A. 連絡訓練は保守契約の範囲内の軽微な作業(受付応答の確認)として設計し、契約更新時に訓練協力を条項化するのが確実です。訓練を嫌がる背景に夜間窓口の実態がない可能性もあるため、拒否自体を評価情報として扱ってください。

出典と確認日

• IPA「情報システム・モデル取引・契約書」: https://www.ipa.go.jp/digital/model/index.html (確認日: 2026-07-10)
• 経済産業省「AI事業者ガイドライン(第1.2版)」: https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html (確認日: 2026-07-10)
• IPA「ITサービス継続ガイドライン」: https://www.ipa.go.jp/archive/security/reports/economics/itservice.html (確認日: 2026-07-10)
• NIST「AI Risk Management Framework」: https://www.nist.gov/itl/ai-risk-management-framework (確認日: 2026-07-10)