システム保守のSLA（サービスレベル合意＝対応時間や稼働率などの約束）は、厳しくするほどよいものではありません。障害時の事業影響を基準に、受付時間、初動時間、復旧目標、稼働率、除外条件、報告方法を数値化し、費用と実現体制を確認して契約することが重要です。
システム保守のSLAとは何か
SLAは、保守会社が提供するサービスの範囲と水準を、発注者との間で測定可能な形にするための合意です。「できるだけ早く対応する」といった曖昧な表現を避け、どの障害に、いつまでに、何をするのかを明確にします。
正式にはService Level Agreementの略で、一般的には保守契約書、運用保守仕様書、SLA別紙などに記載します。SLAを設ける主な目的は、障害を完全になくすことではなく、問題が起きた際の対応を予測可能にすることです。
SLA・SLO・SLIの違い
似た用語としてSLOとSLIがあります。契約を確認する発注者は、次の違いを押さえておけば十分です。
| 用語 | 意味 | 発注者が確認するポイント |
|---|---|---|
| SLA | 発注者と保守会社が合意するサービス水準 | 契約上の対象、計測方法、未達時の扱い |
| SLO | サービスレベル目標＝運用品質の個別目標 | SLAを守れる余裕のある目標か |
| SLI | サービスレベル指標＝品質を測る数値 | 稼働率や応答時間をどこでどう測るか |
たとえばSLAで月間稼働率99.9％以上を約束する場合、保守会社側では99.95％以上をSLOとして管理することがあります。実績値として計測される月間稼働率がSLIです。
ただし、SLAはシステムの品質を無条件に保証するものではありません。クラウド事業者の障害、発注者による設定変更、外部サービスの停止、事前に告知されたメンテナンスなどは対象外になることがあります。契約時には数値だけでなく、対象範囲と除外条件を見る必要があります。
SLAを設けたほうがよいシステム
特にSLAを設ける意義が大きいのは、停止時の事業影響が明確なシステムです。
- ECサイトや予約サイトなど、停止が売上に直結するサービス
- 取引先や顧客が常時利用するWebサービス
- 店舗、工場、物流などの業務を支える基幹システム
- 個人情報や機密情報を扱い、事故時の報告が必要なシステム
- 複数の外部システムと連携し、障害箇所の切り分けが必要なシステム
- 社内外に対する復旧見込みの報告が求められるシステム
一方、停止しても翌営業日の対応で業務を継続できる社内ツールに、24時間365日の厳格なSLAを設定すると、得られる効果に対して費用が高くなる可能性があります。重要なのはシステムの規模ではなく、停止したときの影響です。
SLAで決める項目と水準の目安
SLAでは、受付時間、障害レベル、初動時間、復旧目標、稼働率、連絡・報告方法を一組で決めます。「初動30分」だけを記載しても、障害の定義や計測開始時点が曖昧なら実務では機能しません。
SLAに盛り込む基本項目
| 項目 | 決める内容 | 注意点 |
|---|---|---|
| 対象システム | 画面、API、管理機能、バッチ処理、インフラなど | 外部サービスや社内ネットワークを含むか明記する |
| サービス提供時間 | システムが利用される曜日・時間 | 受付時間と混同しない |
| 問い合わせ受付時間 | 保守窓口が連絡を受け付ける時間 | メール送信可能時間ではなく、対応を開始する時間を見る |
| 障害レベル | 重大、重要、軽微などの分類条件 | 機能数ではなく事業影響で分類する |
| 初動時間 | 受付から確認・連絡を行うまでの時間 | 復旧時間とは異なる |
| 暫定対応時間 | 回避策や代替手段を提示する目標 | 完全復旧との違いを定義する |
| 復旧目標 | サービスを再開するまでの目標 | 原因調査や恒久対応の完了とは分ける |
| 稼働率 | 一定期間に利用できた割合 | 計測地点、計算式、除外時間を明記する |
| バックアップ | 頻度、保存期間、復元確認 | 取得だけでなく復元できるかを確認する |
| 報告 | 連絡手段、更新間隔、障害報告書 | 誰にいつ報告するかを決める |
| セキュリティ対応 | 脆弱性や情報漏えい疑いへの対応 | 通常障害と異なる連絡経路が必要な場合がある |
| 除外条件 | 計画停止、不可抗力、発注者の操作など | 広すぎる除外条件になっていないかを見る |
| SLA未達時の扱い | 改善報告、減額、契約見直しなど | 損害賠償条件と区別する |
発注者が特に誤解しやすいのが、初動時間と復旧時間の違いです。「初動1時間」は、多くの場合、受付確認や調査開始、担当者からの最初の連絡までを意味します。1時間以内の復旧を約束するものではありません。
見積もりを依頼する際は、「対応1時間以内」とだけ伝えず、次のどこまでを求めるのかを明確にしてください。
- 問い合わせの受領連絡
- 担当者による調査開始
- 影響範囲と状況の一次報告
- 暫定的な回避策の実施
- サービスの復旧
- 原因の特定と恒久対応
障害レベル別に目標を変える
すべての問い合わせに同じ対応時間を設定すると、費用が膨らむだけでなく、本当に重要な障害への対応が遅れる可能性があります。次の表は、小規模から中規模の業務システムやWebサービスを想定した設定例です。実際の数値は事業影響と保守体制に応じて調整します。
| 障害レベル | 事象の例 | 初動の例 | 状況報告の例 | 復旧方針 |
|---|---|---|---|---|
| 重大 | 全利用者がログインできない、決済できない、情報漏えいの疑い | 30分～1時間以内 | 30分～1時間ごと | 最優先で暫定復旧を目指す |
| 重要 | 一部機能が使えない、多数の利用者に影響する | 1～2時間以内 | 1～2時間ごと | 代替手段を示し営業時間内の復旧を目指す |
| 軽微 | 表示崩れ、操作方法の問い合わせ、代替手段がある不具合 | 4時間～翌営業日 | 必要時 | 通常の改修計画へ組み込む |
「重大障害」の判断は保守会社だけに任せず、事業上の基準を含めることが大切です。たとえば利用者が少なくても、月末の請求処理が止まれば重大障害に該当する場合があります。
稼働率は小数点以下の違いが大きい
月間稼働率は、数字が少し違うだけでも許容される停止時間が大きく変わります。1か月を平均30.4日として単純計算した場合の目安は次のとおりです。
| 月間稼働率 | 1か月に許容される停止時間の目安 |
|---|---|
| 99.0％ | 約7時間18分 |
| 99.9％ | 約43分49秒 |
| 99.95％ | 約21分55秒 |
| 99.99％ | 約4分23秒 |
99.99％を求めるには、保守担当者を増やすだけでは不十分です。サーバーやネットワークの冗長化、障害の自動検知、切り替え設計など、システム構成そのものへの投資が必要になることがあります。
また、同じ99.9％でも、計画メンテナンスを停止時間に含めるか、外部サービスの障害を除外するかで実質的な水準は異なります。ログイン画面が表示できたら稼働とみなすのか、決済や予約完了まで確認するのかという計測地点も重要です。
RTOとRPOも確認する
災害や大規模障害を想定する場合は、次の2項目も決めます。
- RTO（目標復旧時間＝停止後、何時間以内にサービスを戻すか）
- RPO（目標復旧時点＝最大でどの時点までのデータ消失を許容するか）
たとえばRPOが24時間なら、最悪の場合は前日のバックアップ取得後に登録されたデータを失う可能性があります。データをほぼ失わない目標にすると、バックアップやデータ複製の構成が複雑になり、費用も上がります。
SLA付き保守の費用相場と見積もりの見方
**SLA付き保守の費用は、システム規模よりも対応時間帯、初動時間、必要人数、障害時の責任範囲に左右されます。**厳格なSLAほど待機要員や監視環境が必要になるため、通常の保守より高くなる傾向があります。
小規模から中規模のWebサービス・業務システム1つを対象とした一般的な月額目安は、次のとおりです。クラウド利用料、外部サービス利用料、大規模改修費は含まない想定です。
| 保守体制 | 月額費用の一般的な目安 | 向いているケース |
|---|---|---|
| ベストエフォート型 | 5万～20万円程度 | 代替手段があり、翌営業日の対応でも支障が小さい |
| 平日日中のSLA付き | 15万～50万円程度 | 営業時間中の業務停止を早期に解消したい |
| 夜間・休日を含む拡張保守 | 20万～80万円程度 | 土日営業や夜間処理がある |
| 24時間365日対応 | 50万～200万円以上 | 常時稼働が必要で、停止の損失が大きい |
これはあくまで一般的な目安です。同じ24時間365日対応でも、「電話を受け付けるだけ」なのか、「技術者が調査し復旧操作まで行う」のかで費用は大きく異なります。大規模システム、複数拠点、複雑な外部連携、高度なセキュリティ要件がある場合は、目安を超えることがあります。
運用開始前には、次のような初期費用が発生する場合もあります。
- システム構成や既存資料の調査
- 監視項目と通知条件の設計
- 障害対応手順書の作成
- 連絡網とエスカレーションルールの整備
- アカウント、ソースコード、クラウド環境の引き継ぎ
- バックアップからの復元テスト
- 障害訓練や運用リハーサル
初期費用は、資料が整った比較的単純なシステムで20万～50万円程度、調査や手順整備を広く伴う場合は50万～150万円以上が一般的な検討範囲です。仕様書やソースコードが不足している場合は、別途調査費用が必要になることがあります。
保守費用全体の考え方は、関連記事のシステム保守費用の相場｜契約・見積もりの見方でも解説しています。
見積もりで分けて確認する費用
SLA付き保守の見積書では、総額だけでなく、少なくとも次の内訳を確認してください。
- 基本保守料に含まれる作業時間
- 監視費用と監視対象数
- 夜間・休日の待機費用
- 緊急出動や時間外作業の単価
- 障害調査と復旧作業の無料・有料範囲
- 軽微な修正に使える時間枠
- 月間作業時間を超過した場合の単価
- クラウドや監視サービスの利用料
- 月次報告会や改善提案の費用
- SLA設計、引き継ぎ、手順書作成の初期費用
「月額10万円、24時間受付」と書かれていても、夜間は受付だけで技術者の調査が翌営業日になる契約はあります。受付、初動、技術調査、復旧作業を分けて確認することが重要です。
SLAを厳しくする前に費用対効果を計算する
SLA水準は、次の3つを比較して決めます。
- 1時間停止した場合に発生する売上損失や人件費
- 顧客への告知、返金、手作業への切り替えにかかる負担
- SLAを厳しくするための追加保守費用とシステム改善費
たとえば夜間停止の影響がほとんどないサービスなら、24時間365日対応より、翌朝の営業開始前までに復旧できる体制のほうが合理的です。反対に、停止中も注文機会を失い続けるサービスでは、月額保守費が上がっても早期復旧へ投資する意味があります。
SLAの決め方と保守会社の選び方
**SLAは、希望する数値を先に置くのではなく、業務影響の整理から始めます。**発注のご相談を受ける開発会社の立場では、「重大障害は30分以内に復旧できますか」と聞かれることがありますが、現行システムの構成や復旧手段を確認せずに回答することはできません。
SLAを決める6つのステップ
1. 対象システムと利用時間を整理する
どの機能が、誰に、いつ使われているかを整理します。通常の営業時間だけでなく、月末処理、給与計算、キャンペーン、決算期など、限定的に重要度が高まる時期も確認してください。
2. 停止時の事業影響を評価する
機能ごとに、売上、顧客、社内業務、法令・契約、情報セキュリティへの影響を評価します。「停止した機能の数」ではなく、「止まった結果、何が起きるか」が判断基準です。
3. 障害レベルを定義する
重大、重要、軽微などの分類条件を文章で定めます。判断に迷う事象が発生した場合に、最終的に誰がレベルを決めるかも明確にします。
4. 対応時間と復旧目標を置く
初動、一次報告、暫定対応、復旧、恒久対応を分けて目標を設定します。保守会社には、その数値を実現するための人数、監視方法、連絡経路も説明してもらいます。
5. 計測方法と除外条件を決める
計測開始は利用者からの連絡時刻か、監視による検知時刻かを決めます。稼働率については、計測対象、計画停止、外部サービス障害などの扱いを明文化します。
6. 契約前に障害対応を模擬する
代表的な障害を想定し、誰が連絡し、誰が判断し、どの順番で復旧するかを机上で確認します。契約書の数値を読むだけでは見つからない連絡先の不足や権限の問題を確認できます。
発注前の準備チェックリスト
次の資料や情報を準備すると、保守会社が現実的なSLAと見積もりを提示しやすくなります。
- システムの利用者、利用時間、繁忙期
- 重要機能と停止時の影響
- システム構成図と外部サービス一覧
- ソースコード、設計書、アカウントの保有状況
- 過去1～2年程度の障害履歴と対応記録
- 現在の監視項目と通知先
- バックアップ頻度と復元実績
- 発注者側の緊急連絡先と意思決定者
- 夜間・休日に発注者側が対応できる範囲
- 希望予算と許容できる停止時間
既存の保守会社から切り替える場合は、SLAを決める前に、ソースコード、クラウドアカウント、ドメイン、証明書、監視設定などを引き継げるか確認してください。具体的な準備は開発会社の変更方法｜引き継ぎ費用と手順で解説しています。
保守会社を見極める質問
保守会社の提案を比較するときは、「対応できます」という回答だけでなく、実現方法を確認します。
- 重大障害を誰が、どの基準で判定しますか
- 夜間・休日は技術者が対応しますか、それとも受付だけですか
- 主担当者が不在の場合の代替要員はいますか
- 障害検知から発注者への連絡まで、どのような流れですか
- 外部サービス障害の切り分けは保守範囲に含まれますか
- 過去の障害から改善につなげる仕組みはありますか
- 月次報告書と障害報告書のサンプルを提示できますか
- バックアップからの復元テストは実施しますか
- 再委託先を含む連絡・セキュリティ体制はどうなっていますか
- 契約終了時に手順書や監視設定を引き渡せますか
体制図に多くの担当者が書かれていても、実際に夜間対応できる技術者が1人だけという場合があります。人数だけでなく、担当者の役割、勤務時間、代替要員を確認してください。
SLA契約でよくある失敗
必要以上に厳しい数値を求める
稼働率99.99％や復旧1時間以内といった数値を置いても、システム構成が対応していなければ実現できません。契約交渉だけでなく、監視、冗長化、バックアップ、復旧手順への投資を含めて検討します。
初動と復旧を混同する
保守会社は初動時間を回答しているのに、発注者は復旧時間だと理解しているケースがあります。各時間の終了条件を文章で定義してください。
発注者側の役割を決めていない
保守会社が修正を準備しても、公開承認やクラウド権限がなければ復旧できません。夜間に誰が承認するか、緊急時に保守会社へどこまで権限を与えるかを決めます。
外部サービスを考慮していない
決済、メール配信、地図、認証などの外部サービスが停止した場合、保守会社だけでは復旧できません。問い合わせ代行、利用者への告知、代替手段の準備をSLAや運用手順に含めます。
SLA未達時の減額だけを重視する
サービスクレジット（＝SLA未達時に利用料を減額する仕組み）があっても、事業停止そのものは解消されません。未達原因の分析、改善計画、再発防止策、繰り返し未達となった場合の契約見直し条件まで決めることが大切です。
契約後に見直さない
利用者数、営業時間、外部連携、事業上の重要度は変化します。少なくとも年1回、または大きな機能追加や障害の後に、SLAが現状に合っているか確認します。
SLAの新設や既存保守契約の見直しを具体的に進めたい場合は、現行資料や障害履歴を整理したうえで開発のご相談はこちらからご相談ください。
まとめ
- SLAは、保守会社の受付時間、初動、復旧目標、稼働率、報告方法などを数値化する合意です
- 厳しいSLAが常に適切とは限らず、停止時の売上・顧客・業務への影響から水準を決めます
- 初動時間は復旧時間ではないため、一次報告、暫定対応、復旧、恒久対応を分けて定義します
- 月間稼働率は計測地点、計画停止、外部サービス障害などの除外条件まで確認します
- SLA付き保守の月額費用は、平日日中で15万～50万円程度、24時間365日対応で50万～200万円以上が一般的な検討範囲です
- 見積もりでは、受付だけか技術者が復旧するのか、時間外費用や作業時間の上限も確認します
- 発注者側にも、障害レベルの判断、公開承認、緊急連絡、必要な権限を提供する役割があります
- 契約前には机上訓練を行い、契約後も事業やシステムの変化に合わせて定期的に見直します
よくある質問
SLAとSLOの違いは何ですか？
SLAは発注者と保守会社が契約として合意するサービス水準です。SLOはサービス提供者が管理する個別の目標値で、SLAを守るためにSLAより厳しく設定されることがあります。
障害の初動時間は何分に設定すべきですか？
一律の正解はありません。売上や顧客対応が停止する重大障害は30分から1時間以内、代替手段がある障害は2時間から翌営業日など、事業影響と保守費用のバランスで設定します。
24時間365日のSLAは必要ですか？
夜間や休日にも利用され、停止による損失が大きいシステムでは検討する価値があります。営業時間外の影響が小さい社内システムなら、平日日中の保守と緊急連絡の組み合わせで十分な場合があります。
SLA違反が発生した場合はどうなりますか？
契約内容によって異なります。サービスクレジット、月額費用の減額、改善計画の提出などを定める方法がありますが、損害賠償や契約解除の条件とは分けて明記することが重要です。