SLAの例とテンプレート

著者: Linh Ngo · 更新日: 2026年9月8日

SLAのテンプレートを探している人の多くは、SLAとは何かを学びたいわけではありません。3週間後に更新を控えている、誰も合意していない期限を守れずにいるサービスデスクがある、あるいは、見事な稼働率の数字は載っているものの、その稼働率をどう測るかが定義されていない取引先との契約書がある、といった状況です。金曜日までに文書が必要なのです。

そこでこのページは、成果物のライブラリとして、よくある5つのケースのテンプレートと実例を、約束に意味を持たせる測定ルールとともに用意しました。測定ルールのない目標は、数字を添えただけの願望です。

重要なポイント：参考にしたいSLAのベンチマーク

• Amazon は、EC2について、リージョンレベルで月間稼働率99.99%、単一インスタンスで99.5%を約束しており、対象料金の10%、30%、または100%のクレジットを提供します（AWS Compute SLA、2022年5月25日）。
• Google Cloud は、複数ゾーンのCompute Engineインスタンスで99.99%、単一インスタンスで99.9%を約束していますが、クレジットを受け取るには、顧客が60日以内に請求しなければなりません（Google Compute Engine SLA）。
• Microsoft は、Azureのサポートの約束を稼働率ではなく重大度別に示しています。Standardプランでは、Severity Aは24x7で1時間未満、Severity Cは8営業時間未満です（Azure support）。
• 回答者の57%が、直近の大規模な障害のコストは10万ドルを超えたと答え、5分の1は100万ドルを超えると答えました（Uptime Institute、2026年）。
• SLAとは、含まれるSLOを達成した（または未達だった）場合の結果を盛り込んだ契約です（Google SRE Book）。

SLAの構成を条項ごとに解説

使えるSLAは、どれも同じ12の問いに答えています。そのうち4つか5つを飛ばしたテンプレートは、すぐに署名されますが、あとで揉めます。

このページの範囲

関連ページであるSLAとは何か、社内SLAの設定方法は、概念を扱っています。定義、3つの古典的な種類、合意のための5ステップの方法です。このページでは、代わりに条項と数字をお渡しします。1つのケースだけは、意図的に繰り返していません。マーケティングと営業の双方向の合意は、すでにマーケティングと営業のSLAテンプレートがあります。

条項チェックリスト

最も省略されやすい3つは、測定方法、報告、解約の条件で、これらが合意に実効性があるかどうかを決めます。曖昧な条項がそれぞれ何に化けるかは、あとのセクションで挙げます。

SLA、SLO、SLI、OLA、下請契約

会議では5つの用語が区別なく使われますが、書面上は意味が異なります。

Google の SRE の実践は、取り入れる価値のあるテストを提案しています。目標が未達だった場合に何が起きるかを問い、「明示的な結果がなければ、ほぼ間違いなくSLOです」。また、完璧な数字を求めることも戒めており、SLOが100%の時間で達成されることを求めるのは「非現実的であり、望ましくもありません」（Google SRE Book）。

OLAという語彙は ITIL に由来します。ITIL は現在 PeopleCert が発行しており、その現行のスキームは ITIL 4 からITIL バージョン5へ進んでいます。この考え方は、どの版よりも長く生き残ります。頼りにしているデータベースチームが、1日より速い対応に一度も合意したことがないのに4時間での修復を約束すれば、他人のカレンダーを約束したことになります。

SLAが誠実かどうかを決める測定の定義

同じ目標を掲げる2つの組織が、時計のルールだけで、まったく異なる達成率を報告することがあります。誰かが署名する前に、これらを文書で決めておきましょう。

問い	弱い表現	根拠のある表現
時計はいつ開始するか	「リクエストの受領時」	「提供者が顧客のために起票したチケットを含め、チケットが{システム}で作成された時刻」
いつ一時停止するか	記載なし、または「顧客の回答待ちの間」	「チケットが顧客対応待ちの間のみとし、停止した時間は別に報告する」
営業時間か、暦の時間か	「4時間以内」	「4営業時間以内。営業時間とは、{タイムゾーン}の月曜から金曜の9:00から18:00で、{祝日カレンダー}を除く」
解決とは何か	「チケットのクローズ」	「サービスが復旧し、依頼者が確認したこと。回避策が認められるのはP3とP4のみ」
再オープンはどう数えるか	記載なし	「日以内に再オープンされたチケットは元の時計に戻り、以前のクローズは達成とみなさない」
どれだけの割合が遵守すべきか	「すべてのチケット」	「暦月ごとに、その月に作成されたすべてのチケットのうち、P1の95%、P2の90%」

そのうち3つが、ほとんどの議論を決めます。一時停止のルールは、達成率の数字に対する最大のてこです。チケットを顧客対応待ちに置いて自分たちの時計を止められるチームは、どんな目標を設定しても達成できるからです。営業時間は、表の中のあらゆる数字を変えます。9:00から18:00の暦で4営業時間とは、金曜の17:30に依頼が届いた場合、実時間ではほぼ24時間です。そして再オープンは、解決の数字を良く見せます。顧客が1時間後に再オープンしたクローズは、達成された目標1件と新しいチケット1件として数えられるからです。再オープン率は、独立したプロセスKPIとして追跡してください。

稼働率にも同じ注意が必要です。Google の Compute Engine SLA は、「1分以上連続するダウンタイムの期間」だけを数えるため、「1分未満の部分的な分や断続的なダウンタイムは数えられません」（Google Compute Engine SLA）。サービスが月中ずっと、50秒ずつ不安定になっても、完璧な稼働率を報告できてしまいます。

稼働率の計算：9が1つ増えるごとのコスト

稼働率のパーセンテージは実感しにくいものですが、分数なら実感できます。以下のすべての数値は、（1から稼働率のパーセンテージを引いた値）に期間の長さを掛けたもので、30日の月と365日の年を使っています。

交渉では、2つの差が重要です。99.5%と99.9%の間には月に2時間52分48秒があり、チームが落ち着いて対応できる障害と、午後を丸ごと食いつぶす障害の違いになります。99.9%と99.99%の間はわずか38分53秒ですが、この跳躍は通常、マルチゾーン構成と本格的なオンコール体制を要求するので、コストがかかる部分です。

ほとんどのSLAは暦月で測定するため、許容量も月によって変わります。99.9%の場合、同一の約束でも、2月は40分19秒、31日の月は44分38秒です。

テンプレート1：ITサービスデスクのインシデントSLA

多くの組織が最初に必要とするテンプレートであり、実際に機能する部分である優先度マトリクスを抜きにして最もよくコピーされるものでもあります。優先度は、依頼者が選ぶ項目ではありません。影響度と緊急度から導き出されるため、2人の人が同じ障害を異なる等級に分類することはできません。

初動対応と解決は別々の約束であり、1つの数字にまとめてはいけません。初動対応とは、人間がチケットの担当となり、それを表明する時点のことで、解決とはサービスが復旧することです。チームが一方は優秀でも、もう一方は絶望的ということはあり得ますし、まとめた数字はそれを隠します。

これらの数字は出発点であり、鵜呑みにしてコピーするベンチマークではありません。Microsoft は、Standardプラン以上でSeverity A（「サービスの著しい喪失または劣化」）に24x7で1時間未満、Severity Cに8営業時間未満を約束しています（Azure support responsiveness）。これが何であるかに注意してください。解決ではなく、最初の対応です。

インシデント管理SLA、{提供者}から{顧客}へ 1. 範囲。 {名称を明記したシステム}のインシデント対応。依頼、変更、プロジェクト作業は{別の文書}に記載する。 2. サービス時間。 P1とP2は24x7で対応する。P3とP4は、{タイムゾーン}の月曜から金曜の9:00から18:00とし、{祝日カレンダー}を除く。 3. 優先度。 トリアージ時に、{役割}が上記のマトリクスから割り当てる。再評価しても時計はリセットされない。 4. 目標値。 上記の初動対応と解決の表のとおり。 5. 測定。 時間は、チケット作成時点から{チケット管理システム}で計測する。時計は、チケットが顧客対応待ちの間のみ停止し、停止した時間は別に報告する。 6. 解決。 サービスが復旧し依頼者が確認した場合、または異議なく2営業日が経過した場合。P1とP2では、回避策は解決とみなさない。 7. 再オープン。 5営業日以内に再オープンされたチケットは、元の時計を再開する。 8. 除外事項。 営業日前に通知された計画メンテナンス、顧客が管理するシステムまたは付録Aに記載されたサードパーティに起因するインシデント、{提供者}の合理的な支配が及ばない事象。 9. 報告。 優先度別の達成率、再オープン率、繰り返し発生する上位3つの原因を、毎月5営業日目までに公表する。 10. エスカレーション。 解決目標の50%の時点で未解決のP1は{役割}へ、100%の時点では{上級の役割}へエスカレーションし、後者はクローズまで顧客とのコミュニケーションを担う。 11. レビュー。 四半期ごとに、{役割}が出席して実施する。目標値は、書面による合意によってのみ変更する。 12. 繰り返しの不履行。 3か月連続でP1のしきい値を下回った場合、サービス改善計画を発動する。

条項8には、一つのルールがあります。すべての除外事項に、名前が付けられ、検証可能でなければならないということです。「不可抗力」は標準的ですが、「顧客環境の複雑さに起因する問題」は逃げ道です。

テンプレート2：カスタマーサポートSLA

サポートのSLAは、振る舞いが異なります。満足度を最も左右する数字は、解決時間ではなく、会話が始まってから返信の間にある待ち時間である次の返信までの時間です。初回対応の目標を達成していても、2回目の返信に2日かかったために顧客を苛立たせているチームは、数多くあります。チャネルも違うため、チャットとメールにまたがる一つの平均的な目標は、どちらかで約束しすぎることになります。

カスタマーサポートSLA、{会社}から{顧客ティア}へ 1. 対象チャネル。 {チャット、メール、電話、アプリ内}。ソーシャルメディアとコミュニティフォーラムは、約束なしのベストエフォートとする。 2. 初回対応とは、具体的な問題に対応する、人間による実質的な返信を指す。自動の受領通知は、この条項を満たさない。 3. 次の返信とは、会話が継続中で{会社}の対応待ちである間の、その後の各返信を指す。 4. 時計のルール。 時間は、メッセージが{サポートプラットフォーム}に届いた時点から計測し、会話が顧客対応待ちの間のみ停止する。顧客対応待ちが日続いた会話は自動的にクローズされ、いかなる返信でも再オープンされて、元の時計を再開する。 5. 達成率。 平均ではなく、{90}パーセンタイルで毎月測定する。 6. エスカレーションと報告。 解決目標の倍を超えて開いている会話は{役割}へ回し、毎週のレビューに加える。チャネルごとの達成率、再オープン率、時間を超えて違反している会話を、毎月公表する。 7. 除外事項。 付録Aに記載されたサードパーティ連携、カスタム開発の依頼、告知済みのメンテナンス。

そこでの2つの選択は、意図的なものです。平均ではなくパーセンタイルを使うことで、あらゆる苦情の原因となる1週間経った会話が、平均に隠されるのを防ぎます。自動応答を初回対応から除外することで、サポートSLAがごまかされる最も一般的な手口を塞ぎます。

例3：社内共有サービスのSLAと、その背後にあるOLA

社内SLAは、最も簡単な手続きで書かれ、最も頻繁に破られます。財務、人事、法務、ITは、契約も、クレジットも、代わりの供給元もない顧客にサービスを提供するため、強制力は、可視化とレビュー会議だけです。

右端の列にあるすべての目標は、それを引き受けたチームの外にいる誰かに依存しており、これはまさに運用レベルアグリーメントが扱うものです。OLAがなければ、目に見えるSLAを抱えるチームが、上流のあらゆる遅れを吸収し、その目標を信じなくなります。

2つ目の対策は、完全な依頼を定義することです。社内の違反の多くは、作業が遅いのではなく、予算コードのないまま依頼が届いたために、作業の開始が遅れたものです。その定義を標準作業手順書に盛り込み、依頼がそれを満たすまで時計を止め、達成率の数字の隣に不完全な提出の件数を報告してください。

フローが部門をまたぐ場合は、まず地図にします。業務プロセスマップは引き渡しとキューを示し、サイクルタイムとリードタイムの差は、その目標が作業を測っているのか、待ちを測っているのかを教えてくれます。署名済みの合意書は、スライド資料ではなく、プロセス文書と一緒に保管してください。

例4：買い手側から書くベンダーSLA

ベンダーSLAは、あらかじめ書かれた状態で届き、サプライヤーに有利なように最適化されています。寛大な除外事項、誰も請求しないクレジット、そして測定する当事者自身が書いた測定の定義です。

交渉の資本を使う価値のある条項が2つあります。1つ目は、慢性的な不履行のトリガーです。「連続する6か月の間に稼働率の約束を3回違反した場合、または1か月でも95%を下回った場合、{顧客}は違約金なしで解約できる」といったものです。四半期ごとに未達を繰り返し、そのたびにクレジットを払っているベンダーは、あなたの許容度を取引の価格に織り込んでいます。2つ目は、除外事項の上限です。計画メンテナンスは、上限があり、通知され、ベンダーの営業時間ではなく自社の営業時間外である場合にのみ正当だからです。

例5：クラウドの稼働率SLA。買い手が読むべき読み方で読む

クラウドのSLAは、主要プロバイダーが全文を公開しているため、最良の実例になります。Amazon の EC2の約束は、2022年5月25日に最終更新されたもので、リージョンレベルで月間稼働率99.99%（複数のアベイラビリティゾーンにまたがるインスタンスを意味します）、単一インスタンスで99.5%です。クレジットの段階は、どちらも同じです。

これらの約束を、上の計算に当てはめてみましょう。リージョンレベルの99.99%は、30日の月で4分19秒を許容し、インスタンスレベルの99.5%は3時間36分を許容します。同じページにある2つの数字の間に50倍の差があり、それは完全にアーキテクチャの問題です。1つのゾーンで稼働させれば、弱いほうの約束を買ったことになります。

AWS は、他の場面でもベンチマークとして使う価値のあることも行っています。「1時間のうち6分を超えて利用できなかった単一のEC2インスタンスには料金を請求せず」、これは「自動的に適用され、クレジットを請求する必要はありません」。Google の Compute Engine SLAは、Premiumティアの複数ゾーンのインスタンスで99.99%、ほとんどのマシンファミリーの単一インスタンスで99.9%を約束しており、中間帯の25%はより手厚くなっています。落とし穴は請求です。「顧客は、財務クレジットを受け取る資格を得た時点から60日以内に、Googleのテクニカルサポートに通知しなければなりません」。

したがって、見出しの数字より先に測定の定義を比較し、救済措置が自動なのか請求制なのかを確認し、すべてのパーセンテージを分数に換算しましょう。

サービスクレジットが損失をほとんど補填しない理由

クレジットは補償のように読めますが、ガバナンス上のシグナルとして機能します。AWS の SLA では、クレジットは「Amazon EC2の将来の支払いにのみ適用でき」、「AWSからの返金やその他の支払いを受ける権利は生じません」。Google のクレジットも、将来の請求に充当されます。どちらの契約も、これが唯一の救済措置であることを明示しています。AWS は「お客様の唯一かつ排他的な救済措置を定めて」おり、Google の契約は「顧客の唯一かつ排他的な救済措置を述べて」います。

では、それを損失と並べてみましょう。Uptime Institute の2026年の障害分析によると、「回答者の57%が、直近の大規模な障害のコストは10万ドルを超えたと答え」、「2年連続で、5分の1が100万ドルを超えるコストを報告した」とされています（Uptime Institute）。影響を受けた月の料金に対する10%のクレジットは、次の請求書へのささやかな値引きです。この計算は、つり合うようにできていません。

したがって、クレジットは保険ではなく、シグナルとして扱ってください。数字に意味のあるパーセンテージを賭けようとしないサプライヤーは、その数字を信じていません。本当の保護は別のところにあります。冗長化、事業継続の取り決め、慢性的な不履行に対する解約の権利です。

現実に耐えるSLAをつくる

署名されたSLAは、それだけでは何も変えません。実効性のある合意には、4つの習慣があります。

合意ごとに1人の責任者を置きます。 委員会ではなく、報告の公表とレビューの議長を職務に含む一人の人です。責任者のいないSLAは、静かに劣化します。更新のときまで、違反しても誰も何のコストも負わないからです。

数字を、仕事が行われる場所に置きます。 共有ドライブの奥に埋もれた目標は、重要な瞬間、つまり誰かが次のチケットを選ぶときに見えません。キューの表示やチームのボードは、ごく普通の目で見る管理であり、誰にも見えないSLAは、誰にも守られないSLAです。

気分ではなく、トリガーでエスカレーションします。 アンドンの論理を借りましょう。しきい値を超えたらシグナルが発され、指名された人が対応します。解決目標の50%に達したP1は、エンジニアが状況が悪いと思っているかどうかにかかわらず、当番マネージャーを呼び出すべきです。

違反は、責任追及ではなく原因のためにレビューします。 繰り返し起こるものには根本原因分析を実施し、それぞれの対策をPDCAサイクルで検証します。常設のプロセス監視がそれを可能にします。誰も計装していないものは、レビューできないからです。同じ手作業のステップが毎月同じ遅れを引き起こしている場合は、目標を再交渉するより、受付やルーティングのワークフロー自動化のほうが早く元が取れます。また、プロセスの標準化は、1つのSLAが3つの地域で3通りの意味を持つのを防ぎます。

SLAが形骸化する経緯

形骸化したSLAの多くは、同じいくつかの経緯をたどって死んでいます。

• 誰も測定していない目標。 その数字を自動的に生成するシステムがなければ、その数字は存在しません。
• 約束を飲み込む除外事項。 無制限のメンテナンス、際限のない「顧客起因の遅延」、ルールのない一時停止のステータスは、見出しに触れることなく、99.9%の約束を骨抜きにします。
• 責任者もレビュー日もない。 どちらも、付録ではなく、署名欄に入れるべきものです。
• パーセンタイルではなく平均。 平均は裾野を隠し、苦情を生むのはその裾野です。
• より大きな会社からコピーした目標。 オンコール体制なしの15分のP1初動対応は、何の意味もありません。
• 背中合わせの合意がない約束。 何にも合意していないチームに依存する約束は、他人の口座に対する小切手です。

自分に合うテンプレートを選んで、括弧内の値を埋め、そのあとは測定方法と除外事項に本当の労力を費やしてください。この2つの条項が、合意が初めて試される月にその意味を決めます。