EDIとは？受発注の文脈でわかりやすく解説（種類・費用・自社開発との違い）

「取引先から『これからはEDIで発注します』と言われたけれど、EDIって結局なに？」——受発注の現場では、こんな場面が増えています。EDIは、企業同士が注文や請求のデータを電子でやり取りする仕組みで、言葉は難しそうでも、やっていることは「紙やFAXの注文を、システム同士のデータ交換に置き換える」ことです。この記事では、EDIとは何かを受発注の文脈でやさしく解説し、なぜ使われるのか、種類、自社の受発注システムやBtoB ECとの違い、中小がEDI対応を迫られたときの選択肢、費用の目安と一律100万円で作れる範囲まで、注文処理に追われる現場目線でまとめます。

EDIとは（受発注の文脈でわかりやすく）

EDIとは、Electronic Data Interchange（電子データ交換）の略で、企業と企業が受発注・出荷・請求といった取引データを、決められた形式で電子的にやり取りする仕組みのことです。これまで紙の注文書やFAX、電話で伝えていた「何を・いくつ・いつまでに」という情報を、システム同士が直接データで交換します。

イメージしやすいのは、取引先と自社のあいだに「共通の伝票フォーマットと専用のポスト」を用意することです。取引先が注文データをそのポストに入れると、自社のシステムがそれを受け取り、そのまま受注として処理できます。人が注文書を見ながらキーボードで打ち直す作業が、まるごと不要になります。

やり取りされるデータは、受発注だけではありません。取引の流れに沿って、次のような情報が電子で交換されます。

データの種類	やり取りされる内容
発注データ	何を・いくつ・いつまでに、という注文情報
出荷・納品データ	出荷した品目・数量、納品予定
受領データ	取引先が受け取った内容の確認
請求・支払データ	締め後の請求金額、支払いの案内

つまりEDIは、「注文から請求まで」の一連の伝票を、紙の代わりにデータで流すための共通ルールだと考えるとわかりやすいです。

なぜEDIが使われるのか

EDIが広く使われる理由は、大きく2つあります。1つは大手取引先からの要請、もう1つは転記の手間とミスの削減です。

まず、スーパーやドラッグストア、大手メーカーなど、1日に膨大な注文を出す企業は、取引先ごとにFAXや電話で注文していては処理しきれません。そのため「うちと取引するならEDIで」という形が、事実上の取引条件になっていることが多いのです。納入業者側からすると、EDIに対応できるかどうかが取引継続の条件になる場面もあります。

もう1つの理由が、手作業の削減です。FAXで届いた注文をシステムに打ち直す作業は、時間がかかるうえに品番や数量の打ち間違いが起きます。EDIならデータがそのまま受注として取り込まれるので、次のような効果が見込めます。

• 転記作業がなくなる：注文を見ながら入力する時間がゼロに近づく。
• 入力ミスが減る：品番・数量・単価の打ち間違いによる誤出荷・請求ミスを防ぐ。
• 処理が速くなる：注文を受けてから出荷手配までのリードタイムが短くなる。
• 繁忙期に強い：件数が増えても人手を増やさずさばける。

たとえば、大手スーパー3社に食品を納める卸で、それぞれから毎日100件近い注文がFAXで届いていたとします。担当者が午前中いっぱいをかけて入力し、月末は請求書の突き合わせに数日を取られていた——という現場でEDIに切り替えると、注文データがそのまま受注に取り込まれ、入力そのものが消えます。浮いた時間を、仕入れ交渉や新規開拓といった「人にしかできない仕事」に回せるのが、EDIの本質的な価値です。

受発注まわりの手作業をなくすという方向性は、EDIに限らず受発注システム全般に共通します。基礎は受発注システムとは？も合わせてご覧ください。

EDIの主な種類

ひとくちにEDIといっても、いくつかの方式があります。中小企業がよく出会うのは、次の3つです。

種類	特徴	向いているケース
従来型EDI	専用回線やソフトを使い、システム同士が直接データ交換する。大手取引先で古くから使われる	取引量が非常に多く、基幹システムと本格的に連携したい
Web-EDI	ブラウザから取引先のサイトにログインして注文を確認・入力する方式	中小の納入業者が、取引先ごとの画面で手軽に対応したい
流通BMS	流通業界向けに標準化された新しいEDI規格。インターネット回線を使う	複数の大手取引先と標準的な形でやり取りしたい

従来型EDIは、専用の回線や通信手順を使ってシステム同士が直接つながる、昔からある方式です。大量の取引を自動でさばける一方、導入・運用が重くなりがちです。

Web-EDIは、取引先が用意したWebサイトに納入業者がログインし、届いた注文を画面で確認したり、出荷データを入力したりする方式です。専用回線が不要で、パソコンとブラウザがあれば始められるため、中小企業が最初に触れるEDIはこの形が多くなっています。ただし、取引先ごとに別々のサイトにログインする必要があり、取引先が増えるほど「サイトの数だけ画面を開く」手間が増える弱点もあります。

流通BMSは、バラバラだったEDIの規格を流通業界で標準化したもので、インターネット回線を使うぶん従来型より導入しやすくなっています。

大事なのは、「どの方式が優れているか」ではなく、取引先がどの方式を求めているかでこちらの対応が決まる、という点です。取引先が複数いれば、従来型・Web-EDI・流通BMSが混在することも珍しくありません。

EDIと自社の受発注システム・BtoB ECの違い

「EDIを入れれば、受発注システムは要らないのでは？」という疑問はよくあります。ここは混同しやすいので整理しておきましょう。

• EDI：主に「大手取引先とデータをやり取りするための共通ルール・回線」の部分。取引先とのあいだの“通り道”にあたる。
• 自社の受発注システム：自社に届いた注文・在庫・請求を管理する“自社側の台帳”。
• BtoB EC（Web受発注）：取引先が自分でブラウザから注文を入力する、自社が用意する“注文サイト”。

役割が違うので、これらは競合するものではなく、組み合わせて使うものです。たとえば、大手取引先からはEDIで注文を受け取り、それを自社の受発注システムに取り込んで在庫引当・出荷・請求につなげる。一方、中小の取引先には自社のBtoB EC（Web受発注）で注文してもらう——というように、複数の入口を1つの受発注システムに束ねる形が現実的です。

卸売業のように取引先が多い業種では、この「EDI・Web受発注・FAXが混在する注文を、1つの台帳に集約する」設計がとくに重要になります。詳しくは卸売の受発注システムで、取引先ごとの単価や締めの扱いまで含めて解説しています。

この3つを分けて考えると、投資の順番も見えてきます。まずは自社の受注・在庫・請求を管理する土台となる受発注システムを持ち、そのうえで、大手取引先向けにはEDIの入口を、中小取引先向けにはBtoB ECの入口を足していく——という順番です。土台がないままEDIだけを入れても、結局その先で手入力が発生してしまい、効果が半減します。

中小がEDI対応を迫られる場面と選択肢

中小企業がEDI対応を考えるきっかけは、たいてい取引先からの要請です。「来月からEDIで発注する」「Web-EDIに登録してほしい」と言われ、対応しないと取引が難しくなる、という場面です。このとき取れる選択肢は、おおむね次の3つです。

選択肢	内容	向いているケース
既製のWeb-EDIをそのまま使う	取引先が用意した画面にログインして対応	取引先が少なく、件数もそれほど多くない
変換・取り込みの仕組みを入れる	Web-EDIから出したデータを自社システムに取り込む	手入力の二度手間をなくしたい
自社システムとEDIを連携する	受注データを自動で自社の台帳に反映	取引先・件数が多く、自動化したい

取引先が1〜2社で件数も少ないうちは、取引先のWeb-EDI画面をそのまま使うのが手軽です。ただし、Web-EDIで見た注文をまた自社システムに打ち直しているなら、それは「FAXが画面に変わっただけ」で、転記の手間は残っています。取引先や件数が増えてきたら、Web-EDIから出したデータを自社の受発注システムに取り込む、あるいはEDIと自社システムを連携させて自動で受注に反映する方向に進めると、手作業を本当に減らせます。

判断の目安は、「その取引先の注文にかけている時間」です。たとえば、Web-EDIのために毎朝いくつものサイトにログインし、注文を確認して自社システムに打ち直す作業に1〜2時間かかっているなら、取り込みや連携の仕組みを入れる費用は十分に回収できます。逆に、月に数件しか注文がない小口の取引先まで自動連携しようとすると、かけた費用に見合いません。「件数が多く手間のかかる取引先だけ自動化し、残りは手動のまま」と割り切るのが、費用対効果の高いやり方です。

EDI導入の費用感と注意点

EDI対応の費用は、「どの方式に・何社ぶん対応するか」で大きく変わります。取引先が用意したWeb-EDIを使うだけなら、初期費用はほとんどかからないこともあります。一方で、自社システムとの連携や変換の仕組みを作るとなると、開発費用が必要です。

注意しておきたいのは、EDIは取引先ごとに仕様（データの形式や項目）が違うという点です。同じ「発注データ」でも、A社とB社でフォーマットが異なることは普通にあります。そのため、複数の取引先とEDI連携しようとすると、取引先の数だけ「合わせ込み」の作業が発生し、費用がふくらみやすくなります。

• 取引先ごとに仕様が違う：1社対応できても、次の取引先でまた調整が要る。
• 相手都合の変更がある：取引先側の規格変更に、こちらが追随する必要が出る。
• 全部を一度に対応しない：件数の多い主要取引先から段階的に進めるのが安全。

費用を抑えるコツは、「一番手間がかかっている取引先」から優先して自動化し、少額の取引先は当面Web-EDIの手動対応のままにする、という優先順位づけです。システム開発の費用の考え方全般は業務システムの開発費用も参考になります。

もう一つ、見落とされがちなのが運用が始まってからの手間です。EDIは取引先とのデータのやり取りが日々続くため、フォーマットの変更や、うまく取り込めなかったデータへの対応が発生します。導入時の費用だけでなく、「誰が日々の運用を見るか」「エラーが出たときにどう気づくか」まで含めて考えておくと、導入後に慌てずに済みます。最初は主要取引先1社で運用を回し、問題点を洗い出してから広げると、こうしたトラブルを小さいうちに潰せます。

自社システムとEDIをつなぐ開発

「EDIで受け取った注文を、自社の受発注システムに自動で流したい」——ここが、開発でよく相談される部分です。技術的には、EDIやWeb-EDIから出力されるデータ（CSVなどのファイルや、API経由のデータ）を受け取り、自社システムのフォーマットに変換して取り込む、という流れになります。

この「システム同士をデータでつなぐ」仕組みは、EDIに限らずAPI連携と考え方が共通しています。会計ソフトや在庫システムとの連携と同じく、外部から来たデータを自社の台帳に自動で反映させることで、二重入力をなくします。連携の基本的な考え方はAPI連携とは？でやさしく解説しています。EDI対応も、身構えるほど特別なものではなく、こうしたデータ連携の一種として捉えると全体像がつかみやすくなります。

現実的な進め方は、次のような順番です。

1. 一番件数の多い取引先1社ぶんのEDIデータを、自社システムに取り込めるようにする。
2. 取り込み・受注反映がうまく回ることを確かめる。
3. 効果を見ながら、他の取引先や出荷・請求データの連携へ広げる。

最初から全取引先・全データの自動連携を目指すと、費用も期間もふくらみます。「一番手間を奪っている一社・一工程」に絞って小さく作るのが、失敗しにくいやり方です。取り込みの仕組みができてしまえば、2社目・3社目はフォーマットの違いを合わせ込むだけで済むことも多く、最初の1社ぶんの投資が、その後の横展開の土台になります。

費用相場と、一律100万円で作れる範囲

EDIまわりの開発費用は、対応する規格の数・取引先の数・自社システムとの連携の深さで変わります。目安は次のとおりです（一般的な相場感で、要件により上下します）。

範囲	費用の目安
Web-EDIのデータを自社システムに取り込む（1〜数社）	100万円前後
複数取引先のEDIデータ変換・自動取り込み	+30万〜100万円
基幹・在庫・請求とのフル連携、複数EDI規格対応	200万〜400万円
大量取引先・多規格・リアルタイム連携	400万円〜

「EDI対応は大がかりで高い」というイメージがありますが、範囲を絞れば一律100万円でも実用的な仕組みは作れます。100万円で狙いやすいのは、取引先が用意したWeb-EDIの画面を使いつつ、そこから出したデータを自社の受発注システムに取り込んで、受注・在庫・請求につなげる範囲です。

一方、複数のEDI規格へのフル対応や、大量の取引先との完全自動連携まで盛り込むと、100万円には収まりにくくなります。予算内に収めるコツは、一番件数の多い取引先の受注取り込みに絞って作り、他は効果を確かめてから足すことです。D-oneAppは追加費用なし・着手前に総額を確定するので、「うちの取引先のEDI、どこまで自動化するといくら？」を見える形で相談できます。

まとめ

EDI（電子データ交換）とは、企業同士が受発注・出荷・請求のデータを、決められた形式で電子的にやり取りする仕組みです。紙やFAXの注文をシステム同士のデータ交換に置き換えることで、転記の手間とミスを減らせます。大手取引先からの要請で対応を迫られる場面が多く、方式には従来型EDI・Web-EDI・流通BMSなどがあり、どれを使うかは取引先が求める形で決まります。EDIは自社の受発注システムやBtoB ECと競合するものではなく、複数の入口を1つの台帳に束ねてつなぐのが現実的です。取引先ごとに仕様が違うぶん、件数の多い取引先から小さく始めるのが失敗しにくく、範囲を絞れば一律100万円でも実用的な一本が作れます。無料相談で「うちのEDI対応、システム化するといくら？」を整理しましょう。