AI開発ベンダーのSLA違反エスカレーション証跡の残し方
AI開発の保守運用でベンダーのSLA違反が起きたとき、通知・協議・是正要求・減額請求まで進められる証跡の残し方と、契約前に決めるエスカレーション段階を解説します。

結論
ベンダーのSLA違反に対して減額や契約見直しを主張できるかどうかは、違反発生時ではなく契約前の設計で決まります。必要なのは、SLA指標の測定主体を発注側にも持たせること、違反の通知から協議・是正・ペナルティ適用までのエスカレーション段階を契約書に書くこと、そして各段階でどの証跡(ログ、通知メール、議事録、是正計画書)を残すかを決めておくことの3点です。この記事では、AI開発の保守・運用契約でSLA違反時に泣き寝入りしないための証跡設計を解説します。
SLA違反のエスカレーション証跡とは
エスカレーション証跡とは、SLA違反の検知から解決までの各段階で、いつ・誰が・何を通知し、ベンダーがどう応答したかを時系列で再現できる記録の集合のことです。単なる障害記録との違いは、契約条項(応答時間、復旧時間、稼働率など)と対応づけて「どの条項の違反か」を特定できる形で残す点にあります。
AI開発の保守では、モデルの精度劣化やAPI応答遅延のように「障害と呼ぶか判断が割れる事象」が多いため、SLA指標の定義と測定方法を曖昧にしたままだと、違反かどうかの認定自体で揉めます。
契約前に決めるエスカレーション段階
エスカレーションは段階と期限を決めて契約別紙に入れます。次の4段階が標準的な構成です。
| 段階 | トリガー | 発注側の行動 | 残す証跡 |
|---|---|---|---|
| L1: 検知通知 | SLA指標の逸脱を検知 | チケットで事象と該当条項を通知 | 監視ログ、通知チケット |
| L2: 正式協議 | L1から5営業日で解消しない | 管理職間の協議を書面で要求 | 協議議事録、ベンダー回答書 |
| L3: 是正要求 | 同一違反が月2回以上 | 是正計画書の提出を期限つきで要求 | 是正計画書、進捗報告 |
| L4: ペナルティ | 是正期限までに未解消 | 減額請求または契約見直し通知 | 減額計算書、内容証明 |
段階を飛ばすと「協議を尽くしていない」と反論される余地が生まれます。逆に、L1の口頭連絡だけを繰り返して書面化しないのが、発注側の最も多い失敗です。
SLA指標の測定主体と証跡の形式
測定主体がベンダーだけだと、違反の一次データをベンダーが握ることになります。稼働率と応答時間は発注側の外形監視(合成監視)でも測り、両者の数値が乖離した場合の優先順位を契約に書いてください。
| 証跡 | 形式の要件 | 保管期間の目安 |
|---|---|---|
| 監視ログ | タイムスタンプつき、改変不可の形式でエクスポート | 契約終了後1年以上 |
| 通知記録 | チケットまたはメール。口頭連絡は当日中に書面化 | 同上 |
| 協議議事録 | 双方の出席者名と合意事項、次回期限を明記 | 同上 |
| 是正計画書 | 原因、対策、完了予定日、責任者をベンダー名義で | 同上 |
議事録は発注側が作成してベンダーに確認を取る運用にします。ベンダー作成の議事録だけに頼ると、違反の認定に不利な表現が残ることがあります。
減額請求とペナルティ条項の実務
SLA違反のペナルティは、月額保守費の減額率テーブルで定めるのが一般的です。稼働率99.5%未満で5%減額、99.0%未満で10%減額のように段階を作り、減額の上限(月額の20%など)も同時に決めます。上限のないペナルティはベンダーが受けないため、上限とセットで交渉するのが現実的です。
減額請求時は、L1からL4までの証跡一式を添付した請求書面を送ります。ここで監視ログの測定条件(測定間隔、判定基準)が契約と一致していることを確認してください。測定条件の不一致は、減額請求が却下される典型的な理由です。
精度劣化SLAという難所
AI特有の論点として、モデル精度の劣化をSLAに含めるかがあります。含める場合は、評価データセットの固定、評価頻度(月次など)、劣化の閾値、再学習の費用負担を全部決める必要があります。ここまで固められない場合は、精度はSLAではなくSLO(努力目標)として扱い、閾値を下回った場合の協議義務だけを契約に入れる方法が現実的です。経済産業省のAI事業者ガイドラインも、AIの性能が運用データの変化で変動しうる前提での継続的な評価を求めています。
実務チェックリスト
- SLA指標ごとに定義、測定方法、測定主体を契約別紙に書いたか
- 発注側の外形監視を用意し、数値乖離時の優先順位を決めたか
- L1-L4のエスカレーション段階と各期限を契約に入れたか
- 口頭連絡を当日中に書面化する運用ルールを決めたか
- 議事録は発注側作成・ベンダー確認の運用にしたか
- 減額率テーブルと減額上限を合意したか
- 精度劣化をSLAとSLOのどちらで扱うか決めたか
- 証跡の保管場所と保管期間を決めたか
図解で確認するポイント
この記事の画像は、監視ダッシュボードからアラートが上がり、段階的なエスカレーションを経て是正に至る流れを文字なしで図解しています。各段階で記録が積み上がっていく構造を確認できます。
AllAI内での次の行動
保守契約の全体設計はAI開発の保守契約ガイド、ペナルティ条項の詳細はベンダーSLAペナルティ契約ガイドを確認してください。障害対応の一次切り分けはAI開発のバグトリアージSLAガイドが参考になります。これから発注する場合はAI発注診断で要件を整理し、AI開発パートナーで保守体制を比較できます。
FAQ
Q. SLA違反の証跡はどこまで細かく残すべきですか? A. 「第三者(法務や裁判所)が時系列を再現できるか」が基準です。検知時刻、通知時刻、ベンダー応答時刻、解消時刻の4点と該当条項が最低限で、スクリーンショットより機械可読なログのほうが証拠力は安定します。
Q. ベンダーが違反を認めない場合はどうすればよいですか? A. まず測定条件の一致を確認し、双方の測定値を並べた協議議事録を残します。認定で平行線になる事態を減らすため、契約時に「乖離時は発注側指定の第三者測定を優先する」等の決着ルールを入れておくのが有効です。
Q. 減額請求をすると関係が悪化しませんか? A. 減額テーブルを契約時に合意しておけば、請求は感情論ではなく契約の適用になります。むしろ曖昧なまま不満を溜めて更新時に一方的に打ち切るほうが、移行リスクが大きくなります。
Q. クラウドやLLM APIの障害が原因の場合もベンダーの違反になりますか? A. 外部サービス起因の免責範囲を契約でどう定めたか次第です。免責にする場合も、ベンダーには外部障害の検知通知と代替手段の提示義務を残すのが実務的です。
出典と確認日
- 経済産業省「AI・データの利用に関する契約ガイドライン」: https://www.meti.go.jp/press/2018/06/20180615001/20180615001.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「情報システム・モデル取引・契約書」: https://www.ipa.go.jp/digital/model/index.html (確認日: 2026-07-10)
- NIST「AI Risk Management Framework」: https://www.nist.gov/itl/ai-risk-management-framework (確認日: 2026-07-10)
関連する記事・ガイド
- AI開発会社ガイドBest-of-N: OpusAI開発 本番KPI未達時の契約見直し会議
AIシステムの本番KPIが未達のとき、事業責任者・PM・調達が開く契約見直し会議の論点、証跡、判断、費用の見方を整理します。
- AI開発会社ガイドBest-of-N: OpusAI開発 検収後クレームの紛争証跡ワークフロー
AI受託開発の検収後にクレームや紛争が起きたとき、法務・PM・経理が証跡を整理するワークフロー、紛争段階、費用の見方を整理します。
- AI開発会社ガイドBest-of-N: OpusAI開発 障害時ベンダー連絡のエスカレーション表
AIシステムの障害時に、運用・情シス・ベンダーが使うエスカレーション表の作り方、連絡基準、証跡、費用の見方を整理します。
- AI開発会社ガイドBest-of-N: OpusAI開発 運用マニュアル検収の版管理
AI受託開発で納品される運用マニュアルを、運用・品質保証・情シスが検収し版管理する手順、確認項目、証跡、費用の見方を整理します。