ベンダーや社内IT部門と英語でSLAを締結するとき、「何をどう書けばいいか分からない」と迷うエンジニアは多い。グローバルプロジェクトでは可用性目標・応答時間・障害復旧目標・ペナルティ条項を英語で定義したSLAが、サービス品質の合意と責任の所在を明確にする前提条件となる。
この記事では、ITプロジェクトで実際に使える英語SLAの書き方を解説する。フレーズ20選・日英Wordテンプレートもセットで用意した。コピペしてすぐに使える。
英語SLAを整備すると、「障害が起きたとき誰が何時間以内に対応するか」がチーム全員に共有され、対応遅れとベンダーとの認識ずれを防げる。さっそく構成と書き方を確認しよう。
英語SLAとは何か・なぜ必要か
SLA（Service Level Agreement）とは、サービス提供者と利用者の間で合意したサービス品質の基準を文書化した合意書だ。可用性・応答時間・障害復旧目標・ペナルティなどを数値で定義し、双方が品質要件を共有する根拠として機能する。
英語では “SLA” が一般的だが、”Service Level Agreement” “Service Agreement” とも記載される。ITサービス管理（ITSM）・クラウド契約・ベンダー管理の現場で広く使われる。
SLA・OLA・UCの違い
SLAと混同されやすい概念が2つある。OLA（Operational Level Agreement）は社内の異なる部門間で結ぶ内部合意書だ。UC（Underpinning Contract）は外部ベンダーとの契約書で、SLAを支える下位契約として機能する。
グローバルチームで外部ベンダーと品質を合意する文書がSLAだ。社内IT部門同士の合意ならOLAを使い分けるのが正確だ。
SLAがないと何が起きるか
SLAなしでサービスを運用すると、「応答時間が遅い」「障害復旧に時間がかかりすぎる」というクレームに対して、合意した基準がないため責任の所在が曖昧になる。特にグローバルチームでは、時差・言語・チーム文化の違いがあり、口頭での合意は機能しない。
SLAを整備することで、サービス品質の透明性・問題発生時の判断基準・ベンダー評価の根拠が同時に確保できる。
ITSMフレームワーク全体でのSLA設計は、【例文あり】エンジニアの英語ITSM術｜SLA設計・インシデント管理・KPI報告フレーズ30選も合わせて参考にしてほしい。
英語SLAの7つの必須セクション（日英対訳）
英語SLAは7つのセクションで構成するのが基本だ。
1. サービス定義（Service Definition）
SLAの対象サービス・対象システム・サービス利用者・提供者・契約期間を記載するセクションだ。「このSLAが何に適用されるか」を最初に定義することで、スコープ外の問題でSLAが引用される事態を防げる。
2. 可用性・稼働率目標（Availability Target）
サービスの稼働率目標（例：99.9%）・計画メンテナンス時間・稼働率計算方法を記載するセクションだ。稼働率の計算式と計測期間を明記しないと、ダウンタイムの認定で双方の解釈が食い違う。
3. 応答時間・復旧目標（Response Time / RTO / RPO）
インシデント発生時の初回応答時間・復旧目標時間（RTO）・目標復旧時点（RPO）を優先度別に定義するセクションだ。「Critical障害は30分以内に応答、4時間以内に復旧」のように、優先度ごとに数値を設定する。
4. インシデント優先度と対応時間（Incident Priority & Response Time）
インシデントの優先度定義（Critical/High/Medium/Low）と、各優先度の応答時間・解決目標時間を一覧化するセクションだ。優先度の定義がないと、障害発生時に「これはCriticalか」でチームが判断を迷う。
5. ペナルティ・クレジット条項（Penalty / Service Credit）
SLA目標を達成できなかった場合の補償内容（サービスクレジット・返金・割引）を定義するセクションだ。ペナルティの計算方法・上限額・適用条件を明記することで、SLAが「努力目標」ではなく「契約上の義務」として機能する。
6. レビュー・改定サイクル（Review & Revision）
SLAの定期レビュー頻度・改定手続き・変更通知期間を記載するセクションだ。システム構成やビジネス要件の変化に合わせて、SLAを定期的に見直す仕組みを最初から組み込んでおく。
7. 除外条項（Exclusions）
SLAの対象外となる条件（天災・第三者起因の障害・計画メンテナンス・利用者側の操作ミス）を明記するセクションだ。除外条項がないと、SLA対象外の事象でペナルティを求められるリスクがある。
テンプレートをダウンロード（Word）
以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。
📥 日本語テンプレートをダウンロード（Word（空白版））
📥 Download English Template (Word – Blank)
📥 日本語サンプルをダウンロード（ECサイト クラウドインフラ運用）
📥 Download Sample in English (E-Commerce Cloud Infrastructure)
日本語版テンプレート（コピペOK）
以下をコピーして、プロジェクトのSLAとしてそのまま使える。
# サービスレベル合意書（SLA）
**サービス名：** 〇〇サービス
**提供者：** 〇〇株式会社
**利用者：** 〇〇株式会社
**有効期間：** 2026年〇月〇日〜2027年〇月〇日
**作成日：** 2026年〇月〇日
---
## サービス定義
- 対象サービス：〇〇（概要・スコープ）
- 対象システム：〇〇
- 対象外：〇〇（明示的に除外するサービス・システム）
---
## 可用性・稼働率目標
| 指標 | 目標値 | 計測期間 | 計算方法 |
|------|--------|---------|---------|
| 稼働率 | 99.9%以上 | 月次 | （稼働時間÷契約時間）×100 |
| 計画メンテナンス | 月4時間以内 | 月次 | 事前通知（7日前）必須 |
---
## 応答時間・復旧目標（RTO/RPO）
| 優先度 | 初回応答時間 | 復旧目標時間（RTO） | 目標復旧時点（RPO） |
|--------|------------|-----------------|-----------------|
| Critical | 30分以内 | 4時間以内 | 1時間以内 |
| High | 2時間以内 | 8時間以内 | 4時間以内 |
| Medium | 翌営業日 | 3営業日以内 | 24時間以内 |
| Low | 3営業日以内 | 5営業日以内 | 対応時点 |
---
## インシデント優先度定義
| 優先度 | 定義 | 例 |
|--------|------|-----|
| Critical | サービス全停止・売上直接影響 | 決済機能停止・DB障害 |
| High | 主要機能の部分停止・回避策なし | ログイン不可・API障害 |
| Medium | 機能は動作するが著しく劣化 | 応答遅延・一部機能エラー |
| Low | 軽微な不具合・業務影響なし | 表示崩れ・誤字 |
---
## ペナルティ・サービスクレジット
| 稼働率 | クレジット（月額費用の〇%） |
|--------|--------------------------|
| 99.0〜99.9%未満 | 10% |
| 95.0〜99.0%未満 | 25% |
| 95.0%未満 | 50% |
※クレジットの上限は月額費用の50%とする。除外条項に該当する場合は適用外。
---
## レビュー・改定サイクル
- 定期レビュー：四半期ごと（〇月・〇月・〇月・〇月）
- 改定手続き：変更30日前に書面で通知し、双方合意のうえ改定
- 緊急改定：重大なシステム変更が発生した場合は随時協議
---
## 除外条項
本SLAは以下の事象に起因するダウンタイムには適用しない。
- 天災・自然災害・不可抗力による障害
- 利用者側のシステム・ネットワーク障害
- 第三者サービス（CDN・外部API等）の障害
- 事前通知済みの計画メンテナンス
- 利用者の操作ミス・設定誤りに起因する障害英語版テンプレート（コピペOK）
以下をコピーして、グローバルチームのSLAとしてすぐに使える。
# Service Level Agreement (SLA)
**Service Name:** [Service Name]
**Provider:** [Provider Company Name]
**Customer:** [Customer Company Name]
**Effective Period:** [Start Date] - [End Date]
**Date:** [Date]
---
## Service Definition
- Covered Services: [Description and scope]
- Covered Systems: [System Name]
- Exclusions: [Services or systems explicitly out of scope]
---
## Availability Target
| Metric | Target | Measurement Period | Calculation Method |
|--------|--------|-------------------|--------------------|
| Uptime | 99.9% or above | Monthly | (Uptime / Total contracted hours) x 100 |
| Planned Maintenance | Up to 4 hours/month | Monthly | Prior notice required (7 days in advance) |
---
## Response Time and Recovery Targets (RTO / RPO)
| Priority | Initial Response | Recovery Time Objective (RTO) | Recovery Point Objective (RPO) |
|----------|-----------------|-------------------------------|-------------------------------|
| Critical | Within 30 min | Within 4 hours | Within 1 hour |
| High | Within 2 hours | Within 8 hours | Within 4 hours |
| Medium | Next business day | Within 3 business days | Within 24 hours |
| Low | Within 3 business days | Within 5 business days | At time of resolution |
---
## Incident Priority Definitions
| Priority | Definition | Examples |
|----------|------------|---------|
| Critical | Full service outage; direct revenue impact | Payment failure, DB outage |
| High | Key feature unavailable; no workaround | Login failure, API outage |
| Medium | Feature degraded but operational | Slow response, partial errors |
| Low | Minor issue; no business impact | UI issue, typo |
---
## Penalties and Service Credits
| Uptime Achieved | Service Credit (% of Monthly Fee) |
|----------------|----------------------------------|
| 99.0% - below 99.9% | 10% |
| 95.0% - below 99.0% | 25% |
| Below 95.0% | 50% |
Credits are capped at 50% of the monthly fee. Credits do not apply if the outage falls under the Exclusions clause.
---
## Review and Revision
- Scheduled Review: Quarterly ([Month], [Month], [Month], [Month])
- Revision Process: Written notice 30 days in advance; effective upon mutual agreement
- Emergency Revision: Ad hoc discussion in the event of significant system changes
---
## Exclusions
This SLA does not apply to downtime caused by:
- Natural disasters, acts of God, or force majeure events
- Failures in the Customer's systems or network infrastructure
- Outages in third-party services (CDN, external APIs, etc.)
- Pre-announced planned maintenance windows
- Incidents caused by Customer misconfiguration or operator error英語SLAで使えるフレーズ20選
SLAを作成するとき・ベンダーと品質要件を交渉するときに使える表現を場面別にまとめた。
稼働率・可用性を定義するとき
| 日本語 | 英語フレーズ |
|---|---|
| 本サービスの稼働率目標は月次99.9%以上とする | The uptime target for this service is 99.9% or above, measured on a monthly basis |
| 稼働率は「稼働時間÷契約時間×100」で計算する | Uptime is calculated as (actual uptime / total contracted hours) x 100 |
| 計画メンテナンスはダウンタイムの計算から除外する | Planned maintenance windows are excluded from downtime calculations |
| メンテナンスは7日前までに書面で通知する | Maintenance windows must be communicated in writing at least 7 days in advance |
| 稼働率が目標を下回った場合、サービスクレジットが発生する | If the uptime target is not met, service credits will be applied as defined in this agreement |
対応時間・復旧目標を伝えるとき
| 日本語 | 英語フレーズ |
|---|---|
| Critical障害の初回応答時間は30分以内とする | The initial response time for Critical incidents is within 30 minutes of detection |
| 復旧目標時間（RTO）はCritical障害で4時間以内だ | The Recovery Time Objective (RTO) for Critical incidents is 4 hours |
| 目標復旧時点（RPO）は最大1時間のデータロスとする | The Recovery Point Objective (RPO) is set at a maximum data loss of 1 hour |
| インシデントの優先度はビジネス影響度にもとづいて分類する | Incidents are classified by priority based on the level of business impact |
| 対応時間の計測は障害検知時刻から開始する | Response time measurement begins from the moment the incident is detected |
ペナルティ・クレジットを交渉するとき
| 日本語 | 英語フレーズ |
|---|---|
| SLA目標未達の場合、月額費用の10%をクレジットする | If the SLA target is not met, a service credit of 10% of the monthly fee will be applied |
| クレジットの上限は月額費用の50%とする | Service credits are capped at 50% of the applicable monthly fee |
| クレジットは次回請求時に自動的に適用される | Credits will be automatically applied to the next billing cycle |
| 除外条項に該当する事象はSLA違反として扱わない | Incidents falling under the Exclusions clause will not be considered SLA breaches |
| ペナルティ条項は双方合意のもと改定できる | The penalty clause may be revised by mutual written agreement of both parties |
レビュー・改定を依頼するとき
| 日本語 | 英語フレーズ |
|---|---|
| 本SLAは四半期ごとに見直しを行う | This SLA is subject to a quarterly review by both parties |
| SLAの改定は30日前の書面通知を必要とする | Any revision to this SLA requires written notice at least 30 days in advance |
| システム構成の変更があった場合は随時協議する | In the event of significant system changes, both parties will negotiate revisions as needed |
| 直近四半期のSLA達成率をレビュー会議で報告する | SLA compliance for the previous quarter will be reported at the review meeting |
| 本SLAは双方署名をもって発効する | This SLA becomes effective upon signature by both parties |
ベンダー選定・契約時のSLA交渉は、【例文あり】エンジニアの英語アウトソーシング術｜RFP・SLA交渉・ベンダー管理フレーズ30選も参考にしてほしい。
英語SLAを書くときの3つのコツ
① 稼働率の計算方法を必ず定義する
「稼働率99.9%」と書くだけでは不十分だ。計測期間（月次・年次）・計算式・ダウンタイムの定義（検知時刻か報告時刻か）・計画メンテナンスの扱いを明記する。計算方法が曖昧だと、達成・未達の判定でベンダーと認識がずれ、クレジット適用の議論が紛糾する。
② インシデント優先度はビジネス影響度で定義する
「システムが遅い」と「決済が止まった」は深刻度が異なる。優先度の定義をビジネス影響度（売上影響・利用者数・回避策の有無）で記述することで、担当者が現場でその場の判断をできるようになる。技術的な症状だけで優先度を定義すると、ビジネス側との認識ずれが起きやすい。
③ 除外条項を具体的に列挙する
「不可抗力による障害を除く」という曖昧な記述は、のちに解釈で揉める原因になる。第三者サービスの障害（CDN・外部決済API等）・計画メンテナンス・利用者の操作ミスを個別に列挙する。除外条項が具体的であるほど、SLA違反を巡る不要な交渉コストを削減できる。
障害発生時の対応手順はRunbookとセットで整備すると完結する。【テンプレあり】英語Runbookの書き方｜ITプロジェクトで使える日英フォーマット付きも合わせて参考にしてほしい。
本番リリース後の負荷増大に備えたキャパシティ計画は、【テンプレあり】英語キャパシティ計画書の書き方｜ITプロジェクトで使える日英フォーマット付きも活用してほしい。
SLAと合わせてキックオフ議事録を整備することで、プロジェクト開始時の品質合意も文書化できる。【テンプレあり】英語キックオフ議事録の書き方｜ITプロジェクトで使える日英フォーマット付きも参考にしてほしい。
SLAと合わせてコミュニケーション計画書を整備することで、サービス品質の合意と報告体制が一体化する。【テンプレあり】英語コミュニケーション計画書の書き方｜ITプロジェクトで使える日英フォーマット付きも参考にしてほしい。
まとめ：英語SLAでサービス品質の合意を文書化する
英語SLAの要点は3つだ。
- 7セクションで構成：サービス定義・可用性目標・応答時間/RTO/RPO・インシデント優先度・ペナルティ・レビューサイクル・除外条項
- 稼働率の計算方法とインシデント優先度をビジネス影響で定義する：曖昧な記述は達成・未達の認定で揉める原因になる
- 除外条項を具体的に列挙する：第三者障害・計画メンテナンス・利用者ミスを個別に記載することで不要な交渉を防ぐ
SLAをプロジェクト標準として整備することで、「障害が起きたとき誰が何時間以内に対応するか」がチーム全員に共有され、ベンダーとの認識ずれと対応遅れを防げる。Wordテンプレートを活用して、今すぐ自チームのSLAを作ってみてほしい。
コメント