システム保守のSLAとは — 中小企業が決める障害対応時間・稼働率と費用

SLA（サービスレベルアグリーメント）とは、保守や運用を委託するときに「どこまでの品質を、どんな数字で約束するか」を取り決めたものです。中小企業が決めるべき項目は多くありません。止まったら困る業務を洗い出し、「どれくらいの時間まで止まってよいか（許容停止時間）」と「何分以内に誰が動くか（初動応答時間）」を決めれば、SLAの大半は固まります。稼働率は99.5%前後、対応時間は平日日中が現実的な出発点で、24時間365日対応にすると月額費用は2〜3倍以上になるのが一般的です。本記事では、SLAの基本、主な項目、稼働率の目安、障害の重要度区分、費用への影響、決め方の手順、契約でつまずきやすい落とし穴までを、IT専門ではない経営者・担当者向けに整理します。費用はいずれも市場の一般的な目安であり、実際の金額は契約内容や委託先によって大きく異なります。

SLAは Service Level Agreement の略で、サービスの提供者と利用者の間で「品質の水準」を約束する合意のことです。システム保守の場面では、「障害の連絡から30分以内に初動対応する」「月間稼働率99.5%を目標とする」「未達の場合は月額費用の一部を減額する」といった内容が書かれます。大切なのは、SLAが気合いや誠意の話ではなく、測定できる数字と、守れなかったときの扱いまで含めた約束だという点です。

似た言葉との違いも整理しておきます。SLO（Service Level Objective）は、提供側が社内で目標にしている水準のことで、契約上の約束とは限りません。SLAはそのうち顧客に対して約束する部分です。一方、保守契約はもっと広い概念で、対応範囲、料金、期間、解約条件、データの扱いなどを含む契約全体を指します。SLAは保守契約の中に含まれる「品質の約束」の部分、と考えるとわかりやすいでしょう。保守契約全体で確認すべき点は保守契約書のチェックポイント、保守という仕事そのものの全体像はシステム保守・運用の完全ガイドで詳しく扱っています。

保守のSLAは、突き詰めると「いつ受け付けるか」「どれくらい早く動くか」「どれくらいで直すか」「どこまで戻せるか」「どう知らせるか」の5つに集約されます。契約書やサービス仕様書でこれらがどう書かれているかを順に見ていきます。

この中で中小企業が特に迷いやすいのが、RTOとRPOです。RTO（Recovery Time Objective）は「どれくらいの時間で戻すか」、RPO（Recovery Point Objective）は「どの時点まで戻すか」を表します。たとえばRPOが24時間なら、最悪の場合は前日の夜までのデータしか戻せず、その後の1日分の入力はやり直しになります。RPOを短くするほどバックアップの頻度を上げる必要があり、その分コストが増えます。バックアップや災害復旧の考え方はクラウドバックアップと災害復旧（DR）の基礎で整理しています。

稼働率は「99.9%」のように割合で書かれるため、数字の差が小さく見えます。しかし、許容される停止時間に直すと大きな差があります。月を30日（720時間）、年を365日として計算すると、次のようになります。

多くの中小企業の業務システムでは、99.5%から99.9%が現実的な範囲です。99%と99.9%では、許容される停止時間が10倍違います。一方で、99.9%から99.99%に上げるには、サーバーの冗長化や24時間体制の監視など、構成と運用の両面で大きな投資が必要になります。「止まらないに越したことはない」という理由だけで高い数字を選ぶと、費用が膨らむ割に、事業への効果は小さいことがあります。

もう一つ注意したいのは、稼働率の数字だけでは使い勝手がわからないことです。同じ99.5%でも、月に3.6時間が一度に止まる場合と、数分の停止が何十回も起きる場合では、現場の困り方がまるで違います。また、夜間や休日の停止は業務への影響が小さい一方で、締め日や繁忙期の日中に止まると大きな損失になります。稼働率に加えて、1回あたりの最大停止時間や、重要な時間帯の扱いも確認しておくと安心です。

すべての障害を同じ優先度で扱うことはできません。そこで多くの保守契約では、影響の大きさで障害を区分し、区分ごとに初動応答時間や復旧目標を決めます。区分の名称や数はさまざまですが、4段階程度に分けるのが一般的です。下の表は一例で、数値は目安です。

この区分で重要なのは、「誰が、どの基準で区分を決めるか」を事前に決めておくことです。利用者側は何でもS1だと感じがちで、提供側は軽く見積もりがちです。具体例を契約書や運用ルールの別紙に添えておくと、障害のたびに揉めるのを防げます。夜間・休日のS1だけを対象にする、S3以下は営業時間内のみ対応する、といった組み合わせも現実的な選択肢です。

SLAの水準は、月額の保守費用に直接はね返ります。夜間や休日にも人が待機する体制は、人件費がそのまま上乗せされるからです。市場の一般的な傾向としては、平日日中（たとえば9時〜18時）のみの対応を基準とすると、夜間・休日の緊急対応を含めた場合は1.5〜2倍程度、24時間365日の即時対応を求める場合は2〜3倍以上になることが多いと言われます。以下は、中小企業向けの保守でよく見られる構成の目安です。委託先、システムの規模、構成によって大きく変わるため、あくまで比較のための参考として見てください。

たとえば、平日日中の保守が月額3万円前後の水準だとすると、24時間365日の体制では6万〜10万円以上になるイメージです。ただし、これは対応時間の長さだけの話です。冗長構成やバックアップの強化、監視ツールの利用料などが加わると、さらに上がります。費用の上昇に見合うかどうかは、停止したときの損失額で判断します。1時間止まると売上がいくら失われるか、人件費がいくら無駄になるか、信用への影響はどうか。この損失の見積もりが、SLA水準を決める最も確かな根拠になります。保守費用全般の考え方はシステム保守・運用の完全ガイドも参考になります。

SLAを決めるといっても、最初から細かい数字を詰める必要はありません。次の順番で考えると、無理なく現実的な水準にたどり着けます。

- ステップ1：止まったら困る業務を洗い出す。受注、出荷、請求、勤怠、メール、Webサイトなど、システムごとに「止まると誰が何に困るか」を書き出す
- ステップ2：許容停止時間を決める。業務ごとに「何時間までなら手作業や電話で代替できるか」を現場に聞く。代替手段があるものは水準を下げてよい
- ステップ3：重要な時間帯を決める。締め日、繁忙期、営業時間など、止まると特に困るタイミングを確認する。24時間体制が必要かは、夜間・休日に実際に使うかで決まる
- ステップ4：RPO（どこまで戻せるか）を決める。1日分の入力をやり直せるのか、1時間分でも困るのかを確認し、バックアップの頻度に反映する
- ステップ5：費用とのバランスを取る。理想の水準で見積もりを取り、停止時の損失額と比べる。すべてを高水準にせず、重要なシステムだけ高く、他は標準にする

ポイントは、システムごとにメリハリをつけることです。受注に使うシステムは平日日中と夜間の緊急対応を付ける、社内の情報共有ツールは通常の対応でよい、というように分ければ、全体の費用を抑えながら必要な場所を守れます。ひとつの契約ですべてを同じ水準にするより、システムごとに水準を選べる契約のほうが、中小企業には向いています。

AWS、Microsoft Azure、Microsoft 365、Google Cloudなどの主要なクラウドサービスは、それぞれ自社のSLAを公開しています。たとえば月間稼働率の保証値が示され、それを下回った場合は利用料金の一部が返ってくる仕組みです。ただし、これはクラウド事業者が「基盤」について約束するものです。その上で動く、御社の業務アプリケーションの設定ミスや、自社で作ったシステムの不具合まで保証しているわけではありません。

つまり、保守を委託する場合、SLAは二層構造になります。ひとつはクラウド事業者のSLA（基盤の稼働）、もうひとつは保守委託先とのSLA（アプリケーションや運用の対応）です。委託先が99.9%を約束していても、基盤そのものが99.9%に満たないサービスの上で動いていれば、実質的にはそれ以上の数字は望めません。また、複数のサービスを組み合わせたシステムの稼働率は、それぞれの稼働率を掛け合わせた値に近づきます。99.9%のサービスを3つつなげると、全体は約99.7%です。契約を結ぶ前に、使っているクラウドのSLAを確認し、保守委託先のSLAがその範囲を超えた約束になっていないかをチェックしておきましょう。

SLAは書かれていれば安心、というものではありません。実際には次のような点で、期待と契約内容がずれることが多くあります。

特に、サービスクレジットの限界は誤解されやすい点です。SLAが未達になっても、受け取れるのは月額費用の数%から数十%程度の減額というケースが多く、実際の業務損失をカバーするものではありません。SLAは「返金を得る手段」ではなく、「障害を起こさせない・早く直すための約束」として捉え、損失に備える手段はバックアップや保険、手作業の代替手順など、別の形で用意しておくのが現実的です。

最後に、SLAを含む保守契約を結ぶ前に、確認しておきたい項目をまとめます。すべてに「はい」と答えられなくても、空欄になっている項目を把握しておくことが大切です。

- 止まると困る業務と、許容できる停止時間を書き出したか
- 受付時間と対応時間が分けて書かれており、夜間・休日の扱いが明確か
- 初動応答時間が「人が反応するまでの時間」として定義されているか
- 障害の重要度区分があり、誰が判断するかが決まっているか
- RTO（復旧目標）とRPO（データを戻せる時点）が、「保証」か「目標」か明記されているか
- 稼働率の対象範囲、計画停止の扱い、測定方法が書かれているか
- SLA未達時の補償内容と上限が確認できているか
- 利用しているクラウドのSLAと、委託先のSLAに矛盾がないか
- 月次などの定期報告で、稼働実績や障害の内容を数字で受け取れるか
- SLAを見直す時期（たとえば年1回）が決まっているか