システム開発・保守契約のSLAガイド｜発注者が確認すべき7項目と交渉のポイント

SLAを契約に盛り込んだにもかかわらず、システム障害が発生した際にベンダーから「対応できる担当者がいない」「今は優先度が低い」と言い訳をされ、損失だけが残った——そんな経験をお持ちではないでしょうか。

SLAはただ締結すれば発注者を守れるものではありません。設計が不十分なSLAは「努力目標」に過ぎず、実際には何の法的効果も生じない場合があります。一方で、正しく設計・交渉したSLAは、障害対応の遅延・コスト超過・責任逃れから発注者を守る強力な契約上の武器になります。

この記事では、システム開発・保守契約において発注者が確認すべきSLAの7項目と、実際に機能するSLAを締結するための交渉ポイントを解説します。具体的には次のことが分かります。

• SLAとSLO・SLIの違いと、発注者が気にすべき範囲
• SLAに必ず盛り込む7つの項目と各確認ポイント
• 「99.9%稼働率」が月に何分のダウンタイムを意味するか（計算表付き）
• ペナルティ条項の3パターンと「努力目標型」の危険性
• SLAが法的拘束力を持つための3条件
• 今すぐ使える交渉チェックリスト

注意: 本記事は法律的なアドバイスを目的とするものではなく、参考情報として提供しています。具体的な法的判断については、専門の弁護士にご相談ください。

SLAとは何か——システム開発・保守契約における基本定義

SLA（サービスレベルアグリーメント）の定義

SLA（Service Level Agreement）は、サービス提供者（ベンダー）と利用者（発注者）の間で、「提供するサービスの品質水準」と「その水準を下回った場合の効果」を明文化した契約上の合意です。

ポイントは「水準を下回った場合の効果」にあります。単に「稼働率99.9%を目指す」と書かれているだけでは、違反されても何も起きません。後述する「努力目標型SLA」は、実質的にSLAとは呼べないものです。

発注者の立場では、SLAを「ベンダーに品質を約束させる文書」ではなく、「品質が守られなかった場合に補償を得るための契約条項」として捉えることが重要です。

なぜシステム開発・保守契約にSLAが必要なのか

システム開発・保守の契約では、成果物の納品基準（要件定義・仕様書・テスト結果）についての合意は丁寧に行われる一方、保守フェーズに入ってからの「サービス品質」の合意はあいまいになりがちです。

システム開発の要件定義や見積もりの段階でSLAの確認を怠ると、保守フェーズで以下のような問題が起きます。

• 障害が発生しても「対応時間の目安」がなく、ベンダー任せになる
• 「修正します」と言われたまま1週間放置されても、契約上の根拠がない
• 障害によって業務が止まった損失について、補償を求めようとしても「契約書に書いていない」と言われる

SLAを保守契約の中に明確に盛り込むことで、これらのリスクを事前に手当てできます。

SLAがないと何が起きるか——よくあるトラブル事例

SLAが不明確または存在しない場合、以下のようなトラブルが頻発します。

事例1: 障害対応の優先度が低い
夜間に重大障害が発生したが、「平日9時〜18時対応」としか定められていないため翌朝まで放置。翌朝連絡しても「担当者が確認中」のまま3時間経過。結果として半日の業務停止に。

事例2: 復旧の定義がない
システムが不安定な状態でも「一応動いている」としてベンダーが対応を終了。「復旧」の基準が契約に定められていないため、発注者はクレームの根拠を持てない。

事例3: 損失の補償を求められない
障害による売上損失について補償を求めたが、「SLAには稼働率の定めはあるが損害賠償については規定がない」と言われ、実質的に泣き寝入り。

SLA・SLO・SLIの違いをわかりやすく整理

SLA・SLO・SLIの3層構造

システム開発の現場では、SLAと合わせてSLO・SLIという用語も使われます。発注者として必要な理解をシンプルに整理します。

用語	正式名称	誰が使う概念か	例
SLA	Service Level Agreement	発注者とベンダーの間の契約	「稼働率99.9%を保証し、違反時は月額料金の10%を減額」
SLO	Service Level Objective	ベンダーが内部で設定する目標	「内部目標は稼働率99.99%を維持する」
SLI	Service Level Indicator	SLO達成の測定に使う指標	「稼働率の測定は5分ごとのサーバーヘルスチェックで行う」

SCROLL→

発注者が関与すべきはSLAのみ

SLOはベンダーの内部目標であり、発注者が直接交渉する必要はありません。ただし、「なぜSLAで99.9%を保証できるのか」という根拠を確認する際にSLOの概念を知っていると、ベンダーの回答の妥当性を評価できます。

SLAで「稼働率99.9%を保証」しているベンダーは、内部的には99.99%を目標（SLO）として運用しているのが一般的です。SLOがSLAと同じ水準の場合、バッファがなく、実際にSLAを守れないリスクが高まります。

SLIについての確認ポイント

「稼働率はどのように測定していますか？」という質問は、発注者として聞いておく価値があります。測定方法（SLI）によって稼働率の見かけ上の数値が大きく変わります。例えば、「1時間に1回のチェックで障害を検知する」場合、最大59分の障害が「稼働」としてカウントされる場合があります。

SLAに盛り込むべき7つの項目

項目①: サービス提供時間（稼働時間・メンテナンス窓）

定義: システムが利用可能な時間帯とメンテナンスのための計画停止時間。

発注者の確認ポイント:

• 「24時間365日」なのか「平日9時〜18時」なのか、自社の業務時間に合っているか
• 計画メンテナンスの頻度・通知タイミング（「2週間前に通知」など）が明記されているか
• 計画停止は稼働率の計算から除外されているか（除外の場合、実質的な障害許容時間が減る）

関連記事: システムの保守・運用の定義が不明確な場合は、先に「システム保守と運用の違いを解説」をご確認ください。

項目②: 稼働率（可用性）——99.9%と99.99%では何が違うか

定義: 一定期間中にシステムが正常に動作している時間の割合。

発注者の確認ポイント:

• 稼働率の数値と、月次・年次でのダウンタイム許容時間（次章の計算表参照）
• 稼働率が計算対象となる期間（月次か年次か）の確認
• 稼働率が未達の場合のペナルティが「項目⑥ペナルティ条項」と連動しているか

項目③: 障害レベルと対応時間（インシデント分類・初動対応・復旧目標）

定義: 障害の重大度分類と、各レベルに応じた対応時間の保証。

発注者の確認ポイント:

• 「重大障害」「軽微な障害」などの定義と判断基準が明確か
• 初動対応時間（障害を認知してから担当者が着手するまでの時間）が定められているか
• 復旧目標時間（RTO: Recovery Time Objective）が設定されているか

業界標準としては、重大障害（システム全体が利用不可）の初動対応は1時間以内、復旧目標は4〜8時間以内が一般的です。ただし、自社のビジネス要件に応じて交渉することが重要です。

障害レベル	定義例	初動対応目標	復旧目標
レベル1（重大）	システム全体が利用不可	30分以内	4時間以内
レベル2（高）	主要機能が利用不可	1時間以内	8時間以内
レベル3（中）	一部機能が影響を受ける	4時間以内	翌営業日まで
レベル4（低）	軽微な不具合	翌営業日以内	1週間以内

SCROLL→

項目④: パフォーマンス指標（レスポンスタイム・スループット）

定義: システムの応答速度や処理能力に関する保証。

発注者の確認ポイント:

• 主要機能のレスポンスタイム目標（例: 「通常操作は3秒以内」）が定められているか
• 測定条件（同時アクセス数・データ量）が現実の業務に即しているか
• 性能劣化（遅延はしているが落ちていない状態）はペナルティの対象になるか

項目⑤: サポート体制（連絡窓口・受付時間・エスカレーション経路）

定義: 障害発生時の連絡先と対応プロセス。

発注者の確認ポイント:

• 専任の担当窓口（特定の個人ではなくチームや代表番号）が設けられているか
• 夜間・休日の緊急連絡先が明確か
• 担当者不在時のエスカレーション経路（誰が代わりに対応するか）が定められているか

関連記事: 保守費用とサポート体制の関係については、「システム保守費用の相場ガイド」も参照してください。

項目⑥: ペナルティ条項（料金減額・違約金）

定義: SLAで定めた水準を下回った場合の補償内容。

発注者の確認ポイント:

• ペナルティの種類（料金減額か、損害賠償か、またはその両方か）
• 適用される条件（「何分のダウンタイムでペナルティが発生するか」）が明確か
• ペナルティの上限額（「月額利用料の何%まで」）が適正か

ペナルティ条項の詳細は次章で解説します。

項目⑦: 免責事項（天災・第三者障害・ユーザ起因の除外条件）

定義: ベンダーが責任を負わない例外条件の定義。

発注者の確認ポイント:

• 免責条件の範囲が広すぎないか（「その他やむを得ない事由」のような包括条項に注意）
• 「第三者サービスの障害」（クラウドインフラ障害など）が免責になる場合の定義
• ユーザ起因（操作ミス・設定変更）の免責範囲が具体的か

稼働率の読み方と計算例——「99.9%」は月何分のダウンタイムか

稼働率の計算式

稼働率（%）= （サービス提供時間 - ダウンタイム）÷ サービス提供時間 × 100

例えば、月間720時間（30日×24時間）のうち、ダウンタイムが0.43時間（約26分）であれば、稼働率は99.94%となります。

稼働率別ダウンタイム早見表

稼働率	月間ダウンタイム許容時間	年間ダウンタイム許容時間	主な適用対象
99%	約7.2時間（432分）	約87.6時間	低優先度の業務システム
99.9%	約43.2分	約8.7時間	一般的な業務システム
99.99%	約4.3分	約52分	重要な業務システム・EC
99.999%	約26秒	約5.3分	金融・医療・重要インフラ

SCROLL→

※ 1ヶ月を30日（720時間）として計算

自社に合った稼働率の選び方

稼働率は高ければ高いほどよいとは限りません。稼働率を高めるにはコストが比例して増加します。

99.9%が適切なケース:

• 社内利用の業務システム（勤怠管理・在庫管理等）
• 平日昼間のみ利用のシステム
• 障害発生時に代替手段がある業務

99.99%以上が必要なケース:

• 24時間・365日利用のECサイト・予約システム
• 金融取引や決済が絡むシステム
• ダウンタイム1分あたりの損失が大きいサービス

「どの稼働率が必要か」を判断するには、「システムが1時間止まったとき、自社はいくらの損失を被るか」を概算しておくことをお勧めします。この損失額と保守費用・稼働率要件を照らし合わせて交渉することで、費用対効果の高い合意ができます。

SLAのペナルティ条項——発注者を守る3つの設計パターン

パターン①: 努力目標型——これは「SLA」と呼べない

「稼働率99.9%を目指します」「可能な限り迅速に対応します」という記載は、法的には単なる努力目標であり、SLAとしての効果を持ちません。

弁護士法人内田・鮫島法律事務所（IT法務.COM）によれば、「ベンダが単独でSLAを作成したとしても、それが契約書と何ら紐づけられていない場合、当該SLAが法的拘束力を有するものとはならない可能性があります」と指摘されています。さらに、SLA違反時の効果が何も規定されていない場合も同様です。

発注者が確認すべきこと: 「この水準を下回った場合、どのような補償が受けられますか？」と明示的に質問し、具体的な答えが返ってこない場合は、そのSLAは「努力目標型」の可能性があります。

パターン②: 料金減額型——最も一般的。上限額の確認が必須

稼働率や対応時間の水準を下回った場合に、月額利用料の一定割合を減額するパターンです。最も一般的な設計です。

典型的な条項例（参考）:

「サービスの稼働率が当月99.9%を下回った場合、下回った程度に応じて、翌月の月額料金から次の金額を差し引く。ただし、減額の合計は当月月額料金の30%を上限とする。

• 稼働率99.0%以上99.9%未満: 月額料金の5%
• 稼働率95.0%以上99.0%未満: 月額料金の15%
• 稼働率95.0%未満: 月額料金の30%」

※ 上記はあくまでも参考例です。法的アドバイスではありません。

落とし穴: 上限額が月額料金の10〜30%に設定されている場合、大きな障害が起きても補償が少額に留まります。システム障害による業務損失が月額保守料を大きく上回る場合、料金減額だけでは実損をカバーできません。

パターン③: 損害賠償型——業務損失まで請求できるが立証が難しい

SLA違反によって生じた実際の損害について賠償を求めるパターンです。理論上は最も発注者を守れますが、実際には損害額の立証が困難で、訴訟リスクも高まります。

実務的には、料金減額型を基本としつつ、重大な違反（長時間のシステム停止・データ消失等）については損害賠償を認める複合型が現実的です。

ペナルティ条項で発注者が交渉すべきポイント

1. 上限額の引き上げ: 「月額料金の10%」の場合、引き上げ交渉をする
2. ペナルティ発生の閾値を下げる: 「99%を下回った場合」ではなく「99.9%を下回った場合」に変更
3. 適用除外の範囲を絞る: 「天災」は認めても「計画外の作業」は免責対象から外す
4. ペナルティの申請手続きを確認: 発注者が申請しなければペナルティが発生しない場合、見逃しリスクがある

SLAの法的拘束力——違反された時に実際に補償は得られるか

重要: このセクションの内容は参考情報です。法的な効果は個々の契約内容・状況によって異なります。専門の弁護士にご相談ください。

SLAが法的拘束力を持つための3条件

SLAが実際に機能するための条件は以下の3点です。

条件①: 契約書と明示的に紐づいていること
SLAが「別紙」として契約書に添付されていても、契約書本文で「本契約にはSLAが適用される」と明記されていなければ、法的拘束力に疑問が生じます。「本契約の別紙として添付するSLA（別紙○号）は本契約の一部を構成する」という条項が契約書本文にあることを確認してください。

条件②: 水準未達時の効果が具体的に定められていること
「努力目標型」ではなく、「○%を下回った場合に月額料金の△%を減額する」という形で、効果が具体的に規定されていること。

条件③: 免責条項が合理的な範囲に限定されていること
過度に広範な免責条項は、公序良俗違反や消費者契約法・不公正取引方法として無効とされる場合があります。「一切の責任を負わない」という包括的な免責は、ベンダーの故意・重過失がある場合には適用されないと解釈される可能性があります。

「契約書と紐づいていないSLA」は有効か

ベンダーのウェブサイトに掲載されている「SLAポリシー」は、契約書に明示的に取り込まれていなければ、法的拘束力がない場合があります。

確認方法: 契約書に「当社のサービス利用規約およびSLAポリシー（https://～）が適用される」という条項があるかを確認してください。URLの参照だけでも条件①を満たす可能性がありますが、SLAの内容が変更された場合の扱いについても確認が必要です。

SLA違反時の対応フロー

SLA違反が発生した際の対応手順を事前に定めておくことが重要です。

1. 記録: 障害発生日時・復旧日時・影響範囲を記録する
2. 通知: 契約に定められた方法でベンダーにペナルティ申請の意思を通知する（申請期限がある場合も多い）
3. 算定: 契約に基づいてペナルティ額を計算する
4. 請求: ベンダーに減額・返金を要求する

「SLA違反のペナルティ申請は当月末までに書面で行う必要がある」といった条件が契約に定められている場合があります。この手続きを知らずにいると、権利を主張できなくなります。

発注者のためのSLA交渉チェックリスト

契約締結前に確認すべき5つの質問

以下の質問にベンダーが明確に回答できるかを確認してください。

No.	質問	確認ポイント
1	稼働率は何%を保証しますか？	数値と測定方法（SLI）の確認
2	SLAは契約書の一部として明文化されますか？	別紙添付か、本文参照か
3	稼働率未達の場合はどのような補償がありますか？	ペナルティの種類と上限
4	免責条件はどのように定義されていますか？	免責範囲の具体性と妥当性
5	ペナルティの申請手続きはどのように行いますか？	申請期限・方法・確認の流れ

SCROLL→

ベンダーが難色を示すが正当な交渉ポイント

1. ペナルティ上限の引き上げ
「月額料金の10%」は低すぎる場合があります。「月額の30%〜50%」を交渉の起点にすることが一般的です。

2. 免責条件の範囲縮小
「やむを得ない事由」「その他合理的な理由」という包括条項の削除・具体化を求めてください。

3. 計画停止の事前通知期間延長
「3日前通知」を「2週間前通知」に変更することで、業務計画を立てやすくなります。

4. 稼働率の測定方法の開示
「月に1回レポートを提供する」「発注者もリアルタイムで稼働状況を確認できるダッシュボードを提供する」ことを求めてください。

5. SLA定期レビューの義務付け
「半年に1回、SLAの内容と実績を共同でレビューする」という条項を追加することで、実態に合わない水準を修正できます。

秋霜堂株式会社のSLAへのアプローチ

秋霜堂株式会社では、保守運用契約において週次定例会議でSLAの状況を発注者と共有する体制を標準化しています。稼働率・対応履歴・直近の課題を定期的に可視化することで、問題が表面化する前に対処できます。継続的な保守運用の実績と、アジャイル開発で培った高速対応力を活かした保守体制については、お問い合わせからご相談ください。

まとめ——SLAを「守られる契約」にするために

SLAは締結するだけでは意味がありません。この記事で解説した要点を振り返ります。

7つの確認項目:
①サービス提供時間、②稼働率、③障害レベルと対応時間、④パフォーマンス指標、⑤サポート体制、⑥ペナルティ条項、⑦免責事項——この7項目が契約書に具体的に盛り込まれているかを確認してください。

ペナルティ設計の重要性:
「努力目標型」のSLAは機能しません。「料金減額型」を基本として、上限額・閾値・申請手続きを明確にすることが重要です。

法的拘束力の確保:
SLAが契約書本文と明示的に紐づいていること、水準未達時の効果が具体的に規定されていること、免責条件が合理的な範囲に限定されていること——この3条件を確認してください。

発注者にとって、SLAは「ベンダーを縛る文書」ではなく「双方の期待値を合わせ、問題発生時に円滑に解決するための共通言語」です。適切に設計されたSLAは、発注者とベンダーの双方が安心して長期的な関係を築くための基盤になります。

関連記事:

• システム保守費用の相場ガイド——保守費用とSLAの関係
• システム開発の見積もりガイド——見積もり時のSLA確認ポイント
• 要件定義から契約フェーズへの流れ——要件定義後の適切な契約設計
• RFPの書き方ガイド——SLA要件をRFPに記載する方法
• システム保守と運用の違い——保守・運用の定義を正しく理解する

本記事の情報は2026年4月時点のものです。法律・規制の改正等により内容が変更される場合があります。

秋霜堂株式会社について

秋霜堂は、Web開発・AI活用・業務システム開発を手がけるシステム開発会社です。要件定義から設計・開発・運用まで一貫してご支援しています。

システム開発のご相談や、自社課題に合った技術的アプローチについてお悩みの方は、お気軽にお問い合わせください。