多くの方にご覧いただき、誠にありがとうございます。 実務においてSLAの策定や運用に関わる方に向けて、わかりやすく丁寧にSLAの書き方をまとめました。 2025年4月更新：SLAテンプレート構成、KPI指標、作成手順、違反対応フローを追加し、実務に即した形でアップデートしました。
運用フェーズに欠かせないSLAとは
– SLA/OLA/UCの基本と実践的な考え方 –
はじめに
システムやサービスの開発が完了し、いよいよ運用フェーズへと移行する段階で必要になるのが SLA（Service Level Agreement） です。
実際には、開発前の段階からクライアントと合意し、SLAの内容を明確にしておくことが理想です。
SLA / OLA / UCとは何か
SLA（Service Level Agreement）
SLAとは、「サービス品質保証契約」とも呼ばれ、サービス提供者と利用者の間で取り交わされる、サービス内容や品質レベルに関する合意文書です。
主な内容例
- 稼働率（例：99.9%の可用性）
- サポート時間帯
- 障害発生時の対応時間
SLAが必要な理由
- 品質の明文化により、トラブルを未然に防止できる
- 提供者側の「防御線」として機能する
- 利用者に安心感と信頼を提供できる
OLA（Operational Level Agreement）
SLAを守るために、社内チーム間で取り交わす合意書です。
担当者や対応範囲、責任分界点、エスカレーション手順などを明確にします。
UC（Underpinning Contract）
外部ベンダーやクラウドサービスと結ぶ契約書で、SLAを支える基盤となります。
たとえば、AzureやAWSのSLAを自社SLAに反映させる必要があります。
SLA作成のステップ（詳説）
SLAは、単に契約文書を作る作業ではなく、サービスの全体設計と運用方針を明文化する重要なプロセスです。以下に、実務的な視点での手順を詳しく解説します。
1. サービス内容の棚卸しと構成の整理
- 提供するサービス、機能、対象範囲を洗い出す
- SaaSの場合：Webアプリ、API、バッチ処理、管理画面など
- どの範囲がSLAの対象になるか（例：本番環境のみ、検証環境は対象外）
📝 目的：曖昧な範囲はトラブルの元。まずはスコープを明確に。
2. クライアント視点で重要な品質項目を特定
- ユーザーがもっとも重視する項目は何か？（例：レスポンス時間、安定稼働、障害時の対応スピード）
- 利用シーンや業務上の制約から逆算する
- ユーザーとのヒアリングが効果的
📝 目的：SLAの中心は“ユーザー価値”。ズレると形骸化します。
3. 社内でOLAを締結し役割を明確化
- 開発・SRE・カスタマーサポートなど、関係チームの責任を分担
- 例：障害検知はSRE、初動連絡はCS、技術調査は開発チームなど
- 夜間・休日対応の有無なども明確に
📝 目的：社内で実行できないSLAは意味がありません。内部合意が不可欠です。
4. 外部ベンダーとのUC（Underpinning Contract）を確認
- クラウドインフラ（Azure, AWSなど）、外部API（SMS送信、決済など）
- それぞれのSLAと制限事項（例：S3の耐久性、Cloudflareの保証範囲など）
- 自社のSLAより高い保証はできないため、ベンダーSLAを必ず確認・添付
📝 目的：依存先の限界を知らずに自社SLAを組むと破綻します。
5. KPIを設定し評価方法を明記
- 例：月間稼働率99.9%、障害初動10分以内、CS対応満足度85%以上など
- KPIは「可視化可能」かつ「継続測定」できるものにする
- メトリクス取得元（監視ツール、ログ、アンケートなど）を明示
📝 目的：KPIなきSLAは、評価できない約束になってしまいます。
6. SLAドラフト作成 → レビュー → クライアント合意
- ドラフト作成後、社内レビュー（運用・法務・営業）
- クライアントへ提示し、質疑応答を経て合意
- バージョン管理と合意履歴の保存も重要
📝 目的：契約として成立するには、相互理解と明文化が必要です。
SLAにおけるKPI（評価指標）
| KPI項目 | 説明 |
|---|---|
| SLA合意目標の未達率 | 目標稼働率や対応時間に届かなかった割合 |
| OLA・UCの未対応件数 | 内部・外部要因で未達となった件数 |
| SLAレビュー率 | 定期レビューの実施率 |
| SLA変更件数 | 契約改定や修正の頻度 |
| SLA未カバー業務の発生数 | 対象外の業務が発生した件数 |
| 顧客満足度 | ユーザーアンケートなどのスコア |
SLA違反が発生した場合の対応フロー
- ユーザーからの報告受付（問い合わせ、監視検知）
- 運用チームによる影響確認とSLA適用判断
- 復旧対応とログ・証跡の記録
- SLA未達が確定した場合：
- クライアントへの報告
- 補填や返金などの合意対応
- 再発防止策の提示
SLAの種類
努力目標型SLA
- 初期導入フェーズに適している
- SLA未達でもペナルティなし（ただし計測は行う）
目標保障型SLA
- 本格運用、公共案件に多い
- SLA未達時の補償条件や契約解除条項が必要
SLAテンプレート構成例
1. 適用範囲
- サービス名・機能概要
- 対象となるサービスの提供範囲
- 提供者情報（会社名・部署など）
2. サービス提供時間帯
- 稼働時間（例：24時間365日）
- サポート時間（例：平日9:00〜18:00）
計画停止について
- 停止の通知期限（例：3営業日前）
- 停止の目的、頻度、通知方法の明記
3. SLA未達成時の対応
- 利用者からの申請手順
- 返金の有無と上限額
- 契約見直しの条件など
4. サービスごとの基準値
- 可用性（例：月間99.9%以上）
- 障害対応時間（例：初動5分以内）
- 障害復旧目標時間
- 通知手段と通知時間
5. 障害の定義
例：
「30分以上、全ユーザーがサービスへアクセスできない状態を“障害”と定義する」
6. SLAの適用外条件
- 天災（地震、洪水など）
- 通信回線障害（ユーザー側）
- 外部サービス停止（例：クラウド障害）
7. SLA変更フロー
- 提出手順、レビュー方法
- 通知期間（例：変更30日前）
- クライアント同意取得の手段
SLA運用Tips・よくある落とし穴
- 「障害」などの定義が曖昧でトラブルになりやすい
- ベンダーのSLAを考慮せずに高い目標を掲げてしまう
- SLAのレビューや更新が行われず形骸化する
SLAは誰が作る？いつから作る？
- 作成者：サービス運用責任者（PMやSRE）
- レビュー：法務・営業部門
- タイミング：要件定義と並行して早期に着手することが望ましい