Web受発注システムの連携方法とは？CSV・API・EDIの違いと選び方

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

B2B EC-COLUMN

連携しないまま運用すると何が問題になるのか

FAXで届いた注文書を見ながら受発注の画面に入力し、同じ内容をもう一度、販売管理システムの受注入力へ打ち直す。
在庫があるかは別の画面で確かめ、月末には売上を会計用に集計し直す。
既存の基幹システムを動かしたままWeb受発注システムを検討していると、この打ち直しがどこまで減るのかが最大の関心事になります。
分かれ目は連携方式です。
ファイルを受け渡して幅広い外部システムにつなぐCSV連携と、相手システムがAPIを提供している場合にカスタマイズで実現する連携があり、どちらを選べるかは自社の希望ではなく相手システムの仕様で決まります²。
加えて、取引先が流通BMSのような業界標準EDIで発注してくるなら、その規格への対応可否を別に確かめる必要があります³。

受注の現場では、注文がひとつの経路で届くとは限りません。
FAXで届いた注文書、メール本文に書かれた品番と数量、電話で追加された一行。
それらをまず受発注の画面に打ち込み、同じ内容をもう一度、販売管理システムの受注入力画面へ入れ直す。
在庫があるかどうかは在庫管理の画面を別に開いて確認し、出荷の指示は倉庫へ別の帳票で渡し、月末には売上を集計して会計システム用の形に整える。
この一連が、連携していない状態の実態です。

転記そのものは単純作業ですが、事故はたいてい単純作業のつなぎ目で起きます。
数量の桁をひとつ間違える、単価を改定前のまま入れる、急ぎの注文を先に処理して元の順番が崩れる。
さらに厄介なのは、同じ注文のデータが受発注システムと販売管理システムの両方に存在することです。
片方だけを修正すると、どちらが正しいのか後から誰にも判断できなくなります。
出荷指示は販売管理側の数量で出て、取引先への回答は受発注側の数量で返す、という食い違いはこうして生まれます。

もうひとつは時間です。
入力が終わるまで在庫が引き当たらないため、同じ商品に複数の注文が重なったとき、どちらを優先するかが実質的に入力の順番で決まってしまいます。
受注から出荷指示までの間に人の作業が挟まっていると、その日の処理件数の上限も担当者の手の速さで決まります。
繁忙期に受注が増えたとき、システムの性能ではなく入力待ちが先に詰まるのはこのためです。

受発注情報を電子データで連携した場合の効果については、国の実証事業に数字が残っています。
中小企業庁が平成28年度補正予算の「経営力向上・IT基盤整備支援事業(次世代企業間データ連携調査事業)」として実施した取り組みでは、自動車・水インフラ・農林水産・輸出・卸小売・サービスの6業界で12件の実証プロジェクトが行われ、参加した中小企業の業務時間が平均51.4%削減されました⁴。

この数字の読み方には注意が要ります。
対象は12件の実証プロジェクトに参加した企業であり、全業種・全企業に当てはまる平均ではありません⁴。
また、連携していない企業の作業負荷を直接測った調査でもなく、連携を実施した側で測った削減幅です。
それでも、受発注情報を人の手で移し替えている工程には相応の時間が積もりうる、という目安にはなります。
裏返せば、自社のどの工程にその時間が積もっているのかを把握しないまま方式だけを比べても、判断材料にはなりにくいということでもあります。

ですから、連携の検討でまず決めるのは「つなぐかどうか」ではありません。
どのデータを、どちら向きに、どれくらいの間隔で流すのか。
ここが具体的になると、選べる方式はかなり絞られます。

Web受発注システムの連携方式にはどんな種類があるのか(CSV・APIカスタマイズ連携・業界標準EDI)

連携方式の呼び名はベンダーによって違いますが、実際に選択肢になるのは大きく分けて、ファイルを受け渡す方式、相手システムのAPIを使う方式、そして取引先との間で業界標準の規格に合わせる方式です。
前の二つは自社と自社の既存システムの間の話で、後の一つは自社と取引先の間の話です。
同じ「連携」という言葉で語られますが、誰と何を取り決めるかがそもそも違うので、分けて考えたほうが検討は早く進みます。

CSV連携

CSV連携は、決められた項目の並びでデータをファイルに書き出し、相手システムがそれを読み込む方式です。
あるベンダーの例では、CSVファイルを利用して会計システムや倉庫管理システムなど様々な外部システムと連携できる仕組みが用意されています²。
ファイルの形式さえ合えば相手を選ばないため、相手システムがAPIを持っていなくても成立するのが最大の利点です。
長く使っている販売管理システムや、業種に合わせて作り込んだ在庫管理システムが相手でも、CSVの取込機能さえあれば話が始まります。

一方で、ファイルの受け渡しは「ある時点までにたまった分をまとめて渡す」動きになります。
1日1回なのか、1時間ごとなのか、担当者が操作したときなのか。
この間隔がそのまま業務の前提になります。
受注データを夜間にまとめて基幹システムへ渡す運用なら、日中の基幹システム側は前日までの状態を見ていることになります。

影響が出やすいのは在庫数です。
在庫のように刻々と変わる情報は、渡す間隔の分だけ両システムの数字がずれる時間帯が必ず生まれます。
取引先が見ている在庫表示が30分前の数字でも受注に支障がないのか、それとも欠品の回答を後から出し直すことになるのか。
このずれを業務として許容できるかどうかが、CSVで足りるかを判断する実質的な基準になります。

APIカスタマイズ連携

APIは、システム同士がデータをやり取りするための窓口のことです。
ファイルを介さずに、必要なときに必要なデータだけを取りに行ったり渡したりできるため、在庫数や受注状況のように鮮度が問われる情報と相性がよい方式です。
注文が入った時点で基幹システムへ登録する、取引先が画面を開いた時点で最新の在庫を取得する、といった動かし方ができます。

ただし、提供のされ方には注意が要ります。
先の例では、APIが提供されている他システムの場合、カスタマイズによりシステム連携する、と説明されています²。
つまりAPI連携は「契約すればその日から使える標準機能」ではなく、相手システムがAPIを公開していることを前提に、個別に作り込んで実現するものとして位置づけられています²。
相手システム側にAPIがなければ、この選択肢は検討の土俵に上がりません。

製品資料に「API連携対応」と書かれていても、それが意味するのは「APIを持つ相手となら接続を作れる」という意味であることが少なくありません。
自社の既存システムを名指しして、標準で接続できるのか、それとも個別に作るのかを確かめないと、導入時の作業量の見当が立ちません。

業界標準EDI(流通BMS等)への対応確認

三つ目は、自社の都合では決められない領域です。
取引先である小売業が業界標準のEDI規格で発注してくる場合、こちらがその規格に合わせる以外に接続する方法はありません。
消費財流通の分野で使われている流通BMS(流通ビジネスメッセージ標準)は、卸売またはメーカーと小売の間の取引業務を対象として作られた標準EDI規格で、発注・出荷・受領・返品・請求・支払の6業務について8種類の標準メッセージを規定しています³。
策定と普及は一般財団法人流通システム開発センター(GS1 Japan)と流通BMS協議会が担っており、現行は基本形Ver2.2です³。

ここで押さえておきたいのは対象範囲です。
流通BMSは消費財流通業界の卸-小売間取引を主な対象としており、あらゆる業種・あらゆる取引形態を覆う規格ではありません³。
製・配・販の三層をつなぐことは将来の目標として掲げられていますが、現状の対象は卸売(またはメーカー)と小売の間です³。
自社の取引先構成がこの範囲に当てはまるのか、当てはまるとして何社がその規格での接続を求めてくるのかによって、確認の優先度は変わります。

CSV連携とAPI連携が「社内のシステム同士をどうつなぐか」の話なのに対し、EDIは「取引先とどの言語で話すか」の話です。
前者は自社の都合で方式を選べますが、後者は相手の指定に従うことになります。
この違いを混ぜたまま製品比較を始めると、社内連携の使い勝手で選んだ製品が取引先の要件を満たさない、という事態が起こります。

CSV連携・API連携で扱えるデータやシステムの範囲はどう違うのか

方式の輪郭が見えると、次に知りたくなるのは「では実際に何がつながるのか」です。
先のベンダーの例では、連携可能なデータとして注文データ、配送データ、在庫情報、商品情報、組織情報などが挙げられ、対象システムとしては基幹システム(販売管理・会計)、倉庫・物流管理、在庫管理、決済代行、メールマーケティングなどが示されています²。
これは同製品の外部システム連携機能としての対応範囲であり、他社製品の対応データや対応システムは各社ごとに確認が必要です。

この一覧を読むときは、データの種類だけでなく向きをあわせて考えると整理しやすくなります。
注文データは受発注システムから既存の販売管理システムへ出ていく情報です。
反対に、商品情報や在庫情報、取引先や部署といった組織情報は、既存システム側で管理しているものを受発注システムへ取り込む情報になります。
配送データは、倉庫や物流側で発生した出荷実績や送り状の番号を受発注システムへ戻して、取引先が出荷状況を見られるようにするための情報です。

向きが決まると、どちらのシステムに手を入れる必要があるかも決まります。
受注データを出すだけなら受発注システム側の出力機能で足りますが、商品マスタを取り込むなら既存システム側に「必要な項目を出力する機能」が要ります。
連携の話をベンダーだけに聞いていると進まないのは、片側の話しかできないからです。
既存システムの保守担当に、どの項目を出力できてどの項目を取り込めるのかを確かめて初めて、両側の条件が揃います。

もうひとつ、混同しやすい区別があります。
データを渡せることと、相手システムで業務が完結することは別だということです。
受発注システムが売上の明細を出力できても、相手側にその形式を取り込む機能がなければ連携は成立しません。
出せる項目と受け取れる項目の両方が揃って、初めて連携と呼べる状態になります。
製品ページの対応一覧は前者の話をしているので、後者は既存システム側の仕様書で確かめることになります。

APIカスタマイズ連携の場合、扱える範囲は一覧では決まりません。
相手システムがAPIを提供している場合にカスタマイズで連携する仕組みである以上²、何がどこまで連携できるかは相手システムのAPIが何を受け付けるかと、個別の要件定義でどこまで作るかによって決まります。
相手システムのAPIが受注の登録にしか対応していなければ、在庫の取得はAPIでは実現できず、別の手段を併用することになります。
CSVとAPIのどちらかを選ぶ、という二択ではなく、データの種類ごとに向いた方式を組み合わせる形になることも珍しくありません。

検討を具体化する一番早い方法は、いま何を打ち直しているかを書き出すことです。
どの画面からどの画面へ、どの項目を、1日に何件移しているのか。
その項目が受発注システム側と既存システム側の両方に存在するかを突き合わせると、連携で消える作業と、項目が足りないために残る作業がはっきり分かれます。
ベンダーへの相談も、この一覧があるかないかで回答の具体性が変わります。

連携の導入で開発・保守の負担はどう変わるのか

同じ「連携」でも、導入時に誰が何をするかは方式で変わります。
CSV連携が様々な外部システムに汎用的に対応する仕組みとして用意されているのに対し、API連携は相手システムがAPIを提供している場合にカスタマイズで実現するものとされています²。
この書かれ方の差は、そのまま作業の性質の差になります。
前者は用意されたものに自社を合わせる作業、後者は自社のために作る作業です。

CSV連携で実際に時間がかかるのは、意外にも項目の対応表ではありません。
項目の並び、文字コード、区切り文字、日付の書式、金額の小数の扱い。
これらは仕様書を突き合わせれば決まります。
手が止まるのはコード体系のほうです。
受発注システムで使っている取引先コードと販売管理システムの得意先コードが一致していない、商品コードの桁数や枝番の付け方が違う、単位や税区分の持ち方が違う。
この変換表をどちら側で持ち、誰が更新するのかを決めないと、ファイルの形式が合っていても取り込みは通りません。

API連携では、決めることの中身が変わります。
どの操作をどのタイミングで呼ぶのか、認証をどう持つのか、相手システムが応答しなかったときに再送するのか止めるのか、重複して登録されないようにどう防ぐのか。
要件定義の段階で、正常に動いたときの流れだけでなく、失敗したときの扱いまで決めておく必要があります。
リアルタイムに動く仕組みは、うまくいっているときは手がかからない代わりに、止まったときに誰が気づくかを設計しておかないと発見が遅れます。

導入後の保守も、方式によって発生の仕方が違います。
CSV連携は、扱う項目が増えたときにファイルの定義を変え、受け側の取込設定も合わせて変える必要があります。
API連携は、相手システムがバージョンアップしてAPIの仕様が変わった場合に、こちら側の改修が必要になることがあります。
どちらも無保守ではなく、変更が起きる場面と、そのとき誰が動くのかが違うだけです。
カスタマイズで作った連携は、作った内容を把握している人がいなくなると手を入れにくくなる、という別の負担も抱えます。

費用の見当をつけたい場合は、見積もりを取る前に条件を揃えておくと比較が成り立ちます。
連携したい相手システムの製品名とバージョン、連携するデータの種類と向き、流す間隔、1日あたりの件数、コード変換が必要かどうか。
これらを同じ内容で各社に伝えると、返ってくる金額が何に対する金額なのかが分かります。
逆にこの条件が曖昧なまま概算を聞くと、各社が想定している作業範囲がばらばらになり、金額だけを並べても意味を持ちません。

なお、連携を前提にすると利用料金そのものの前提も変わることがあります。
あるベンダーの例では、負荷分散とシステム連携用の構成をとったモデルケースのASP利用料金として、月額260,000円という金額が示されています¹。
これは特定の製品の特定構成における一例であり、連携の開発費用を表すものでも、他社の料金水準を示すものでもありません。
ただ、連携を行う構成ではサーバー構成やライセンスの前提が変わりうる、という点は見積もりを読むときの視点になります。

最後に、運用がどう変わるかを現実的に見ておきます。
連携で減るのは、同じ数字を別の画面へ入れ直す作業と、そのために両方の画面を見比べる確認です。
残るのは、取り込みが正常に終わったかどうかの確認、エラーになった明細の個別対応、そしてマスタの整備です。
商品コードが登録されていない新商品の注文は、方式を問わず取り込みで弾かれます。
「事故がなくなる」と考えるより、確認する場所が入力結果から取り込み結果へ移る、と捉えたほうが運用の設計は実態に近くなります。

自社の既存システム構成にどう合わせて選べばよいのか

ここまでを自社の状況に当てはめる段になります。
方式をすべて並べて比べるより、選べない方式を先に外していくほうが早く決まります。
外す基準になるのは、自社の希望では動かせない条件のほうです。

既存システム側のAPI対応有無で分ける

最初に効いてくるのは、つなぎたい相手システムがAPIを提供しているかどうかです。
提供されていればカスタマイズによる連携が選択肢に入り、提供されていなければCSVによるファイル連携が現実的な手段になります²。
ここは検討の初期に確かめておく価値があります。
後から分かると、比較していた製品の前提が崩れるからです。

確認先は既存システムのベンダー、または社内の保守担当です。
ただ「APIはありますか」とだけ聞くと、答えが曖昧になりがちです。
受注データを登録できるか、商品マスタを取得できるか、在庫数を参照できるか。
やりたいことの単位で聞くと、できる範囲とできない範囲がはっきり返ってきます。

パッケージ製品の場合、APIの利用が上位エディションやオプション契約に限られていることもあります。
使えると分かっても、追加契約や版数の更新が前提になるなら、それ自体が導入計画の一部になります。
「技術的に可能か」と「いまの契約で使えるか」は別の質問だと考えておくと、確認が一度で済みます。

社内・委託先の開発体制で分ける

APIが提供されていても、それだけでは決まりません。
カスタマイズによる連携は、要件を決める人と、動かし続ける人の両方を必要とします²。
導入時に仕様を決めるだけでなく、既存システムの更新に合わせて改修が必要になったとき、誰が手を動かすのか。
ここが空白のまま作った連携は、数年後に触れる人がいない状態になりがちです。

社内に情報システム部門があるのか、保守を外部に委託しているのか。
委託しているとして、その委託先は受発注システム側の仕様まで見てくれるのか、それとも既存システム側だけなのか。
連携は二つのシステムの間にあるので、どちらの担当でもない領域が生まれやすい部分です。
誰が全体を見るのかを先に決めておくと、障害が起きたときの初動が変わります。

体制を用意できない場合、即時性を多少あきらめてでもCSV連携で確実に回すほうが、結果として業務は安定します。
1日1回の受け渡しでも、手入力の打ち直しがなくなれば、転記に伴う突き合わせ確認は減ります。
まずCSVで連携の運用を軌道に乗せ、在庫の即時反映など本当に必要な部分だけを後から別の方式で検討する、という進め方も現実的です。

取引先の標準EDI対応で分ける

三つ目は、社内事情とは別の軸です。
取引先が流通BMSのような業界標準EDIで発注してくるなら、導入を検討しているWeb受発注システムがその規格に対応できるかを、他の比較よりも先に確認する必要があります³。
対応できなければ、その取引先の注文だけ別の仕組みで受けることになり、減らしたはずの手作業が別の形で戻ってきます。

確認を具体的にするには、取引先から指定されている内容を控えておくことです。
流通BMSが対象としているのは卸売(またはメーカー)と小売の間の取引で、発注・出荷・受領・返品・請求・支払の6業務について8種類の標準メッセージが規定されています³。
自社が扱うのが発注と出荷だけなのか、請求や支払まで含むのかによって、必要な対応範囲は変わります。
規格名とバージョン、対象業務、接続先の取引先数をまとめてベンダーに伝えると、対応可否の回答が具体的になります。

なお、流通BMSは消費財流通業界の卸-小売間取引を主対象とした規格であり、すべての業種・取引形態に当てはまるものではありません³。
取引先がこの範囲の外にいるなら、標準EDIではなく個別の取り決めによるファイル交換や、Web受発注システムの画面をそのまま使ってもらう形が候補になります。
自社の取引先がどの類型に分かれているのかを整理しておくと、全社一律で考えるより検討が現実的になります。

三つの軸のうち、取引先の要件だけは期限とともに外から降ってくることがあります。
社内の検討順序を飛び越えて「この時期までに対応を」と求められると、選定をやり直す余裕はありません。
先に確認しておくと、方式選びそのものが後戻りしにくくなります。

連携方式の選択は、既存システムがAPIを提供しているか、どのデータをどの間隔で流すかという自社固有の条件で先に絞られるため、一般的な比較だけでは決まりません。

現在お使いの販売管理・在庫・会計システムの構成と、いま手作業で移し替えている項目をお聞かせいただければ、CSVでのファイル連携で足りる範囲と、カスタマイズが必要になる部分の切り分けをご説明します。無料相談で要件を整理する

連携方式を決める前に確かめておく条件

自社の希望で決められる条件と、既存システムや取引先の都合で決まってしまう条件の両方を洗い出す観点から挙げています。

• つなぎたい既存システム(販売管理・在庫・会計など)がAPIを提供しているか、提供されているとして受注登録や在庫取得などどの操作まで対応しているか

• そのAPIが現在の契約・エディションで使えるか、追加契約やバージョン更新が前提になるか

• 連携したいデータの種類と向き(受注を出すのか、商品・在庫・組織情報を取り込むのか)

• データを流す間隔と、両システムの数字がずれる時間帯を業務として許容できる範囲

• 取引先コード・商品コード・単位・税区分などのコード体系が両システムで一致しているか、変換表を誰が保守するか

• 取引先から業界標準EDIでの接続を求められているか、その規格名・バージョン・対象業務

• カスタマイズが発生した場合に、要件定義と将来の改修を担う体制が社内または委託先にあるか

要点の整理

軸	判断の基準
相手システムのAPI提供	提供あり→カスタマイズによる連携が選択肢／提供なし→CSVによるファイル連携が現実的
連携できるデータ	注文・配送・在庫・商品・組織などが対象として示される例がある。向きと、両側の出力・取込機能の有無で決まる
データの鮮度	CSVは書き出しと取り込みの間隔だけ数字がずれる。許容できるかが方式選びの実質的な基準
取引先の標準EDI	流通BMSは卸-小売間の6業務・8種メッセージ。指定があれば製品の対応可否を最優先で確認
開発・保守の体制	カスタマイズは要件定義と将来の改修の担い手が必要。用意できなければCSVで確実に回す
連携後に残る作業	取り込み結果の確認、エラー明細の個別対応、マスタ整備は方式を問わず残る
効果の目安	国の実証事業で業務時間が平均51.4%削減。12件・6業界の実証参加企業での数値

取引先から業界標準EDIでの接続を求められている場合や、連携したいデータが複数のシステムにまたがる場合は、方式の比較だけでなく構成そのものの検討が必要になります。 取引先から指定されている規格や対象業務、連携したいデータの種類と件数をもとに、必要な連携方式と構成の考え方、確認しておくべき既存システム側の条件をお伝えします。

よくある質問

流通BMSに対応していないWeb受発注システムでも取引先と連携できるか

取引先が流通BMSでの接続を指定している場合、その規格に対応していない製品でEDI接続することはできません。
流通BMSは卸売(またはメーカー)と小売の間の取引業務を対象に、発注・出荷・受領・返品・請求・支払の6業務について8種類の標準メッセージを規定した標準EDI規格です³。
規格に対応していない場合は、その取引先の注文だけFAXやメール、取引先側のWeb画面で受け、受けた内容を自社システムへCSVなどで流す形にならざるを得ません。
一方、流通BMSが対象としているのは消費財流通の卸-小売間取引であり³、取引先がこの範囲外であれば、個別の取り決めによるファイル交換など別の手段で連携できる場合があります。
まず取引先から指定されている規格名と対象業務を確認するところから始めてください。

API連携は必ず個別のカスタマイズ開発が必要になるのか

製品によります。
ただ、相手システムがAPIを提供している場合にカスタマイズによってシステム連携する、という位置づけをとっている製品もあります²。
この場合、APIがあること自体は前提条件にすぎず、そこからどの項目をどのタイミングでやり取りするかを個別に決める作業が残ります。
検討中の製品については、標準で接続できる相手システムがあらかじめ決まっているのか、それとも相手ごとの個別対応なのかを確認してください。
この区別がはっきりすると、見積もりに含まれる作業範囲も読み取りやすくなります。

CSV連携で会計システムの仕訳データまで自動反映できるか

連携の対象システムとして会計システムが挙げられている製品はあります²。
ただし、受発注側から渡せるのは売上や請求の元になる明細データで、それを仕訳の形に組み立てるのは会計システム側の取込定義の役割です。
勘定科目や補助科目、税区分、部門をどの項目から決めるのか、会計システムが受け取れる形式に変換できるのかで、実際に自動で反映できるかが分かれます。
「データを渡せる」ことと「そのまま仕訳になる」ことは別なので、会計システム側の取込仕様を先に確認するのが近道です。
変換が必要な場合、その変換をどちらのシステムで行うかも決めておく必要があります。

連携方式を選ぶ前に既存システム側で確認しておくべきことは何か

データの出口と入口です。
必要な項目を既存システムから出力できるか(出力形式や項目の指定がどこまで効くか)、そして外部から取り込めるか(取込機能があるか、取込時に必須となる項目は何か)。
この二つが分からないと、受発注システム側の機能だけを比べても連携の可否は判断できません。
もうひとつが更新のタイミングです。
夜間バッチでしか反映されない処理が既存システム側にあると、受発注システム側をいくら即時にしても、全体の反映はその間隔に合わせることになります。
いずれも製品カタログではなく既存システムのベンダーや保守担当に確認する内容で、この回答が揃って初めて方式の比較が意味を持ちます。

1. 1　出典：株式会社フライトソリューションズ「EC-Rider B2B Ⅱ 料金プラン・費用ページ」（2026年）
2. 2　出典：株式会社フライトソリューションズ「EC-Rider B2B Ⅱ 外部システム連携ページ」（2026年）
3. 3　出典：一般財団法人流通システム開発センター(GS1 Japan)・流通BMS協議会「流通BMS(流通ビジネスメッセージ標準)公式解説」（2025年）
4. 4　出典：中小企業庁「企業間のデータ連携で、受発注の業務コストを削減する！(ミラサポplus)」（2020年）