AIシステムを本番環境に導入した後、「回答の精度が下がった気がする」「AIが変な出力を返すようになった」「ユーザーからクレームが来ている」——そんな経験をした方は少なくないはずです。しかし、一般的なサーバー停止とは異なり、AIシステムの品質問題は「稼働しているのに品質が落ちている」という見えにくい状態で発生します。ベンダーに問い合わせても「問題なく稼働しています」と返ってきて、発注者として何を根拠に対応を求めればよいのか分からない、という場面に直面することがあります。
この問題の根本にあるのは、多くのAIシステムの契約において「精度SLA」や「エラーバジェット」といったAI固有の品質指標が設定されていないことです。通常のシステム保守契約で盛り込む稼働率SLA（99.9%など）だけでは、AIの品質劣化を指摘する根拠になりません。発注者がSLAの視点でAIシステムを管理できていないために、品質問題が発生しても「問題の定義すら難しい」という状況に陥ります。
本記事では、まずAIシステム固有の障害分類を整理し、次に発注者が契約・保守合意書で確認すべきSLA指標を解説します。そのうえで、本番障害が発生した際に発注者が取るべき初動5ステップと、障害後の事後対応、さらに次回契約時の再発防止策として活用できるチェックリストまでを一貫してご紹介します。AIシステムのカットオーバー後に「何かおかしい」と感じたときの行動指針として、ぜひ参考にしてください。
なお、本記事はAIシステム特有の障害対応にフォーカスしています。一般的なシステム障害（サーバー停止・データベース障害など）の発注者対応フローについては「本番障害発生時の発注者対応フロー」をご覧ください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
AIシステムの障害は「普通のシステム障害」と何が違うのか
AIシステムの障害を「サーバーが落ちた」と同じ感覚で捉えていると、初動を誤ります。まず、AIシステムの障害が一般的なシステム障害とどう異なるのかを整理しましょう。
AIシステムの障害は大きく4つのタイプに分類できます。
タイプ1: 可用性障害
サーバーの停止や応答不能など、システム自体がダウンしている状態です。これは一般的なシステム障害と同様で、監視ツールのアラートやエラーレスポンスですぐに検知できます。ベンダーへの障害報告フローも通常のシステムと同じく機能します。
タイプ2: 精度劣化（モデルドリフト）
AIシステムが「稼働しているにもかかわらず」推論精度が低下している状態です。モデルが学習した時期のデータ分布と、現在の入力データの分布がずれてくることで発生します（データドリフト）。チャットボットの回答品質が落ちた、OCRの認識精度が下がった、需要予測の誤差が拡大した——といった現象として現れます。稼働中であるため自動アラートが鳴らず、ユーザーからのフィードバックや定期モニタリングによって初めて気づく場合がほとんどです。
タイプ3: 出力異常（ハルシネーション・バイアス・有害出力）
生成AIに特有の障害で、事実と異なる情報をもっともらしく出力するハルシネーション、特定の属性に偏った回答を返すバイアス、コンプライアンス上問題のある表現の増加などが含まれます。モデルのバージョンアップや、ファインチューニングデータの変化をきっかけに発生することがあります。
タイプ4: コンプライアンス逸脱
個人情報の混入、社内ポリシーや法的規制に反する出力が発生している状態です。このタイプは発見が遅れると実損害に直結するため、他のタイプと異なり即時エスカレーションが必要です。
今起きている事象がどのタイプかを判断する早見表
| 確認ポイント | 該当タイプ | 緊急度 |
|---|---|---|
| サービスが止まっている・エラーが返ってくる | タイプ1: 可用性障害 | 高 |
| 稼働はしているが回答精度・予測精度が下がっている | タイプ2: 精度劣化 | 中〜高 |
| AIが事実と異なる内容や不適切な内容を出力している | タイプ3: 出力異常 | 中〜高 |
| 個人情報の漏洩・法的問題となる出力が疑われる | タイプ4: コンプライアンス逸脱 | 最高（即エスカレーション） |
タイプ2〜4が発注者にとって特に厄介です。サービスは稼働しているため自動的には検知されず、気づいたときにはすでにユーザー被害が積み重なっているケースがあります。また、「何が障害なのか」の定義自体が難しいため、ベンダーに問い合わせても「問題ありません」と返ってきてしまうことがあります。この定義問題を解消するのが、次に解説するAI向けSLA指標です。
発注者が今すぐ確認すべき「AIシステムのSLA」3つの指標
SLA（Service Level Agreement：サービスレベル合意）は、発注者がベンダーに品質不足を指摘するための根拠になります。AIシステムの場合、通常の稼働率SLAに加えて、AI固有の品質指標を契約・保守合意書に盛り込んでおくことが重要です。今すぐ確認すべき3つの指標を解説します。
指標1: 可用性SLA（稼働率・ダウンタイム上限）
これは一般的なシステムと同様です。AIシステムの推論APIやサービス全体が何%の時間稼働しているかを定めます。稼働率の数値は一見大差がないように見えますが、許容されるダウンタイムには大きな差があります。
| 稼働率 | 月間許容ダウンタイム | 年間許容ダウンタイム |
|---|---|---|
| 99.9%（スリーナイン） | 約43分 | 約8.7時間 |
| 99.5% | 約3.6時間 | 約1.8日 |
| 99.0% | 約7.2時間 | 約3.6日 |
「99.9%を保証する」という記載があれば、月43分以上ダウンした場合にSLA違反として対応を求められます。可用性SLAの詳細な設計・交渉方法については「システム開発・保守契約のSLAガイド」も参考にしてください。
指標2: 精度SLA（推論精度・F値・正答率の下限値）
これがAIシステム固有の重要指標です。「AIの精度が下がった」と発注者が感じたとしても、精度SLAが契約に記載されていなければベンダーに改善を求める法的根拠がありません。
精度SLAでは「どの指標を、何%以上に保つか」を明記します。業務用途別の目安は以下のとおりです。
| AI活用用途 | 推奨精度指標 | 目安下限値 | 計測頻度 |
|---|---|---|---|
| 問い合わせチャットボット | 意図分類精度（F値） | 85%以上 | 週次 |
| 帳票OCR・文書読み取り | 文字認識正確率 | 97%以上 | 日次 |
| 需要予測・売上予測 | MAPE（平均絶対誤差率） | 10%以下 | 月次 |
| 文書要約・生成AI | ハルシネーション率（人手評価） | 5%以下 | 月次 |
精度SLAの記載がない場合、発注者がとれる現実的な選択肢は3つです。
- 次回契約更新時に追加する: 最もクリーンな方法。更新交渉の際に「精度SLAの明記」を必須条件とします
- 覚書・追補契約として今すぐ合意する: 現行契約に覚書を追加することで、書面上の根拠を確保します
- 運用上の合意事項として議事録に残す: 最低限、「月次で精度を〇〇%以上に保つ」という合意を議事録化しておきます。法的拘束力は弱いですが、対話の記録として活用できます
指標3: 応答時間SLA（P95応答時間・タイムアウト上限）
AIの推論処理は一般的なデータベース参照より時間がかかります。応答が遅すぎると業務フローが止まるため、応答時間の上限も明記しておきましょう。
「P95で3秒以内」という記載は、全リクエストの95%が3秒以内に完了することを意味します。業務用途別の目安は以下です。
| 用途 | P95応答時間の目安 | タイムアウト設定 |
|---|---|---|
| リアルタイム対話チャットボット | 3秒以内 | 10秒 |
| バッチ処理（夜間の需要予測など） | 規定不要（時間帯保証のみ） | ジョブ単位で設定 |
| 文書読み取り・OCR | 5秒以内（ページあたり） | 30秒 |
コラム: エラーバジェットという考え方
SLAに「エラーバジェット（Error Budget）」という概念を追加することも有効です。これは「全期間のうち、品質未達が許容される時間の総量」を事前に決めておく考え方です。たとえば「月間の推論リクエストのうち、精度SLA未達となるリクエストを1%以内に収める」と定めることで、完璧な精度を毎回求めるのではなく、現実的な品質保証が可能になります。エラーバジェットが尽きた時点でベンダーに改善対応を要求する、というルールを設けると運用がスムーズです。
AIシステムの本番障害 初動5ステップ
AIシステムの品質問題が発生したとき、発注者として何をすべきか。ここでは「何をすべきか」「ベンダーに何を確認すべきか」「社内で何を動かすべきか」の3軸で、初動の5ステップを整理します。
ステップ1: 事象を分類する（5分以内）
最初にすべきことは、「今起きていることが何なのか」を言語化することです。
上記のタイプ分類表に当てはめ、今見ている事象が「可用性障害（サーバー停止）」なのか、「精度劣化」なのか、「出力異常」なのか、「コンプライアンス逸脱」なのかを判定します。焦ってベンダーに「早く直してください」と連絡するのは、事象を特定してからにしてください。タイプが異なれば対処方法も異なるため、ベンダーへの指示も変わります。
ベンダーへの初期連絡文テンプレート
件名: [緊急度: 高/中] AIシステム品質問題の報告
[日時]
[事象の概要: 例「チャットボットの回答が事実と異なる内容を返すケースが増加している」]
[業務影響: 例「カスタマーサポート業務で誤案内が発生する可能性がある」]
[確認を依頼したいこと: 例「直近24時間の推論精度ログの確認と、暫定対応策の提示」]
次の報告を [X時間後] に希望します。事象を3行で整理してからベンダーに送ることで、「問題を定義できていない発注者」ではなく「根拠を持って対応を求める発注者」として交渉できます。
ステップ2: 業務影響を特定する（30分以内）
AIシステムの品質問題が「どの業務プロセスに、どの程度の影響を与えているか」を自社側でマッピングします。
確認すべきポイントは以下の3点です。
- 影響範囲の確認: そのAIシステムが担っている業務プロセスをリストアップし、どのプロセスが現在影響を受けているかを確認します
- 代替手段の確認: AIなしで業務を手動代替できるか、代替にかかるコストと工数を見積もります
- SLA指標との照合: 精度SLAや可用性SLAが設定されている場合、現状の数値がSLA水準を下回っているかを確認します
ベンダーには以下の情報提供を求めてください。
- 復旧の見込み時間（ETA: Estimated Time to Recovery）
- 影響を受けているシステムの範囲
- 暫定回避策の有無（AIを迂回して手動処理するための支援など）
ステップ3: 社内エスカレーション判断（30〜60分以内）
ステップ2で把握した業務影響をもとに、経営層・関連部門への報告が必要かを判断します。以下の3軸マトリクスで判断してください。
| 軸 | 判断基準 | エスカレーション要否 |
|---|---|---|
| 業務停止時間 | 2時間以上 | 必要 |
| 影響顧客数 | 10件以上のユーザー影響 | 必要 |
| 代替手段 | 手動代替が不可能 | 必要 |
いずれか1つでも該当すれば、経営層への第一報を入れることを推奨します。
タイプ4（コンプライアンス逸脱）は即エスカレーション必須です。 個人情報の漏洩リスクや法的規制違反が疑われる場合は、業務影響の大小に関わらず、法務担当・プライバシー責任者を即時起動してください。
一次報告の骨格
① 事象の概要（何が起きているか、いつから）
② 業務影響（どの業務に、どの程度の影響が出ているか）
③ 現在のベンダー対応状況（ベンダーからの回答・復旧ETA）
④ 次の報告タイミング（例: X時間後に続報を共有）体制の構築方法・オンコール契約の詳細については「外部エンジニアを含む障害対応・オンコール体制の作り方」も参照ください。
ステップ4: ユーザー告知の判断（状況に応じて）
一般的なサーバー停止であれば「サービスが止まっている」という事実が明確なため、告知の判断は比較的シンプルです。しかし、AIシステムの品質問題では告知の要否判断が難しくなります。「サービスは稼働しているが精度が落ちている」という場合、ユーザー自身が問題に気づいていないケースも多いからです。
以下のいずれか1つでも該当すれば、告知を検討してください。
- ユーザーがAIの出力に基づいて意思決定・行動している（例: AIの案内を信じて手続きを行った）
- 誤った出力が実害につながる可能性がある（例: 医療情報・法的情報・財務情報を含む）
- 問題が長時間続く見込みである（例: 原因特定・修正に数日かかる）
告知文の構成
① 現象（何が起きているか）
② 影響範囲（どのユーザー・機能が影響を受けているか）
③ 対応状況（現在どういった対応を行っているか）
④ 復旧見込み（いつ頃に解消される見込みか）
⑤ お詫び・感謝（ご不便をおかけして申し訳ありません、ご報告いただいた方への感謝）「まだ確定していないから告知しなくていい」という判断は、後から批判されるリスクがあります。判断に迷う場合は「ユーザーが知ることで不利益を避けられるか」を基準にしてください。
ステップ5: 復旧確認と暫定対処の合意
ベンダーから「復旧しました」と連絡が来ても、発注者側で復旧を確認するまで対応を終了しないでください。AIシステムの場合、「サーバーを再起動した」だけでは品質が復旧していないケースがあります。
精度劣化型（タイプ2）の場合: 復旧とは「サーバーが起動している」ことではなく、「精度指標がSLA水準に戻っている」ことです。ベンダーにSLAで定めた精度指標の数値を報告させ、自社側でも確認してください。
出力異常型（タイプ3）の場合: 復旧には「問題のあった出力パターンが解消されていること」と「同種の問題が再発しない対策が合意されていること」の両方が必要です。
また、復旧までの間に「AIを無効化して手作業で対応する期間」が発生する場合、そのコスト・期間の上限を書面で合意しておきましょう。「とりあえず手動で対応してください」では、いつまでも手動対応が続くリスクがあります。
ここで合意したベンダーへの要求事項は記録に残し、次のステップ（事後対応・ポストモーテム）に引き継ぎます。
障害後の事後対応 — ポストモーテム要求と再発防止
障害が収束した後、ベンダーに対してポストモーテム報告書（事後分析書）の提出を求めることが重要です。これは再発防止の議論を始めるための根拠資料であり、次回の契約更新・SLA改定の材料にもなります。
ベンダーに要求すべきポストモーテムの内容
ポストモーテム報告書には、以下の4項目を必ず含めるよう求めてください。
- 根本原因（RCA: Root Cause Analysis）: 表面的な「モデルの精度が下がった」ではなく、「なぜ精度が下がったか」の原因追及が必要です
- タイムライン: 障害発生→検知→対応開始→復旧までの時系列。どの段階でどれだけ時間がかかったかを確認します
- 再発防止策と実施スケジュール: 「検討します」ではなく、「いつまでに、何を実施するか」を明記させます
- SLA違反の有無と補償の適用: 可用性SLAや精度SLAを下回った場合、契約上の補償規定を確認します
AIシステム特有のRCA観点
AIシステムの障害における根本原因追及では、一般的なシステム障害と異なる視点が必要です。精度劣化（モデルドリフト）の場合、以下の点を確認してください。
- 学習データの鮮度問題: モデルの学習データが古くなり、現在の入力パターンとズレが生じていないか
- 外部データの変化: 連携している外部データソース（市場データ・ユーザー行動データなど）に変化があったか
- 前処理・特徴量の変化: データの前処理ロジックやモデルへの入力特徴量に変更が加わっていないか
- モデルバージョンの変更: サードパーティのAI APIを使用している場合、プロバイダー側でモデルのバージョンが変更されていないか
ポストモーテム報告書の評価ポイント
受け取った報告書が「形式だけで根本原因が曖昧」なものでないか、以下のポイントで確認してください。
- 根本原因の記述が「〜の可能性がある」という推定にとどまっていないか（証拠があるかを確認）
- 再発防止策が「監視を強化する」「注意する」のような抽象的な表現でないか
- 再発防止策の実施期限が明記されているか
報告書の内容が不十分な場合は差し戻し、具体的な情報の追記を求めてください。障害対応が完結するのは、ポストモーテムが発注者として納得できる内容になった時点です。
AIシステムを発注する前にやっておくべきSLA準備
ここまで読んだ方の中には「障害が起きてから対処するのではなく、最初からSLAを整備しておくべきだった」と感じている方もいるかもしれません。今後AIシステムを発注する方、または契約更新を控えている方向けに、事前準備のチェックリストをまとめます。
| # | チェック項目 | SLA記載なしの場合のリスク |
|---|---|---|
| 1 | 可用性SLA: 稼働率・ダウンタイム上限・初動対応時間・緊急連絡先が記載されているか | 障害発生時にベンダーの対応義務が不明確になる |
| 2 | 精度SLA: 業務用途に応じた精度指標・下限値・計測方法・計測頻度が明記されているか | 精度劣化が発生してもベンダーに改善を求める根拠がない |
| 3 | 応答時間SLA: P95応答時間・タイムアウト設定が業務用途に合わせて設定されているか | AI推論の遅延が業務影響を生じさせても対応を求められない |
| 4 | エラーバジェット: 許容できる品質未達期間の総量が合意されているか | ベンダーに改善対応を要求するトリガーが曖昧になる |
| 5 | 障害時エスカレーション先: 技術担当・PM・法務の連絡先と、連絡すべき事象の定義が明確か | タイプ4（コンプライアンス逸脱）発生時に迅速対応できない |
| 6 | ポストモーテム提出義務: 障害発生から何営業日以内に報告書を提出するかが定められているか | 事後分析がなく再発防止が進まない |
各項目の詳細な水準設定の方法については「システム開発・保守契約のSLAガイド」を参照してください。同記事では、SLAの一般的な設計手順・交渉時のポイントを詳しく解説しています。
これら6項目のうち、特にAIシステムで重要なのはチェック2（精度SLA）とチェック4（エラーバジェット）です。従来のシステム発注経験がある担当者でも、AI固有の品質指標を契約に盛り込むことは盲点になりやすいため、チェックリストとして手元に置いておくことをお勧めします。
まとめ
AIシステムの障害が「見えにくく対処しにくい」最大の理由は、「稼働しているのに品質が落ちている」という精度劣化・出力異常がサービス停止のように自動検知されないことにあります。そして、AI固有のSLA指標が設定されていないと、問題が起きても発注者がベンダーに対応を求める根拠を持てません。
本記事で解説した初動5ステップをまとめると以下のとおりです。
- 事象を分類する（5分以内）: 可用性障害・精度劣化・出力異常・コンプライアンス逸脱のどのタイプかを特定してからベンダーに連絡する
- 業務影響を特定する（30分以内）: 影響範囲・代替手段の有無・SLAとの乖離を確認し、ベンダーへの情報要求をまとめる
- 社内エスカレーション判断（30〜60分以内）: 業務停止時間・影響顧客数・代替手段の3軸で判断し、タイプ4は即エスカレーション
- ユーザー告知の判断（状況に応じて）: ユーザーが誤った出力に基づいて行動するリスクがある場合は告知を検討する
- 復旧確認と暫定対処の合意: ベンダーの「復旧しました」を鵜呑みにせず、SLA指標の回復を自社でも確認する
また、発注者が確認すべきAIシステムのSLA指標は「可用性SLA」「精度SLA」「応答時間SLA」の3つです。今すぐできる行動として、現在の契約書・保守合意書を開き、AI固有の品質指標（精度SLA・エラーバジェット）が記載されているかを確認してみてください。
関連記事もぜひ参照ください。
- 本番障害発生時の発注者対応フロー（一般システムの障害対応）
- システム開発・保守契約のSLAガイド（SLAの定義・契約書の読み方）
- 外部エンジニアを含む障害対応・オンコール体制の作り方（体制設計・オンコール契約）
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 精度SLAが現在の契約に記載されていない場合、ベンダーに改善を求める根拠はありますか？
現行契約に精度SLAがなければ法的根拠はありませんが、「覚書として今すぐ精度目標を合意する」または「議事録に月次精度目標を記録する」ことで対話の根拠を確保できます。契約更新まで待たず、まず書面による合意を求めることを優先してください。
- AIシステムの精度劣化は自動でアラートが鳴らないとのことですが、発注者はどうやって気づけばよいですか？
ユーザーからのクレーム・問い合わせ件数の増減を週次でモニタリングすることが最も現実的な方法です。契約・保守合意書に「週次または月次でベンダーが精度指標を報告する」義務を盛り込むことで、発注者が自力で検知しなくて済む仕組みをつくれます。
- ベンダーが「問題ありません」と回答し、精度劣化を認めない場合はどう対処すればよいですか？
発注者側で事象を記録した画面キャプチャ・ユーザーからのフィードバック・発生日時を文書化し、「具体的な精度ログの数値で確認してほしい」とデータ提示を書面で要求します。それでも対応が得られない場合は、エスカレーション先として法務担当を交えた三者協議に移行することを検討してください。
- タイプ4（コンプライアンス逸脱）が疑われる場合、AIシステムを即時停止すべきですか？
個人情報漏洩や法的規制違反が「疑われる」段階でも、業務継続よりもリスク回避を優先してAIを停止し、法務担当とプライバシー責任者を即時起動することを推奨します。停止判断を遅らせた場合の実損害は、停止による業務影響より大きくなるケースがほとんどです。
- ベンダーへポストモーテム提出を求める場合、期限は何営業日を目安にすればよいですか？
一般的には障害収束後5営業日以内を目安とし、コンプライアンス逸脱（タイプ4）の場合は3営業日以内を推奨します。契約に記載がない場合も、障害発生後の最初のコミュニケーションで提出期限を書面で合意しておくことで、「検討中」のまま放置されるリスクを防げます。
