BtoB通販システムに障害が発生したら?初動対応から取引先への連絡、再発防止までの進め方

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

B2B EC-COLUMN

BtoB通販システムに障害が発生したら最初に確認すべきこと

取引先から「発注画面が開かない」と電話が入り、管理画面を見ても原因が分からないまま問い合わせだけが増えていく。
BtoB通販の障害でまず苦しいのは、直せないことよりも、次に何をすべきかを決められない時間です。
動かせるのは順序のほうです。
最初に対応体制を立ち上げて責任者を決め、何がどこまで止まっているかを確認し、原因が自社システムか外部の基盤かを切り分けます。
外部が原因なら自社で直接は直せず、対応の範囲は契約したSLAが基準になります。
取引先へは事前に取り決めた代替手段を軸に連絡し、復旧後に対応状況と再発防止策を正式に報告する。
そして収束後、調査の結果を平時の体制へ戻す。
この並びを先に持っておくと、原因が見えない時間帯でも判断が止まりません。

対応体制を立ち上げ責任者を決める

障害の一報は、たいてい取引先からの電話やメールで届きます。
「発注画面が開かない」「カートに入れたのに確定できない」という連絡が数件重なり、社内で異変に気づいたときには問い合わせがすでに増え始めている、という順序になりがちです。
ここで起きやすいのが、担当者が一人で原因調査と電話対応を同時に抱え、どちらも前に進まなくなる状態です。
最初に決めるべきなのは原因ではなく、誰が何を引き受けるかという役割のほうです。

IPAの手引きは、インシデントが事業や顧客に与える影響を踏まえて速やかに対応体制を立ち上げ、責任者と担当者を定めることを示しています¹。
この手引きはウイルス感染や情報漏えい、システム停止を含むセキュリティインシデント全般を対象にした中小企業向けの一般的な内容で、BtoB通販の障害だけを想定した手順書ではありません。
それでも、指揮系統を先に置くという考え方は、原因がまだ見えていない時間帯ほど効いてきます。
判断する人が決まっていないと、調査結果が一つ出るたびに「これは誰に報告して、誰が次を決めるのか」で止まってしまうからです。

役割の分け方は、規模が小さくても三つに分けられれば回り始めます。
システムの状態を調べる人、取引先からの連絡を受けて内容を記録する人、止めるかどうかや外部への案内を決める人です。
兼任せざるを得ない場合でも、少なくとも決める人を一人に固定しておくと、同じ質問が別々の担当者に何度も持ち込まれる事態を避けられます。
あわせて、この時点から対応の経過を時刻付きで書き残す担当も決めておくと、後の原因調査と取引先への報告がそのまま楽になります。

影響範囲と原因の切り分けを進める

体制ができたら、次は何がどこまで止まっているのかを確定させます。
BtoB通販システムは、ログイン、商品の検索、取引先ごとの価格表示、在庫の引き当て、注文の確定、注文履歴や帳票の出力といった機能が連なって動いています。
サイト全体にアクセスできないのか、注文確定だけが失敗するのか、特定の取引先だけ価格が表示されないのかで、原因の候補も、取引先に伝えるべき内容も変わります。
「障害が起きている」という粒度のままでは、社内の誰も次の行動を決められません。

確認したいのは、止まっている機能、影響している取引先の範囲、始まった時刻の三つです。
とくに始まった時刻は、直前に行った作業と突き合わせるための手掛かりになります。
リリースや設定変更、商品マスタや価格の一括更新、取引先アカウントの登録作業など、その日に誰かが触ったものが分かれば、切り分けの範囲は一気に狭まります。
逆に、社内で何も変更していない時間帯に突然始まったのであれば、自社の外にある基盤を疑う理由が一つ増えます。

問い合わせを受ける人の側でも、記録の形をそろえておくと切り分けが進みます。
連絡してきた取引先、使っていた画面や操作、表示されたメッセージ、発生した時刻を同じ並びで控えるだけで、特定の取引先だけの問題なのか、全体で起きているのかが見えてきます。
この記録は、後で取引先ごとに「あなたの注文はどうなったか」を説明するときの材料にもなります。

もう一つ、初動のうちに見ておきたいのが受注データの状態です。
注文の確定処理が途中で切れていると、取引先の画面ではエラーなのに自社側には注文が残っている、あるいはその逆が起こります。
エラーを見て再送を繰り返した取引先の注文が、重複して登録されていることもあります。
これは復旧作業そのものではありませんが、後で取引先に何をどう伝えるかを決める材料になるので、早い段階で状況を控えておくと説明が具体的になります。

必要な場合はシステム・サービスを停止する

IPAの手引きは、被害が拡大する可能性がある場合の初動として、ネットワークの遮断や対象機器の隔離、システム・サービスの停止を挙げています¹。
ただしBtoB通販では、止めるという判断そのものが取引先の発注業務を止める行為になります。
ここが一般的なインシデント対応の考え方をそのまま当てはめにくいところで、止める判断には自社なりの基準が要ります。

判断を分けるのは、動かし続けたときに間違った取引が成立し続けるかどうかです。
誤った価格が表示されている、在庫がないものを受け付けている、別の取引先の情報が見えてしまっているといった状態なら、稼働させたままにするほど後始末が増えます。
一方、表示が遅い、一部の帳票が出力できないといった不具合であれば、注意書きを出したうえで動かし続けたほうが取引先の業務は続きます。
迷ったときは、後から取り消しや訂正ができる不具合かどうかで切り分けると整理しやすくなります。

止めると決めた場合は、止まっていることと次の連絡が伝わる状態にしておきます。
サイトに掲示する案内文、システムを介さずに注文を受ける窓口、次に状況を知らせる時刻の目安を、同じ内容でそろえて出します。
この文面を障害の最中に一から作ると、書いては直しを繰り返して時間を取られるので、平常時に雛形を用意しておくと初動が短くなります。
取引先に何をどこまで伝えるかという中身は、この後の節で扱います。

障害の原因が自社か外部基盤かで、対応の範囲はどう変わるか

自社システム側が原因の場合の対応範囲

影響範囲が見えてくると、次に知りたいのは「自社で直せるのか」です。
この問いの答えで、復旧までの見通しも、取引先に伝えられる内容も変わります。
原因が自社のシステムやデータの側にあるなら、対応の主導権は自社にあります。

自社側が原因の場合にできるのは、直前の変更を戻す、設定やデータを修正する、詰まっている処理を解消するといった作業です。
大きな違いは、復旧の見通しを自分たちで見積もれることです。
切り戻しにどれくらいかかるかが分かれば、その見込みをそのまま取引先への案内に反映できます。
その代わり、受注データの不整合や欠落した注文の扱いも、最後まで自社の責任範囲に残ります。

ここで気をつけたいのは、復旧を急ぐあまり調査の材料を消してしまうことです。
ログの世代が上書きされる、エラー画面を控えないまま再起動する、修正前のデータを残さずに書き換える、といった作業は後の原因究明を難しくします。
復旧作業に入る前にログと該当データの控えを取っておくだけで、後から説明できる範囲が変わります。
この材料は、復旧後の原因調査でそのまま使うことになります。

外部のクラウド・決済・物流基盤が原因の場合の対応範囲

原因が外部の基盤側にある場合、状況は大きく変わります。
サーバーを借りているクラウド、決済代行、物流や配送の事業者、取引先とつなぐEDIの中継サービスなど、BtoB通販は自社の外にある仕組みに支えられています。
その側で障害が起きているなら、自社で修復することはできません。
できるのは、どこまでが外部の影響かを切り分けること、代わりの受注手段を出すこと、事業者から出てくる情報を取引先へ中継することです。

自社で直せない以上、どこまで対応してもらえるのかは契約で決まります。
その基準になるのがSLA（サービス品質保証。
提供事業者が稼働率などの水準と、下回った場合の扱いをあらかじめ定めた取り決め）です。
例えばAmazon EC2のSLAでは、リージョンごとの月間稼働率が99.99%以上になるよう商業上合理的な努力をするとされ、水準を下回った場合は返金ではなく、将来の利用料から差し引かれるサービスクレジットとして扱われます²。
月間稼働率が95.0%を下回った場合のサービスクレジットは100%と定められています²。

この数値は、確認した時点におけるAmazon EC2のコンピュート向けSLA（リージョン単位）に限った基準です。
BtoB通販で使われるECパッケージや決済代行、物流、EDIの各サービスが、同じ水準や同じ補償方法を採っているとは限りません。
そのため、自社が使っている基盤ごとに契約書やSLAの条文を個別に確認する必要があります。
実例として押さえておきたいのは数値そのものより、外部基盤の契約には「どこまでを保証し、下回ったら何をするか」があらかじめ書かれている、という点のほうです。

もう一つ、SLAによる補償と取引先への対応は別だという整理も要ります。
サービスクレジットは自社が支払う利用料に対する割引であって、発注できなかった取引先の損失を埋める仕組みではありません²。
外部が原因であっても、取引先から見れば自社のBtoB通販システムが止まっている状態に変わりはありません。
連絡も、受注データの後始末も、自社が担うことになります。

復旧までの間、取引先企業への連絡はどう進めるか

事前に取り決めた代替提供内容を基準に案内する

復旧作業と並行して進めなければならないのが、発注できない取引先への連絡です。
BtoBの発注は、相手の生産計画や在庫の補充に紐づいていることが多く、止まった時間そのものより「いつ発注できるようになるか分からない」ことのほうが相手の業務を止めます。
そして障害の最中に代替案を一から決めようとすると、社内の合意を取るだけで時間が過ぎていきます。

中小企業庁のBCP策定運用指針は、大企業が取引先や協力会社にBCPに沿った部品調達・サービス提供を求める動きがあることを挙げ、緊急時に提供できるサービスの内容を関係者とあらかじめ協議しておくことを勧めています³。
これは中小企業全般に向けた事業継続の指針で、BtoB通販の障害を名指しした記述ではありません。
ただ、発注の受け皿として取引先の業務に組み込まれている以上、止まったときに何を提供できるかを平時に決めておく意味は、同じように当てはまります。

事前に決めておけるのは、例えば次のような項目です。
電話・メール・FAXなど、システムを介さずに注文を受ける手段と、その受付時間を決めておきます。
緊急時に優先して処理する取引先や品目の考え方も、あらかじめ握っておける部分です。
締め日や納期をずらす場合に、誰が取引先と話し、社内で誰が承諾できるかも先に決められます。
これらが決まっていれば、障害中の連絡は「決めてあることを案内する」作業に変わります。

一方で、障害が続いている最中の連絡について、どのタイミングでどの手段を使うかまでを具体的に定めた公的な指針があるわけではありません。
ここからは実務上の提案として読んでいただきたいのですが、進行中の連絡は、確定していること、まだ分からないこと、次に連絡する時刻の三つを分けて伝えると行き違いが減ります。
復旧の見込みが読めない段階で曖昧な時刻を出すと、その時刻に戻らなかった時点で説明がもう一度必要になります。
分からないことは分からないまま伝え、次の連絡時刻だけを約束するほうが、取引先も自社の段取りを組み直せます。

復旧後に対応状況・再発防止策を正式に報告する

IPAの手引きは、対応が完了した後に、被害者や取引先、顧客といった関係者へ対応状況と再発防止策を報告する必要があるとしています¹。
障害中の連絡が「いま何が起きているか」を伝えるものだとすれば、復旧後の報告は「何が起きて、これからどうするか」を残す文書です。
口頭やチャットで済ませず文書の形で出しておくと、取引先の担当者が自社内で説明するときにそのまま使えます。

報告に含めておきたいのは、発生と復旧の日時、影響した機能と取引先の範囲、原因、影響を受けた注文の扱い、そして再発防止として何をいつまでに行うかです。
とくに注文の扱いは、取引先が自分たちの発注データと突き合わせる部分なので、重複して登録された注文をどう処理したか、失われた注文をどう再登録したかまで書いておくと、後の問い合わせが減ります。
原因が外部の基盤側にあった場合は、事業者から公表された内容と、自社が取った対応を分けて書くと、どこまでが自社の責任範囲だったのかが正確に伝わります。

再発防止策は、報告の時点で確定していないこともあります。
その場合は調査中であることを書いたうえで、いつまでに続報を出すかを添えるほうが、根拠の薄い対策を並べるより信頼を保てます。
ここで書いた再発防止策は、そのまま次の節で扱う平時の体制づくりの入口になります。

復旧後、原因究明と再発防止のために何を整えるべきか

5W1Hで発生状況・原因を調査する

IPAの手引きは、復旧と再発防止の段階で、発生状況をいつ・どこで・誰が・何を・なぜ・どうしたかという5W1Hの観点で調べ、原因を明らかにしたうえでシステムを修復するとしています¹。
この枠組み自体はセキュリティインシデント全般に向けたもので、BtoB通販システムの技術的な調査手順を定めたものではありません。
ただ、当てはめる対象を決めてしまえば、そのまま障害報告の骨組みとして使えます。

BtoB通販システムに当てはめると、いつは最初に注文が失敗した時刻、どこでは止まった機能やサーバー、誰がはどの取引先のどの権限の利用者、何をはそのときの操作、なぜは原因、どうしたかは実施した復旧作業という置き方になります。
ここまでを埋められるかどうかは、障害の最中に記録を残せていたかで決まります。
初動で経過の記録係を置いておく意味は、この段階で出てきます。

記録がないまま復旧だけが終わると、原因は「おそらくこれだろう」で止まります。
推測のまま再発防止策を決めると、実際には別の要因が残ったままになり、同じ障害が繰り返される余地を残します。
調査の材料が足りなかったのであれば、そのこと自体を課題として書き残し、次は何を取得できるようにするかを決めておくほうが確実です。

平常時からのBCP体制に反映する

中小企業庁のBCP策定運用指針は、緊急事態からの事業継続と早期復旧を図るために、平常時からの体制整備と計画の運用を求めています³。
障害対応で分かったことを、この平時の枠組みに戻すのが最後の仕事です。
戻し先が決まっていないと、報告書を書いた時点で作業が終わってしまいます。

反映しやすいのは、次のようなところです。
取引先ごとの連絡先と、担当者が不在のときの連絡経路を更新します。
システムを介さずに受けた注文を、誰がどうやって自社システムへ戻すのかという手順も残しておきます。
止める判断を誰が下せるかという権限の所在も、今回の対応で迷ったなら書き直す対象です。
そして、自社が使っている外部基盤の契約条件、とくにSLAで何がどこまで定められているかの一覧を作っておきます。

外部基盤の契約条件は、障害が起きてから読み始めると時間を取られる部分です。
保証されている稼働率の水準、下回った場合の扱い、障害の連絡がどこに届くのか、問い合わせ窓口と対応時間といった項目を契約ごとにまとめておくと、次に同じことが起きたときの切り分けが早まります。
ここまでの整理は、契約が複数にまたがっているほど効いてきます。

なお、この指針はあくまで事業継続の一般的な枠組みで、監視の強化のようなBtoB通販システム特有の技術的な対策まで定めているわけではありません³。
技術面の再発防止は、5W1Hの調査で見えた原因に沿って自社で決めることになります。
指針から持ってこられるのは、決めたことを平時の計画に載せて運用し続ける枠組みのほうです。

障害が長期化した場合、どのような基準で対応方針を切り替えるべきか

復旧の見込みを示せるかどうかで区切る

ここまでは、原因が切り分けられて復旧の見通しが立つ流れで進めてきました。
実際には、調べても原因が特定できない、外部の事業者から続報が出ない、復旧作業が失敗するといった形で、時間だけが過ぎることがあります。
この状態で判断を先送りすると、代替手段への切り替えも遅れ、取引先の発注業務が止まったままになります。

長期化かどうかを分けるのは、経過した時間そのものよりも、復旧の見込みを自社で示せるかどうかです。
自社が原因で切り戻しの段取りが見えているなら、多少時間がかかっても見通しは出せます。
逆に、原因が分からない、あるいは外部の事業者から復旧時刻が示されない場合は、いつ戻るかを前提にした対応を続けられません。
この二つを分けたうえで、後者に入った時点を切り替えの合図にする、という決め方ができます。

外部基盤が原因のときは契約上の区分が手掛かりになる

外部の基盤が原因の場合、判断の手掛かりの一つが、契約しているSLAの区分です。
Amazon EC2のSLAでは、リージョンごとの月間稼働率99.99%以上を目標としたうえで、稼働率が95.0%を下回った場合のサービスクレジットを100%とする段階が定められています²。
月単位で見て稼働率がどの区分に入るかは、その停止が契約上どれくらい重いものとして扱われるかの目安になります。

ただし、SLAは補償の基準であって、復旧までの時間を約束するものではありません。
99.99%という水準も、商業上合理的な努力をするという書き方です²。
したがって、条文を読んでも「あと何分で戻る」は分かりません。
分かるのは、この停止が契約上どの重さに当たるかと、後で何を申し出られるかのほうです。

この区分もAmazon EC2のSLAに限った例で、他のECパッケージや決済、物流の契約に同じ数値が当てはまるわけではありません。
また、原因が自社システム側にある場合や、SLAが定められていない契約・自社で用意したサーバーの場合には、こうした外部の基準そのものが存在しません。
その場合の長期化の目安は、自社で決めておくしかない部分です。
復旧の見込みを示せなくなった時点で切り替える、という考え方までは共通して使えます。

切り替えると決めたときに動かす中身も、平時に決めておける範囲があります。
システム経由の受注をいったん止め、電話やメールなど別の手段に寄せること、受け付ける内容を主要な品目に絞ること、締め日や納期の調整を取引先に依頼することなどです。
どれも障害の最中に新しく決めると時間がかかるため、事前の取り決めがそのまま効いてきます。
そして誰がこの切り替えを宣言するのかは、最初に決めた責任者の役割に戻ってきます。

ここまでの順序は、障害が起きてから読むより、起きる前に一度自社の構成と契約に当てはめておくほうが速く回ります。

障害のときにどこまで自社で復旧できるかは、システムの構成と外部基盤の契約の組み合わせで決まるため、社内の議論だけでは切り分けの線を引きにくいところです。

現在の構成と契約条件を見ながら、自社で直せる範囲、外部に委ねるしかない範囲、取引先へ出せる代替手段の候補を整理できます。無料相談で要件を整理する

要点の整理

軸	基準
初動の順序	体制の立ち上げ、影響範囲の確認、原因の切り分け、停止の判断
止めるかの判断	誤った価格・在庫・権限のまま取引が成立し続けるかどうか
原因が自社側	切り戻しや修正を自社で行え、復旧の見通しも自社で示せる
原因が外部基盤	修復は事業者側。対応範囲は契約したSLAの条文で確認する
取引先への連絡	進行中は事前に決めた代替手段を案内し、復旧後に文書で報告する
長期化の合図	復旧の見込みを自社で示せなくなった時点

再発防止まで含めると、平時の運用や受注データの後始末の仕組みにも手を入れる話になり、どこから着手するかの優先順位が付けにくくなります。 今回の障害で詰まった場所を起点に、先に整えるべき運用と、システム側で用意しておける備えを分けて確認できます。

よくある質問

障害の影響で発注できなかった取引先への謝罪・補償はどう考えればよいか

補償の要否や範囲は取引先との基本契約や個別の取り決めで決まる部分が大きく、一律の基準を示すことはできません。
まず必要なのは、発注できなかったことで実際に何が起きたのかを取引先ごとに把握することです。
外部基盤のSLAによるサービスクレジットは自社が支払う利用料への割引であり、取引先の損失を埋めるものではないため²、取引先への対応は別に考える必要があります。
金銭の話に入る前に、復旧後の報告で事実関係と再発防止策を正確に伝えておくこと¹が前提になります。

障害対応の窓口は社内のどの部門が持つべきか（EC運用・情報システムの役割分担）

手引きは責任者と担当者を定めることを示していますが、どの部門が持つべきかまでは定めていません¹。
実務上は、取引先の発注の事情を分かっているEC運用側が連絡の窓口を持ち、情報システム側が原因調査と外部事業者とのやり取りを担う分担が動かしやすい形です。
大事なのは部門名よりも、取引先へ出す情報を一本化することと、止める判断を下す人を一人に決めておくことです。

クラウド基盤以外（決済代行・物流会社）が原因の場合も同じ考え方で切り分けてよいか

自社で修復できず、対応の範囲が契約で決まるという点は同じ考え方で切り分けられます。
ただし保証の水準や補償の方法は事業者ごとに異なり、Amazon EC2で確認できる稼働率や補償の形²がそのまま当てはまるわけではありません。
影響の出方も違います。
決済が止まれば注文を確定させるかどうかの判断が要りますし、物流側なら注文は受けられても出荷が遅れるという形で表れます。
契約条件と、取引先への影響の出方の両方を基盤ごとに整理しておくと、次の判断が早まります。

障害対応の記録は、次のBCP見直しにどう活かせばよいか

5W1Hで整理した記録¹は、原因の特定だけでなく、平時の体制のどこが足りなかったかを示す材料になります。
連絡が遅れたなら連絡経路、代替手段を出せなかったなら事前の取り決め、契約条件を調べるのに時間がかかったならSLAの一覧、というように、詰まった場所とBCPの項目を対応させて見直すと反映しやすくなります。
指針も、平常時からの体制整備と計画の運用を求めています³。

1. 1　出典：独立行政法人情報処理推進機構（IPA）「中小企業のためのセキュリティインシデント対応の手引き」（2023年）
2. 2　出典：Amazon Web Services, Inc.「Amazon Compute Service Level Agreement（Amazon EC2 SLA）」（2026年・確認時点）
3. 3　出典：中小企業庁（経済産業省）「中小企業BCP（事業継続計画）策定運用指針 第2版」