B2B EC停止のリスクとは？原因の優先順位と対策の選び方

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

B2B EC-COLUMN

B2B ECが停止すると受注・出荷・売上計上はどう止まるか

取引先から「発注画面が開かない」と連絡が入った時点で、止まっているのは新規注文の受け付けだけではありません。
前日までに確定した注文の出荷指示も、締めに向けた売上計上も、同じ仕組みの上で動いていることが多いからです。
停止の原因は機器や回線の障害からサイバー攻撃まで幅広く、すべてに同じ重さで備えるのは現実的ではありません。
優先順位をつける手がかりのひとつがIPAの「情報セキュリティ10大脅威 2026」で、取引先や委託先を狙った攻撃が組織編2位に位置づけられています¹。
まずは受注から売上計上までのどこが止まると痛いのかを自社の流れに沿って洗い出し、外部に委ねる部分は契約前にセキュリティ対応を確かめ、止まっている間の受注手段を決めておく。
この三つが、停止リスクへの備えの出発点になります。

受注・出荷・売上計上が同時に止まる仕組み

B2B ECは、注文を受け取る窓口であると同時に、取引先ごとの単価や掛け率、与信枠、納期、出荷指示、請求のもとになるデータを抱える帳簿の役割も兼ねていることが少なくありません。
一般消費者向けのサイトなら、止まっている間に入るはずだった注文を取り逃すことが主な損失です。
企業間取引では、すでに受け取った注文をこれから動かすための情報も同じ場所にあるため、入口が閉じるだけでは済みません。

仮に当日出荷の締め時刻の直前に止まったとします。
取引先が新しく注文を入れられないことに加え、確定済みの注文を倉庫へ渡すためのピッキング指示が出せません。
すでに印刷して倉庫に渡した分は作業が進みますが、その後に入った変更やキャンセルを反映できないため、取り消されたはずの品物が出荷されてしまう余地が残ります。
止まった範囲の外側でも、確認できない情報を前提に人が動き続けるところに、あとから手直しの必要な作業が積み上がっていきます。

売上計上の側にも影響が伸びます。
出荷実績が計上へ回らなければ、締め処理と請求書の発行がその分だけ後ろにずれます。
停止が月末の締め日にかかると、請求書の発送が遅れ、取引先の支払サイクルにも合わなくなります。
復旧後に数日分の処理をまとめて流すことになるため、経理と物流の担当者には通常業務と復旧作業が同時に乗ることになります。

停止中に電話やメールで注文を受ける運用へ切り替えた場合も、作業は先送りされるだけです。
控えておいた注文を復旧後に本システムへ入力し直し、その間に取引先が再送していた分と重複していないかを突き合わせる必要があります。
取引先ごとに単価や掛け率が違う企業間取引では、システムの外で受けた注文ほど金額の誤りが混じりやすく、照合には注文の件数以上の時間がかかります。
停止のコストは、サイトが見られなかった時間の長さだけでは測れません。

ここまでは、受注から売上計上までを一つの仕組みで処理している場合の話です。
受注はB2B EC、出荷指示は倉庫システム、売上計上は基幹システムと分かれていて、それぞれが独立して動けるなら、止まる範囲は入口に近いところに限られることもあります。
逆に、在庫数や与信の残高をB2B EC側が持っているなら、他のシステムが生きていても判断材料が欠けて動けません。
自社の場合にどこまでが同じ仕組みに乗っているのかを、発注から請求までの順に並べて確かめておくと、停止したときに真っ先に困る工程が見えてきます。

停止は取引先との関係にどう波及するか

取引先側に生じる影響

取引先の購買担当者から見れば、自社のB2B ECの停止は「発注ができない」という一点に集約されます。
在庫を見ながら補充をかけている取引先や、決まった曜日に発注をまとめている取引先では、その回の発注を逃すと納品リードタイムの分だけそのまま入荷が遅れます。
遅れは取引先の在庫計画や生産計画にずれを生み、さらにその先の納品先にも順に伝わっていきます。
自社の停止時間は数時間でも、商流の下流で生じる遅れはそれより長く尾を引きます。

止まっている間、取引先が知りたいことは二つに絞られます。
いつ戻るのか、そして今すぐ別の方法で発注できるのか、です。
この二つに答えが返ってこないと、取引先は自分の納期を守るために、在庫を持っている別の仕入先へ振り替えるという判断に傾きます。
いったん別の経路で回った発注が、復旧したからといって自動的に戻ってくるとは限りません。
停止そのものより、停止中に連絡がつかなかったことのほうが関係に残ることがあります。

代替の受注手段は、電話番号とメールアドレスを案内すれば足りるというものではありません。
誰がその窓口で受けるのか、どの様式で控えるのか、在庫の引当と与信をどう確認するのか、復旧後にどの順で本システムへ取り込むのか。
ここまで決まっていないと、受けた注文の一部が宙に浮きます。
特に単価は取引先ごとに異なるため、システムの外で受けるときに参照できる価格の一覧を、あらかじめ担当者が手元に置ける形にしておけるかどうかで、復旧後の手戻りの量が変わります。

影響の集中のしかたは、取引構造によって違います。
売上の大半を数社の大口取引先が占めているなら、停止の痛みはその数社への対応に集中し、電話で個別に状況を説明するという方法が現実的に成り立ちます。
一方、小口の取引先が数百社あるような構造では、一社ずつ連絡する運用は回りません。
この場合は、サイトが止まっていても掲示できる連絡先や、一斉に状況を知らせる手段を、平時のうちにどこへ置いておくかが論点になります。
どちらの構造かによって、備えるべき代替手段の形が変わります。

自社が発注する側で、取引先のB2B ECが止まることを心配している場合は、見る向きが逆になります。
発注履歴や型番、取り決めた単価を自社側にも控えておくこと、取引先の営業担当者と電話でつながる経路を把握しておくこと、そして主要な品目について切り替え可能な調達先があるかを確認しておくことが、止まったときに動ける範囲を決めます。
相手のシステムの堅牢さは自社では変えられませんが、止まった前提で何分後に誰へ電話するかは自社で決められます。

停止原因のうち何を最優先で警戒すべきか－IPA「情報セキュリティ10大脅威2026」に見る傾向

ランサム攻撃の位置づけ

B2B ECが止まる原因を並べると、サーバや回線の障害、利用しているクラウド基盤側の障害、アクセスの集中、リリース作業や設定変更の誤り、証明書やドメインの期限切れ、そしてサイバー攻撃と、性質の違うものが並びます。
それぞれ打つ手も費用も違い、すべてに同じだけ投資できる会社はまずありません。
どこから手を付けるかを社内で説明するとき、自社の感覚だけでは根拠になりにくいため、公的機関が整理した脅威の位置づけを手がかりにする方法があります。

IPAの「情報セキュリティ10大脅威 2026」の組織編では、ランサム攻撃による被害が1位に選出され、11年連続11回目の選出となっています¹。
10年以上にわたって上位に置かれ続けている脅威であり、一時的な流行として扱えるものではありません。

ランサム攻撃による停止は、サイトの表示が重くなるといった種類の停止とは質が違います。
受注データ、在庫、出荷指示といった業務データそのものが使えなくなるため、サイトを再起動すれば戻るという復旧のしかたが通用しません。
戻せるかどうかは、バックアップをどの頻度で取り、どこに保管し、実際に戻す手順を試したことがあるかで決まります。
バックアップが本番と同じ場所に置かれていれば、まとめて巻き込まれる可能性があるという点も、備えを考えるうえで見落としやすいところです。

ここで注意しておきたいのは、この順位が脅威の重要度についての選考結果であって、個々の企業が被害に遭う確率や被害の件数を示した統計ではないという点です¹。
「1位だから自社も高い確率で狙われる」という読み方はできません。
使い方としては、どの脅威に社会全体として関心と対策が集まっているかを知り、自社の業務が止まったときの痛みの大きさと重ね合わせて優先順位を決める、という形になります。

サプライチェーン攻撃の位置づけ

同じ2026年版の組織編で、サプライチェーンや委託先を狙った攻撃は2位に位置づけられており、2019年の初選出以来8年連続8回目の選出となっています¹。
ある年だけ跳ね上がったのではなく、8年にわたって上位に置かれ続けているという継続性が、この脅威の特徴です。
取引先や外部委託先を経由して対象企業への侵入を図るという手口の性質上、自社の中だけを固めても守り切れない点が、B2B ECの停止リスクを考えるうえで重く効いてきます。

B2B ECは、外部とつながることを前提にした仕組みです。
取引先の購買担当者がIDでログインし、基幹システムや倉庫システムとデータをやり取りし、構築や保守を外部のベンダーに任せていることも珍しくありません。
つながっている先のどこかでセキュリティ水準が落ちていれば、そこが入口になり得るという意味で、この手口が想定する構図にそのまま当てはまります。
言い換えれば、自社の対策状況だけを点検しても、リスクの半分しか見ていないことになります。

ランサム攻撃と取引先経由の攻撃は別々の脅威として並んでいますが、B2B ECが止まるという結果から見ると、しばしば地続きです。
委託先や取引先のアカウントを経由して入られ、業務データが暗号化されて動かなくなる、という経路が考えられます。
そのため「サイバー攻撃対策」とひとまとめにせず、誰が自社のシステムに触れられるのかという入口の話と、被害を受けたあとにデータをどう戻すのかという回復の話に分けて手を打つほうが、対策の抜けに気づきやすくなります。

一方で、攻撃だけを見ていればよいわけでもありません。
設定変更の誤りやリリース作業の失敗は、自社や保守委託先の手が届く範囲にある分、作業手順と確認体制の整備で減らせます。
脅威ランキングは攻撃への備えを優先する根拠にはなりますが、身近な原因を切り捨ててよいという根拠にはなりません。
順位の高い脅威から着手しつつ、自分たちの操作で起こしうる停止は手順で潰していく、という二本立てで考えることになります。

取引先経由の攻撃リスクを自社の取引構造にどう当てはめ、外部委託先に何を確認すべきか

自社の取引構造への当てはめ

取引先経由の攻撃という一般論を自社の話に変える作業は、自社のB2B ECに触れている相手を書き出すところから始まります。
取引先の購買担当者が使うログインID、基幹システムや倉庫システムとの連携、決済や与信の外部サービス、サイトの構築と保守を任せているベンダー、そのベンダーからの再委託先、そして利用しているソフトウェアの提供元。
ここに挙がった相手の数だけ、自社の外側に管理の境界があります。

受注側の立場で見ると、最も身近なほころびは取引先のアカウント運用です。
担当者が異動や退職をしてもIDが残ったまま使われている、部署で一つのIDを共用している、初期パスワードのまま運用されている、といった状態は、取引先の社内の話でありながら、入口になるのは自社のサイトです。
自社側でできることとして、長期間使われていないIDの扱いを決めておく、利用状況を定期的に取引先へ知らせて棚卸しを促す、といった仕組みがあるかどうかを確認しておくと、相手の運用に踏み込みすぎずに水準を上げられます。

委託先については、権限と記録が論点になります。
構築を任せたベンダーが保守のために持っている管理者権限、作業に使う接続経路、緊急時に本番環境へ入る手順。
これらが誰にどこまで開いていて、いつ誰が入ったのかが後から確認できる形で残っているか。
契約書に守秘義務の条項があることと、実際の作業が記録されていることは別の話です。

評価の最後に、依存度を重ねます。
売上の大半を一社の大口取引先が占めているなら、その一社に関わる経路で起きた事故が、自社の売上のほとんどを止めることになります。
停止リスクの評価は、起こりやすさだけでなく、起きたときに止まる範囲の広さと掛け合わせて見るものです。
なお、ここで示しているのは企業間取引に共通する評価の観点であり、自社の被害確率を数値として算出するための方法ではありません。

外部委託(ASP/クラウド型)ベンダーに確認したいセキュリティ対応の項目例

ASP/クラウド型のサービスを検討する段階では、そもそも何を聞けばよいのかが分からない、という状態から始まることがよくあります。
その場合は、実際に公開されている対応項目を下敷きにすると話が進みます。
一例として、EC-Rider B2B Ⅱは、ISMAP対応、ソフトウェアのセキュリティ対策、不正アクセス対策、第三者セキュリティチェック済み、ISMS取得済みの5項目を挙げています²。
これは一つのサービスが自社で掲げている対応内容であり、他のASP/クラウド型サービスが同じ構成や同じ水準であることを示すものではありません。

言葉の意味を押さえておくと、質問が具体的になります。
ISMAPは政府情報システムのためのセキュリティ評価制度で、政府が求める基準に沿って評価されたサービスが登録される枠組みです。
ISMSは情報セキュリティを管理する体制についての認証で、個別の機能ではなく運用の仕組みを対象にしています。
第三者セキュリティチェックは、自社の申告ではなく外部の診断を受けたという意味になります。
いずれも「何を対象に、いつ、誰が確かめたのか」を伴って初めて判断材料になります。

そこで、有無の確認で止めずに、対象範囲と時点と更新の三つを重ねて聞きます。
認証を持っているのは会社全体なのか、自社が使う予定のサービスと環境なのか。
診断はいつ実施され、次はいつ予定されているのか。
ソフトウェアの更新は誰が、どの頻度で適用し、緊急のセキュリティ修正が公表されたときはどれくらいで反映されるのか。
ここまで聞いておくと、資料上は同じように見えるサービスの間に差が見えてきます。

もう一つ、止まったあとの取り決めを忘れずに確認します。
障害が起きたとき、誰から誰へ、どの手段で連絡が届くのか。
復旧の見通しはどの間隔で共有されるのか。
自社が取引先へ説明するために必要な情報が、委託先から降りてくる形になっているか。
これは技術仕様ではなく契約と運用の取り決めの話で、導入後に変更しようとすると手間がかかる部分です。

同じ質問は、自社構築の場合には保守を任せている委託先へ向かいます。
相手が変わるだけで、確認すべき中身はほとんど変わりません。
自社構築だから自分たちで把握できているとは限らず、実務上はベンダー任せになっている領域が残っていることも多いため、委託の形にかかわらず一度は書き出して突き合わせる価値があります。

自社構築かASP/クラウド型かで費用感と対策の取りやすさはどう変わるか

自社構築の費用構造

自社構築を選ぶ場合、費用は初期の開発とインフラの投資で終わりません。
止めないための運用が、そのあとずっと続きます。
稼働の監視、バックアップの取得と実際に戻せるかの確認、公表される脆弱性情報の追跡と修正の適用、障害が起きたときの一次対応。
これらは見積書に金額として並ぶものと、担当者の時間として静かに消えていくものが混ざっているため、比較のときに片方だけを数えると実態からずれます。

体制の費用を大きく動かすのは、時間帯の扱いです。
企業間取引は業務時間内の利用が中心とはいえ、夜間にバッチ処理を走らせていたり、時差のある取引先がいたりすれば話が変わります。
24時間の対応を自社で持つのか、保守委託先に任せるのか、翌営業日の対応で許容するのか。
この判断が、同じ規模のサイトでも運用費用に大きな幅を生みます。
そして停止が起きたときに実際に動ける時間帯も、ここで決まります。

自社構築の強みは、自社の商流に合わせられることです。
取引先別の単価や掛け率、社内の承認フロー、既存システムとのつなぎ方を、自分たちの都合で設計できます。
裏返すと、独自に作り込んだ部分が多いほど、更新のたびに動作確認が必要な範囲が広がります。
検証が重いという理由で更新を先送りすると、適用されないままのセキュリティ修正が積み残り、止まるリスクの側が静かに増えていきます。
自由度を活かせるかどうかは、作り込みの巧拙より、その後も手を入れ続けられる体制があるかにかかっています。

ASP/クラウド型の費用構造(EC-Rider B2B Ⅱの例)

ASP/クラウド型は、インフラの運用とセキュリティ対応をベンダー側の費用に含めて委ねる形です。
自社で専任の体制を持たないかわりに、月々の利用料が継続して発生します。
金額の出方を具体的に見ておくと、自社構築との比較がしやすくなります。

一例として、EC-Rider B2B Ⅱのベースエンジン利用料は月額170,000円からで、ECサイト稼働の負荷分散および社内外システム連携用のリソースを確保した構成をモデルケースとしています³。
ASP利用料金は月額260,000円で、こちらもモデルケースの金額です³。
いずれもサーバー構成や各種要件の変更に伴って月額料金が変わるとされています³。
これは一つの製品の特定の構成についての金額であり、ASP/クラウド型サービス全体の相場や他社の水準を示すものではありません。

比較するときに月額だけを自社構築の保守費と並べても、判断の材料にはなりません。
自社構築の側に、監視や更新や障害対応に費やす人の時間、保守委託の費用、数年ごとに必要になる更新投資を足して、はじめて同じ土俵に乗ります。
人件費は社内では見えにくい費用ですが、止めないための作業に月に何日分を割いているかを概算するだけでも、比較の輪郭は変わります。

費用のほかに、停止したときの立場の違いがあります。
ASP/クラウド型では自社が手を出せる範囲が狭く、復旧そのものは待つ場面が増えます。
そのかわり、日常の監視や修正の適用を専門の体制が担います。
どちらが安心かは一般論では決まらず、自社が運用に割ける人数と時間の実態で決まります。
そして、自分では触れない部分が多いからこそ、契約前にセキュリティ対応と障害時の連絡の取り決めを確かめ、止まっている間の受注手段を自社側で用意しておくことが効いてきます。

B2B ECの停止は、受け付けが止まることよりも、確定済みの注文と売上計上が同時に動かなくなることで広がります。
そして取引先の側では、発注できない時間の長さより、状況が分からない時間の長さが判断を変えます。
原因のすべてに同じ重さで備えることはできませんが、取引先や委託先を経由した攻撃が8年にわたって組織編の上位に置かれ続けているという事実は、外部との接点を優先して点検する根拠になります¹。
接続先を書き出し、委託先には対象範囲と時点まで踏み込んで確認し、止まっている間の受注手段を決めておく。
この順で進めれば、費用をかける前に減らせる停止リスクが見えてきます。

受注から売上計上までのどこまでが同じ仕組みに乗っているかは、社内で長く運用しているほど当たり前になっていて、抜けに気づきにくい部分です。

現在の受注から請求までの流れを一緒に並べ、止まったときに真っ先に困る工程と、外部に委ねている接続先の洗い出し方を確認できます。無料相談で要件を整理する

停止原因の優先順位を知る－IPA組織編ランキングに見るサイバー攻撃の位置づけ

順位は公表された調査に依ります¹。

自社の停止リスクとして読み替えるときは、順位そのものではなく、どの経路から入られると受注から売上計上までのどこが止まるのかという順で並べ替えます。

要点の整理

軸	確認すること
影響の広さ	受注・出荷指示・売上計上のうち、どこまでが同じ仕組みに乗っているか
取引先対応	復旧の見通しの伝え方と、代替受注の窓口・様式・復旧後の取り込み手順
原因の優先順位	取引先や委託先を経由した侵入経路を、自社の接続先一覧に当てはめて点検する
委託先の確認	セキュリティ対応の対象範囲・時点・更新頻度と、障害時の連絡の取り決め
費用の比較	月額だけでなく、自社構築側の運用の時間と保守委託費を足して並べる

自社構築を続けるか外部委託へ移すかは、月額の金額だけでは決まらず、自社が運用に割ける時間と、止まったときに誰が動くかの取り決めまで含めて見る必要があります。 想定する構成での費用の出方と、セキュリティ対応や障害時の連絡がどこまで委託側に含まれるかを、確認済みの内容に沿って具体的に確かめられます。

よくある質問

停止が数時間で復旧する場合と数日に及ぶ場合とで、取引先への対応はどう変えるべきか

数時間で戻る見込みなら、取引先が必要としているのは代替手段より見通しです。
復旧のめどと、その時間内に締切のある注文をどう扱うか（電話で受けるのか、翌日の出荷に振り替えるのか）を伝えれば、取引先は自社の予定を組み直せます。
数日に及ぶ場合は前提が変わり、代替の受注窓口を正式に開く判断が必要になります。
誰が受け、どの様式で控え、単価と在庫をどう確認し、復旧後にどう取り込むかまで決めてから案内しないと、受けた注文が宙に浮きます。
加えて、取引先が別の仕入先へ切り替える検討に入る局面でもあるため、出荷可能な在庫がある品目だけでも先に知らせておくと、取引の継続に効きます。
どこで線を引くかは、自社の納品リードタイムと取引先の在庫の持ち方によって変わります。

自社構築のB2B ECからASP/クラウド型へ切り替える際、停止リスクの観点でまず何を確認すべきか

最初に確認するのは、今のシステムで自社が担っている役割のうち、どこまでがベンダー側に移り、どこからが自社に残るのかという線引きです。
監視、バックアップ、修正の適用がベンダー側に移るなら、その分の自社の作業は減りますが、障害時に自分で手を出せる範囲も同時に狭まります。
次に、障害が起きたときの連絡の取り決めを確認します。
誰から誰へ、どの手段で第一報が届き、復旧の見通しがどの間隔で共有されるか。
自社が取引先へ説明するための材料が降りてくる形になっているかが要点です。
あわせて、受注データや取引先別の単価をいつでも自社側へ取り出せるかも確かめておくと、止まっている間に別の手段で受注する際の備えになります。

ベンダーのセキュリティ対応（ISMS認証や第三者診断の有無）を契約前にどう確認すればよいか

有無を尋ねるだけでは差が見えないため、対象範囲と時点と更新の三つを重ねて聞きます。
認証は会社全体に対するものか、自社が利用する予定のサービスと稼働環境を含むのか。
第三者による診断はいつ実施され、次はいつ予定されているのか。
ソフトウェアの更新は誰がどの頻度で行い、緊急のセキュリティ修正が公表されたときの適用の流れはどうなっているのか。
質問の項目立てに迷う場合は、公開されている対応内容を出発点にすると具体的になります。
たとえばEC-Rider B2B Ⅱは、ISMAP対応、ソフトウェアのセキュリティ対策、不正アクセス対策、第三者セキュリティチェック済み、ISMS取得済みの5項目を挙げています²。
これは一つのサービスの対応内容であり他社が同じ構成とは限りませんが、比較の枠組みとしては使えます。

特定の取引先への依存度が高い場合、停止リスクの評価はどう変わるか

評価の重心が、起こりやすさから影響の大きさへ移ります。
売上の大半を数社が占めていると、その取引に関わる経路で起きた一件が、自社の受注のほとんどを止めることになるためです。
具体的には、その取引先とのやり取りに使っているアカウントや連携の経路を優先して点検し、停止時にはその数社へ確実に届く連絡手段を平時から確保しておく、という形になります。
大口が相手であれば、電話や担当者経由で個別に対応する代替手段が現実的に成り立つという利点もあります。
逆に小口の取引先が多数ある構造では、一社ずつの連絡は回らないため、止まっていても掲示できる連絡先や一斉に状況を知らせる手段を、平時のうちに決めておくことが実務的な備えになります。

1. 1　出典：独立行政法人情報処理推進機構（IPA）「情報セキュリティ10大脅威 2026（組織編）」（2026年）
2. 2　出典：株式会社フライトソリューションズ「安心・安全なセキュリティ（EC-Rider B2B Ⅱ 機能紹介）」（2026年）
3. 3　出典：株式会社フライトソリューションズ「料金プラン・費用｜BtoB EC受発注システム EC-Rider B2B II」（2026年）