BtoB通販システムの稼働率と障害対応｜止まったときの影響から補償・代替策・乗り換え判断まで

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

B2B EC-COLUMN

受発注が止まったとき、まず何を確認すべきか

取引先から「発注画面が開かない」と連絡が入り、復旧の見通しも分からないまま受注が止まっている。
あるいは、ベンダーから届いた稼働率の実績を見て、この水準のまま使い続けてよいのかと迷っている。
こうした場面でまず見極めたいのは、稼働率の数字の高さではなく、その数字が「保証」として約束されたものか、「目標」として掲げられたものかという違いです。
目標であれば下回っても補償が定められていないことがあり、計画停止が計算から外れている場合もあります。
契約書と公開資料でこの前提を確かめたうえで、止まっても注文を受けられる代替手段を用意し、実際の障害履歴とベンダーの対応を突き合わせて、継続か乗り換えかを判断していきます。

取引先から「発注画面が開かない」と電話が入ったとき、最初の数分で知りたいのは原因ではありません。
止まっているのが自社側なのか、サービス側なのかという切り分けです。
社内の別の端末からも、社外の回線からも同じ症状が出るのであれば、自社のネットワークや端末に原因がある可能性は下がります。
そのうえでベンダーの障害情報ページやメール通知を確認し、事象が認識されているか、復旧の見込みが示されているかを見ます。
ここで復旧見込みが出ていれば待つ判断もできますが、見込みが示されないまま時間が過ぎるときほど、次の確認が効いてきます。

次に見ておきたいのは、止まっているのが注文の入口だけなのか、その先まで及んでいるのかという範囲です。
受発注システムは、注文の受付だけでなく、在庫の引き当て、出荷指示、納品書や請求データの作成までが一続きになっていることがあります。
入口だけが止まっているのなら、すでに受け付けた注文の出荷作業は進められます。
一方、出荷指示まで止まっているのであれば、当日出荷の締め時間に間に合うのかという、別の判断をその場で下さなければなりません。
どこまでが動いていてどこから止まっているのかを先に押さえておくと、取引先への説明も「使えません」ではなく「今日の分の出荷は動いています」と具体的に伝えられます。

もう一つ、後から効いてくるのが、止まっている間に取引先が送ろうとした注文の行方です。
送信できずにエラーとして跳ね返っているのか、受け付けられたうえで処理待ちとして滞留しているのかによって、復旧後の作業がまったく変わります。
滞留している場合は、復旧と同時にまとめて流れてくることがあり、その間に電話やメールで先に受けた分と重複していないかを確認する必要が出てきます。
この挙動はサービスの仕様によって違うため、障害の最中に調べるのではなく、平時にベンダーへ確認しておきたい点です。

取引先への連絡は、気づいた順ではなく、締め時間が近い先から手を付けるほうが実務に合います。
当日出荷の締めが迫っている取引先にとっては、復旧するかどうかより、今日中に発注を通せるかどうかが問題だからです。
逆に、翌日以降の納品で足りる取引先には、復旧後にまとめて案内しても大きな支障は出にくくなります。
この優先順位を障害の最中に考え始めると、どうしても後手に回ります。

受発注が長時間止まる事態は、現実に起きています。
インフォマートは、同社の「BtoBプラットフォーム」の全サービスで、11時50分から19時56分までアクセスできない事象が発生したことを2024年に公表しました²。
時間にすれば約8時間、営業時間のほぼ全域にあたります。
同社はこの事案について、総務省へ重大な事故としての第一報を行ったことも併せて公表しています²。
これは公表された一社の一事案であって、BtoBの受発注システム全般で同じ規模の停止が起きるという意味ではありません。
ただ、「半日使えない」が想定外の出来事ではないことは、この一件だけでも分かります。

目の前の障害がひとまず収まると、次に出てくるのが「このシステムを使い続けてよいのか」という問いです。
その入口として、多くの担当者はまず契約書や公開資料にある稼働率の数字を探します。
ところが、そこに書かれた数字は、そのままでは継続の可否を判断する材料になりません。

稼働率の数字は「保証」か「目標」かを見分ける

稼働率の計算式と計画停止の扱い

稼働率について書かれた資料には、SLAとSLOという二つの言葉が出てきます。
SLAはサービス品質保証と訳され、達成できなかった場合の対応まで含めて約束する取り決めを指します。
SLOはサービスレベル目標で、事業者が目指す水準を示すものです。
名前が似ているうえ、どちらも「99.9%」のように同じ形の数字で書かれるため、読む側からは区別がつきにくくなっています。
そして、この区別を飛ばしたまま数字の大小だけを比べてしまうと、後で補償の話になったときに前提が食い違います。

実際の記載を見てみます。
インフォマートが公開している「BtoBプラットフォーム」のサービスレベル目標では、月間稼働率99.99%以上を目標として掲げています¹。
計算式も示されており、当月の稼働時間から障害時間を差し引き、それを当月の稼働時間で割るという形です¹。
そして、事前に通知したうえで行う計画停止の時間帯は、この目標の適用範囲外とされています¹。
なお、これは同社の現行の公開ページにある記載であり、計算式や適用範囲が他のサービスでも同じとは限りません。

この三つの記載を並べると、数字の性格が見えてきます。
計画停止が適用範囲から外れるということは、メンテナンスで使えなかった時間は稼働率の数字を下げないということです。
つまり掲げられた水準は、「使えなかった時間の割合」そのものではなく、「予告なく止まった時間の割合」に近い意味を持ちます。
深夜帯のメンテナンスであれば実務への影響は小さいかもしれませんが、自社の締め処理や基幹システムへのデータ取り込みを夜間に回している場合、計画停止の時間帯こそが業務の山場と重なることもあります。
数字を見るときは、パーセンテージと一緒に、何が障害時間として数えられ、何が数えられないのかまで確かめておきたいところです。

だからこそ、計画停止がいつ、どのように知らされるかは確認しておく価値があります。
先のガイドラインでは、サーバーメンテナンス等の計画停止は事前に通知されるとされています¹。
ただし何日前に通知されるかは、契約書や利用規約の側で定められていることがあり、サービスによっても異なります。
あわせて見ておきたいのが、その通知が社内の誰に届くかです。
ベンダーの登録連絡先が異動前の担当者のままだったり、情報システム部門で止まって受発注の現場に伝わらなかったりすると、事前通知があっても当日は「急に止まった」のと変わりません。

保証か目標かを見分けるには、数字の大きさではなく、その数字が置かれている文書と言い回しを見ます。
「保証します」と書かれているのか、「目標とします」「努めます」と書かれているのか。
公開ページに目標として掲げられていても、契約書の別紙に保証としての条項が置かれている場合もあれば、その逆もあります。
最終的に自社を縛るのは、署名した契約書と、そこから参照されている規約の本文です。
実績通知のメールや営業資料の数字は、条文を探すための手掛かりとして扱うのが安全です。

稼働率が基準を下回っても補償されるとは限らない

補償条項の有無を契約書で確認する視点

稼働率が目標として示されている場合に見落としやすいのが、下回ったときに何が起きるのかという点です。
先に挙げたインフォマートのサービスレベル目標には、これはサービス品質として保証するものではない旨が明記されています¹。
同じページに、目標を下回った場合の返金や減額といった補償の条項は見当たりません¹。
つまり、掲げられた水準に届かなかったとしても、金銭的な補償が当然に発生するとは限らないということです。
「99.99%を目標としています」という記載を見て、下回れば何か戻ってくるはずだと考えていると、いざというときに根拠がないことに気づきます。

これは同社の現行の公開情報について言えることであって、すべての受発注システムが同じ枠組みだという話ではありません。
契約上の保証として稼働率を定め、未達の場合に月額の一部を返金したり、利用期間を延長したりする取り決めを置いている事業者もあります。
一方で、どの水準ならいくら返金されるのかという業界共通の相場と呼べるものは、今回確認できた公的・業界の資料の中には見当たりませんでした。
ですから、他社の例から自社の補償を推し量るのではなく、自社の契約書そのものを読むしかありません。

契約書を開いたときに確かめる場所は、およそ次の五つに絞れます。
一つは、稼働率が保証として書かれているか、目標として書かれているか。
二つ目は、どの期間で測るのか、つまり月間の稼働率なのか年間の稼働率なのか。
三つ目は、何が障害時間から除かれるのか、計画停止のほかに通信回線の障害や不可抗力、利用者側の設定に起因する不具合などが除外されていないか。
四つ目は、未達のときの対応が金銭なのか、利用期間の延長なのか、それとも解約の権利なのか。
五つ目は、その対応を受けるために利用者からの申請が必要か、申請に期限があるかです。

五つ目は特に見落とされがちです。
補償が申請制になっている場合、ベンダーから自動的に処理されるわけではなく、利用者が停止の事実を示して申し出る必要があります。
そのときに手元にあると強いのが、自社で取った記録です。
いつから画面が開かなくなり、いつ復旧を確認したか、その間に取引先から何件の問い合わせがあったかを、障害の最中にメモしておくだけでも、後から話が早くなります。
ベンダーの公表する復旧時刻と、自社の現場で実際に使えるようになった時刻がずれることもあるため、自分たちの時計で記録を残す意味があります。

五つの観点まで確認すると、補償条項の読み方も少し変わってきます。
返金や減額が定められていたとしても、その金額は月額利用料を基準に算定されることがあり、停止していた時間に受けられなかった注文や、取引先への連絡に費やした手間を埋め合わせる性質のものとは限りません。
補償条項は、損害を回収する手段としてよりも、そのベンダーが品質についてどこまで言い切る構えなのかを示す材料として読むほうが実態に合います。
だとすれば、補償の有無を確かめたうえで次に考えるべきなのは、止まったときに自社がどう受け止めるかのほうです。

稼働率何%なら、どれくらい止まってよいのか

稼働率と年間停止時間の対応

そもそも99.9%と99.99%では、止まってよい時間にどれだけの差があるのでしょうか。
数学的に換算すると、稼働率99%は年間で約3.65日、99.9%で約8.76時間、99.99%で約52.3分の停止に相当します³。
これは割合を時間に置き換えた目安であり、特定の受発注システムで実際に計測された停止時間ではありません。
それでも、桁が一つ増えるごとに許される停止時間が一桁ずつ短くなるという関係は、数字の意味をつかむ助けになります。
99%と99.9%は見た目にはほとんど同じですが、年に三日半止まるのか、九時間弱で収まるのかという違いがあるわけです。

この換算を自社に当てはめるとき、注意したいことが二つあります。
一つは、同じ年間52.3分でも、一分の瞬断が五十回起きるのと、五十分の停止が一度起きるのとでは、業務への響き方がまったく違うという点です。
瞬断であれば画面を開き直せば済むこともありますが、営業時間中にまとまった時間止まれば、その日の締めに間に合うかという話になります。
稼働率の数字は停止時間の合計しか表さないため、一回あたりどれだけ長く止まりうるのかは、別に聞いて確かめる必要があります。

もう一つは、測定の期間です。
先に見たように月間の稼働率を掲げている例もあれば、年間で示される例もあり、同じ一度の停止でも、どの期間で割るかによって数字の見え方は変わります。
年間で均せば小さく見える停止も、その月だけを取り出せば大きく響きます。
契約書や実績通知の稼働率を読むときは、パーセンテージと一緒に、それが何か月を単位にした数字なのかを確かめておくと、通知を受け取ったときに慌てずに済みます。

そのうえで考えておきたいのが、自社にとっての「止まってよい時間」は一律ではない、ということです。
取引先からの発注が朝一番に集中する商材であれば、始業直後の一時間の停止は、夜間の三時間よりはるかに痛いはずです。
月末に注文が寄る取引であれば、月末の停止は他の時期と同じ長さでも意味が違います。
稼働率のパーセンテージは、こうした時間帯や時期の重みを表せません。
ベンダーと話すときも、実績通知を評価するときも、「年に何分まで許容できるか」より先に「いつ止まってほしくないか」を言葉にしておくほうが、判断の軸がぶれません。

そして、どれだけ高い水準を求めても、止まる可能性そのものを消すことはできません。
ここからは、止まることを織り込んだうえで受発注を続ける方法を考えます。

障害発生時に受発注を止めないための備え

障害への備えを考えるとき、出発点になる見方があります。
「システムは止まってはならない」ではなく「システムは止まることがあるものだ」という発想で考えるほうが現実的だ、という考え方です³。
実際に約8時間にわたって全サービスが利用できなくなった事案が公表されていることを踏まえると²、この前提に立って業務側の手を打っておく意味はあります。
稼働率を上げるのはベンダー側の仕事ですが、止まった日に取引先の注文を受け続けられるかどうかは、自社の段取りで変わる部分です。

最初に決めておきたいのは、システムが使えない間、取引先からの注文をどこで受けるかです。
電話、FAX、メール、所定の書式の注文書など、手段そのものは普段から社内にあるものばかりです。
難しいのは、障害の最中にその切り替えを周知することのほうです。
取引先の担当者名や連絡先が受発注システムの中だけにある場合、止まっている間はその一覧を開けません。
連絡先の控えをシステムの外に持っておくこと、そして「止まったときはこちらへ」という案内をあらかじめ取引先に渡しておくことが、当日の手戻りを減らします。

次に決めておきたいのが、いつ代替運用に切り替えるかと、それを誰が決めるかです。
復旧見込みが示されないまま三十分待つのか、二時間待つのか、判断が人によって変わると、ある取引先には電話受注を案内し、別の取引先には復旧をお待ちくださいと伝える、といった食い違いが起きます。
停止から何分で切り替えるかを目安として決め、判断する担当者と不在時の代理を決めておけば、少なくとも案内のばらつきは防げます。
目安の時間は、締め時間の何分前かという形で置くと、現場でも判断しやすくなります。

見落とされやすいのが、復旧した後の作業です。
代替手段で受けた注文はシステムに入っていないため、復旧後に入力し直すことになります。
このとき、取引先が障害中に送信を試みた注文が滞留していて、復旧と同時に流れ込んでくると、同じ注文が二重に入る可能性があります。
代替経路で受けた注文には受付の控えを残し、受信時刻と取引先名、品目が分かる形にしておいて、復旧後にシステム側の受信一覧と突き合わせる手順を決めておくと、入力の前に重複を見つけられます。
この突き合わせを誰がいつ行うかまで決めておかないと、通常業務が戻った忙しさの中で後回しになりがちです。

在庫や出荷の扱いも、事前に方針を決めておける部分です。
システムが見えない間は在庫の引き当て状況が分からないため、取引先から納期を聞かれても即答できません。
その場で確約するのか、いったん保留にして復旧後に折り返すのかを決めておけば、担当者ごとに回答が変わる事態は避けられます。
取引先へ送る一次連絡の文面も、雛形を用意しておくと、書き出しに時間を取られずに済みます。
文面には、何が使えないのか、代わりにどこで受けるのか、いつ次の連絡をするのかを入れておくと、問い合わせの電話そのものを減らせます。

これらの備えをしても、停止による影響がなくなるわけではありません。
減らせるのは、障害の最中に手順を考える時間と、復旧後の突き合わせで生じる混乱です。
どこまで手間をかけるかは、半日止まったときに動かせなくなる受注の大きさと、取引先から求められる応答の速さに応じて決まります。
取引先が数社であれば電話で足りることもありますし、数百社へ一斉に知らせる必要があるなら、連絡の手段そのものを受発注システムの外に用意しておくことになります。

稼働率実績と契約条件から継続・乗り換えを判断する

確認すべき4つの視点

ここまでの内容を、継続か乗り換えかの判断に使える形へ並べ直します。
見るのは四つで、実際に障害が起きたときのベンダーの振る舞い、稼働率が保証か目標か、未達のときの補償、そして自社側の備えで受け止められる範囲です。
この四つは独立した項目ではなく、前の答えによって次の重みが変わります。
補償がない契約でも、自社の代替運用が回るなら継続はありえますし、補償が手厚くても連絡が来ないベンダーなら現場は疲れます。

一つ目の、過去に何が起きたかは、ベンダーの公表情報から確認できます。
ニュースリリースや障害情報のページに、発生と復旧の時刻、影響範囲が掲載されているかを見ます。
先に挙げた事案では、事業者自身が自社サイトで事象を公表し、総務省への第一報についても記載していました²。
一方で、公表文に何がどこまで書かれるかは事業者や事案によって異なります。
実際、この公表では発生と復旧の時刻や報告した事実は示されていますが、原因の詳細や再発防止策の具体的な内容までは記載されていません²。
だからこそ、利用者としては公表を待つだけでなく、原因と再発防止策の説明を自分たちから求めることになります。

検索しても障害情報が出てこない場合、それは障害がなかったことを意味するとは限りません。
公表の基準は事業者ごとに違い、影響を受けた利用者にだけ個別に通知し、サイトには載せない運用もありえます。
導入を検討している段階であれば、直近一年の停止回数、一回あたりの最長停止時間、障害時の通知手段と第一報までの目安を、提案を受ける中で質問しておくと比較の材料になります。
すぐに答えられるか、確認して折り返すと言うか、答えを濁すか。
その反応自体も、止まったときにどう扱われるかを想像する手掛かりになります。

二つ目と三つ目、稼働率が保証か目標か、補償条項があるかは、すでに見てきたとおり契約書の中でしか確かめられません。
ここで大事なのは、この二つを乗り換えの決め手にしないことです。
補償が手厚い契約へ移っても、止まる時間が短くなるわけではありません。
逆に、目標としてしか書かれていなくても、障害時の連絡が速く、復旧の見通しが随時示されるのであれば、現場の困りごとは小さくなります。
条文は、ベンダーの姿勢を測る物差しの一つとして使い、実際の振る舞いと並べて見るのが現実的です。

四つ目の自社の備えは、乗り換えの判断そのものを左右します。
乗り換えには、商品マスタや取引先マスタ、取引先ごとの価格条件の移し替えに加えて、取引先への操作の再周知が伴います。
取引先の担当者に新しい画面を覚えてもらう手間は、こちらの都合では短縮できません。
そして、移った先でも止まることはあるという前提は変わりません³。
つまり、乗り換えで選び直せるのは「止まらないこと」ではなく、止まったときの連絡や復旧の進め方、そして自社の代替運用と噛み合うかどうかです。

判断の順番としては、まず代替運用の手順を整え、そのうえで直近の障害でベンダーがどう動いたかを記録に残すところから始めるのが現実的です。
第一報までにどれだけかかったか、経過報告はどの程度の間隔で届いたか、復旧後に説明があったか。
一度の障害だけでは偶発なのか体制の問題なのかは分かりませんが、二度目が起きたときに同じ項目で記録を取れば、比べられる材料になります。
あわせて契約の更新時期と、解約の申し出に必要な予告期間を確認しておけば、判断がついたときにすぐ動ける状態を保てます。
稼働率の数字だけを眺めていても、この判断は進みません。

稼働率の条文の読み方までは整理できても、自社の受発注のどこが止まると業務が回らなくなるのかは、契約書ではなく日々の運用の中にあります。社内だけで棚卸ししようとすると、普段は意識していない受け渡しが抜けがちな部分です。

受注から出荷指示までの流れを一緒にたどり、止まったときに手作業で受けられる範囲と、復旧後に入力し直す量がどれくらいになるかを見積もるところまでご相談いただけます。無料相談で要件を整理する

要点の整理

軸	基準
稼働率の性格	契約書に「保証」と書かれているか、「目標」と書かれているか
計算の前提	計画停止が障害時間から除かれるか、測定期間は月間か年間か
未達時の扱い	返金・減額・解約権の有無と、申請の要否や期限
障害の実績	公表の有無、一回あたりの最長停止時間、第一報までの速さと経過報告
自社の備え	代替受注経路の事前周知と、復旧後に重複を見つける突き合わせ手順

継続か乗り換えかは、稼働率の数字だけでは決まらず、移行にかかる手間と取引先への影響を並べて初めて比べられます。 現在の商品データや取引先ごとの価格条件の持ち方、取引先の使い方を伺ったうえで、移行で何を作り直すことになり、今の運用のどこを残せるのかを整理してお伝えします。

よくある質問

稼働率のSLAとSLOはどう違うのですか

SLAはサービス品質保証、SLOはサービスレベル目標を指します。
同じ99.9%のような数字でも、SLAは達成できなかった場合の対応まで含めて約束する取り決め、SLOは事業者が目指す水準の表明という違いがあります。
実際、インフォマートが公開しているサービスレベル目標には、これはサービス品質として保証するものではない旨が明記されており、未達時の返金や減額の条項は置かれていません¹。
判断の材料になるのは呼び名ではなく条文の書きぶりですので、自社の契約書で「保証します」なのか「目標とします」なのかを確かめてください。

障害が「総務省への重大な事故」として報告されるのはどのような場合ですか

先に触れた事案では、全サービスが約8時間にわたり利用できなくなった件について、事業者が総務省へ重大な事故としての第一報を行ったと公表しています²。
どの障害が報告の対象になるかは、提供しているサービスの種類や影響の規模に応じて定められていますが、本記事で確認した資料の範囲では個別の要件までは示されていないため、ここで基準を断定することはできません。
利用者の立場としては、報告対象に当たるかどうかを見極めるより、その事業者が事象と対応をどこまで公表しているかを判断材料にするほうが実用的です。

計画停止（メンテナンス）の事前通知はどのくらい前に来るのが一般的ですか

一般的な通知日数を示す公的な資料は、今回確認できた範囲では見当たりませんでした。
インフォマートのサービスレベル目標では、サーバーメンテナンス等の計画停止は事前に通知されるとされていますが¹、何日前かは契約書や利用規約の定めによります。
日数と同じくらい確かめておきたいのが、通知がどの手段で社内の誰に届くかです。
管理者のアドレス宛にだけ届く設定になっていると、受発注の現場に伝わらないまま当日を迎えることがあります。

乗り換えを検討する際、現行ベンダーの過去の障害情報はどこで確認できますか

まずはベンダーのニュースリリースや障害情報のページを見ます。
先の事案では、事業者が自社サイトで発生と復旧の時刻を含めて公表していました²。
ただし公表の基準は事業者ごとに異なり、個別通知のみで公開しない運用もあるため、掲載がないことを障害がなかった証拠とは扱えません。
導入検討中であれば、直近一年の停止回数、一回あたりの最長停止時間、障害時の第一報までの目安を提案の場で質問し、回答の具体性まで含めて比べると差が見えます。

障害の最中に取引先が送った注文は、復旧後どうなりますか

送信できずにエラーとなるのか、受け付けたうえで処理待ちとして滞留するのかは、サービスの仕様によって異なります。
滞留する場合は復旧と同時にまとめて処理され、電話やメールで先に受けた分と重複する可能性があります。
仕様の確認は障害の最中では間に合わないので、平時のうちに、送信中だった注文がどう扱われるか、受信の記録を利用者側の画面で確認できるかをベンダーに聞いておくと、復旧後の突き合わせが早く終わります。

1. 1　出典：株式会社インフォマート「BtoBプラットフォーム サービスレベル目標（SLO）ガイドライン」（公表年の記載なし）
2. 2　出典：株式会社インフォマート「システム障害についてのお知らせ」（2024年）
3. 3　出典：日経BP（日経クロステック Active）「稼働率99.9999%のコストは100倍以上、発注時に「システム停止」をどう考えるか？」（公表年の記載なし）