使っているSaaSが止まった日に業務を止めない備え：SLAの読み方と代替手段の決め方(2026)

朝、メールにも社内チャットにもログインできない。状況を聞こうにも、そのチャットが落ちている。SaaSの障害はこういう形で来ます。この記事は、中小〜中堅企業の情シス・総務・バックオフィス担当に向けて、数十分から数時間の停止を事故にしないための準備を4つの手順にまとめたものです。災害対策やBCP(事業継続計画)の策定ではなく、明日から始められる日常の備えを扱います。

最終更新: 2026年9月21日／引用した公的資料・規約は、すべて同日に原文を確認しています。業務の区分・手順・所要時間・金額の試算・チェックリストは編集部が作成したもので、引用した資料に同じ区分や手順があるわけではありません。出典の記述と編集部の解釈が隣り合う箇所にだけ「(編集部)」と付けています。本記事は業務手順の解説であり、契約条項の解釈や適用の可否を判断するものではありません。

SaaSが止まったとき、自社にできることは何か

IPA(情報処理推進機構)の「中小企業の情報セキュリティ対策ガイドライン」第4.0版は、クラウドサービスのセキュリティ対策について、利用者の役割と責任範囲は「直接対策を講じることができるパソコン・スマートフォンなどの端末やネットワーク機器、それらにインストールされたソフトウェアに限定されます」と整理しています。セキュリティの文脈の記述ですが、サーバー側に手を出せない構図は、止まったときも同じです(編集部)。同じIPAの「中小企業のためのクラウドサービス安全利用の手引き」も、サービスを選ぶときのチェック項目3で「クラウドサービスで取扱う情報が漏えい、改ざん、消失したり、サービスが停止した場合の影響を確認しましたか？」と問うています。次の4手順は、この確認を実際の備えに落とすものです。

所要時間は編集部の目安で、実測ではありません。

手順1：止まったら困る順に、業務をA・B・Cに仕分ける

部門長と1時間とり、業務を書き出します。「経理」ではなく「請求書の発行」「入金消込」のように、担当者が1日のうちに着手する単位で出すのがこつです。出した業務に、下の表を上の行から順に当て、最初に当てはまった段階で止めます。

区分・条件・業務例は編集部の作成です。業務例は一般的な中小〜中堅企業を想定しているので、自社の業務に入れ替えてください。

表のAの条件にある「当日中に取り返せない」が、Aを絞り込む基準です。社外やお金に関わる業務でも、復旧後に処理して当日中に取り返せるならBとして扱い、連絡の代替経路だけ確保します。Aは、当日の担当者が代わりの手段へ切り替えて回せる数までに収めます。

Aに残った業務には、次の1文を書きます。「〇〇が止まったら、△△で進め、復旧後に□□へ転記する」。たとえば「受注管理が止まったら、当日分は紙の伝票で受け、復旧後に受注管理へ転記する」。この1文が当日の手順書そのものになります。「復旧を待つ」としか書けない業務は、その場で悩まず一覧の末尾に回します。多くは「そのSaaSにしかデータが無い」ことが原因で、手順2の手元コピーで解消します。

従業員20人の卸売業を想定すると、書き出した18件のうちAが3件(受注入力、出荷指示、顧客からの電話対応)、A(連鎖)が1件(配送担当への当日連絡に使う社内チャット)、Bが9件、Cが5件、といった落ち方になります(説明用の架空の例です)。

できた一覧は、止まるかもしれないSaaSの中には置かず、PDFか紙にして情シスとバックオフィスの2か所に置きます。手順2と手順3で作るものも、すべて同じ扱いです。見直しは年に1回か、主要なSaaSを入れ替えたときで足ります。

手順2：止まる前に、5つ用意する

下準備として、使っているSaaSを一覧にします。部署が個別に契約しているものや、契約はしていないが業務で使っているものも含めます(一覧の作り方はSaaSの棚卸しでムダな出費を減らす手順で扱っています)。そのうえで、Aの業務を支えるSaaSから順に次の5つを用意します。

3つ目の手元コピーは、IPAの手引きのチェック項目10「サービス停止やデータの消失・改ざんなどに備えて、重要情報を手元に確保して必要なときに使えるようにしていますか？」に当たる準備です。ただし顧客の連絡先などの個人情報を含むので、備えが漏えいの原因にならないよう、扱いを同時に決めます(以下は編集部の整理です)。

• 項目を絞る：連絡先なら氏名と連絡先だけ。与信や過去の取引履歴は書き出さない
• 置き場所を決める：私物の端末には置かず、会社の端末は暗号化する。紙は施錠して保管し、担当者の交代・退職時に回収する(入退社でSaaSアカウントを取りこぼさない手順と同じ台帳で管理すると漏れません)
• 紛失したときの初動を決める：自社の個人情報の取扱規程と照らし、誰が判断して誰に連絡するかを先に決めておく

書き出しの形式や件数上限など、SaaSからのデータの取り出し方そのものの注意点はSaaSを解約・乗り換える前にデータを取り出す手順で扱っています。5つ目のオフライン設定では、自動でオフライン用に保存されるのは最近使った一部のファイルだけなので、使うファイルは個別に指定します。管理者がオフライン同期を無効にしていると使えないので、管理コンソールの設定も確かめます。「設定したが中身が空だった」を当日に知ることのないよう、機内モードでの確認まで済ませてください。

手順3：止まった当日の30分を、1枚に書いて印刷しておく

下の表が、そのまま印刷する1枚です。裏面には手順2の「契約と管理者の控え」を写します。情シスの机とバックオフィスの壁に1枚ずつ貼っておきます。

記録は、後でクレジットを申請するときの材料になります。Microsoft Learnの解説「How to Read a Service-Level Agreement (SLA)」は、障害の最中と直後に残す記録として、時刻(タイムゾーンを含む)、エラーの詳細、リトライのログ、構成の証跡、事業者からの連絡の5つを挙げています。このうちリトライと構成は、それが条件になっているSLA向けの項目です。業務用のSaaSなら、時刻・エラー・事業者からの連絡の3つを1行ずつ残せば足ります(編集部)。書式は「09:12 JST／受注管理にログイン不可(503)／別回線でも同じ／スクショ有」のように1行で決めておくと迷いません。

手順4：復旧後の後始末を、その週のうちに終わらせる

転記：二重計上を防ぐ順で戻す

代わりの手段で処理した受注や問い合わせを、本来のシステムへ戻します。障害の前後は同じ取引が二重に入りやすいので、次の順で進めます。

1. 転記待ちリストには、停止中に受けた分だけを残す(復旧後に本番へ直接入れた分は消し込む)
2. 本番へ入れる前に、同じ取引先・同じ金額・同じ日付の記録が無いかを検索する
3. 転記した行に、転記日と担当者名を書く

転記は受けた本人が、復旧の翌営業日までに行います。紙の伝票の略記は、書いた人にしか復元できないからです。紙の伝票などの原本は、転記が終わっても記録と一緒に保管します。締め処理をまたぐ場合は、転記より先に経理へ「当月の請求が何件、発行待ちになっている」と一報を入れてください。

記録の保管：止まり方の癖を見る

手順3の記録は、ファイル名に「サービス名＋発生日」を入れて、止まったSaaSの外に保管します。年に1回並べると、短く何度も止まるのか、まれに長く止まるのかが見えます。前者なら、1回ごとには小さくても、Google Workspace SLA のように月内の停止時間を合算する契約では、月の合計が約束値を割っていないかを記録から確かめます。1回ずつがしきい値に遠く、合計しても届かないなら、代わりの手段の準備に力を入れます。後者なら申請の段取りを整えておく価値があります。契約更新の判断材料にもなります。

クレジット申請の判断：3点を見て、迷ったら先に送る

自社の契約のSLAを開き、その月の稼働率が約束値を下回ったか、除外される事由に当たらないか、申請期限はいつか、の3点を確かめます。Microsoft Learnの解説も、SLAの算定式に記録を当てはめ、除外に当たる時間を差し引き、約束値と比べる順で判断するとしています。

クレジットは、黙っていても付くものではありません。Google Workspace SLAは、クレジットを受け取るには、資格が生じた時点から30日以内(within thirty days)にサポートケースを作ってGoogleに通知する必要があり、守らなければ権利を失う(forfeit)と定めています。リセラー経由の契約では、顧客がリセラーに通知し、リセラーがGoogleに通知する2段階です。この場合も期限はリセラーに連絡した日からではなく資格が生じた時点から進むので、控えに書いたリセラーの担当者へ早めに連絡します。Microsoft Learnも一般論として、事業者は通常クレジットを自動では適用しないと説明しています。

迷いやすいのは起算点です。同SLAの稼働率は暦月で集計されるため、資格が生じた時点(the time Customer becomes eligible)がいつかは条文から一意には読めません。Microsoft Learnの解説も、申請期限は「Common timeframes range from 30 to 60 days after the end of the billing month」としつつ、事業者ごとに異なると述べています。復旧したその週のうちに起票し、確定した数字は後から補うのが確実です(編集部)。起票の材料は、手順2の控え(サービス名とプラン)、影響を受けたドメイン、手順3の記録(開始・終了の時刻と合計時間、エラーの様子、事業者の告知)でそろいます。

5分の振り返り：次までに直す1点を決める

「当日いちばん手が止まったのはどこか」を1行だけ書きます。ステータスページを探して10分かかったなら購読が未設定、電話をかけられなかったなら連絡先の控え不足です。手順1〜3の紙に赤で書き込めば、それが次の版になります。

SLAの読み方：契約で取り戻せるのはここまで

公開されているGoogle Workspaceのサービスレベル契約(2026年8月31日改定)を例に見ます。同SLAは、対象サービスの月間稼働率(暦月の総分数のうち、Downtime でなかった分数の割合)を99.9%以上と約束しています。他社のSLAは数値も定義も異なるので、自社の契約書で確認してください。

稼働率の段階と日数は同SLAの Service Credit の表(原文表記は「< 99.9% – >= 99.0%」など)によります。1行目・停止時間の換算(30日＝43,200分。31日の月なら境は44.6分)・試算は編集部が補ったものです。試算は計算用の仮の契約額(月32,000円)の日割りで、実際の付与はSLAを満たさなかった対象サービスの分に限られます。クレジットはサービス日数の追加か、同じ日数分の額の将来の請求への充当で、上限は対象サービスごとに月15日分です。

何が停止時間に数えられるかも、思うより狭く定められています。同SLAの定義は次のとおりです。

“Downtime” means, for a domain, a period of time during which the user web interface for the applicable Covered Services used by Customer has more than a five percent user error rate. Downtime is measured based on server side error rate.

• ドメイン単位で測る：一部の部署や一部のユーザーだけが使えない状態は、ドメイン全体では5%に届かないことがあります
• 対象はWebの画面：定義が名指しするのは user web interface で、モバイルアプリやAPI連携は文言に入っていません
• サーバー側のエラー率で測る：現場が「止まっている」と感じても、エラー率が5%を超えなければ数えられません

同SLAは、このクレジットを稼働率の未達に対する「sole and exclusive remedy」(唯一かつ排他的な救済)と定めています。Microsoft Learnの解説も一般論として「Credits don’t cover lost revenue, customer attrition, or reputational damage.」と注意しています。同SLAは、Google Workspace Essentials Starter エディションのサービスや不可抗力による問題などを除外しており、対象サービスも名指しで列挙されたものに限られます。契約で取り戻せる範囲がこの程度だからこそ、備えの重心は手順1〜4に置きます。

よくある質問(FAQ)

あわせて読みたい

関連カテゴリ: SaaS活用 ／ SaaS

本記事に登場する製品名は各社の商標または登録商標です。図解はjisalab編集部が作成しました。