BtoB ECの障害対応体制｜停止時の判断と復旧の型

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

B2B EC-COLUMN

BtoB ECの障害対応体制とは

BtoB ECの障害対応体制とは、受注が止まったときに誰が何をどの順で判断・実行するかを、検知から再発防止まであらかじめ決めておく社内の取り決めです。国内のBtoB-EC市場規模は514.4兆円、EC化率は43.1%に達しており^*1、企業間取引の停止はもはや例外的な事象ではありません。

取引先の生産・仕入まで止める停止の重さ

BtoB ECの受注が止まると、影響は自社の売上だけにとどまりません。取引先はその受注データをもとに生産計画や仕入計画を組んでいるため、停止は取引先側の業務にも波及します。

締め時間を過ぎてから復旧した場合、その日の受注はまとめて翌営業日扱いになりやすく、取引先の出荷スケジュールにずれが生じます。EDI（電子データ交換。企業間で受発注データを電子的にやり取りする仕組み）で連携している相手先が多いほど、影響範囲は広がる点に注意が必要です。

人員配置より先に止まってよい時間を決める順番

障害対応体制というと、担当者を並べた体制図から作り始めたくなります。しかし内閣府の事業継続ガイドラインが示す手順^*3は逆です。まず「どの業務をどれくらいの時間で戻すか」を先に決め、そのあとで必要な人員・監視・冗長化を組み立てます。

この順番を踏まないと、体制図は完成しても実際の障害時に「何分以内に何をすべきか」の基準がなく、現場の判断が遅れます。詳しい決め方は「止まってよい時間を先に決める」をご覧ください。

体制づくりで決めるべき4つの論点

何が起きて止まるのか——障害の3類型

体制を決める前に、何が原因で止まるのかを整理しておきます。BtoB EC の障害は、大きく自社起因・外部起因・攻撃起因の3つに分けられます。

自社起因——設定変更・リリース・データ不整合

価格・在庫・会員区分などのマスタ更新や、システムのリリース作業に伴う設定変更が原因になるパターンです。作業前後の確認手順が決まっていないと、気づかないまま受注が誤った条件で処理される事態にもつながります。

外部起因——決済・物流・EDI連携先の停止

クラウド基盤やSaaS、決済・与信サービス、物流事業者、EDI連携先など、外部のサービスが止まると自社のシステムは無傷でも受注は止まります。連携先が落ちたときにどこまで自社の裁量で縮退運転できるかは、連携設計の段階で決めておくべき論点です。

可視化した停止リスクを自社の商習慣に当てはめて確かめるには、無料相談で要件を整理するのが近道です。

攻撃起因——組織の脅威1位はランサム攻撃

IPA「情報セキュリティ10大脅威2026」の組織編は、1位をランサム攻撃による被害としています。2位はサプライチェーンや委託先を狙った攻撃、9位はDDoS攻撃（分散型サービス妨害攻撃。大量のアクセスを送りつけてサービスを利用不能にする攻撃）です^*2。2位のサプライチェーン・委託先への攻撃は、決済・与信・物流・EDIの連携先が狙われれば自社は無傷でも受注が止まる脅威です。BtoB ECの連携の多さそのものに関わります。攻撃を防ぐための対策の中身は別稿に譲り、本記事では止まった後に受注を回す段取りに絞って扱います。

止まってよい時間を先に決める

ここが体制づくりの中核です。誰が何を担当するかを決める前に、どの業務をどれくらいの時間で、どの水準まで戻すのかを先に確定させます。

事業影響度分析（BIA）で重要業務を絞る

内閣府の事業継続ガイドライン（令和5年3月）は、事業影響度分析（BIA。Business Impact Analysis。業務が止まった場合の影響の大きさを時系列で評価する分析）で重要業務を絞り込む手順を示しています^*3。BtoB EC では受注受付・在庫引当・出荷指示・請求のように、業務ごとに影響の出方が異なるため、まとめて一つの復旧目標を置くことはできません。

同ガイドラインは自然災害を対象としています。ただし対象事象について「サイバー攻撃など、事業の中断をもたらす可能性がある、あらゆる発生事象について適用可能」とも明記しています^*3。防災の話に限定せず、システム障害にもそのまま引ける手順です。

RTOとRLOを対で決める

同ガイドライン3.1.2は、重要業務についてどれくらいの時間で復旧させるかを目標復旧時間（RTO。Recovery Time Objective）、どの水準まで復旧させるかを目標復旧レベル（RLO。Recovery Level Objective）として定義し、両方を対で決めるとしています^*3。決め方の基準も明確で、「時間の許容限界より早く目標復旧時間を設定し、レベルの許容限界を上回るように目標復旧レベルを設定する」とされています^*3。

すべての業務を全面的に戻すという目標ではなく、「4時間以内に主要取引先の受注受付だけを再開する」のように、業務と水準を絞って設定します。この考え方があると、冗長化や監視にどこまで投資するかの線引きが具体的になります。

締め時間から逆算するBtoB EC固有の決め方

締め時間を持つBtoB ECでは、締め時間からRTOを逆算する決め方が実務的です。15時締め・翌日出荷の運用であれば、13時台の障害と16時台の障害では許容される時間が変わります。締め時間の設計自体は別稿で扱っており、本記事ではその締め時間を復旧目標の基準として使う考え方に絞ります。

以下は業務別にRTO・RLOを記入するテンプレートです。自社の数値を当てはめて埋めてください。

誰が判断するのか——役割と権限を決める

止まってよい時間が決まったら、その時間内に判断・実行する役割を割り当てます。平常時の業務分担は別稿で扱っており、本記事では異常時に限った判断権限の配置を扱います。

緊急対応体制と事業継続・復旧体制は分ける

経済産業省・IPA「サイバーセキュリティ経営ガイドラインVer3.0」の重要10項目は、指示7と指示8を別の項目として立てています^*4。指示7は「インシデント発生時の緊急対応体制の整備」、指示8は「インシデントによる被害に備えた事業継続・復旧体制の整備」です。止血にあたる緊急対応と、商売を続けるための事業継続・復旧を同じ担当者がまとめて抱えると、復旧作業に人手が集中し、取引先への連絡が後回しになりがちです。

兼務前提の3役に名前を入れる

専任の情報システム担当を複数名置ける企業は多くありません。専任を増やす前提ではなく、次の3つの役割に担当者と代行者の名前を入れることが現実的です。一次受け（検知・記録・連絡の起点）、切り分け（自社かベンダーか外部要因かを判定する担当）、意思決定（受注停止の判断と告知を承認する担当）の3役です。

代行者と緊急時に限った権限

意思決定役が夜間・休日・出張で不在の時間帯に、誰が代わりに判断するかも決めておきます。緊急時に限って権限を代行者へ一時的に付与する運用は、平常時の権限設計とは別の論点として整理しておきます。

ベンダー・委託先との取り決め

保守を委託している場合は、契約に受付時間・連絡先・一次回答の目安・どこからが有償対応かを明記しておく必要があります。次の項目は、保守契約を結ぶ段階、あるいはRFP（提案依頼書）を作る段階で確認しておくと後で困りません。

発生したら何をするか——5段階の手順

体制が決まったら、実際に障害が起きたときの手順を確認します。次の5段階で進めていきましょう。

1. 検知：監視ツールからの通知と、取引先からの申告の両方を検知の入口とします。申告を受ける窓口が決まっていないと、初動の遅れにつながりかねません。
2. 切り分けと記録：影響範囲（全社か、一部取引先か、特定機能か）と発生時刻を先に確定させましょう。この時点で、設定したRTOの残り時間を意識して動く必要があります。
3. 取引先への告知と代替受注：発生時刻・影響範囲・代替手段・次回連絡予定時刻の4点を含む告知文を、サイト上の掲示と主要取引先への個別連絡の両方で出します。復旧見込みは断定せず、次回連絡の予定時刻を示すにとどめるのが実務的でしょう。代替の受注手段として、電話・FAXへの一時的な切り替えを用意しておきます。
4. 復旧（暫定と恒久）：原因の特定に時間がかかる場合は、暫定対応で業務を先に戻し、恒久対応は後から進めるとよいでしょう。
5. 復帰：内閣府のガイドラインは、代替手段から平常運用へ切り替える際の「復帰計画」の必要性に触れています^*3。具体的には、手作業で処理した分がシステムへ反映されたことを確認してから通常運用に戻す、という段取りです。BtoB ECでは、電話・FAXで受けた注文の二重入力や取りこぼしがここで起きやすく、基幹システムとの整合確認と、受注データの入力チェックの両方が効いてきます。

平時に何をしておくか

体制と手順を決めたら、平常時のうちに済ませておくべき備えは4点です。

年1回の演習で連絡だけでも回す

経済産業省・IPAのガイドラインの指示8は、サプライチェーンも含めた実践的な演習の実施までを求める内容です^*4。フルシナリオでなくても、年1回、連絡網を実際に回してみるだけで、抜けている連絡先に気づけます。

連絡先と代行者の棚卸し

異動や退職で最初に古くなるのは連絡網です。棚卸しの頻度をあらかじめ決め、担当者の変更があったタイミングで反映する運用にしておきます。

発生時の記録を次回のRTO設定に使う

発生時刻・影響範囲・判断内容・復旧にかかった時間を記録に残しておくと、次に目標復旧時間を設定するときの根拠になります。記録がなければ、RTOは経験のない見込みで決めるしかありません。

体制を文書として取引先・親会社に説明できる形にする

主要取引先や親会社から、BCP・障害対応の説明を求められる場面が想定されます。決めた内容を1枚の文書にまとめておけば、そのつど資料を作り直す手間がかかりません。

ここまでの検討や、EDI連携先ごとの窓口整理、契約書のSLA（サービス品質保証。委託先が保証する対応時間などの水準）確認まで含めて自社だけで抱えるのは、専任が1〜2名という体制では負担が大きくなります。RTOを実際に守れるかどうかは、冗長化・監視・保守受付時間がシステムの要件に組み込まれているかで変わります。要件定義の段階で非機能要件として書けるかどうかが分かれ目です。商習慣を理解したベンダーであれば、優先すべき業務の順位づけも一緒に検討できます。

まとめ：BtoB EC障害対応体制の3つの判断軸

本稿では、BtoB ECの障害対応体制について、止まってよい時間の決め方から役割の配置、発生時の手順までを整理しました。要点を3つに集約すると、第一に、体制図より先にBIA・RTO・RLOで止まってよい時間を決めること。第二に、緊急対応の体制と事業継続・復旧の体制を分け、兼務前提の3役に代行者まで含めて名前を入れること。第三に、検知から復帰まで5段階の手順を踏み、取引先への告知と復帰後のデータ整合確認まで書き切ることです。決めるべきことは多くありませんが、今日から表を埋め始められるはずです。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

情報システム部門が無い場合、障害対応体制は作れませんか。

専任部門がなくても作れます。一次受け・切り分け・意思決定の3役に、専任1〜2名または兼務担当の名前と代行者を割り当てる形が現実的です。全工程を自前で担うのが難しい場合は、保守を委託しているベンダーの窓口を切り分け役の一部として組み込む方法もあります。

RTOは何時間に設定すればよいですか。

一律の正解はありません。内閣府のガイドラインは、業務の停止が許される時間の許容限界を評価した上で、その限界より早く目標復旧時間を設定するという決め方を示しています^*3。BtoB ECでは締め時間を許容限界の目安として使うのが実務的です。

クラウドサービス側の障害でも、自社で決めておくことはありますか。

あります。連携先が原因の障害でも、受注をどこまで縮退運転で受け付けるか、取引先への告知を誰が出すかは自社側の判断です。外部起因の障害を体制の対象外にしていると、連携先の障害時に社内の誰も動けなくなります。

障害の告知は、いつ・どこまで出すべきですか。

発生に気づいた時点で、発生時刻・影響範囲・代替手段・次回連絡予定時刻の4点を含む告知を、サイト上の掲示と主要取引先への個別連絡の両方で出します。復旧の見込み時刻を断定せず、次に情報を更新する予定時刻を示すにとどめるのが実務的です。

BCPと障害対応体制は別に作る必要がありますか。

別文書にする必要はありません。内閣府のガイドラインはサイバー攻撃を含むあらゆる発生事象に適用可能と明記しています^*3。システム障害への対応体制はBCP（事業継続計画）の一部として位置づけられ、BIA・RTO・RLOの考え方も共通です。

1. *1　出典：経済産業省「令和6年度電子商取引に関する市場調査」（2025年8月公表）
2. *2　出典：独立行政法人情報処理推進機構「情報セキュリティ10大脅威2026」（2026年1月公表）
3. *3　出典：内閣府（防災担当）「事業継続ガイドライン－あらゆる危機的事象を乗り越えるための戦略と対応－」（令和5年3月公表）
4. *4　出典：経済産業省・独立行政法人情報処理推進機構「サイバーセキュリティ経営ガイドライン Ver 3.0」（2023年3月公表）、および同「実践のためのプラクティス集 第4版」（2023年10月公表）