保守契約にSLAを盛り込む方法｜稼働率・RTO・RPOの決め方と条項サンプル

保守契約書のドラフトを受け取り「SLA 部分は御社で決めてください」「別紙で稼働率や RTO/RPO を定めてください」と言われた——このような状況で手が止まっている担当者は少なくありません。SLA という言葉の意味や、稼働率・SLO・SLI の違いは既存の解説記事で一通り確認したはずです。それでも「実際に契約書へ書く段になると、何を、どの数値で、どんな文面で書けばいいのか」が見えず、ベンダー案をそのまま飲むか、あるいは決められないまま契約を進めてしまう、という声をよく耳にします。

保守契約における SLA の難しさは、稼働率一つとっても「99.9% が定番」といった一般論だけでは決められない点にあります。自社のシステムが社内業務向けなのか顧客向けなのか、24 時間稼働なのか営業時間内のみか、災害時のデータ喪失をどこまで許容するのか——これらの前提が変わると、書き込むべき数値も条項の粒度も大きく変わります。さらにベンダー提示のドラフトには、免責条項の広さやペナルティ上限の低さといった「見た目は書いてあるが実効性は薄い」条件が混ざっていることも珍しくありません。

そこで本記事では、保守契約に SLA を盛り込むための「書き方」に焦点を当て、次の 4 点を実務レベルで整理します。第一に、SLA 条項として盛り込むべき主要指標（稼働率・障害対応時間・MTTR/MTBF・RTO/RPO・レポーティング）の全体像。第二に、稼働率と RTO/RPO の数値を自社に合った水準で決めるための判断フロー。第三に、契約書の別紙にそのまま貼り付けられる条項サンプル文例。第四に、ベンダー案をレビューする際に見落としやすい落とし穴と、その修正方針です。

なお、本記事で提示する条項サンプルは実務で参照しやすいひな形として作成した参考テンプレートであり、法的助言ではありません。実際の契約書化にあたっては、貴社の顧問弁護士・法務担当のレビューを必ず受けてください。

—Free Download / 資料ダウンロード

失敗しないためのシステム保守の引継ぎチェックリスト

この資料でわかること

システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。

こんな方におすすめです

• 現在の保守会社のサービスに不満を感じている方
• 保守会社の変更を検討しているが、何から始めればよいか分からない方
• 引継ぎ作業でトラブルを避けたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

保守契約に SLA を盛り込む理由と SLA が果たす役割

まず「なぜ保守契約に SLA を書く必要があるのか」を整理します。SLA を書いていない、あるいは形だけで実効性のない SLA しか書いていない保守契約では、運用開始後にトラブルが起きたときに「約束の水準」が存在せず、責任範囲や対応スピードの議論が感情論に流れやすくなります。

保守契約に SLA を書かないと何が起きるか

SLA が明記されていない保守契約でよく発生する問題は、大きく 3 つあります。

第一に、障害時の対応スピードに関する共通認識が持てないことです。「重大障害は速やかに対応する」とだけ書かれた契約では、発注者が期待する「速やか」（1 時間以内など）とベンダーが想定する「速やか」（翌営業日など）にずれが生じます。実際に本番停止が発生してから「そんなに早く復旧するとは契約に書いていない」と言われても、契約書に基準がなければ交渉材料になりません。

第二に、追加費用の線引きが曖昧になることです。障害対応・調査・データ復旧などの作業が「保守範囲内」なのか「範囲外の別途費用」なのかの判断根拠が契約書にないと、都度の見積提示になり、対応の遅れやコスト超過の温床になります。

第三に、ベンダー側の品質改善圧力が働かないことです。稼働率や復旧時間の目標値がなければ、ベンダーは自主的な改善インセンティブを持ちにくく、障害の再発防止が「実施した／していない」の水掛け論になりがちです。

SLA は「品質目標」ではなく「合意した基準と、破ったときの取り決め」

SLA（Service Level Agreement）は、直訳すると「サービスレベル合意」です。ここで重要なのは、SLA が発注者・ベンダーの一方的な目標ではなく、「両者が合意した基準」と「基準を下回ったときの取り決め（サービスクレジット・改善報告・契約解除等）」をセットで含む契約文書だという点です。

保守契約書の本体に「別紙 SLA に定める」と参照条項を置き、SLA を別紙・付属文書として詳細に定めるのが一般的な構成です。SLA 単体で法的拘束力を持たせるかどうかは書き方次第で、努力目標として位置付けるパターン、料金減額（サービスクレジット）を規定するパターン、損害賠償の予定額を明記するパターンなどが存在します（IT 法務.COM「ＳＬＡに関する注意点」）。本記事ではサービスクレジット型を中心に扱いますが、契約全体としてどの拘束力レベルを採用するかは、後述する「ペナルティ条項」の設計とあわせて決めていきます。

SLA・SLO・SLI の関係——発注者が合意するのは SLA

参考までに関連用語を整理しておきます。SLO（Service Level Objective）はベンダー側の内部目標値、SLI（Service Level Indicator）はその測定に使う具体的な指標値です。実務上は「SLI（測定指標）で SLO（内部目標）を管理し、そのうち発注者と合意する水準を SLA として契約書に書く」という関係になります。

本記事の焦点は「SLA として契約書に何をどう書くか」であるため、SLO/SLI そのものの解説は最小限にとどめます。定義や測定の考え方をより深く知りたい方は、SLA・SLO・SLI の違いや稼働率の意味を体系的に解説した専門記事もあわせて参照するとよいでしょう。

保守契約の SLA 条項に盛り込むべき 5 つの主要指標

ここからが本題です。保守契約 SLA に盛り込む指標は、契約書の項目として整理すると次の 5 つに集約できます。まず全体像を掴んだ上で、後半で稼働率と RTO/RPO の数値の決め方、そして各項目の条項サンプルへと進んでいきます。

なお、SLA を書く前提として「保守と運用の作業範囲区分」を明確にしておく必要があります。保守と運用の区分が曖昧だと、SLA の対象範囲もぼやけます。作業区分の考え方については保守と運用の違いを参照してください。

① 稼働率（可用性）——サービス提供時間との組み合わせが必須

稼働率は、対象システムが利用可能な時間の割合を表す指標で、「99.9%」のようにパーセンテージで記述します。ただし稼働率単独ではなく、サービス提供時間の定義（24 時間 365 日／平日 9〜18 時／計画メンテナンス除外の有無）とセットで書かなければ意味を持ちません。

契約書には「サービス提供時間内における月間稼働率を 99.9% 以上とする」といった形で、分子・分母の定義を明示することが必須になります。

② 障害対応時間——「初動応答」と「復旧目標」を分けて書く

障害対応時間は、障害連絡を受けてから対応を開始するまでの初動応答時間と、復旧までの復旧目標時間を分けて記述します。両者を混同すると、「対応した＝復旧した」のように読める曖昧な条項になりがちです。

さらに、障害の重大度を 3〜4 段階のレベルに分類し（例: レベル 1 = 全機能停止、レベル 2 = 主要機能停止、レベル 3 = 部分機能不具合）、レベルごとに初動応答時間と復旧目標時間を設定するのが実務的な書き方です。

③ MTTR/MTBF——信頼性を測るための補助指標

MTTR（Mean Time To Repair：平均修復時間）は 1 回の障害あたりの平均復旧時間、MTBF（Mean Time Between Failures：平均故障間隔）は障害と障害の平均間隔を表します。稼働率や個別の復旧時間だけでは見えにくい「長期的な信頼性の傾向」を測るための補助指標です。

すべての保守契約で必須ではありませんが、月次レポートの参考指標として盛り込むと、ベンダー側の品質改善サイクルを促す効果があります。

④ RTO/RPO——災害・データ喪失時の復旧目標

RTO（Recovery Time Objective：目標復旧時間）は災害・大規模障害発生時に何時間以内に復旧を完了するかの目標、RPO（Recovery Point Objective：目標復旧時点）は復旧時に何時間前までのデータを取り戻せるかの目標です。

稼働率や通常時の障害対応時間だけでは、データセンター停止・ハードウェア全損・データ破損といった大規模インシデントに備えられません。BCP（事業継続計画）や DR（Disaster Recovery）設計と一体で考える必要があるため、本記事では独立したセクションで詳しく扱います。

⑤ サポート体制・レポーティング——連絡経路とレポート提出のルール

サポート体制の条項では、受付時間・連絡経路（メール／電話／チャット）・エスカレーション体制を明記します。レポーティングは「月次で稼働率・障害件数・対応時間の実績をどの様式で提出するか」を規定するもので、SLA の達成状況を継続的に可視化する仕組みです。

これらを条項化しておかないと、ベンダーが自主的にレポートを出すか否かは担当者の裁量になり、SLA を定めた意味が半減します。

稼働率の数値の決め方——「99.9%」は月何分のダウンタイムか

主要指標の全体像を押さえたところで、まず稼働率の数値をどう決めるかを見ていきます。「99.9% が推奨」といった一般論だけで決めるのではなく、自社の事業タイプ・利用者の期待・コストとのバランスから逆算する視点が重要です。

稼働率別ダウンタイム早見表——数字の実感を掴む

稼働率のパーセンテージは、月次・年次のダウンタイム許容時間に換算して初めて実感が湧きます。以下は主な稼働率水準の月次・年次ダウンタイム換算表です。

（1 ヶ月＝ 30 日、1 年＝ 365 日で計算）

「99.9% と 99.99% は数字上は 0.09 ポイントしか違わないが、月次で見ると許容ダウンタイムが約 43 分と約 4 分で 10 倍の差になる」というのが、この換算表の要点です。稼働率を 1 桁高く設定すると、必要な冗長化構成や監視・オンコール体制のレベルが跳ね上がるため、後述するコストへの跳ね返りも意識してください。

事業タイプ別の稼働率の目安

事業タイプごとの稼働率の目安は、次のように整理できます。

• 社内業務システム（社内基幹・情報系）: 99.5〜99.9%。営業時間帯（例: 平日 9〜19 時）に限定した稼働率とすることも一般的です
• 顧客向け BtoB サービス: 99.9% 前後。24 時間 365 日ベースで測定し、月次で数十分のダウンタイムまでを許容範囲とします
• 顧客向け BtoC サービス・EC: 99.9〜99.95%。特に決済導線・カート機能は 99.95% 以上が求められます
• 金融基幹・ミッションクリティカル系: 99.99% 以上。冗長化構成・自動フェイルオーバー・24 時間有人監視が前提となります

ベンダーから「99.9% で問題ないですよね」と提示されたときに、そのまま飲むのではなく「自社の事業タイプ・営業時間・停止時の売上インパクトから逆算するとどこか」を必ず自問してください。

メンテナンス時間の扱い——計算式で稼働率が変わる

稼働率の計算式は、シンプルに書くと「稼働率 = 稼働時間 ÷ サービス提供時間」ですが、実務では計画メンテナンス時間を稼働時間・停止時間のどちらに含めるかで数値が大きく変わります。

• 計画メンテナンスを除外する方式: サービス提供時間から計画メンテナンス時間を差し引いた分母で計算。ベンダー側に有利になりやすい
• 計画メンテナンスを含める方式: 発注者から見て「実質的に利用できなかった時間」を全て停止扱いにする。発注者にとって厳しい方式

契約書には「計画メンテナンス時間は稼働率の分母から除外する。ただし計画メンテナンスは月○時間を上限とし、実施の 7 営業日前までに書面で通知する」といった形で、扱いと上限をセットで書くのが望ましい形です。上限規定がないと、計画メンテナンス扱いで実質的な停止時間が青天井になるリスクがあります。

過剰な稼働率はコストに跳ね返る

「念のため 99.99% を要求しておこう」という発想は、コスト面で裏目に出ることがあります。稼働率を 1 桁高く設定するには、サーバー・DB の冗長化、マルチ AZ／マルチリージョン構成、自動フェイルオーバー、24 時間監視体制などの上乗せが必要になり、月額の保守運用費が数割〜数倍単位で上振れするのが一般的です。

保守費用の相場や見積根拠の考え方はシステム保守費用の目安と根拠を参照してください。「事業インパクトから見て過剰でないか」を常に自問しながら数値を決めることが、SLA 設計の中核になります。

RTO・RPO の設定方法——災害・データ喪失に備える指標

続いて、多くの保守契約 SLA で書き漏れが発生しやすい RTO/RPO の設定を見ていきます。競合の解説記事の多くはこの領域を薄く扱っていますが、事業継続性の観点では稼働率と並んで欠かせない指標です。

なぜ稼働率だけでなく RTO/RPO が必要か

稼働率は「通常運転中にどれだけ止まらないか」を示す指標です。しかし現実の障害には、稼働率では捕捉しきれない次のようなパターンがあります。

• データセンター全体の停止（大規模災害・停電・ネットワーク切断）
• ハードウェア全損・ストレージ破損
• ランサムウェア感染などによるデータ暗号化・破壊
• オペミス・不具合によるデータ論理破壊

これらの大規模インシデントが発生したとき、「いつまでに復旧するか（RTO）」と「どの時点までのデータを取り戻せるか（RPO）」を事前に合意していないと、復旧作業の優先順位や許容工数がその場の判断になり、事業被害が拡大します。

稼働率は「起きないようにする指標」、RTO/RPO は「起きた後に取り戻す指標」と位置付けて、両方を SLA に書き込むのが基本形です。

事業タイプ別の RTO/RPO の目安

RTO/RPO の目安は、事業インパクト（1 時間・1 日停止したときの売上損失・信用毀損）と、失われたデータを再入力・再構築するコストから逆算して決めます。

• 社内業務システム: RTO 24 時間 / RPO 24 時間（前日夜間バックアップ復元）
• 顧客向け BtoB サービス: RTO 4〜8 時間 / RPO 1〜4 時間
• 顧客向け BtoC・EC: RTO 1〜4 時間 / RPO 15 分〜 1 時間（決済トランザクションを守るためレプリケーション必須）
• 金融・決済・医療情報系: RTO 1 時間以内 / RPO ほぼゼロ（同期レプリケーション・ホットスタンバイ構成）

医療情報システム向けの参考例としては、総務省が公開している医療情報連携基盤におけるサービス仕様適合開示書及びサービス・レベル合意書（SLA）参考例（PDF）が、公的機関が示す SLA テンプレートとして参考になります。

RTO/RPO はバックアップ運用・DR 構成と一体で設計する

RTO/RPO は、目標値を決めれば自動的に達成できるものではなく、それを支えるバックアップ運用と DR（Disaster Recovery）構成とセットで決める必要があります。

• RPO を短くする: 定期バックアップの間隔を短縮する、あるいは同期レプリケーション（プライマリの書き込みと同時にセカンダリにも書き込み）を導入する
• RTO を短くする: バックアップからの復元手順を自動化する、コールドスタンバイからウォーム／ホットスタンバイへ格上げする、DR サイトを地理的に別リージョンに構築する

このどれを組み合わせるかで、必要な設備投資・月額運用費が大きく変わります。「RTO 1 時間・RPO 5 分」を要求するなら、それを支える冗長化構成の維持コストを別途負担する覚悟が必要です。SLA 交渉時に構成前提を確認せずに数値だけを詰めると、「その数値は現構成では実現できません」と後から言われるリスクがあります。

保守契約に RTO/RPO を書く際の注意点

RTO/RPO を保守契約に書く際、実務で押さえておきたい注意点が 3 つあります。

第一に、DR 環境の維持コストは通常の保守費用と別建てで見積るのが慣行です。プライマリ環境の保守費用のなかに DR 費用が含まれるのか、別途 DR オプションとして計上されるのかを契約書で明確にしてください。

第二に、平常時の障害対応時間と、災害時の RTO は別物として書き分けます。平常時の障害対応時間は「初動応答 15 分、復旧目標 4 時間」のように書き、災害時 RTO は「大規模災害時は別紙 DR プランに従い、24 時間以内にサービスを再開する」といった形で分けて記載します。

第三に、RTO/RPO の測定方法と、達成できなかった場合の扱いを書いておきます。災害は頻繁に発生する事象ではないため、実測値でペナルティを発動するのは非現実的です。代わりに「年 1 回以上の DR 訓練を実施し、訓練で RTO/RPO を達成できなかった場合は改善計画を提出する」といった、訓練ベースでの担保に落とし込むのが実務的です。

そのまま使える SLA 条項サンプル文例集

ここまでで押さえた考え方をもとに、実際の保守契約書の別紙 SLA に貼り付けられる条項サンプル文例を並べていきます。各サンプルには、書き方のチェックポイントを併記します。

サンプル利用時の免責事項

以下のサンプル文例は、あくまで契約書起草・レビューの参考テンプレートであり、法的助言ではありません。実際の契約締結にあたっては、貴社の顧問弁護士・法務担当のレビューを必ず受けてください。また、業界固有の規制（金融庁のガイドライン、医療情報の 3 省 2 ガイドライン、個人情報保護法など）が適用される場合は、当該規制に沿った表現への調整が必要です。

サービス提供時間条項のサンプル

まず、SLA の対象となるサービス提供時間の定義です。

第○条（サービス提供時間）
1. 本サービスの提供時間は、年中無休で 24 時間とする。
2. 前項にかかわらず、乙は保守作業に必要な範囲で計画メンテナンスを実施することができ、その実施時間は本条第 1 項のサービス提供時間から除外する。
3. 乙は計画メンテナンスの実施日時、作業内容および想定停止時間を、実施の 7 営業日前までに書面または甲乙間で合意した電子的方法により甲に通知する。
4. 計画メンテナンスの月間合計時間は 4 時間を上限とし、これを超える場合は事前に甲の書面承諾を得るものとする。

チェックポイント: 提供時間・計画メンテナンスの扱い・通知期間・月間上限までを 1 セットで書きます。上限規定を書かないと、計画メンテナンス扱いの停止が青天井になります。

稼働率条項のサンプル

続いて、稼働率条項です。

第○条（稼働率）
1. 本サービスの月間稼働率は、以下の計算式により算出するものとし、乙は 99.9% 以上を維持することを目標とする。
   月間稼働率（%）＝（月間サービス提供時間 − 月間停止時間）÷ 月間サービス提供時間 × 100
2. 前項の「月間停止時間」には、以下は含まないものとする。
   (1) 前条に定める計画メンテナンス時間
   (2) 甲の責めに帰すべき事由により発生した停止時間
   (3) 天災地変、戦争、暴動、法令の制定・改廃、その他不可抗力により発生した停止時間
3. 稼働率の実測値は、乙が管理する監視システムのログをもって確定する。

チェックポイント: 計算式・分母・分子の定義を明示することが必須です。停止時間から除外する事由（免責）を書きすぎると SLA が空洞化するため、除外事由は最小限に絞り込みます。免責の空洞化については後述する落とし穴セクションを参照してください。

障害対応条項のサンプル（障害レベル分類つき）

障害の重大度をレベル分類し、レベルごとの初動応答時間・復旧目標時間を規定します。

第○条（障害対応時間）
1. 障害の重大度は、以下のレベルに分類する。
   レベル 1（重大）: 本サービス全体が利用できない状態、または主要業務に重大な支障が生じる状態
   レベル 2（高）: 主要機能の一部が利用できない、または業務に相当の支障が生じる状態
   レベル 3（中）: 一部機能に不具合があるが、代替手段により業務継続が可能な状態
   レベル 4（低）: 業務への影響が軽微な不具合
2. 障害連絡を乙が受領した時刻を起点とし、レベルごとの初動応答時間および復旧目標時間は以下のとおりとする。

   | レベル | 初動応答時間 | 復旧目標時間 | 対応時間帯 |
   |--------|-------------|-------------|-----------|
   | 1 | 30 分以内 | 4 時間以内 | 24 時間 365 日 |
   | 2 | 1 時間以内 | 8 時間以内 | 24 時間 365 日 |
   | 3 | 4 時間以内 | 2 営業日以内 | 平日 9〜18 時 |
   | 4 | 1 営業日以内 | 5 営業日以内 | 平日 9〜18 時 |

3. 復旧目標時間は目標値であり、乙は合理的な努力をもって当該時間内の復旧に努めるものとするが、原因が乙の合理的な管理範囲を超える場合はこの限りでない。

チェックポイント: 「初動応答」と「復旧目標」を分けて書くこと、レベル分類の判定基準を書くこと、対応時間帯（24 時間か営業時間内か）をレベルごとに書くことが重要です。判定基準がないと、ベンダー側が「レベル 3 相当」と主張して緩い対応時間で処理される余地が残ります。

RTO/RPO 条項のサンプル

災害・大規模障害時の復旧目標です。

第○条（災害時の目標復旧時間および目標復旧時点）
1. 大規模災害、データセンター全体の障害、その他前条に定めるレベル 1 障害を超える大規模インシデントが発生した場合、乙は別紙「DR 対応計画書」に基づき、以下の目標復旧時間（RTO）および目標復旧時点（RPO）を目標として復旧対応を行う。
   目標復旧時間（RTO）: 24 時間以内
   目標復旧時点（RPO）: 直近 1 時間以内のデータ状態
2. 前項の RTO / RPO は目標値であり、実際の復旧に要する時間は災害の規模・被害状況により変動する。乙は復旧見込み時刻を甲に随時報告するものとする。
3. 乙は年 1 回以上、本条に定める RTO / RPO の達成可能性を検証する DR 訓練を実施し、訓練結果および改善提案を書面で甲に報告する。訓練において RTO / RPO を達成できなかった場合、乙は原因分析および改善計画を訓練実施後 30 日以内に提出する。
4. 本サービスの DR 構成の維持に係る費用は、別途「DR オプション費用」として第○条（費用）に定めるとおりとする。

チェックポイント: RTO/RPO 数値・訓練ベースの担保・DR 費用の別建てを 1 セットで書くこと。DR 費用の扱いを書かないと、後から「その水準では別費用が必要」と言われるリスクがあります。

レポーティング条項のサンプル

月次で SLA 達成状況を可視化するレポート提出のルールです。

第○条（月次サービスレポート）
1. 乙は毎月 10 営業日以内に、前月分の「サービスレベル報告書」を甲に提出する。
2. サービスレベル報告書には以下を含む。
   (1) 月間稼働率の実績値および計算根拠
   (2) 障害発生件数（レベル別）および初動応答時間・復旧時間の実績
   (3) 計画メンテナンスの実施実績
   (4) 未解決事項および次月以降の対応方針
3. 甲は前項の報告書を受領後、内容について乙に対して照会・確認を行うことができる。乙は 5 営業日以内に回答するものとする。
4. 稼働率が第○条に定める目標値を 3 ヶ月連続で下回った場合、乙は原因分析および改善計画書を提出し、甲乙協議のうえ改善措置を講じる。

チェックポイント: 提出期限・記載項目・目標未達時のエスカレーション手続を明記します。「毎月報告する」だけでは、フォーマットが月ごとに変わったり、達成率だけを載せて実測データを省略されたりする余地が残ります。

ペナルティ（サービスクレジット）条項のサンプル

稼働率未達時の料金減額規定です。損害賠償ではなく、サービスクレジットとして翌月以降の保守費用に充当する方式が一般的です。

第○条（サービスクレジット）
1. 月間稼働率が第○条に定める目標値（99.9%）を下回った場合、乙は甲に対し、以下の基準に従いサービスクレジットを付与する。

   | 月間稼働率 | サービスクレジット（月額保守料金に対する比率） |
   |-----------|--------------------------------------------|
   | 99.0% 以上 99.9% 未満 | 10% |
   | 95.0% 以上 99.0% 未満 | 25% |
   | 95.0% 未満 | 50% |

2. サービスクレジットは、付与月の翌月以降の月額保守料金から控除する形で適用する。
3. サービスクレジットは本 SLA 未達に対する乙の唯一の金銭的責任とし、これを超える損害賠償の請求はできない。ただし、乙の故意または重大な過失により生じた損害についてはこの限りでない。
4. 月間稼働率が 90% を下回る状態が 2 ヶ月連続で発生した場合、甲は書面通知により本契約を解除することができる。

チェックポイント: 稼働率レンジとクレジット比率の階段を書くこと、上限規定と例外（故意・重過失）を書くこと、深刻な未達時の契約解除権を明記すること。ベンダー案では「月額保守料金の 5% を上限とする」のような極端に低い上限が入っていることが多いため、実効性のある比率になっているかレビューしてください。

免責条項のサンプル——書きすぎると SLA が空洞化する

免責条項は、SLA を空洞化させる最大の要因です。ベンダー案では免責事由が広く書かれる傾向があるため、範囲を絞り込みます。

第○条（免責事由）
1. 以下の事由により本サービスに障害が発生した場合、当該時間は前条稼働率の計算における停止時間から除外し、乙は本 SLA 上の責任を負わない。
   (1) 天災地変、戦争、暴動、法令の制定・改廃、公的機関の命令その他の不可抗力
   (2) 甲の責めに帰すべき事由（甲の設定変更ミス、甲提供機器の障害、甲による本サービスの想定外利用等）
   (3) 甲が指定するサードパーティ製サービス・機器の障害（ただし、乙が構成要素として組み込んだクラウド事業者のサービス障害は本免責事由に含めない）
2. 前項第 3 号にかかわらず、乙が利用するインフラ事業者（IaaS/PaaS）の障害については、乙は当該事業者の SLA に基づく補償を可能な限り甲に還元する。

チェックポイント: 「クラウド障害・第三者サービス障害は一切免責」とベンダー案に書かれていることが多いですが、これでは乙が組み込んだクラウド事業者の障害まで全て免責されてしまい、稼働率 SLA が実質無意味になります。「甲が指定するサードパーティ」に限定し、乙が選定した基盤サービスの障害は稼働率に含める形に修正するのが実務的です。

SLA 条項を書くときに陥りやすい 3 つの落とし穴

ベンダー提示のドラフトをレビューする際、または自社で SLA 条項を起草する際に、特に陥りやすい落とし穴を 3 点に絞って整理します。

免責条項の空洞化——除外事由を書きすぎない

先ほどの免責条項サンプルでも触れましたが、免責事由を広く書きすぎると SLA が形骸化します。特に警戒すべきパターンは次の 3 つです。

• 「クラウド事業者の障害は全て免責」: ベンダーが選定したインフラ（AWS/Azure/Google Cloud 等）の障害まで免責されると、稼働率 SLA の対象時間が大幅に縮小します。「甲が指定したサードパーティ」に限定してください
• 「乙の合理的な管理範囲を超える事由は全て免責」: 「合理的」の定義が主観的で、判断の逃げ道になります。具体的な事象を列挙する方式に修正してください
• 「本 SLA に定めのない事由により発生した障害は免責」: SLA の網羅性を逆手に取った文言です。この一文があると SLA が骨抜きになるため、削除を要求してください

契約前に「この免責条項が発動されるのは具体的にどんな障害か、直近 3 年で該当したことがあるか」をベンダーに確認するとよいでしょう。

ペナルティ上限が形だけになっていないか

ベンダー案のサービスクレジットは、実効性が薄い水準に設定されていることが少なくありません。

• 月額保守料金の 5% 上限: 停止による事業損失に比して極端に低く、ベンダー側の改善インセンティブが働きにくい
• 稼働率 95% 以上ならクレジットなし: 月間 36 時間以上停止しないとペナルティが発動しない設計。目標値が 99.9% なのにペナルティの発動下限が 95% では階段が広すぎます
• 年間上限が月額の 1 ヶ月分: 慢性的な未達を放置してもベンダー側の負担が頭打ちになり、改善インセンティブがない

修正の指針: 目標値の直下からペナルティが発動する階段を設定し、目標未達幅が広がるほどクレジット比率が上がる設計にしてください。稼働率 SLA 目標が 99.9% なら、99.0% 未達で 25%、95.0% 未満で 50% 程度が実務的な水準です。

「保守範囲」と「範囲外＝追加費用」の線引きを条項で潰す

契約締結後に頻発するトラブルの一つが、「その作業は保守範囲外で追加費用が発生します」という後出しです。保守範囲と範囲外の線引きを条項で明確にしておかないと、都度交渉になり、対応の遅れとコスト超過を招きます。

対策は、SLA 別紙とは別に「作業範囲一覧」を契約書の別紙として付けることです。想定される作業（障害対応・不具合修正・環境調整・データ復旧・OS/ミドルウェアのアップデート適用・設定変更依頼など）を一覧化し、それぞれ「保守料金に含む／別途見積」を明記します。

契約類型（準委任か請負か）によっても作業範囲の書き方は変わります。準委任・請負の違いや保守契約書の記載項目については運用保守契約の種類と内容を参照してください。

SLA 条項作成のチェックリストと次のアクション

最後に、記事全体をチェックリスト形式で振り返り、次のアクションを整理します。

SLA 条項作成チェックリスト

• サービス提供時間・稼働率・障害対応時間・MTTR/MTBF・RTO/RPO・レポーティングの主要指標を網羅しているか
• 稼働率の数値は、自社の事業タイプ・営業時間・停止時の事業インパクトから逆算しているか
• 稼働率の計算式（分子・分母）と、計画メンテナンスの扱いを明示しているか
• 障害レベル分類と、レベルごとの初動応答時間・復旧目標時間を書き分けているか
• RTO/RPO と、それを支える DR 構成・訓練体制・DR 費用の別建てを条項化しているか
• 月次レポートの提出期限・記載項目・目標未達時のエスカレーションを明記しているか
• サービスクレジット条項が実効性のある比率になっているか（形だけの上限になっていないか）
• 免責条項が広すぎず、乙が選定したインフラ障害まで免責されない設計になっているか
• 「保守範囲」と「範囲外＝追加費用」を別紙の作業範囲一覧で線引きしているか

次のアクション

第一に、既存の保守契約ドラフト（自社が起草中、またはベンダーから提示されたもの）を、上記チェックリストで自己レビューしてください。空白のセルが多いほど、契約後のトラブルリスクが高い状態です。

第二に、稼働率と RTO/RPO の水準を、事業インパクトから逆算して社内で仮決めしてください。特に RTO/RPO はバックアップ運用・DR 構成と一体で決める必要があるため、社内の DR 想定シナリオを 1 度整理する必要があります。

第三に、本記事の条項サンプルをベースに、貴社の顧問弁護士・法務担当のレビューを経てカスタマイズし、ベンダー交渉に持ち込んでください。ベンダー案をそのまま飲むのではなく、「なぜこの数値・この免責範囲になるのか」を根拠込みで議論する材料になります。

第四に、契約締結後の月次レポートで SLA 達成状況を継続的にモニタリングし、未達傾向が見えた段階で改善協議に入る運用を回してください。SLA は「書いて終わり」ではなく、「合意した基準を継続的に検証する仕組み」として初めて機能します。

保守運用を外部委託する場合の SLA 設計（委託先タイプ別の設計差・運用実績ゼロから水準を決める進め方）については、発注者向けの補足として保守運用の外部委託SLA設計もあわせて参照するとよいでしょう。

関連するお役立ち資料

システム保守契約の設計・SLA 交渉・ベンダーマネジメントを体系的に整理したい方は、お役立ち資料一覧 から関連資料をあわせてご覧ください。発注実務・契約書レビューの実務テンプレートを提供しています。

既存の保守契約書に SLA を追加したい、または新規発注時の SLA 要件定義に伴走してほしい方は、お問い合わせフォーム からご相談ください。契約書ドラフトのレビューから、ベンダー交渉時の伴走まで、要件整理段階からのご相談も承ります。

—Free Download / 資料ダウンロード

失敗しないためのシステム保守の引継ぎチェックリスト

この資料でわかること

システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。

こんな方におすすめです

• 現在の保守会社のサービスに不満を感じている方
• 保守会社の変更を検討しているが、何から始めればよいか分からない方
• 引継ぎ作業でトラブルを避けたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。