B2B ECの機会損失とリスクをどう比較するか｜導入判断の材料と進め方

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

B2B EC-COLUMN

電話・FAX中心の受発注を続けると何を失うのか

取引先から「次回からはWebで発注したい」と言われた、あるいは同業の仕入先がEC受注を始めたと聞いて、電話とFAX中心の今の受発注のままでよいのか気になっている。
この段階で決めたいのは導入の可否そのものではなく、先送りした場合の損と、導入した場合の損をどう並べるかです。
企業間取引全体のEC化率は2024年時点で43.1%に達し、業種によっては8割を超えます¹。
機会損失の重さは自社の業種と取引先の意向という外側の事情で決まり、導入リスクの重さは自社で作るか対策を講じた提供形態を選ぶかという、自社で決められる選択で変わります。
全面移行のほかに、対象を絞って小さく始める道もあります。

企業間取引全体のEC化率の現在地

まず、自社が置かれている位置を数字で見ておきます。
企業間取引（BtoB）の市場のうち、電子商取引で行われた分が占める割合は、2024年時点で43.1%でした¹。
金額にすると514兆4069億円で、前年から10.6%増えています¹。
ここでいうEC化率とは、企業間の商取引金額のうち、コンピュータネットワークを介して受発注が行われた分の割合を指します。

この水準が意味するのは、企業間の受発注のうち半分弱はすでに電話やFAX、訪問といった経路を通っていない、ということです。
逆に言えば、金額ベースでは過半がまだそれ以外の方法で動いています。
つまり「もう全部ECになった」でも「一部の先進企業だけの話」でもなく、ちょうど半分に差し掛かった局面にいます。
この位置にいるときの機会損失は、取引を丸ごと失うといった分かりやすい形では現れにくく、発注のしやすさを比べられる場面で少しずつ差がつく形で出てきます。

たとえば、取引先の購買担当者が同じ資材を二社から仕入れているとします。
一方は画面で在庫と価格を見てその場で発注でき、もう一方は営業時間内に電話をかけ、注文書をFAXで送り、翌日に受注確認を待つ。
急ぎの追加注文が出たとき、どちらに先に声がかかるかは想像がつきます。
ただしこれは条件が揃った場合の話で、価格や納期、長年の関係で発注先が決まっている取引では、この差はほとんど効きません。
実際に機会損失が起きているかどうかは、このあと見る業種と取引先の事情で変わります。

電話・FAXでの受発注は今も珍しくない

EC化率の数字だけを見ると、自社の受発注体制が取り残されているように感じるかもしれません。
ただ、別の調査を並べると受け止め方は少し変わります。
経済産業省が帝国データバンクに委託し、2019年に公開された調査では、日本の中小企業の7～8割が受発注をファクスでやり取りしていると紹介されています³。

この割合は2019年時点のもので、EC化率の43.1%は2024年の集計です¹。
調査時点が5年以上離れているため、二つを引き算して「この間にどれだけ減った」と読むことはできません。
読み取れるのは、金額ベースでEC化が進む一方、旧来の手段も広く残るという両方の状態が併存しうる、ということです。
金額の大きい取引から順にEC化が進んだ場合、EC化率が上がっても、FAXを使っている企業の数そのものはさほど減らない、ということも起こり得ます。

ここから言えるのは、「まだFAXを使っているのは自社だけではない」ことと、「だから急がなくてよい」は別の話だ、という点です。
周りの平均に合わせることが目的ではなく、自社の取引先が今どちらを求めているかが判断の材料になります。
その平均が業種によってどれだけ違うのかを、次に見ていきます。

機会損失の大きさは業種・取引先によってどう変わるか

業種によるEC化率の差

43.1%は全業種を合計した数字です¹。
実際には業種ごとの差が大きく、たとえば食品分野のBtoB EC化率は81.3%に達しています¹。
この分野の市場規模は41兆5859億円で、前年から17.0%増えました¹。
全体平均と食品分野のあいだには、それだけの開きがあります。

食品分野のように8割を超える業種では、EC発注は例外ではなく前提です。
この環境で電話・FAX中心の受発注を続けている企業は、取引先から見ると「そこだけ別の手順が必要な仕入先」になります。
反対に、全体平均より低い業種では、EC発注を求める取引先はまだ少数で、導入しても使われないまま維持費だけがかかる可能性があります。
同じ「B2B ECを入れるべきか」という問いでも、業種によって答えは反対方向を向きます。

注意したいのは、業種別に確認できる数値は食品分野など一部にとどまり、全業種を並べて比較できる形にはなっていないことです¹。
自社の業種の数値がすぐに見つからない場合、平均を探し続けるより、取引先の実際の動きを見るほうが早い判断材料になります。

自社の業種平均を確認する視点

業種平均を知りたいのは、それ自体が目的だからではなく、「取引先がEC発注を求めてくる確率」を知りたいからです。
であれば、平均を探す代わりに直接数えることもできます。
主要な取引先を上位から二十社ほど挙げ、そのうち何社がすでに他の仕入先とECで発注しているか、何社から自社にもECでの発注を打診されたかを数える。
この二つの数が、判断を大きく動かします。

打診が一件も来ていない状態と、上位取引先の半数がすでにECで発注している状態とでは、先送りの意味がまったく違います。
前者では、先送りは選択肢として成り立ちます。
後者では、先送りは「いつか失うかもしれない」ではなく、すでに発注量の一部が他へ流れている可能性を示します。

もうひとつ見ておきたいのは、取引先の側で発注しているのが誰かという点です。
購買部門が集中購買を進めている相手ほど、仕入先ごとに発注手順が違うことを嫌います。
一方、現場ごとに発注している相手では、長くやり取りしている担当者が電話でのやり取りを好むこともあります。
同じ「取引先」でも、発注する人がどの立場かで、EC対応を求める強さは変わります。

B2B EC導入で新たに生じるリスクとは何か

被害が自社構築サイトに集中する理由

ここからは導入する側のリスクを見ます。
IPAのECサイト構築・運用セキュリティガイドラインは、ECサイトへの不正アクセス等による被害の大半を、セキュリティ対策の理解が不十分な中小企業の自社構築サイトが占めていると指摘しています²。
ここでいう自社構築サイトとは、パッケージ製品やスクラッチ開発で自社用に作り、自社または委託先で運用しているサイトのことです。
このガイドラインはBtoBとBtoCを区別していないため、B2B特有の傾向として読むことはできませんが、提供形態の違いがリスクの大きさに効くという構造は、企業間取引のサイトにも同じように当てはまります。

被害が自社構築側に偏る背景には、ECサイトが作って終わりの仕組みではないという事情があります。
土台となるOSやミドルウェアには公開後も新しい脆弱性が見つかり続け、その都度、更新を当てるかどうかを判断し、適用し、動作を確認する作業が発生します。
自社構築では、この継続作業の担い手を自社側で確保し続けなければなりません。
構築費用の見積もりには含まれていても、三年目、五年目に誰がその判断をするのかまで決めてから始める例は、多くありません。

企業間取引の場合、扱う情報の性質も考えておく必要があります。
取引先ごとの掛け率や個別単価、発注履歴、担当者の連絡先といった、外に出れば商談に直接響く情報が一か所に集まります。
消費者向けサイトのように件数が多いわけではなくても、一件あたりの重さが違います。

提供形態によるリスクの違い

この前提に立つと、「B2B ECを導入するとリスクが増えるか」という問いの立て方が、少しずれていることが見えてきます。
増えるかどうかではなく、増えた分を誰が引き受けるかが実際の分かれ目です。
自社構築であれば、更新の判断も、脆弱性診断の実施も、攻撃を検知する仕組みの運用も自社側に残ります。
事業者が提供するサービスを利用する形であれば、その多くは提供側の運用範囲に入ります。

選ぶ側が確認したいのは、事業者が何をどこまで担っているかです。
基盤となるプラットフォームがどの基準を満たしているか、OSやミドルウェアの更新を誰がいつ行うか、外部の専門機関による診断を受けているか、組織としての情報セキュリティ管理の認証を持っているか。
この四つは、契約前に質問すれば答えが返ってくるはずの項目で、答えが曖昧なまま進める理由はありません。

逆に言えば、これらに答えられない提供形態を選んだ場合、リスクの重さは自社構築とあまり変わりません。
導入するかどうかではなく、どの形で導入するかが、リスクの側の変数になります。

心配されやすい別の論点として、取引先が新しい発注画面を使いこなせるか、既存の商流や代理店との関係とぶつからないか、といった点もあります。
ただしこれらは取引先ごとの事情と自社の販売体制で決まるもので、どの企業にも当てはまる傾向として示せるものではありません。
どの相手から始めるかを選ぶ段階で、個別に確かめる論点として扱うのが現実的です。

機会損失とリスクのどちらを重く見るべきか

外的要因（業種・取引先）と内的要因（対策の有無）

ここまでで、比べるべき二つの量の性質が見えてきました。
機会損失の大きさは、自社の業種でどれだけECが使われているか、取引先がどれだけEC発注を求めているかという、自社では動かせない事情で決まります¹。
一方、導入リスクの大きさは、自社で作るか、対策を講じた提供形態を選ぶかという、自社で決められる選択で変わります²。
この整理は二つの資料を組み合わせた本記事の解釈であり、どの企業にも当てはまる法則として検証されたものではありません。

この違いが効いてくるのは、優先順位を決めるときです。
外的要因は待っても改善しません。
業種のEC化率が上がり、取引先の要望が強まる方向に動いているなら、先送りしている間に機会損失は積み上がります。
対して内的要因は、選び方を変えれば下げられます。
「リスクが怖いから見送る」という判断は、下げられる側のリスクを理由に、下げられない側の損失を放置していることになりかねません。

二つを並べたとき、最も損失を抱えやすいのは、業種平均が高く取引先の要望も強いのに、自社構築以外の選択肢を検討していない状態です。
動かなければ機会損失が増え、動けば対策の負担を自社で背負い込むことになります。
反対に、業種平均が低く取引先の要望もない企業が、対策済みの提供形態を前提に小さく試すのであれば、どちらの損失も限定されます。
どちらを重く見るかは、この二つの軸のどこに自社がいるかで決まります。

リスクを抑えながら機会損失を減らす導入の仕方

対策済みの提供形態を選ぶ

では、対策済みの提供形態とは具体的にどういうものか。
確認できた一例として、ASP型で提供されているB2B EC受発注システム「EC-Rider B2B Ⅱ」では、政府が求めるセキュリティ要求を満たすISMAP対応プラットフォームの採用、OS・ミドルウェアの常時最新化、ファイアウォール・WAF・IPS/IDS・アンチウイルスによる不正アクセス対策、第三者によるセキュリティ診断、ISMS認証という5つの項目で対策を講じていることが公開されています⁴。
ISMAPは政府がクラウドサービスのセキュリティ水準を評価する制度で、ISMSは組織としての情報セキュリティ管理体制に対する認証です。

前節で挙げた確認の観点と並べると、対応関係が見えます。
基盤の基準はISMAP対応、更新の担い手は提供側による常時最新化、外部診断は第三者によるセキュリティ診断、組織の認証はISMSがそれぞれ該当します⁴。
自社構築でこれらを揃えようとすれば、それぞれに費用と担当者の時間がかかり、しかも一度整えれば終わりにはなりません。
提供形態を選ぶという判断は、この継続作業をどちらが持つかを決める判断でもあります。
なお、ここで挙げた内容は同サービスの公開情報にもとづくもので、提供形態一般に共通する水準を示すものではありません。

ただし、提供形態を選べば安全が完結するわけではありません。
取引先ごとのアカウント管理、担当者が異動・退職した際のID削除、どの価格をどの相手まで見せるかといった運用は、利用する側に残ります。
事業者が担う範囲と自社に残る範囲の線引きは、契約前に書き出して確認しておく必要があります。

要件を絞った構成から始める

もうひとつの軸が、始める規模です。
同サービスの料金は、サーバー構成や月間転送量、月間リクエスト数、ストレージなどの要件によって変動する形で示されています⁵。
公開されているモデルケース（Webサーバー2台・DBサーバー1台・バッチサーバー1台、月間転送量200GB、月間リクエスト数100万などの条件）では、ベースエンジン利用料が月額170,000円～、ASP利用料金が月額260,000円とされています⁵。
これは特定の構成を前提にした例であり、要件が変われば金額も変わります。
市場の相場や他社の料金を表す数字ではありません。

料金が要件で変わるということは、裏を返せば、最初から全取引を載せる前提で構成を決める必要がない、ということです。
対象を一部の取引先と定番商品に絞れば、必要な転送量やリクエスト数も小さくなります。
実際にどの構成が要るかは取引量と同時アクセスの見込みによるため、見積もりの段階で自社の条件を出して確かめることになります。

段階的に始めるという進め方そのものは、公的機関が標準として示す手順を確認したものではなく、料金が要件に応じて変わる仕組みと、対策済みの提供形態を選べるという二点から導いた考え方です。
それでも、機会損失とリスクを同時に小さくしたい場合には、対象を絞って始めるのは現実的な選択肢になります。

絞って始めた場合に残るのが、二つの受発注方法が並走する期間の運用です。
EC経由の注文とFAX・電話の注文が同じ日に入り、在庫の引き当てや出荷指示をどこで一本化するかを決めていないと、現場の確認作業がかえって増えます。
最初の範囲をどこまでにするかは、この並走をどの部門がどれだけの期間受け持てるかで決まります。
この点だけは、提供形態を選んでも自社側に必ず残る作業です。

機会損失は業種と取引先という外側の事情で決まり、リスクは提供形態という自社の選択で変わります。
この二つを分けて見れば、「怖いから見送る」でも「周りが動いたから急ぐ」でもない判断ができます。
次に、状況ごとにどの進め方が合うのかを整理します。

業種のEC化率や取引先の意向をどれだけ集めても、自社の取引量でどの構成が必要になり、月額がいくらになるかは、条件を出さなければ分かりません。

対象にしたい取引先の数や商品点数、想定する月間の発注件数を伝えれば、その規模で必要な構成と、更新や診断がどこまで提供側の範囲に入るかを確認できます。無料相談で要件を整理する

外的要因と内的要因の組み合わせで見た四つの状態

業種のEC化率と取引先からの要望の強さ（自社では動かせない外的要因）と、自社構築か対策済みの提供形態かという選択（自社で決められる内的要因）の二軸で並べています。

• 業種のEC化率が高く取引先の要望も強い／対策済みの提供形態を検討している：機会損失を減らす動きを、リスクを上げずに進められる状態。範囲と時期の判断が中心になる。

• 業種のEC化率が高く取引先の要望も強い／自社構築しか検討していない：動かなければ機会損失が積み上がり、動けば更新や診断の負担を自社で抱える。二つの損失を同時に抱えやすい状態。

• 業種のEC化率が低く要望も出ていない／対策済みの提供形態を検討している：小さく試しても損失が限定される。急ぐ必要はないが、始める余地はある状態。

• 業種のEC化率が低く要望も出ていない／自社構築しか検討していない：先送りの機会損失は小さいが、必要になったときに負担の大きい選び方しか手元にない状態。

業種平均が低くても、主要取引先から具体的なEC発注の要望が出た時点で、上段の状態に切り替わります。

取引先の状況と対策の有無で分かれる三つの進め方

進め方	選ぶ状況	確認する基準
様子を見る（先送り）	自社の業種のEC化率が全体平均より低く、主要取引先から具体的な要望がまだない	業種別のEC化率と自社取引先の意向。乖離が小さいうちは急がない
対象を絞って部分導入する	一部の取引先・商品群から始め、自社構築を避けて対策済みの提供形態を小規模構成で使う	更新・診断・認証まで提供側が担うか。要件に応じて料金が変わるか
全面的に移行する	取引先の多くがすでにEC発注を求めている、または業種平均が高く出遅れの損失が大きい	業種のEC化率の高さと、取引先からの具体的な要望の有無

先送りが判断として成り立つ場合

急がなくてよいと言える条件

全体のEC化率が43.1%という数字だけを見て焦る必要はありません¹。
自社の業種で使われている割合が全体平均より低く、主要取引先からEC発注の具体的な要望がまだ来ていないなら、先送りは合理的な判断です。
この状態で導入しても、取引先が従来どおり電話とFAXで発注してくるため、二つの受発注経路を維持する手間だけが増えます。

ただし、条件は二つとも満たしている必要があります。
業種平均が低くても、上位の取引先から具体的な打診が来ているなら、それは業種の話ではなくその取引先との取引の話です。
平均は個社の要望を打ち消しません。

待っている間に決めておくこと

先送りを選ぶことは、何も決めないことと同じではありません。
要望が出たときに何を判断するのかを先に決めておけば、実際に打診が来てから慌てずに済みます。
具体的には、上位取引先の発注方法を定期的に確認する担当を決めること、そして提供形態を自社構築と外部サービスのどちらで検討するかの方針を、先に持っておくことです。

提供形態の方針を先に持っておく意味は、判断の速さだけではありません。
要望が出てから慌てて構築を始めると、更新や診断を誰が続けるのかを決めないまま稼働させることになりがちで、被害が自社構築サイトに集中しているという指摘が当てはまる状態に近づきます²。
先送りの期間は、この方針を落ち着いて決められる時間でもあります。

一部の取引先から、対策済みの形態で始める

どこを最初の対象にするか

部分導入で最初に決めるのは、機能ではなく対象です。
候補になりやすいのは、発注の頻度が高く、品目が定番化していて、担当者がWebでの発注に抵抗のない取引先です。
逆に、都度見積もりが必要な特注品や、納期調整のやり取りが前提の取引は、最初の対象から外したほうが混乱が少なくなります。
ここで絞った範囲が、そのまま必要なシステム構成の規模にも効いてきます。

提供形態と構成の決め方

部分導入でリスクを抑える鍵は、規模を小さくすることではなく、対策の担い手を自社の外に置けるかどうかです。
ASP型で提供されているサービスでは、ISMAP対応のプラットフォーム採用、OS・ミドルウェアの常時最新化、不正アクセス対策、第三者によるセキュリティ診断、ISMS認証といった項目が提供側で講じられている例があります⁴。
小さく始めても、これらが自社側に残る形であれば、負担は規模ほどには小さくなりません。

構成と料金は要件で変わります。
公開されているモデルケースでは、ベースエンジン利用料が月額170,000円～、ASP利用料金が月額260,000円と示されていますが、これはサーバー構成や月間転送量などの条件を固定した場合の例で、要件が変われば金額も変わります⁵。
対象を絞るのであれば、その範囲での発注件数や同時利用の見込みを出したうえで見積もりを取ることになります。

部分導入で残るのが、EC経由の注文と従来の注文が並走する期間の扱いです。
どちらの注文も最終的には同じ在庫から引き当て、同じ出荷指示につながります。
その合流点をどこに置き、誰が確認するのかを決めないまま始めると、確認の手間が二重になります。
対象を絞る判断は、この並走をどれだけの期間受け持てるかとセットで考えるものです。

出遅れの損失が大きいと判断できる場合

全面移行が妥当になる状況

食品分野のようにEC化率が81.3%に達している領域では、EC発注は取引の前提に近い位置にあります¹。
取引先の多くがすでにEC発注を求めている、あるいは業種平均が高く出遅れによる損失が大きいと見込める場合は、部分導入で様子を見る期間そのものが機会損失になります。
判断の材料は二つで、業種のEC化率の高さと、取引先からの具体的な要望の有無です。

要望の有無を見るときは、件数だけでなく、誰から来ているかを見ます。
発注量の多い上位数社から出ている要望と、取引量の小さい相手から出ている要望とでは、対応しなかった場合に失う金額が違います。
上位に集中しているなら、全面移行の判断は早まります。

移行時に判断が集中する点

全面移行を選んでも、リスクの側の論点は変わりません。
むしろ扱う取引先と情報が一度に増えるぶん、更新や診断を誰が続けるのかという問題は重くなります²。
移行の範囲を広げる判断と、自社で対策を抱えるかどうかの判断は、別々に決められます。
全面移行だから自社構築、という結び付け方をする必要はありません。

もうひとつ、全面移行では既存の受発注方法をいつ止めるかという判断が加わります。
すべての取引先が同じ日に切り替わることは考えにくく、実際には移行期間が発生します。
その間、どの取引先がどちらの経路で発注しているのかを把握できる状態を保つこと、そして最後まで移れない取引先への対応をどうするかを、開始前に決めておく必要があります。
この判断を先送りすると、全面移行のつもりが恒久的な二重運用になります。

要点の整理

軸	基準
機会損失の大きさ	自社の業種のEC化率と、主要取引先からEC発注の打診が来ている件数
リスクの重さ	自社構築か、更新・診断・認証まで提供側が担う形態か
始める規模	全取引を前提にせず、対象を絞った要件で構成と料金を見積もれるか
先送りの可否	業種平均が全体平均より低く、かつ上位取引先から具体的な要望が出ていないか
残る運用	EC経由と電話・FAXの注文が並走する期間、どこで一本化し誰が確認するか

部分導入で難しいのは機能の選定より、どこまでを最初の範囲にし、並走期間の注文をどこで一本化するかという線引きの部分です。 現在の受発注の流れと、最初に載せたい取引先の条件を持ち込めば、その範囲で要件を絞った場合の構成と、自社側に残る運用がどこまでかを整理できます。

よくある質問

取引先ごとに一部だけEC受発注にすることはできるか

できます。
実務上は、発注頻度が高く品目が定番化している取引先から始め、都度見積もりが必要な取引は従来の方法に残す形が現実的です。
ただし、EC経由の注文と電話・FAXの注文が並走する期間が必ず生じます。
在庫の引き当てと出荷指示をどこで一本化し、誰が確認するのかを先に決めておかないと、確認作業が二重になります。
なお、段階的に始めるという進め方自体は公的機関が示す標準手順ではなく、料金が要件で変わる仕組みと提供形態を選べることから導いた考え方です。

自社構築のECサイトと外部の提供サービスでは、セキュリティリスクの性質はどう違うか

違うのはリスクの有無ではなく、対策を誰が続けるかです。
IPAのガイドラインは、ECサイトへの不正アクセス等による被害の大半を、セキュリティ対策の理解が不十分な中小企業の自社構築サイトが占めていると指摘しています²。
自社構築ではOS・ミドルウェアの更新、脆弱性診断、攻撃の検知といった継続作業が自社側に残ります。
提供サービスでは、ISMAP対応の基盤、常時最新化、第三者診断、ISMS認証といった項目を提供側で講じている例があり⁴、この範囲は自社から外れます。
一方、アカウント管理や価格の公開範囲といった運用は、どちらの形でも利用側に残ります。
なおこのガイドラインはBtoBとBtoCを区別していないため、企業間取引に限った傾向を示すものではありません。

自社の業種のEC化率が低い場合でも導入を急ぐべき場合はあるか

あります。
業種平均は「取引先がEC発注を求めてくる確率」の代わりに見る目安にすぎないため、実際の要望が先に来た場合は平均より要望が優先します。
特に発注量の多い上位数社から打診が出ているなら、対応しない間に失う金額は業種平均とは無関係に生じます。
逆に、業種平均が低く、上位取引先からの打診もない状態であれば、急ぐ理由はありません。

B2B ECの月額料金は取引規模や要件によってどのくらい変わるか

金額の幅を一般的な相場として示すことはできませんが、料金が何によって動くかは確認できます。
ASP型で提供されているEC-Rider B2B Ⅱの場合、サーバー構成、月間転送量、月間リクエスト数、ストレージなどの要件によって料金が変動する形で示されています⁵。
公開されているモデルケース（Webサーバー2台・DBサーバー1台・バッチサーバー1台、月間転送量200GB、月間リクエスト数100万などの条件）では、ベースエンジン利用料が月額170,000円～、ASP利用料金が月額260,000円です⁵。
これは特定の構成を前提にした一例で、要件が変われば金額も変わります。
自社の金額を知るには、対象とする取引先数や発注件数の見込みを出して見積もりを取る必要があります。

1. 1　出典：経済産業省「令和6年度電子商取引に関する市場調査 報告書」（2025年）
2. 2　出典：IPA（独立行政法人情報処理推進機構）「ECサイト構築・運用セキュリティガイドライン」（2023年）
3. 3　出典：日経クロステック「中小企業の8割が「ファクスで受発注」の現実、DX時代に日本の競争力が失われる」（2019年）
4. 4　出典：株式会社フライトソリューションズ「EC-Rider B2B Ⅱ 機能紹介（セキュリティ）」（2026年）
5. 5　出典：株式会社フライトソリューションズ「EC-Rider B2B Ⅱ 料金プラン・費用」（2026年）