受発注システムの連携API仕様書で確認すべき点｜注文を最後まで流せるかの見方

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

B2B EC-COLUMN

API仕様書を渡されたとき、注文はどこまで流れるのかを先に切り分ける

ベンダーから受発注システムのAPI仕様書を渡されても、項目の多さに押されて、自社の注文が販売・在庫・会計まで途切れずに流れるのかを判断しきれないことがあります。
見る場所は絞れます。
注文から入金までのどこをAPIが受け持つか、認証と通知の方式、二重登録と取りこぼしへの備え、利用上限と変更の扱いの4点です。
それぞれが仕様書に書かれていないと業務で何が起き、自社側にどんな実装と運用が残るのかが分かれば、仕様書は導入後の手間を見積もる資料として読めるようになります。

注文から入金までの流れとAPIの受け持ち

受発注の業務データは、注文を受ける、出荷する、請求する、入金を確かめる、という順に動きます。
自社の販売管理や在庫管理を受発注システムにつなぐとき、担当者が知りたいのは、この流れのどこまでをAPIでやり取りでき、どこから先を別の手段で埋めるのかです。
仕様書の目次を上から順に読むより、先にこの四つの段階を横に並べ、仕様書に出てくるデータの種類を当てはめていくほうが、抜けている部分が見えやすくなります。

たとえば、仕様書に注文の作成と取得の操作はあるものの、出荷の状態は受発注システムの画面からしか更新できない場合を考えます。
注文は自社の販売管理へ自動で入りますが、出荷が済んだことを両方のシステムに反映するには、担当者が受発注システムの画面と自社システムの両方に入力することになります。
転記がなくなるのは注文の段階だけで、出荷の段階には手作業が残る、という読み方です。
請求についても同じように、請求書番号や請求金額をAPIで取得できるかどうかで、会計システムへの入力が自動になるのか、人が写すのかが分かれます。

公開されているAPI仕様の例では、ECプラットフォームのSquarespaceがOrders APIに注文作成の操作を用意しています²。
注文をAPIで作れるかどうかは、受発注の連携で最初に確かめる部分です。
ただし、これはECプラットフォームの仕様であり、企業間の受発注システムが同じ範囲を受け持つとは限りません。
製品ごとに、出荷や請求の状態までAPIで扱えるのかを、仕様書の対象データの一覧で見ていくことになります。

入金側は銀行のEDI情報という別の層になる

流れの最後にある入金は、銀行振込の仕組みの側でデータが動きます。
全国銀行協会の全銀EDIシステム（ZEDI）は、企業間の振込電文をXML形式にし、商品名・支払通知番号・請求書番号などの商流情報を振込に添付できるようにした仕組みです¹。
受け取った企業は、その情報を入金と売掛金の消込に使えます¹。
従来の固定長の振込電文では、添付できる情報が短く限られていました¹。

ここで押さえたいのは、添付情報を設定するのは支払う側の企業であり、ZEDIは受発注システムの注文データを運ぶものではないという点です¹。
利用するには、ファームバンキングかインターネットバンキングが必要です¹。
つまり入金消込を自動化したいという要望は、受発注システムのAPIだけでは完結せず、銀行の契約と取引先の振込の仕方にも左右されます。

そのため、受発注のAPI仕様書に入金消込の項目が見当たらなくても、それだけで仕様の不足とは言えません。
受発注のAPIで確かめるべきなのは、請求書番号などの請求情報を会計システムへ渡せるかどうかです。
振込と請求書番号を結び付ける部分は、銀行の仕組みと取引先の対応で決まります。
API仕様書で読む範囲を注文・出荷・請求までと区切っておけば、次に見る記載がかなり絞れます。

▼ 図の内容を文字で読む

1. 注文：APIで作成・更新・取得できるか
2. 出荷：出荷の状態をAPIで更新・取得できるか
3. 請求：請求書番号などをAPIで取得できるか
4. 入金：銀行の振込の仕組みの側で動く

仕様書の冒頭で見る：対象データ、認証、通知方式

対象リソースと操作（作成・更新・取得）

範囲を区切ったら、次は注文・出荷・請求のそれぞれについて、どの操作ができるかを見ます。
APIで扱うデータのまとまりをリソースと呼び、注文や在庫といったリソースごとに、作成・更新・取得のどれができるかが記載されているかを探します。
ここで紹介する仕様の例はいずれもECプラットフォームのもので、受発注システムのベンダーが同じ書き方や同じ機能を持つとは限りません。
あくまで、どこを読めば判断できるかの観点として使ってください。

注文の取得はできても更新ができない仕様だと、自社側で納期や数量を変えたときに、その変更を受発注システムへ戻せません。
その注文は二つのシステムで内容が食い違ったまま進み、出荷や請求の段階で誰かが気付いて直すことになります。
先に並べた四つの段階のうち、自社から書き戻す必要があるデータはどれかを決めておくと、取得だけで足りるのか、更新まで要るのかが判断できます。
注文の取り消しや分納のように、一つの注文の状態が途中で変わる業務がある場合は、その変化をどのリソースのどの操作で表すのかも読みどころです。

Squarespaceの例では、在庫数の調整と注文の作成が、後で触れる再送対策の付いた操作として明記されています²。
操作の一覧に加えて、どの操作にどんな保護が付いているかまで書かれている仕様書は、失敗したときの動きも読み取りやすくなります。

認証と権限の粒度

認証は、APIを呼び出す側が誰なのかを受発注システムに証明する手順です。
方式の一つであるOAuthは、パスワードを渡す代わりに、許可した範囲の操作だけを認めるトークン（一時的な通行証）を発行して使う仕組みです。

Squarespaceの通知購読のAPIでは、リクエストにOAuthトークンが必要で、イベントの種類によっては特定の権限が求められます⁵。
認証が通れば何でもできるわけではなく、与えられた権限によって受け取れる通知や呼び出せる操作が変わる、という作りです。

自社の販売管理と会計システムが、それぞれ受発注システムにつながる場合を考えてみます。
権限を注文の読み書きと請求の読み取りに分けられる仕様なら、会計側の連携には請求を読む権限だけを与えられます。
分けられない仕様だと、会計側の連携にも注文を書き換えられる権限を渡すことになり、設定の誤りや不具合が起きたときに影響の及ぶ範囲が広がります。
仕様書では、権限の一覧と、各操作にどの権限が要るかの対応が書かれているかを見ます。
あわせて、トークンの有効期限と更新の手順も読んでおくと、夜間に連携が止まって朝に注文が入っていない、という事態を設計の段階で避けやすくなります。

呼び出して確認する方式とWebhook通知の違い

新しい注文が入ったことを自社システムが知る方法は、大きく二つあります。
自社から定期的にAPIを呼び出して新しい注文がないかを確かめる方式と、受発注システムの側から変更を知らせてくるWebhookです。
Webhookは、注文の作成などの出来事が起きたときに、あらかじめ登録した自社のURLへ受発注システムが通知を送る仕組みです。

呼び出す方式は、問い合わせる頻度を自社側で決められます。
その代わり、間隔をあければ注文の反映が遅れ、間隔を詰めれば呼び出しの回数が増えて、後で触れる利用制限に近づきます。
Webhookは変更があったときだけ届くので反映は早くなりますが、通知を受け取るURLを自社で用意し、止まらないように運用し続ける必要があります。

Squarespaceでは、Webhookの受け取り先をAPIで登録し、購読の一覧・作成・取得・更新・削除のほか、シークレット（通知が本物かを確かめるための鍵）の入れ替えやテスト通知の送信もAPIで行えます⁵。
一方で、同じページには再試行や署名検証の具体的な記載がなく、別ページを参照する形になっています⁵。
通知方式を確かめるときは、購読の設定方法だけで読み終えず、通知が届かなかったときにどうなるかがどこに書かれているかまで追う必要がある、ということです。

注文の重複と取りこぼしを仕様がどう防ぎ、運用に何が残るか

送信側：冪等性キーで再送しても1回だけにする

自社システムから受発注システムへ注文を作成するリクエストを送り、応答が返る前に通信が切れたとします。
注文が受け付けられたのか、届いていないのか、送った側には分かりません。
もう一度送れば、最初のリクエストが実は通っていた場合に同じ注文が二件できます。
送らなければ、通っていなかった場合にその注文は消えます。

この迷いを仕様の側で解くのが冪等性キーです。
冪等性とは、同じ操作を何度繰り返しても結果が一度行ったときと変わらない性質のことで、リクエストに一意の値を添えて送り、受け取った側がその値で重複を見分けます。
Squarespaceでは、注文作成と在庫数調整のリクエストにIdempotency-Keyというヘッダーを付けられます²。
同じキーと同じパラメータで再送しても実行されるのは最初に成功した一回だけで、後の再送には同じ応答が返ります²。
キーには英数字・ハイフン・アンダースコアからなる一意の文字列を使い、UUIDも使えます²。

これがあれば、通信が切れたときの判断は「同じキーで送り直す」の一つで済みます。
注文が二件になる心配も、消える心配もなくなるので、再送処理を単純に作れます。

仕様書で見るのは、キーをどの操作で使えるか、キーの形式、そしてキーがどれだけの期間覚えておかれるかです。
Squarespaceは、成功して使われた後の一定期間はキーが有効であることを保証していますが、その期間はSquarespace固有の値です²。
保証期間を過ぎた後に同じキーを使った場合の扱いは明示されていません²。
自社の再送処理が、障害の翌日にまとめて送り直すような作りであれば、その間隔がキーの有効期間に収まるかを比べる必要があります。
キーの付けられない操作があるなら、その操作の再送で重複が起きたときにどう見つけて直すかを、自社で考えておくことになります。

受信側：重複排除と定期照合は自社に残る

逆向きの、受発注システムから自社へ届く通知にも同じ問題があります。
ShopifyはWebhookの仕様で、同じ通知が複数回届くことがあると明記し、冪等に処理するか、通知ごとのID（X-Shopify-Webhook-Id）を保存して既に受け取ったものを無視するよう案内しています³。
送信側の冪等性キーと違い、重複を除く処理は受け取る自社側の実装に任されています。

届かない側の問題もあります。
Shopifyでは、応答がない、またはエラーが返る場合に一定期間にわたって再試行し、連続して失敗すると、APIで作った購読が自動で削除され、警告メールが送られます³。
応答には短い制限時間があり、速やかに成功の応答を返し、受け取った通知はキューに積んで後から処理するよう勧めています³。
自社の受信処理が、通知を受けたその場で販売管理への登録まで済ませる作りだと、登録に時間がかかったときに失敗扱いになり、再試行が重なって同じ通知が何度も届き、失敗が続けば購読そのものが外れる、という順に問題が広がります。

そのうえでShopifyは、取りこぼしの穴を埋めるために、APIで定期的にデータを取得して突き合わせる照合ジョブを推奨しています³。
通知だけで注文をすべて受け取れる前提には立っていない、ということです。

ここに挙げた回数や時間の扱いはShopify固有の仕様で、受発注システムのベンダーが同じ仕組みを持つとは限りません。
それでも、二つのECプラットフォームの仕様を並べると、送信側の再送は冪等性キーで、受信側の重複は通知のIDで、取りこぼしは定期照合で、と失敗の種類ごとに別の手当てが要ることが分かります。
この整理は、受発注システムの仕様書を読む観点としてそのまま使えます。
探すのは、再試行の回数と期間、応答の制限時間、通知に重複判定用のIDが付くかどうか、照合に使える取得APIがあるかどうかです。
どれかが書かれていなければ、その分の設計と運用は自社に残るものとして見積もります。

▼ 図の内容を文字で読む

• 送信側の再送
  • 冪等性キーを付けて同じキーで送り直す
• 受信側の重複
  • 通知のIDを保存して既に受け取ったものを無視する
• 取りこぼし
  • 取得APIで定期的にデータを突き合わせる

▼ 図の内容を文字で読む

1. 通知を受信：同じ通知が複数回届くことがある
2. すぐに成功の応答を返す：応答の制限時間内に返す
3. キューに積む：登録処理は後から行う
4. 通知のIDで重複を除く：既に受け取ったIDなら無視する
5. 自社システムへ登録：販売管理などへ注文を反映する

取引量が増えたときの利用制限と、仕様変更への追従

利用制限の仕組みと待ち時間の見方

前の節で触れた再送や照合は、どれもAPIの呼び出しを増やします。
取引量が増える時期にはこれに通常の注文登録が重なり、受発注システムが設けている利用制限にかかることがあります。
利用制限とは、一定の時間に受け付けるリクエストの量に上限を設ける仕組みです。

Shopifyは、リクエストごとにコストが容量に積まれ、容量が一定の速さで回復していく方式を採っています⁴。
短い時間にまとめて送っても、平均が回復の速さを超えなければ通ります⁴。
容量が満杯になるとスロットルエラーが返り、短い待ち時間を置いてから再試行すること、やみくもに再試行しないことを推奨し、リクエストのキュー化や間引き、よく使うデータのキャッシュを勧めています⁴。
容量と回復の速さは、APIの種類とプランによって変わります⁴。

月末に取引先からまとまった注文が入り、同じ時間帯に在庫の照合ジョブも動いている場面を考えます。
上限に達すると注文の登録もエラーになり、自社の再送処理がすぐに送り直せば、さらに容量を使ってエラーが続きます。
仕様が求める待ち時間を守り、送れなかった注文を順番待ちの列に戻す作りにしておけば、反映が少し遅れても注文は失われずに入ります。
仕様書でエラーの種類と推奨される待ち方を読むのは、この再送処理を設計するためです。

制限の数え方は一例で、受発注システムが同じ方式を採るとは限りません。
リクエストの回数で数えるのか、処理の重さで数えるのかによって、一括登録をどう分けて送ればよいかが変わります。
仕様書では、方式の説明と、上限に達したときに返るエラー、推奨される待ち方の三つが揃っているかを見ます。

上限値と変更通知を仕様書で探す

Shopifyの利用制限のページには、方式の説明はあっても容量の具体的な値は載っていません⁴。
プランや契約によって値が変わる仕組みでは、上限の値が仕様の説明とは別の場所に示されることがあります。
受発注システムの仕様書でも、制限の方式の説明と、自社の契約での具体的な値がそれぞれどこに書かれているかを分けて探します。

値が分かれば、自社の取引量と比べてどれだけ余裕があるかを見積もれます。
大量の一括登録が見込まれる場合は、日中の注文登録と重ならない夜間のバッチに分ける、照合ジョブの実行時刻をずらす、といった運用が考えられます。
これは上限に近づく時間帯を減らすための工夫で、上限そのものを広げるものではありません。
どの処理をどの時間帯に動かすかを決めるためにも、値の記載は必要になります。

もう一つ、APIの仕様が変わったときにどう追従するかも、仕様書で探しておきたい項目です。
項目名の変更や古い版の提供終了が、どれくらい前に、どの手段で知らされるのか。
版の管理や変更通知の決まりは製品ごとに異なりうるため、仕様書に記載がなければ、契約前にベンダーへ書面で尋ねる項目になります。
自社の連携処理が古い版に依存したまま提供終了を迎えると、ある日から注文が入らなくなります。
通知の時期と手段が分かっていれば、改修を自社の開発計画に前もって組み込めます。

▼ 図の内容を文字で読む

1. リクエストを送る：リクエストごとにコストが容量に積まれる
2. 容量が満杯になる：スロットルエラーが返る
3. 待ち時間を置く：やみくもに再試行しない
4. キューから再送する：送れなかった注文を順番待ちの列に戻して送り直す

APIで足りるか、EDI・ファイル連携にするかの分かれ目

取引先が求める形式で決まる場合

ここまでの確認を一通り終えると、受発注システムの標準APIだけで足りるのか、自社で中継や変換の仕組みを作る必要があるのか、API以外の連携を選ぶのかが見えてきます。
ただ、この選択は自社のシステムの都合だけでは決まりません。
取引先がどの形式で注文データをやり取りしているかが、先に条件として効いてくるからです。

取引先が流通BMSのような業界標準のEDIで注文データを送受信している場合、データの形式はその取引先の求めに合わせることになります。
報道によれば、流通BMS協議会（GS1 Japan運営）の推計で、卸・メーカーの流通BMS導入企業は直近の半年でも増えています⁶。
同じ報道では、導入や改修の費用負担が大きい小規模事業者ではWeb-EDIが増えていることが、課題として挙げられています⁶。
この推計は報道を通じたもので、協議会の発表そのものではない点は割り引いて読んでください。

大手の取引先とは業界標準のEDIで、小規模な取引先とは別の手段でやり取りしている会社では、注文が複数の経路から入ってきます。
この場合、受発注システムのAPIには、各経路の注文を一つの形にまとめて自社の販売管理へ渡す役割が求められます。
そこで問われるのは、どの経路から入った注文も同じ注文番号の決まりで重複を判定できるかどうかです。
前の節で見た重複排除の考え方が、経路をまたいでも成り立つかを確かめることになります。

支払いの側も、自社だけでは決まりません。
入金消込に振込の添付情報を使いたい場合、使うのは銀行の仕組みで、ファームバンキングかインターネットバンキングの利用が前提です¹。
添付情報を設定するのは支払う側の企業なので、取引先がその情報を載せて振り込むかどうかで使い道が変わります¹。
これは受発注APIの代わりになるものではなく、請求書番号を受発注・会計・振込でそろえておけるかが接点になります。

自社で中継・変換を作る場合の負担

標準APIで足りるか、中継の開発が要るかは、ここまでで自社に残ると分かった作業の量で考えるのが一つの目安です。
重複排除、定期照合、利用制限に合わせた再送の三つは、仕様書に手当てがなければ自社で作り、動かし続ける部分です。
これらを販売管理や会計の側にそれぞれ組み込むのか、受発注システムと自社システムの間に一つの中継処理を置いてまとめるのかで、改修の範囲が変わります。

中継処理を置くと、受発注システムの仕様が変わったときの改修を中継の中に閉じ込めやすくなります。
複数の経路から入る注文の形式をそろえる変換も、一か所で行えます。
その代わり、中継処理そのものの監視と保守が新しい仕事になります。
通知を受け取るURLが止まっていないか、照合ジョブが失敗していないか、再送待ちの列に注文がたまっていないかを、誰がいつ見るのかを決めておく必要があります。

取引先の数やデータの量で、どこから中継を作るべきかを機械的に線引きすることはできません。
自社の注文がどの経路から入り、どこで転記や手作業の確認が残っているかを書き出したうえで、仕様書で埋まる部分と自社で作る部分を見比べるのが、判断を誤りにくい進め方です。
取引先や既存のシステムがファイルでのやり取りを前提にしている場合も、ファイル連携を同じ表の上に並べて、自社に残る作業を比べられます。

▼ 図の内容を文字で読む

• 標準APIで足りる場合
  • 重複排除・定期照合・再送の手当てが仕様書にある
• 自社で中継・変換を作る場合
  • 手当てが仕様書になく自社で作る
  • 複数の経路から入る注文を一つの形にまとめる
• EDI・ファイル連携にする場合
  • 取引先が業界標準のEDIやファイルでのやり取りを求める

契約・PoCの前に仕様書で確かめる項目を一覧にする

PoCで試す順の確認項目

PoC（本番の前に小さく試して実現性を確かめる検証）では、仕様書に書かれていることがその通りに動くかを、うまくいく場面より失敗の場面から確かめるほうが、導入後の手間を見積もりやすくなります。
ここまでの確認点を試す順に並べると、次のような組み方が考えられます。
決まった手順ではなく、自社の取引先や取引量に合わせて入れ替えてかまいません。

最初に、本番の注文に影響しないテスト用の環境（サンドボックス）があるかを確かめます。
Squarespaceの購読APIにはテスト通知を送る操作があります⁵。
こうした操作があれば、本番の注文を待たずに受信側の処理を試せます。

次に、同じ注文を二回送る試験です。
冪等性キーを付けて送り直し、注文が一件だけになり、同じ応答が返るかを見ます。
キーに対応していない操作で同じことをしたら何が起きるかも、ここで確かめておきます。

三つめは、通知を止める試験です。
受信用のURLを一時的に止めてから再開し、重複して届いた通知をIDで除けるか、届かなかった注文を照合ジョブで拾えるかを見ます。
止めている間に購読が無効になっていないかも、あわせて確認します。

最後に、上限に近い件数を送る試験です。
制限にかかってエラーが返ったときに、待ち時間を置いて再送し、注文が欠けずに入るかを確かめます。
一括登録の時間帯をずらす運用を考えているなら、その時間帯で試すと実際の負荷に近づきます。

ベンダーに書面で確認する項目

仕様書を読んでもPoCで試しても分からない項目があります。
障害が起きたときの連絡とサポートの範囲、稼働率などの約束（SLA）、APIの版の変更や提供終了をいつどの手段で知らせるか、サンドボックスをどんな条件で使えるか、といった点です。
これらは公開された仕様のページに書かれていないことがあり、口頭の説明だけで済ませると、導入後に認識が食い違ったときに拠り所がなくなります。
書面で回答をもらっておくのはそのためです。

尋ねる内容は、ここまでの節で記載が見つからなかったものをそのまま並べれば足ります。
冪等性キーが使える操作と有効期間、通知の再試行の回数と期間、応答の制限時間、通知に付く重複判定用のID、照合に使える取得APIの有無、利用上限の方式と自社の契約での値、版の変更の通知時期です。
Webhookのシークレットを入れ替えるときの手順と、入れ替え中に通知が届かなくなる時間が生じないかも、本番の運用に直結するので加えておきます。

書面の回答と仕様書の記載を、記事の初めに並べた注文・出荷・請求・入金の流れに戻して当てはめると、どの段階に自社の作業が残るのかが一枚にまとまります。
その一覧が、標準APIで進めるか、中継を作るか、別の連携を選ぶかを社内で決めるときの材料になります。

▼ 図の内容を文字で読む

1. サンドボックスの確認：本番の注文に影響しない環境で受信処理を試す
2. 同じ注文を二回送る試験：注文が一件だけになるかを見る
3. 通知を止める試験：重複をIDで除き、取りこぼしを照合で拾えるか
4. 上限に近い件数を送る試験：待ち時間を置いた再送で注文が欠けずに入るか

仕様書の記載が自社の注文の流れのどこに当たるかは、自社の販売・在庫・会計の構成と合わせて見ないと判断しにくいためです。

お手元の仕様書と自社の注文の流れを並べ、記載があるところと、重複排除や照合など自社で用意する部分を切り分けて整理できます。無料相談で要件を整理する

要点の整理

軸	基準
APIの受け持ち	注文・出荷・請求のどこまでを作成・更新・取得できるか。入金消込は銀行の振込の仕組みの側
認証と権限	連携先ごとに必要な範囲だけの権限を与えられるか。トークンの有効期限と更新手順が書かれているか
通知方式	呼び出し方式かWebhookか。届かなかったときの扱いがどこに書かれているか
重複と取りこぼし	送信側の冪等性キー、受信側の通知ID、照合用の取得APIの有無。記載がない分は自社に残る
利用制限と変更	制限の方式・エラー・待ち方・契約での上限値、版の変更の通知時期。記載がなければ書面で確認

PoCの試験項目やベンダーへ書面で尋ねる内容は、取引先の形式や取引量によって優先順位が変わり、社内だけでは絞り込みにくいためです。 試す順番と書面で確認する項目を、自社の取引先と注文の経路に合わせて絞り込めます。

よくある質問

仕様書に冪等性キーの記載がないとき、注文の二重登録は自社でどう防げるか

仕様の側で再送を一回にまとめる仕組みがないため、送る前に確かめる手順を自社に持たせることになります。
たとえば、自社の注文番号を受発注システム側の項目に必ず入れて送り、通信が切れたときは送り直す前に取得APIでその注文番号が既に登録されていないかを照会する、という作りです。
この方法が成り立つには、注文番号で検索できる取得APIがあること、そしてその項目で重複を受け付けない作りかどうかが分かっていることが前提になります。
どちらも仕様書に記載がなければ、ベンダーへ書面で尋ねる項目に加えてください。

Webhookが一時的に止まった場合、取りこぼした注文はどうやって拾うか

通知とは別に、APIで定期的にデータを取得して自社の登録内容と突き合わせる照合ジョブで拾います。
Shopifyも、取りこぼしの穴を埋めるためにこの照合ジョブを推奨しています³。
あわせて、連続して受信に失敗すると購読そのものが外れる仕様もあるため³、受信を再開した後に購読が有効なままかを確かめる手順も用意しておくと安心です。
照合には、更新日時などで絞り込んで取得できるAPIがあるかが効いてくるので、仕様書で確かめておきます。

APIと流通BMSなどのEDIは、同じ取引先に併用できるか

取引先との取り決め次第で、一律には言えません。
技術的に併用を考える場合に気を付けたいのは、同じ注文が二つの経路から入ってくることです。
どちらの経路で受けた注文を正とするか、両方から届いたときにどの番号で同じ注文と判定するかを決めておかないと、二重登録の原因になります。
併用するかどうかは、取引先が求める形式と、こうした重複判定を自社で持てるかを合わせて判断します。

PoCで最低限試すべきエラーケースは何か

本文で挙げた順に、同じ注文を二回送る試験、受信用のURLを止めて通知の重複と取りこぼしを確かめる試験、上限に近い件数を送って待ち時間を置いた再送を確かめる試験の三つが中心です。
これに加えて、トークンの有効期限切れや権限の不足でリクエストが拒否されたときに、自社の連携処理が止まったことに気付けるかも見ておくと、夜間に注文が入らなくなる事態を防ぎやすくなります。
いずれも決まった手順ではなく、自社の取引の形に合わせて選ぶ案です。

1. 1　出典：一般社団法人全国銀行協会「全銀EDIシステム（ZEDI）の概要」
2. 2　出典：Squarespace「Commerce APIs: Idempotency-Key」（2026年確認）
3. 3　出典：Shopify「Webhooks: HTTPS subscription」（2026年確認）
4. 4　出典：Shopify「API rate limits」（2026年確認）
5. 5　出典：Squarespace「Webhook Subscriptions API overview」（2026年確認）
6. 6　出典：LOGI TODAY「流通BMS導入企業数の推計」（2024年）