SLAとは何か｜アウトソーシング契約で失敗しない2026年版完全ガイド

SLA：サービス・レベル・アグリーメント ― アウトソーシング契約の実務

システム運用を外部へ委託するとき、「安定稼働に努める」「速やかに対応する」だけでは、発注者と提供者の判断基準が揃いません。SLAは、サービスの範囲、品質目標、測定方法、報告、未達時の扱い、改善方法を合意し、契約後の不透明さを減らすための文書です。

本記事は、IPA、NIST、Google SRE、ISO、各クラウド事業者などの公式・一次情報を基に独立して再構成しています。特定企業の資料、サービス又は見解を解説する記事ではありません。

調査・記述方針

SLAの定義と基本構造は、公的機関、標準化機関及びサービス提供者の公式資料を相互に照合しました。各社固有のSLA条件は一般原則と分け、契約時には必ず対象サービスの最新規約を確認する前提で整理しています。

本記事で得られる3つのポイント

  1. SLA・SLI・SLO・OLAの違いと、2026年時点のITIL／ISOの位置づけが分かります。
  2. 可用性の計算、停止時間、除外条件、サービスクレジットの落とし穴を判断できます。
  3. アウトソーシング契約へ転用できるSLA項目表と運用チェックリストを使えます。

なぜ重要か：SLAの数字が同じでも、測定範囲と除外条件が違えば、利用者が受け取る実質的な品質は大きく変わるためです。

続きを読む

SLAの定義：公式情報を基にした実務的な整理

SLA（Service Level Agreement）とは、サービス提供者と顧客・利用者が、提供するサービス、そのサービスに求める水準、双方の責任、測定・報告方法及び目標未達時の対応を文書化して合意したものです。

IPAは、SLAをサービス及び合意したサービスレベルを文書化した、サービスプロバイダと顧客間の書面による合意として扱っています。また、サービスレベル管理では、サービスレベルを定義・合意・記録・管理し、目標、作業負荷の限度、例外を含めて監視・レビュー・報告することを示しています。

NISTは、SLAをサービス提供者と顧客の間のコミットメントとして整理し、責任、サービスの種類、信頼性・品質・応答時間などの期待性能、報告、解決及び終了に関する要求事項を含むものとしています。Google SREは、SLIを測定指標、SLOを目標値、SLAをSLOの達成又は未達に伴う結果を含む合意として区別しています。

公式情報 SLAを理解する要点 実務への反映
IPA サービスと合意したサービスレベルを書面化し、定義・合意・記録・管理する 対象、目標、例外、監視、レビュー、報告を明記する
NIST 提供者と顧客の責任、期待性能、報告、解決、終了を含むコミットメント 品質目標だけでなく責任分界と契約終了まで設計する
Google SRE SLIは指標、SLOは目標、SLAは目標未達時等の結果を伴う合意 測定値・目標値・未達時措置を混同せず記載する
AWS公式解説 稼働時間、配信時間、応答時間、解決時間などと未達時の対応を規定する 指標、例外、追跡・報告、見直し、解除を具体化する
本記事での定義SLAは単なる「品質保証の数値表」ではありません。何を、誰が、どの条件で、どのように測り、報告し、未達時にどう対応するかまでを合意する管理文書です。

SLAは単独の契約書として作る場合もありますが、業務委託契約、利用規約、仕様書、サービス記述書などの一部又は別紙として扱うこともあります。文書名だけで判断せず、契約本文との優先順位、変更手続、解除・損害賠償条項との関係が明確かを確認する必要があります。

SLAの目的と双方の効果

観点 委託者・利用者 提供者
範囲 何が提供され、何が対象外かを確認できる 責任範囲と前提条件を限定できる
品質 業務影響に見合う目標を要求できる 必要な人員・設備・運用費を積算できる
測定 主観ではなく記録で評価できる 品質実績と改善効果を説明できる
未達 是正、報告、クレジット等の手続を確保できる 責任の上限と対応手順を予見できる

SLA・SLI・SLO・OLAを混同しない

用語 役割 例
SLI
Service Level Indicator		 実際のサービス品質を測る指標 成功リクエスト率、p95応答時間、復旧時間
SLO
Service Level Objective		 SLIに対して設定する目標値・範囲 月間成功リクエスト率99.9％以上
SLA
Service Level Agreement		 SLO、測定・報告、責任、未達時の扱いを含む合意 未達時に原因報告と利用料10％相当のクレジット
OLA
Operational Level Agreement		 SLAを支える社内組織間の運用合意 監視部門は5分以内に一次判定し、基盤部門へ連携
UC
Underpinning Contract		 外部の再委託先・供給者との下支え契約 回線事業者、データセンター、クラウドとの契約

Google SREでは、SLIを定量的な指標、SLOをその目標値、SLAを目標未達時の結果を伴う合意として区別しています。契約にペナルティがなくてもSLAと呼ばれる場合はありますが、少なくとも「未達時に何をするか」は決めておくべきです。

サービス・レベルの設計：可用性の計算

計算式可用性（％）＝（測定対象時間－対象停止時間）÷ 測定対象時間 × 100

1,000時間を測定対象とし、SLA上の対象となる停止が1時間なら、可用性は (1,000－1)÷1,000×100＝99.9％ です。ただし、計画停止を分母から外すのか、部分障害をどう数えるのかによって結果は変わります。

「9」の数と許容停止時間

可用性目標 30日当たりの停止上限 365日当たりの停止上限 設計上の注意
99.0％ 7時間12分 3日15時間36分 重要業務には長すぎる場合が多い
99.5％ 3時間36分 1日19時間48分 単一構成の水準として見かける
99.9％ 43分12秒 8時間45分36秒 月次評価では1回の障害で未達になり得る
99.95％ 21分36秒 4時間22分48秒 冗長化と迅速な切替が必要
99.99％ 4分19秒 52分34秒 複数ゾーン等の構成条件を伴うことが多い
99.999％ 約26秒 5分15秒 費用と運用難度が急増する

注：単純計算による参考値。実契約では暦月、請求月、営業時間、除外時間等の定義を優先します。

可用性以外の代表的な指標

領域 SLIの候補 定義で決める事項
性能 応答時間、処理時間、スループット 平均値だけでなくp95・p99、測定点、対象取引
障害対応 検知時間、受付時間、一次応答、復旧時間 起算点、重大度、営業時間、保留条件
サービスデスク 応答率、放棄呼率、初回解決率、満足度 対象チャネル、待ち時間、再オープンの扱い
変更 変更成功率、緊急変更率、ロールバック率 成功の定義、除外変更、評価期間
バックアップ 成功率、RPO、RTO、復元テスト成功率 データ範囲、復元地点、テスト頻度
セキュリティ 検知・通知時間、脆弱性是正時間 重大度、起算点、証跡、法令上の通知との関係

平均値だけで契約しない：応答時間の平均は、少数の極端に遅い処理を隠します。利用者体験を評価する指標では、p95又はp99と成功率を組み合わせる方が実務的です。

契約書とSLAの関係

1．基本契約書契約期間、対価、知的財産、秘密保持、解除、損害賠償などを定めます。
2．個別契約・仕様書対象業務、提供範囲、成果物、体制などを具体化します。
3．SLA別紙測定可能な品質水準、測定方法、未達時の対応を合意します。
4．運用手順・報告書日常運用、連絡、証跡、月次評価の方法を定めます。

基本契約書には契約期間、対価、知的財産、秘密保持、個人情報、再委託、解除、損害賠償などを定め、仕様書に対象業務を、SLAに測定可能なサービス水準と運営ルールを置く構成が分かりやすいでしょう。

優先順位を必ず定める

文書間で矛盾した場合の優先順位を定めます。例えば「個別契約書 → SLA別紙 → 仕様書 → 提案書」のように契約で明示します。提案書の華やかな約束だけが独り歩きすると、後で数字が迷子になります。

費用とSLAの関係

サービス水準を上げるほど、冗長設備、監視、当番体制、自動復旧、試験、ログ保管などの費用は一般に増えます。全項目を最高水準にせず、業務影響とリスク許容度から段階を付けます。

判断軸 確認質問 契約・設計への反映
業務影響 1時間止まると売上・安全・法令に何が起こるか 重大度、可用性、RTO/RPO
時間帯 24時間必要か、営業時間だけでよいか サービス時間、保守時間
代替手段 手作業や別システムで継続できるか 目標値と継続計画
費用対効果 追加の「9」にいくら払えるか 構成案別の価格比較

クラウドSLAを読むときの実務ポイント：構成条件で保証水準が変わる

AWSのAmazon EC2 SLAでは、同一リージョンの複数AZへ同時配置した構成に月間99.99％、単一インスタンスに99.5％という別の水準を設定しています。Google Cloud Compute Engineも、Premium Tierの複数ゾーン構成と単一インスタンスで水準が異なります。契約上の数字は、設計要件を満たした場合に初めて適用されます。

サービスクレジットは自動的な損害賠償ではない

クラウドのSLA未達時は、現金賠償ではなく将来利用分へのクレジットが一般的です。AWS EC2では所定の情報とログを添えて期限内に請求する必要があり、Google Cloud Compute Engineでも資格発生から60日以内の通知とログ提出が求められます。請求を忘れると権利を失うため、月次レビューに申請判定を組み込みます。

除外条件と責任分界を確認する

  • 計画保守、事前通知、緊急保守は停止時間から除外されるか
  • インターネット、顧客機器、顧客設定、第三者サービスはどこまで対象外か
  • プレビュー・ベータ機能、利用上限、規約違反は除外されるか
  • 再委託先のSLAが自社の顧客向けSLAを下支えできているか
  • クラウド基盤のSLAと、自社アプリケーション全体のSLAを混同していないか

重要：クラウド基盤が99.99％でも、アプリ、DNS、認証、回線、運用手順を含むエンドツーエンドのサービスが99.99％になるとは限りません。

2026年時点のITIL：ITIL 4だけでなくVersion 5が始まっている

旧資料の「ITILは英国OGCが作成した書籍」という説明は歴史的背景としては理解できますが、現状説明としては更新が必要です。2026年9月時点の公式資格体系にはITIL（Version 5）とITIL 4の双方が掲載されています。Version 5にはFoundation、Service、Product、Experience、Strategy等があり、ITIL ServiceはSLA、運用品質、継続的改善を扱います。一方、ITIL 4のService Level Management Practiceも引き続き公式体系に掲載されています。

ISO/IEC 20000-1：2018年版が現行

ISO公式情報では、ISO/IEC 20000-1:2018（第3版）は2023年に確認され、2026年9月時点でも現行です。組織がサービスマネジメントシステムを確立、実施、維持し、継続的に改善するための要求事項を定めています。2024年には気候変動への考慮を加えるAmendment 1が発行されています。

ITILは実務のベストプラクティスを学ぶ枠組み、ISO/IEC 20000-1は組織のサービスマネジメントシステムに対する要求事項です。両者は競合ではなく、用途が異なります。

SLAに盛り込むべき実務テンプレート

No. 項目 記載内容 確認ポイント
1 目的 合意の目的、対象となる契約 品質管理か責任限定か、双方の認識を揃える
2 サービス範囲 機能、拠点、利用者、時間帯、対象外 サービス名だけで終わらせない
3 役割・責任 RACI、連絡先、再委託、顧客側義務 測定・復旧・承認の責任者を特定する
4 用語・重大度 障害、停止、復旧、重大度の定義 起算点と終了点を定義する
5 サービス時間 提供時間、受付時間、保守時間 24/365と24時間受付を混同しない
6 SLI・SLO 指標、数式、目標、測定期間 測定点、母数、粒度、丸め方を明記する
7 除外条件 計画保守、不可抗力、顧客原因等 広すぎる包括除外を避ける
8 監視・証跡 監視元、ログ、時刻同期、保存期間 双方の値が違う場合の確定方法を決める
9 報告 月報、障害速報、原因分析、改善計画 期限、様式、レビュー会議を定める
10 未達時措置 是正、クレジット、減額、エスカレーション 申請要否、期限、上限、累積可否を定める
11 継続性 RTO/RPO、訓練、代替手段 バックアップ成功と復元可能を区別する
12 変更管理 目標値・構成・料金の変更手続 一方的なSLA変更をどう扱うか決める
13 契約終了 データ返却・消去、移行支援、証明 出口計画と追加費用を事前合意する

記載例：可用性条項

対象：本番Webサービスの認証済み主要機能

サービス時間：毎日0:00～24:00（日本標準時）

目標：暦月の月間可用性99.9％以上

測定：指定監視地点から1分間隔で実行する合成監視。連続3回失敗した最初の失敗時刻を開始、連続3回成功した最初の成功時刻を終了とする

除外：月4時間を上限とし7日前までに通知した計画保守、委託者の明白な設定誤り、合意済みの不可抗力

未達：翌月5営業日以内に実績と原因を報告し、10営業日以内に是正計画を提示する。クレジットの率・上限・申請期限は別表に定める

上記は検討用の例であり、個別契約への採用時は法務・調達・運用・セキュリティ担当者による確認が必要です。

SLA運用のPDCA

PLAN要求、指標、測定方法、目標値を定めます。
DO合意した手順で運用し、監視結果と証跡を記録します。
CHECK月次評価、傾向分析、利用者影響の確認を行います。
ACTION是正、変更、目標値や契約条件の再合意へつなげます。

達成率を月報へ並べるだけでは改善になりません。未達の有無に加え、エラーバジェットの消費、重大インシデント、再発率、利用者影響、変更失敗との関連を確認します。SLOを恒常的に大幅超過している場合は、過剰投資又は目標設定の不整合も疑います。

発注前・運用中のチェックリスト：発注・契約前

  • サービスの境界と依存先を図示した
  • 業務影響分析から必要な目標値を決めた
  • 監視点、母数、時間帯、計算式、丸めを合意した
  • 計画停止と不可抗力の除外範囲を精査した
  • 提供者の標準SLAと個別交渉できる範囲を確認した
  • 再委託先・クラウドの下支えSLAを確認した
  • 未達時の是正、クレジット、重大な反復未達時の解除を定めた
  • 契約書、仕様書、SLA、提案書の優先順位を定めた

運用開始後

  • 委託者側でもログ又は外形監視を保全している
  • 月次報告をサービスオーナーがレビューしている
  • クレジット申請期限を管理している
  • 重大障害のRCAと再発防止策を期限管理している
  • 目標達成だけでなく利用者体験と事業成果を確認している
  • 年1回又は重大変更時にSLAを再評価している

研修用まとめと確認問題：要点

  • SLAは品質目標だけでなく、測定・報告・未達時措置・改善ルールを含む
  • SLIは指標、SLOは目標、SLAは合意である
  • 可用性は分母、除外時間、構成条件を見なければ比較できない
  • サービスクレジットは自動付与とは限らず、請求期限と証跡が重要である
  • ITIL、ISO/IEC 20000、SREは用途が異なり、併用できる

確認問題

  1. 可用性99.9％のサービスで、30日当たりの停止上限はおよそ何分か。
  2. 「応答時間200ms以下」はSLI、SLO、SLAのどれに当たるか。測定方法が書かれていない場合の問題点も述べる。
  3. クラウド基盤のSLAとアプリケーション全体のSLAが一致しない理由を三つ挙げる。
  4. 計画保守を可用性計算から除外するとき、最低限何を合意すべきか。
  5. SLA未達が続いていないのに利用者満足度が低い場合、どの指標を見直すべきか。
回答例を表示
  1. 43分12秒。
  2. 目標値なのでSLO。測定点、対象処理、百分位、時間帯、母数がなければ判定できない。
  3. アプリ障害、認証・DNS・回線等の依存障害、顧客設定・運用ミスなど。
  4. 通知期限、実施時間帯、月間上限、緊急保守の扱い、延長時の扱い。
  5. 利用者に近いSLI、例えばp95/p99応答時間、業務成功率、初回解決率、満足度など。

まとめ

SLAの本質は、高い数字を掲げることではなく、期待と責任を測定可能な言葉へ変えることです。要求を上げれば費用も増えるため、業務影響、代替手段、構成条件、未達時の実効性を並べて決めます。契約締結後も月次評価と改善を続け、サービスと事業の変化に合わせて再合意することで、SLAは初めて生きた管理手段になります。

一次情報・参考資料

確認日：2026年9月26日。クラウドSLAや資格体系は変更されるため、契約・受験・引用前にリンク先の最新版を確認してください。

記事の独立性・編集方針

本記事は、特定の企業・団体・製品・サービスの広告、公式見解又は提供資料をそのまま紹介することを目的としたものではありません。

IPA、NIST、ISO、PeopleCert、Google SRE、各クラウドサービス事業者などが公開する公式・一次情報を複数確認し、SLAに関する一般原則、契約上の論点及び実務上の確認事項を比較・整理した上で、独自に構成しています。

企業名、製品名及びサービス名は、制度・仕様・契約条件等を具体的に説明するための参考情報として記載しています。特定の企業、製品又はサービスへの推奨・評価を目的とするものではありません。

掲載内容は2026年9月26日時点で確認可能な公開情報を基にしています。SLA、利用規約、資格体系、規格等は変更される場合があるため、契約、導入、受験その他の具体的な判断を行う際は、各公式サイトで最新情報をご確認ください。

タグ

関連投稿