Web-EDIの多画面問題を集約するには？方法の選び方と費用の考え方

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

B2B EC-COLUMN

Web-EDIの多画面問題とは何か、この記事でわかること

取引先が増えるたびに新しいWeb-EDIのIDが配られ、朝は画面を順番に開いて発注を拾い、自社のシステムへ入れ直す。
その積み重ねに限界を感じて、多画面をまとめられないかと調べ始めた方に向けた記事です。
ここでは、集約でどの程度の効果が見込めるのか、費用は何で決まるのか、費用以外に何を比べるべきかを順に整理します。
効果の手掛かりになるのは、EDI標準化の実証事業で報告された受発注業務時間の平均削減率51.4%という値ですが¹、これは規格を共通化した施策の結果であり、集約ツールの効果を保証する数字ではありません。
費用は基盤の利用料に合わせ込みや拡張が積み上がる形で決まり、対応できるEDI規格の業務範囲も方式によって差があります。
取引先数、仕様の差、社内の対応力を踏まえ、費用と対応範囲の両方から選ぶことが要点です。

取引先ごとに異なるWeb-EDI画面へのログイン・二重入力という悩み

Web-EDIは、取引先が用意したWebサイトに担当者がブラウザでログインし、発注や出荷のデータを画面上で確認したり入力したりする仕組みです。
専用の通信回線や自社側のソフトを持たなくても取引を始められるため、導入のハードルは低く済みます。
その手軽さの裏側で起きるのが、取引先が増えるたびに見るべき画面も増えていくという問題です。

負担の中身は、ログインの回数だけではありません。
ある取引先の画面では発注データをCSVでダウンロードできるのに、別の取引先では画面の表示を目で追いながら自社の基幹システムへ入力し直す、という具合に、同じ「発注を受ける」という仕事が取引先ごとに別々の作業へ分かれていきます。
締め時刻もそろっていないため、担当者は「何時までにどの画面を開くか」という時間割を頭の中に持つことになります。
この時間割は手順書に落としにくく、担当者が休んだ日に誰も代われないという形で表面化します。

取引先が増えたときに負担が単純な足し算にならないのも、この構造から説明できます。
画面が一つ増えると、巡回先が一つ増えるだけでなく、締め時刻の組み合わせが増え、転記のルールが増え、数量や納期の食い違いが起きたときに「どの画面の話か」を特定する手間まで増えます。
多画面問題を集約で解きたいという動機は、たいていこの、増え方が読めない負担にあります。

ここで一つ、言葉の整理をしておきます。
「集約」と呼ばれるものには、取引先の画面をまとめて一つの入り口から扱えるようにすることと、取引先とのデータのやり取りそのものを規格で統一してしまうことの二通りがあります。
前者は取引先側の仕組みを変えずに自社側で束ねる考え方、後者は取引先も同じ規格に合わせる考え方で、必要な調整の相手も費用のかかり方も変わります。
この違いは、後で効果や費用を読むときにそのまま効いてきます。

この記事で答える範囲と答えない範囲

この記事で答えるのは、次の三点です。
集約の効果をどの程度と見積もればよいか、費用がどの要素で動くのか、そして費用以外に比べるべき条件は何か。
いずれも、公的機関と業界団体の資料、および当社が公開している料金情報という、出所のはっきりした材料に沿って説明します。

一方で、この記事では「集約の相場は月額いくら」という形の金額は示しません。
公開されている価格は、対象とする取引先の数、業務の範囲、サーバーの構成といった前提と一体で決まっているため、条件を外して平均値のように扱うと、自社の見積もりを読み違える原因になるからです。
金額そのものより、金額が何で動くかの構造をつかむほうが、見積書を受け取ったときの判断に直結します。

集約の具体的な進め方にも、データ変換や連携を担うサービスを挟む形、画面操作を自動化する形、取引先がAPIを公開していればそれを使う形など、複数の道筋があります。
ただし、それぞれの費用体系と対応規格を同じ条件で並べられる独立した資料は限られます。
そのため本記事では方式ごとの金額比較は行わず、「方式によって対応できる範囲と費用の組み立てが違うので、個別に条件をそろえて確かめる必要がある」という論点として扱います。
比較のための軸は、後半で具体的に示します。

集約でどの程度の効果が見込めるか

EDI標準化の実証事業にみる業務時間削減の参考値

効果を数字で確かめたいときに、まず手掛かりになるのが公的な実証事業の結果です。
中小企業庁は、企業間のデータ連携を標準化する「中小企業共通EDI」の取り組みとして、2016年度に12のプロジェクトを選定し、導入効果を測定する実証事業を行いました¹。
その結果として、中小企業のほうが業務時間の削減率が高く、平均して51.4%の削減効果が得られたと報告されています¹。

この数字が示しているのは、受発注にかかる業務時間が半分程度になったという事実そのものです。
何が減ったのかを工程に戻して考えると、人が画面やFAXを介して行っていた入力、転記、確認の作業が、データがそのまま流れることで不要になったという読み方ができます。
多画面問題に悩む担当者の実感、つまり「同じ数字を二度打っている」という感覚と重なる部分が、この削減率の中身にあたります。

規模の小さい企業ほど削減率が高かったという結果も、目を引きます。
その理由を本記事で断定することはできませんが、手作業の比率が高い工程ほど機械に置き換えられる余地が大きい、という見方は、自社の効果を見積もるうえで参考になります。
裏を返せば、すでに一部の取引先とはデータ連携ができていて、残りが手作業という状態なら、削減の幅は手作業が残っている部分の大きさで決まります。

参考値として扱う際の注意点（対象・手法の違い）

ここで重要な注意があります。
51.4%という値は、EDIの規格を共通化するという施策によって得られた効果です¹。
取引先ごとのWeb-EDI画面をそのままにして、自社側のツールで束ねる場合とは、対象も手法も異なります。
この記事で紹介する集約ツールを入れれば同じ削減率になる、という意味には読めません。

違いを具体的に見ると分かりやすくなります。
規格の共通化は、取引先側も同じ形式でデータを出し入れする前提に立つため、そろえる調整の負担は取引先との交渉側にかかり、そのぶん自社に残る差分は小さくなります。
一方、自社側で束ねる集約は、取引先の画面も仕様もそのままで進められる代わりに、取引先ごとの違いを吸収する仕掛けが自社側に残ります。
どちらが効率的かは一概には言えず、取引先の数と、相手がどこまで仕様の変更に応じられるかで変わります。

では自社の効果はどう見積もればよいのか。
外部の削減率を借りるのではなく、いま行っている作業を工程に分けて、それぞれがどう変わるかを考えるほうが確かです。
受発注の工程は、ログインと画面の巡回、データの取り出し、基幹システムへの転記、内容の照合、差異が出たときの取引先への問い合わせ、という五つに分けられます。
集約で大きく減るのは前の三つで、照合と問い合わせは形を変えて残ることが多い部分です。

この分け方をしておくと、導入後の落差が小さくなります。
全体で何割減るかという期待の持ち方をすると、照合や問い合わせが残ったときに「思ったほど楽にならない」という評価になりがちです。
逆に、消える工程と残る工程を先に分けておけば、残る工程にどれだけ人を割くかという運用の設計まで、導入前に決められます。

費用はどのように決まるか（料金構成の実例）

ベース利用料・カスタマイズ費用・オプション費用という内訳の例

費用を調べ始めると、金額そのものより先に、内訳の立て方で迷うことになります。
提供者によって、どこまでが基本料金に含まれ、どこからが個別の見積もりになるかが違うためです。
そこで、実際に公開されている料金情報を一つの例として見ておきます。

当社が提供するEC-Rider B2B IIの料金プランでは、ベースエンジンの利用料が月額170,000円からとして示されています³。
金額の後ろに「〜」が付いているのは、この利用料だけで導入がすべて完結するとは限らないからです。
取引先ごとの仕様の差を吸収する作業や、必要に応じて足す機能の部分は、前提となる条件によって変わります。

見積書を読むときは、編集上の整理として、費用を三つの層に分けて考えると比較しやすくなります。
一つめは基盤の利用料で、仕組みを使うための土台にあたる部分です。
二つめは合わせ込みの費用で、自社の基幹システムと取引先それぞれの仕様の差を埋める作業にかかります。
三つめは拡張の費用で、対応する取引先や業務の範囲を広げるときに発生します。

この三つのうち、事前に読みにくいのは二つめの合わせ込みです。
取引先の数が同じでも、仕様の差が大きければ作業量は増えますし、同じ規格を使っている取引先が多ければ流用が効いて抑えられます。
つまり合わせ込みの費用は、提供者の価格表ではなく、自社の取引先の顔ぶれによって決まる部分が大きいということです。
問い合わせの前に取引先ごとの状況を整理しておくほど、返ってくる金額の精度が上がります。

サーバー構成や処理量で費用が変わる例

同じ製品でも、どう使うかで月額が変わります。
先ほどの料金プランには、特定のサーバー構成を前提としたモデルケースとして、ASP利用料金が月額260,000円という例も示されています³。
基盤の利用料の下限と並べて見ると、構成の選び方によって月額が動くことが読み取れます。

ここで強調しておきたいのは、この二つの金額が当社の一製品の、しかも特定の前提に紐づく価格だという点です³。
Web-EDIを集約する仕組み全般の相場を表すものではありませんし、画面操作の自動化やAPI連携といった他の方式の費用水準を代表するものでもありません。
読者が自分の見積もりに持ち帰るべきなのは金額ではなく、金額が動く軸のほうです。

複数の提供者から見積もりを取るときに起きやすいのが、前提の違うものを横に並べてしまうことです。
片方は初期費用込みで三年分、もう片方は月額のみ、対象とする取引先の数も業務の範囲も違う、という状態で金額だけを比べると、安く見えたほうが後から積み上がることがあります。
期間、対象の範囲、追加が発生したときの課金の単位、そして自社側で必要になる工数。
この四つをそろえてから並べると、比較が成り立ちます。

見落とされやすいのは最後の自社側の工数です。
集約する仕組みを入れても、そこから自社の基幹システムへデータを渡す受け口は誰かが作る必要があります。
その改修が提供者の見積もりに含まれるのか、社内で行うのか、別の会社に頼むのか。
ここが曖昧なまま契約が進むと、月額は想定どおりでも導入が止まります。

費用以外に比較すべき条件（対応EDI規格の範囲）

流通BMSが対応する業務範囲（発注〜支払の6業務）

集約の可否を左右するもう一つの条件が、どのEDI規格にどこまで対応できるかです。
EDI規格とは、企業間でやり取りするデータの項目や形式を定めた取り決めのことで、代表的なものの一つに流通BMS（流通ビジネスメッセージ標準）があります。
流通BMSは、卸売（メーカー）と小売の間の取引業務を対象に、発注、出荷、受領、返品、請求、支払という六つの業務と、8種の標準メッセージに対応する規格として整理されています²。

この業務の並びを見ると、多画面問題の測り方が少し変わってきます。
発注だけを集約できたとしても、請求や支払が取引先の画面に残っていれば、担当者は月末に結局ログインすることになります。
つまり問題の大きさは、開かなければならない画面の数ではなく、画面へ行かないと終わらない業務の数で測るほうが実態に近いということです。

返品や支払のように件数の少ない業務は、集約の検討から抜け落ちやすい部分です。
ただ、件数が少ない業務ほど手順を覚えていられず、そのつど画面の操作を思い出すところから始まります。
一件あたりの負担でみると、毎日触れている発注より重いこともあります。
対応範囲を比べるときは、件数の多い業務だけでなく、たまにしか発生しない業務まで含めて範囲を確かめる価値があります。

取引先の規格・仕様に対応できるかの確認ポイント

規格名が同じでも、そのまま接続できるとは限りません。
どの項目をどう使うかの運用、商品や取引先を表すコードの体系、ファイルの受け渡しの方法、送受信のタイミング。
これらは取引先ごとの取り決めに委ねられている部分があり、同じ規格を採用していても差が残ります。
「対応規格は何か」と「その取引先の運用に合わせられるか」は、別々に確かめる必要があります。

取引先が特定の規格に則らず、独自のWeb-EDIを使っている場合はさらに事情が変わります。
この場合に判断を分けるのは、画面からデータを機械が扱える形で取り出せるかどうかです。
CSVでのダウンロードやアップロードができるなら、そこを接点にできます。
画面の表示だけで、印刷か目視しか手段がないなら、取り出しの部分から仕組みを考えることになり、必要な作業も費用も変わります。

確認の順序にもコツがあります。
規格名から尋ね始めると、取引先の担当者が規格名を即答できない場面で話が止まってしまいます。
先に「どの業務をこの画面でやり取りしているか」を整理し、次に「データはどうやって出し入れできるか」を確かめ、最後に規格名とバージョンにたどり着く順序のほうが、途中で行き詰まりにくくなります。
業務と手段は現場の担当者が答えられる範囲にあり、規格名はそこから逆にたどれることが多いためです。

集約を検討する側にとって、この確認はそのまま見積もりの精度につながります。
取引先ごとに、扱う業務、データの取り出し手段、規格名の三つが埋まった一覧があれば、提供者は合わせ込みの作業量を見積もれます。
逆にこの一覧がないまま相談すると、返ってくるのは幅の広い概算になり、比較の材料になりません。

自社の状況に応じた判断のポイント

取引先数・仕様差・社内のシステム対応力で変わる判断軸

ここまでの内容を、自社の状況に当てはめてみます。
判断を左右するのは、Web-EDIでつながっている取引先の数、取引先どうしの仕様の差、そして社内でシステムの改修や運用に対応できる体制があるかどうかの三点です。
この組み合わせによって、集約が効きやすい場面と、費用が膨らみやすい場面が分かれます。

よく聞かれるのが「何社くらいから集約を考えるべきか」という問いですが、社数だけでは答えが出ません。
取引先が多くても、規格や取り出し方がそろっていれば合わせ込みは流用が効き、費用は抑えやすくなります。
反対に、取引先が数社でも、それぞれ独自の画面で扱う業務も違うなら、社数のわりに作業量は大きくなります。
判断の軸に置くべきは社数ではなく、仕様の差がいくつあるか、そしてその差が今後増える見込みがあるかです。

社内の対応力も、方式の選び方に直結します。
基幹システム側の受け口を自社で作れる体制があるなら、データの受け渡しだけを外部の仕組みに任せる形が選べます。
担当者がいない場合は、受け口の設計から任せられる相手を探すことになり、費用の見え方も、相談すべき内容も変わります。
費用の安さを先に固めてから体制を考えると、この部分で計画が止まりやすくなります。

最初に確認すべきこと

最初に手を付けるべきなのは、金額を集めることではなく、自社の現状を一枚に写し取ることです。
取引先ごとに、どの業務をその画面で扱っているか、データはどう取り出しているか、締め時刻はいつか、担当者は誰か。
この四つの欄がある一覧を作ると、ここまで説明してきた判断の材料がほぼそろいます。
作ってみると、想定より業務の種類が多い、あるいは特定の担当者にしか分からない画面がある、といった形で問題の輪郭が出てくることもあります。

次に、いまかかっている時間を実際に測っておくことをおすすめします。
一週間ほど、画面の巡回と転記に使った時間を記録するだけで構いません。
外部の削減率は、あくまで別の施策の参考値です¹。
自社の削減幅を語れるのは、自社で測った時間だけですし、この記録は導入後に効果を確かめるときの比較対象にもなります。

そのうえで、これからの変化の見込みを書き添えます。
新しい取引先が増える予定があるか、いま紙や電話でやり取りしている業務をWeb-EDIへ移す話が出ているか。
集約の仕組みは、入れた時点の取引先だけを見て選ぶと、一年後に追加の費用が読めなくなります。
増える見込みがあるなら、取引先を追加したときの課金の単位を、契約前に確かめる意味が大きくなります。

最後に、社内で誰がこの件を持つかを決めておきます。
受発注の現場が困っている問題である一方、解決には基幹システム側の受け口が関わるため、現場だけでも情報システム部門だけでも完結しません。
ここまでの一覧と時間の記録があれば、両者が同じ材料を見ながら話せます。
集約の検討が途中で止まる原因は、たいてい技術ではなく、この共有されていない前提のほうにあります。

多画面問題の集約は、費用の安い方式を選ぶ作業ではなく、どの業務まで画面へ行かずに済ませたいかを決める作業です。
公開されている削減率も料金も、それぞれの前提と一体で読む必要があります。
自社の取引先一覧と、いまかかっている時間。
この二つがそろったところから、比較が具体的になります。

集約の効果も費用も、取引先ごとの業務範囲とデータの取り出し方が分からなければ幅の広い概算にしかならず、社内だけで詰めきれない部分が残ります。

取引先ごとの業務と受け渡し方法を整理した状態でご相談いただければ、どの業務まで画面へ行かずに済ませられるか、費用がどの要素で動くかを、公開している料金の構成に沿ってご説明します。無料相談で要件を整理する

集約の方法を選ぶときに見る判断軸

費用の安さではなく、集約したあとに取引先の画面へ戻らずに済むかどうかを基準に並べました。

• 集約後も取引先の画面へ行かないと終わらない業務が残るか（発注だけか、請求・支払まで含むか）

• 取引先のデータを機械が扱える形で取り出せるか（CSVなどの手段があるか、画面表示のみか）

• 取引先ごとの仕様の差がいくつあり、今後増える見込みがあるか

• 基盤の利用料のほかに、合わせ込みと拡張の費用がどこまで見積もりに含まれるか

• 取引先や業務を追加したときに、どの単位で費用が発生するか

• 自社の基幹システム側の受け口を誰が作り、その工数が見積もりのどちらに入っているか

取引先の仕様差が小さくデータの取り出し方もそろっている場合は、対応範囲より、費用の構成と日々の運用の手間が判断の中心に移ります。

要点の整理

軸	基準
効果の見積もり	外部の削減率をそのまま当てず、ログインと巡回、取り出し、転記、照合、問い合わせの工程ごとに減り方を見る
費用の読み方	基盤の利用料、合わせ込み、拡張、自社側の工数の四つに分け、期間と対象範囲をそろえて比べる
対応範囲	発注だけでなく、請求や支払まで画面へ行かずに済むかで測る
取引先の条件	社数よりも、仕様の差がいくつあるかと、今後増える見込みで判断する
着手の順序	取引先ごとの業務・取り出し手段・締め時刻・担当者の一覧と、現状の作業時間の記録から始める

基幹システム側の受け口を誰がどこまで担うかは、方式選びと同じくらい導入の成否を左右しますが、製品情報を読むだけでは自社に当てはめにくい部分です。 現在のWeb-EDIの使われ方と社内の体制を伺ったうえで、自社側に残る作業の範囲と、取引先が増えたときに費用がどう動くかを整理してお伝えできます。

よくある質問

Web-EDIを集約すると既存の取引先とのやり取りに影響はありますか

どの集約の仕方を選ぶかで変わります。
取引先の画面や仕様はそのままにして自社側で束ねる形であれば、取引先から見たやり取りの中身は変わらず、自社側で扱いが変わります。
一方、規格を共通化する形で進める場合は、取引先にも同じ形式でのデータのやり取りに対応してもらう必要があるため、事前の合意と調整が前提になります。
どちらを選ぶかは、取引先が仕様の変更にどこまで応じられるかで現実的な答えが変わりますので、検討の早い段階で取引先側の事情を確かめておくと、後戻りが減ります。

取引先が対応しているEDI規格が分からない場合はどう確認すればよいですか

規格名から尋ねると、相手の担当者が即答できずに話が止まることがあります。
先に「その画面で発注、出荷、受領、返品、請求、支払のどれをやり取りしているか」を整理し、次に「データをCSVなどの形で出し入れできるか」を確かめ、最後に規格名とバージョンを尋ねる順序が進めやすくなります。
業務と取り出し手段は現場の担当者が答えられる範囲にあり、そこから規格の見当も付きます。
流通BMSのように、対象とする業務の範囲が公開されている規格もあるため、扱っている業務の顔ぶれと突き合わせて確かめることもできます²。

集約したあとに新しい取引先が増えた場合、追加費用はどう発生しますか

発生の仕方は提供者と契約の形によって異なるため、金額の目安を一律に示すことはできません。
確かめるべきなのは、追加が「基盤の利用料の範囲内」なのか、「合わせ込みの作業として都度見積もり」なのか、「取引先数などの単位で課金」なのかという、課金の単位のほうです。
新しい取引先が既存と同じ規格・同じデータの取り出し方であれば流用が効き、独自の仕様であれば作業が要る、という違いも費用に反映されます。
取引先が増える見込みがあるなら、初期の導入費用と同じ重さでこの条件を確認しておく価値があります。

社内にシステム担当者がいない場合でも集約は進められますか

進められないわけではありませんが、誰が基幹システム側の受け口を作るかを決めておく必要があります。
集約の仕組みが取引先ごとのデータを一つにまとめても、そこから自社の仕組みへ渡す部分は残るためです。
その設計や改修を提供者に含めて依頼するのか、別の会社に頼むのか、あるいは当面は集約されたデータを人が扱う運用にするのか。
選択肢はありますが、ここが決まらないまま契約だけ進むと導入が止まりやすいため、相談の時点で「どこまでをお願いできるか」を確かめておくことをおすすめします。

1. 1　出典：中小企業庁「中小企業共通EDI（次世代企業間データ連携調査事業）」（2018年）　経路
2. 2　出典：一般財団法人流通システム開発センター（GS1 Japan）「流通ビジネスメッセージ標準（流通BMS）標準仕様」（2018年11月、基本形Ver.2.0時点）　経路
3. 3　出典：株式会社フライトソリューションズ「EC-Rider B2B II 料金プランページ」（2026年）　経路