SLA（Service Level Agreement：サービスレベル合意）

📖 はじめに

SLA（Service Level Agreement：サービスレベル合意）とは、サービス提供者と利用者の間で、「どの程度の品質でサービスを提供するか」を取り決めた合意事項です。

単なる契約書ではなく、「どのような品質を保証し、どのように評価するか」を明確にすることで、サービス提供者と利用者の認識のずれを防ぐ役割があります。

ITサービスマネジメント（ITSM）やITILでは、SLAはサービスレベル管理の中核となる重要な概念です。

SLAはサービスそのものを保証するものではなく、サービス品質の目標と評価方法を定める合意です。

🎯 SLAの目的

SLAの目的は、サービス提供者と利用者の双方が期待するサービス品質を明文化することです。

例えば、

どれくらいの時間で障害を復旧するか
システムがどれくらい利用できるか
問い合わせにどれくらいで回答するか

などを事前に定めます。

これにより、

利用者は期待できるサービス品質が分かる
提供者は守るべき品質基準が明確になる
トラブル時の判断基準になる

というメリットがあります。

🏗 SLAを構成する主な項目

SLAには一般的に次のような内容が含まれます。

項目	内容
対象サービス	どのサービスを対象とするか
提供時間	サービス提供時間・サポート時間
可用性	稼働率（Availability）
性能	応答時間や処理性能
障害対応	復旧目標時間（RTO）や対応時間
問い合わせ対応	受付時間・回答時間
責任範囲	提供者・利用者それぞれの責任
除外事項	保証対象外となる条件

📊 よく使われる指標

可用性（Availability）

サービスが利用可能だった割合です。

例

可用性	年間停止時間の目安
99%	約3.65日
99.9%	約8時間46分
99.95%	約4時間23分
99.99%	約52分
99.999%	約5分

可用性は「99.9%」と「99.99%」では停止許容時間が約10分の1になるため、実現コストも大きく増加します。

応答時間

利用者からの要求に対して、システムが応答するまでの時間です。

例

Webページ：2秒以内
API：500ms以内
データベース検索：1秒以内

問い合わせ対応時間

サービスデスクが問い合わせを受け付けてから対応を開始するまでの時間です。

例

優先度	対応開始
重大障害	30分以内
高	2時間以内
中	当日中
低	翌営業日

復旧時間

障害発生からサービス復旧までの目標時間です。

例

重大障害：4時間以内
通常障害：翌営業日まで

⏱ SLAとRTO・RPOの違い

災害対策（BCP・DR）では、SLAと合わせてRTO・RPOが使われます。

用語	意味
SLA	サービス品質全体に関する合意
RTO（Recovery Time Objective）	復旧目標時間
RPO（Recovery Point Objective）	許容できるデータ損失量

例えば、

SLA：可用性99.9%
RTO：2時間
RPO：15分

というように組み合わせて利用します。

🤝 SLA・SLI・SLOの違い

近年はクラウドやSREの普及により、SLAと合わせてSLI・SLOもよく使われます。

用語	意味
SLI（Service Level Indicator）	測定する指標
SLO（Service Level Objective）	目標値
SLA（Service Level Agreement）	利用者との合意

例えば、

項目	例
SLI	サービス可用性
SLO	99.95%以上
SLA	契約として99.9%以上保証

SREでは「まずSLIを測定し、その結果をもとにSLOを設定し、必要に応じてSLAで顧客と合意する」という考え方が一般的です。

📋 SLAの具体例

例えば、社内システムであれば次のようなSLAを設定できます。

項目	内容
サービス時間	平日8:30～18:00
可用性	99.9%以上
重大障害対応	30分以内に対応開始
復旧時間	4時間以内
問い合わせ受付	平日9:00～17:30
定期保守	毎月第2日曜日 2:00～5:00

⚖️ SLAと契約の違い

SLAは契約書の一部として定められることもありますが、契約そのものとは異なります。

契約では、

利用料金
契約期間
支払条件

などを定めます。

一方、SLAでは、

品質目標
測定方法
評価方法

を定めます。

🔄 ITILにおけるSLA

ITILでは、SLAはサービスレベル管理（Service Level Management） の中核となります。

サービスレベル管理では、

利用者の要求を把握する
適切なサービス品質を定める
SLAを締結する
品質を測定する
改善を継続する

というサイクルを繰り返します。

⚠️ SLAを作る際の注意点

数値だけを並べない

「99.9%」だけでは意味がありません。

測定方法
測定対象
集計期間

も明確にする必要があります。

達成困難な目標を設定しない

高い可用性ほど設備投資や運用コストは増加します。

必要以上に厳しいSLAは、サービス料金の増加や運用負荷の増大につながります。

利用者の責任も明確にする

例えば、

利用者側ネットワーク障害
利用者端末の故障
計画停止

などはSLAの対象外とすることが一般的です。

SLAでは「何を保証するか」だけでなく、「何を保証しないか」も明確に定義することが重要です。

🔗 関連する用語

用語	概要
ITIL	ITサービスマネジメントのベストプラクティス
ITSM	ITサービスを管理する考え方
SLM	サービスレベル管理
OLA（Operational Level Agreement）	組織内部の部門間で結ぶサービスレベル合意
UC（Underpinning Contract）	外部ベンダーとの契約。SLAを支える基盤契約
SRE	サービス信頼性を重視する運用手法

ITILでは、利用者とのSLA、組織内部のOLA、外部委託先とのUCを組み合わせることで、サービス品質を維持します。

📝 まとめ

SLAは、サービス提供者と利用者の間でサービス品質について合意する取り決めである。
可用性、応答時間、復旧時間、問い合わせ対応時間などを数値で定義する。
SLAは品質目標だけでなく、測定方法や対象外条件も明確にすることが重要である。
SLI・SLO・SLAは役割が異なり、SREやクラウドサービスでは組み合わせて利用される。
ITILでは、SLAはサービスレベル管理（SLM）の中核として継続的な品質改善に活用される。