「SLAとSLOを英語でどう文書化すればいいか」と悩んだことはないだろうか。
SLA（Service Level Agreement：サービスレベル合意書）とSLO（Service Level Objective：サービスレベル目標）は、サービスの信頼性を定義し、顧客・ステークホルダーと合意するための文書だ。SREプラクティスの中核であり、グローバルなプロダクト開発では英語での作成が求められる。
この記事では、英語SLA・SLO設計書の4つの必須セクションと日英テンプレートを解説する。コピペで使えるWord形式のテンプレートもダウンロードできる。
SLAとSLOの違いを正確に理解し、英語で信頼性目標を定義・合意できるようになる、実践的な内容だ。
英語SLA・SLO設計書とは？SLIとの違いも整理する
SLA・SLO設計書は、サービスの信頼性に関する目標・測定方法・合意内容を体系的に文書化したものだ。SRE（Site Reliability Engineering）の基盤となる文書であり、エラーバジェットの算出や障害対応の優先度判断にも使われる。
まず、3つの用語の違いを整理する。
| 用語 | フルネーム | 意味 |
|---|---|---|
| SLI | Service Level Indicator | サービスの品質を測る指標（例：成功率・レイテンシ） |
| SLO | Service Level Objective | SLIの目標値（例：成功率99.9%以上） |
| SLA | Service Level Agreement | 顧客と合意したSLO・補償条件を含む契約 |
SLOはSLIの目標であり、SLAはSLOを含む顧客との正式な合意だ。SLOはSLAより厳しく設定するのが一般的で、その差がエラーバジェットの余裕になる。
英語SLA・SLO設計書が必要な場面は以下のとおりだ。
| 場面 | 例 |
|---|---|
| 顧客契約 | 企業顧客へのSLA提示・契約締結 |
| 内部合意 | チーム間・部門間のSLO設定 |
| SREプラクティス導入 | エラーバジェット制度の確立 |
| 監査・コンプライアンス | 可用性保証の証跡 |
| インシデント対応基準 | SLO違反時のエスカレーション判断 |
英語SLA・SLO設計書の4つの必須セクション
英語SLA・SLO設計書は4つのセクションで構成する。
1. SLI Definition（サービスレベル指標の定義）
測定対象の指標（SLI）を明確に定義するセクションだ。何を測定するかが曖昧だと、SLOの値に意味がなくなる。
主要なSLIの種類と定義例：
| SLIカテゴリ | 測定対象 | 計算式 |
|---|---|---|
| Availability | サービスの可用性 | 成功リクエスト数 ÷ 総リクエスト数 |
| Latency | 応答時間 | p50 / p95 / p99のレイテンシ |
| Throughput | スループット | 単位時間あたりの処理件数 |
| Error Rate | エラー率 | エラーリクエスト数 ÷ 総リクエスト数 |
| Durability | データ永続性 | 1年間でのデータ損失リスク（例：99.999999999%） |
SLI定義シートの例：
| 項目 | 内容 |
|---|---|
| SLI名 | API Availability |
| 説明 | APIエンドポイントが正常にレスポンスを返した割合 |
| 測定対象 | /api/v1/* への全HTTPリクエスト |
| 成功の定義 | HTTPステータスコード 2xx を返したリクエスト |
| 除外条件 | 計画メンテナンス中・レート制限（429）のリクエスト |
| データソース | CloudWatch Logs / Datadog APM |
| 集計期間 | 30日間のローリングウィンドウ |
英語例文：
- “The SLI measures the proportion of successful requests, defined as HTTP 2xx responses, out of all valid requests.”
- “Planned maintenance windows are excluded from SLI calculations.”
- “We measure latency at the p99 percentile to capture tail latency that affects the worst-served users.”
2. SLO Targets（サービスレベル目標の設定）
SLIに対して達成すべき目標値（SLO）を設定するセクションだ。
SLO設定の例：
| サービス | SLI | SLO目標 | 測定期間 | エラーバジェット |
|---|---|---|---|---|
| API Gateway | Availability | 99.9% | 30日 | 43.2分/月 |
| API Gateway | Latency (p95) | 200ms以内 | 30日 | 43.2分/月 |
| Batch Processing | Throughput | 95%完了 | 24時間 | 72分/日 |
| Data Pipeline | Availability | 99.5% | 30日 | 3.6時間/月 |
| Database | Durability | 99.9999999% | 年間 | 0.032秒/年 |
エラーバジェットの計算例：
- SLO: 99.9% availability（30日間）
- 許容ダウンタイム: 30日 × 24時間 × 60分 × (1 – 0.999) = 43.2分/月
SLO設定の考え方：
- SLAより5〜10%厳しく設定し、SLAまでのバッファを持つ
- 過去の実績データに基づいて現実的な値を設定する
- サービスの重要度に応じてSLOを差別化する（コア機能 > 補助機能）
英語例文：
- “The SLO target of 99.9% availability corresponds to a monthly error budget of 43.2 minutes.”
- “The SLO is set 0.1% stricter than the SLA to provide a safety buffer before contractual obligations are breached.”
- “When the error budget is exhausted, new feature releases are paused until reliability is restored.”
3. SLA Terms & Compensation（SLA条件と補償規定）
顧客との合意内容・補償条件を定義するセクションだ。SLOを下回った場合の対応が明示されることで、顧客との信頼関係が構築される。
SLA可用性ティアの例：
| ティア | 可用性目標 | 月間許容ダウンタイム | 対象サービス |
|---|---|---|---|
| Platinum | 99.99% | 4.3分 | ミッションクリティカルシステム |
| Gold | 99.9% | 43.2分 | 基幹業務システム |
| Silver | 99.5% | 3.6時間 | 補助業務システム |
| Bronze | 99.0% | 7.2時間 | 開発・テスト環境 |
補償規定（Service Credits）の例：
| SLA未達率 | 補償クレジット |
|---|---|
| 99.0% 〜 99.9%未満 | 月額利用料の10% |
| 95.0% 〜 99.0%未満 | 月額利用料の25% |
| 95.0%未満 | 月額利用料の50% |
対象外条件（Exclusions）：
- Force Majeure（不可抗力：自然災害・停電・通信障害等）
- Planned maintenance with prior notice（事前通知済みのメンテナンス）
- Customer-caused outages（顧客側の操作に起因する障害）
- Third-party service failures（外部サービスの障害）
英語例文：
- “If the monthly uptime percentage falls below 99.9%, the customer is eligible for Service Credits.”
- “Service Credits are the customer’s sole remedy for SLA violations.”
- “Planned maintenance windows notified at least 72 hours in advance are excluded from SLA calculations.”
- “Service Credits will be applied to the following month’s invoice upon customer request.”
4. Monitoring & Incident Response（モニタリングと障害対応）
SLOを継続的に監視し、違反時に迅速対応するための仕組みを定義するセクションだ。
モニタリング体制の例：
| 監視項目 | ツール | 頻度 | アラート閾値 |
|---|---|---|---|
| Availability | Datadog / CloudWatch | 1分 | SLO 50%消費時 |
| Latency (p99) | Datadog APM | 5分 | 閾値の120%超過 |
| Error Rate | ELK Stack | 1分 | 0.1%超過 |
| Error Budget | SLO Dashboard | 1時間 | 残量50% / 10% |
エラーバジェット消費アラートの段階：
| 消費率 | アクション |
|---|---|
| 50%消費（月中） | チームへの通知・原因調査開始 |
| 75%消費 | 新機能リリースの一時停止 |
| 100%消費 | 信頼性改善を最優先・経営報告 |
インシデント対応フロー（英語）：
| ステップ | 英語表記 | 内容 |
|---|---|---|
| 1. Detection | Alert triggered | モニタリングがSLO違反を検知 |
| 2. Acknowledgment | Incident acknowledged | 担当者がアラートを受理 |
| 3. Investigation | Root cause analysis | 原因特定・影響範囲の確認 |
| 4. Mitigation | Incident mitigated | 応急対応・サービス復旧 |
| 5. Resolution | Incident resolved | 根本原因の解消 |
| 6. Post-mortem | Post-mortem published | 再発防止策の文書化 |
英語例文：
- “When the error budget drops below 50%, the on-call team is notified via PagerDuty.”
- “All SLO violations require a post-mortem within 5 business days.”
- “The incident is considered resolved when the SLI returns to the target range for 30 consecutive minutes.”
テンプレートをダウンロード（Word）
日本語版・英語版をWordファイルで用意した。
ダウンロードしてそのまま使えるフォーマットだ。
日本語版テンプレート（コピペOK）
【英語SLA・SLO設計書】
サービス名：
作成日：
作成者：
レビュー日：
対象期間：
■ 1. SLI定義
SLI名 | 説明 | 成功の定義 | 除外条件 | データソース
-----|------|-----------|---------|----------
| | | |
■ 2. SLO目標
サービス | SLI | SLO目標 | 測定期間 | エラーバジェット
--------|-----|---------|--------|-------------
| | | |
エラーバジェット計算：
・月間許容ダウンタイム：
・消費50%時のアクション：
・消費100%時のアクション：
■ 3. SLA条件と補償規定
可用性ティア | 目標 | 月間許容ダウンタイム
----------|------|----------------
| |
補償規定（Service Credits）：
未達率 | 補償額
------|------
|
対象外条件：
・
■ 4. モニタリングと障害対応
監視項目 | ツール | 頻度 | アラート閾値
--------|--------|-----|----------
| | |
インシデント対応フロー：
1. Detection：
2. Acknowledgment：
3. Investigation：
4. Mitigation：
5. Resolution：
6. Post-mortem：英語版テンプレート（コピペOK）
[SLA / SLO Design Document]
Service Name:
Date:
Author:
Review Date:
Target Period:
■ 1. SLI Definition
SLI Name | Description | Success Criteria | Exclusions | Data Source
---------|-------------|-----------------|------------|------------
| | | |
■ 2. SLO Targets
Service | SLI | SLO Target | Measurement Window | Error Budget
--------|-----|-----------|-------------------|------------
| | | |
Error Budget Policy:
• At 50% consumed:
• At 75% consumed:
• At 100% consumed:
■ 3. SLA Terms & Compensation
Availability Tier | Target | Monthly Allowance
-----------------|--------|------------------
| |
Service Credits:
Downtime Range | Credit
---------------|-------
|
Exclusions:
•
■ 4. Monitoring & Incident Response
Metric | Tool | Frequency | Alert Threshold
-------|------|-----------|----------------
| | |
Incident Response Flow:
1. Detection:
2. Acknowledgment:
3. Investigation:
4. Mitigation:
5. Resolution:
6. Post-mortem:英語SLA・SLO設計書で使えるフレーズ20選
SLI・SLO定義に使うフレーズ
| 日本語 | 英語 |
|---|---|
| 成功リクエストの割合を測定します | The SLI measures the proportion of successful requests |
| 計画メンテナンスは除外します | Planned maintenance windows are excluded from SLI calculations |
| p99レイテンシでテール遅延を測定します | We measure latency at the p99 percentile to capture tail latency |
| SLOはSLAより厳しく設定します | The SLO is set stricter than the SLA to provide a safety buffer |
エラーバジェットの説明フレーズ
| 日本語 | 英語 |
|---|---|
| 月間エラーバジェットは〜分です | The monthly error budget corresponds to ~ minutes of downtime |
| エラーバジェットを消費したらリリースを停止します | When the error budget is exhausted, new releases are paused |
| エラーバジェット消費率50%で調査を開始します | At 50% budget consumption, we initiate a root cause investigation |
| 信頼性改善を最優先にします | We prioritize reliability improvements over new feature releases |
SLA条件・補償を説明するフレーズ
| 日本語 | 英語 |
|---|---|
| 可用性が〜%を下回った場合、補償クレジットが発生します | If uptime falls below ~%, the customer is eligible for Service Credits |
| サービスクレジットは翌月請求に充当されます | Credits will be applied to the following month’s invoice |
| 不可抗力は対象外です | Force majeure events are excluded from SLA obligations |
| 72時間前通知済みのメンテナンスは除外します | Maintenance with 72-hour advance notice is excluded from SLA |
インシデント対応に使うフレーズ
| 日本語 | 英語 |
|---|---|
| SLO違反時はポストモーテムが必要です | All SLO violations require a post-mortem within 5 business days |
| 30分間の連続復旧でインシデントクローズです | The incident is resolved when the SLI returns to target for 30 consecutive minutes |
| オンコールチームにアラートを送信します | The on-call team is notified via PagerDuty when the error budget drops below 50% |
| 根本原因を特定し再発防止策を文書化します | We identify the root cause and document preventive measures |
信頼性KPIの測定基準を明確にするには、SLA・SLO設計書との連携が有効だ。英語エンジニアリングKPI設計書の書き方も合わせて整備することで、SLO達成率KPIの運用体制が明確になる。
まとめ：英語SLA・SLO設計書は4つのセクションで完成する
英語SLA・SLO設計書のポイントをまとめる。
- SLI Definition：何を測定するか・成功の定義・除外条件を明確にし、測定の曖昧さをなくす
- SLO Targets：SLIに対する目標値とエラーバジェットを設定し、信頼性の目標を数値化する
- SLA Terms & Compensation：顧客との合意条件・補償規定・対象外条件を文書化する
- Monitoring & Incident Response：SLOの継続監視とエラーバジェット消費時のアクションを定義する
SLAとSLOの違いで最も重要なのは「バッファ」の考え方だ。SLOをSLAより厳しく設定することで、SLA違反前に問題を検知・対応できる。このバッファがエラーバジェットとして機能し、信頼性と機能開発のバランスを取る仕組みになる。
障害発生時の対応記録を体系化するには、ポストモーテムとRunbookの整備が欠かせない。
英語ポストモーテムの書き方と合わせて、SLO違反時の学習サイクルを確立してほしい。
SLO違反時の障害対応を標準化するには、Runbookが有効だ。
英語Runbookの書き方も合わせて整備することで、インシデント対応の属人化を防ぎ、SLO回復までの時間を短縮できる。
コメント