受注管理システムの連携とは？方式4種と設計要件を解説

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

B2B EC-COLUMN

受注管理システムの連携とは何か ― 二重入力と転記ミスをなくす仕組み

受注管理システムの連携とは、電話・FAX・メール・EC・EDIから入った注文データを、周辺システムへ自動的に受け渡す仕組みです。渡す先は、販売管理や在庫・倉庫、会計・請求などです。老朽化した通信回線であるINSネットは2028年12月31日に提供を終了するため^*1、これを機に連携の設計を見直す動きが続いています。

連携が解決する3つの状態

受注管理システムの連携が目指すのは、同じ注文を複数のシステムへ入力し直す二重入力をなくすことです。あわせて、手入力に伴う転記ミスを減らし、在庫の引当や出荷指示に反映されるまでの時間差を縮めることも目的になります。

連携を設計するとは、どのデータを・いつ・どの粒度で渡し、失敗したときにどう戻すかを決める作業です。

「受注管理」「注文管理」「販売管理」の言葉の重なり

「受注管理」「注文管理」は受付から出荷指示まで、「販売管理」は売上・請求まで含む場合があります。呼び方は提供事業者で幅があるため、名称よりも扱う業務範囲で確認するのが実務的です。

受注管理システムは何とつながるか ― 連携先5種と渡すデータ

受注管理システムの連携先は、販売管理・基幹、在庫・倉庫、会計・請求、取引先との受発注、ECサイト・モールの5種類です。渡すデータと求められる同期の速さは、連携先ごとに異なります。

販売管理・基幹 ― 受注確定データと売上計上

受注が確定した時点のデータを販売管理・基幹システムへ渡し、売上計上や請求処理につなげます。方式4分類の詳細は基幹システムとの連携方式をご参照ください。渡す粒度がずれると、後工程の請求金額が合わなくなる原因になります。

在庫・倉庫（WMS）― 引当と出荷指示、実在庫の戻し

受注データは在庫の引当と出荷指示のために倉庫管理システム（WMS）へ渡され、出荷完了後は実在庫の数量が受注管理システム側へ戻ります。倉庫連携の詳細はBtoB ECの倉庫・WMS連携、在庫のリアルタイム性はBtoB ECの在庫連携とリアルタイムの要否をご参照ください。この往復が遅れると、売り越しや欠品の見落としにつながります。

会計・請求 ― 締めと請求データ、入金消込

締め処理で確定した受注データは請求データとなり、入金消込にも使われます。振込通知に添付できるEDI情報は、従来は固定長20桁までの制限がありました^*3。全銀EDIシステム（ZEDI、銀行間の振込情報を電子的にやり取りする仕組み）の利用によりXML形式となり、従来より多くの情報を添付できます^*3。

取引先との受発注（EDI・Web-EDI）― 取引先側のフォーマットに合わせる負担

EDI（企業間で受発注データを電子的にやり取りする仕組み）やWeb-EDIでは、取引先ごとにフォーマットが異なることがあります。個別対応が積み重なるほど、運用の負担が増えます。使い分けの詳細はEDIとBtoB ECの違い・使い分けをご覧ください。

ECサイト・モール ― 注文取込のチャネル

自社ECサイトやモールで受けた注文も、受注管理システムへの取込チャネルの1つです。チャネルが増えるほど、受注管理システム側での一元管理の必要性が高まります。

【表】連携先別・渡すデータと同期タイミングの目安

向く同期頻度は業務要件で決まるため、以下は目安として参照してください。

連携方式は4種 ― ファイル・DB直結・API・EDI標準の使い分け

受注管理システムの連携方式は、大きくファイル連携・データベース直接連携・API連携・EDI連携の4種類に分かれます。どれか1つに決め打ちするのではなく、業務ごとに使い分けるのが実務的な考え方です。

ファイル連携（CSV・バッチ）― 大量処理に強く、締め処理と相性がよい

CSV等のファイルを定期的に受け渡す方式です。大量データの一括処理に向き、締め処理のようにタイミングが決まっている業務と相性がよい一方、即時性には向きません。項目設計の手順は通販の受注データをCSVで連携する方法で解説しています。

データベース直接連携 ― 速いが結合が強く、片側の改修に巻き込まれる

データベース同士を直接つなぐ方式は処理が速い半面、片方のシステムを改修すると、もう一方の連携部分にも影響が及びやすくなります。改修のたびに双方の担当者が確認する体制が必要です。

API連携 ― リアルタイム性と疎結合

API（システム同士が機能やデータをやり取りするための接続仕様）を使う方式は、即時性が求められる業務に向きます。在庫引当のような即時処理が必要な場面で使われ、システム同士の結合が緩やかなため片方の改修が他方に及ぼす影響を抑えやすくなります。設計の注意点はBtoB EC API連携の設計と注意点をご覧ください。

EDI連携 ― 取引先とつなぐ。標準仕様に寄せるか個別対応かの分岐

取引先とのEDI連携では、業界標準の仕様に寄せるか、取引先ごとの個別フォーマットに対応するかが分かれ道になります。取引先数が増えるほど、標準に寄せたほうが運用コストを抑えやすくなります。

【比較表】4方式の比較

選び方の判断軸 ― 全部をリアルタイムにしない

連携設計で大切なのは、すべての業務をリアルタイム化することではありません。即時性が要る在庫引当だけAPI連携で切り分け、タイミングが決まっている締め・請求はファイル連携にとどめる組み合わせが現実的です。

設計要件①：標準仕様に寄せられるか ― 流通BMS・ZEDI・JP PINT

連携方式を決めたあとは、業界の標準仕様に寄せられるかを検討します。標準仕様は、個別対応を減らすための公的な受け皿として整備されています。

消費財流通の標準＝流通BMS

流通BMS（流通ビジネスメッセージ標準）は、消費財流通業界の標準となることを目標に策定されているEDI標準仕様です^*2。メッセージ（電子取引文書）と通信プロトコル・セキュリティの両方を対象としています^*2。最新の基本形はVer2.2.2（訂正版）で、2025年7月15日に公開されています^*2。

請求・入金の標準＝ZEDI

請求・入金の情報については、前章で触れた全銀EDIシステム（ZEDI）がXML形式による標準的な受け皿になります^*3。従来の固定長20桁という制限を超えて、詳細な取引情報を添付できる点が特徴です^*3。

デジタルインボイスの標準＝JP PINT

デジタル庁は、国際的な電子インボイスの標準であるPeppolの日本における管理主体（Japan Peppol Authority）です^*4。この立場からJP PINTというデジタルインボイスの仕様を管理し、2021年9月からOpenPeppolのメンバーとして活動しています^*4。

標準に寄せる判断 ― 取引先数が多いほど個別対応の運用コストが効いてくる

標準仕様に寄せるか個別対応を続けるかは、取引先数と将来の増減で判断が変わります。取引先が少なければ個別対応でも回りますが、多い、または増える見込みがあるなら標準仕様への統一を検討する価値があります。

設計要件②：電子帳簿保存法が求める受注データの保存

受注データを電子的に授受した時点で、電子帳簿保存法上の「電子取引」に該当する場合があります。該当する場合、取引情報に係る電磁的記録の保存が法律で求められます。

電子で受発注した時点で「電子取引」に当たる ― 法第7条の保存義務

電子帳簿保存法第7条は、「所得税（源泉徴収に係る所得税を除く。）及び法人税に係る保存義務者は、電子取引した場合には、財務省令で定めるところにより、当該電子取引の取引情報に係る電磁的記録を保存しなければならない」と定めています^*5。電子取引に該当する場合、この保存義務が生じます。

満たすべき措置は4つのいずれか（規則第4条第1項）

同法施行規則第4条第1項は、保存にあたって次のいずれかの措置を講じることを求めています^*6。

1. タイムスタンプが付された後に取引情報を授受すること
2. 授受後、または業務処理に係る通常の期間を経過した後、速やかにタイムスタンプを付すこと
3. 記録事項の訂正・削除の事実と内容を確認できる、または訂正・削除ができないシステムを使用すること
4. 正当な理由がない訂正・削除の防止に関する事務処理規程を定め、運用し、備え付けること

連携設計への具体的な影響 ― システム側で満たす要件と連携方式の選定

4つの措置のうち③は、システム側の機能で満たす要件です。中間ファイルを人が自由に書き換えられる運用のままでは、訂正・削除の事実を確認できないおそれがあります。連携方式を選ぶ段階から、この要件を満たせる作りかどうかを確認しておく必要があります。

検索要件と、基準期間の売上高5,000万円以下の事業者に関する緩和

施行規則第4条第1項には検索要件や、基準期間の売上高が5,000万円以下の事業者向けの緩和も定められています^*6。ただし条件は入り組んでおり、自社が緩和の対象となるかどうかは、所轄税務署または税理士に確認することをおすすめします。

設計要件③：止まったときの設計 ― 非機能要求グレードで6項目を点検

連携は作ることよりも、止まったときにどう戻すかという運用面の設計が実務では重くのしかかります。この整理に使えるのが、独立行政法人情報処理推進機構（IPA）が公開している非機能要求グレードです。

非機能要求グレードとは

非機能要求グレードは、非機能要求項目を網羅的にリストアップし分類するとともに、要求レベルを段階的に示したものです^*7。2018年版が最終公開版で、2023年8月17日に最終更新されています^*7。本事業自体は2009〜2018年度で終了しており、最新のガイドラインではありません^*7。

6大項目を受注連携に当てはめる

非機能要求グレードは、可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境エコロジーという6つの大項目で構成されています^*7。受注連携では特に可用性（止まらない・止まっても戻せる設計か）と運用保守性（監視・障害対応の体制があるか）が実務上の論点になりやすい項目です。

受注連携で先に決めておく4点

受注連携の要件定義では、再送の可否、重複取込の防止、締め時間との関係、障害時の代替手段の4点を先に決めておくと手戻りを抑えられます。締め時間の設計はBtoB ECの受注締め時間設定、受注の時間帯集中への対策はBtoB ECの受注集中時間帯対策で解説しています。詰めずに連携を組むと、締め時間とずれて当日出荷分が翌日回しになりかねません。

連携設計の進め方5STEP ― 入口の洗い出しから保存要件の反映まで

ここまでの要件をふまえ、連携設計は次の5つのSTEPで進めるのが実務的です。

連携でつまずく5つの典型パターンと回避策

連携設計では、方式そのものよりも周辺の運用設計でつまずくケースが目立ちます。代表的な5つのパターンを見ていきます。

取引先コード・商品コードのマスタ不整合

連携の失敗は、データ設計の失敗として現れることがあります。取引先コードや商品コードが連携先ごとにばらばらだと、突合作業に人手が割かれ続けることになります。

個別接続を増やし続ける（点対点の増殖）

取引先が増えるたびに個別フォーマットで接続を増やすと、接続の数だけ保守対象が増えます。標準仕様への統一は、この増殖を止める手段の1つです。

締め時間と連携タイミングがずれ、当日出荷に間に合わない

締め時間の設定と連携のタイミングがずれると、締め後に入った注文の扱いがあいまいになり、当日出荷分の注文が翌日回しになるリスクがあります。締め時間と連携タイミングは、セットで設計する必要があります。

中間CSVを人が手で直す運用が残り、訂正・削除の記録が残らない

中間ファイルを人が手作業で修正する運用が残っていると、電子帳簿保存法が求める訂正・削除の事実を確認できないおそれがあります^*6。この論点は前章の保存要件と直結します。

レガシーな通信経路への依存 ― INSネットは2028年12月31日にサービス提供終了

INSネット64・INSネット64ライト・INSネット1500は、2028年12月31日にサービス提供が終了します^*1。新規申込の受付はすでに2024年8月31日に終了しています^*1。この経路に依存した連携を組んでいる場合、期限を見据えた移行計画が必要です。

内製か外部委託か ― 判断軸と中小企業向け補助金

連携設計をどこまで内製し、どこから外部に委託するかは、社内に確認できる要件と、確認できる人がいるかどうかで変わってきます。

内製で持てる範囲と、外注が向く範囲

内製で対応する場合に必要なのは、データ項目を洗い出すデータ設計の知識と、連携方式ごとの実装知識です。加えて、電子帳簿保存法・非機能要件を要件定義に落とし込む力も求められます。これらを社内で網羅できない場合、要件の一部が抜け落ちたまま連携が組まれてしまうことがあります。

委託先に確認すること

外部に委託する場合は、連携方式を決め打ちしていないか、保存要件と非機能要件を要件定義に含めているかを確認します。専門家との違いは、要件を漏れなく洗い出せるかどうかに現れます。

費用の考え方と公的支援 ― 中小企業デジタル化・AI導入支援事業（通常枠）

中小企業基盤整備機構は、中小企業デジタル化・AI導入支援事業（通常枠）を実施しています^*8。補助額は1プロセス以上で5万円以上150万円未満、4プロセス以上で150万円以上450万円以下です^*8。補助率は1/2以内または2/3以内です^*8。

直近の5次締切は2026年9月29日（火）17:00で、いずれも2026年8月29日時点の情報です^*8。金額・補助率・締切は回次によって変わるため、検討時は公式ページで最新の情報を確認してください。

費用の見積もりを比較する際は、金額の多寡だけでなく、どこまでの要件定義が含まれているかを揃えて比べることが大切です。連携先の数、同期タイミング、電子帳簿保存法の保存要件、障害時の再送・重複防止までを見積もりの前提に含めているかどうかで、後工程の追加費用は大きく変わります。

まとめ：受注管理システムの連携を決める3つの判断軸

本稿では、受注管理システムの連携を「何とつなぐか」ではなく「何を・いつ・どの粒度で渡し、止まったらどう戻すか」を決める作業として整理しました。要点を3つに集約すると、第一に連携方式はファイル・DB直結・API・EDIの4種から業務ごとに使い分けること、第二に標準仕様・電子帳簿保存法・非機能要件という3つの設計要件が方式選定に外から効いてくること、第三に締め時間や保存要件、点対点の増殖といった典型的なつまずきを先に押さえておくことです。自社だけで要件を網羅できるか不安な場合は、要件整理の段階から相談するのが近道です。

---

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

よくある質問

受注管理システムと販売管理システムは連携しないと使えないのですか

連携しなくても、それぞれ単独で使うことは可能です。ただし連携しない場合は、同じ注文データを両方のシステムへ入力し直す二重入力が発生し、転記ミスのリスクも残ります。業務量が多いほど、連携によるメリットが大きくなります。

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

即時性が必要かどうかで判断します。在庫引当のように即時の反映が求められる業務はAPI連携、締め処理のようにタイミングが決まっている大量処理はCSVなどのファイル連携が向いています。すべてをどちらか一方に統一する必要はありません。

取引先ごとにフォーマットが違う場合はどうすればよいのですか

取引先数が少なく増える見込みがなければ、個別対応でも運用できます。取引先が多い、または増える見込みがあるなら、流通BMSのような標準仕様への統一を検討します^*2。個別対応を積み重ねるほど、保守対象が増え続けます。

受注データはどのくらいの期間、どう保存する必要がありますか

電子的に授受した受注データが電子帳簿保存法上の電子取引に該当する場合、同法第7条により電磁的記録の保存が必要です^*5。具体的な保存の方法は施行規則第4条第1項の4つの措置のいずれかを満たす必要があり^*6、自社の該当状況は税理士・所轄税務署に確認することをおすすめします。

連携は一度作れば終わりなのですか

連携は作って終わりではなく、運用しながら見直すものです。取引先の増減、通信回線の終了、制度改正などのタイミングで、連携方式や保存要件の見直しが必要になります。INSネットのように提供終了時期が決まっているケースは、期限から逆算した計画が欠かせません^*1。

1. *1　出典：東日本電信電話株式会社「INSネットの新規申込受付・提供終了について」（2024年3月7日）https://www.ntt-east.co.jp/release/detail/20240307_02.html
2. *2　出典：一般財団法人流通システム開発センター（GS1 Japan）／流通システム標準普及推進協議会「流通BMS（流通ビジネスメッセージ標準）」（基本形Ver2.2.2訂正版・2025年7月15日公開）https://www.gs1jp.org/ryutsu-bms/
3. *3　出典：一般社団法人全国銀行資金決済ネットワーク「全銀EDIシステム（ZEDI）」https://www.zengin-net.jp/zedi/
4. *4　出典：デジタル庁「デジタルインボイス（JP PINT／Japan Peppol Authority）」https://www.digital.go.jp/policies/electronic_invoice
5. *5　出典：e-Gov法令検索「電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関する法律（電子帳簿保存法）」第7条https://laws.e-gov.go.jp/law/410AC0000000025
6. *6　出典：e-Gov法令検索「電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関する法律施行規則」第4条https://laws.e-gov.go.jp/law/410M50000040043
7. *7　出典：独立行政法人情報処理推進機構（IPA）「非機能要求グレード（2018年版）」（最終更新2023年8月17日）https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html
8. *8　出典：独立行政法人中小企業基盤整備機構「中小企業デジタル化・AI導入支援事業（通常枠）」（2026年8月29日時点）https://it-shien.smrj.go.jp/applicant/subsidy/normal/