BtoB EC API連携｜設計の注意点7つと要件整理

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

B2B EC-COLUMN

BtoB ECのAPI連携とは何か——バッチ・EDIとの違い

BtoB ECのAPI連携とは、BtoB EC（Web受発注システム）と基幹システム（販売管理・在庫管理・会計システム）の間で、受注・在庫・商品・取引先などのデータをHTTPを介して機械可読な形式で相互にやり取りする仕組みです。

冪等キーとは、同一の要求を複数回実行しても同じ結果を得られるようにするための一意識別子である。API連携において重複注文を防ぎ、再送ルールの安全性を担保する仕組みです。基幹システム側も冪等キーに対応する必要があります。

BtoB ECのAPI連携で設計時に押さえるべき注意点は、連携範囲の主従・同期方式・認証認可・冪等性・エラー設計・流量制御・法令対応の7つです。2024年のBtoB-EC市場規模は514.4兆円^*1に達しており、連携設計の巧拙が業務品質を左右する場面が増えています。

バッチ・EDI・APIの違い——リアルタイム性と標準仕様の有無で選ぶ

基幹連携の方式は大きく3つに分かれます。バッチ（CSV／FTP）はファイルを定期的に受け渡す方式、EDI（Electronic Data Interchange、電子データ交換）は取引先間で定型フォーマットを取り決めて送受信する方式、APIはHTTPで都度データを要求・応答する方式です。

いずれもデータをやり取りする点は共通ですが、リアルタイム性・初期コスト・標準仕様の有無が異なります。方式選定を誤ると、必要な即時性が得られないか、逆に過剰な開発コストを払うことになります。

市場の電子化とINSネット終了が設計を急がせている

経済産業省の令和6年度デジタル取引環境整備事業（電子商取引に関する市場調査、2025年8月26日公表）によると、2024年のBtoB-EC市場規模は514.4兆円で、前年の465.2兆円から10.6%増加しました^*1。BtoB-ECのEC化率も43.1%となり、前年比3.1ポイント増です^*1。

並行して、EDIの通信基盤として使われてきたINSネットの終了時期が明確になっています。NTT東日本・西日本は2024年3月7日、INSネット64・INSネット64ライト・INSネット1500について、2028年12月31日に提供を終了すると発表しました^*2。新規申込の受付は2024年8月31日で終了しています^*2。既存EDI回線からAPI・専用線への移行を検討する事業者にとって、期限が具体的な数字で示された形です。

注意点①：連携データの「主従」を7領域ごとに固定する

対象となる7領域（受注・在庫・商品・取引先・価格・出荷・請求）

連携設計でまず決めるべきは、何を連携するかの範囲です。一般に対象となるのは、受注・在庫・商品・取引先・価格・出荷・請求の7領域です。領域ごとに更新頻度も重要度も異なるため、一括りに「全部連携する」と決めてしまうと、後工程での手戻りが大きくなります。

例えば在庫は分単位で変動しますが、取引先マスタは月に数回しか変わりません。同じ粒度で扱う必要はなく、領域ごとに個別の方針を立てることが出発点になります。

どちらのシステムをマスタ（正）とするかを領域ごとに固定する

次に決めるべきは、どちらのシステムをマスタ（正、データの原本）とするかです。BtoB ECと基幹システムの双方で同じ項目を更新可能にすると、更新の競合が起き、どちらの値が正しいか判断できなくなります。

実務では、受注・出荷はBtoB EC側で発生しやすく、在庫・商品・取引先・価格は基幹システム側がマスタになるケースが多く見られます。ただし業種・業務フローによって最適な組み合わせは変わるため、領域ごとに「どちらが正か」を要件定義書に明記し、双方向で書き込み可能な項目を作らないことが重要です。

項目・桁数・コード体系の整合（標準仕様を参照する意義）

マスタが決まったら、項目名・桁数・コード体系を両システムで一致させます。商品コードの桁数が異なる、取引先コードの体系が違う、といった不整合は連携後に頻発する不具合の典型です。

消費財流通業界では、一般財団法人流通システム開発センターと流通システム標準普及推進協議会が策定する流通ビジネスメッセージ標準（流通BMS、基本形Ver2.2）が、メッセージ項目とコード体系の標準仕様を提供しています^*9。自社の業界に対応する標準仕様がある場合は、独自にコード体系を設計するより、標準を参照したほうが取引先との整合コストを抑えられます。

注意点②：同期方式とタイミングは業務要件から逆算する

リアルタイム／準リアルタイム／日次バッチの切り分け（表②）

連携範囲と主従が決まったら、領域ごとの同期タイミングを決めます。すべてをリアルタイム化すると開発・運用コストが膨らむため、業務上どこまでの遅延が許容できるかを起点に設計します。

ポーリング・Webhook・バッチの適性と運用コスト

同期の実装方式には、一定間隔でAPIを呼び出すポーリング、イベント発生時に相手先へ通知するWebhook、まとめて処理するバッチがあります。ポーリングは実装が単純な一方、呼び出し頻度が高いとサーバー負荷が増えます。

Webhookは即時性に優れますが、受信側の可用性が前提になるため、失敗時の再送設計が欠かせません。バッチは負荷を予測しやすい半面、即時性を犠牲にします。領域ごとの許容遅延に合わせて、これらを組み合わせるのが現実的です。

締め時間と営業日カレンダーのずれが二重更新を招く

同期タイミングの設計では、締め時間や営業日カレンダーの扱いも決めておく必要があります。BtoB ECと基幹システムで締め時刻の解釈がずれると、同じ取引が二重に計上されたり、逆に計上漏れが起きたりします。

祝日・特殊営業日を含むカレンダーをどちらのシステムが管理するかも、要件定義の段階で合意しておく論点です。

注意点③：認証・認可はOAuth 2.0の標準仕様に寄せる

認可コードフロー＋PKCEを使う（RFC 9700）

API連携では、誰が・どのシステムとして・どこまでアクセスできるかを制御する認証・認可の設計が欠かせません。IETFが公表したRFC 9700「Best Current Practice for OAuth 2.0 Security」（BCP 240）は、OAuth 2.0（Open Authorization、外部サービスに認証情報を渡さずにアクセス権限だけを付与する仕組み）の実装で推奨される方式を整理した文書です^*3。

同文書は、認可コードフローにPKCE（Proof Key for Code Exchange、認可コードの横取りを防ぐ追加の検証手順）を組み合わせて使うことを推奨しています^*3。取引先システムとの連携でも、この組み合わせを基本形とするのが妥当です。

インプリシット・ROPCは非推奨と明記されている

RFC 9700は、インプリシットフロー（トークンをリダイレクトURLに直接含める方式）や、リソースオーナーパスワードクレデンシャル（ID・パスワードを直接送信する方式）について、脆弱性のリスクが相対的に高い運用方式として扱っています^*3。ベンダーの提案がこれらの方式を前提にしている場合は、なぜその方式を選んだのかを確認する価値があります。

古い実装例をそのまま踏襲すると、標準の見直しに追随できなくなる点にも注意が必要です。

取引先IDの越権参照を防ぐ設計が必須（OWASP API1:2023）

OWASP（Open Worldwide Application Security Project）が公表するOWASP API Security Top 10 2023では、API1:2023として「Broken Object Level Authorization」（オブジェクトレベル認可の不備）を最上位のリスクに挙げています^*4。これは、あるユーザーが自分以外のデータ（他の取引先の受注情報など）にIDを差し替えるだけでアクセスできてしまう不備を指します。

BtoB ECのAPIでは、取引先IDをURLやパラメータに含める設計が一般的です。認証さえ通れば別の取引先のデータも参照できてしまう実装にならないよう、リクエストごとに「認証されたユーザーが、指定した取引先IDのデータにアクセスする権限を持つか」をサーバー側で検証する設計が求められます。

注意点④：冪等キーを設計し、重複注文を防ぐ

冪等なメソッドは自動再試行しても結果が変わらない前提がある（RFC 9110）

冪等性（べきとうせい。同じリクエストを複数回送っても結果が1回送った場合と変わらない性質）は、API連携の可用性を左右する論点です。IETFのRFC 9110「HTTP Semantics」（STD 97）では、GET・PUT・DELETEなどのメソッドを冪等と定義し、接続エラー時にクライアントが自動的に再試行してよい根拠として位置づけています^*5。

一方でPOSTメソッドは冪等と定義されていません^*5。注文登録のような処理をPOSTで実装したまま単純に自動再試行すると、通信が不安定な環境で同じ注文が複数回登録される恐れがあります。

注文APIにIdempotency Keyを持たせる

この問題への対応として、注文APIのリクエストに冪等キー（Idempotency Key、リクエストごとに発行する一意の識別子）を持たせる設計が広く使われています。サーバー側で同じキーのリクエストを検知した場合は、新規登録せず最初の処理結果を返す仕組みです。

冪等キーの発行元・有効期限・保持期間をどちらのシステムが管理するかは、実装前に取り決めておく必要があります。

自社の数字でこの論点を確かめるには、無料相談で要件を整理するのが近道です。

タイムアウト時の再送で二重計上させない運用ルールを決める

タイムアウトが発生した場合、クライアント側は「処理が失敗した」のか「処理は成功したが応答が届かなかった」のかを区別できません。ここで単純に再送すると、後者のケースで二重の受注登録が発生します。

冪等キーによる重複排除に加え、タイムアウト後の状態確認手順（受注番号や処理結果を問い合わせるAPIを別途用意するなど）を運用ルールとして定めておくと、二重計上のリスクを抑えられます。

注意点⑤：エラー表現とログの保管ルールを仕様に含める

機械可読なエラー表現にproblem+json形式を使う（RFC 9457）

API連携では、エラー時のレスポンス形式も事前に取り決めが必要です。IETFのRFC 9457「Problem Details for HTTP APIs」は、HTTPステータスコードだけでは伝えきれないエラーの詳細を、機械可読なJSON（またはXML）形式で表現する仕様で、旧規格のRFC 7807を廃止して定められました^*6。

この形式（application/problem+json）を採用すると、エラーの種別・詳細・発生箇所を構造化して受け渡せるため、連携先システムでのエラーハンドリングが実装しやすくなります。

業務エラーとシステムエラーを区別して返す

エラー設計では、在庫不足や与信超過のような業務エラーと、サーバー障害やタイムアウトのようなシステムエラーを分けて返すことが大切です。業務エラーは業務担当者が対処でき、システムエラーは開発・運用担当者が対処するというように、対応する部門が異なるためです。

この区別が曖昧だと、本来は在庫を確認すれば済む問題が、システム障害として調査対象になってしまうことがあります。

相関IDを付け、連携ログの保管期間を決める

連携トラブルの原因調査を早めるには、リクエストごとに相関ID（一連の処理を追跡するための識別子）を発行し、両システムのログに残す設計が有効です。相関IDがないと、どのリクエストがどの応答に対応するかを突き合わせる作業だけで時間がかかります。

ログの保管期間は、後述する電子帳簿保存法の要件とも関係するため、法務・経理部門と合わせて確認しておく必要があります。

注意点⑥：流量制御は締め日のピークを基準に見積もる

レート制限・件数上限・ページングを事前に確認する

APIには一般に、一定時間あたりの呼び出し回数を制限するレート制限や、1回のリクエストで取得できる件数の上限が設けられます。OWASP API Security Top 10 2023は、API4:2023として「Unrestricted Resource Consumption」（無制限なリソース消費）を挙げ、こうした制限を設けないことがサービス妨害や運用コスト増につながるリスクだと位置づけています^*4。

連携先のAPIが持つレート制限・上限件数・ページング方式（データを分割取得する仕組み）を事前に確認し、自社の想定リクエスト量が制限内に収まるかを検証しておく必要があります。

月初・締め日のアクセス集中を基準に設計する

取引データの多くは月初・月末・締め日に集中します。平常時のアクセス量だけを基準に設計すると、締め日にレート制限へ抵触したり、処理が滞留したりする恐れがあります。

ピーク時の想定件数を洗い出し、レート制限に収まるようリクエストを分散させる、あるいは事前にバッチ処理へ切り替えるといった対応を、設計段階で組み込んでおくことが望まれます。

全件同期をやめ、差分同期に切り替える

連携の初期段階では、実装の単純さから全件同期（毎回すべてのデータを送受信する方式）を選びがちです。しかしデータ量が増えると、通信時間・処理負荷ともに増大し、締め日のピークと重なった場合に処理が終わらなくなるリスクがあります。

更新日時やバージョン番号を使って変更分だけを送受信する差分同期に切り替えることで、通信量を抑えられます。設計の初期段階から差分同期を前提にしておくと、後からの作り直しを避けられます。

注意点⑦：電子帳簿保存法の保存要件を連携項目に組み込む

EDI・API受発注データも電子取引データとして保存義務の対象になる（国税庁 問40）

API連携で見落とされやすいのが、法令上の保存要件です。電子取引を行った場合は、その取引情報に係る電磁的記録を保存しなければなりません。国税庁「電子帳簿保存法一問一答【電子取引関係】」（令和8年7月）の問40は、EDI取引で授受した電子取引データについて、保存すべきデータは実際に授受したデータそのものに限定されず、取引内容が変更されるおそれのない合理的な方法で編集したデータによる保存も可能である旨を示しています^*7。API連携で授受される受発注データも、同様に電子取引データとして扱われます。

連携設計の段階でこの保存要件を組み込んでおかないと、稼働後に保存項目の追加対応が必要になり、システム改修と運用ルールの見直しが同時に発生します。

真実性の確保はタイムスタンプか訂正削除防止規程で満たす（同 問33）

電子取引データの保存では、データが後から不正に書き換えられていないことを示す「真実性の確保」が求められます。同一問一答は、正当な理由がない訂正・削除の防止に関する事務処理規程を定めて運用する方法を、対応の一つとして挙げています（問33）^*7。タイムスタンプを付与する方法と、社内規程を整備して運用する方法のいずれかを選ぶことになります。

連携システムのどちらがこの規程の運用主体になるか、あるいはタイムスタンプ機能をどちらが持つかを、設計段階で決めておく必要があります。

取引年月日・取引金額・取引先の検索要件を連携項目に含める

保存したデータは、税務調査等の際に検索できる状態でなければなりません。検索の条件として求められるのは、取引年月日・取引金額・取引先です。連携項目の設計時にこれらの項目を漏れなく含め、検索可能な形式で保存できるようにしておく必要があります。

この検索要件を後から連携項目に追加しようとすると、既存の連携仕様全体を見直すことになり、影響範囲が大きくなります。要件定義の段階でチェック項目に含めておくことが、手戻りを避ける近道です。

仕様の合意とテストは、OpenAPIでの文書化から始める

OpenAPI Specificationでインターフェース仕様を固定する

ここまでの7つの注意点を整理したら、双方の合意事項をドキュメントとして固定します。OpenAPI Initiative（Linux Foundation傘下）が策定するOpenAPI Specificationは、プログラミング言語に依存しない形でHTTP APIのインターフェースを記述する標準仕様で、最新版はv3.2.0（2025年9月19日公開）です^*8。

エンドポイント・パラメータ・認証方式・エラー形式をOpenAPI形式で記述しておくと、人が読める仕様書であると同時に、モックサーバーやテストコードの自動生成にも使える機械可読な仕様として機能します。口頭やExcelでの仕様共有に比べ、認識のずれを防ぎやすくなります。

結合テスト・並行稼働・切り戻しの段取りを事前に決める

仕様が固まったら、結合テストの計画に移ります。個々のAPIが単体で動くことの確認だけでなく、締め処理や月末バッチのような業務シナリオに沿った結合テストを行うことが重要です。

本稼働の前には、旧方式（バッチやEDI）と新しいAPI連携を一定期間並行稼働させ、結果を突き合わせる段取りを組んでおくとリスクを抑えられます。並行稼働中に問題が見つかった場合に、旧方式へ切り戻す手順もあらかじめ用意しておく必要があります。

責任分界点とSLAを契約に書き、内製に必要な工数を見積もる

連携システムは自社と取引先・ベンダーの複数主体にまたがるため、障害発生時にどちらの責任範囲かを明確にしておかないと、対応が遅れます。責任分界点・SLA（サービスレベル合意）・障害時の連絡経路は、契約書または連携仕様書に明記しておくべき事項です。

この設計をすべて内製で行う場合、必要になるのはAPI設計・OAuth 2.0などの認証方式・電子帳簿保存法の実務知識・結合テスト設計という複数分野の知見です。これらを1人の担当者が兼務するのは負荷が大きく、専門パートナーへの相談によって、要件の抜け漏れや手戻りのリスクを抑えられる場合があります。

まとめ：BtoB ECのAPI連携設計で押さえる3つの判断軸

本稿では、BtoB ECのAPI連携を設計する際に押さえるべき7つの注意点を、IETF・OWASP・OpenAPI Initiativeの技術標準と国税庁の電子帳簿保存法一問一答にもとづいて整理しました。要点は3つに集約できます。第一に、連携範囲とデータの主従を7領域ごとに固定し、標準仕様を参照して項目を整合させることです。第二に、認証・冪等性・エラー設計を標準仕様に寄せ、稼働後の障害対応を想定した仕様にしておくことです。第三に、流量制御と電子帳簿保存法の保存要件を、要件定義の段階から連携項目に組み込むことです。いずれも稼働後の変更コストが大きい論点であり、着手前に決定事項として合意しておく価値があります。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

API連携とCSV連携は、どちらを選ぶべきですか。

結論として、リアルタイム性が必要な領域はAPI、更新頻度が低い領域はCSV連携（バッチ）が向いています。在庫や受注のように即時反映が求められるデータはAPI連携を、月次更新程度で足りる商品マスタなどはバッチのままとする、といった使い分けが現実的です。判断軸の詳細は本文の比較表をご参照ください。

在庫はすべてリアルタイム連携にすべきですか。

在庫は常にリアルタイムである必要はありません。準リアルタイム（数分間隔程度の更新）でも、在庫切れ表示のずれによる過剰受注は一定程度抑えられます。完全なリアルタイム化は開発・運用コストが増えるため、自社の受注件数や在庫回転率を踏まえて許容遅延を決めることが現実的です。

既存の基幹システムにAPIがない場合はどうすればよいですか。

既存システムが古くAPIを持たない場合は、変換用の中間サーバー（連携基盤）を挟んでバッチ・EDIとAPIを橋渡しする方法や、基幹システム側の改修・リプレイスを検討する方法があります。どちらを選ぶかは、既存システムの改修可能性とコストにより異なります。

API連携した受発注データも電子帳簿保存法の対象になりますか。

対象になります。電子取引を行った場合はその取引情報に係る電磁的記録の保存が必要で、API連携で授受される受発注データも電子取引データとして扱われます。国税庁「電子帳簿保存法一問一答【電子取引関係】」（令和8年7月）の問40は、EDI取引について、保存するデータは授受したデータそのものに限らず、取引内容が変更されるおそれのない合理的な方法で編集したデータでもよい旨を示しています^*7。取引年月日・取引金額・取引先で検索できる状態での保存が必要です。

設計の検討は、どの工程から始めるのが現実的ですか。

連携対象データ7領域ごとの主従整理から始めるのが現実的です。主従が決まらないまま同期方式や認証方式の検討に進むと、後から範囲が変わった際に手戻りが大きくなります。本文の「要件定義で最初に固める5つの決定事項」を出発点にすることをおすすめします。

1. *1　出典：経済産業省 商務情報政策局 情報経済課「令和6年度デジタル取引環境整備事業（電子商取引に関する市場調査）」（2025年8月26日公表）https://www.meti.go.jp/press/2025/08/20250826005/20250826005.html
2. *2　出典：東日本電信電話株式会社／西日本電信電話株式会社「INSネットの新規申込受付・提供終了について」（2024年3月7日発表）https://www.ntt-east.co.jp/release/detail/20240307_02.html
3. *3　出典：IETF「RFC 9700 Best Current Practice for OAuth 2.0 Security（BCP 240）」（2025年）https://www.rfc-editor.org/info/rfc9700/
4. *4　出典：OWASP「OWASP API Security Top 10 2023」（2023年）https://owasp.org/API-Security/editions/2023/en/0x11-t10/
5. *5　出典：IETF「RFC 9110 HTTP Semantics（STD 97）」（2022年）https://www.rfc-editor.org/info/rfc9110/
6. *6　出典：IETF「RFC 9457 Problem Details for HTTP APIs」（2023年）https://www.rfc-editor.org/info/rfc9457/
7. *7　出典：国税庁「電子帳簿保存法一問一答【電子取引関係】」（令和8年7月）https://www.nta.go.jp/law/joho-zeikaishaku/sonota/jirei/pdf/0026007-006_06.pdf
8. *8　出典：OpenAPI Initiative（Linux Foundation）「OpenAPI Specification v3.2.0」（2025年9月19日）https://spec.openapis.org/oas/latest.html
9. *9　出典：一般財団法人流通システム開発センター／流通システム標準普及推進協議会「流通ビジネスメッセージ標準（流通BMS）標準メッセージと運用ガイドライン」基本形Ver2.2（項目一覧ver2.2.2・再修正版2025年7月15日公開）https://www.gs1jp.org/ryutsu-bms/standard/standard01_1.html