受発注システムと基幹システムの連携方法|API・EDI・ファイル連携の選び方と費用の決まり方

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

B2B EC-COLUMN

受発注データを都度手入力している状態で何が起きているのか

取引先から届いた注文を受発注システムで受け、そのあと同じ品番と数量を基幹システムの受注入力画面へ打ち直している。
この転記が一日に何十件も続くと、打ち間違いだけでなく、在庫や売上の反映が数時間から一日遅れます。
中小企業庁の実証事業では、受発注をEDI化した中小企業で業務時間が平均51.4%削減されたと報告されています¹。
連携の方式はAPI連携・ファイル(CSV)連携・業界標準EDIに大別され、どれを選べるかを決めるのは、基幹システムがパッケージか独自開発かではなく、つなぎたい相手がAPIを外部に提供しているかどうかです。
APIが無ければCSVでの一括連携が現実的な代替になり、小売の取引先から流通BMSでの接続を求められている場合は、業界標準への対応が別の軸として加わります。

受発注システムの画面には注文が届いているのに、基幹システムには何も入っていない。
その間を埋めているのが、担当者による転記です。
注文一覧を開き、取引先コード、品番、数量、納期、単価を見ながら、基幹システムの受注入力画面へ同じ値を打ち直す。
件数が少ないうちは十数分で終わりますが、一日の注文が数十件を超えると、午前中がまるごと入力で埋まることもあります。

やっかいなのは、転記が一度で終わらないことです。
受注として登録した後、出荷指示のために倉庫へ渡す一覧を作り、出荷が済めば売上として計上し、月末には請求データを作ります。
途中で数量が変わったり、納期が前倒しになったりすれば、変更はもう一度同じ経路をたどります。
最初の一箇所で品番を打ち間違えると、誤りは出荷指示にも売上にも同じ形で流れていき、気づくのは取引先からの連絡か、月末の突き合わせという順番になります。

もう一つ、目に見えにくいのが時間差です。
受発注システム上では在庫が引き当てられていても、基幹システムに反映されるのが夕方のまとめ入力であれば、その間の在庫数は実態とずれたままになります。
営業が基幹システムの在庫を見て回答した納期が、実は別の注文で押さえられていた、という食い違いはここから生まれます。
入力ミスは見つければ直せますが、この時間差によるずれは、誰も間違えていないのに起きるのが厄介なところです。

この手入力をなくす手段として、企業間のデータをそのままやり取りするEDIの効果は、公的な実証でも測られています。
中小企業庁は中小企業共通EDI標準の策定に着手し、その後の実証事業として12のプロジェクトで受発注業務のEDI化の効果を測定しました¹。
そこで得られた業務時間の削減率は、平均で51.4%と報告されています¹。
ただしこれは12件の実証プロジェクトの平均値であり、どの会社がどの方式でつないでも半分になるという保証ではありません。

そのため、最初にやることは方式を選ぶことではなく、自社のどの転記をなくしたいのかを書き出すことです。
どの画面からどの画面へ、どの項目を、一日に何件写しているのか。
受注の登録だけなのか、出荷の実績や請求まで含むのか。
この棚卸しがないまま方式の話から入ると、注文データだけつないで満足し、結局は出荷と売上の転記が手元に残る、という形になりがちです。

連携方式にはどんな種類があり、何で選び分けるのか(API・CSV・EDI)

API連携:リアルタイムにデータをやり取りする方式

APIは、システムが外部とのデータのやり取りを受け付けるために用意した窓口です。
受発注システムで注文が確定した時点で、その窓口を通じて基幹システムへ受注データを渡せば、人が画面を見ながら打ち直す工程がなくなります。
受発注システム側の仕様としても、APIが提供されている外部システムとはリアルタイムでデータ連携する、という形になります³。

リアルタイムという言葉が効いてくるのは、反映の遅れが業務の判断に直結する場面です。
在庫の引き当て、与信残高の確認、納期の回答のように、数時間前の数字で判断すると取り消しややり直しが発生する業務では、注文が入った瞬間に基幹側の数字が動くことに意味があります。
逆に、月次でまとめて処理すれば足りる業務のために、わざわざ即時の経路を作る必要はありません。
同じ会社の中でも、伝票の種類によって必要な速さは違います。

API連携の前提は、つなぐ相手がAPIを外部に提供していることです。
提供されていれば、あとは渡す項目と方向を決める作業になりますが、提供されていなければ、まず相手側にその窓口を作るところから始まります。
この差が、後で見る費用の桁を分けます。

ファイル(CSV)連携:一括登録・一括更新でつなぐ方式

APIが無い相手とつなぐときに現実的なのが、ファイルによる連携です。
受発注システムから決まった形式のCSVファイルを出力し、基幹システム側でそれを取り込む。
受発注システム側の仕様でも、対応するAPIが無いシステムに対しては、CSVの出力・取込による一括登録・一括更新という形が用意されています³。

一括という点が、APIとのいちばんの違いです。
注文が入るたびに流れるのではなく、朝と夕方、あるいは一時間ごとといった決めたタイミングで、その間にたまった分がまとめて動きます。
ファイルの受け渡し自体はSFTPのような経路で自動化でき、人が押すのはボタン一つ、あるいは何も押さない運用にできます⁴。
手作業が残るかどうかと、反映が即時かどうかは別の話です。

実務でつまずきやすいのは、ファイルの中身を合わせる工程です。
品番の桁数、取引先コードの体系、日付の書式、数量の小数点の扱いが一致していないと、取込の時点で弾かれます。
この項目の対応表を作る手間はAPIでも同じように発生しますが、CSVの場合は取込に失敗した行がファイルの中に残るため、誰がそれを見て直すのかまで決めておく必要があります。

ここまでは、社内のシステム同士をつなぐ話です。
これとは別に、取引先との間で使う形式が業界の標準として決まっている場合があり、その代表が流通BMSのようなEDIの規格です。
社内の事情だけでは選べない領域なので、条件を分けて見ていきます。

基幹システムの種類より重要な「APIが使えるか」という条件

連携の相談でよく出るのが、うちの基幹システムはかなり古い独自開発なので難しいのではないか、という不安です。
パッケージか、スクラッチで作った独自開発か、クラウドのサービスか。
この分類で可否が決まるように思えますが、方式の選び分けを説明している資料が基準にしているのは、いずれも分類ではなく、APIが使えるかどうかでした。

基幹システム連携の方式を比較した資料では、古い基幹システムであってもAPIが無い場合には、SFTPやCSVによるファイル連携、あるいはEAI型のツールでデータベースから直接データを取得する方法が現実的な連携手段になる、という整理が示されています⁴。
古いから連携できないのではなく、APIという窓口が無いために別の入口を使う、という話です。
反対に、新しいクラウドの基幹システムであっても、受注の登録に使えるAPIが公開されていなければ、API連携は選べません。

そこで、自社の状況を確かめる問いは、システムの世代や導入形態ではなく、次のような形になります。
外部連携用のAPIが提供されているか。
提供されている場合、対象は受注・出荷・在庫・取引先マスタのどれで、登録まで行えるのか、参照だけなのか。
提供されていない場合、データベースから所定の形式でファイルを書き出す仕組みや、外部からファイルを取り込む仕組みが用意されているか。

この確認をすると、答えは全部か無かではなく、まだらになることが多くあります。
受注の登録APIはあるが在庫の参照は無い、出荷実績はCSVでしか出せない、といった具合です。
その場合の連携は、伝票の種類ごとに方式が分かれます。
注文はAPIでその場で渡し、出荷実績と売上は一日一回のファイルでまとめて戻す、という組み合わせも取り得ます。
方式をひとつに決めなければいけないという前提を外すと、選択肢はかなり広がります。

もう一点、確認の相手を間違えないことも大事です。
APIの有無は、製品のカタログよりも、実際に保守しているベンダーや情報システムの担当者が持っている情報です。
過去の改修で独自に作り込んだ入出力の仕組みが残っていることもあり、それが使えるなら新規の開発は要りません。
見積りを取る前に、この棚卸しをどこまでできているかで、話の進み方が変わります。

流通BMSなど業界標準のEDIが必要になるケース

流通BMSが対象とする6業務・8種のメッセージ

流通BMSは、消費財の流通向けに定められたEDIのメッセージ標準です。
一般財団法人流通システム開発センターの流通BMS協議会が仕様を策定・発行しており、スーパーやグロサリーの業界で行われるターンアラウンド型の取引が中心に想定されています²。
ターンアラウンド型とは、小売から届いた発注データをもとに、仕入先が出荷や請求のデータを返していく流れのことです。

基本形のVer1.0では、発注、出荷、受領、返品、請求、支払の6業務について、8種の標準メッセージが定められました²。
ここが自社で決めるファイル形式と決定的に違うところで、どの項目をどう並べるかを取引先ごとに取り決めるのではなく、規格の側にあらかじめ決まっています。
取引先が増えても同じ形式で受けられるのが利点であり、裏を返せば、自社の都合で項目を足したり減らしたりできない規格でもあります。

注意したいのは、流通BMSが社内のシステム同士をつなぐ規格ではないことです。
取引先との間を標準の形式で行き来したデータは、最終的に自社の基幹システムへ入らなければ、転記はなくなりません。
そこから先は、APIかファイルかという先ほどの話に戻ります。

導入を判断する基準:取引先数と既存システムの状態

では、いつ対応が必要になるのか。
流通BMSへの対応は法令で一律に義務づけられているわけではなく、取引先の小売業から接続を要請されて検討が始まる例が多い、という整理があります⁵。
自社が業界標準に合わせるべきかどうかは、社内の効率化の議論としてではなく、取引の条件として持ち込まれることが多いということです。

判断は、取引先の数と既存システムの状態を突き合わせて行うのが基本になります⁵。
要請してきたのが一社だけで、その取引の伝票枚数も限られているなら、標準規格へ全面的に対応するより、その取引先が求める範囲に絞って手当てするほうが現実的な場合があります。
反対に、同じ要請が複数の小売から続いている、あるいは今後も増える見込みがあるなら、取引先ごとの個別対応を積み重ねるほど後の保守が重くなります。

既存システムの状態というのは、標準メッセージを受け取れる仕組みが社内のどこにあるか、という意味です。
受発注システムが標準に対応しているのか、基幹システム側で受けるのか、間に変換の仕組みを置くのか。
ここが決まっていないと、複数社から見積りを取っても、前提が違うまま金額だけが並ぶことになります。
要請を受けた段階で、取引先が求める業務の範囲と、社内で受ける場所の候補を先に整理しておくと、その後の話が早くなります。

連携の費用・期間は何で決まるのか

接続の単純さと改修規模で費用は数十万円〜1000万円超まで変わる

費用の話に入ると、まず桁を知りたくなります。
API連携の開発費用の目安を公開しているGXO株式会社の資料では、通知連携のような単純なAPI連携で30万〜100万円、レガシーシステムにAPIのラッパーを作る場合で100万〜500万円、レガシーな基幹システムそのものをAPI化するエンタープライズ規模で600万〜1,000万円以上という幅が示されています⁶。
これは同社が自社の開発実績と見積りの水準として示している目安であり、市場全体の相場を統計として示したものではありません。
また、この資料には公開日の明記がなく、どの時点の水準かは特定できていません。

幅の広さそのものが、費用の決まり方を表しています。
安い側は、両側にすでにAPIがあり、決められた項目を決められた方向へ渡すだけの状態。
高い側は、基幹システムに外部と話す窓口が無く、それを作るところから始める状態です。
前の節で確認したAPIがあるかどうかという一点が、そのまま金額の段差になっているわけです。

期間についても、同じ要素で増減すると考えるのが実務的です。
つなぐ伝票の種類、項目の数、相手システムの台数、そしてテストで何回分のデータを流して確認する必要があるか。
特に基幹システム側に手を入れる場合は、連携部分の開発そのものよりも、既存の処理に影響が出ていないかを確かめる作業が工程を左右します。
何か月で終わるという一般的な目安を確かな数字として示せる資料はありませんが、見積りを比べるときは、金額の内訳がこのどの部分に対応しているのかを聞くと、期間の見通しも一緒に見えてきます。

保守・運用費も合わせて見込んでおく

見落とされやすいのが、つないだ後に毎月かかる費用です。
同じ資料では、保守運用の費用として月12万〜33万円程度という目安が示されています⁶。
これも同社の水準としての目安ですが、初期費用だけで予算を組むと、二年目以降に想定していなかった固定費が乗ることになります。

保守運用が必要になるのは、連携が一度作って終わりの仕組みではないからです。
相手システムのバージョンが上がればAPIの仕様が変わることがあり、取引先が増えればコードの対応表が増えます。
取込が失敗したときに気づく仕組みと、失敗した分をどう流し直すかの手順も、運用として抱え続けるものです。
社外へ払う保守費だけでなく、社内で誰がその面倒を見るのかも費用のうちに数えておくと、導入後の議論が現実的になります。

連携後に気をつけたいデータのずれ・運用の注意点

連携が動き出すと、転記そのものは減ります。
ただし、減った分だけ別の種類の確認が生まれます。
その中心にあるのが、方式による反映タイミングの違いです。
APIによる注文データの連携がリアルタイムで行われるのに対し、CSV連携は出力と取込による一括登録・一括更新という形をとります³。

この差から素直に導けるのは、CSV連携では実行と実行の間に必ず空白の時間があるということです。
朝9時と夕方17時に取り込む設定なら、10時に入った注文は17時まで基幹システムには存在しません。
その間に基幹システムの在庫を見て納期を回答すれば、受発注システム側で押さえられている分を数えそこねます。
ですから、取込の時刻を決めるときは、注文が集中する時間帯や、営業が在庫を見て回答する時間帯とどう重なるかを先に見ておくのが実務的です。
これは実測された不具合の発生率の話ではなく、一括処理という仕様から予想できる範囲の話です。

もう一つは、データの入口が増えることによるずれです。
連携を入れても、電話やFAXで入る注文が残っていれば、そちらは従来どおり誰かが基幹システムへ入力します。
連携経由の受注と手入力の受注が同じ台帳に並ぶと、重複や二重計上が起きることがありますが、これは連携の失敗というより、入口が二つあることの結果です。
受注番号の付け方や、どちらの経路で入ったかが後から分かる印を決めておくと、月末の突き合わせの負担が変わります。

マスタのずれも同じ性質の問題です。
品番や取引先コードは、受発注システムと基幹システムの両方に存在します。
新商品を基幹側だけに登録して受発注システムに入れ忘れれば、注文は連携の途中で止まります。
止まったことに気づく仕組み、つまりエラーの通知先と、誰がその日のうちに直すのかを決めておくことが、連携を始めた後の運用でいちばん効いてきます。

残る確認作業も、なくなったわけではありません。
単価や納期の条件が特殊な注文、数量の急な変更、返品の処理といった、内容を見て判断するものは人の手に残ります。
連携で減らせるのは同じ値を写す作業であって、判断そのものではない。
この線引きを導入前に共有しておくと、始まった後で思ったほど楽にならないという感想になりにくくなります。

ここまでの判断をまとめると、出発点は自社の基幹システムの分類ではなく、つなぎたい相手にAPIという窓口があるかどうかです。
そのうえで、即時の反映が要る伝票とそうでない伝票を分け、取引先から標準EDIを求められているかを別の軸として重ねます。
方式ごとに、前提となる条件と、選んだ場合に社内で決めることを順に見ていきます。

連携方式の当たりはつけられても、自社の基幹システムにどのAPIがあり、どの伝票までつなげるのかは、仕様と現在の運用を突き合わせないと判断できません。

受発注システム側がAPIとCSVのどちらで受けられるか、扱っている伝票の流れに沿って、どの転記が実際になくなり、どの確認作業が残るのかを確かめられます。無料相談で要件を整理する

連携方式を決める前に確かめておきたいこと

つなぐ相手の仕様で決まることを先に、自社の業務都合で決めることを後に並べています。

• 基幹システムに外部連携用のAPIが提供されているか、提供されている場合の対象は受注・出荷・在庫・取引先マスタのどれか

• そのAPIで登録まで行えるのか、参照だけなのか（参照だけなら、確定の操作は基幹側に残る）

• APIが無い場合に、所定の形式でファイルを書き出す仕組みや、外部からファイルを取り込む仕組みがあるか

• 即時の反映が必要な伝票はどれか、一日数回の反映で足りる伝票はどれか

• 取引先の小売業から、流通BMSのような標準規格での接続を求められているか

標準規格での接続を求められている場合は、これらに加えて対応する業務の範囲の確認が必要になります。

連携方式別に見る、選べる条件と決めておくこと

連携方式	選べる条件	判断の分かれ目	先に決めておくこと
API連携	つなぐ相手がAPIを外部提供している	即時の反映が業務に要るか、開発の予算をかけられるか	どの伝票をどちらの方向へ流すか、登録まで行えるか
ファイル(CSV)連携	相手にAPIが無い、または開発の規模を抑えたい	一日数回の反映で回るか、実行時刻を繁忙時間とずらせるか	実行のタイミング、項目の対応、取込に失敗した行の扱い
EDI標準(流通BMS等)	小売の取引先から標準規格での接続を求められている	取引先の数と、標準メッセージを受けられる既存システムの状態	対応する業務の範囲と、受け取ったデータを社内のどこへ渡すか

API連携が選べる条件と、先に決めること

API連携を選べるのは、つなぐ相手がAPIを外部に提供している場合です³。
この条件が満たされているなら、次に考えるのは、その即時性が本当に必要かどうかです。
注文が入った瞬間に基幹システムの在庫が動くことに意味がある業務と、翌朝に反映されていれば足りる業務は、同じ会社の中に混在します。

決めておくのは、どの伝票をどちらの方向へ流すかです。
注文は受発注システムから基幹システムへ、在庫や単価は基幹システムから受発注システムへ、というように向きが逆になるものがあります。
そして、それぞれのAPIが登録まで行えるのか、参照だけなのかで、残る手作業が変わります。
在庫の参照しかできなければ、引き当ての確定は基幹側の操作として残り、その分の運用を設計しておく必要があります。

相手にAPIが無く、新しく作るところから始める場合は、開発の規模が一段変わります⁶。
その場合は、基幹システムのAPI化そのものを目的にせず、まず削りたい転記に必要な範囲だけ窓口を用意する、という切り分けを検討する余地があります。
最初に全部をつなごうとすると、金額も期間も判断しにくい規模になります。

ファイル連携で足りるかを見分ける条件

ファイル連携を選ぶのは、相手にAPIが無い場合か、開発の規模を抑えたい場合です³⁴。
判断の分かれ目は、一日数回の反映で業務が回るか、そして実行の時刻を繁忙の時間帯とずらせるかどうかです。
ここが厳しい業務だけをAPIにし、残りをファイルにするという分け方もできます。

決めることは具体的です。
一日に何回、何時に流すのか。
ファイルに含める項目と、両側のコード体系をどう対応させるのか。
取込が途中で失敗したとき、失敗した行だけ直して流し直すのか、ファイル全体をやり直すのか。
この三点を決めずに始めると、運用が始まってから毎回その場で判断することになり、担当者が固定されてしまいます。

APIも使えず、自社形式のファイル出力も用意されていない基幹システムの場合には、EAI型のツールでデータベースから直接データを取り出す方法が現実的な選択肢として挙げられています⁴。
ただし、これは相手システムの内部構造に触れる方法なので、保守を担当しているベンダーの了解と、バージョンアップ時の影響の確認が前提になります。

業界標準のEDIで受ける場合に決まること

取引先の小売業から接続を要請されている場合は、これまでの二つとは別の軸が加わります⁵。
方式を自社の都合で選ぶのではなく、規格が先にあり、それに合わせる形になるからです。
そのぶん、社内で決められるのは対応の範囲と、受けた後の流し先になります。

決めるのは、規格のどこまでを対象にするかです。
流通BMSは発注、出荷、受領、返品、請求、支払の6業務を対象にしていますが²、取引先から求められるのが発注と出荷だけということもあります。
請求や支払まで標準で回すなら、会計側との連携も同時に設計することになり、関わる部署が増えます。

そしてもう一つが、受け取ったデータを社内のどこへ渡すかです。
標準EDIで取引先とつながっても、その内容が基幹システムに入らなければ、転記は社内に残ったままになります。
結局のところ、取引先との接続は規格に従い、社内の受け渡しはAPIかファイルかを選ぶ、という二段構えになります。
見積りを比べるときは、この二段のどちらの費用なのかを分けて確認すると、金額の違いの理由が読めるようになります。

要点の整理

軸	基準
方式の分かれ目	つなぐ相手がAPIを外部提供しているか
即時性の要否	注文と同時の反映が業務判断に要るか、一日数回で足りるか
業界標準の要否	小売の取引先から流通BMSでの接続を求められているか
費用の規模	既存のAPIをつなぐだけか、基幹システム側に窓口を新設するか
運用の設計	取込の実行時刻と、失敗した行を直す担当

取引先から標準規格での接続を求められている場合は、対応する業務の範囲と、受け取ったデータを社内のどこへ渡すかまで決めないと、見積りの前提がそろいません。 取引先の数と既存システムの状態をもとに、標準の形式で受ける部分と社内の基幹システムへつなぐ部分を分けて整理でき、どこに開発が必要になるのかが見えます。

よくある質問

EDI連携とAPI連携はどう違うのですか？

EDIは企業と企業の間で取引データをそのまま交換する仕組みの総称で、流通BMSのように、対象とする業務とメッセージの種類まで規格として決められているものがあります²。
一方APIは、システムが外部とのやり取りを受け付けるための窓口で、企業間でも社内のシステム同士でも使えます。
対立する選択肢というより、取引先とは業界の規格に従って接続し、社内の受発注システムと基幹システムの間はAPIかファイルでつなぐ、という組み合わせになることがあります。
見積りを読むときは、どちらの区間の費用なのかを分けて見ると分かりやすくなります。

流通BMSへの対応は必ず必要なのですか？

法令で一律に義務づけられた規格ではなく、取引先の小売業から接続を要請されて検討が始まる例が多いとされています⁵。
要請が無い段階で先回りして対応しなければならない性質のものではありません。
判断は、要請してきた取引先の数と、標準メッセージを受けられる既存システムの状態を突き合わせて行います⁵。
一社からの要請で、その取引の伝票枚数も限られているなら、範囲を絞った対応から始める選択もあります。

APIが無い古い基幹システムでも連携できますか？

できないとは限りません。
方式を比較した資料では、APIが無い場合にSFTPやCSVによるファイル連携、EAI型のツールによるデータベースからの直接取得が現実的な手段として挙げられています⁴。
受発注システム側から見ても、APIが提供されていない相手にはCSVの出力・取込による一括登録・一括更新でつなぐ形になります³。
確認すべきなのはシステムの古さではなく、外部とデータをやり取りする入口がどんな形で用意されているかです。

連携後の保守・運用費用はどれくらい見ておけばよいですか？

API連携の費用目安を公開しているGXO株式会社の資料では、保守運用費として月12万〜33万円程度という水準が示されています⁶。
これは同社が自社の実績と見積りの水準として示す目安であり、市場の相場を統計として示したものではありません。
また、この資料には公開日の明記がなく、どの時点の水準かは特定できていません。
金額に加えて、取込の失敗に気づいて直す担当を社内に置く必要があるため、その工数も運用の費用として見込んでおくと、予算のずれが小さくなります。

受発注システム側のAPI対応状況はどこで確認できますか？

製品の機能説明や連携仕様のページに、どの方式に対応しているかが書かれています。
たとえばEC-Rider B2B Ⅱの場合は、APIが提供されている外部システムとはリアルタイムに連携し、対応するAPIが無いシステムにはCSVの出力・取込で一括登録・一括更新を行う、という形が示されています³。
見るべき点は、対応の有無だけではありません。
受注・出荷・在庫・取引先マスタのうちどれが対象か、登録まで行えるのか参照だけか、CSVの項目定義が公開されているか。
この三点まで確認できると、自社に残る手作業の量が具体的に見えてきます。

1. 1　出典：中小企業庁(ミラサポplus)「企業間のデータ連携で、受発注の業務コストを削減する！」（2020年）
2. 2　出典：一般財団法人流通システム開発センター(流通BMS協議会)「流通BMS標準仕様」（2007年）
3. 3　出典：株式会社フライトソリューションズ「外部システム連携で生産性向上(EC-Rider B2B Ⅱ)」（2026年）
4. 4　出典：Aurant Technologies「基幹システム連携の方式比較【2026年】API・iPaaS・ETL・ファイル連携の選び方とコスト」（2026年）
5. 5　出典：株式会社フライトソリューションズ「流通BMSとは｜電子受発注の標準規格と導入の進め方」（2026年）
6. 6　出典：GXO株式会社「API連携開発の費用相場｜主要サービス別の工数目安と開発の進め方」（確認時点不明）