iPaaSでEDI連携は可能か｜レガシーEDIから寄せる移行設計と役割分担の判断

iPaaSでEDIを置き換えたい、という相談で最初に確認するのは、取引先から指定されている通信手順です。ここがJCA手順や全銀TCP/IP手順であれば、iPaaS単体では受け口を作れません。この記事は、iPaaSがEDI連携のどの層を担えてどの層を担えないのかという境界線、国内EDIサービスを前段に置く分業構成の組み方、Web EDIの多画面運用をiPaaSへ巻き取れる条件、訂正伝票と締め処理を扱うときの設計論点、そして実行量課金のiPaaSに伝票を流したときに費用が跳ねる構造を、2026年8月時点の情報で整理した内容です。

まとめ：iPaaSでEDI連携を組む結論と担当範囲の線引き

結論から示します。iPaaSはEDIの通信層を置き換える製品ではありません。EDIの受け口（通信手順の終端とフォーマットの解読）は国内EDIサービスかEDIパッケージに任せ、その内側にある社内システムへの取り込み、コード読み替え、基幹システムへの反映をiPaaSが担う。この分業が国内企業にとっての現実解です。

理由は対応標準の偏りにあります。海外製iPaaSのB2B機能はASC X12とUN/EDIFACTを軸に設計されており、通信方式もAS2が中心です。国内の受発注EDIで指定されるJX手順や全銀TCP/IP手順は、これらの製品ドキュメントに標準対応として記載がありません。つまり「iPaaSでEDIに対応した」という海外の事例をそのまま国内の取引先に当てはめると、接続テストの段階で止まります。

移行期限も明確です。INSネットのディジタル通信モードは2024年1月から地域ごとに段階的な終了が進み、切替後のデータ通信（補完策）は2028年12月31日に提供終了が予定されています。レガシーEDIを補完策で延命している企業は、この日付から逆算して移行を組む必要があります。iPaaSの位置づけを含めた連携基盤そのものの考え方はiPaaSの仕組みとRPA・ETLとの違いを整理した解説記事で確認可能です。

iPaaS EDI連携の二つの構成とiPaaSが担える処理範囲の境界線

「iPaaSでEDI連携」と言うとき、実際には性質の違う二つの構成が混ざって語られています。取引先の接続条件によってどちらになるかが決まるため、先に切り分けます。

EDIゲートウェイの内側だけをiPaaSが担う分業型の基本構成

国内で最も多い形です。取引先との通信は既存のEDIサービスやEDIパッケージが終端し、受信した伝票データをファイルやAPIとして社内側へ渡します。iPaaSはそこから先を引き受けます。具体的には、受信ファイルの検知、固定長やCSVからJSONへの変換、取引先コードの読み替え、販売管理システムへの登録、登録結果の通知までです。

この構成の利点は、取引先ごとの通信条件がiPaaS側に一切漏れてこない点です。取引先が増えてもiPaaSのフローは変わらず、EDIサービス側で取引先を追加するだけで済みます。逆に言えば、EDIサービスの利用料はそのまま残ります。iPaaSを入れて削れるのは通信費ではなく、受信後の手作業と個別バッチの保守費です。

取引先がAPIを提供する場合にiPaaS単独で完結する適用条件

取引先が自社のECプラットフォームや購買システムのAPIを公開しているなら、EDIサービスを挟まずiPaaS単独で完結します。実際、Shopifyやkintone、Salesforceのように標準コネクタが用意されているサービス同士であれば、受注データの取得から基幹反映まで画面設定だけで組めます。

ただしこの形が成立するのは、取引先が少数で、かつ相手側がAPI提供に応じる立場にある場合に限られます。大手小売や自動車部品の一次取引では、様式と手順を指定するのは発注側です。受注側の都合でAPIに切り替えてもらえる交渉余地は、実務上ほとんどありません。自社が発注側で、相手がSaaSを使う中小事業者、という組み合わせのときにだけ検討してください。

iPaaSのB2B機能で通信まで担う統合型と国内運用での制約

一部のiPaaSはB2B/EDI機能を持ちます。Boomiの公式ドキュメントでは、Trading Partnerというコンポーネントで自社側と取引先側を対にして設定し、ASC X12・UN/EDIFACT・HL7・RosettaNet・TRADACOMS・ODETTEの各標準と、MDNによる電子受領確認を伴うAS2通信を扱えると記載されています。Workatoの場合はOrderfulとの提携でEDIコネクタを提供し、AS2・VAN・SFTP・APIのチャネルを取引先仕様に合わせて構成する形です。

並んでいる標準名を見ると、いずれも北米のB2B取引を前提にした構成であることが分かります。国内の流通・製造で指定されるJX手順や、金融向けの全銀TCP/IP手順は、これらの一覧に含まれません。国内取引先を持つ企業がこの統合型を選べるのは、海外拠点や海外サプライヤとの取引が主で、国内側はAPIかファイル授受で済んでいる場合に限られます。

レガシーEDIの通信手順にiPaaSが直接対応できない理由と代替経路

境界線が生まれる原因は、EDIの通信手順が単なるデータ転送ではなく、業務手続きを含んだ規約だからです。

JCA手順と全銀TCP/IP手順が標準コネクタに載らない構造

JCA手順は電話回線上で1バイトずつ制御コードをやり取りする同期通信で、全銀手順も同様に回線交換を前提に作られています。どちらもISDNのディジタル通信モードに依存してきた手順です。iPaaSのコネクタはHTTPやSFTP、データベース接続といった汎用のトランスポートを抽象化したものなので、モデムの制御やセッション確立の手続きを内側に持ちません。

全銀TCP/IP手順はIP網へ載せ替えた後継規約ですが、こちらもファイル転送の制御電文をやり取りする独自プロトコルで、汎用HTTPクライアントでは話せません。国内EDIベンダーが専用の通信ソフトウェアを製品化しているのは、この部分を作り込む必要があるためです。iPaaSの守備範囲外だと割り切るところから設計が始まります。

補完策の提供終了予定日から逆算するEDI基盤移行着手の実質期限

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

締め時刻に間に合わせるバッチを組んでいる企業では、この遅延がすでに実害として出ています。取引先との接続テストと並行稼働に半年、要件定義と開発に半年を見込むなら、着手の実質的な期限は2027年後半です。EDIそのものの種類と2024年問題の全体像はEDIの仕組みと種類を整理した解説記事にまとめています。

国内EDIサービスを前段に置いてiPaaSへつなぐ経路の作り方

分業型を組むときの接続点は、実務上ほぼ三択に収束します。EDIサービスが払い出すSFTP領域にファイルを置いてもらう、EDIサービスのWeb APIをiPaaSから呼ぶ、クラウドストレージ（Amazon S3やBoxなど）を共有領域として挟む、のいずれかです。

1. SFTP経由：ファイル名の規約と保管期間、取得済みファイルの移動先を先に決める
2. API経由：ページングの単位と取得済みマークの持ち方、レート制限の値を確認する
3. ストレージ経由：書き込み完了を判定する方法（一時拡張子やマーカーファイル）を決める

三択のうち、取りこぼしと二重取り込みが起きにくいのはAPI経由です。SFTPとストレージは、書き込み途中のファイルをiPaaSが拾ってしまう事故が起きます。EDIサービス側でAPIが選べるなら、多少の追加費用を払ってでもAPIにしてください。

Web EDIの多画面運用をiPaaSで巻き取る設計とRPAとの分担基準

受注側にとって切実なのは、取引先ごとに異なるWeb EDI画面へ毎日ログインして注文を拾う作業です。ここをiPaaSで減らせるかどうかは、画面の裏にAPIがあるかどうかで決まります。

手入力をiPaaSへ寄せられる条件と寄せられない条件の判断軸

寄せられるのは、そのWeb EDIがCSVダウンロードかAPIを提供している場合です。多くのクラウド型Web EDIは受注一覧のCSV出力を持っているので、出力先をSFTPやストレージに向けられればiPaaSの守備範囲に入ります。ダウンロードが画面操作でしか行えない場合、iPaaSのコネクタからは触れません。

取引先が3社までなら、画面運用を続けたほうが安上がりになる場面もあります。1社あたり1日15分の転記なら月におよそ15時間。iPaaSの月額と設計工数を回収するには足りない規模です。画面運用の負担をどう測るかはWeb EDIの仕組みと多画面運用の判断を扱った記事で整理しています。

画面しか無い取引先にRPAを併用するときの分担と保守負担の整理

CSVもAPIも無い取引先が残るなら、RPAで画面からダウンロードし、保存先をiPaaSに監視させる二段構えにします。RPAの担当範囲はログインとダウンロードまでに絞り、変換と基幹反映はiPaaS側へ寄せる。この線引きにしておくと、取引先が画面を改修したときの手直しがRPAのシナリオだけで済みます。

RPAを含む構成は保守が重くなります。画面改修の頻度は取引先次第で、年に数回の改修があるだけでシナリオの修正工数が積み上がります。RPAで賄う取引先は「取引額が大きく、当面API化の見込みが無い相手」に限定し、それ以外は取引先へ様式変更を打診するか、EDIサービス側の対応取引先一覧に載っているかを先に確認してください。

EDI固有のデータ変換をiPaaS上で作り込むときの設計論点

受け口が整った後にiPaaSで作り込む部分は、汎用のSaaS連携とは要求される厳密さが違います。伝票は金銭のやり取りに直結するため、取りこぼしも二重計上も許されません。

取引先コードと自社商品コードの読み替え表を運用上どこに置くか

取引先は自社の商品コードで発注してきます。これを自社の品番へ変換する読み替え表が必要で、置き場所は三つの候補があります。iPaaSのルックアップテーブル機能、基幹システムのマスタテーブル、スプレッドシートです。

推奨は基幹システム側です。読み替え表は業務部門が日々更新する台帳であり、商品の追加や廃番と同じ流れで管理されるべきものだからです。iPaaS側に持たせると、更新のたびに連携基盤の設定変更となり、業務部門が触れなくなります。スプレッドシートは初期の暫定手段としては機能しますが、行数が数千を超えると取得のたびに時間がかかり、締め時刻に響きます。

訂正伝票と取消伝票を扱うときの実務上の重複制御と冪等性の設計

EDIには、同じ発注番号で内容を差し替える訂正伝票と、発注そのものを取り消す取消伝票があります。iPaaSのフローを「受信したら登録する」とだけ組むと、訂正伝票が二重登録され、取消が無視されます。

設計としては、発注番号と伝票区分と改訂番号の組を一意キーとして扱い、登録処理を「同一キーがあれば上書き、無ければ新規」という形で組みます。iPaaSの標準コネクタが単純な新規登録しか持たない場合は、基幹システム側に登録用のAPIを1本用意して、その内側で判定させるほうが安全です。フロー側で分岐を作ると、リトライ時に分岐の途中から再開して不整合が残ります。

締め時刻に間に合わせる再送設計とエラー滞留時の扱い方と判断基準

発注の締め時刻は取引先の決定事項です。15時締めの取引先に対し、iPaaSのスケジュール実行が30分間隔で、失敗時のリトライが3回だとすると、最悪ケースで2時間近く遅延します。締め前の時間帯だけ実行間隔を詰める、リトライ間隔を指数的に広げずに固定する、といった調整を設計時に入れておきます。

もう一つ決めておくのは、リトライを使い切った伝票の行き先です。エラー通知をメールに流すだけの設計にすると、担当者が見落とした伝票が消えます。失敗した伝票を専用の保留領域へ退避し、翌朝の担当者チェックで必ず件数がゼロになる運用に落とし込んでください。設計と運用体制の組み立てまで含めて相談したい場合はiPaaS導入支援で対応しています。

実行量課金のiPaaSでEDI伝票を流すときに費用が膨らむ構造

見積り段階で見落とされやすいのが課金です。iPaaSの多くはタスク数やレコード数で課金するため、伝票の粒度がそのまま金額に跳ね返ります。

明細単位でフローを回すとタスク数が跳ねる課金構造の落とし穴と回避策

1件の発注に平均20明細が含まれるとします。明細ごとに商品マスタを引き、明細ごとに基幹へ登録するフローを組むと、発注1件あたり40回以上の処理が発生します。1日500件の受注なら月に約40万回。SaaS連携で想定される数千回とは桁が二つ違います。

表の数字は明細20行・稼働20日で置いた概算です。製品ごとに何を1タスクと数えるかは異なるため、契約前に自社の伝票件数と明細数を渡して見積りを取り直してください。製品別の課金単位の違いはiPaaS9製品の料金と課金単位を比べた記事で確認できます。

伝票をまとめて処理する設計へ切り替えるときの実務上の判断基準

まとめ処理に切り替える目安は、月間タスク数が契約プランの上限の6割を超えたときです。上限に張り付いてから設計変更を始めると、繁忙期に処理が止まります。切り替えの具体策は、明細のマスタ参照を1回のバルク取得に置き換える、基幹への登録を伝票単位のAPIにまとめる、の二つです。

まとめ処理には副作用があります。1伝票がエラーになったときに、同じ束の他の伝票まで巻き添えで止まる設計にしないこと。束の中で1件ずつ結果を返し、失敗分だけ保留領域へ落とす形にしておけば、まとめ処理と再送設計は両立します。

iPaaSにEDI連携を寄せる条件と受託開発へ切り替える分岐点

ここまでの制約を踏まえて、判断を言い切ります。

iPaaSへ寄せてよい三つの条件と想定される規模の目安と判断基準

次の三つがすべて揃うなら、iPaaSへ寄せてください。第一に、取引先との通信を終端するEDIサービスかWeb EDIがすでにあり、ファイルかAPIで社内へデータが渡ってくること。第二に、接続先の社内システムがクラウドかAPIを持っていること。第三に、伝票の月間処理量が契約プランの上限に対して余裕を持って収まること。

規模の目安は、取引先10〜50社、月間受注3千〜1万件あたりです。この範囲であれば、個別バッチを作り込むより設定変更で回せる利点が保守費の差として出ます。導入の工程そのものはEDI導入の六工程を整理した記事と同じ流れで進めれば足ります。

iPaaSを見送り受託開発かEDIパッケージへ寄せるべき場面

見送るべき場面は三つあります。取引先から全銀TCP/IP手順やJCA手順を直接指定され、間にEDIサービスを挟む予算が取れない場合。この条件では通信ソフトウェアの導入が先で、iPaaSの検討は順序が逆です。

接続先の基幹システムがオンプレミスのメインフレームやオフコンで、APIもファイル連携口も無い場合も見送りです。iPaaSから届かない以上、まず接続口を作る開発が必要になり、それはiPaaSの契約とは別の受託開発案件になります。

三つ目は、伝票量が月10万件を超え、かつ変換ロジックが取引先ごとに大きく異なる場合。この規模では実行量課金が専用サーバの構築費を上回り、フローの本数が増えてiPaaSの画面上で全体を追えなくなります。EDIパッケージか個別開発へ寄せたほうが、5年の総額でも運用の見通しでも有利です。

よくある質問

iPaaSとEDIの組み合わせについて、相談の場でよく出る質問をまとめます。

iPaaSだけでEDI連携を実現できますか？

取引先がAPIかCSV授受に対応している場合に限り実現できます。JX手順・全銀TCP/IP手順・JCA手順といった国内のEDI通信手順を指定されている場合は、iPaaS単体では受け口を作れません。国内EDIサービスかEDIパッケージで通信を終端し、その内側の変換と基幹反映をiPaaSが担う分業構成にしてください。海外製iPaaSのB2B機能はASC X12とUN/EDIFACT、通信はAS2が中心で、国内手順の記載はありません。

ZapierやMakeでEDI連携はできますか？

これらはSaaS間のAPI連携を主眼にした製品で、AS2やEDIFACTを扱う専用のB2B機能を標準では備えていません。取引先のWeb EDIがCSV出力かAPIを持っていて、それをストレージ経由で受け取れる構成であれば、変換と登録の部分は組めます。取引先ごとの変換が複雑になる、あるいは伝票量が月数万件を超える場合は、B2B機能を持つ製品か個別開発を検討してください。

iPaaSとEDIシステムはどちらを先に決めるべきですか？

EDIシステムが先です。取引先が指定する通信手順と伝票様式に対応できるかどうかで候補が絞られ、その結果として社内側へ渡ってくるデータの形式（ファイルかAPIか、どの粒度か）が決まります。iPaaSはその渡し口に合わせて選ぶ側なので、順序を逆にするとiPaaSの契約後に接続方式が合わないと判明します。

EDI連携をiPaaSに寄せると費用は下がりますか？

通信費は下がりません。下がるのは受信後の手作業と、個別バッチの保守費です。一方でiPaaSの月額と実行量課金が新たに発生します。1日500件・明細20行の受注を明細単位で処理すると月40万回規模の処理量になり、想定より上位プランが必要になる場合があります。伝票単位でまとめる設計にできるかを見積り前に確認してください。

2024年問題への対応はiPaaSで間に合いますか？

iPaaSは移行先の通信手段そのものではないため、これだけでは解決しません。INSネットの補完策は2028年12月31日に提供終了が予定されており、まず通信手順の移行先（全銀TCP/IP手順・JX手順・ebXML MS・AS2など）を取引先と合意する工程が先に来ます。iPaaSが効くのは、移行後に社内システムへ取り込む部分の作り込みを設定で済ませる場面です。

関連記事

• iPaaSとは？仕組み・RPAとの違い・主要ツールと導入判断をわかりやすく解説：iPaaSそのものの定義と、RPA・ETL・EAIとの違いを先に押さえられます
• EDIとは？電子データ交換の仕組み・種類と2024年問題後の移行判断を解説：EDIの種類と2024年問題の全体像を、移行判断の前提として確認できます
• EDIシステムの比較｜4タイプの対応業界・フォーマット・連携方式で選ぶ判断軸：分業型の前段に置くEDIサービスを選ぶ判断軸が分かります
• Web EDIとは？仕組みとレガシーEDIとの違い・多画面運用の判断を解説：画面運用を続けるか自動連携へ投資するかの分岐を測れます
• iPaaSとETLの違いを実装視点で判定｜連携方式5種の選定表と分岐条件：iPaaS以外の連携方式まで広げて比べたい場合の選定表です