業務やサービスが止まるリスクを回避する考え方：重要業務の絞り込みから対策の選び方まで

◆監修・編集責任者　小園 将隆　2026年10月5日

B2B EC-COLUMN

「止まったら誰が困るのか」が言えないときの最初の整理

取引先のシステム障害やアカウント停止の知らせを見て、自社でも注文書の受け付けや出荷が止まるかもしれないと感じても、何が止まると誰が困るのかを言えなければ、対策の順番は決められません。
変えられるのは、考える順番です。
まず止まって困る業務を選び、業務ごとに許容できる停止時間を置きます。
許容できる時間が短い業務は止めないための回避策を中心にします。
長めに許容できる業務は、止まる前提で早く戻す備えを中心にします。
この順で決めれば、停止のリスクに対して、予防・冗長化・代替手段・復旧手順・取引先との取り決めを、効果と負担で選べます。

止まって困る業務を書き出す

備えを考え始めると、サーバー、パソコン、ネットワーク、使っているクラウドサービスと、止まり得るものを片端から並べたくなります。
ところが機器やサービスの一覧は際限なく長くなります。
どれも止まれば困るように見えるため、かえって順番が付けられなくなります。
出発点に置くのは「止まり得るもの」ではなく、「止まると困る業務」です。

内閣府の事業継続ガイドラインの案内ページは、BCP（事業継続計画。
緊急時にも重要な業務を続け、止まっても早く再開するための計画）を、業務の中断から企業を守る経営戦略と位置づけています。
そのうえで、重要な機能を目標復旧時間内に再開することを軸に置いています²。
守る対象が機器ではなく、機能や業務になっている点が、ここでの手掛かりになります。
機器やサービスは、業務を止める原因として後から書き足せば足ります。

業務を書き出すときは、単位を少し細かくします。
たとえば「受注業務」とまとめると、注文書を受け取る、受注内容を登録する、在庫を引き当てる、出荷を指示する、請求書を出す、という性質の違う作業が一つになってしまいます。
注文書の受け取りが止まれば、取引先はその日の注文が届いたか分からなくなります。
一方で請求書の発行が止まっても、締めの時期までに取り戻せる場合があります。
同じ受注の流れでも、どこが止まるかで急ぐ度合いが違うので、分けておかないと後の判断がぼやけます。

書き出しには、業務ごとに一行ずつの小さな表を使うと整理しやすくなります。
これはガイドラインが定めた様式ではなく、編集部が勧める整理の方法です。
欄は、業務の名前、止まると何ができなくなるか、困る相手、困り始めるのはいつか、いま頼っているもの、の五つで足ります。

表のうち「困り始めるのはいつか」の欄は、この段階で正確な時間を書けなくても構いません。
「その日の注文締めを過ぎたら」「当日の出荷指示を出す前」「月末の締めが近づいたら」のように、相手の側で何かが起きる時点を書いておきます。
それが、後で許容できる停止時間を決めるときの材料になります。
「いま頼っているもの」の欄には、メール、受発注サービス、受注管理システム、会計ソフト、特定の担当者など、その業務が止まる入口を書きます。
人を書いてよいのは、担当者が不在なだけで業務が止まることも、停止の一つだからです。

影響を受ける相手（顧客・取引先・現場）の整理

同じ停止でも、誰がどう困るかは相手によって違います。
注文書の受け取りが止まった場合、顧客や取引先は注文が通ったか確かめられず、問い合わせや再送の手間を負います。
倉庫や営業などの現場には、処理できない注文がたまります。
再開後にまとめて処理するときには、入力漏れや二重登録の心配も抱えます。
経理は、受注が登録されないことで請求の準備が遅れます。

相手を書き分けておくと、二つのことが分かります。
一つは、社外の相手が困る業務ほど、信頼や取引への影響が大きくなりやすいことです。
もう一つは、止まったときに誰へ知らせるべきかが、この時点でほぼ決まることです。
後で連絡の順番を決めるとき、この欄がそのまま連絡先の候補になります。

ここでいう「停止」には、自社のシステム障害、担当者の不在などによる業務の中断、取引先やクラウドサービスの停止、アカウントの停止が混ざっています。
原因はばらばらでも、自社の仕事が止まるという結果は同じなので、表の上では区別せずに書いて構いません。
なお、BCPはもともと災害などの緊急事態を想定した枠組みで、日々のシステム障害やサービス停止へ当てはめるのは、編集部としての整理です。
考え方は借りられますが、多くの業務が同時に止まる災害時と、一つのサービスだけが止まる場面とでは、取れる手が違います。

表が埋まったら、全部を同じ重さで扱わず、重要業務を選びます。
目安になるのは、困る相手に社外の顧客や取引先が含まれるか、困り始める時点が早いか、の二点です。
どちらにも当てはまる業務が、最初に備える候補になります。

停止の原因を3つに分けて見る：自社内・取引先や外部サービス・不正や誤操作

自社内の原因

重要業務を選んだら、それぞれの「いま頼っているもの」を見ながら、何が原因で止まり得るかを考えます。
原因は、自社内、取引先や外部サービス、不正や誤操作の三つに分けておくと扱いやすくなります。
分ける理由は、誰が直せるかが違い、取れる対策もそこで変わるからです。
この分け方は停止の起点を整理するための編集部の考え方で、公的な分類ではありません。

自社内の原因は、機器の故障、停電、設定の誤り、ソフトの更新後の不具合、担当者の不在などです。
自社で直せる、あるいは自社で備えを用意できる点が特徴です。
予備の機器、手順書、複数人で処理できるようにする引き継ぎなど、手を付ける順番も自分たちで決められます。

見落としやすいのは人の要素です。
注文書を受注管理システムへ登録する作業を一人の担当者しかできない場合、その人が休めば、システムが正常でも受注の登録は止まります。
機器の一覧からは出てこない停止なので、業務から考える意味がここに表れます。

取引先・外部サービスの原因

受発注サービスやクラウドの受注管理、メール、決済、配送会社など、外部に頼っている部分が止まる場合です。
取引先の会社そのものが止まり、注文書が届かなくなる、部材が入らなくなる、ということも含みます。
サービス自体は動いているのに、アカウントが停止されて自社だけ使えなくなる場面も、ここに入ります。

このとき、自社では原因を直せません。
問いは「どう直すか」から、「相手が止まっている間、自社はどこまで仕事を続けられるか」に変わります。
そのため備えの中心は、別の受け取り経路などの代替手段と、停止時の連絡や扱いについての取引先・提供者との取り決めになります。
相手との話し合いや契約の確認には時間がかかるので、自社内の備えより先に動き始めておく価値があります。

不正・誤操作の原因

外部からの攻撃、内部不正、誤った削除や設定変更、誤送信などです。
攻撃と誤操作は起点がまったく違います。
ただ、データが消えた、システムに入れない、という起きたことだけを見ると、最初は区別がつかないことがあります。
そのため、権限を必要な人に絞る、操作の記録を残す、別の場所にバックアップを持つ、といった備えが、両方に効く形で重なります。

この分類は、ほかの二つと重なることもあります。
委託先が攻撃を受けて止まれば、外部の原因でもあり、不正の原因でもあります。
重なりを厳密に分ける必要はありません。
自社で防げる部分と、相手が止まる前提で備える部分が見えれば十分です。

10大脅威の読み方と限界

外部や不正が原因の停止について、公的な整理として参考になるのが、IPA（独立行政法人情報処理推進機構）の「情報セキュリティ10大脅威 2026［組織］」です。
ランサム攻撃による被害が最も上位に置かれ、サプライチェーンや委託先を狙った攻撃がそれに次ぎます。
ほかにも、システムの脆弱性を悪用した攻撃、内部不正、DDoS攻撃（大量の通信を送りつけてサービスを使えなくする攻撃）、ビジネスメール詐欺などが挙げられています¹。

自分の表と照らし合わせると使いやすくなります。
ランサム攻撃（データを暗号化するなどして使えなくし、元に戻すことと引き換えに金銭を求める攻撃）が自社のシステムに起きれば、受注管理そのものが止まります。
サプライチェーンや委託先を狙った攻撃は、取引先や外部サービスが攻撃を受けて止まる形で、自社の業務に及びます。
DDoS攻撃は、自社のサイトや頼っているサービスが外から使えなくなる原因として関わります。
表の「いま頼っているもの」ごとに当てはまりそうな脅威を書き添えると、三つの分類のどこに備えが要るかが具体的になります。

ただし、この順位の意味は取り違えないでください。
10大脅威は、社会的に影響が大きかった事案を基に、専門家が審議と投票で選んだセキュリティ上の脅威の順位です¹。
停止が起きた件数や頻度の順位ではありません。
機器の故障、停電、設定の誤りといった障害は、そもそも対象に入っていません。
上位にあるから自社でもよく起きる、とは読めません。

どの原因が起きやすいかで順番を付けたくなりますが、自社にとっての起きやすさを示す確かな数字がないまま並べると、判断の根拠が弱くなります。
そこで順番は、起きやすさではなく、止まったときの影響の大きさと、どれだけの停止なら許容できるかで付けます。
原因の分類は、その順番の中で「どの対策が効くか」を選ぶときに使います。

回避する業務と、止まる前提で早く戻す業務の分け方

許容できる停止時間の考え方

目標復旧時間は、業務が止まったとき、どれだけの時間内に再開させるかの目標です。
内閣府のガイドラインは、事業影響度分析（業務が止まったときの影響を評価する作業）で、優先して継続・早期復旧する重要業務を選び、目標復旧時間を検討する考え方を示しています。
目標は、影響の大きさの評価や取引先との関係を踏まえて決めるとされています²。

ここで大事なのは、「技術的に何時間で直せるか」から出発しないことです。
決めるのは、相手にとって停止が許されると考える時間です。
最初に作った表の「困り始めるのはいつか」の欄が、そのまま材料になります。

注文書の受け取りを例にします。
取引先が毎日決まった時刻までに注文書を送り、その日のうちの出荷を期待している取引だとします。
この場合、締め時刻を越えて受け取れない状態は、出荷の遅れとして取引先に直接届くので、許容できる停止時間は短く見積もることになります。
一方、請求書の発行は、締めの時期に間に合えば取引先への影響が出にくいので、長めに許容できると考えられます。
同じ会社の同じ受注の流れの中でも、業務ごとに答えが違います。

何時間、何日という具体的な目安は、業種や取引条件によって大きく変わるため、ここでは示しません。
他社の数字を借りるより、取引先との約束や締め時刻を知る営業、たまった注文を処理する現場の担当者に「どこまで止まったら取り返しがつかなくなるか」を聞くほうが、自社の実情に合った時間になります。

決めた時間は社内だけで持たず、関係の深い顧客や取引先と共有することも考えてください。
相手の期待と自社の想定がずれていれば、止まる前にそれが分かります。
止まったときにも、相手はいつごろまでに戻る想定なのかを知ったうえで、待つか別の手を打つかを決められます。
これは編集部の提案で、共有の範囲は取引の関係に応じて選べます。

仕分けの手順

許容できる停止時間を置けたら、業務を「止めないように回避を狙うもの」と「止まる前提で早く戻すもの」に分けます。
判断の軸は、止まったときに許容時間の内に戻せる見込みがあるかどうかです。
ガイドラインに「何時間より短ければ回避」といった基準があるわけではありません。
各業務の許容時間と戻るまでの見込みを比べる、編集部が勧める手順です。

戻るまでの見込みは、正確には分かりません。
自社内の機器なら、過去に止まったときの経験や、バックアップから実際に戻してみた結果から、おおよその見当が付きます。
外部サービスが原因の場合は、相手の復旧を自社では早められないので、見込みが立たないものとして扱うほうが安全です。
その結果、外部に頼っていて許容時間が短い業務は、回避の側、つまり別の経路で続ける備えが必要な業務として残りやすくなります。

許容時間が長く、手作業でしばらく回せる業務は、戻す側に入ります。
手を抜いてよいという意味ではなく、止まったときに迷わず戻せる手順とデータの控えを持っておくことが、備えの中心になります。
重要業務に選ばなかった業務は、止まることを受け入れる判断として表に残しておきます。
何も決めていない業務と、止まってもよいと決めた業務とでは、止まった当日の迷いが違います。

予防・冗長化・代替手段・復旧手順・取引先との取り決めを比べる

同じ軸での比較表

仕分けができると、どの対策を選ぶかに進めます。
ここで比べる五つの対策は、次の意味で使います。

予防：止まる原因そのものを減らすこと。
ソフトの更新、権限の整理、機器の点検などがあたります。
冗長化：同じ役割を果たすものを複数用意し、一方が止まっても続けられるようにすること。
代替手段：普段とは別のやり方で、一時的に仕事を続けること。
受発注サービスが止まったら注文書をメールで受け付ける、といった形です。
復旧手順：止まった後に元へ戻すための手順と、データの控え。
取引先との取り決め：停止時の連絡や扱いを事前に合意し、契約書面で条件を確かめておくこと。

判断が分かれやすいのは、冗長化と代替手段のどちらに手間をかけるかです。
冗長化は、うまく切り替われば顧客や取引先が停止に気づかずに済むので、許容時間が短い業務に向きます。
ただし、同じクラウドサービスの中で二重に持っていても、提供者側が止まった場合や、自社のアカウントが停止された場合には、両方が同時に使えなくなります。
外部サービスに頼る業務で回避を狙うなら、冗長化だけでなく、別の経路を代替手段として持つことに意味があります。

代替手段は普段の仕組みを使わずに仕事を続けるので、再開後に必ず後始末が出ます。
受発注サービスが止まっている間にメールで受けた注文書は、復旧後に受注管理へ登録し直す必要があります。
ここで登録漏れが起きたり、取引先がサービスにも再送していて二重登録になったりしやすくなります。
代替手段を決めるときは、切り替える手順と同じだけ、戻すときにどの注文を突き合わせるかを決めておくと、後始末の確認が減ります。

予防は止まる回数を減らすことには効きますが、止まった後の速さは変えません。
取引先や外部サービスが止まる場合には、自社の予防はほとんど届きません。
復旧手順は三つの原因すべてに使える一方、許容時間が短くて戻るのを待てない業務では、それだけでは足りません。

実際には、一つの業務に一つの対策ではなく、組み合わせになります。
たとえば、外部の受発注サービスで注文書を受けていて、許容時間が短い業務を考えます。
この場合、提供者との取り決めの確認、メールなど別の受け取り経路の用意、復旧後の突き合わせ手順を組み合わせる形が考えられます。
どの組み合わせが合うかは、表の「向かない場面」に自社の業務が当てはまっていないかを見ると絞り込めます。
費用は契約や規模で大きく変わるため、候補を絞ってから見積もると比べやすくなります。

外部サービスの契約書面で確認すること

外部サービスが原因の停止に備えるとき、まず手元で確かめられるのが契約書面です。
利用規約やSLA（サービス品質保証。
提供者が稼働の水準や障害時の対応を約束する取り決め）に何が書かれているかで、自社が用意すべき備えが変わります。

稼働の水準：稼働率などの定めがあるか、計画的なメンテナンスによる停止がそこに含まれるか。
障害時の通知：障害をどの方法で知らせるか、自社側の問い合わせ窓口はどこか。
免責：どのような停止が提供者の責任の外に置かれているか。
補償の範囲：約束を下回ったときに何が返ってくるか。
アカウントの停止：どんな条件で利用が止められ、事前に知らせがあるか。
データの取り出し：止まったときや解約するときに、受注などのデータを自社で取り出せるか。

読み方の要点は、補償があっても業務は戻らない、ということです。
利用料の一部が返ってくる定めがあっても、注文書を受け取れなかった時間の取引先への影響は残ります。
契約書面は、相手に任せられる範囲と、自社で代替手段を持つべき範囲の境目を知るために読みます。
通知の方法が分かれば停止に気づく時点が早まり、データを取り出せると分かれば、別の仕組みで続ける代替手段が現実的になります。

定めの内容は提供者や契約の種類ごとに異なるので、一般的な水準を当てにせず、自社が結んでいる契約で確かめます。
書面で分からない点は、取り決めの一部として提供者へ問い合わせておくと、止まった当日の問い合わせを減らせます。

実際に止まったとき、誰が何を判断して連絡するか

事前に決める項目

重要業務と許容時間、選んだ対策が決まっていても、止まった当日に「誰が切り替えを決めるのか」で迷えば、許容時間はすぐに過ぎていきます。
起きやすいのは、もう少し待てば戻るかもしれないと判断を先送りし、代替手段へ切り替える時機を逃すことです。
そこで、止まったときの判断を、事前に決められるところまで決めておきます。
次の項目は公的な様式ではなく、編集部が勧める一覧です。

判断する人と代理：誰が停止と判断し、切り替えを決めるか。
その人が不在のときは誰が決めるか。
停止と扱う基準：どんな状態になったら「止まった」として動き始めるか。
切り替えの時点：許容時間のどこまで待ったら代替手段へ移るか。
連絡先の一覧：社内の現場、顧客や取引先、外部サービスの提供者の窓口。
知らせる文の下書き：何が止まっているか、何は使えるか、代わりにどうしてほしいか、次にいつ知らせるか。
記録の取り方：いつ気づき、何を判断し、誰に知らせたか。
再開後の確認：代替手段で受けた注文の登録漏れと二重登録の突き合わせ。

このうち切り替えの時点は、前に置いた許容時間から逆算して決められます。
切り替えにも時間がかかるので、許容時間ぎりぎりではなく、余裕を残した時点に置きます。
許容時間が「当日の出荷指示を出す前まで」なら、メールでの受け付けに切り替えて現場が手で処理するのに必要な時間を差し引いた時点が、判断の期限になります。
期限が決まっていれば、判断する人は「戻るかどうか」を当てる必要がなく、時刻を見て決められます。

担当者が一人しかいない会社でも、この一覧は作れます。
判断する人の代理には上長や経営者を置き、外部サービスについては提供者の窓口を書いておきます。
一人で抱えている手順ほど、紙や共有の場所に書いておけば、その人が不在でも、ほかの人が少なくとも連絡までは動けます。
会社の規模や体制で置き方は変わるので、自社の人の配置に当てはめて決めてください。

連絡の相手と順番

連絡の相手は、最初の表に書いた「困る相手」がそのまま候補になります。
順番を考えるときは、誰に知らせると次の混乱が減るかを基準にします。

最初に知らせるのは社内の現場です。
受注管理が止まっているのに、現場が普段どおり注文を処理しようとすると、手元の控えとシステムの記録がずれ、再開後の突き合わせが増えます。
現場には、止まっている業務、代わりのやり方、記録の残し方を先に伝えます。

次に、影響を受ける顧客や取引先へ知らせます。
伝えるのは、何が止まっているか、何は使えるか、注文書をどこへ送ってほしいか、次の知らせをいつ出すか、です。
代わりの送り先を伝えずに止まったことだけを知らせると、相手は待つしかなくなり、問い合わせが集中します。
外部サービスが原因なら、並行して提供者の窓口へ状況を確かめ、復旧の見込みが分かれば次の知らせに反映します。

再開したら、代替手段で受けた注文を突き合わせ、現場と相手へ再開を知らせます。
最後に記録をもとに、判断の時点や連絡の順番が実際に合っていたかを振り返ります。
食い違いが見つかれば、表や一覧の書き直しに使います。

小さく始めて見直しを続ける

最初の一歩

ここまでの作業をすべての業務に一度に行おうとすると、表が半分埋まったところで止まりがちです。
最初は重要業務を一つか二つに絞り、その業務について、表の一行、許容できる停止時間、切り替えの時点、連絡先だけを決めます。
全部の業務に少しずつ手を付けるより、一つの業務で「止まったら誰が何をするか」が最後までつながっているほうが、実際に止まったときに使えます。

決めたら、一度だけ試してみると、紙の上では見えない抜けが分かります。
たとえば、普段は受発注サービスで受けている注文書を、代わりの受け取り経路で一件受け取り、受注管理へ登録し、再開後の突き合わせまでたどってみます。
代わりの送り先を取引先が知らなかった、手作業で登録する画面の権限が担当者になかった、といった点は、試すことで見つかる場合があります。

見直しのきっかけ

内閣府は、BCPを文書を作って終わるものではなく、継続的な管理（BCM。
計画を運用し、見直しながら保つ取り組み）まで含むものと位置づけています²。
作った表や一覧も同じで、業務や相手が変われば中身が古くなります。

見直しは、決まった頻度を置くより、中身が古くなる出来事をきっかけにするほうが手間に見合います。
これは編集部の提案です。

取引先が増えた、変わった、注文の締め時刻などの取引条件が変わった。
外部サービスの契約を更新した、提供者を変えた。
受注管理などのシステムを入れ替えた、使い方を変えた。
担当者が異動した、退職した、代理が変わった。
実際に止まった、または止まりかけた。

どのきっかけでも、見直す順番は同じです。
重要業務と困る相手は変わったか、許容時間は今の取引条件に合っているか、選んだ対策はまだ効くか、連絡先は生きているか、と最初に決めた順にたどります。
見直すたびに重要業務を一つずつ足していけば、限られた手間のまま、備えの範囲を広げられます。

重要業務の選び方や許容できる停止時間は、社内だけで決めると、普段の業務の見方や担当者の経験に引っ張られやすいところです。

注文書の受け取りから出荷・請求までのどこが外部のサービスや特定の担当者に頼っているか、許容時間と代わりの手段の当てがあるかを整理できます。無料相談で要件を整理する

要点の整理

軸	基準
最初に決めること	止まって困る業務と、困る相手
優先順位の付け方	影響の大きさと許容できる停止時間（起きやすさの順位ではない）
回避か復旧か	許容時間の内に戻せる見込みがあるか
外部サービス	通知・免責・アカウント停止・データの取り出しを契約書面で確かめる
止まったとき	判断する人と代理、切り替えの時点、連絡の順番
見直し	取引先・契約・システム・担当者が変わったとき

切り替えの時点や連絡の順番は、決めた後に自社の取引条件と照らすと、抜けや食い違いが見つかりやすくなります。 決めた許容時間と代わりの手段、契約書面で確かめた条件が、いまの取引先との約束に合っているかを確かめられます。

よくある質問

停止の原因を自社内・外部・不正に分けるとき、どれから手を付けるべきですか。

原因の分類から順番を決めるのではなく、先に選んだ重要業務ごとに、頼っているものがどの分類に入るかを見ます。
そのうえで、取引先や外部サービスに頼る部分は早めに動き始めると進めやすくなります。
契約の確認や相手との取り決めには時間がかかり、自社だけでは直せないためです。
自社内の原因は、手順書や引き継ぎなど、自社の判断ですぐ着手できるものから進められます。

許容できる停止時間は、何を基準に決めればよいですか。

技術的に直せる時間ではなく、相手にとって停止が許されると考える時間を基準にします。
内閣府のガイドラインも、目標復旧時間を影響の大きさや取引先との関係を踏まえて決める考え方を示しています²。
注文の締め時刻や出荷の約束、たまった注文を現場がいつまでに処理しきれるかが手掛かりになります。
具体的な時間は業種や取引条件で変わるため、営業や現場の担当者に聞いて決めます。

取引先やSaaSが止まったとき、自社は契約書面のどこを確認すればよいですか。

稼働の水準の定めと計画停止の扱い、障害時の通知の方法と窓口、免責の範囲、補償の範囲、アカウント停止の条件、データの取り出し方を見ます。
補償があっても業務は戻らないので、書面は、提供者に任せられる範囲と、自社で代替手段を持つべき範囲の境目を知るために読みます。
内容は提供者や契約ごとに異なるため、自社の契約で確かめます。

担当が一人でも、停止時の判断と連絡の体制は作れますか。

作れます。
判断する人の代理に上長や経営者を置き、外部サービスについては提供者の窓口を連絡先に書いておきます。
切り替えの時点と連絡先、知らせる文の下書きを共有の場所に残しておけば、担当者が不在でも、ほかの人が少なくとも連絡までは動けます。

BCPと日常のシステム障害対策は、どう使い分けますか。

BCPは災害などの緊急事態を想定した枠組みで、多くの業務が同時に止まる場面を扱います。
日常のシステム障害やサービス停止は、一つの仕組みだけが止まる場面が中心です。
重要業務を選び、許容できる停止時間を置くという考え方は両方に使えるので、同じ表を土台にできます。
違いが出るのは取れる手で、一つのサービスの停止なら、別の経路への切り替えや提供者への確認で対応できる範囲が広くなります。

1. 1　出典：独立行政法人情報処理推進機構（IPA）「情報セキュリティ10大脅威 2026［組織］」（2026年）
2. 2　出典：内閣府 防災担当「事業継続ガイドラインに関する情報」（2023年）