多拠点の受発注システムを基幹システムと連携する方法｜4つの連携方式と拠点展開の判断軸

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

B2B EC-COLUMN

拠点が増えるほど深刻になる二重入力と締めのズレの正体

拠点ごとに受けた注文が、拠点の管理表と基幹システムの両方に入力されている。
月末になると各拠点から届いた集計を本部で打ち直し、在庫と売上が合わない箇所を探す時間が積み上がっていく。
この打ち直しを減らすのが、受発注システムと基幹システムをつなぐ連携の仕組みです。
つなぎ方はAPI連携・ファイル連携・データベース連携・データ連携ツールの4つがあり、どれを選べるかは基幹システム側がAPIを備えているか、基幹の改修をどこまで許容できるかで分かれます¹。
そして多拠点では、本部一括発注と拠点直送が混在するほど、方式選び以上にマスタと拠点コードの整合をどう設計するかが重くなります。

同じ注文が二度入力される場所を数えてみる

拠点の担当者が電話やFAXで受けた注文を、まず拠点のExcelや独自の管理表に入力します。
その後、本部の担当者がその内容を基幹システムの受注画面へ入力し直す。
ここまでは二重入力として自覚されやすい作業です。

ただ、実際に手が動く回数はもう少し多いことが珍しくありません。
受注が確定すれば在庫の引当が要り、出荷が終われば売上計上、月末には請求。
それぞれの画面で、拠点から届いた紙やファイルを見ながら数字を拾っている。
転記は1回のつもりでも、受注・引当・売上・請求の4つの場面に分かれて残っているわけです。

拠点が1つなら、この程度は担当者の手際で吸収できます。
5つになると、届く様式も5通りになる。
単位の書き方がケース単位の拠点とバラ単位の拠点で違い、商品名の略し方も備考欄の使い方も揃っていない。
本部側は入力の前に読み替えをしていて、この読み替えが実のところ一番時間を食います。

締めのズレは、遅れではなく突き合わせを生む

拠点Aは毎日夕方にその日の受注をまとめて送り、拠点Bは週に一度まとめて送る。
基幹システムに入る時点が拠点ごとに違うと、ある瞬間の在庫数は、どの拠点まで反映済みかによって変わります。

困るのは、数字が古いことそのものより、どの数字を信じてよいか判断できないことです。
拠点Bの在庫が余っているように見えて他拠点への振替を指示したが、実際には3日前に出荷済みだった。
ここから始まる確認の電話とメールは、二重入力そのものより時間を取ります。

締め処理でも同じことが起きます。
月次の売上を締めようとしたら、ある拠点の当月分がまだ届いていない。
締めを待つか、暫定で締めて後から修正するか。
どちらを選んでも、翌月に「どの数字を使って締めたか」を覚えておく作業が残ります。

仕組みで変えられるのは、転記の回数と届く時点

この状態を人の努力で解こうとすると、入力フォーマットを統一する、送付の締め時刻を揃える、といった運用ルールの話になります。
ルール自体は有効ですが、拠点が増えるたびに周知と教育をやり直すことになり、担当者が替われば元に戻りやすい。

受発注システムと基幹システムをつなぐという選択は、転記の回数と、データが基幹に届く時点の二つを仕組み側に持たせる考え方です。
転記が減れば読み替えも減り、届く時点が決まっていれば、どこまで反映済みかという前提が全拠点で同じになります。

もっとも、つなげば手作業がすべて消えるわけではありません。
何が自動で流れ、何が手元に残るかは、選ぶ連携方式と基幹システム側の条件で変わります。

受発注システムと基幹システムをつなぐ4つの連携方式

API連携:リアルタイム性と基幹改修の必要性

APIは、システム同士がデータをやり取りするための窓口です。
受発注システム側が「この受注を登録してほしい」と基幹システムのAPIを呼び、基幹が受け取って結果を返す。
この方式であれば、受発注システムと基幹システムの間でリアルタイムにデータをやり取りできます¹。

多拠点では、この即時性が在庫の判断に効いてきます。
拠点Cで受注が確定した瞬間に基幹側で在庫が引き当てられれば、拠点Dの担当者が同じ在庫を見て取引先に返事をしてしまう事故が起きにくくなる。
夕方のまとめ処理まで待つ方式では、この数時間の空白が残ります。

前提になるのは、基幹システム側がAPIを備えていることです。
備えていない場合は改修が必要になることがあります¹。
長く使ってきた自社開発の基幹や古いパッケージでは、APIを外に出す部分から作ることになり、その改修の見積もりがそのまま連携の費用になります。

ファイル連携(CSV等):基幹を変えずに始めやすい

ファイル連携は、CSVなどのファイルをFTP/SFTPで受け渡す方式で、バッチ処理が中心になります¹。
受発注システムがその日の受注を書き出し、基幹システムが決まった時刻に取り込む、という形です。

利点は、低コストで、既存の基幹システムを変えずに導入しやすいことです¹。
多くの基幹システムはCSVの取り込み口をもともと持っているため、連携のために基幹へ手を入れる場面を避けやすくなります。

代わりに、反映は定期的なタイミングになります¹。
リアルタイム性を求めず、決まった時刻の反映で足りる業務であれば、この制約は実務上あまり問題になりません。
逆に、拠点間で同じ在庫を奪い合う商材を扱っている場合は、取り込みの間隔がそのまま判断の遅れになります。

多拠点で気をつけたいのは、ファイルの取り決めが拠点ごとに枝分かれしないようにすることです。
文字コード、項目の並び、拠点コードの桁数、ファイル名の付け方。
ここが拠点ごとにばらつくと、人の転記が機械の例外処理に置き換わっただけで、確認の手間は残ります。

データベース連携:スキーマ理解が前提になる

データベース連携は、基幹システム側のデータベースを直接読み書きする方式です。
柔軟に扱える一方で、スキーマ、つまりテーブルや項目の設計を理解したうえでの慎重な設計が必要になります¹。

柔軟さの中身は、基幹の画面や標準の取り込み機能では届かない項目にも手が届くことです。
受注明細に拠点固有の管理番号を持たせたい、といった要望に応えやすくなります。

一方で、直接書き込むということは、基幹システムが画面経由で行っているチェックや関連テーブルの更新を、こちら側で正しく再現する責任を負うということでもあります。
この方式が成り立つのは、基幹のデータベース構造を読める担当者が社内かベンダー側にいる場合に限られます¹。

拠点が増えるほど、影響範囲の確認も増えます。
拠点追加でマスタの構成が変わったとき、直接書き込んでいる箇所をすべて点検し直す必要がある。
最初の構築より、その後の変更のたびにかかる負荷で判断が分かれる方式です。

データ連携ツール:基幹を改修せず疎結合でつなぐ

データ連携ツールは、基幹システムと周辺システムの間に層を1つ挟む方式です。
双方を直接結合させない疎結合の構成を組み、基幹を改修せずに変換や運用を部品化できます¹。

多拠点で効いてくるのは、この部品化の部分です。
拠点ごとに様式の違うファイルが届いても、変換の処理を拠点別に用意して、基幹へ渡す形式は1つに揃える。
拠点が増えたときに手を入れるのは変換の部分だけで、基幹側の設定には触らずに済みます。

費用面では、ノーコード型ツールの導入費用が別途発生します¹。
連携の相手が受発注システムと基幹システムの2つだけなら、ファイル連携で足りることもある。
倉庫管理や会計など周辺システムが複数あり、今後も増える見込みがあるかどうかが判断の分かれ目になります。

この方式がどの程度使われているかの手がかりとして、アステリア株式会社は同社のデータ連携ツール「ASTERIA Warp」シリーズの導入社数が2023年8月1日に1万社を突破したと公表しています²。
同社は企業データ連携(EAI/ESB)製品の国内ソフトウェア市場で16年間連続シェアNo.1としていますが、これは同社調べの数字であり、第三者機関による認定かどうかはこの発表だけでは確認できません²。
いずれも1つの製品の実績なので、連携ツールという方式全体の普及率として読み替えないほうが安全です。

拠点ごとに商流が違う場合、連携設計はどう変わるか

本部一括発注と拠点直送でマスタ整合性の負荷が変わる

本部一括発注は、各拠点の必要数を本部が取りまとめ、仕入先へ1本の発注として出す形です。
基幹システムに入るのは本部名義の発注1件ですが、入荷後の在庫や原価は拠点別に分ける必要がある。
つまり連携するデータは、合算した発注と拠点別の内訳の両方を持ち歩くことになります。

拠点直送は、拠点が自分で仕入先へ発注し、納品も拠点に直接届く形です。
基幹には拠点別の発注・入荷・在庫がそのまま並ぶので、データ構造としてはこちらのほうが素直になります。
ただし仕入先マスタと単価を拠点ごとに持つことになり、同じ商品に複数の単価が並ぶ状況が生まれます。

実務で厄介なのは、どちらか一方ではなく混在している場合です。
定番品は本部一括、季節品や地場の商材は拠点直送、という分け方は珍しくありません。
同じ商品コードが、あるときは本部発注、あるときは拠点発注として基幹に入ってくる。
この状態では、連携の設計は項目の対応付け、つまり受発注側のこの欄を基幹のこの欄へ、という作業だけでは終わりません。
どの単位を正として集計するかを先に決めることが、設計の本体になります。

データベース連携がスキーマの理解と慎重な設計を必要とする¹という条件は、こうした状況で重くなります。
商流の種類が増えるほど、1つのテーブルに収めるべき区分が増え、後から拠点を足したときに影響が及ぶ範囲も広がるからです。
ただしこれは基幹連携に共通する設計上の要件から導いた見立てであり、商流の型ごとに必要な設計を定めた決まりがあるわけではありません。

対外的な標準規格(流通BMS等)が関わる場面と関わらない場面

拠点をまたぐ商流を整理していると、取引先との形式の話が混ざってきます。
流通BMS(流通ビジネスメッセージ標準)は、経済産業省の流通システム標準化事業により、日本チェーンストア協会などの業界団体が検討して策定された、小売業と卸・メーカーの間のメッセージ形式を統一するEDIガイドラインです³。
EDIは、企業間で注文や出荷のデータを電子的にやり取りする仕組みを指します。

ここで区別しておきたいのは適用範囲です。
流通BMSが対象とするのは、小売のチェーンストアと卸売業・メーカーとの対外的なデータ交換であり、小売企業内の店舗と本部の間や、受発注システムと自社の基幹システムをつなぐ内部連携そのものを規定するものではありません³。

したがって、取引先とのやり取りを標準に合わせたから社内の連携も同じ形で片づく、とは考えないほうがよい。
外向きのデータ形式は取引先と標準に従い、内向きの連携形式は自社で決める。
この二層を分けておくと、外部標準が改定されたときに社内の連携設計まで作り直す事態になりにくくなります。

逆に、外部EDIを使っている拠点と使っていない拠点が混在していると、基幹に入る手前で経路が枝分かれします。
どの拠点がどの経路でデータを受け、どこで形式が変わるのかを一覧にしておくと、連携方式を選ぶときの前提が揃います。

拠点展開は段階的に進めるか、一斉に進めるか

まず1拠点で連携を検証する考え方

方式の見当がついたら、次に出てくるのが、どの拠点から始めるかという問いです。
全拠点を同時に切り替えるほうが、二重運用の期間が生まれない分すっきりして見えます。
ただ、ここまで見てきた条件、つまり基幹の改修が要るかどうかや、マスタと拠点コードの整合をどう取るかは、机上では詰め切れない部分が残ります。

先行して1拠点で動かすと、その残りが具体的な形で出てきます。
連携したデータが基幹に入ったとき、拠点コードが変換表にない、ケースとバラの換算が合わない、値引きの持たせ方が基幹の想定と違う。
こうした不一致は、設計書を眺めているときより、実データを流したときのほうが早く見つかります。

同時に全拠点へ広げた場合、不一致が出たときに、原因がその拠点固有の運用なのか、連携設計そのものなのかを切り分けにくくなります。
切り分けに時間がかかると、拠点側は従来のやり方に戻して手入力を続けることになり、せっかく入れた連携が定着しません。

この進め方は、事例や統計で裏づけられた手順ではなく、前の節までに確認した技術要件から導いた提案です。
段階的に進めれば不一致が起きない、という保証をするものではありません。

拠点数・拠点間の業務差が大きいときの注意点

段階展開にも宿題は残ります。
連携済みの拠点と未連携の拠点が並んでいる期間は、基幹に入るデータの経路が2通りになる。
月次で締めるとき、どちらの経路の数字も同じ時点まで反映されているかを確認する作業が増えます。

この期間を短くしたいなら、先行拠点の選び方が効いてきます。
最も標準的な運用をしている拠点から始めると設計の検証はスムーズに進みますが、横展開の段階で例外に当たり、作り直しになることがある。
逆に例外の多い拠点から始めると、そこに合わせた設計が他の拠点には過剰になる可能性があります。

扱いやすいのは、標準的な拠点で基本の流れを確認し、2番目に例外の多い拠点を置いて、変換や区分の持たせ方を決めてから残りへ広げる形です。
拠点数が多い場合は、3番目以降を地域や商流でまとめ、同じ設定を使い回せる単位にしておくと、展開の回数そのものが減ります。

一斉展開が向くのは、拠点間の運用差が小さく、マスタがすでに1本化されている場合です。
差が小さければ検証で出てくる不一致も少なく、二重運用の期間を作るコストのほうが大きくなります。
自社がどちらに近いかは、拠点ごとの様式が何通りあるか、同じ得意先が別コードで登録されていないかを数えてみると見当がつきます。

連携導入の前に基幹システム側で確認しておくこと

APIは「あるか」だけでなく「何を出し入れできるか」まで見る

API連携はリアルタイムのやり取りができますが、成立には基幹システム側がAPIを備えていることが前提で、無ければ改修が必要になる場合があります¹。
そのため最初の確認はAPIの有無になりますが、実務ではその次が本題です。

受注ヘッダは登録できても明細行の値引きは登録できない、在庫の参照はできても引当まではできない、といった対応範囲の差が出ます。
自社が連携したいのは受注・在庫引当・売上計上・請求のどこまでかを先に並べ、その1つずつについて可否を聞く形にすると、返ってくる答えが具体的になります。

拠点の情報をどう持たせるかも確認項目です。
基幹側のAPIが拠点コードを受け取れるか、受け取れる場合に桁数や体系の制約があるか。
ここが合わないと、結局は連携ツールやファイル側で変換を持つことになり、方式を選んだ意味が薄れます。

改修が必要になる境目を見ておく

基幹にAPIが無い場合、選択肢は大きく二つに分かれます。
改修してAPIを用意するか、既存システムを変えずに済むファイル連携やデータ連携ツールで組むかです¹。

判断するとき、改修費用の一回きりの金額だけで比べると見誤ります。
見ておきたいのは、拠点や周辺システムが増えるたびに基幹の改修が必要になる構造かどうか。
データ連携ツールが疎結合の構成で変換・運用を部品化できる¹と言われるのは、この増えるたびの負荷を間に挟んだ層で受け止めるためです。

一方で、ツールには導入費用が別途かかります¹。
連携先が今後も受発注と基幹の2つのままなら、ファイル連携のほうが総額は収まりやすい。
今後3年の拠点計画と、社内ですでに動いている他システムの数を並べて比べるのが現実的な進め方です。

マスタ・スキーマの整合性を先に確認する

データベース連携を選ぶ場合はもちろんですが¹、他の方式でも基幹側のデータ構造は避けて通れません。
特に拠点をまたぐと、得意先コード・商品コード・拠点コードの三つで不一致が出やすくなります。

同じ得意先が拠点ごとに別コードで登録されている、統合した旧拠点のコードがそのまま残っている、という状態は珍しくありません。
連携を入れると、これまで担当者が頭の中で読み替えていた部分が、そのまま不一致として表に出てきます。

対処は、統一するか、変換表を連携側に持つかの二択です。
統一は後々が楽ですが、過去データの扱いと拠点側の慣れの問題が出る。
変換表は着手が早い代わりに、拠点追加のたびに更新する人と手順を決めておく必要があります。
どちらを取るにせよ、連携の設計に入る前に現状のコード体系を書き出しておくと、後の手戻りが減ります。

受発注システム側がどこまで対応しているかも合わせて見る

基幹側の条件が整理できたら、受発注システム側の対応方針と突き合わせます。
ここは製品によって考え方が分かれるところで、標準の連携メニューを持つ製品もあれば、個別に設計する前提の製品もあります。

一例として、株式会社フライトソリューションズはBtoB受発注システム「EC-Rider」を提供しており、同社の料金ページでは外部システム連携について画一的な仕様を示さず、要望・要件に応じて連携ツールを個別に提案するとしています⁴。
同ページのEC-Rider B2B Ⅱでは、ベースエンジン利用料が月額170,000円からと示され、負荷分散とシステム連携を見込んだ構成のモデルケースとしてASP利用料金が月額260,000円と記載されています⁴。
これは同社製品の同ページ記載の条件下での金額であり、受発注システム全般の相場を示すものではありません。

こうした情報は、金額そのものより、連携の設計が構成に含まれているかを確かめる材料として見るほうが役に立ちます。
連携を個別に設計する前提の製品では、基幹側の条件、つまりAPIの有無、改修の可否、マスタの状態をこちらから提示できるかどうかで、提案と見積もりの精度が変わります。

基幹システム側で先に確かめておく条件を、連携方式の選択が分かれる順に並べ直しておきます。

連携方式の選択は基幹システム側の条件で決まりますが、自社の基幹がどの受け渡し口を持ち、どこまで改修せずに組めるかは、社内の資料を見ているだけでは判断しきれない部分が残ります。

現在の拠点ごとの受発注の流れと基幹システムの状態を伝えたうえで、どの方式なら改修を抑えて組めるか、どのデータから連携を始められるかを具体的に確かめられます。無料相談で要件を整理する

基幹システム側の事前確認3点(API有無・改修要否・スキーマ整合性)

連携方式の選択が分かれる基幹システム側の条件から並べています。

• 基幹システムにAPIがあるか。あるとして、受注登録・在庫引当・売上計上のどこまでを扱えるか

• APIが無い場合、基幹の改修まで踏み込むか、既存を変えずにファイル連携やデータ連携ツールで組むか

• 得意先・商品・拠点のコード体系が拠点間で揃っているか。揃っていない場合、統一するか変換表を連携側に持つか

基幹の改修を許容できるかどうかで、同じ確認結果からでも選べる方式は入れ替わります。

要点の整理

軸	基準
基幹のAPI有無	APIがあればリアルタイム反映を検討できる。無ければ改修か、ファイル連携・データ連携ツールへ
基幹改修の可否	改修を避けたいならファイル連携かデータ連携ツール。ツールは導入費用が別途かかる
反映の速さ	即時の在庫引当が要るならAPI連携。決まった時刻の反映で足りるならファイル連携
社内のデータベース知識	スキーマを読める担当が社内かベンダー側にいる場合に限り、データベース連携が選択肢になる
拠点間の商流差	本部一括発注と拠点直送が混在するほど、どの単位を正として集計するかの取り決めが先に要る
外部EDIとの関係	流通BMSは対外取引の標準であり、社内の拠点間・基幹連携の形式は自社で決める
展開の順序	標準的な拠点で基本の流れを確認し、例外の多い拠点で設計を固めてから残りへ広げる

拠点ごとのコード体系や商流の違いをどこまで揃えてから連携に入るかは、拠点数と現行の運用によって答えが変わり、一般論だけでは決めきれません。 拠点別の運用差とマスタの現状を持ち寄れば、統一と変換表のどちらで進めるか、どの拠点から着手するかの見通しを立てられます。

よくある質問

基幹システムにAPIが用意されていない場合でも連携できるか

できます。
CSV等をFTP/SFTPで受け渡すファイル連携は、低コストで既存の基幹システムを変えずに導入しやすい方式です¹。
基幹と周辺システムの間にデータ連携ツールを挟み、疎結合の構成で変換を部品化する組み方もあります¹。
ただしツールにはノーコード型ツールの導入費用が別途発生するため¹、連携先が受発注と基幹の2つだけならファイル連携から検討するほうが収まりやすくなります。
どちらの方式でも基幹側にファイルの取り込み口やデータの受け渡し口は要るので、自社の基幹が何を持っているかは個別の確認が必要です。

拠点ごとにマスタコードが異なる場合、連携前にどこまで統一しておくべきか

一律の基準はありませんが、手がかりになるのは、そのコードが基幹システムの集計単位になっているかどうかです。
得意先別の売上や拠点別の在庫を基幹で集計しているなら、そのコードは統一しておくほうが後の調整が少なくて済みます。
集計に使っていない補助的なコードであれば、連携側に変換表を持たせて逃がす選択もあります。
変換表を選ぶ場合は、拠点が増えたときに誰がいつ更新するかを決めておかないと、連携は動いているのに数字が合わないという状態になりがちです。

一部の拠点だけ先に連携を始めることはできるか

技術的には可能で、どの連携方式を選ぶかで制約が変わるものでもありません。
実務で決めておきたいのは、連携済みの拠点と未連携の拠点が並ぶ期間の集計方法です。
基幹に入るデータの経路が2通りになるため、月次で締めるときに両方が同じ時点まで反映されているかを確認する手順が要ります。
段階展開と一斉展開のどちらがよいかを示す調査があるわけではないので、自社の締め業務にどれだけ負担が増えるかで判断してください。

データ連携ツールを使うと基幹システムの改修は本当に不要になるか

データ連携ツールは、基幹と周辺システムの間に層を挟んで直接結合させない構成を組み、基幹を改修せずに変換・運用を部品化できるとされています¹。
ここで前提になるのは、ツールが基幹とやり取りする入り口があることです。
ファイルの取り込み口やデータベースへの接続など、基幹側が外部とデータを受け渡す手段を何も持たない場合は、その部分への対応が必要になります。
自社の基幹がどの受け渡し口を持っているかは製品や導入時の設定で異なるため、ツールの選定と同時に確認する項目になります。

受発注システム側の対応状況は導入前にどう確認すればよいか

基幹連携に対応という表記だけでは、自社の基幹とつながるかまでは判断できません。
確認するときは、どの方式で(API・ファイル・データベース・連携ツール)、どのデータを(受注・在庫引当・売上・請求)、どの頻度で連携できるかを分けて聞くと、回答が具体的になります。
製品によっては連携仕様を固定せず、要望や要件に応じて個別に提案する方針を取っているものもあります⁴。
その場合は、基幹側のAPIの有無やマスタの状態をこちらから提示できるかどうかで、提案と見積もりの精度が変わります。

1. 1　出典：アステリア株式会社「基幹システム連携の方法｜つなぎ方・注意点・始め方を解説（ASTERIA Warpブログ）」（2026年）
2. 2　出典：アステリア株式会社「データ連携ツール『ASTERIA Warp』導入社数1万社を突破（プレスリリース）」（2023年）
3. 3　出典：経済産業省（流通システム標準化事業）／一般財団法人流通システム開発センター「流通ビジネスメッセージ標準（流通BMS）の解説」（2022年）
4. 4　出典：株式会社フライトソリューションズ「EC-Rider B2B Ⅱ 料金プラン・費用ページ」（2026年）