EDI導入の進め方｜六工程の手順と基幹システム連携・電子契約の使い分け

EDI導入でつまずく企業の多くは、製品を選ぶ工程から着手しています。取引先から指定される通信手順と伝票種別が決まらないうちに製品を決めると、契約後に対応外の様式が判明して連携開発をやり直す流れになります。この記事は、棚卸しから本稼働までの六工程と期間の目安、既存の基幹システムとつなぐEDI連携で決めるべきデータ変換と再送の設計、クラウドEDIを選ぶときに社内で先に確認する前提条件、そして電子契約との役割分担を、2026年8月時点の情報で整理した内容です。

まとめ：EDI導入の結論と製品選定より先に着手する順序

結論を先に示します。EDI導入は「製品選定」から始めず、「取引先の指定条件の棚卸し」から始めてください。取引先が指定する通信手順（EDIINT AS2・ebXML・全銀TCP/IPなど）と伝票種別、コード体系の3点が決まれば、候補製品は自動的に数社まで絞られます。ここが決まらないまま相見積りを取ると、各社の提案が別々の前提で作られ、金額を比べる意味がなくなります。

工程は6つに分かれ、小規模で3〜4か月、基幹システムとの自動連携を伴う中規模で6か月から1年が目安です。難所は製品の設定ではなく、取引先との接続テストと、自社の商品コードを取引先コードへ読み替えるデータ整備にあります。ここは業務部門の作業でベンダーの見積りに含まれないことが多く、社内工数として先に確保しておく必要があります。

着手時期にも期限があります。INSネットのディジタル通信モードは2024年1月から地域ごとに段階的な終了が進み、切替後のデータ通信（補完策）は2028年12月31日に提供終了が予定されています。レガシーEDIを使い続けている企業が要件定義から本稼働まで1年を見込むなら、着手の実質的な期限は2027年後半です。EDIそのものの仕組みと種類はEDIとは何かを整理した解説記事で確認できます。

EDI導入を決める前に確定させる取引先の指定条件と自社の適用範囲

EDIは自社だけで完結しない仕組みです。相手がいる以上、自社の希望より取引先の指定が優先されます。ここを飛ばした導入計画は、要件定義の途中で必ず作り直しになります。

取引先から指定される通信手順と伝票種別を先に書き出す棚卸しの手順

最初の作業は、主要取引先ごとに「どの手順で」「どの伝票を」やり取りしているかを一覧にすることです。列は、取引先名・現在の授受方法（FAX・メール・専用線・Web画面）・通信手順・伝票種別（注文・出荷・受領・請求）・月間件数・締め日の6つ。この表があれば、どの取引先を第一弾の対象にするかを件数順で決められます。

全取引先を一度にEDI化する計画は避けてください。件数上位2割の取引先で全伝票の8割を占める分布になっている企業が多く、上位数社だけを対象にしても効果の大半を回収できます。残りは紙やFAXのまま残し、第二弾で判断すれば十分です。

自社で自動化する業務範囲と手作業のまま残す範囲を線引きする基準

次に決めるのは自社側の適用範囲です。受注データの取り込みまでを自動化するのか、在庫引当や出荷指示まで連動させるのか、請求と入金消込まで含めるのかで、連携開発の規模が数倍変わります。

線引きの基準は、担当者が毎日繰り返している転記作業の件数です。月100件を超える転記は自動化の対象、月20件以下は当面手作業のままでも損失が小さい水準になります。中間帯は、締め日に作業が集中するかどうかで判断してください。集中するなら残業時間の削減効果が大きく、平準化しているなら後回しでも支障はありません。業務の流れそのものを確認する場合はEDI取引の流れを発注から支払まで追った記事が参考になります。

EDI導入の進め方を棚卸しから本稼働まで六つの工程で追う実務手順

工程を6つに分けて示します。期間は、取引先5社・伝票2種・基幹システムとの自動連携ありという中規模の案件を想定した目安です。

棚卸しと要件定義でコード体系の読み替え表を先に作る作業の中身

要件定義の実体は、伝票項目の対応表づくりです。取引先の注文データにある「品名コード」が自社の品番と一致することは、まずありません。読み替えテーブルを作る作業が必要で、これは開発ではなくデータ整備の仕事です。担うのは営業部門と生産管理部門になります。

商品点数が数千を超える企業では、この読み替え表の作成だけで1〜2か月かかります。ベンダーの見積書に含まれない場合が大半のため、社内の担当者と作業期間を先に確保しておいてください。ここが遅れると、後続の連携開発が着手できず全体が止まります。

製品選定と構築でベンダーへ渡す前提条件と社内試験の合格ラインの決め方

製品選定の工程では、棚卸し表と読み替え表の進捗をベンダーへ提示します。前提条件が揃った状態で相見積りを取ると、金額差が製品差なのか作業範囲の差なのか判別が可能です。候補を絞る段階の判断軸はEDIシステムを4タイプで比較した記事に整理してあり、金額の内訳と課金単位はEDIシステムの費用を分解した記事で検算できます。

構築の工程では、社内試験の合格ラインを先に文書化します。正常系のデータが流れるだけでは不十分で、確認すべきは異常系です。項目が欠けたデータを受け取ったとき、同じ注文が二重に届いたとき、締め処理中に受信したとき。この3つの挙動を試験項目に入れておかないと、本稼働後に伝票の欠落や重複計上が起きます。

接続テストと並行稼働で取引先の合意を取りながら切り替える段取り

接続テストは取引先1社ごとに発生し、テストデータの授受と項目突き合わせ、エラー時の再送確認で1社あたり2〜4日を見込みます。相手にも作業が発生するため、締め日や決算期を外した日程調整が必要です。取引先の担当者名と連絡経路を工程2の段階で押さえておくと、ここで滞りません。

並行稼働は1〜2か月が目安です。EDIで受けたデータと従来のFAXや電話で受けた内容を突き合わせ、差異がゼロになった時点で紙を止めます。差異が出た場合、原因の大半はコード読み替えの漏れか、単位（ケースとバラ）の解釈違いです。取引先との合意形成そのものの進め方は電子契約の導入手順を棚卸しから解説した記事と共通の型が使えます。

EDI連携とは何かを基幹システム側のデータ変換と再送設計で整理する

EDI連携とは、EDIサービスが受け取った取引データを自社の販売管理システムや生産管理システムへ渡し、自社が作った出荷データや請求データを取引先へ返す一連の橋渡しを指します。EDI製品を契約しただけでは、この橋渡しは動きません。総コストが膨らむのも、難所が残るのもここです。

ファイル連携とAPI連携とiPaaS経由で変わる連携方式の適性と限界

連携方式は大きく3つです。EDI側が出力したCSVを共有フォルダ経由で取り込むファイル連携、基幹システムのAPIへ直接投入するAPI連携、そして中間にiPaaSを挟む方式。ファイル連携は実装が軽い一方で、取り込み失敗の検知が遅れがちです。API連携はリアルタイム性と再送制御に優れますが、基幹システム側にAPIが無ければ開発が要ります。

iPaaS経由は、EDI以外の連携も同じ基盤に集約したい企業に向きます。接続先が増えるほど1本あたりの構築費は下がるものの、月額が接続数で増える設計が一般的です。方式ごとの技術的な違いはAPI連携とデータ連携の違いを解説した記事で確認できます。

データ変換とマスタ突合を誰が担うかで工数配分が変わる連携開発の設計

連携開発の中身は、変換処理とマスタ突合の2つに集約されます。受注データ1本の取り込みで、項目マッピング定義に2〜3人日、変換処理の実装に5〜8人日、エラー処理と再送設計に3〜5人日というのが一つの目安になります。伝票種別が増えれば本数分だけ積み上がる構造です。

誰が担うかで総額は変わります。EDIベンダーが基幹システム側まで請け負う形、基幹システムのベンダーが受け側を作る形、第三者が中間の連携部分だけを作る形の3通りがあり、既存システムの改修権限がどこにあるかで決まります。既存の基幹システムに手を入れずEDI連携だけを外付けしたい場合は、API開発・システム連携の相談窓口へ現行の構成と取引先の指定手順を提示したうえで方式の比較を依頼してください。

受信失敗と二重受信を想定した再送ルールと締め処理の設計上の論点

設計で落としやすいのが、異常時の扱いです。決めておく項目は4つあります。受信に失敗したデータをいつ誰が再取得するか、同一の注文番号を二重に受けたときどちらを採用するか、締め処理の実行中に届いたデータをどの日付で計上するか、そして取引先が送信を取り消したときの訂正伝票の扱い。

この4点を仕様書に書かないまま稼働すると、月次の締めで数字が合わない事態が起きます。原因の追跡には受信ログと基幹システムの登録ログの突き合わせが要り、調査だけで数日を溶かします。設計段階で30分議論すれば済む話です。

クラウドEDIで導入する場合に社内で先に確認する五つの前提条件

クラウドEDIは初期費用が軽く、サーバー調達も不要なため、新規導入の第一候補になります。ただし社内の条件によっては選べません。確認すべきは5点です。

取引先の指定手順とクラウド側の対応可否を突き合わせる確認の順序

第一に、取引先が指定する通信手順にサービスが対応しているかどうか。第二に、自社のセキュリティ基準が外部サービスへの取引データ保管を許すかどうか。この2点は他の条件より先に確認してください。どちらかが不可なら、クラウド以外の方式を検討する流れになります。

金融や医療の取引先を持つ企業では、データの国内保管やアクセス経路の限定を求められる場合があります。サービス提供者の公開資料で保管先リージョンと監査報告書の有無を確認し、情報システム部門の判断を工程2までに得ておくと後戻りを防げます。

基幹システムとの接続経路と権限をクラウド前提で見直す構成上の注意

残る3点は、基幹システムがオンプレミスに置かれている場合の接続経路、送受信データの保存期間と保存先、そして退職や異動に伴うアカウント権限の運用です。クラウドEDIから社内の基幹システムへデータを流すには、閉域接続かエージェント経由の中継が必要で、ここは情報システム部門の設計対象になります。

保存期間は、電子帳簿保存法の要件と自社の内部統制の両方で決まります。サービス側の標準保存期間が短い場合、自社側にデータを退避する仕組みを別途組み込むことになるため、要件定義で確定させておいてください。基幹システム全体の刷新と同時に進めるかどうかは基幹システムの構成と刷新の進め方を解説した記事で判断できます。

電子契約とEDIの役割の違いと電子帳簿保存法への対応を決める順序

「電子契約とEDIをどう使い分けるか」は、導入検討でよく出る論点です。両者は代替関係ではなく、扱う書類と目的が違います。混同したまま製品を選ぶと、契約書の締結に向かない仕組みで基本契約を回そうとして行き詰まります。

基本契約は電子契約・個別の受発注はEDIという役割分担の考え方

電子契約は、取引基本契約書や業務委託契約書といった「一度結べば長く効く文書」を、電子署名とタイムスタンプで締結し保管する仕組みです。対してEDIは、その基本契約のもとで日々発生する注文・出荷・請求のデータを、決められた様式で自動的に交換する仕組みになります。締結の証跡が要るのが前者、件数の多さと自動処理が要るのが後者という整理です。

実務では両方を使います。基本契約を電子契約サービスで締結し、個別の受発注をEDIで流す形が標準的な構成です。電子契約側の進め方は電子契約の導入手順と取引先合意の進め方をまとめた記事に譲り、本記事はEDI側の工程に絞ります。

電子取引データの保存要件をEDI側とシステム側のどちらで満たすかの判断

電子帳簿保存法では、EDIでやり取りした注文データや請求データは電子取引データに当たり、電子のまま保存する義務があります。判断が要るのは保存場所です。EDIサービス側の保存機能で要件を満たすのか、自社の文書管理システムへ退避して満たすのか、この二択を要件定義で決めます。

EDIサービス側で完結させると運用は軽くなる反面、契約を解約したときに過去データの取り出しが課題になります。解約後のデータ提供条件を契約書で確認しておいてください。保存要件の具体的な中身はEDI取引と電子帳簿保存法の対応手順を解説した記事で扱っています。

EDIを導入する条件と紙やFAXのまま見送ってよい場面の判断基準

最後に判断を言い切ります。すべての企業がEDIを導入すべきというわけではなく、規模と取引形態によっては見送りが合理的です。

EDI導入に踏み切る三つの条件と着手時期を決める逆算の実務目安

導入に踏み切る条件は3つです。第一に、主要取引先からEDIでの受発注を指定されている、または近く指定される見込みがあること。第二に、月間の伝票件数が100件を超え、転記作業が特定の担当者に固定されていること。第三に、レガシーEDIを使っており2028年12月31日の補完策終了までに移行が要ること。

いずれかに当てはまるなら、逆算して着手時期を決めます。中規模で6か月から1年、取引先が10社を超える案件では1年半を見込み、そこから補完策の終了予定日を引いた時点が着手の期限です。2026年8月の時点で残りは約2年4か月しかなく、要件定義に入る余裕があるのは2027年前半までと考えたほうが安全でしょう。

取引先が少数で件数も小さい企業がEDI導入を見送ってよい条件

見送りの条件も明示します。取引先が2社以下、いずれも自社向けのWeb EDI画面を無償で提供している、月間伝票が50件を下回る。この3つが揃うなら、EDIパッケージへ投資する判断は成り立ちません。削減できる転記工数が月数時間にとどまり、初期費用の回収に何年もかかるためです。

この状態で打つ手は、取引先の画面運用を続けながら、受け側の販売管理システムで入力を効率化することになります。取引先が5社を超えた時点、あるいは主要取引先が独自の通信手順を指定してきた時点で投資を検討すれば間に合います。画面運用を続ける負担の測り方はWeb EDIの多画面運用を扱った記事で確認してください。

基幹システムの刷新とEDI導入を同時に進めるか分けるかの判断

順序の判断も要ります。基幹システムの刷新を1年以内に予定しているなら、EDI導入は刷新後に回すのが原則です。刷新前の基幹システムに合わせて連携を作ると、刷新時に作り直しが発生し、連携開発費を二重に払うことになります。

例外は、取引先からの指定期限が刷新より先に来る場合です。この場合は、EDIサービス側でデータを受けて画面運用でしのぎ、刷新後に自動連携を作る二段構えを取ります。暫定期間の手作業を許容する判断を先に社内で共有しておくと、稼働直後の混乱を避けられます。

よくある質問

EDI導入について、検索でよく調べられている疑問に答えます。

EDI導入にはどれくらいの期間がかかりますか？

取引先5社・伝票2種で基幹システムとの自動連携を伴う場合、棚卸しから本稼働まで6か月から1年が目安です。画面運用のみで自動連携を作らない構成なら3〜4か月に短縮できます。期間を左右するのは製品の設定ではなく、コード読み替え表の整備と取引先ごとの接続テストの日程調整です。取引先が10社を超えると接続テストだけで数か月を要するため、対象を件数上位に絞って第一弾を回すほうが早く効果が出ます。

EDI連携とは何を指し、どこまでを開発するのですか？

EDI連携は、EDIサービスが受け取った取引データを自社の基幹システムへ渡し、出荷や請求のデータを取引先へ返す橋渡しを指します。開発の対象は、伝票項目のマッピング定義、データ変換処理、コード読み替え、そして受信失敗や二重受信に備えた再送制御の4つです。ファイル連携・API連携・iPaaS経由の3方式があり、基幹システム側にAPIがあるか、改修権限が自社にあるかで選べる方式が変わります。

クラウドEDIとオンプレミス型はどちらを選ぶべきですか？

取引先の指定手順にクラウド側が対応しており、外部サービスへの取引データ保管が自社の基準で許されるなら、クラウドEDIが第一候補になります。初期費用が軽く、通信手順の改定にもサービス側で追随してもらえるためです。データの国内保管やアクセス経路の限定を求められる取引がある場合、あるいは基幹システムが閉域網にありクラウドからの接続経路を確保できない場合は、オンプレミス型を検討します。

電子契約とEDIは同じサービスでまとめられますか？

まとめられる製品もありますが、役割が違うため無理に統合する必要はありません。電子契約は取引基本契約書のような文書を電子署名とタイムスタンプで締結し保管する仕組み、EDIは日々の注文や請求データを様式に沿って自動交換する仕組みです。基本契約は電子契約サービス、個別の受発注はEDIという役割分担が実務では扱いやすく、取引先が指定するサービスに合わせる形でも支障はありません。

EDI導入で社内に必要な体制はどの程度ですか？

最小構成は3役です。取引先との交渉と伝票様式の決定を担う業務部門の担当者、基幹システム側の接続経路と権限を設計する情報システム部門の担当者、そして進捗と予算を持つ責任者。社内に情報システム部門が無い企業では、2役目をベンダーへ委託する形になります。読み替え表の整備は業務部門の作業として残るため、専任でなくとも月に数十時間を確保できる体制が要ります。

関連記事

• EDIとは？電子データ交換の仕組み・種類と2024年問題後の移行判断を解説：導入を進める前に、EDIの種類と2024年問題の全体像を押さえられます
• EDIシステムの比較｜4タイプの対応業界・フォーマット・連携方式で選ぶ判断軸：工程3の製品選定で、候補を数社まで絞る判断軸を確認できます
• EDIシステムの費用｜初期費用と月額の相場・課金単位の内訳と見積りの読み方：相見積りを比べる段階で、金額の内訳と課金単位を検算できます
• EDI取引とは？発注から支払までの流れ・具体例と電子帳簿保存法の対応を解説：自動化の対象となる業務工程と保存義務の中身を把握できます
• Web EDIとは？仕組みとレガシーEDIとの違い・多画面運用の判断を解説：画面運用を続けるか自動連携へ投資するかの判断材料になります