【クラウド法務】「SLA」と「約束された復旧」を同じ意味で使ってはいけない理由― “稼働率の話”と“復旧の約束”を混ぜた瞬間、監査・取引先・経営説明が崩れる ―

※本記事は一般的な情報提供であり、個別案件の法的助言ではありません。

────────────────────────────

はじめに

────────────────────────────

クラウド導入の説明で、よく起きる“危ない会話”があります。

情シス：「AzureはSLAがあるので大丈夫です」

経営：「じゃあ止まってもすぐ戻るんだね？」

営業：「取引先に“復旧は保証されてます”って言っていい？」

このやり取り、技術的にはそれっぽく聞こえます。

しかし実務・契約・説明責任の観点では、かなり危険です。

結論から言うと、「SLA」と「約束された復旧（RTO/RPO）」は別物で、同じ意味で使うと、事故時・監査・取引先審査・経営説明の場面で確実に詰みます。

本記事では、なぜ混ぜてはいけないのか、どう言い換えれば事故らないのかを整理します。

────────────────────────────

技術構成の“事実整理”：SLAと「復旧の約束」が指している対象が違う

────────────────────────────

まずは用語を、技術の言葉で整理します。

────────────────────────────

SLAとは何か（多くの場合のイメージ）

────────────────────────────

SLAは、サービス提供者が提示する 稼働率（可用性） を中心とした指標・合意です。

一般的には

・稼働率（例：月間99.9%等）

・計測条件（どこから見て“稼働”とみなすか）

・免責や除外（計画停止、顧客側要因など）

・未達のときの救済（多くはサービスクレジット等）

がセットです。

ポイント

SLAは「落ちないこと」を示す指標ではなく、**落ちた場合の“評価の枠”**に近いです。

────────────────────────────

「約束された復旧」とは何か（RTO/RPO）

────────────────────────────

一方、取引先や経営が本当に聞きたいのは、復旧の約束です。

代表がRTO/RPOです。

・RTO（Recovery Time Objective）

　止まったとき、どれくらいの時間で業務を復旧できるか（復旧までの目標時間）

・RPO（Recovery Point Objective）

　どこまでデータが戻る想定か（許容されるデータ損失量）

これはクラウド事業者のSLAだけで決まりません。

自社の設計・運用・復旧手順・復旧テストで決まります。

（ここまでは技術の話。ここからが法務・説明責任の話です。）

SLAと復旧の約束を混ぜると危険なのは、

「対象」「責任主体」「根拠」「救済」が全部違うからです。

────────────────────────────

2. 「SLA」と「約束された復旧」を同じ意味で使ってはいけない理由（4つ）

────────────────────────────

────────────────────────────

理由①：SLAは“稼働率の条件”であって、“復旧時間の約束”ではない

────────────────────────────

SLAは、稼働率の測定・評価の枠です。

稼働率が高いことと、復旧が早いことは関係はありますが、同義ではありません。

落とし穴

「99.9%だから、止まっても短いはず」

→ 取引先が欲しいのは「何時間で戻るか」であり、稼働率ではありません。

特にクラウド事故では

・依存関係（ID、ネットワーク、DNS、鍵管理、ログ）

・自社設定ミス（NSG、条件付きアクセス、権限、ルーティング）

・運用委託の連絡遅延

などで復旧が遅れることが多く、SLAだけでは説明できません。

────────────────────────────

理由②：SLAの“救済”は、たいていサービスクレジットで、あなたの損害を補填しない

────────────────────────────

SLA未達時の救済が、実損補償ではなく「サービスクレジット（料金減額等）」であることは珍しくありません。

つまり、取引先に対する損害賠償や、売上損失、信用毀損を直接カバーしません。

危険なすり替え

「SLAがある＝損害がカバーされる」

→ 実務では、事故後に“会社としての損失”は残ります。

経営の顔色が変わるのはここです。

SLAがあっても、事業損失は埋まりません。

────────────────────────────

理由③：「復旧の約束」は、自社の体制（BCP）と委託契約（SOW）で決まる

────────────────────────────

RTO/RPOは、クラウド事業者のSLAだけでは決まりません。

・バックアップ設計（保持、世代、復旧点）

・冗長化構成（ゾーン、リージョン、複数系統）

・復旧手順書（誰が何をするか）

・復旧テスト記録（本当に戻るか）

・委託先（MSP/SOC）の対応時間、夜間休日体制

・ログ提出や保全の体制（事故対応の速度）

これらが無い状態で「SLAがあるので大丈夫」と言うと、

取引先に対して“復旧を約束したように聞こえる”のに、根拠がない、という危険な状態になります。

────────────────────────────

理由④：契約・監査の場面では「SLA」より「RTO/RPOを根拠付きで言えるか」が問われる

────────────────────────────

監査や取引先審査が成熟してくると、質問はこう変わります。

・「停止時の復旧目標は？（RTO）」

・「データ損失の許容は？（RPO）」

・「その根拠は？（復旧テスト記録、手順書）」

・「委託先を含む体制は？（RACI）」

・「事故時の一次通知は何分以内？」

ここでSLAの説明をしても、質問に答えたことになりません。

SLAと復旧の約束を混ぜると、説明が噛み合わず、信頼が落ちます。

────────────────────────────

3. どう説明すれば事故らないか：言い換えテンプレ（情シス・営業・経営向け）

────────────────────────────

ここからは、そのまま社内で使える言い換えの型です。

────────────────────────────

（A）情シスが言うべきテンプレ

────────────────────────────

悪い例

「SLAがあるので大丈夫です」

言い換え（安全）

「SLAは稼働率の指標で、復旧時間を直接約束するものではありません。

復旧の目標（RTO/RPO）は、当社の設計と運用・復旧手順で決まります。

現時点の目標はRTO○時間／RPO○時間（または○世代）で、根拠は復旧手順書とテスト結果です。」

────────────────────────────

（B）営業が取引先に言うべきテンプレ

────────────────────────────

悪い例

「クラウドなのでSLAがあります。復旧も保証されます」

言い換え（安全）

「クラウド事業者のSLA（稼働率指標）とは別に、当社としての復旧目標（RTO/RPO）を定義しています。

障害時の対応手順・体制、復旧テストの記録に基づいて説明可能です。

必要であれば、提出可能な範囲でその概要を共有します。」

※ここで「保証」という言葉は、契約とセットでない限り危険なので避けるのが無難です。

────────────────────────────

（C）経営に説明するときのテンプレ

────────────────────────────

「SLAは“落ちにくさの指標”で、事業継続の約束そのものではありません。

当社としてのBCPはRTO/RPOで管理し、復旧手順書・復旧テスト・委託先を含む体制（RACI）で担保します。

取引先に約束する場合は、その根拠（成果物）と契約表現をセットで整えます。」

────────────────────────────

4. 「約束された復旧」を作るために最低限必要な成果物（3点）

────────────────────────────

RTO/RPOを“言える”だけでは足りません。

監査や取引先に耐えるには、最低限この3点が必要です。

────────────────────────────

成果物①：RTO/RPO一覧（システム別の目標と根拠）

────────────────────────────

・システムごとの目標（RTO/RPO）

・根拠（バックアップ設計、冗長構成、手順書、テスト）

・例外（手作業が必要、外部依存がある等）

────────────────────────────

成果物②：復旧手順書＋復旧テスト記録（根拠の中身）

────────────────────────────

・誰が（責任者・実行者）

・何を（復旧手順）

・どの順番で（依存関係）

・どれだけ時間がかかったか（テスト結果）

────────────────────────────

成果物③：委託先を含むタスク別RACI（事故対応まで）

────────────────────────────

・一次通知（何分以内）

・封じ込め

・ログ保全

・復旧判断

・対外説明の承認

・委託先の対応範囲（SOWで義務化されているか）

これが揃うと、「SLAの話」と「復旧の約束の話」をきれいに分けて説明できます。

────────────────────────────

5. ケーススタディ（匿名化）：SLAを復旧保証のように説明して取引先審査で止まった例

────────────────────────────

背景

・Azure移行中。経営説明で「SLAがあるので止まらない」的な表現が混ざる

・取引先審査でBCPの質問が入り始める

取引先の質問

・RTO/RPOは？根拠は？

・復旧テストは？

・委託先を含む体制は？一次通知は？

・ログ提出は何営業日以内？

詰まった理由

・SLAの説明はできるが、RTO/RPOを根拠付きで言えない

・復旧手順書・復旧テスト記録が整っていない

・委託先の対応時間や範囲がSOWで固定されていない

立て直し

・RTO/RPOをシステム別に定義し、復旧テストで根拠化

・タスク別RACIを作成し、委託先の義務（通知、復旧支援）をSOWに落とす

・対外説明では「SLA」と「復旧目標」を分けて話す運用へ

結果

・説明が安定し、取引先審査での質疑が収束した

────────────────────────────

6. すぐ使えるチェックリスト

────────────────────────────

□ 社内で「SLA」と「復旧目標（RTO/RPO）」が混ざった表現をしていない

□ 取引先に出す説明で「保証」という言葉を安易に使っていない

□ システム別にRTO/RPOが定義されている（根拠がある）

□ 復旧手順書と復旧テスト記録がある

□ 委託先を含む事故対応RACIがある（一次通知、復旧、保全）

□ 復旧に必要な前提（権限、手順、連絡経路）が整っている

□ 監査・取引先向けに、提出できる範囲のBCP説明資料がある

YESが揃わない場合、「SLAがあるので大丈夫」は言わない方が安全です。

────────────────────────────

7. 全国からのご相談について

────────────────────────────

山崎行政書士事務所では、Azure / M365 等のクラウド運用について、

技術構成（バックアップ・復旧設計）と、契約・規程・監査対応をセットで整理し、

「SLAの説明」ではなく「約束された復旧（RTO/RPO）を根拠付きで説明できる」状態に整えるクラウド法務支援を行っています。

・取引先にRTO/RPOをどう説明すべきか整理したい

・復旧手順書・復旧テスト記録を“約束の根拠”として整備したい

・委託先（MSP/SOC）を含めた責任分界（RACI）とSOWを固めたい

・BCPを“技術の話”から“説明できる約束”に変換したい

といったお悩みがあれば、オンライン（全国対応）でご相談を承っております。

お問い合わせの際に「SLAと復旧の違いの記事を見た」と書いていただけるとスムーズです。