--- title: "SLA（サービスレベル合意）の決め方｜アメリア・テクノロジー株式会社" url: https://www.ameliatechnology.co.jp/blog/sla-how-to-decide/ description: "SLA（サービスレベル合意）の決め方を、SLI・SLO・SLAの違い、稼働率の計算と測り方、守れなかったときの扱いの順に説明します。業務への影響から数字を決める考え方と、IPAや経済産業省の資料の使い方も紹介します。" updated: 2026-11-12 publisher: "アメリア・テクノロジー株式会社" --- # SLA（サービスレベル合意）の決め方 SLA（サービスレベル合意）の決め方を、SLI・SLO・SLAの違い、稼働率の計算と測り方、守れなかったときの扱いの順に説明します。業務への影響から数字を決める考え方と、IPAや経済産業省の資料の使い方も紹介します。 2026.11.12 [開発の発注と契約](https://www.ameliatechnology.co.jp/blog/category/outsourcing/) 執筆 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/)（グループCTO） 開発の発注と契約（OUTSOURCING）のコラム ## この記事の要点 - SLAは、測る指標（SLI）と目標（SLO）に、守れなかったときの扱いを加えた、利用者との約束です - 稼働率は、計画したサービスの時間から止まった時間を引き、計画したサービスの時間で割って求めます - 数字は高ければよいのではなく、止まったときの業務への影響と、その数字を守るための費用から決めます 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）](https://sre.google/sre-book/service-level-objectives/) 社内の目標としてSLOを持ち、その一部を、守れなかったときの扱いとともにお客様や発注者との約束（[可用性とSLA](https://www.ameliatechnology.co.jp/glossary/availability-sla/)）にする、という使い分けがよく見られます。社内の目標の[SLO](https://www.ameliatechnology.co.jp/glossary/slo/)は、約束のSLAより少し厳しくしておくと、約束を破る前に気づけます。 ## 稼働率は、どう計算するか 稼働率とは、サービスを利用できる時間の割合です。IPAのモデル契約書の追補版が参考として載せている、経済産業省の「SaaS向けSLAガイドライン」（2008年1月）のモデルケースでは、サービスの稼働率を、計画したサービスの時間から止まった時間を引き、計画したサービスの時間で割った値としています。 稼働率 ＝ 計画したサービスの時間 − 止まった時間 計画したサービスの時間 経済産業省「SaaS向けSLAガイドライン」（2008年1月）のモデルケースでの定義です 同じモデルケースは、設定の例として、基幹業務で99.9%以上、それ以外で99%以上を挙げ、対象の業務の重大さを考えながら、サービスの内容や品質に応じて個々に検討するものとしています。あくまで例で、実際の数字は業務の状況に応じて決めるものとされています。 出典：[情報システム・モデル取引・契約書（第二版）・追補版（IPA）](https://www.ipa.go.jp/digital/model/model20201222.html) 稼働率の数字が、止まってよい時間としてどのくらいになるかは、計算で確かめられます。1か月を30日（43,200分）として計算すると、次のとおりです。 | 稼働率 | 1か月（30日）で止まってよい時間 | |---|---| | 99% | 432分（7時間12分） | | 99.9% | 43.2分 | | 99.99% | 約4.3分 | 99.9%と99.99%の差は数字では小さく見えますが、止まってよい時間は10分の1になります。止まってよい時間を短くするほど、サーバーを二重にする（[冗長化](https://www.ameliatechnology.co.jp/glossary/redundancy/)）、夜間も人が待機する、といった備えが要り、費用が上がることが多いです。 ## 測り方を決めておく 稼働率の数字と同じくらい大切なのが、測り方です。同じ99.9%でも、何を「止まった」と数えるかで、意味が大きく変わります。SLAには次の点を書いておきます。 1. **測る対象**：画面が開くか、ログインできるか、決まった処理が終わるか 2. **測る方法**：外からの監視で一定の間隔で確かめるか、記録（[ログ](https://www.ameliatechnology.co.jp/glossary/log/)）から数えるか 3. **集計の期間**：月ごとか、四半期ごとか 4. **計画停止の扱い**：点検や更新のために前もって知らせて止める時間を、止まった時間に含めるか 5. **除外の条件**：利用者の側の通信の問題や、決めた範囲の外の原因で止まった場合 計画停止について、先のモデルケースは、サービスを提供する時間帯の記載に計画停止の時間を含めること、定期的な保守のための停止を事前にどう知らせるかを決めておくことを、項目として挙げています。 ## 稼働率のほかに決めておく項目 SLAで決める項目は、稼働率だけではありません。保守や運用の契約では、問い合わせや障害への対応の速さも大切です。IPAのモデル契約書の追補版は、保守について、受付時間・応答時間・復旧時間などを、測定できるサービスの内容として合意することを求めています。 ほかにも、業務に合わせて次のような項目を選びます。 - 画面の応答の速さ（決めた割合の操作が、何秒以内に終わるか） - バックアップを取る間隔と、戻せる時点 - 障害が起きたときに知らせるまでの時間と、報告の形 - 定期的な報告の内容と頻度 項目を増やしすぎると、測って報告する手間が増えます。業務への影響が大きいものから、数を絞って決めるのが現実的です。 ## 数字は、業務への影響から決める SLAの数字は、高ければよいわけではなく、止まったときの業務への影響と、その数字を守るための費用から決めます。IPAの「非機能要求グレード」は、可用性・性能拡張性・運用保守性などの、機能以外の要求を一覧にし、要求の水準を段階で示した道具で、発注者と開発会社の認識の行き違いを防ぐことを目的としています。 出典：[非機能要求グレード（IPA）](https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html) 数字を決めるときは、発注者の側で次の点を整理しておくと、話し合いが進めやすくなります。 - そのシステムが止まると、どの業務がどのくらい止まるか - 何時間までなら、手作業などの代わりの方法でしのげるか - 業務で使う時間帯（平日の昼間だけか、夜間や休日もか） ## 守れなかったときの扱いを決める SLAを守れなかったときの扱いを決めておかないと、数字は目標のままで、約束としての重みを持ちにくくなります。よく使われる扱いには、次のようなものがあります。 - 月の費用の一部を減らす（減らす割合と上限を決める） - 原因と再発を防ぐ対策を、決めた期限までに報告する - 続けて守れなかった場合に、契約を見直す、または終了できるようにする 費用を減らす形にする場合は、契約全体の[損害賠償の上限](https://www.ameliatechnology.co.jp/glossary/liability-cap/)との関係も確かめておきます。本記事はSLAの考え方を一般的に整理したものです。個別の契約書の内容や判断については、弁護士などの専門家にご確認ください。保守契約全体で決める項目は[システムの保守契約で決めておくこと](https://www.ameliatechnology.co.jp/blog/maintenance-contract-points/)にまとめています。 ## 当社のご支援 当社の[Webシステム開発](https://www.ameliatechnology.co.jp/service/web-system/)では、要件定義の段階で使う方や使う場面をおうかがいして作るものを決め、公開した後の運用まで同じチームで受け持ちます。止まったときの影響や対応の時間の考え方も、その中でご相談いただけます。いま使っているシステムやサービスのSLAが業務に合っているかを確かめたい場合は、[AI・DXコンサルティング](https://www.ameliatechnology.co.jp/service/consulting/)でもお手伝いします。まずは[お問い合わせ](https://www.ameliatechnology.co.jp/contact/)からご相談ください。 - SLA - SLO - 稼働率 - 保守契約 ## この記事に出てくる用語 - [可用性・SLA](https://www.ameliatechnology.co.jp/glossary/availability-sla/) - [SLO（サービスレベル目標）](https://www.ameliatechnology.co.jp/glossary/slo/) - [SRE（サイトリライアビリティエンジニアリング）](https://www.ameliatechnology.co.jp/glossary/sre/) - [情報システム・モデル取引・契約書（IPA）](https://www.ameliatechnology.co.jp/glossary/model-contract-ipa/) - [SaaS](https://www.ameliatechnology.co.jp/glossary/saas/) - [サーバー](https://www.ameliatechnology.co.jp/glossary/server/) - [冗長化](https://www.ameliatechnology.co.jp/glossary/redundancy/) - [監視](https://www.ameliatechnology.co.jp/glossary/monitoring/) ## 関連する法令・指針（参考情報） - 指針 独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書」（第二版（2020年12月22日）） 情報システムの受託開発（一部の企画を含む）と保守運用の取引について、モデル契約と解説をまとめた資料です。民法の改正に直接関係する論点と、それ以外の論点の両方を見直しています。 [発行元の公式ページで開く](https://www.ipa.go.jp/digital/model/model20201222.html) - 指針 独立行政法人情報処理推進機構（IPA）「非機能要求グレード」（非機能要求グレード2018） 非機能要求（機能以外の要求）について、発注者と開発者の認識の行き違いを防ぐことを目的に、項目を網羅的に一覧にして分類し、それぞれの要求の水準を段階的に示した資料です。項目は、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目に分けられています（事業は2018年度で終了し、紹介ページはアーカイブとして公開されています）。 [発行元の公式ページで開く](https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html) 法令は2026年10月21日時点の内容です。要旨は当社がまとめたもので、条文・判決・指針の全文ではありません。個別の事案への当てはめは、弁護士・社会保険労務士などの専門家にご確認ください。表記の決まりは[法令・指針の参考情報と凡例](https://www.ameliatechnology.co.jp/knowledge/legal/)をご覧ください。 この記事を書いた人 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/) グループCTO インターネットの黎明期から、ホスティング事業の立ち上げや、インフラ・セキュリティのプロジェクトに携わってきました。現在は、AWS・Azure へのクラウド移行の支援と、業務アプリケーションの要件定義から実装までを担っています。 このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。 ## あわせて読みたい - [開発会社を替えるときの引き継ぎと、そろえておく資料](https://www.ameliatechnology.co.jp/blog/vendor-switch-handover/) - [取適法（中小受託取引適正化法）とシステム開発の発注](https://www.ameliatechnology.co.jp/blog/toriteki-act-system-development/) - [システム開発の成果物の著作権は誰のものか](https://www.ameliatechnology.co.jp/blog/software-copyright-ownership/) [開発の発注と契約のコラムを見る](https://www.ameliatechnology.co.jp/blog/category/outsourcing/) [コラムの一覧に戻る](https://www.ameliatechnology.co.jp/blog/) ## 次の一歩 ### 現場に入るチームに任せる 技術者がお客様の現場に入り、要件定義から開発・運用までを担います。 [FDEを見る](https://www.ameliatechnology.co.jp/fde/) ### まずは30分、オンラインで話してみる 何に使うかが決まっていない段階でも構いません。30分のオンライン相談は無料です。 [無料で相談する](https://www.ameliatechnology.co.jp/contact/) ## ご関心に合わせて、お選びください。 [情報を集めている方へ会社案内、AI開発の例、セキュリティ診断の報告書の見本をお送りします。資料をダウンロード](https://www.ameliatechnology.co.jp/download/)[課題が見えている方へオンラインで30分、お話をうかがいます。費用はかかりません。無料で相談する](https://www.ameliatechnology.co.jp/contact/)[進め方を決めたい方へ2〜4週間で、優先順位と計画をまとめるAI活用の診断です。診断について見る](https://www.ameliatechnology.co.jp/pricing/#diagnosis) --- 出典：アメリア・テクノロジー株式会社「SLA（サービスレベル合意）の決め方｜アメリア・テクノロジー株式会社」 https://www.ameliatechnology.co.jp/blog/sla-how-to-decide/