基幹システム連携の方式｜種類・特徴と選び方

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

B2B EC-COLUMN

基幹システム連携とは何か

基幹システム連携とは、販売管理や在庫管理を担う社内システムのデータを、外部のシステムと決められた形式と時刻で受け渡す仕組みです。受け渡しの手段は、ファイル連携・データベース連携・API連携・EDIの4つに大きく分かれます。どれが適するかは、更新の頻度とデータ量、そして基幹側をどこまで改めてよいかで変わります。方式の優劣を先に決めるのではなく、自社の受発注の流れと締めの時刻から逆算して選ぶ順序が、後戻りを減らします。

連携の対象になるのは、得意先マスタ・商品マスタ・価格・在庫・受注・出荷・請求・入金の8種類が中心です。このうちマスタ系は更新の頻度が低く、受注や在庫は日々動きます。同じ連携という言葉で括っても、月に数回動くデータと分単位で動くデータでは、求められる仕組みが違います。仕分けの軸は、更新の頻度・1回あたりの件数・遅れが許される時間の3つです。最初に性質ごとに仕分けておくと、方式の検討が進めやすくなります。

連携が課題になる背景には、基幹システムの長期利用があります。2018年に公表された国の報告書は、既存システムを刷新しないまま2025年を迎えた場合に、年間で最大12兆円の経済損失が生じうると指摘しました。いわゆる2025年の崖と呼ばれる論点です。指摘から年数を経た2025年の公的機関の調査でも、既存システムの更新は続く課題として扱われています。刷新が終わらないまま外部システムだけが増えれば、つなぎ込みの負担は年ごとに重くなります。

長く使われた基幹システムでは、機能追加の履歴が積み上がり、データ項目の意味が文書に残っていない箇所が出てきます。改修に必要な調査の工数は、そのぶん膨らみます。外部との接続口が用意されていない世代の基幹システムでは、接続口を作る改修そのものが最初の関門になるでしょう。2026年に公表された企業のIT動向の調査でも、既存システムの維持と新規の投資をどう配分するかは続く論点です。この関門を避けるために、基幹側を触らない受け渡し方式が選ばれる場面もあります。

連携で解決できるのは、同じ値を二重に入力する手間と、入力の食い違いです。受注の入り口が電話・ファクス・電子メール・EDI・BtoB ECと分かれていても、基幹側の受注データに集約できれば、後続の出荷や請求は1本の流れで進みます。転記の作業が減れば、締めの時刻に間に合わせるための残業も抑えられます。入力の誤りが減ることは、出荷の誤りと返品の減少にもつながります。

一方、連携では解決できない事柄も残ります。得意先ごとに異なる価格の決め方や、締め日の例外処理といった業務の取り決めは、つないだだけでは揃いません。マスタの粒度が両側で違う場合、たとえば片方が荷姿単位、もう片方がケース単位で在庫を持っていれば、換算の規則を決めるまで数量は合わないでしょう。連携の設計に入る前に、業務側の取り決めを文書にする工程が要ります。

運用が始まった後の責任の所在も、設計の段階で決める事柄です。受け渡しが止まったとき、送り側と受け側のどちらが調べ、どこまで復旧の作業を担うのかを、書面で分けておきます。取り決めがないまま運用に入ると、障害のたびに担当の押し付け合いが起き、復旧までの時間が延びます。連携は仕組みの話であると同時に、運用の役割分担の話でもあります。

連携方式の主な種類と仕組み

連携方式は、ファイル連携・データベース連携・API連携・EDIの4つに整理できます。ファイル連携はまとまった件数をまとめて渡す方式、データベース連携は保管場所を直接読み書きする方式、API連携は1件ずつその場でやり取りする方式、EDIは企業間の取引電文を標準の形式で交換する方式です。即時性はAPI連携が高く、1回あたりの処理量はファイル連携が扱いやすいという向き不向きがあります。まずは4つについて、方式ごとの受け渡しの単位と即時性、向く場面を並べて押さえます。

ファイル連携は、CSVや固定長のファイルに複数件をまとめ、決めた時刻に受け渡す方式です。夜間にまとめて処理する運用と相性がよく、基幹側の改修を抑えやすい利点があります。反面、次の受け渡しの時刻まで相手側の値は古いままです。受注から出荷までの時間が短い商材では、この待ち時間が支障になります。ファイルの文字コードや項目の区切りが両側で食い違えば、取り込みの失敗も起きるでしょう。

データベース連携は、基幹システムの保管場所を外部から直接読み書きする方式、あるいは複製した保管場所を参照させる方式です。仲介の仕組みを挟まないため速度は出ますが、項目の追加や型の変更が相手側に直接響きます。複製を挟む形にすれば影響は薄まり、読み取りの負荷を基幹本体から切り離せます。ただし複製の遅れをどこまで許すかは、業務ごとに決める必要があります。

API連携（外部からの呼び出しに応じて処理を返す接続口を用意する方式）は、1件ずつその場で結果を返せます。在庫の残数照会や与信の可否判定のように、待たせずに答えを返したい処理に向きます。基幹側に接続口を新設する改修が要るため、初期の工数は他の3方式より膨らみがちです。呼び出しの回数が増えると基幹側の負荷も上がるので、上限や再送の決めごとを併せて設計します。

EDIは、企業間で受発注や請求の電文を標準の形式で交換する仕組みです。流通業向けの標準仕様では、発注・出荷・受領・返品・請求・支払という6つの業務単位でメッセージが定められています。取引先ごとに個別の様式を作らずに済む点が利点でしょう。標準が定まっていない項目は個別の取り決めになるため、取引先ごとの差分は残ります。請求のやり取りでは、標準仕様に沿ったデジタルインボイスの整備も2026年時点で進んでいます。

EDIでは、電文の形式に加えて通信手順の世代も確認が要ります。固定電話網のIP化に伴い、旧来の通信手順を支えてきた回線サービスは、2024年に公表された案内で新規の申し込み受付と提供の終了時期が示されました。手順の移行は取引先との調整を伴うため、着手から完了までの期間を見込んで計画します。期日を危機として煽る必要はありませんが、切り替えの順番は早めに決めておくほうが安全です。

自社の商流に合わせた要件整理を進めたい場合は、無料相談で要件を整理するのが近道です。

方式ごとのメリットと注意点

方式の比較は、即時性・改修の影響範囲・障害時の切り分けやすさという3つの軸で見ると整理できます。即時性を上げるほど1回あたりの処理は軽くなる一方、呼び出しの件数が増え、基幹側の負荷と監視の手間は上がります。改修の影響範囲は、基幹側に接続口を新設するかどうかで大きく変わるでしょう。障害の切り分けは、受け渡しの記録が1件ずつ残る方式のほうが追いやすくなります。3つの軸は互いに引っ張り合うため、どれを優先するかを先に決めます。

ファイル連携は、まとまった件数を1回で渡す処理に向きます。ただし次の受け渡しの時刻まで値は更新されないので、在庫の引き当てを即時に返す用途には向きません。API連携は1件あたりの応答が速い反面、大量の一括更新には向きません。両方が要る場合は、日々の一括はファイル連携、照会はAPI連携と、用途で分ける設計が現実的です。用途で分ければ監視の対象は増えますが、どちらか一方に無理をさせるより運用は安定します。

改修の影響範囲は、基幹側にどこまで手を入れるかで決まります。ファイル連携は出力の機能を追加するだけで済む場合があり、既存の処理への影響を抑えやすい方式です。データベース連携は、項目の追加や型の変更がそのまま相手側に響くため、変更のたびに双方の確認が要ります。API連携は接続口の新設が前提となるので、初期の工数は増えますが、内部の作りを外に見せずに済みます。

運用に入ってから差が出るのは、障害の切り分けです。ファイル連携では、渡したファイルと取り込みの記録が残るため、どの時点の値まで反映されたかを後から追えます。API連携は1件ずつの記録が残る半面、呼び出しの失敗が散発すると、どの取引が抜けたかを探す手間がかかります。いずれの方式でも、受け渡しの記録を後から追える形で残す設計にしておくと、原因の特定が早くなるでしょう。

復旧のしやすさも方式で変わります。まとめて渡す方式は、失敗した回の分をもう一度渡せば戻せる場合があり、手順を決めやすい利点があります。1件ずつ渡す方式では、同じ依頼が重ねて届いても結果が変わらない作りが要ります。この作りがないまま再送を繰り返すと、受注の重複という別の障害を生みます。

切り分けの遅れは、業務の損失に直結します。受注データの取り込みが止まったまま気づかなければ、出荷の指示が出ず、納期の遅れと欠品の連絡が積み上がります。締めの時刻をまたいで停止すれば、請求の締めにも影響が及ぶでしょう。停止を検知する仕組みと、誰が何分以内に気づくかの取り決めは、方式の選定と同じ重さで検討する事柄です。

方式の比較では、社内の体制も判断の材料になります。接続口の設計、受け渡しの監視、取引先ごとの電文の差分の吸収は、それぞれ別の知識を要します。担当が1人に集中していると、その人が離れた時点で運用が止まりかねません。内製で進めるか外部の支援を受けるかは、方式そのものよりも体制の厚みで決まる面があります。

BtoB ECと基幹システムをつなぐ際の論点

BtoB ECと基幹システムをつなぐ場合、論点は得意先別の価格・与信・在庫という3点の同期に集まります。同じ商品でも得意先ごとに単価が違い、掛け売りの与信枠が設定され、引き当て可能な在庫も出荷元ごとに分かれるためです。これらを画面に即時で出すのか、日々の受け渡しで足りるのかによって、選ぶ方式が変わります。受注データの取り込みから、与信と在庫の引き当て、出荷指示、売上の計上までの流れを先に描き、どこで基幹側と突き合わせるかを決めます。

得意先別の価格は、BtoB EC側で持つか基幹側で持つかを決めます。基幹側に価格の決め方が集約されている場合、BtoB EC側では都度問い合わせて表示する形が整合を保ちやすくなります。ただし表示のたびに問い合わせると、画面の応答が基幹側の混み具合に引きずられます。閲覧の多い価格だけを写しておき、注文の確定時に基幹側で再計算する折衷も採られます。

与信は、注文を受け付けてよいかの判定です。与信枠を超える注文をそのまま通せば、出荷後に回収の問題が残ります。判定を即時に返すには接続口が要りますが、注文の確定を保留にして基幹側の判定を待つ運用でも成り立つでしょう。どちらを選ぶかは、注文から出荷までに許される時間の長さで決まります。与信枠の残りを画面に出すかどうかも、取引先との関係を踏まえて決める事柄です。

在庫の同期は、引き当ての二重取りを避ける設計が中心になります。BtoB EC側に写した在庫数を見せる場合、写した時点から実際の残数は動き続けます。仮の引き当てを立てて基幹側で確定させる流れにすれば二重取りは避けられますが、仮の引き当てが滞留したときの解放の規則が要ります。滞留を放置すると、在庫があるのに注文を受けられない状態が生まれます。

受注データの取り込みのタイミングは、締めの処理と合わせて決めます。日々の締めの直前にまとまった件数の取り込みが走ると、締めの処理と競合して両方が遅れます。取り込みの時刻を締めの前後どちらに寄せるか、締めの最中は取り込みを止めるかを、運用の設計に含めます。月末の締めでは、月をまたぐ受注の扱いを先に決めておくと、計上のずれを防げるでしょう。

受発注のチャネルが複数ある場合、集約の順序も論点になります。電話・ファクス・電子メール・EDI・BtoB ECの5つが並存している状態では、まず取扱件数の大きいチャネルから基幹側の受注データに寄せると効果が見えます。すべてを同時に切り替えると、障害時に切り分ける対象が増え、業務が止まる範囲も広がります。段階を分けて寄せるほうが、戻す判断もしやすくなります。

これらの論点は、方式の選定より先に決める事柄です。価格・与信・在庫のどれを即時にするかが決まれば、必要な接続口の数と受け渡しの回数はおのずと絞られます。逆に方式を先に決めると、業務の要件に合わせるための例外処理が増え、運用の負担が残ります。判断の順序を守ることが、後戻りを減らす近道になります。

自社に合う連携方式の選び方

方式の絞り込みは、更新頻度の確認・データ量の見積もり・即時性の判断・改修可否の判断という4つの順序で進めます。更新の間隔が日単位で足りるならファイル連携が候補に残り、分単位や秒単位の応答が要るならAPI連携が中心になります。1回に動く件数が大きければ、まとめて渡す方式のほうが安定するでしょう。最後に、基幹側へ手を入れられるかどうかで、残った候補が絞られます。

更新頻度の確認では、データごとに許される遅れの時間を書き出します。商品マスタの反映が翌日で足りる一方、在庫の残数は数分の遅れでも注文の取りこぼしにつながる、といった差が見えてきます。すべてを即時にすると費用と運用の負担が上がるため、即時にする対象を絞ることが実務的です。遅れが許される範囲を数値で決めておくと、後の監視の基準にもなります。

データ量の見積もりでは、1回の受け渡しで動く件数と、繁忙期の伸びを見ます。年に数回の繁忙期に件数が跳ねる業種では、平常時の件数だけで設計すると、繁忙期に処理が終わらない事態が起きます。件数が増えたときに受け渡しの回数を増やせるか、1回の処理時間がどこまで伸びるかを、設計の段階で確かめます。見積もりの根拠は、過去の受注の実績から取ります。

即時性の判断では、画面に出す値と、後続の処理に渡す値を分けて考えます。画面の表示は写した値で足りても、注文の確定は基幹側の最新の値で判定する、という分け方ができます。すべてを即時にそろえるより、判定の瞬間だけ基幹側に問い合わせるほうが負荷を抑えられるでしょう。この切り分けは、業務側の担当と一緒に決める必要があります。

改修可否の判断は、基幹システムの世代と保守の契約に左右されます。接続口の新設が契約の範囲外であれば、費用と期間の見積もりを取り直すことになります。改修できない場合は、出力ファイルを受け取る方式や、複製した保管場所を参照する方式が現実的な選択肢です。社内で対応できる人員が限られている場合も、基幹側を触らない方式が選ばれます。

実現の手段は、自社開発・連携ツールの導入・外部サービスの利用の3つに分かれます。自社開発は要件に合わせやすい半面、作った後の保守を自社で抱えます。連携ツールは接続口の作り込みを減らせますが、扱える形式や手順の範囲を先に確かめる必要があります。外部サービスの利用は初期の負担が軽い一方、取引先ごとの個別要件をどこまで吸収できるかが分かれ目でしょう。2026年に公表された国の通信利用動向の調査でも、企業が外部のサービスを利用する流れは続いています。

判断の材料がそろっても、社内だけで結論を出しにくい場面は残ります。方式の選定には、基幹システムの内部の作り、取引先の受発注の慣行、運用に回せる人員という3つの知識が同時に要ります。3つのうち欠けている部分がある場合は、外部の設計支援を受けて要件を整理するほうが、後戻りの費用を抑えられます。判断そのものを外に委ねるのではなく、判断の材料をそろえるための支援と捉えると使いやすくなります。

連携の設計と移行で押さえる実務ポイント

設計と移行では、連携仕様書の整備、データ項目マッピングの作成、疎通確認、異常系の確認、並行稼働、切り替え判定という順で作業が進みます。設計工程で決めた項目の意味が曖昧なまま検証工程へ進むと、値の食い違いが移行工程で表面化します。運用監視と記録の保存は、切り替えの後ではなく設計の段階から組み込みます。工程ごとに合格の条件を先に決めておけば、判断が個人の勘に寄りません。

連携仕様書の整備では、受け渡しの単位・時刻・件数の上限・文字コード・失敗時の扱いという5点を書き出します。項目の名称だけでなく、桁数と型、空欄を許すかどうかまで決めます。送り側と受け側が同じ文書を見る状態を作れば、後の問い合わせが減るでしょう。文書が残らないまま口頭で決めた取り決めは、担当が替わった時点で失われます。

データ項目マッピングでは、両側の項目を1対1で突き合わせ、変換の規則を添えます。得意先コードの桁数が違う、単位が荷姿とケースで違う、といった差はこの工程で見つかります。片方にしかない項目は、初期値を入れるのか受け渡しの対象から外すのかを決めます。突き合わせの結果は、後の障害の切り分けでも参照する資料になります。

検証工程では、疎通確認と異常系の確認を分けて進めます。疎通確認は、決めた形式のデータが決めた時刻に届き、想定どおり取り込まれることを見ます。異常系の確認は、項目が欠けたとき、件数が上限を超えたとき、途中で通信が切れたときの振る舞いを見ます。正常な流れだけを確かめて本番に入ると、最初の障害で判断の材料がない状態に陥ります。

移行工程では、並行稼働の期間を設けて両方の結果を突き合わせます。旧来の手順と新しい受け渡しを同時に動かし、件数と金額が一致するかを日々確かめます。切り替え判定では、差異が出た場合に戻す条件と、戻す判断を出す人を事前に決めます。差異の原因が業務の運用側にある場合もあるため、業務側の担当も判定に加えます。

運用監視では、止まったことに気づく仕組みを先に用意します。受け渡しが済んだ記録だけでなく、届くはずの時刻に来なかったことを検知する仕組みが要ります。検知した後の連絡先と、初動で何を確かめるかを手順書にしておけば、復旧までの時間は短くなるでしょう。監視の対象には、受け渡しの件数と処理の所要時間を含めます。

電子取引のデータ保存に関する法令上の要件は、連携の設計にも影響します。取引の記録をどこに残すか、検索できる状態をどちらのシステムで保つかは、税務の判断を伴うため、所管の官公庁が公表する原典と社内の担当部門で確認します。設計の側でできるのは、記録を残す場所と期間を明示し、後から取り出せる形にしておくことです。判断そのものを設計の担当が下すのではなく、確認の経路を用意することが実務的です。

よくある質問

選んだ連携方式は途中から変更できますか

変更はできますが、費用と期間は初回の構築に近い規模になります。受け渡しの形式・時刻・失敗時の扱いを決め直し、検証と並行稼働をもう一度進めるためです。将来の変更を見込むなら、基幹側の項目の出し方を方式に依存しない形で整えておくと、切り替えの負担を抑えられます。まず更新頻度とデータ量の見積もりを丁寧に行い、初回で大きく外さないことが現実的です。

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

既存の出力機能を使う形であれば、改修を抑えたまま連携できる場合があります。決まった時刻にCSVや固定長のファイルを出せるなら、ファイル連携が候補になります。複製した保管場所を参照する方式も、基幹本体への負荷と改修を避ける選択肢です。ただし即時の在庫照会や与信の可否判定が要件に入ると、接続口の新設が避けにくくなります。

連携の費用はどのように見積もればよいですか

費用は初期の構築費と、運用が始まった後の保守費に分けて見ます。初期は接続口や変換の作り込み、項目の突き合わせ、検証と並行稼働の工数が中心です。保守は監視、取引先の追加、電文や仕様の改訂への追随が対象になります。取引先の数と受け渡しの本数が増えるほど保守側が伸びるため、初期費だけで比べると判断を誤りかねません。

EDIとAPI連携は併用できますか

併用できます。取引先との受発注はEDIの標準の形式で受け、在庫の残数照会や与信の可否判定だけをAPI連携で処理する組み合わせが採られます。併用すると監視の対象は増えるため、どちらで受けた取引かを記録に残す設計が要ります。受注データを基幹側の1か所へ集約しておけば、後続の出荷や請求の流れは1本に保てます。

連携が止まったときは誰が対応しますか

運用に入る前に、送り側と受け側の役割を書面で分けておきます。検知の担当、初動で確かめる項目、再送の判断を出す人、取引先へ連絡する担当の4つを決めておくと、復旧までの時間が短くなります。外部に構築を委託した場合も、監視と一次切り分けをどちらが担うかは契約の範囲として明示します。取り決めがないまま運用に入ると、障害のたびに調整の時間が積み上がります。

1. *1　出典：経済産業省「DXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～」（2018）　経路
2. *2　出典：独立行政法人情報処理推進機構（IPA）「DX動向2025」（2025）　経路
3. *3　出典：総務省「令和7年通信利用動向調査の結果」（2026）　経路
4. *4　出典：デジタル庁「デジタルインボイス（JP PINT）標準仕様」（2026）　経路
5. *5　出典：一般財団法人流通システム開発センター（GS1 Japan）「流通BMS標準仕様（標準メッセージ）」（2018）　経路
6. *6　出典：一般社団法人日本情報システム・ユーザー協会（JUAS）「企業IT動向調査2026」（2026）　経路
7. *7　出典：東日本電信電話株式会社（NTT東日本）「INSネットの新規申込受付・提供終了について」（2024）　経路