- SLA（サービスレベル契約）の基本概念と必要性
- SLAで定めるべき指標（SLI）の種類と設定方法
- 稼働率の計算方法と現実的な目標値
- SLA違反時のペナルティ・補償条項の設計
- 運用保守契約へのSLA盛り込み方と交渉ポイント
SLAとは何か — なぜ必要なのか
SLA（Service Level Agreement）は、システムやサービスの提供者と利用者の間で「どのレベルのサービスを保証するか」を定めた合意文書です。日本語では「サービスレベル契約」や「サービス品質保証」と呼ばれます。
SLAがないと何が起きるか。たとえば、社内システムが停止したときに「いつまでに復旧するのか」を巡って揉めます。発注者は「すぐ直してほしい」と思い、受注者は「契約にない対応はできない」と返す。この認識のズレがトラブルの原因になります。
SLAは、こうした「暗黙の期待」を数値で明文化し、サービス品質を保証する仕組みです。
SLAが特に重要なケース
- 基幹システムの運用保守 — 停止すると業務が止まるため、復旧時間の保証が必須
- ECサイト・Webサービス — ダウンタイムが直接的な売上損失になる
- SaaS・クラウドサービスの利用 — AWS、Azure等のクラウドもSLAを提供している
- 外部ベンダーへの運用委託 — 委託先のサービス品質を契約で担保する
SLAの構成要素 — SLI・SLO・SLA
SLAを正しく設計するには、3つの概念を理解する必要があります。
| 用語 | 正式名称 | 意味 | 例 |
|---|---|---|---|
| SLI | Service Level Indicator | サービス品質を測る指標 | 稼働率、レスポンスタイム、エラー率 |
| SLO | Service Level Objective | SLIの目標値（社内目標） | 稼働率99.95%を目指す |
| SLA | Service Level Agreement | SLOを対外的に約束した契約 | 稼働率99.9%を保証する |
ポイントは、SLO（社内目標）はSLA（契約上の保証値）より高く設定することです。SLAギリギリで運用していると、少しのトラブルで契約違反になってしまいます。
SLAで定めるべき主要指標
①稼働率（Availability）
最も基本的なSLA指標です。「月間でシステムが正常に稼働している時間の割合」を示します。
計算方法
稼働率 = （総時間 − ダウンタイム）÷ 総時間 × 100%
稼働率の数字は、0.1%の違いが大きなインパクトを持ちます。
| 稼働率 | 月間許容ダウンタイム | 年間許容ダウンタイム | 一般的な用途 |
|---|---|---|---|
| 99.0% | 約7.3時間 | 約3.7日 | 社内ツール、開発環境 |
| 99.5% | 約3.6時間 | 約1.8日 | 一般的な業務システム |
| 99.9%（スリーナイン） | 約43分 | 約8.8時間 | ECサイト、基幹システム |
| 99.95% | 約22分 | 約4.4時間 | 重要なWebサービス |
| 99.99%（フォーナイン） | 約4.3分 | 約53分 | 金融・医療システム |
中小企業のシステムであれば、99.5〜99.9%が現実的な目標値です。99.99%以上を求めると、冗長構成や24時間監視体制が必要になり、コストが大幅に跳ね上がります。
②応答時間（Response Time）
障害やインシデントが発生してから、運用チームが「対応を開始する」までの時間です。復旧完了までの時間ではなく、「認知して着手する」までの時間である点に注意してください。
| 重要度 | 定義 | 応答時間の目安 |
|---|---|---|
| 緊急（P1） | システム全体が停止 | 15分〜1時間 |
| 重大（P2） | 主要機能が利用不可 | 1〜4時間 |
| 通常（P3） | 一部機能に不具合 | 4時間〜翌営業日 |
| 軽微（P4） | UXの問題、要望 | 翌営業日〜3営業日 |
③復旧時間（MTTR）
MTTR（Mean Time To Recovery）は、障害が発生してから正常な状態に復旧するまでの平均時間です。応答時間とは異なり、「完全に直るまで」の時間です。
- P1障害の復旧目標：4時間以内
- P2障害の復旧目標：8時間〜翌営業日
- 完全復旧が困難な場合は、暫定対応（ワークアラウンド）の提供時間を別途定める
④対応時間帯
運用保守の対応時間帯は、コストに直結する重要な要素です。
- 24時間365日 — ECサイト、SaaSなど停止が許されないサービス向け。コスト高
- 平日9:00〜18:00 — 一般的な社内システム向け。最もコスト効率が良い
- 平日9:00〜21:00 — 夜間の利用もある場合の折衷案
- 営業時間外はアラート監視のみ — P1障害だけ夜間対応する方式
⑤その他の指標
- バックアップ頻度 — 日次/週次/リアルタイム。RPO（Recovery Point Objective）として定義
- レスポンスタイム — Webページの表示速度（95パーセンタイルで3秒以内、等）
- データ保全 — バックアップの保持期間、リストア手順の確認頻度
- 月次レポート — SLI実績の報告頻度と内容
SLA違反時のペナルティ条項
SLAは「約束」なので、守れなかった場合の取り扱いを定める必要があります。
ペナルティの種類
- サービスクレジット — SLA未達の度合いに応じて、翌月の利用料から割引。クラウドサービスで一般的
- 減額・返金 — 月額保守費用の一部を減額。運用保守契約で一般的
- 契約解除権 — 重大なSLA違反が繰り返された場合に発注者が契約を解除できる条項
サービスクレジットの設計例
| 月間稼働率 | サービスクレジット |
|---|---|
| 99.9%以上 | なし（SLA達成） |
| 99.0〜99.9% | 月額費用の10% |
| 95.0〜99.0% | 月額費用の25% |
| 95.0%未満 | 月額費用の50% |
免責事項（SLA除外）
以下のケースは一般的にSLAの計算対象外とします。
- 計画メンテナンス（事前に通知されたもの）
- 発注者の責に帰すべき事由（操作ミス、未承認の変更等）
- 不可抗力（天災、大規模停電等）
- 第三者サービスの障害（クラウド基盤自体の障害等）
運用保守契約へのSLA盛り込み方
契約書の構成
SLAは運用保守契約の本体に含めるか、別紙として添付するのが一般的です。
- 契約本体 — 委託範囲、期間、報酬、解約条件など基本事項
- 別紙1：SLA — SLI・目標値・ペナルティ条項・免責事項
- 別紙2：運用手順書 — 障害対応フロー、エスカレーションルール、連絡体制
交渉のポイント
- 数値の根拠を共有する — 「99.9%にしたい」だけでなく、「月43分以上止まると○万円の損失」と具体的に説明
- 段階的に引き上げる — 初年度は99.5%、2年目から99.9%のように段階設定も有効
- 測定方法を合意する — どのツールで、何を基準に稼働率を測定するか
- レポーティングの頻度 — 月次レポートでSLI実績を共有し、問題を早期発見
- 見直し条項 — 年1回のSLA見直し協議の場を設ける
主要クラウドサービスのSLA比較
自社でSLAを設計する際の参考として、大手クラウドのSLAを見てみましょう。
| サービス | 稼働率保証 | サービスクレジット |
|---|---|---|
| AWS EC2 | 99.99% | 稼働率99.0%未満で30%クレジット |
| Azure Virtual Machines | 99.99%（可用性ゾーン利用時） | 稼働率99.0%未満で25%クレジット |
| Google Cloud Compute | 99.99% | 稼働率99.0%未満で25%クレジット |
| Salesforce | 99.9% | 非公開（個別交渉） |
自社が利用するクラウドのSLAを超える保証を約束することはできません。たとえば、AWSの上で動くシステムで99.999%のSLAを保証するのは、基盤自体が99.99%保証のため原理的に困難です。
あわせて読みたい
- システム開発の契約ガイド｜請負・準委任・SESの違いと注意点
- システム開発の検収・納品ガイド｜検収基準の決め方とトラブル防止策
- システム開発トラブルの法的対応｜瑕疵担保・損害賠償・契約解除
- システム保守の費用相場と契約で確認すべきポイント
- クラウド移行ガイド｜オンプレミスからクラウドへの移行手順と費用【2026年版】
まとめ
- SLAはサービス品質の「数値化された約束」。暗黙の期待を明文化しトラブルを防ぐ
- 稼働率は0.1%の差が大きい。99.9%と99.99%ではコストが桁違いに変わる
- 応答時間と復旧時間は分けて定義。「対応開始」と「完全復旧」は別の指標
- ペナルティはサービスクレジットが一般的。段階的な設計でリスクを適切に配分
- 免責事項を明確に。計画メンテナンス・不可抗力・第三者起因はSLA対象外とする
- 年1回の見直し。ビジネス環境やシステム構成の変化に合わせてSLAも更新する
SLAの設計や運用保守契約のご相談は、お問い合わせからお気軽にどうぞ。FUNBREWでは、システム開発から運用保守まで一貫したサポートを提供しています。
この記事をシェア