BtoB ECと基幹システム連携｜方式の選び方と設計5段

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

B2B EC-COLUMN

BtoB ECの基幹システム連携とは、受注・在庫・出荷・請求のデータを両システム間で自動的に受け渡し、二重入力をなくす仕組み

BtoB ECの基幹システム連携は、方式（CSVかAPIか）から決めるのではなく、①データの洗い出し②向き③鮮度④方式⑤異常時運用、の5段で設計します。ZEDI^*2やJP PINT^*4など標準規格の活用範囲も、この段階で検討対象に含めます。

クラウド利用率80.6%の一方で、基幹連携の方式は後回しにされやすい

独立行政法人情報処理推進機構（IPA）は2025年6月26日、日本・米国・ドイツの3か国を比較した「DX動向2025」を公表しました^*7。副題は「「内向き・部分最適」から「外向き・全体最適」へ」であり、部門単位の効率化に閉じない情報基盤の見直しが論点として置かれています^*7。また総務省「令和7年版 情報通信白書」が掲載する「通信利用動向調査」では、クラウドサービスを「全社的に利用している」「一部の事業所または部門で利用している」と回答した企業は、2024年時点で合わせて80.6%でした^*8。ITインフラの見直しが進む一方で、基幹システムとBtoB ECの連携方式は、後回しにされがちな領域です。

加えて、レガシーEDIをISDN回線経由で運用している企業には、後述するとおり回線側の切替期限が迫っています。基幹連携の設計を先送りにできる期間は、今後さらに短くなっていくと考えられます。

本記事で使う3語 — マスタ・トランザクション・EDI

BtoB ECの基幹システム連携とは、通販サイトが受け付けた受注データや在庫・商品情報を、販売管理・会計などの基幹システムとの間で自動的にやり取りする仕組みを指します。担当者が同じ情報を両方のシステムへ手作業で入力する状態をなくすことが、その目的です。ここでいう基幹システムとは、受発注・在庫・会計など企業の中核業務を処理するシステムの総称です。

マスタとは、商品コードや取引先コードのように内容が頻繁には変わらない基礎データを指します。トランザクションとは、受注・出荷・請求のように日々発生する取引データを指します。EDI（Electronic Data Interchange、電子データ交換）とは、企業間の商取引データを電子的な形式でやり取りする仕組みの総称です。この3つの用語は、以降のセクションで繰り返し使います。

連携しない場合に残る作業と、連携が解くもの

基幹システムと連携していないECサイトでは、受注データをECの管理画面から確認し、基幹システムへ手入力で転記する作業が残ります。在庫数も、担当者が電話や口頭で在庫担当に確認してからECサイトへ反映する運用になりがちです。

連携を設計すると、受注データは基幹システムへ自動的に渡り、在庫データは基幹側からECサイトへ定期的に反映されます。転記の手間そのものより、転記ミスによる数量・単価の相違や、在庫のズレによる欠品・過剰在庫が減ることが、連携の実務的な効果です。

連携は導入のどの工程で決まるか

連携の設計は、BtoB EC導入の工程のうち、要件定義の後半から構築工程にかけて詰める部分にあたります。連携するデータの洗い出しと「正とするシステム」の合意は要件定義の段階で終えておき、方式の実装と異常時の運用設計を構築工程で確定させる、という分担が現実的です。本記事では、この連携そのものの設計に絞って解説します。

方式より先に「何を・どちらへ・どの鮮度で」を決める

連携設計で最初に詰めるべきは、方式ではなく「何のデータを、どちらの向きに、どの鮮度で流すか」です。この3点が固まって初めて、方式の選択肢を比較できる状態になります。

連携データは「向き・鮮度・正とするシステム・担当部門」の4欄で1行ずつ埋める

まず連携するデータを一覧化し、向き・鮮度・正とするシステム・担当部門を1行ずつ埋めます。下表は代表的なデータ項目の埋め方の例です。

マスタ系は基幹を正とし、基幹からECへ流す

商品・取引先・価格のマスタは、日々の変更頻度が低く、基幹システム側で一元管理されているのが一般的です。したがって基幹を正として、基幹からECへ流す向きが基本形になります。ECサイト側でマスタを直接編集できる状態にすると、基幹側との不整合が生まれやすくなります。

トランザクション系はECと基幹の間を交差する

受注・出荷・請求のようなトランザクションデータは、発生源が異なります。受注はECサイトで発生するためEC→基幹の向きになり、出荷・請求は基幹側の処理結果としてEC側へ戻す向きになります。1つの業務の中で向きが入れ替わる点が、マスタ系との違いです。

「正とするシステム」を決めないまま連携すると、どちらの数字も信用されなくなる

在庫数や取引先の与信枠のように両方のシステムで保持しうる項目では、どちらを正とするかの合意が出発点です。決めないまま連携すると、ECと基幹で数値が食い違ったときにどちらが正しいかを都度調べる作業が発生し、現場が数字を信用しなくなります。連携の品質は、方式の巧拙よりもこの1点の合意で決まる部分が大きいといえます。

連携方式の選び分け（CSV／API／EAI・iPaaS／データベース直結）

連携するデータの向きと鮮度が固まったら、初めて方式を選びます。鮮度の要求が方式選択の主な判断材料になります。

CSV・API・EAI／iPaaS・データベース直結の4方式を鮮度と運用負荷で比べる

鮮度の要求から方式が決まる

在庫数のように販売可否に直結するデータは、リアルタイムに近い鮮度が求められる場面が多く、API連携が候補になります。一方、請求データのように締め日単位で扱うデータは、日次のCSV連携でも実務上は足ります。鮮度の要求水準を先に言語化してから方式を選ぶことが、過剰な実装コストを避ける近道です。

基幹側をどこまで触るかが費用と期間を左右する

連携の実装期間・費用は、連携するデータの本数、基幹システム側の改修の有無、取引先の数によって変わります。一次情報で裏づけられる相場値は示せないため、本記事では金額ではなく「何が費用を動かすか」の判断軸に絞るのが方針です。基幹側にAPIが用意されていない場合、連携のためだけに基幹側の改修が発生し、費用と期間が読みにくくなる点は事前に認識しておく必要があります。

手作業を挟む方式を常用の連携に据えない理由

画面操作を自動的になぞる方式は、初期の実装が容易に見える一方、基幹システムの画面構成が変わると連携全体が止まるという弱点を抱えます。停止に気づく仕組みを別途用意しない限り、障害の発見が遅れるリスクがあるため、常用の連携方式としては推奨しません。

連携は5段で設計する

ここからは、冒頭で示した5段それぞれで何を決めるかを具体的に見ていきます。

第1段：連携データを洗い出す

H2-2の一覧表の要領で、連携するデータを列挙します。抜け漏れを防ぐには、受注から入金消込までの一連の業務フローを追いながら、各工程で発生するデータを1行ずつ書き出す方法が確実です。

第2段：項目・桁数・コード体系を突き合わせる

商品コードや取引先コードの桁数・体系がECと基幹で異なることは珍しくありません。この突合を後回しにすると、連携を開始してから片方のシステムがデータを読み込めない事態につながります。コード体系の差異は、連携設計の中でもっとも見落とされやすい箇所です。

第3段：方式と実行タイミングを決める

H2-3で選んだ方式について、実行する時刻・締めのタイミング・営業日の扱いを具体的に決めます。バッチ（一定間隔でまとめて処理する方式）を採用する場合は、処理にかかる時間が締め時刻に間に合うかどうかも合わせて確認します。

第4段：異常時を決める

連携が失敗したときの再送方法、同じデータを二重に処理しない仕組み（冪等性・重複防止）、エラーの通知先、縮退運用（一部機能を制限してでも業務を止めない運用）をあらかじめ決めておきます。この設計を後回しにすると、実際に障害が起きたときに現場が対応方法を持たない状態に陥ります。

第5段：テストデータと本番移行を決める

連携の最終段階では、テストデータの準備方法と本番移行の手順を固めます。取引先を巻き込んだ接続テストが必要になる場合は、取引先ごとに依頼する内容・テストデータの受け渡し方法・回答期限を先に決め、依頼から完了までの期間を移行スケジュールに織り込んでおきます。

自社の数字で連携設計の負荷を確かめるには、無料相談で要件を整理するのが近道です。

取引先とつなぐ側は「標準規格に載せるか」を先に決める

取引先企業とのデータ交換が絡む連携では、自社独自のフォーマットで組むか、業界標準に載せるかを先に判断する必要があります。

流通BMS（消費財流通業界のEDI標準仕様）

流通BMSとは、消費財流通業界の標準となることを目標に策定されている、メッセージ（電子取引文書）と通信プロトコル・セキュリティに関するEDI標準仕様です^*5。策定を進めているのは流通システム標準普及推進協議会（流通BMS協議会）で、「流通ビジネスメッセージ標準」および「流通BMS」は一般財団法人流通システム開発センター（GS1 Japan）の登録商標です^*5。主要な取引先がすでに流通BMSに対応している業界であれば、自社独自フォーマットより流通BMSに載せるほうが、将来的な接続先の追加が容易になります。

INSネットの終了は連携設計の期限になる

古いEDIをISDN回線（INSネット）経由で運用している場合、切替の期限として2028年12月31日が示されています。NTT東日本の公表によれば、INSネット関連サービスおよび移行期間中の補完策は、この日をもってすべて終了する予定とされています^*1。EDIが利用する「ディジタル通信モード」は、これに先立ち2024年1月より段階的に終了しています^*1。新規申込の受付自体も2024年8月31日に終了しました^*1。

これはNTT東日本の発表であり、全国一律の期限として断定はできません。ただし、ISDN回線を使ったレガシーEDIを温存したまま基幹連携の設計を進めると、標準規格への移行とISDNからの回線切替という2つの切替が別々の時期に発生しかねません。結果として生じるのは、同じ取引先に対する二度手間です。連携設計の初期段階で、自社の回線・EDI環境を棚卸ししておくことが望まれます。

自社独自フォーマットと標準の判断軸

取引先の数が少なく固定的であれば、自社独自フォーマットでも運用は成立します。一方、取引先の数が多い、または将来的に増える見込みがある場合は、標準規格に載せておくほうが取引先ごとの個別対応は少なくて済むはずです。相手方が標準規格にすでに対応しているかどうかも、判断材料になります。

受注で止めない — 請求・入金消込まで連携を通す

受注データの連携だけを整えても、請求・入金消込の作業が紙や手作業のままでは、業務全体の効率化効果は限定的です。ここでは受注の先にある請求・入金の標準規格を扱います。

デジタルインボイス（JP PINT）を請求データの受け渡しに載せる

JP PINTとは、国際標準仕様であるPeppol（ペポル）をベースにした、日本のデジタルインボイスの標準仕様です^*4。デジタル庁は2021年9月から、Japan Peppol Authority としてOpenPeppolのメンバー活動を行っています^*4。公表されている仕様は複数あり、Peppol BIS Standard Invoice JP PINT は Ver.1.1.3 が2026年6月8日に更新されました^*4。請求データをJP PINTの形式に載せることで、取引先との請求書の受け渡しを標準化できます。

ZEDI（全銀EDIシステム）で入金消込を自動化する

ZEDIとは、支払企業から受取企業へ総合振込する際に、支払通知番号・請求書番号などのEDI情報の添付を可能にするシステムです^*2。運営主体は一般社団法人全国銀行資金決済ネットワーク（全銀ネット）です^*3。支払企業側では、請求データが添付された総合振込の作成を自動化でき、受取企業側では、総合振込に添付された請求データをもとに入金消込作業を自動化できます^*2。

従来のフォーマットは固定長電文で20桁までという制限がありました^*3。ZEDIのXML電文はこの制約を受けず、請求書タイプコード・請求書番号・請求書発行日・請求金額（税込）などを添付できます^*3。振込に添付する金融EDI情報の内容は、事前に取引先企業と相談しておく必要があります^*3。

受注〜出荷〜請求〜入金の一気通貫

受注から出荷、請求、入金消込までを1本の線として設計すると、EC側の連携で解決できる範囲と、請求・入金側の標準規格で解決できる範囲が明確になります。受注だけを電子化して請求・入金を手作業のまま残すと、業務全体で見た効率化の効果は限定されます。

会計・債権管理側の担当部門を、連携の設計会議に最初から入れる

ZEDIによる入金消込の自動化を検討する場合、会計・債権管理の担当部門が持つ知見が必要になります。EC側・情報システム側だけで連携仕様を決めてしまうと、後工程で請求・入金側の要件が抜けていたことが判明し、設計をやり直す事態になりかねません。

連携の非機能要件 — 止まったとき・遅いときを先に決める

連携方式やデータ項目が決まっても、連携が止まったとき・遅いときにどう振る舞うかを決めていない状態では、設計は未完成です。

IPA「非機能要求グレード」を認識合わせの枠組みとして使う

非機能要求グレードとは、独立行政法人情報処理推進機構（IPA）が公開している、非機能要求についてのユーザーと開発者の認識のずれを防ぐための枠組みです^*6。非機能要求項目を網羅的にリストアップして分類し、それぞれの要求レベルを段階的に示したもので、樹系図は非機能要求項目を6つの大項目ごとに階層的に示しています^*6。利用手順は、開発システムに最も近いモデルシステムを1つ選び、樹系図で全体を俯瞰しながらグレード表で重要項目のレベル値を決め、残る項目を項目一覧で決める、の3段階です^*6。連携の可用性・性能・運用について、発注側と受注側の認識を合わせるためのたたき台として活用できます。

可用性：連携が止まった間の受注をどう受けるか

連携が一時的に止まっても、受注そのものを止めない設計が望まれます。ECサイト側で受注を受け付けたまま基幹への連携だけを遅延させ、復旧後にまとめて連携するという縮退運用を、あらかじめ決めておく必要があります。

性能：件数が増えたときのバッチ時間と締め時刻

取引先数や受注件数が増えると、バッチ処理にかかる時間も伸びます。締め時刻までに処理が終わらなければ、翌日の出荷・請求に影響します。件数の増加を見込んだ処理時間の余裕を、設計段階で確保しておくことが大切です。

運用：エラーの気づき方と再実行の権限

連携内製で運用する場合、コード体系の知識、EDI標準仕様の理解、障害時の切り分けができる人材が必要です。エラー通知の受け手が誰か、誰が再実行の権限を持つかを決めておかないと、障害発生時に対応が滞ります。自社に該当する知見が乏しい場合、設計段階から専門パートナーに相談することで、この種の判断の抜け漏れを減らせます。

連携でつまずく5つの箇所と、どの段で潰すか

連携の設計・実装でつまずきやすい箇所は、おおむね次の5つに集約されます。いずれもH2-4で示した5段のどこかで潰せる問題です。

マスタが整っていないまま連携を始めた

商品マスタや取引先マスタの整備が済んでいない状態で連携を始めると、連携そのものより前の段階でつまずきます。第1段・第2段でマスタの整備状況を確認しておく必要があります。

コード体系が両システムで違った

商品コード・取引先コードの桁数や体系がECと基幹で異なっていることに、連携開始後に気づくケースがあります。第2段の項目突合を丁寧に行うことで防げます。

「正とするシステム」を決めなかった

在庫数などをどちらのシステムが正とするか決めないまま連携すると、数値の食い違いが発生したときに原因の特定に時間がかかります。第1段のデータ洗い出しの段階で決めておく事項です。

異常時の設計を後回しにした

連携が止まったときの運用を決めないまま本番稼働すると、実際に障害が起きた際に現場が対応方法を持たない状態になります。第4段で設計しておく必要があります。

請求・入金を範囲から外した

受注・在庫の連携だけに範囲を絞り、請求・入金消込を対象から外すと、業務全体で見た効率化の効果が限定されます。H2-6で扱ったJP PINT・ZEDIの活用も含めて範囲を検討することが望まれます。

そのまま使える基幹連携チェックリスト

ここまでの内容を、段階別のチェックリストとしてまとめます。追加の検索をせずに、そのまま自社の連携設計に使える形にしています。

設計5段を10項目に落とした確認リスト

1. 連携するデータ（商品・取引先・価格・在庫・受注・出荷・請求）を一覧化したか
2. 各データについて、向き（EC→基幹／基幹→EC／双方向）と正とするシステムを決めたか
3. 各データの鮮度（リアルタイム・日次・都度・締め単位）の要求水準を言語化したか
4. 商品コード・取引先コードなど、項目の桁数とコード体系をECと基幹で突き合わせたか
5. 連携方式（CSV・API・EAI／iPaaS・データベース直結）を鮮度の要求から選んだか
6. 実行タイミング（バッチの時刻・締め・営業日の扱い）を決めたか
7. 連携が止まったときの縮退運用・再送・重複防止・通知先を決めたか
8. テストデータの準備方法と本番移行の手順を決めたか
9. 取引先との連携がある場合、標準規格（流通BMS等）に載せるかを判断したか
10. 請求・入金消込（JP PINT・ZEDI）を連携の対象範囲に含めるかを検討したか

ベンダーに連携仕様を依頼する前の最終確認

まとめ：基幹連携の成否は「どちらを正とするか」と「止まったときの決め」で決まる

本稿では、BtoB ECと基幹システムの連携を、方式論からではなくデータ設計から組み立てる考え方を整理しました。要点は3つです。第一に、連携するデータを洗い出し、向き・鮮度・正とするシステムを先に決めること。第二に、方式（CSV・API・EAI／iPaaS・データベース直結）は鮮度の要求から選び、異常時の運用まで含めて設計すること。第三に、受注・在庫だけで終わらせず、流通BMSやJP PINT、ZEDIといった標準規格を使って請求・入金消込までを連携の視野に入れることです。

着手の順序は、連携データ一覧の作成、「正とするシステム」の合意、鮮度の言語化、方式の選定、異常時の決め、の順です。最初の2つは自社の会議だけで進められます。ベンダーへ仕様を依頼する前に、この2つを終えておいてください。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

CSV連携とAPI連携は、どちらを選べばよいですか。

鮮度の要求水準と運用負荷で決めます。在庫のように販売可否に直結し鮮度が求められるデータはAPI連携が候補になり、請求のように締め単位で足りるデータはCSV連携でも実務上は成立します。データごとに鮮度を言語化したうえで方式を選ぶことが基本です。

基幹システムを改修せずにBtoB ECと連携できますか。

基幹システム側に外部から呼び出せるAPIやファイル出力・取込機能がすでに用意されている場合は、大きな改修なしで連携できる可能性があります。一方、そうした機能が無い場合は、連携のために基幹側の改修が発生し、費用・期間が読みにくくなる点に注意が必要です。

在庫はリアルタイムに反映すべきですか。

在庫データは販売可否に直結するため、リアルタイムに近い鮮度が求められる場面が多いといえます。ただし取引形態によっては日次反映でも実務上支障がない場合もあり、自社の受注パターンに応じて鮮度の要求水準を先に整理することが判断の出発点になります。

古いEDI（ISDN回線）を使っていますが、いつまでに切り替えが必要ですか。

NTT東日本の公表によれば、INSネットの「ディジタル通信モード」は2024年1月より段階的に終了しており、INSネット関連サービスおよび移行期間中の補完策は2028年12月31日をもってすべて終了する予定です^*1。これはNTT東日本の発表であり、自社が利用する回線・契約内容を確認したうえで移行時期を検討する必要があります。

連携が止まったとき、受注はどう受ければよいですか。

連携が止まっても受注の受け付け自体は継続し、基幹への連携だけを遅延させて復旧後にまとめて処理する縮退運用を、あらかじめ決めておくことが基本です。誰が異常に気づき、誰が再実行するかという運用の役割分担も、事前に決めておく必要があります。

1. *1　出典：東日本電信電話株式会社「ISDNサービス（INSネット）の提供が2028年12月にすべて終了。企業への影響とは」（https://business.ntt-east.co.jp/column/denwa/isdn.html）
2. *2　出典：一般社団法人全国銀行協会「ZEDI（全銀EDIシステム）」（https://www.zenginkyo.or.jp/abstract/efforts/smooth/xml/）
3. *3　出典：一般社団法人全国銀行資金決済ネットワーク「全銀EDIシステム（ZEDI）」（https://www.zengin-net.jp/zedi/）
4. *4　出典：デジタル庁「デジタルインボイス（電子インボイス）」（最終更新2026年6月8日、https://www.digital.go.jp/policies/electronic_invoice）
5. *5　出典：一般財団法人流通システム開発センター（GS1 Japan）「流通BMS」（https://www.gs1jp.org/ryutsu-bms/）
6. *6　出典：独立行政法人情報処理推進機構（IPA）「システム構築の上流工程強化（非機能要求グレード）」（https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html）
7. *7　出典：独立行政法人情報処理推進機構（IPA）「DX動向2025」日米独比較で探る成果創出の方向性（2025年6月26日、https://www.ipa.go.jp/digital/chousa/dx-trend/dx-trend-2025.html）
8. *8　出典：総務省「令和7年版 情報通信白書」（2025年7月、https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r07/html/nd111210.html）