受発注システムのAPI連携とは？方式の違いと会計・EC・取引先連携で確認すべき条件

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

B2B EC-COLUMN

受発注のAPI・EDI連携で解消できる業務範囲

取引先から届いた注文書を見ながら、自社のシステムへ品番と数量を打ち直し、その内容をまた出荷や請求のために入力し直す。
この打ち直しをなくしたくてAPI連携を調べ始めると、標準EDI、ベンダーが公開するAPI、複数のシステムを橋渡しする基盤といった言葉が並び、どれが自社の話なのか分かりにくくなります。
連携でなくせるのは、相手から届いた注文内容を人がもう一度入力する作業です。
中小企業共通EDIの実証プロジェクトでは、中小企業全体で平均51.4%の業務時間削減が報告されています（平成28年度、12件の集計）⁴。
ただしその効果を実現する仕組みは一つではなく、標準EDI・個別ベンダーのAPI・データ連携基盤では取引先に求める前提が違います。
選べる方式は、自社のシステムが何に対応しているかだけでなく、取引先が何に対応しているかによって決まります。

紙やメール、FAXで受けている注文は、届いた時点ではまだデータになっていません。
担当者が注文書を読み、品番と数量、納期、届け先を自社の受発注システムへ入力して、はじめて社内で扱える形になります。
その先でも、倉庫へ出荷を指示するための情報、請求を起こすための情報と、同じ注文が形を変えて何度も入力されます。
転記ミスが起きるのは、この読み替えの回数だけ間違える機会があるからです。

打ち直しが増えると、時間だけでなく確認の手間も増えます。
数量が一桁違えば欠品や過剰在庫になり、届け先を取り違えれば出荷したあとに回収が要ります。
間違いを防ごうとして読み合わせや二重チェックを足せば、今度は確認の工数が積み上がります。
入力そのものを減らさない限り、確認を厚くする方向にしか進めない、というのが紙やFAXのままでの限界です。

API連携やEDI連携は、この読み替えの入口をなくす仕組みです。
EDIは企業間で注文や出荷、請求などのデータをあらかじめ決めた形式でやり取りする仕組みを指し、APIはシステム同士が決められた手順でデータを受け渡すための接続口を指します。
呼び方は違っても、担当者が目で読んで打ち直していた内容が、品番や数量といった項目ごとに区切られたデータとして届き、そのまま登録される点は共通しています。
入力欄を埋める作業と、埋めた内容が元の注文書と合っているかを目で確かめる作業が、まとめて不要になります。

では、どの程度の削減になるのか。
中小企業庁の支援で行われた中小企業共通EDIの実証プロジェクトでは、12件の集計として中小企業全体で平均51.4%の業務時間削減が報告されています⁴。
ただしこれは平成28年度に実施された特定の実証事業の集計値であり、対象となった企業の取引件数や紙の比率によって内訳は変わります。
自社でも半減する、と読み替えることはできませんが、受発注のやり取りにかかる時間がまとまって減りうる規模の話だとは言えます。

一方で、連携しても残る作業があります。
届いたデータの品番が自社のマスタに登録されていなければ、受け取った側で登録するまで処理は進みません。
単価や納期の条件が普段と違う注文、電話で口頭の追加があった注文も、そのままでは自動で流れません。
連携で消えるのは同じ内容を人が打ち直す作業であって、届いた内容が妥当かを判断する作業ではない。
この線引きで考えると、導入後に自分の手元へ何が残るかを見積もりやすくなります。

API連携にはどんな方式があるのか

ここまでの削減は、一つの決まった製品で実現するものではありません。
受発注のデータをやり取りする仕組みには、業界で共通の仕様を決めておく方法、ソフトの提供元が接続口を公開する方法、間に変換役を置く方法があります。
違うのは技術の細かさではなく、誰が仕様を決めるのか、そして取引先に何を求めるのか、という点です。
ここが分かると、自社だけで進められる話と、相手の判断を待つ話を分けて考えられます。

標準化されたEDI（流通BMS・中小企業共通EDIなど）

流通BMSは、消費財流通業界の卸売・メーカー・小売の間で交わす受発注、出荷、請求、値引などのメッセージと、通信の手順やセキュリティを定めたEDIの標準仕様です²。
仕様の管理と商標の登録は、一般財団法人流通システム開発センターが行っています²。
同じ仕様に沿っていれば、相手が変わってもデータの形は共通なので、取引先ごとに項目を作り分ける必要がありません。
ただしこの仕様が対象としているのは消費財の流通であり、会計や在庫、ECといった分野へそのまま当てはまるものとしては示されていません²。

もう一つの標準が、中小企業庁が2020年度から認証を始めた中小企業共通EDIです¹。
この方式では、標準に対応したプロバイダーと契約すると、プロバイダー側が取引先ごとに必要なデータ形式へ変換するため、異なる受発注システムの間でも個別に作り込まずデータを流せるとされています⁴。
自社のシステムを取引先の数だけ改修する、という負担を一か所に寄せる考え方です。
言い換えれば、標準EDIは「業界やプロバイダーが決めた形に双方が合わせる」方式であり、合わせる相手がいて初めて成立します。

個別ベンダーが提供するAPI

業界で仕様を決めるのではなく、ソフトの提供元が自社システムへの接続口を公開している場合もあります。
たとえばfreee会計は、ECサイトや受発注システムと接続するための連携ガイドラインと会計APIリファレンスを公開しており、これに沿って取引先や勘定科目などのマスタ情報と、取引の登録処理を対応づける実装が必要とされています³。
この方式で相手になるのは取引先ではなく、自社が使っている別のソフトです。

違いは、進め方に表れます。
取引先の合意や投資判断を待たなくても検討を進められる代わりに、接続の仕様は提供元が決めたものに従うことになります。
また、接続口が公開されていることと、自社がすぐ使える状態にあることは同じではありません。
ガイドラインとリファレンスに沿って実装するという前提が置かれている場合、誰がその実装を担うのかまで含めて考える必要があります³。

複数システムを橋渡しするデータ連携基盤

三つ目は、異なるシステムの間に変換役を置く考え方です。
中小企業庁は2021年に、業界やサプライチェーンの系列ごとに異なる電子受発注システムへ接続し、入力されたデータを自動変換する「データ連携基盤」の開発を発表しました¹。
取引先のシステムを個別に立ち上げなくても受発注業務を一元管理できるとされ、2022年中の運用開始を予定するものとして公表されています¹。

ここで押さえておきたいのは、これが発表時点の構想だという点です。
その後の運用状況や普及の度合いは、本記事で扱っている資料からは確認できません。
検討の候補に入れるなら、現在どのような形で提供されているのかを提供元へ直接確かめるところから始まります。
逆に言えば、既存のシステムを変えずに異なる相手とつなぎたい、という需要が公的な開発の動機になるほど一般的だった、とは読み取れます¹。

会計・在庫・ECなど連携先ごとのデータ対応の違い

取引先との間をつなぐ話と、自社の中でつなぐ話は、確認することが違います。
会計や在庫、ECと受発注システムをつなぐ場合、相手は取引先ではなく自社が契約しているソフトなので、交渉相手はいません。
代わりに問題になるのが、渡すデータと受け取るデータの項目が噛み合うかどうかです。

freee会計の公開されている案内では、ECサイトや受発注システムと連携する際に、連携ガイドラインと会計APIリファレンスに沿って、取引先や勘定科目などのマスタ情報と、取引の登録処理を対応づける実装が必要とされています³。
ここから読み取れるのは、連携が二つの層に分かれるという構造です。
一つは、どの取引先をどの勘定科目で処理するかといった、先に揃えておく情報。
もう一つは、注文や売上が起きるたびに流れる情報です。
前者が揃っていなければ、後者は受け取り先で行き場を失います。

この構造が分かると、連携がうまく動かないときの見方も変わります。
毎日の取引がまとめて止まっているのか、特定の取引先の分だけ落ちているのかで、見るべき場所がマスタ側か取引データ側かに分かれるからです。
金額が合わないときも、差額の大小から原因を決めつけず、どの取引が落ちているのかを明細で突き合わせて判断することになります。
連携は「動くか動かないか」ではなく、「どの条件のデータが通り、どの条件で止まるか」で見る対象です。

ECサイトと受発注、会計をつなぐ場合、データは一方向にだけ流れるわけではありません。
注文が立つと受注のデータが起こり、在庫が引き当てられ、出荷後に売上として計上されます。
どのシステムを起点にして、どの段階のデータを次へ渡すのかで、連携の組み立ては変わります。
起点をあいまいにしたまま複数の画面から登録できる状態にすると、同じ注文が二重に残る原因になります。

ただし、ここまでの具体的な項目の話はfreee会計という特定のソフトの公開情報に基づいています³。
他の会計ソフトや在庫管理システム、ECのカートでは、項目の名前も連携の手順も、そもそもAPIが公開されているかどうかも異なります。
「会計と連携できます」と書かれていても、何と何が対応づくかは製品ごとに決まっているため、候補が絞れた段階で各社の仕様書に当たる以外に確かめる方法はありません。
自社が日々入力している項目、たとえば品番、数量、単価、税区分、取引先コード、納期が、相手側のどの欄に入るのかを一覧にしてみると、埋まらない欄がそのまま手作業として残る部分になります。

取引先の受発注システムと連携する際の制約

自社の中の連携と違って、取引先とつなぐ場合は相手の事情がそのまま条件になります。
発注する側は注文データを送り、受注する側はそれを受け取って、出荷や請求のデータを返します。
流通BMSが受発注だけでなく出荷、請求、値引のメッセージまで定めているのは、やり取りが一方向では終わらないからです²。
自社がどちらの立場であっても、相手が同じ形式を扱えなければ、送っても受け取ってもらえず、受け取っても返せません。

中小企業共通EDIによる連携には、取引先も同じ仕組みを導入していることが前提になるという制約が指摘されてきました¹。
データ連携基盤が、既存のシステムを変えずに接続できる仕組みとして構想されたのも、この前提が実際の壁になっていたためです¹。
自社側の準備が整っていても、取引先が紙のままであれば、その相手との間の転記は残ります。
方式の検討を自社の都合だけで進めると、ここで手戻りになります。

取引の関係によって、どちらが仕様に合わせるかも変わります。
発注側が業界標準を使っていれば、納入する側はその標準に合わせて受け取る形になりますし、発注側が独自の発注サイトを運用していれば、受注側はその画面から取り込む方法を探すことになります。
自社が受注側で、相手ごとに異なる仕組みへ個別に合わせている状態は、取引先が増えるほど負担が積み上がります。
取引先ごとの形式変換を担う仕組みが用意されてきたのは、この積み上がりを一か所へ寄せるためです⁴。

どのくらいの相手が対応しているのかは、業界によって事情が違います。
流通BMSは2025年6月時点で21,600社以上が導入していると公表されていますが、これは消費財流通業界を中心とした集計であり、他の業種で取引先がどの程度対応しているかを示すものではありません²。
一方、電子受発注システムそのものの導入率は、2021年9月の時点で約2割という水準が示され、2023年をめどに約5割へ引き上げる目標が掲げられていました¹。
自社の取引先が対応している可能性は、業界の慣行や相手の規模によって大きく変わると考えておくのが現実的です。

自社の状況でAPI連携を導入・検討する際に確認すべき条件

方式の違いも、制約がどこから来るのかも見えてきました。
残るのは、自社の場合に何を確かめれば方式が絞れるのか、という点です。
費用や改修の要否は契約やシステム構成によって変わるため、ここでは金額ではなく、判断が分かれる条件に絞って挙げます。

自社システムの対応方式を確認する

最初に見るのは、いま使っている、あるいは導入を検討している受発注システムが、どの方式に対応しているかです。
標準EDIに対応しているのか、提供元がAPIを公開しているのか、他システムとの受け渡しはCSVの取り込みだけなのかで、検討できる範囲が変わります。
同時に確かめたいのが、対応しているとして、それが追加の開発なしで使える機能なのか、実装を前提とした接続口の提供なのか、という点です³。
ここを取り違えると、「対応済み」という回答をもらったのに、社内に実装できる人がいないという状態で止まります。

主要取引先の対応状況を確認する

次が取引先です。
取引件数の多い相手から順に、受発注のデータをどの形で扱っているかを聞くことになります。
相手が業界標準を使っているのか、自社専用の発注サイトを持っているのか、紙やFAXのままなのか。
この答えで、標準に合わせるのか、形式の変換を挟むのか、その相手は当面対象外とするのかが分かれます。

聞き方も結果を左右します。
「APIに対応していますか」と尋ねるより、「注文データをどの形式で送れますか、受け取れますか」と尋ねるほうが、相手の担当者も答えやすくなります。
取引先も同じ仕組みの導入が前提となる方式では、相手の投資判断を待つことになるため、自社の都合だけでは進みません¹。
だからこそ、相手の返事を待つ範囲と、待たずに動ける範囲を先に分けておく意味があります。

連携先ごとのデータ項目をベンダー仕様書で確認する

三つ目が、会計・在庫・ECなど自社内の連携先との項目の対応です。
ここは取引先と違って相手の意向に左右されませんが、確認の粒度は最も細かくなります。
品番、数量、単価、税区分、取引先コード、納期といった項目が、連携先のどの欄に入るのか。
対応する欄がない項目は、連携後も誰かが別に管理することになります。
具体的な項目名や登録の手順は製品ごとに決まっているため、各ベンダーの仕様書で一つずつ突き合わせる必要があります³。

全部を一度につなごうとすると、取引先の返事待ちで検討全体が止まります。
自社内の連携は相手の合意がいらないので、受発注と会計・在庫・ECの間から着手し、取引先との連携は対応状況が分かった相手から広げる進め方もとれます。
この場合、紙で届く注文は当面残りますが、入力したあとの社内の転記は先に減らせます。

この三つを押さえると、「連携できるかどうか」という大きな問いが、「どの相手と、どのデータを、どの方式で」という答えの出る問いに変わります。
逆に、ここが曖昧なまま製品を比較すると、機能一覧を見比べる時間ばかりが増えます。

取引先の対応状況によって現実的な選択肢がどう変わるかは、次の整理で確かめられます。

受発注とECや会計をどこまでつなげるかは、製品の機能一覧を見比べても決まらず、実際に流れている注文データの項目を並べてはじめて判断できるためです。

扱っている注文の件数と項目、いまどの画面へ何を転記しているかを持ち寄れば、接続でどの転記が減り、どこに確認作業が残るのかを具体的に確かめられます。無料相談で要件を整理する

取引先対応状況と連携方式の対応関係（整理）

取引先が自社と同じ仕組みに対応しているかという条件で整理しています。

• 取引先も同じ標準に対応している：業界標準EDIや中小企業共通EDIのように、双方が同じ仕様で送受信する方式が現実的になる

• 取引先は電子化しているが仕様が揃わない：取引先ごとに必要な形式へ変換する仕組みを間に置く方式が検討対象になる⁴

• 取引先の対応が当面見込めない：連携の対象を自社内（受発注と会計・在庫・EC）に絞り、取引先との受領は従来の方法を残す

• 連携先が自社内のシステム：提供元が公開するガイドラインとAPIに沿って接続し、取引先の判断を待たずに進められる³

取引先の数が増えて対応状況がばらついてきたら、相手ごとに個別対応する方式から、形式の変換を一か所へ寄せる方式へ検討を切り替えます。

要点の整理

確認する軸	判断の基準
自社システムの対応	標準EDI対応かAPI公開か。追加開発なしで使える機能か、実装前提の接続口か
主要取引先の対応	業界標準・専用の発注サイト・紙やFAXのどれか。取引件数の多い相手から確認する
連携先の項目対応	品番・数量・単価・税区分などが相手のどの欄に入るか。製品ごとに異なるため仕様書で突き合わせる
効果の見積もり	平均51.4%は平成28年度の実証12件の集計値。自社の件数と紙の比率で変わる
連携後も残る作業	マスタ未登録の品番、条件の異なる注文、口頭で追加された分の確認

取引先ごとに対応状況がばらついている場合、どこから着手すれば効果が出るのかを自社だけで見極めるのは難しいためです。 取引先の対応状況と自社システムの対応方式を並べて見れば、いま接続できる範囲と、当面は従来のやり方で残る範囲を切り分けて考えられます。

よくある質問

取引先が標準EDIや個別ベンダーのAPIに対応していない場合、連携はあきらめるしかないのですか

取引先とのやり取りだけが連携ではありません。
受発注システムと会計・在庫・ECをつなぐ部分は自社内の話なので、相手の対応状況に関係なく進められます³。
この場合、注文を受け取る入口は紙やFAXのまま残りますが、一度入力したあとに出荷や請求へ回していた転記は減らせます。
また、取引先ごとに必要なデータ形式へ変換する仕組みを間に置く方式も示されており、相手のシステムが自社と同じでなくても連携の余地が検討されてきました⁴。

受発注システムのAPI連携は、会計・在庫・EC以外に取引先のシステムと直接つなぐこともできますか

できます。
企業間で注文や出荷、請求のデータをやり取りする仕組みがEDIであり、流通BMSのように業界で共通の仕様が定められている分野もあります²。
ただし、自社内の連携と違って相手の対応が前提になります。
中小企業共通EDIによる連携では、取引先も同じ仕組みを導入していることが前提になるという制約が指摘されてきました¹。
取引先とつなぐ場合は、自社の準備と相手の対応状況を並行して確かめることになります。

API連携による業務時間の削減効果は、業種や企業規模によって変わりますか

公表されている51.4%という数値は、平成28年度に実施された中小企業共通EDIの実証プロジェクト12件について、中小企業全体で集計した平均です⁴。
特定の実証事業の集計値なので、すべての業種や企業で同じ効果が出ることを示すものではありません。
削減の大きさは、いま紙やFAXで受けている注文の件数、一件あたりの明細数、入力後に何回転記しているかによって変わります。
自社で見積もるなら、まず受注一件が社内でいくつの画面を通っているかを数えるところから始めると、減らせる範囲がつかめます。

個別ベンダーのAPI（freeeなど）を使う場合、自社に開発の専門知識がなくても連携できますか

freee会計の公開されている案内では、連携ガイドラインと会計APIリファレンスに沿って、取引先や勘定科目などのマスタ情報と取引の登録処理を対応づける実装が必要とされています³。
つまり、APIが公開されていることと、設定だけで使える状態にあることは別です。
受発注システム側にあらかじめ用意された連携機能があるのか、それとも接続口だけが提供されていて実装が要るのかを、双方の提供元に確認するのが確実です。
実装が必要な場合は、誰がそれを担い、仕様が変わったときに誰が直すのかまで決めておく必要があります。

1. 1　出典：株式会社日刊工業新聞社「中小企業庁が中小企業の電子受発注実現へ開発する「データ連携基盤」の全容」（2021年）
2. 2　出典：一般財団法人流通システム開発センター（GS1 Japan）「流通BMS（流通ビジネスメッセージ標準）公式サイト」（2025年）
3. 3　出典：freee株式会社「freee会計 ECサイト連携ガイド（Developers Community）」（2026年参照）
4. 4　出典：中小企業庁経営支援部「企業間のデータ連携で、受発注の業務コストを削減（ミラサポplus）」（平成28年度）