Web受発注システムで障害が起きたときの対応と、再発を防ぐ選び方のポイント

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

B2B EC-COLUMN

Web受発注システムの障害が起きたとき、まず確認することと代替手段の範囲

注文画面が開かない、受注データが取り込めない。
Web受発注システムが止まると、発注する側は在庫を切らさないための手配ができず、受注する側は届いているはずの注文を確認できなくなります。
この局面で自分たちが変えられるのは復旧の速さではなく、止まっている間の受け方と、取引先への伝え方です。
実際に起きた障害では、システムを使わずファクスで受注する手作業運用に切り替えるまでに日数がかかり、再開した当初は取り扱う商品を絞った限定的なものにとどまりました²。
原因がベンダー側にあるのか、自社の設定や回線にあるのかを切り分けながら、契約書のサービス水準や責任分界の条項を確認し、代替手段で業務を段階的につなぐ。
障害対応の芯はここにあり、同じ視点は次のシステムを選ぶときの確認項目にもそのまま使えます。

実際の障害ではどこまで業務が止まるのか

システムが開かない瞬間に起きているのは、「自社だけの問題なのか、サービス全体の問題なのか分からない」という状態です。
ここが曖昧なまま復旧を待つと、取引先への連絡が後手に回り、相手側では「注文は通ったのか、通っていないのか」が分からない時間だけが伸びていきます。
最初に手を動かすべきなのは原因の特定ではなく、状況の範囲を見極めることです。

範囲を見極める材料は、特別なものではありません。
別の端末や別のネットワーク、別のアカウントで同じ症状が出るかどうか。
社内で使っている他のクラウドサービスも同時に重くなっていないか。
ベンダーが障害情報を掲示しているページや、配信されるお知らせメールに記載が出ていないか。
そして、取引先から「注文が送れない」という連絡が来ているかどうか。
この四つが揃うと、自社の端末や回線の問題なのか、サービス側で広く起きていることなのかが、かなりの確度で見分けられます。

問題は、この見極めが済んだあとです。
サービス側の障害だと分かったとして、何時間で戻るのかは利用者側からは決められません。
参考になるのは、実際に起きた障害がどう推移したかという記録です。
2025年10月、アスクルはランサムウェア感染によるシステム障害で受注・出荷業務が停止しました²。
システムを使わずファクスで受注を受け付ける手作業運用を試験的に始めたのは、発生からおよそ10日後のことで、受注の対象商品はコピー用紙やペーパータオルなど一部のアイテムに限定され、対象の顧客と商品を順次広げながら全面復旧を目指すという進め方でした²。

これは特定の一社に起きた、ランサムウェアという特定の原因による事例です。
原因や規模が違えば、停止期間も代替運用の広さも変わります。
それでも、ここから引き出せる見立てが一つあります。
「夕方には戻るだろう」という前提だけで待ち続ける構えは、持っておかないほうが安全だということです。

そのため、障害に気づいてから最初の数時間でやるべきことは、原因の究明ではなく、復旧の見通しが立たない場合にどう受けるかを決めることになります。
取引先に何を伝え、どの窓口で注文を受け、受けた注文をどこに記録するのか。
この三点が決まっていれば、復旧が長引いても業務は細い線でつながります。

手作業・ファクスなど代替手段の現実的な限界

代替手段という言葉から思い浮かぶのは、「システムでやっていたことを、そのまま紙と電話に置き換える」という絵かもしれません。
ただ、実際の障害で立ち上がった手作業運用は、対象の商品を絞ったところから始まり、対象を順次広げていく形をとっていました²。
最初から全商品を受けなかったのには、実務上の理由があります。

受発注システムが担っているのは、注文を受け取る窓口だけではありません。
取引先ごとの単価、在庫の引き当て、出荷可能日、過去の取引条件といった情報を、注文の入力と同時に照らし合わせています。
システムが止まると、この照合が一件ずつの手作業に戻ります。
商品点数が多いほど、また取引先ごとの条件が細かいほど、一件あたりにかかる時間は膨らみます。
対象を絞るのは手抜きではなく、確認が追いつく範囲まで入口を狭めて、誤った受注を出さないための判断です。

自社で代替手段を立てるときも、同じ考え方が使えます。
全商品を受け付けようとして窓口が詰まるより、動きの速い定番品や、条件の確認が要らない取引先から受けるほうが、結果として流せる量は増えます。
どの商品、どの取引先から受けるかは、障害が起きてから考えると判断に時間がかかるところです。

もう一つ、見落とされやすいのが復旧後の処理です。
手作業で受けた注文は、システムが戻ったあとに入力し直すことになります。
このとき受付の控えに通し番号や受付時刻が入っていないと、どれが入力済みでどれが未入力なのかが分からなくなり、同じ注文が二重に登録される余地が生まれます。
取引先が障害中に電話とファクスの両方で同じ注文を送っていた場合も同様です。
受付の様式に番号欄と受付時刻欄を一つ足しておくだけで、復旧後の突き合わせで確認する項目が、注文内容そのものから「番号が連番でつながっているか」へ減ります。

取引先の側にも負担が生じる点も、伝え方に関わります。
ファクスや電話での発注は、相手の担当者にとっても普段と違う作業です。
どの番号へ、どの様式で、いつまでに送ればその日の出荷に間に合うのか。
この三つを連絡の最初に書いておくと、問い合わせの電話が減り、その分を受注の処理に回せます。

障害の原因にはどんな種類があり、自社対応とベンダー対応はどこで分かれるか

報告されてきた障害原因の主な類型

代替手段で当座をしのげたとして、次に効いてくるのは「何が起きたのか」の見立てです。
原因の種類によって、復旧までの見通しも、自社側で打てる手の有無も変わるためです。

情報処理推進機構（IPA）は、社会的影響が大きく全国紙などで報道された情報システム障害を2010年から収集し、発生要因ごとに分類して公開していました¹。
大規模通信障害、セキュリティ事故に起因する障害、システム統合の問題、トラフィック集中による障害、テスト作業が本番環境に悪影響を及ぼしたもの、業務処理の誤りが長期間見逃されていたもの、といった区分です¹。
この取り組みは2019年後半のデータを最後に終了しており、また受発注システムに限った調査でもありません¹。
それでも、障害という一語がいくつもの異なる事象をまとめた言葉であることは、ここからはっきり読み取れます。

この類型が自社の状況を見るときに役立つのは、原因ごとに「気づき方」が違うからです。
通信障害が絡んでいるなら、受発注システムだけでなく社内の他のクラウドサービスも同時に不調になります。
アクセスの集中が原因であれば、特定の時間帯だけ極端に重くなり、時間をずらすと通ることがあります。
セキュリティ事故に起因する障害では、サービスが意図的に停止される場合があり、復旧の判断にベンダー側の調査完了が必要になるため、待ち時間が長くなりやすい性質があります。

最も気づきにくいのは、業務処理の誤りが長期間見逃されていた類型です¹。
画面は普通に動き、注文も通る。
ただし計算や振り分けの結果が間違っている、という形で表れます。
受発注の文脈に引き直すと、単価の適用や在庫の引き当てが一部の条件でだけずれている、といった状況が当てはまります。
こうした障害は「止まらない」ため、取引先からの指摘や締め処理の差異で初めて見つかることがあります。
システムが動いているうちは障害ではない、という前提は置かないほうが安全です。

自社側の切り分けが必要な場面

原因の類型が頭に入ると、次は自社で切り分けられる範囲の話になります。
ベンダーに問い合わせる前の数分で確かめられることがあり、その結果は問い合わせの質にも直結します。

確かめる順番は、影響の広い側から狭い側へたどると迷いません。
社内の他のサービスも不調であれば、回線やネットワーク機器の側を先に疑います。
受発注システムだけが不調なら、次は別の端末やブラウザで再現するかを見ます。
特定の一人だけが使えないのであれば、権限設定やアカウントの状態といった自社で変更できる範囲に原因がある可能性が出てきます。
そして、直前に何か変えていないかを思い出します。
商品マスタの更新、アクセス元のIP制限の追加、ブラウザや端末の更新といった変更は、ベンダー側には見えないところで起きています。

この切り分けは、自社で原因を突き止めるために行うものではありません。
ベンダーに渡す材料を揃えるための作業です。
「使えません」という連絡だけでは、ベンダー側は再現の条件を探すところから始めることになります。
発生した時刻、操作していた画面と手順、表示されたエラーの文言、影響している人数、毎回起きるのか時々なのか。
これらを添えて連絡すると、調査の出発点が変わります。

切り分けの結果、自社側に原因が見当たらず、ベンダーの障害情報にも記載がない場合があります。
このときに判断を保留して待ち続けるのは、避けたいところです。
情報が出ていないことは、障害が起きていないことを意味しません。
障害情報の掲示は、原因の把握がある程度進んでから更新されることが多く、発生直後は空白の時間帯が生まれます。
自社側で再現し、他の端末でも再現するのであれば、掲示を待たずに問い合わせる根拠は十分にあります。

なお、ここでの切り分けは実務上の進め方であって、どの原因がベンダーの責任でどの原因が自社の責任か、という線引きそのものではありません。
技術的にどこで起きたかと、契約上どちらが責任を負うかは、別の物差しで決まります。
その物差しが次の論点です。

障害時の責任・補償はどこまで求められるか、契約書で確認すること

契約書で確認すべき条項

障害が長引くと、取引先からは「補償はどうなるのか」という問いが来ます。
社内でも、止まっていた間の損失をベンダーに請求できるのかという話が出ます。
ここで注意したいのは、答えが業界の相場ではなく、自社が結んだ契約書の中にしかないという点です。
サービス水準の約束も、賠償の範囲も、事業者ごと、契約ごとに異なります。
そのため以下は、契約書のどこを開けばよいかという読み方の提案として受け取ってください。

最初に探すのは、サービス水準に関する取り決めです。
SLA（サービスの提供水準をあらかじめ約束する文書）という名前で別紙になっていることもあれば、本文の一条として書かれていることもあります。
ここに何が約束されているのか、約束が守られなかったときに何が起きるのか（返金なのか、料金の減額なのか、何も定めがないのか）を読みます。
水準の数値そのものは契約ごとに違うため、他社の例を当てはめず、自社の文書に書かれている内容を確認することになります。

次が免責条項です。
自然災害や通信事業者側の障害、第三者による不正アクセスといった事象が、事業者の責任の外に置かれている場合があります。
どの事象が書かれているかによって、同じ停止時間でも結論が変わります。
そのうえで損害賠償の条項を見ます。
賠償の対象となる損害がどこまでか、上限の定めがあるかどうか。
上限が設けられている契約では、実際に生じた機会損失の額と請求できる額が一致しないことになります。

通知や報告についての条項も、障害の最中に効いてきます。
障害が起きたときに事業者から知らせることになっているのか、知らせる手段と宛先はどこか、事後の報告書は提供されるのか。
ここに定めがあれば、連絡が来ないこと自体を根拠に照会ができます。
定めがなければ、照会は依頼という位置づけになります。
この違いは、やり取りの進め方に直接響きます。

データの取り扱いについての条項は、停止そのものより影響が長く残る部分です。
障害中に失われたデータの復旧をどこまで行うのか、バックアップの保持についての定めがあるのか、自社のデータを取り出せる形式と手段は用意されているのか。
ランサムウェアのようにデータそのものが人質になる事象が障害の一類型として報告されてきたことを踏まえると¹、ここを読んでいるかどうかで復旧後の作業量が変わります。

確認が難しい場合の対応

ここまでの読み方は、落ち着いて契約書を開ける状況を前提にしています。
ところが障害の最中は、電話が鳴り続け、取引先への連絡に追われ、契約書の保管場所を探すところから始まることも珍しくありません。
この状態で条項を読み解こうとすると、対応そのものが止まります。

現実的なのは、障害が起きていない時期に要点だけを一枚にまとめておくことです。
契約書の原本がどこにあるか、障害時の連絡先と手段は何か、通知や報告の定めがあるか、賠償の上限の定めがあるか。
この程度の粒度で控えがあれば、障害の最中には控えを見て動き、詳細な条項の読み込みは落ち着いてから行う、という分担ができます。
契約書の内容が変わるわけではありませんが、判断にたどり着くまでの時間は変わります。

もう一つ、障害の最中にしかできないことがあります。
記録を残すことです。
いつ気づき、どの機能がどこまで使えなくなり、ベンダーに何時に連絡し、どんな回答があったか。
代替手段での対応に誰が何時間かかり、取引先に何件の連絡をしたか。
これらは時間が経つと再現できません。
のちに責任や補償の話をする段になって、停止の範囲と影響を具体的に示せるかどうかは、この記録の有無で決まります。

ベンダーからの説明が遅い場合も、記録が照会の土台になります。
いつ連絡して、どんな回答を得たかが時系列で並んでいれば、次の照会は「状況を教えてください」ではなく「前回の回答から何が進みましたか」という形になります。
障害の最中のベンダー側は問い合わせが集中していますから、重複した問い合わせを減らす意味でも、社内の窓口を一本にして記録を集約しておくほうが進みます。

復旧後には、原因と再発防止策を記した報告を求めることになります。
契約に報告の定めがあればそれに沿って、なければ依頼として求めます。
この報告は、同じ事業者との契約を続けるかどうかの判断材料にもなりますし、社内や取引先への説明の根拠にもなります。
受け取った報告が原因の記述にとどまり、再発を防ぐ手立てに触れていない場合は、その点を具体的に尋ねる余地があります。

再発を防ぐために、Web受発注システムの選定・運用で確認しておくこと

安全・信頼性の情報開示認定という目安

ここまでは、起きてしまった障害への対応でした。
残るのは、次に選ぶとき、あるいは今の契約を見直すときに何を確かめるか、という問いです。
難しいのは、障害への強さが外から見えにくいことです。
機能の一覧や画面の使いやすさは比較できても、止まりにくさや、止まったときの対応の体制は、提案資料を眺めただけでは判断がつきません。

この見えにくさを埋める手掛かりの一つが、第三者による情報開示の認定です。
ASP・SaaS・IoTクラウドコンソーシアム（ASPIC）は、総務省の「クラウドサービスの安全・信頼性に係る情報開示指針」（平成23年3月）に基づき、ASP・SaaS事業者が安全・信頼性に関する適切な情報開示を行い、一定の要件を満たしていることを認定する制度を運営しています³。
同制度は、認定によって「サービス及び事業者の比較・評価・選択が容易になります」としています³。

この制度が利用者側にもたらすのは、「開示されている」という状態です。
品質そのものの保証ではなく、比較に必要な情報が外に出ている状態を確かめられる、という性質のものです。
選定の初期段階で、候補を絞る材料として使えるのはこの点です。
提案を受けている事業者が認定を受けているかどうかは、公開されている情報から確認できますから、問い合わせる前の段階で調べられます。

ただし、この指針に基づく開示で具体的にどの項目が求められるのか、稼働率の数値を示す必要があるのかどうかといった細部は、制度の紹介ページだけでは確認できませんでした。
そのため、認定の有無を確認したうえで、自社が知りたい項目は個別に尋ねることになります。
認定は入口を絞る道具であって、確認の代わりにはなりません。

認定の有無だけで判断しない範囲

この認定は任意の制度であり、取得が法律で義務づけられているわけではありません³。
したがって、認定を受けていないことが直ちに品質の低さやリスクの高さを意味するわけではありません。
規模の小さい事業者や、特定の業界に特化したサービスでは、制度を利用していないという選択もあり得ます。
認定の有無は、候補を比べるときの一つの目安として扱うのが実態に合っています。

では、認定の確認に加えて何を尋ねるか。
障害対応の観点から挙げるなら、障害が起きたときに誰からどの手段で知らせが届くのか、障害情報はどこで公開されるのか、計画的な停止は事前に告知されるのか、自社のデータをどの形式で取り出せるのか、過去に起きた障害について報告がなされているのか、サポートを受けられる時間帯はいつか、といった点です。
どれも、提案資料の機能一覧には載りにくく、尋ねれば答えが返ってくる性質の項目です。

選定で確かめたことを、運用の側へつないでおく作業も残ります。
障害の通知がメールで届く仕組みなら、受け取る宛先が退職した担当者のままになっていないか。
障害情報の公開ページがあるなら、その場所を社内の誰が知っているか。
契約時には整っていた前提が、数年のうちに人の入れ替わりで崩れていることは珍しくありません。

そして、代替手段そのものの準備です。
障害時にファクスや電話で受けると決めていても、番号が現在も使える状態か、受付の様式が手元にあるか、取引先側の担当者に伝わっているかは、別の話です。
実際の障害では、代替運用の立ち上げは対象を絞った試験的な形から始まっていました²。
あらかじめ「この商品、この取引先から受ける」という優先順位を決めておけば、立ち上げの判断に割く時間を、受注の処理に回せます。

こうした備えは、障害を起こさないための対策ではありません。
障害が起きたときに、確認に追われる項目を減らすための準備です。
どれだけ整えても止まらない保証は得られませんが、止まったときに何から手をつけるかで迷う時間は確実に短くなります。

原因の種類によって、待ち方も問い合わせ方も変わります。
報道された障害がどのような要因で分けられてきたのかを、先に押さえておきます。

障害の最中は、自社の症状がどこまで広がっているのか、代替手段をどの範囲から立ち上げるのかを、社内だけで判断しきれないことがあります。

受発注のどの処理が止まっていて、どこから手作業で受けられるのかを一緒に整理し、復旧後の突き合わせで何を確認することになるかまで見通しを立てられます。無料相談で要件を整理する

報道された情報システム障害で分けられてきた原因の類型

IPAが2010年から2019年後半にかけて収集した、社会的影響が大きく全国紙等で報道された情報システム障害を、発生要因ごとに分けた区分です（受発注システムに限った調査ではありません）。

• 大規模通信障害

• セキュリティ事故に起因する障害

• システム統合の問題

• トラフィック集中による障害

• テスト作業が本番環境に悪影響を及ぼしたもの

• 業務処理の誤りが長期間見逃されていたもの

自社の症状がどの類型に近いかで、問い合わせる相手と、復旧を待つ間の構え方が変わります。

要点の整理

軸	基準
障害に気づいた直後	自社だけの事象か、サービス全体かを範囲から見極める
代替手段の立て方	対象の商品と取引先を絞り、受付番号と受付時刻を残す
原因の見立て	気づき方の違いから、通信・集中・セキュリティ事故などの類型に当てる
責任と補償	サービス水準、免責、賠償の上限、通知と報告の条項を自社の契約書で読む
選定時の確認	第三者による情報開示認定の有無を入口にし、通知手段とデータの取り出しを個別に尋ねる
運用での維持	通知の宛先と代替手段の連絡先が現在も使えるかを定期的に見直す

選定の段階で確かめるべき項目は、機能の一覧には現れにくく、提案を受けている最中に自力で洗い出すのは手間がかかります。 障害時の通知の受け取り方やデータの取り出し手段など、契約前に尋ねておきたい点を自社の取引条件に合わせて具体化し、確認の抜けを減らせます。

よくある質問

障害中に受け付けた注文データが、復旧後に消えていた場合はどうすればよいですか

頼りになるのは、障害中に自社側で残した控えです。
ファクスの受信控え、受付簿、メールの履歴を突き合わせ、どの注文が復旧後のシステムに入っているかを一件ずつ照合します。
受付番号や受付時刻を記録していれば、抜けている範囲を番号の連続性から絞り込めます。
そのうえで、契約書のデータの取り扱いに関する条項を確認し、復旧の対象や範囲について定めがあるかを見ます。
定めの内容は契約ごとに異なるため、一般的な水準を当てはめず、自社の文書で確認してください。
並行して、該当する取引先には注文内容の再確認を依頼することになります。
出荷済みかどうかが分からない状態を長く置くと、欠品と二重出荷の両方の可能性が残るためです。

ベンダーから障害の原因説明がなかなか来ないとき、どこに問い合わせを重ねればよいですか

まず、契約書に通知や報告についての定めがあるかを確認します。
定めがあれば、その条項を示したうえで照会できますし、定めがなければ依頼という位置づけで進めることになります。
問い合わせは、社内の窓口を一本にまとめ、いつ連絡して何を聞き、どんな回答があったかを時系列で記録しておくと進みが変わります。
同じ内容を複数の担当者が別々に聞くと、回答までの時間がかえって伸びます。
障害の最中は原因の調査自体が終わっていないこともあるため、発生直後は「現時点で分かっていること」と「次の連絡の予定時刻」を尋ね、原因の詳細は復旧後の報告として求める、という分け方が現実的です。

障害が頻発するベンダーから乗り換える場合、契約途中の解約には何を確認すべきですか

確認する先は契約書の契約期間と解約に関する条項です。
最低利用期間の定めがあるか、解約の申し入れから終了までにどれだけの期間が必要か、途中で終える場合に費用の定めがあるかを読みます。
金額や期間は契約ごとに異なるため、他社の条件を前提に見積もらないでください。
あわせて、自社のデータをどの形式で取り出せるか、契約終了後にデータがどう扱われるかの定めも確認が要ります。
移行の期間中に新旧を並行して使えるかどうかも、実務上は大きな分かれ目です。
並行できなければ、切り替えの当日に受注を止める時間帯が生まれるため、取引先への事前連絡が必要になります。

個人情報や決済情報の漏えいを伴う障害の場合、対応の優先順位はどう変わりますか

業務の復旧だけを追う進め方からは離れることになります。
セキュリティ事故に起因する障害は、報道された障害の類型の一つとして挙げられてきました¹。
実際の事例でも、ランサムウェア感染によるシステム障害から受注・出荷業務の停止に至っています²。
この種の事象では、復旧を急いで元の環境に戻すことが、原因の調査や被害範囲の特定を妨げる場合があります。
優先されるのは、事実関係の確認と、影響する範囲の把握、そして関係する取引先や本人への連絡の準備です。
監督官庁への報告が必要になるかどうかは制度上の定めによるため、自社だけで判断せず、ベンダーからの報告内容とあわせて、法務の担当や外部の専門家に確認してください。
なお、ベンダー側で起きた事故であっても、自社が取引先に対して負う説明の責任が自動的に消えるわけではありません。

1. 1　出典：独立行政法人情報処理推進機構（IPA）「情報システムの障害状況（アーカイブ）」（2010年〜2019年後半）
2. 2　出典：日経クロステック「アスクルが一部商品を試験的に出荷、障害中のシステム使わずファクスで受注」（2025年）
3. 3　出典：特定非営利活動法人ASP・SaaS・IoT クラウドコンソーシアム（ASPIC）「ASP・SaaSの安全・信頼性に係る情報開示認定制度」