SLA（サービスレベル合意）の決め方

SLA（サービスレベル合意）は、まず「何を測るか」を決め、次に「どの水準を目標にするか」を決め、最後に「守れなかったときにどうするか」を決める順で作ると、実際に使える約束になります。稼働率の数字だけを先に決めると、測り方や計画停止の扱いが曖昧なまま残り、後で解釈が分かれることがあります。

ここでは、SLAとよく一緒に使われるSLI・SLOの意味、稼働率の計算と測り方、守れなかったときの扱いを、公的な資料を参考に整理します。内容は2026年11月時点で公開されている資料にもとづいています。

SLA・SLO・SLIは、どう違うか

SLI・SLO・SLAは、測る指標、目標の値、利用者との約束という、段階の違う3つの言葉です。Google のSRE（サイト信頼性エンジニアリング）の書籍は、3つを次のように区別しています。

• SLI（サービスレベル指標）：サービスの水準のある面を、注意深く定義して数字で測ったもの。応答の速さ、エラーの割合、処理できる件数などがよく使われます
• SLO（サービスレベル目標）：SLIで測る値の目標、またはその範囲
• SLA（サービスレベル合意）：SLOを含む利用者との約束で、守れたとき・守れなかったときの結果を含むもの

同じ書籍は、SLOとSLAを見分ける方法として「SLOを守れなかったら何が起きるか」を問うことを挙げ、はっきりした結果が決まっていなければ、それはSLOだろうと説明しています。

出典：Service Level Objectives（Site Reliability Engineering、Google）

社内の目標としてSLOを持ち、その一部を、守れなかったときの扱いとともにお客様や発注者との約束（可用性とSLA）にする、という使い分けがよく見られます。社内の目標のSLOは、約束のSLAより少し厳しくしておくと、約束を破る前に気づけます。

稼働率は、どう計算するか

稼働率とは、サービスを利用できる時間の割合です。IPAのモデル契約書の追補版が参考として載せている、経済産業省の「SaaS向けSLAガイドライン」（2008年1月）のモデルケースでは、サービスの稼働率を、計画したサービスの時間から止まった時間を引き、計画したサービスの時間で割った値としています。

同じモデルケースは、設定の例として、基幹業務で99.9%以上、それ以外で99%以上を挙げ、対象の業務の重大さを考えながら、サービスの内容や品質に応じて個々に検討するものとしています。あくまで例で、実際の数字は業務の状況に応じて決めるものとされています。

出典：情報システム・モデル取引・契約書（第二版）・追補版（IPA）

稼働率の数字が、止まってよい時間としてどのくらいになるかは、計算で確かめられます。1か月を30日（43,200分）として計算すると、次のとおりです。

99.9%と99.99%の差は数字では小さく見えますが、止まってよい時間は10分の1になります。止まってよい時間を短くするほど、サーバーを二重にする（冗長化）、夜間も人が待機する、といった備えが要り、費用が上がることが多いです。

測り方を決めておく

稼働率の数字と同じくらい大切なのが、測り方です。同じ99.9%でも、何を「止まった」と数えるかで、意味が大きく変わります。SLAには次の点を書いておきます。

1. 測る対象：画面が開くか、ログインできるか、決まった処理が終わるか
2. 測る方法：外からの監視で一定の間隔で確かめるか、記録（ログ）から数えるか
3. 集計の期間：月ごとか、四半期ごとか
4. 計画停止の扱い：点検や更新のために前もって知らせて止める時間を、止まった時間に含めるか
5. 除外の条件：利用者の側の通信の問題や、決めた範囲の外の原因で止まった場合

計画停止について、先のモデルケースは、サービスを提供する時間帯の記載に計画停止の時間を含めること、定期的な保守のための停止を事前にどう知らせるかを決めておくことを、項目として挙げています。

稼働率のほかに決めておく項目

SLAで決める項目は、稼働率だけではありません。保守や運用の契約では、問い合わせや障害への対応の速さも大切です。IPAのモデル契約書の追補版は、保守について、受付時間・応答時間・復旧時間などを、測定できるサービスの内容として合意することを求めています。

ほかにも、業務に合わせて次のような項目を選びます。

• 画面の応答の速さ（決めた割合の操作が、何秒以内に終わるか）
• バックアップを取る間隔と、戻せる時点
• 障害が起きたときに知らせるまでの時間と、報告の形
• 定期的な報告の内容と頻度

項目を増やしすぎると、測って報告する手間が増えます。業務への影響が大きいものから、数を絞って決めるのが現実的です。

数字は、業務への影響から決める

SLAの数字は、高ければよいわけではなく、止まったときの業務への影響と、その数字を守るための費用から決めます。IPAの「非機能要求グレード」は、可用性・性能拡張性・運用保守性などの、機能以外の要求を一覧にし、要求の水準を段階で示した道具で、発注者と開発会社の認識の行き違いを防ぐことを目的としています。

出典：非機能要求グレード（IPA）

数字を決めるときは、発注者の側で次の点を整理しておくと、話し合いが進めやすくなります。

• そのシステムが止まると、どの業務がどのくらい止まるか
• 何時間までなら、手作業などの代わりの方法でしのげるか
• 業務で使う時間帯（平日の昼間だけか、夜間や休日もか）

守れなかったときの扱いを決める

SLAを守れなかったときの扱いを決めておかないと、数字は目標のままで、約束としての重みを持ちにくくなります。よく使われる扱いには、次のようなものがあります。

• 月の費用の一部を減らす（減らす割合と上限を決める）
• 原因と再発を防ぐ対策を、決めた期限までに報告する
• 続けて守れなかった場合に、契約を見直す、または終了できるようにする

費用を減らす形にする場合は、契約全体の損害賠償の上限との関係も確かめておきます。本記事はSLAの考え方を一般的に整理したものです。個別の契約書の内容や判断については、弁護士などの専門家にご確認ください。保守契約全体で決める項目はシステムの保守契約で決めておくことにまとめています。

当社のご支援

当社のWebシステム開発では、要件定義の段階で使う方や使う場面をおうかがいして作るものを決め、公開した後の運用まで同じチームで受け持ちます。止まったときの影響や対応の時間の考え方も、その中でご相談いただけます。いま使っているシステムやサービスのSLAが業務に合っているかを確かめたい場合は、AI・DXコンサルティングでもお手伝いします。まずはお問い合わせからご相談ください。