EDI導入の期間は何で決まるのか：取引先数・データ範囲・通信方式から見積もる

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

B2B EC-COLUMN

「EDI導入は何か月」と聞かれたとき、一つの数字で答えられない理由

取引先から「この時期までにEDIで注文をやり取りしたい」と言われ、上司からは「何か月で切り替えられるのか」と聞かれる。
それでも、手元に答えとして使える数字がない、という場面は珍しくありません。
EDI導入の期間は、方式ごとに決まった月数で示せるものではありません。
つなぐ取引先の数、扱う注文データの範囲、自社の受発注システムとどこまで連携するかで伸び縮みします。
取引先1社ごとの事前調整に1か月ほどかかったという企業の例があり、期限の直前に作業を集めると間に合わない取引先が出ます。
期間を要素に分けて見積もり、範囲を絞って前倒しで始めれば、根拠を添えて説明できる計画になります。

期間は方式の名前だけでは決まらない

EDI（企業間で注文などの取引データを、決まった形式でやり取りする仕組み）の導入期間を聞かれると、「Web-EDIなら何か月、自社で構築するなら何か月」という答え方を探したくなります。
しかし、方式ごとの標準的な月数を示した公的な目安は、現時点で確かめられるものがありません。
確かな材料として手元にあるのは、標準仕様が求める項目の数、取引先1社ごとの調整にかかった企業の例、通信手順の終了期限です。
どれも、期間そのものではなく、期間を組み立てる部品にあたります。

仮に、上司へ「3か月ほどです」と答えたとします。
つなぐ相手が1社で、注文データを画面で受け取るだけなら、その範囲に収まるかもしれません。
一方で、取引先が20社あり、受け取った注文を自社の受注システムへ自動で取り込みたいのであれば、同じ3か月の中で20社分の調整と、システムをつなぐ作業の両方を終える必要があります。
同じ「EDI導入」という言葉でも、中身の作業量がまったく違うのです。

上司や取引先に伝えた数字が後でずれると、取引先側の準備や、社内の人の割り当てまで組み直しになります。
最初に一つの月数を出すより、「何がどれだけあるから、この期間になる」と説明できる形にしておくほうが、後から修正するときにも理由を示しやすくなります。

工程・取引先数・連携範囲に分けて見積もる

期間を分けて考えるときは、三つの要素を掛け合わせる見方が使えます。
一つ目は、社内で決めることと取引先と合わせることを含めた工程です。
二つ目は、その工程を何社分繰り返すかという取引先数です。
三つ目は、受け取ったデータを画面で見るだけにするのか、自社のシステムへ取り込むのかという連携範囲です。

工程は、大きく見ると社内の準備、取引先1社ごとの調整とテスト、本番への切替に分かれます。
社内の準備は一度で済む部分が多い一方、取引先との調整とテストは社数の分だけ発生します。
連携範囲を広げると、社内の準備にシステムをつなぐ作業が加わり、取引先ごとのテストでも確かめる項目が増えます。
これは実測の相場ではなく、見積もりのための整理です。
それでも、自社の数字を一つずつ当てはめていく枠組みとしては十分に使えます。

期間を左右する条件：方式・取引先数・データ範囲・既存システム連携

取引先数

取引先数は、期間に最もそのまま効いてくる要素です。
EDIは自社だけで完結せず、相手と同じ形式・同じ通信の方法でデータを送り合えることを確かめて、はじめて使えるようになります。
相手が1社増えるごとに、連絡、仕様のすり合わせ、テスト送受信、切替日の決定という一連のやり取りが増えます。

見落としやすいのが、取引先ごとの事情の違いです。
すでに別の企業とEDIをしている取引先なら話が早く進むこともあります。
反対に、EDIの担当者が決まっていない取引先では、窓口を探すところから始まります。
同じ10社でも、各社がどの段階にいるかで期間は変わります。

取引先がどの業界の標準を使っているかも、社数と一緒に確かめておきたい点です。
消費財流通の業界では、流通BMSという業界標準が使われています⁴。
取引先によって求める標準が違えば、自社は複数の形式に対応することになり、その分だけ準備とテストが増えます。

扱う注文データの範囲

次に効くのが、どのデータを、どの項目までやり取りするかです。
中小企業共通EDIの標準仕様書は、EDIのサービスを提供する事業者（プロバイダー）に対応を求める注文メッセージを全135項目、業務アプリケーションに対応を求める最低限の項目を13項目と定めています¹。
13項目には、注文書番号や注文書発行日などが含まれます¹。

この数字から読み取れるのは、注文データ一つをとっても、標準が用意している項目と、最低限そろえる項目との間に大きな幅があるということです。
取引先と「どの項目を使うか」を決める作業は、この幅の中で行われます。
使う項目が増えるほど、項目ごとの意味の確認、自社の品番や取引先コードとの対応付け、テストで照らし合わせる箇所が増えていきます。

ただし、13項目が最低限だからといって、その範囲にすれば期間が短くなるとまでは言えません。
最低限の項目だけでは自社の受注処理に足りず、結局は電話やメールでの確認が残ることもあり得ます。
また、135項目と13項目という区分は中小企業共通EDIの標準仕様に沿う場合の話で、流通BMSなど他の標準にはそのまま当てはまりません。
範囲を決めるときは、項目の数より、自社が注文を受けてから出荷するまでにどの情報を使っているかを基準にするほうが、後で足りない項目に気付いて作業が戻る事態を減らせます。

既存の受発注・基幹システムとの連携

三つ目は、受け取った注文データを自社のシステムでどう扱うかです。
今はFAXやメールで届いた注文を、担当者が受注システムや基幹システム（販売・在庫・会計などをまとめて管理するシステム）へ手で入力しているとします。
EDIで注文をデータとして受け取っても、それを画面で見て同じように手入力するなら、システム側の作業はほとんど増えません。
その代わり、転記の手間と、入力ミスがないかの確認は残ります。

受け取ったデータを自社のシステムへ取り込むようにすれば、その転記は減らせます。
ただし、取引先から届く項目と自社システムの項目を対応付け、形式を変換し、取り込んだ結果が正しいかを確かめる作業が加わります。
システムの改修を外部の会社に頼んでいる場合は、その会社の予定にも期間が左右されます。

ここまでの三つの条件を、期間が延びやすい状況と抑えやすい状況に分けると、次のように整理できます。
どちらに寄るかは自社と取引先の状況で決まり、右側を選べば必ず短くなるという意味ではありません。

取引先1社の調整は1か月ほど：事例から読める範囲と読めない範囲

約500弱の取引先とつながる企業の例が示すこと

取引先1社あたりにどれくらい見込めばよいかを考えるうえで、手掛かりになる報道があります。
2016年の記事で、約500弱の小売店とEDIを利用している企業が、EDIの通信方式を切り替えるにあたり、事前調整から利用開始までに1社あたり1か月ほどかかると述べています²。
同じ企業は、切替の直前に作業が集中すると、間に合わない取引先が出ることへの懸念も語っています²。

この話から読み取れるのは、EDIの切替が取引先1社ごとに、事前の連絡や設定、確認といった一定の時間を伴う作業だということです。
相手が多ければ、その時間が社数の分だけ積み重なります。
一度に進められる社数には、自社の担当者の手と、取引先側の準備の速さという二つの限りがあります。
期限が近づいてから全社に一斉に声をかけると、どちらかの限りに当たり、後回しになった取引先が期限までに終わらなくなります。

1か月を自社の見積もりに使うときの注意

一方で、この1か月をそのまま「EDI導入の標準期間」として使うことはできません。
これは、すでにEDIでつながっている相手との通信方式の切替についての、一つの企業の目安です。
新しくEDIを始める場合は、取引先と形式や項目をまだ決めていないため、すり合わせに要する時間がこの例と同じになるとは限りません。
また、2016年の記事であり、その後の通信環境やサービスの変化は反映されていません。

1社1か月に社数を掛けて全体の期間とする計算も、この資料からは成り立ちません。
何社を並行して進めていたのかが、記事に書かれていないからです。
1社ごとに1か月かかるとしても、並行して進めれば全体は「社数×1か月」より短くなりますし、並行できる社数は企業によって違います。

この例を自社に生かすなら、数字そのものより、取引先1社ごとに調整の時間が要ること、そして期限直前の集中が遅れを生むことの二点を受け取るのが妥当です。
自社の1社あたりの日数は、最初の取引先で実際にかかった日数から見積もるほうが確かです。

Web-EDI利用と自社でのEDI構築で、期間の何が変わるのか

違いは期間の長さより、作業が生じる場所

取引先などが用意したWebの画面にログインして注文を確認する形は、一般にWeb-EDIと呼ばれます。
これに対して、届いたデータを自社の受注システムなどへ取り込んで使う形では、自社側でデータを受け渡す仕組みを用意します。
前の節で見た連携の有無を、始め方の選択として見直すと、両者の違いは期間の長さより、作業がどこに生じるかにあります。

中小企業共通EDIの標準仕様書は、プロバイダーに対応を求める注文メッセージの全135項目と、業務アプリケーションに対応を求める最低限の13項目を分けて定めています¹。
ここからは、データの形式や通信を整える役割と、受け取ったデータを業務で使う役割とが、分けて考えられていることが読み取れます。
自社の業務システムとつなぐ場合は後者の役割を自社側で担うことになり、項目の対応付けや取り込みの確認が自社の作業として加わる、と整理できます。

Web-EDIで始める場合に残る作業

Web-EDIで始める場合、自社のシステムに手を入れずに済むことが多く、準備は利用登録、画面操作の習得、注文確認の手順づくりが中心になります。
その一方で、画面に表示された注文を自社の受注システムへ入力する作業は、FAXのときと同じように残ります。
取引先ごとに別の画面を使う形になれば、確認する画面の数も取引先の数だけ増えます。

導入までの準備を抑えやすい代わりに、日々の転記と照合は続く、ということです。
取引先が少ないうちは負担が目立たなくても、EDIで受ける注文が増えてくると、画面ごとの確認と入力がまとまった作業時間になっていきます。

自社のシステムとつなぐ場合に増える作業

自社の受注システムや基幹システムとつなぐ場合は、取引先から届く項目を自社システムのどの欄に入れるかを決め、品番や取引先コードの変換を用意し、テストで実際の注文が正しく取り込まれるかを確かめます。
この作業は最初の取引先で最も大きくなり、同じ形式を使う取引先が増えるほど、作った仕組みを使い回せる部分が出てきます。
取引先ごとに使う項目や標準が違えば、その差分の分だけ追加の対応が要ります。

どちらで始めるかは、期限までの時間と、今の転記の負担のどちらを重く見るかで決まります。
期限が迫っているなら、画面での確認や最小限の取り込みで動かし始め、つなぐ範囲は後から広げる、という段階の踏み方もあります。
ただし、両方式の期間や費用の差を一般的な数字で比べられる確かな資料は見当たりません。
どちらが何か月短いかは、候補になる仕組みの提供元に、自社側で必要な作業の内容を具体的に聞いて比べることになります。

通信方式に期限がある場合：INSネット ディジタル通信モードの終了

期限が通信インフラから来ていないか

取引先から伝えられた期限が、相手の社内事情ではなく、通信の仕組みの終了から来ていることもあります。
NTT東日本の案内によると、INSネットのディジタル通信モードは2024年から地域ごとに段階的に終了し、その後の補完策も2028年度末に提供を終了する予定です³。
同じ案内では、ディジタル通信モードの主な用途の一つとしてEDIが挙げられています³。

この期限が関係するのは、電話回線を使った従来の通信手順でEDIをしている企業です。
自社か取引先のどちらかがその方式で注文データを送受信しているなら、通信方式の切替に期限があることになります。
反対に、これからインターネットを使うEDIを新しく始める場合、この期限そのものは関係しません。

自社がどちらに当たるか分からないときは、EDIで使っている回線の契約と、注文データを送受信している端末やソフトの設定が手掛かりになります。
取引先からの依頼文に「INSネット」「ISDN」「ディジタル通信モード」といった言葉があれば、通信方式の切替を求められている可能性が高いと考えられます。
期限の出どころが分かると、交渉で動かせる期限なのか、動かせない期限なのかの見通しも立ちます。

終了期限から逆算すると何が言えるか

前の節で見た1社1か月ほどという例は、まさにISDNの移行に向けたEDIの切替についての発言でした²。
1社ごとに事前調整から利用開始まで時間がかかり、直前に集中すると間に合わない取引先が出るという話を、2028年度末という終了予定³と重ね合わせると、従来の通信手順を使っている企業は、期限から逆算して早めに着手する必要があると言えます。

ただし、この二つの資料からは、何社まで並行して進められるか、全体で何か月かかるかまでは導けません。
取引先の多い企業ほど、早く始めることの意味が大きくなる、というところまでが言える範囲です。
全体の期間は、自社の実績をもとに組み立てる必要があります。

期限から逆算する：範囲を絞り、取引先を波に分けて始める

最初に決める範囲

期限が決まっているとき、最初に決めたいのは「最初の稼働で何をやり取りするか」です。
EDIでは注文のほかに、出荷の案内や請求などのデータもやり取りできますが、最初からすべてを対象にすると、取引先ごとに決める項目も、テストする場面も増えます。
まずは注文データに絞り、出荷や請求は注文のやり取りが安定してから加える順にすると、最初の稼働までに決めることが少なくなります。

注文データの中でも、使う項目は自社の受注処理に照らして決めます。
注文を受けてから出荷するまでに、担当者が実際に見ている情報を書き出すと、必要な項目と、取引先から届いても使わない項目とが分かれてきます。
連携の範囲も同じ考え方で、最初の稼働では画面での確認や一部の取り込みにとどめ、全面的な自動取り込みは後の段階に回すことも選べます。

取引先を波に分ける

範囲が決まったら、取引先を何回かの波に分けて順に始めます。
最初の波は1社か少数にし、EDIに慣れていて協力を得やすい取引先を選ぶと、自社の手順の不備をこの段階で見つけやすくなります。
注文の件数が非常に多い取引先は、不具合が起きたときの影響が大きいため、最初の波から外し、手順が固まってから移すほうが無難です。

次の波からは、同じ標準や似た項目を使う取引先をまとめると、最初の波で作った設定や確認の手順を使い回せます。
期限を伝えてきた取引先がある場合は、その取引先を期限まで余裕のある波に入れ、最後の波は期限よりかなり手前で終わるように置きます。
直前に集中すると間に合わない取引先が出るため²、最後の波の後ろに予備の期間を残しておくことが、遅れた取引先を受け止める余地になります。

1社目の実績で残りを見積もる

全体の期間は、最初の波で実際にかかった日数をもとに組み立てます。
記録しておきたいのは、取引先へ最初に連絡してから仕様が決まるまで、テスト送受信を始めてから問題がなくなるまで、本番の注文で受け取りを始めて落ち着くまで、という区切りごとの日数です。
区切って残しておくと、2社目以降で短くなりそうな工程と、相手次第で変わる工程とを分けて考えられます。

たとえば、仮に1社目で連絡から本番開始まで6週間かかり、担当者の手が回るのは同時に2社までだと分かったとします。
残りが10社なら、2社ずつ5回に分けて、単純計算で30週間です。
実際には、2社目以降は設定の使い回しで短くなる工程もあれば、返事が遅い取引先で延びる工程もあるため、この計算に予備の期間を足して上司や取引先に示します。
ここでの6週間や2社は説明のための仮の数字で、自社の実績に置き換えて使います。

この見積もり方なら、最初に説明する時点では「1社目の結果を見て全体の日程を確定する」と伝えられ、1社目が終わった時点で、根拠のある日程を示せます。
見積もりと実績がずれたときも、どの工程で何日ずれたかが分かるため、残りの波を組み直す理由を説明しやすくなります。

期間を左右する要素のうち、注文が届いてから出荷するまでのどこに転記や確認が残っているかは、毎日の作業に慣れているほど社内だけでは見落としやすい部分です。

今の受注の流れをたどりながら、最初の稼働で扱う注文データの範囲と、自社システムとつなぐかどうかを判断する材料を整理できます。無料相談で要件を整理する

要点の整理

軸	基準
期間の見積もり方	方式別の月数ではなく、工程×取引先数×連携範囲で組み立てる
データの範囲	まず注文データ。項目は自社の受注処理で使う情報を基準に選ぶ
連携の深さ	期限を優先するなら画面確認や一部取り込みから始め、転記を減らす取り込みは後から広げる
1社あたりの目安	1社1か月ほどは2016年の既存EDI切替の一企業の例。自社の1社目の実績で置き換える
INSネットの期限	ディジタル通信モードでEDIをしている場合に関係。補完策は2028年度末に提供終了予定
進め方	取引先を波に分け、最後の波の後ろに予備期間を残す

取引先を波に分ける順番や、1社目の結果から全体の日程を組み直す判断は、期限が近いほど急ぎがちで、後から理由を説明しにくくなります。 取引先の一覧と期限をもとに、どの取引先から始め、どこに予備の期間を置くかを確かめられます。

よくある質問

導入の準備は何から始めればよいですか。

まず、EDIでつなぐ候補の取引先を一覧にし、各社から求められている方式・標準・期限と、窓口の担当者を書き出します。
同時に、今の注文が届いてから出荷するまでに、誰がどの画面へ何を入力しているかを整理しておくと、扱うデータの範囲と連携の深さを決めやすくなります。
この二つがそろうと、最初の波に入れる取引先と、最初の稼働で扱う項目を決められます。

取引先がEDIへの対応に応じてくれない場合はどうすればよいですか。

取引先にも準備の都合があるため、対応が遅い取引先は後の波に回し、その間は従来のFAXやメールでのやり取りを続ける形が考えられます。
EDIの取引先と従来のやり方の取引先が混在する期間は、注文の受け取り方が二通りになるため、受注の確認手順を両方に合わせて用意しておきます。
通信方式の終了期限が関わる場合は残り時間が限られるため、早い段階で状況を共有しておくことが大切です。

INSネットを使っていない場合も期限はありますか。

ディジタル通信モードの終了期限は、それを使ってEDIをしている企業に関係するものです³。
自社も取引先も使っていなければ、この期限は当たりません。
ただし、取引先が従来の通信手順でEDIをしていて、その切替に合わせて新しい方式への対応を依頼してくる場合は、間接的にこの期限の影響を受けます。
依頼の理由を取引先に聞くと、期限を調整できる余地があるかどうかも見えてきます。

注文データだけでなく、請求や出荷のデータも同時に始めるべきですか。

期限がある場合は、注文データから始め、出荷や請求は後から加える順が進めやすくなります。
データの種類が増えるほど、取引先と決める項目とテストする場面が増え、最初の稼働が遅れやすくなるためです。
注文のやり取りで自社と取引先の手順が固まれば、その経験を次のデータに生かせます。
取引先が最初から複数のデータを求めている場合は、その条件に合わせて範囲を決めます。

導入後に取引先を追加するときの手間は何で決まりますか。

追加する取引先が、既存の取引先と同じ標準・同じ項目・同じ通信方式を使うかどうかで大きく変わります。
同じであれば、作った設定や確認の手順を使い回せる部分が多くなります。
標準や項目が違えば、その差分の対応付けとテストが必要です。
自社システムとつないでいる場合は、新しい取引先のコードや品番の変換を追加する作業も加わります。

1. 1　出典：中小企業庁（ミラサポplus）「企業間のデータ連携で、受発注の業務コストを削減する！」（2020年）
2. 2　出典：日経クロステック（xTECH）「ISDN移行のハードルは業界によって様々、EDIなどは早期対応が必要」（2016年）
3. 3　出典：NTT東日本（フレッツ）「INSネットをご利用の事業者さまへ 固定電話のIP網移行」（2024年）
4. 4　出典：一般財団法人流通システム開発センター（GS1 Japan）「流通BMS」（2025年）