EDIシステムの比較｜4タイプの対応業界・フォーマット・連携方式で選ぶ判断軸

EDIシステムの比較は、製品一覧を眺めるところからは始まりません。取引先から指定される通信手順と伝票の種類が決まった時点で、選べる候補は数分の一に絞られるからです。この記事では、比較の前に固定すべき条件、汎用型・業界特化型・クラウドEDI・自社開発という4タイプの適性と限界、JX手順や全銀TCP/IP手順といった通信手順とデータフォーマットの対応範囲、そして既存の基幹システムとどうつなぐかで総コストが変わる構造を順に整理します。EDIツールやEDIパッケージの選定で迷ったとき、どの順番で何を確かめれば結論が出るかがわかります。

まとめ：EDIシステム比較の結論と取引先条件から決める選定順序

結論は次のとおりです。EDIシステムの比較は「取引先の指定条件」「自社の業務範囲」「既存基幹との連携方式」の順に絞り込むと、候補が自然に数製品まで減ります。逆に機能一覧の比較表から入ると、対応していない通信手順が後から判明して選び直しになります。

タイプ別の適性は明確に分かれます。複数業界の取引先を抱えるなら汎用型EDIパッケージ、流通など業界標準規約が確立した領域なら業界特化型、接続先が十数社までで運用要員を置きにくいならクラウドEDI。取引社数が多く独自の商習慣を抱える企業だけが、自社開発と連携開発の投資に見合います。

見落とされやすいのは、製品費用より連携開発費のほうが大きくなる案件が珍しくない点です。金額の内訳と相場はEDIシステムの費用を初期費用・月額・従量の三層で整理した記事で確認できます。EDIが受け取ったデータは、そのままでは基幹システムに入りません。項目の対応づけと変換、エラー時の差戻し運用を誰が作るかを決めないまま製品だけ決めると、稼働は半年単位で遅れます。INSネット補完策の提供終了予定日は2028年12月31日。移行を控えた企業に残された検討期間は長くありません。

EDIシステムを比較する前に確定させる取引先の指定条件と自社の業務範囲

EDIは自社だけで完結しません。相手がいて初めて成立する以上、比較の自由度は最初から制限されています。

取引先から指定される通信手順・伝票種別・締め日を洗い出す確認項目

着手して最初にやることは、主要取引先ごとの指定条件の棚卸しです。確認する項目は決まっています。

• 通信手順（JCA手順、全銀TCP/IP手順、JX手順、ebXML MS、AS2 など）
• データフォーマット（固定長、CSV、XML、業界標準の項目定義）
• やり取りする伝票の種類（発注、出荷、受領、返品、請求、支払）
• データの送受信タイミングと締め日、再送のルール
• 接続テストの実施主体と、テスト環境を相手が提供するか

この5項目を取引先20社ぶん並べると、対応が必要な通信手順は多くの場合2〜4種類に収束します。1社だけ特殊な手順を要求している場合は、その1社のためにEDIシステム全体を選んでよいかを先に検討してください。取引金額が全体の数%の相手に合わせた選定は、後で必ず問題になります。

受注側と発注側で変わる比較の重心と多画面運用が生む工数の見積り

自社が受注側か発注側かによって、比較の重心は正反対です。発注側は自社の運用ルールを取引先に指定できる立場にあるため、社内の購買業務にどれだけ合うかを軸に選べます。受注側は違います。得意先ごとに異なるWeb EDIの画面へログインし、注文データを手作業で拾う運用が積み上がりやすい立場です。

この差は工数の形で表れます。得意先が15社あり、それぞれ別のWeb EDI画面から1日30分ずつデータを取得しているなら、月あたりおよそ150時間が画面操作に消えます。EDIシステムの比較で受注側が見るべきは機能の多さではなく、この画面運用をどこまで自動のデータ取り込みに置き換えられるかです。画面運用そのものの実務はWeb EDIの仕組みとレガシーEDIとの違いで詳しく整理しています。

既存の受発注業務のうちEDI化する範囲と紙のまま残す範囲の線引き

全取引をEDIに載せる必要はありません。流通BMSが標準メッセージを規定する6業務のうち、実際に電子化するのは発注と出荷だけ、というケースは実務でよくあります。請求と支払は既存の会計フローに残す判断です。

線引きの基準は取引の反復性です。月に数回しか発生しない取引や、都度仕様が変わる個別受注品は、EDI化しても項目定義の保守コストのほうが上回ります。同じ商品コードで毎日発注が飛ぶ定番取引なら効果が出る。この範囲を先に決めないと、比較の段階で「その業務に対応していますか」という質問が発散し、機能が多い製品ほど良く見える歪みが生じます。EDIそのものの定義や種類から確認したい場合は、EDIの仕組みと2024年問題後の移行判断を先に読むと前提が揃います。

汎用型・業界特化型・クラウドEDI・自社開発の四タイプ別の適性と限界

市場にあるEDIの選択肢は、機能の細部を見る前に4つのタイプへ分けられます。

汎用型EDIパッケージが向く複数業界との取引と運用要員の前提条件

汎用型は、業界を問わず多様な通信手順とフォーマットに対応する製品群です。自社サーバーまたはクラウド上に構築し、変換定義を自社で作り込みます。取引先が製造・流通・金融と業界をまたぐ企業に向きます。

前提条件は、変換定義とジョブ設計を維持できる担当者を社内に置けるかどうかです。汎用型は自由度が高いぶん、設定が属人化しやすい性質を持ちます。担当者の異動後に誰も変換定義を触れなくなり、取引先の項目変更へ追随できなくなる。これが汎用型で最も多い失敗の形です。導入時に運用手順書とテスト手順を成果物として要求しておけば避けられます。

業界特化型が持つ流通BMSなど標準規約への追随と適用範囲の狭さ

業界特化型は、特定業界の標準規約に沿った項目定義とメッセージをあらかじめ実装した製品です。流通業界であれば流通BMSが該当します。流通BMSは一般財団法人流通システム開発センターの流通BMS協議会が策定した標準で、基本形Ver.1.0が2007年4月に公開され、発注・出荷・受領・返品・請求・支払の6業務8種の標準メッセージを規定しています。基本形は2.0系（2018年11月公開）が最新です。

強みは規約改訂への追随を製品側が担う点にあります。項目が追加されたときにベンダーが対応版を出すため、自社で仕様書を読み込む必要がありません。限界は範囲の狭さです。流通以外の業界の取引先が増えたとき、同じ製品では対応できず、二重にEDIを持つ結果になります。将来の取引先構成を3年程度の視野で見積もったうえで選びます。

クラウドEDIで短縮できる構築期間と利用形態に伴う制約の見極め

クラウドEDIはサービス提供者の基盤上でEDI機能を利用する形態です。サーバー調達と証明書管理をベンダーに預けられるため、構築期間が数週間単位まで縮みます。接続先が十数社までで、社内に専任のインフラ担当を置きにくい中堅企業に向きます。

制約は3つの形で現れます。1つ目は変換定義の自由度で、標準パターンから外れる要件は追加開発扱いです。2つ目は課金単位。接続先社数に応じた課金、通信量に応じた課金、固定の月額と製品ごとに考え方が違い、取引先が増えたときの費用の伸び方が変わります。3つ目はデータ保持期間で、参照可能期間がサービス規定で決まっている場合、電子帳簿保存法の保存期間との整合を自社側で確保する必要があります。

自社開発を選ぶ判断が成立する取引社数・独自要件・内製体制の水準

自社開発は例外的な選択肢です。パッケージが対応しない独自の商習慣があり、かつ取引量がその開発投資を回収できる規模に達している場合に限って成立します。

4タイプの適性を整理すると次のようになります。

取引社数が数十社に満たず独自要件も薄いのに自社開発を検討しているなら、その判断は見直しの対象です。汎用型パッケージの変換定義で吸収できる範囲を先に確認してください。

通信プロトコルとデータフォーマットの対応範囲で製品を絞り込む手順

タイプが決まったら、次は機械的な絞り込みです。ここは判断ではなく照合の作業になります。

JX手順・全銀TCP/IP手順・AS2など通信手順の対応表で候補を削る手順

通信手順は制定年代によって前提とする回線が違います。JCA手順は1980年制定で公衆回線を前提とし、全銀手順は1983年制定です。インターネット回線を前提とする手順はこれより新しく、用途も分かれます。

取引先の指定手順とこの表を突き合わせ、1つでも欠ける製品は候補から外します。手順は追加開発で埋められる項目ではありません。ここで残った製品だけを、次のフォーマット照合に進めます。

固定長・CSV・XMLの変換要件とマスタ不一致で起きる差戻しの実務

フォーマット変換は、対応表を作れば終わる作業に見えて、実際にはマスタの不一致で止まります。取引先の商品コードと自社の商品コードが1対1で対応していない場合、変換テーブルの保守が恒常的な運用業務として残るためです。

比較の場面で確認すべきは、変換エラーが起きたときの挙動です。エラーデータを保留して担当者に通知するのか、無条件で受信を止めるのか、部分的に取り込んで残りを差し戻すのか。挙動は製品ごとに違い、これが日々の運用負荷を決めます。デモでは正常系ではなく、コード未登録の明細を混ぜたデータを流してもらうと差が見えます。

全銀EDIシステムのXML電文で広がる支払消込の情報量と適用外業務

入金消込の自動化を狙うなら、全銀EDIシステム（ZEDI）への対応も比較軸に入ります。ZEDIは2018年12月25日に稼働し、総合振込の電文に添付するEDI情報をXML形式にする仕組みです。従来の固定長電文ではEDI情報欄が20桁に制限され、請求書番号を複数入れることができませんでした。XML形式ではこの制限がなくなります。

ただし適用範囲は総合振込を中心とした業務に限られ、すべての資金移動が対象になるわけではありません。EDIシステム側がZEDIのXML電文を生成・解釈できるか、そして取引銀行が対応しているかの両方を確認します。片方だけでは消込の自動化には届きません。

既存基幹システムとの連携方式がEDI導入の総コストを左右する構造

ここが本記事の核心です。製品カタログの比較では見えない部分に、費用の大半が潜んでいます。

ファイル連携・API連携・iPaaS経由で変わる開発工数と保守責任の所在

EDIが受信したデータを基幹システムに渡す方法は3通りに整理できます。指定フォルダにCSVを置いて基幹側が定時に取り込むファイル連携、基幹システムのAPIを呼び出して即時に登録するAPI連携、そして両者の間に連携基盤を挟むiPaaS経由の連携です。

ファイル連携は初期構築が軽い一方、取り込み失敗を検知するまでの遅れが弱点です。夜間バッチの失敗に翌朝気づく運用は、受注業務では致命的になり得ます。API連携なら即時性と失敗時の応答が得られるものの、基幹システム側にAPIがなければその開発から始まります。古いオンプレミスの基幹システムでは、この前提が満たされないほうが多いのが実情です。

基幹システム側の受注データ項目とEDI標準項目の対応づけ作業の重さ

項目の対応づけ、いわゆるマッピングは、量が読みにくい作業です。発注データ1件でも、ヘッダとして取引先コード・発注番号・納品日・納品場所、明細として商品コード・数量・単価・単位と、実務では50〜100項目に及びます。

作業が重くなるのは、対応しない項目が出たときです。取引先が送る「納品場所コード」が自社の出荷倉庫マスタに存在しない、といった不一致が必ず残ります。解決には業務側の判断が要り、システム部門だけでは決まりません。比較の段階でベンダーに聞くべきは「マッピングに何人日かかりますか」ではなく「対応しない項目が出たとき、誰がどう決めますか」です。

連携部分を作り込む場合の見積り根拠となる要件定義と依頼時の資料

連携部分を外部に依頼する場合、見積りの精度は渡す資料で決まります。取引先ごとの通信手順一覧、伝票種別と項目定義書、基幹システムのテーブル定義とAPI仕様、現行の運用フローと担当者。この4点が揃っていれば、工数の見積りは現実的な幅に収まります。揃っていないまま相見積りを取ると、各社が別々の前提を置くため、金額を比べても意味のある差が読み取れません。

EDIと基幹システムの間をどうつなぐかを具体的に詰める段階では、API開発・システム連携の相談窓口で、既存システムの構成を前提にした連携方式と工数の当たりを取ることができます。パッケージ選定と連携設計は本来同時に進める作業で、製品を決めてから連携を考える順序にすると、選んだ製品では実現できない要件が後から出てきます。

電子帳簿保存法とINSネット補完策終了への対応可否を確かめる観点

制度対応は、EDIシステムの比較で最後に確認して間に合う項目ではありません。候補製品が制度要件を満たさないと判明した時点で、選定はやり直しになります。

電子取引データの保存義務とEDIシステム側で満たす検索要件の確認

EDIでやり取りする受発注データは、税務上の電子取引に該当します。国税庁は電子取引の保存にあたり、改ざん防止のための措置、「日付・金額・取引先」での検索、ディスプレイやプリンタ等の備付けを求めています（一問一答【電子取引関係】令和7年6月版）。

EDIシステムを比較する際は、この3要件のうちどこまでを製品が担い、どこからを自社の文書管理側で担保するかを切り分けます。送受信ログは残るが「金額」での検索ができない、という製品は実務で珍しくありません。その場合は基幹システム側または文書管理システム側で検索要件を満たす設計にします。保存義務の詳細と対応手順はEDI取引の流れと電子帳簿保存法の対応で整理しています。

INSネット補完策の2028年12月31日終了に間に合わせる移行工程

NTT東日本・NTT西日本の案内によれば、INSネットの「ディジタル通信モード」は2024年1月から地域ごとに段階的に終了しており、切替後のデータ通信（補完策）の提供終了予定日は2028年12月31日です。補完策では従来より伝送遅延が生じ、処理時間が増大する場合があるとも案内されています。

JCA手順などINS回線に依存した接続が残っている場合、逆算した工程はこうなります。

1. 取引先ごとの現行接続方式と移行後の希望手順を確認する
2. EDIシステムの候補を通信手順の対応範囲で絞り込む
3. 取引先と接続テストの日程を調整する（相手都合で数か月ずれる）
4. 並行稼働期間を設け、旧方式と新方式の受信データを突合する
5. 取引先ごとに順次切り替え、最後に旧接続を停止する

読み違えやすいのは3番です。接続テストは相手の要員を拘束するため、自社の都合だけでは進みません。取引先が20社あるなら、テスト調整だけで半年を見込んで計画してください。

EDIシステムを比較して選ぶ条件とパッケージを見送るべき場面の判断

ここまでの整理を、実際の判断に落とします。玉虫色の結論は置きません。

取引社数と伝票枚数で決まるパッケージ導入の損益分岐と判断の順序

判断の順序は決まっています。取引先の指定手順で候補を削り、タイプを決め、連携方式の工数を見積もり、そのうえで費用を比べる。この順序を守れば、比較は2〜3社の相見積りで終わります。選定を含む導入全体の工程と期間の目安はEDI導入の進め方を六工程で整理した記事で確認できます。

損益分岐の目安は、EDI化する伝票の枚数と、それに費やす人手の時間です。月に受発注伝票が2,000枚を超え、その入力と照合に月100時間以上かかっているなら、パッケージ導入の投資は回収の見込みが立ちます。月200枚程度で担当者が片手間に処理できている規模なら、新規導入は時期尚早。取引先が指定するWeb EDI画面を使い続けるほうが合理的です。

EDIパッケージを見送って既存の受発注システム拡張で足りる条件

次の条件がすべて当てはまるなら、EDIパッケージを見送ります。取引先が指定する通信手順が1種類だけで、接続先が5社以内、伝票の種類が発注と出荷に限られ、既存の受発注システムまたは販売管理システムにCSV取込の口がある場合です。この構成なら、既存システム側にファイル取込と変換の機能を追加するほうが、EDIパッケージの年間費用と運用要員を抱えるより負担が軽くなります。

逆に、通信手順が3種類以上に分かれる、あるいは取引先が今後2年で倍増する見込みがあるなら、この判断は成り立ちません。個別対応の積み増しで対応した結果、誰も全体像を把握できない状態になります。受発注の仕組みそのものを見直す段階なら、受注管理システムのタイプ別比較と判断基準もあわせて確認すると、EDI単体で解くべき範囲が見えます。

比較検討の段階で確かめる試験環境・並行稼働期間・保守窓口の条件

最後に、契約前に確認しておく運用条件を挙げます。試験環境が本番と同等の通信手順で使えるか。並行稼働期間中、旧方式と新方式の二重運用に追加費用が発生するか。障害時の一次受付が何時から何時までで、取引先との調整を誰が担うか。

特に3つ目を軽視すると稼働後に苦労します。EDIの障害は自社と取引先のどちらに原因があるかの切り分けが要り、ベンダー窓口が「自社側のログには異常なし」で止まる契約だと、業務担当者が取引先のシステム部門と直接やり取りする状態に陥ります。切り分け支援の範囲を契約書レベルで確認してください。

よくある質問

EDIシステムの比較でよく寄せられる質問に、判断の材料となる形で答えます。

EDIツールとEDIパッケージとEDIサービスは何が違いますか？

呼び分けの実態は提供形態の違いです。EDIパッケージは自社のサーバーやクラウド環境に導入して自社で運用するソフトウェア、EDIサービスはベンダーの基盤上で機能を利用する形態を指すことが多く、EDIツールは両者を含む総称として使われます。比較の場面では名称ではなく、変換定義を誰が保守するか、サーバーとネットワークの責任範囲がどこで分かれるかを確認してください。同じ製品名でオンプレミス版とクラウド版の両方を持つベンダーもあり、名称だけでは形態が判別できません。

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

社内にインフラ運用の要員を置けるかで分かれます。証明書の更新、OSのパッチ適用、通信障害の一次切り分けを担当できる体制があるならオンプレミス型が候補に入り、変換定義の自由度という利点も得られる。この体制がなければクラウドEDIを選び、運用をベンダーに預けたほうが総コストは下がります。取引先が特定業界に限られ標準的な変換で足りるなら、オンプレミス型を選ぶ理由は薄くなります。

EDIシステムの比較で見積りを取るとき何社に依頼すべきですか？

通信手順とフォーマットの照合で候補を絞ったあと、2〜3社が現実的な数です。5社以上に依頼すると、各社への要件説明と回答内容の読み解きに時間がかかり、判断が遅れます。依頼時は本文で挙げた4点の資料を同じ内容で全社に渡してください。前提を揃えないと、金額差が要件の解釈違いなのか実力差なのかを判別できません。

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

クラウドEDIで標準的な変換に収まる場合は、契約から数週間で最初の取引先と接続できます。一方、基幹システムとの連携開発を伴う場合は要件定義から稼働まで6か月前後、取引先20社との接続テストを含めると1年近くを見込みます。期間を左右するのは製品の導入作業ではなく、取引先との日程調整と、マッピングで生じた項目不一致の業務判断です。INSネット補完策の終了を控えて移行を検討しているなら、この調整期間を織り込んで逆算してください。

既存の販売管理システムにEDI機能があれば別製品は不要ですか？

取引先が指定する通信手順をその機能が満たしているかで決まります。販売管理システムに付属するEDI機能は、対応する通信手順とフォーマットが限定的な場合があり、たとえばJX手順のみ対応で全銀TCP/IP手順には対応しない、といった制約が実務では見られます。取引先の指定条件を先に洗い出し、付属機能の対応範囲と突き合わせてください。すべて満たすなら別製品は不要で、1つでも欠けるなら、その取引先だけ別手段を用意するか専用製品を検討する判断になります。

関連記事

• EDIとは？電子データ交換の仕組み・種類と2024年問題後の移行判断：EDIの定義・種類・2024年問題の全体像を先に押さえたい方向けの基礎記事です。
• Web EDIとは？仕組みとレガシーEDIとの違い・多画面運用の判断：受注側の多画面運用をどこまで自動化するかを検討する際に読む記事です。
• 基幹システムとは？業務システム・ERPとの違いと構成領域・刷新の進め方：EDIの接続先となる基幹システムの構成と刷新の考え方を整理しています。
• API連携とは？仕組み・データ連携との違い・導入判断：EDIと基幹システムをAPIでつなぐ方式を検討する際の前提知識です。
• iPaaSの比較9製品｜料金と課金単位・接続数で選ぶ判断軸：連携基盤を挟む方式を選ぶ場合の製品比較として参照できます。