受発注システムの連携API仕様：発注側が確認する項目と、連携方式の選び方

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

B2B EC-COLUMN

メール・FAXの発注をAPIに替えるとき、注文の流れのどこをつなぐのか

仕入先ごとにメールやFAXで発注を送り、届いた回答を基幹システムへ打ち直していると、転記ミスや「届いたかどうか」の確認に手間を取られます。
受発注システムと仕入先をAPIでつなぐときは、仕様書を機能一覧として読むより、1件の注文の流れに沿って見ると確認漏れが減ります。
流れとは、発注の送信、変更・取消、回答の受信、状態確認です。
なかでも、通信が途切れたときに再送して二重発注にならない仕組みは、必ず確かめたい項目です。
連携方式は仕入先の対応状況で決まり、APIに限らず共通EDIやCSV・Web画面で足りる場合もあります。

発注の送信

API（Application Programming Interface）は、システム同士がデータをやり取りするための窓口と、その使い方の取り決めです。
発注側から見ると、これまで担当者がメール本文やFAXの注文書に書いていた内容を、自社のシステムから仕入先のシステムへ直接渡す経路になります。
ただし、つながるのは「注文書を送る」場面だけではありません。
1件の発注は、送ったあとも数量の変更や取消があり、仕入先から回答を受け取り、いまどの状態にあるかを確かめる、という流れをたどります。

仮に、自社の購買担当が部品Aを100個、来月10日納期で仕入先B社へ発注する場面で考えます。
メールやFAXなら、担当者が注文書を作って送り、B社の担当者がそれを読んで自社の受注システムへ入力し、納期回答を返信します。
回答を受け取った購買担当は、その内容を自社の基幹システムへ打ち直します。
この流れでは転記が2回あり、その間に「届いていますか」「回答はまだですか」という問い合わせが挟まります。
API連携は、この注文が動く場面ごとに、どのデータを誰のシステムから誰のシステムへ渡すかを決める作業だと考えると整理しやすくなります。

最初の場面は、新しい発注を仕入先へ届けることです。
自社の基幹システムや受発注システムで確定した発注データを、仕入先のAPIへ送ります。
ここで決めることは二つあります。
一つは、どの時点の発注を送るか（担当者が確定したときか、社内の承認が済んだときか）です。
もう一つは、送る項目の範囲です。

送る項目の範囲を考えるときは、中小企業共通EDIの標準仕様書の考え方が参考になります。
同仕様書は、EDIのプロバイダー（データの変換や中継を担う事業者）に対応を求める注文メッセージの全135項目と、業務アプリケーションに対応を求める最低限の13項目を分けて定めています¹。
取引で使いうる項目の全体と、どの業務システムでも最低限扱うべき項目を、別の層として考えているわけです。
発注側に当てはめると、範囲を次のように決められます。
自社の基幹システムから最初から全項目を出せなくても、まず必須の項目で送り始めます。
そのうえで、取引で実際に使う項目（たとえば納入場所や備考）を仕入先ごとに足していきます。
なお、この項目数は2018年に公開された初版を紹介する資料にあるもので、対象は注文メッセージです。
APIで連携する場合に必要な項目は、仕入先や製品ごとの仕様書で決まります。

変更・取消

発注は送ったら終わりではありません。
数量を100個から80個へ減らす、納期を前倒しする、発注自体を取り消す、といった変更が入ります。
メールなら「先ほどの注文を訂正します」と書けば、相手の担当者が読み替えてくれます。
システム同士では、どの発注のどの明細を変えるのかを、番号で特定しなければなりません。

変更をどう送るかは、仕様によって異なります。
「元の発注の更新」として送る仕様もあれば、「元を取り消して新しく発注し直す」として送る仕様もあります。
後者なら、仕入先側の受注番号が変わることもあります。
また、仕入先が受注を確定し、出荷準備に入ったあとの変更や取消を、APIで受け付けるかどうかも確かめたい点です。
受け付けない場合は、電話などで個別に調整することになります。
前述の共通EDIの項目数は注文メッセージのものです。
変更や取消のやり取りがどこまで同じ枠組みで扱われるかは、採用する仕様の本体で確かめることになります。

回答（納期・数量）の受信

仕入先は発注を受けて、そのまま受諾するか、数量や納期を変えて回答します。
この回答を自社のシステムが受け取れれば、購買担当がメールを読んで基幹システムへ打ち直す作業が減ります。
ただし、回答が「全量受諾」だけとは限りません。
たとえば、100個のうち80個は10日、残り20個は20日に分けて納める、という回答が来たとします。
自社の基幹システムが1つの発注明細に複数の納期を持てなければ、この回答は自動で取り込めず、人が判断する場面が残ります。
回答の受け取り方そのもの（自社から取りに行くのか、仕入先から届くのか）は、次の節で仕様書の確認項目として扱います。

状態の確認

4つ目は、発注がいまどの状態にあるかを確かめる場面です。
送信したが仕入先が受け付けたか分からない、回答がまだ来ない、変更が反映されたか知りたい、といったときに使います。
発注番号を指定して状態を問い合わせられる仕組みがあれば、電話やメールでの確認が減ります。
この照会の仕組みは、次の節で扱う「通信が途切れたときに再送してよいか」の判断にも使います。
送った発注が相手に届いているかを確かめられれば、届いていないものだけを送り直せるからです。

ここまでの4場面のうち、自社がどこまでを自動にしたいのかを先に決めておくと、仕様書のどの章を重点的に読むかが定まります。
送信だけを自動にし、回答は画面で確認するという始め方もあります。
その場合でも、変更・取消と状態の確認がどう扱われるかは、二重発注や行き違いに関わるので省けません。

▼ 図の内容を文字で読む

1. 発注の送信：確定した発注データを仕入先へ渡す
2. 変更・取消：発注番号と明細で対象を特定して送る
3. 回答の受信：受諾・数量変更・納期変更・分納を受け取る
4. 状態の確認：発注番号で受付や回答の状況を照会する

仕様書で確認する項目：識別子・認証・エラー・再送と重複防止・回答受信

発注データの項目と識別子

仕様書を受け取ったとき、項目一覧を上から順に読むと、どこが自社の運用に効くのかが見えにくくなります。
発注側にとって、手戻りや二重発注に直結するのは次の4点です。
注文をどう特定するか、誰として接続するか、失敗したときにどうなるか、回答をどう受け取るか。
以下、この順に見ていきます。

識別子は、その発注や明細を一つに特定する番号やコードです。
最初に見たいのは、注文を特定する番号を誰が採番するかです。
一つは、自社の発注番号をそのまま仕入先へ渡し、仕入先がそれを保持して以後のやり取りに使う形です。
もう一つは、仕入先が独自の受注番号を返し、自社がそれを記録しておく必要がある形です。
どちらかによって、自社の基幹システムに持たせる項目が変わります。
変更や回答が来たときにどちらの番号で照合するかが決まっていないと、同じ注文なのに突き合わせられない状態が起きます。

明細の単位でも同じことが言えます。
1件の発注に複数の品目が並ぶときは、明細行番号で個々の行を特定できるかを確認します。
品目コードが、自社品番と仕入先品番のどちらを使う仕様なのかも確認します。
仕入先品番を使う仕様なら、自社側に品番の対応表（マスタ）を用意し、新しい品目が増えるたびに保守する作業が発生します。
単位（個・箱・ケース）や入数の扱いも、数量の取り違えにつながりやすいところです。
メールやFAXでは担当者同士の暗黙の了解で済んでいた部分ほど、仕様書で明文化されているかを見ておくと、後の手戻りを減らせます。

認証

認証は、接続してきたシステムが本当にその発注者かを、仕入先側が確かめる仕組みです。
方式は提供者によって異なるため、ここでは発注側が運用面で困りやすい点を挙げます。

• 資格情報（キーやパスワードにあたるもの）を誰の名義で発行するか。
  担当者個人に紐づくと、異動や退職のたびに接続が止まるおそれがある
• 有効期限があるか、更新の手順はどうなっているか
• テスト環境と本番環境で資格情報が分かれているか
• 資格情報の漏えいが疑われるときに、停止や再発行をどこへ依頼するか

これらは技術的な細部に見えますが、運用の問題でもあります。
たとえば資格情報の期限が切れて発注が送れなくなったとき、誰が気づき、どう復旧するかを決めておく必要があるからです。
購買部門と情シスのどちらが資格情報を管理するかも、この段階で決めておくと迷いません。

エラーと再送、重複発注の防止

発注側がいちばん判断に迷うのは、発注を送信したあとに応答が返ってこなかった場面です。
通信が途中で切れると、送った側からは区別がつきません。
発注が仕入先に届いていないのか、届いて登録されたのに応答だけが返ってこなかったのかが分からないのです。
ここで同じ発注をもう一度送り、実は1回目が届いていたなら、同じ注文が2件登録されます。
メールやFAXでいえば、同じ注文書を2枚送ってしまう状態です。

HTTP（Web上でデータをやり取りする通信の取り決め）の仕様であるRFC 9110は、基礎となる接続が失敗したとき、一部の要求はクライアントが自動で再試行できると述べています²。
どの要求が該当するかは、冪等性という性質で区別されます²。
冪等とは、同じ要求を何度送っても、1回送ったときと結果が変わらない性質のことです。
これを発注に当てはめると、次のように考えられます。
新しい発注を登録する要求が、送るたびに新しい注文を作る設計であれば、その要求は冪等ではありません。
そのため、機械的に再送すれば二重発注になりえます。
仕様書で「同じ発注を2回受け取ったときにどう扱うか」を確かめる理由はここにあります。
なお、これはHTTP一般の仕様から導いた考え方で、受発注APIの個別の仕様を述べたものではありません。

重複を防ぐ手段の一つとして、Idempotency-Keyというヘッダー（要求に添える付加情報）の提案があります。
この提案では、POSTやPATCHのような冪等でない要求を障害に強くするために使えるとされています³。
考え方は、発注ごとに固有の鍵を添えて送り、受け取る側は同じ鍵の要求を2回目以降は新規登録しない、というものです。
ただし、これはIETFで議論されたインターネットドラフトで、正式な標準（RFC）にはなっておらず、2025年の改訂を最後に失効しています³。
仕入先のAPIがこの仕組みを採用しているとは限りません。
名前で探すより、同じ働きをする仕組みがあるかを確かめるほうが実務的です。

仕様書で確かめたい点は、次のとおりです。

• 自社の発注番号や専用の重複防止キーを、仕入先側で重複の判定に使っているか
• 同じ番号の発注が2回届いたとき、エラーを返すのか、1回目の登録結果を返すのか
• 応答が返らなかったとき、発注番号で登録の有無を照会できるか
• エラーが、項目の不備（直してから送る）と一時的な障害（時間をおいて同じ内容を送る）などに分けて返されるか

エラーの種類が区別されていれば、自社側で「直すべきもの」と「待って送り直すもの」を振り分けられます。
一律に失敗とだけ返る仕様なら、担当者が内容を見て判断する手順を運用に組み込むことになります。
重複判定の仕組みも照会の手段もない場合は、自動再送を止める運用が現実的です。
担当者が仕入先へ確認してから送り直します。

回答の受信方式（ポーリングか通知か）

回答の受け取り方には、大きく分けて二つの形があります。
一つはポーリングで、自社のシステムが一定間隔で仕入先のAPIに「新しい回答はあるか」と問い合わせる方法です。
もう一つは通知で、仕入先のシステムが回答を確定した時点で、自社があらかじめ用意した受け口へデータを送ってくる方法です。

ポーリングは、自社側から接続しに行くだけなので、受け口を外部へ公開する必要はありません。
その代わり、問い合わせの間隔の分だけ回答の反映が遅れます。
間隔を短くすれば反映は早くなりますが、問い合わせ回数の上限が仕様で決まっている場合は、それに収める必要があります。
通知は反映が早い反面、自社側に外部から受け付ける窓口を用意し、その安全性を保つ必要があります。
自社の受け口が停止していた間の通知が再送されるのか、取りこぼした回答を後から取得する手段があるのかも確かめたい点です。

どちらの方式でも、回答に何が含まれるか（受諾・数量変更・納期変更・分納など）を確かめます。
あわせて、それを自社の基幹システムのどの項目に反映するかを対応させておきます。
この対応がないと、回答は受け取れても使えない状態になります。
前の節で見た分納の例のように、自社側が持てない形の回答が来る可能性があるなら、その回答だけは人が確認する、と最初から決めておくのも一つの方法です。

▼ 図の内容を文字で読む

• 識別子
  • 発注番号を誰が採番するか
  • 明細行番号と品目コードの扱い
• 認証
  • 資格情報を誰の名義で発行するか
  • 有効期限と更新の手順
• エラーと再送
  • 同じ発注を2回受け取ったときの扱い
  • 項目の不備と一時的な障害の区別
• 回答の受信
  • ポーリングか通知か
  • 回答に含まれる内容と反映先

▼ 図の内容を文字で読む

1. 発注を送信したが応答が返らない：届いていないのか、応答だけ失われたのか区別できない
2. 発注番号で登録の有無を照会する：照会手段がなければ仕入先へ確認する
3. 登録済みなら再送しない：登録結果を自社側へ記録する
4. 未登録なら同じ発注番号で再送する：重複防止キーがある仕様なら同じキーを添える

API・共通EDI・CSV/Web画面はどう選ぶか

比較表（仕入先側の対応、自社の開発負担、自動化の範囲）

ここまでの確認項目は、仕入先がAPIを公開している前提の話でした。
実際には、仕入先ごとに対応できる方式が異なります。
APIを用意していない仕入先もあれば、自社からの発注がごく少量の仕入先もあります。
発注を電子化する方式としては、APIのほかに、共通EDIのような標準の仕組みを使う方式、CSVファイルや仕入先が用意するWeb画面を使う方式が候補になります。
EDI（電子データ交換）は、企業間の取引データを決められた形式でやり取りする仕組みの総称です。

表のうち、共通EDIの列は公的資料で確認できる前提に基づいています。
APIとCSV・Web画面の列は、それぞれの方式の一般的な性格を編集部で整理したものです。
実際の負担や自動化の範囲は、仕入先の仕様によって変わります。

判断が分かれやすいのは、どこまで自動化できるかと、仕入先ごとの仕様の差を誰が吸収するかです。
APIは、前の節で見た再送や回答受信の仕組みが揃っていれば、送信から回答の取り込みまでを自社のシステムで完結させられます。
その代わり、仕入先ごとに仕様が異なれば、つなぐ先が増えるたびに自社側の開発と保守が増えます。
共通EDIは、形式の違いをプロバイダーが変換するため、仕入先ごとの仕様差を自社で吸収する負担を減らせる可能性があります。
ただし、仕入先側にも対応プロバイダーとの契約が必要です。

CSVやWeb画面は、仕入先に新たな開発を求めずに始めやすい方式です。
一方で、ファイルの出力・取り込みや画面入力に人の作業が残り、変更や回答も人が確認する場面が多くなります。
それでも、FAXの注文書を読み取って打ち直すよりは、データの形で渡せる分、転記の誤りは減らしやすくなります。
件数の少ない仕入先にとっては、この程度の電子化で十分なこともあります。

共通EDIの前提と注意点

共通EDIでは、受注側と発注側がともに同じ標準に対応したプロバイダーと契約すると、プロバイダーが情報を変換します。
そのため、発注側は独自のシステムを引き続き使えるとされています¹。
発注側にとっての利点は、自社の基幹システムを仕入先ごとの形式に合わせて作り直さずに済む点にあります。

一方で、同じ資料は「EDIは、1社だけが導入しても効果を得ることはできません。」と述べています¹。
発注側が自社だけプロバイダーと契約しても、仕入先が対応していなければ発注はつながりません。
共通EDIを選ぶ場合、発注側の作業は自社の契約だけでは終わりません。
仕入先へ対応を依頼し、どの取引から切り替えるかを調整する役割も担うことになります。

効果の目安として、同資料は2018年の実証事業で、中小企業の業務時間が平均して51.4%削減されたと紹介しています¹。
これは共通EDIの実証事業における平均値です。
発注側のAPI連携の効果や、自社で同じ削減が得られる見込みを示すものではありません。
また、資料が紹介しているのは2018年に公開された初版の標準です。
現在の対応プロバイダーや仕様の版は、検討の時点で改めて確かめる必要があります。

自社の基幹システムと仕入先の対応状況から、連携方式を決める手順

自社側の条件を棚卸しする

比較表の軸は、方式の性格を示すものです。
自社の判断には、もう一段、自社の条件と仕入先ごとの事情を重ねる必要があります。
前の節で見たとおり、EDIは1社だけでは効果が出ないため、取引先の状況も踏まえて導入を判断するものとされています¹。
APIでも同じ考え方が当てはまります。
発注側だけが準備を整えても、仕入先の対応がなければ連携は始まりません。

最初に、自社の発注データがどこから生まれ、回答をどこへ戻したいのかを書き出します。

• 発注データの出所：基幹システムや生産管理システムから出るのか、担当者がExcelで作っているのか
• マスタ：品目コードや取引先コード、自社品番と仕入先品番の対応表が整っているか
• 状態の反映先：仕入先の回答を基幹システムへ自動で戻したいのか、受発注システムの画面で見られれば足りるのか
• 運用体制：エラーや未回答を誰が監視し、仕入先への問い合わせを誰が担うか

発注をExcelで作っている段階なら、APIでつなぐ前に、発注データを決まった形式で出せるようにすること自体が最初の課題になります。
反対に、基幹システムに発注データと品番の対応が揃っている場合もあります。
それでも回答を戻す項目（分納や納期変更を持てるか）がなければ、送信だけ自動化して回答は画面で確認する、という段階的な形になります。
状態の反映先をどこにするかで、回答受信方式の確認がどこまで必要かも変わります。
ここを先に決めておくと、仕様書の読み方がぶれません。

仕入先別に方式を割り当てる

次に、仕入先ごとに、発注の件数や頻度、明細の多さ、変更の多さと、相手が対応できる方式を並べます。
すべての仕入先を一つの方式に揃える必要はありません。
仕入先ごとに方式が違ってよい、というのがこの段階の前提です。

割り当ての目安は、次のように考えられます。
これは仕入先の対応状況を確かめたうえで使う提案で、件数の境目を一律に決めるものではありません。

• 仕入先がAPIを公開しており、発注件数や変更が多い：API連携で、送信から回答の取り込みまでの自動化を検討する
• 複数の仕入先が同じ標準に対応したプロバイダーを使える：共通EDIで形式を揃え、自社側の接続をまとめる
• 件数が少ない、または頻度が低い：CSVやWeb画面で足りるかをまず検討する
• 電子的な方式にまだ対応していない：当面はメールやFAXを残し、対応の意向を確かめる

件数が多いのに方式が決まらない仕入先がある場合、その仕入先との調整が全体の効果を左右します。
逆に、件数の少ない仕入先にまでAPI開発を広げると、つなぐ先ごとの保守が増えます。
その結果、減らせる手間に見合わないことがあります。
仕入先に対応状況を尋ねるときは、次の節で扱う確認項目表を同時に渡すと、方式の確認と仕様のすり合わせを一度に進められます。

▼ 図の内容を文字で読む

• API連携
  • 仕入先がAPIを公開している
  • 発注件数や変更が多い
• 共通EDI
  • 複数の仕入先が同じ標準に対応したプロバイダーを使える
  • 形式を揃え、自社側の接続をまとめる
• CSV・Web画面
  • 件数が少ない、または頻度が低い
  • まず足りるかを検討する
• メール・FAX
  • 電子的な方式にまだ対応していない
  • 当面は残し、対応の意向を確かめる

▼ 図の内容を文字で読む

1. 自社側の条件を棚卸しする：発注データの出所・マスタ・状態の反映先・運用体制
2. 仕入先ごとに件数と対応できる方式を並べる：発注の件数や頻度、明細の多さ、変更の多さ
3. 仕入先別に方式を割り当てる：仕入先ごとに方式が違ってよい
4. 確認項目表を渡して仕様をすり合わせる：方式の確認と同時に進める

仕入先との仕様すり合わせとテストの進め方

確認項目表を渡す

方式が決まったら、仕様書で確かめる点を、仕入先に回答してもらう形の表にまとめて渡します。
並べる行は、たとえば次のようなものです。
識別子の扱い、認証の方式と資格情報の発行方法、重複した発注の扱い、エラーの返し方、変更・取消の受付範囲、回答の受信方式と内容、テスト環境の有無。
仕様書がある仕入先なら、該当箇所を示してもらいます。
仕様書に書かれていない点は、回答として残してもらいます。

こうしておくと、仕様書を読み込んで質問を一つずつメールで送る往復を減らせます。
仕入先ごとの違いも、同じ表の上で見比べられます。
仕入先とのやり取りは相手ごとに独立しているので、複数の仕入先への確認は並行して進められます。

試験の順序

試験は、確認する内容が積み上がる順に進めると、問題が起きたときに原因を絞り込みやすくなります。
次の順序は、一つの進め方の提案です。

1. 疎通：テスト環境に接続でき、認証が通るか
2. 正常系：1明細の発注と複数明細の発注が、意図した項目のまま登録されるか
3. 再送・重複：同じ発注番号を2回送ったとき、仕様どおり2件目が登録されないか、応答がどう返るか
4. 変更・取消：受諾前と受諾後のそれぞれで、変更や取消がどう扱われるか
5. 回答受信：全量受諾、数量変更、納期変更、分納の回答を受け取り、自社の項目へ正しく反映されるか

なかでも再送・重複の試験は、本番で起きてから気づくと影響が大きいところです。
通信断を意図的に起こすのは難しくても、同じ内容を2回送る試験なら比較的用意しやすく、仕入先側の重複判定が働くかを確かめられます。
回答受信では、通知方式なら自社の受け口を一時的に止めてみます。
止めていた間の回答がどう扱われるかを見ておくと、取りこぼしへの備えが分かります。
仕入先にテスト環境がない場合は、本番環境で試験用の発注をどう扱うかを事前に取り決めておく必要があります。
たとえば、取消の手順や、在庫・請求に影響させない方法です。

段階的な切替

試験が済んでも、すべての仕入先を一度に切り替える必要はありません。
仕入先単位で切り替えれば、問題が起きても影響をその仕入先との取引にとどめられます。

切替の直後は、一定の期間、従来のメールやFAXでも同じ発注内容を共有し、APIで届いた内容と突き合わせる方法があります。
ただし、二重に送る形になります。
仕入先とは「突き合わせ用で、受注登録はAPI側だけにする」と取り決めておかないと、それ自体が二重発注の原因になります。
突き合わせで差がなくなったら従来の経路を止め、次の仕入先へ広げます。

あわせて、APIが使えない障害時にどの手段で発注を送るかを決めておくと、停止した場面で判断に迷いません。
この場合も、障害が復旧したあとに、同じ発注をAPIで送り直してしまうおそれがあります。
どちらの経路で送った発注かを記録しておくことが、二重発注を防ぐ手掛かりになります。

▼ 図の内容を文字で読む

1. 疎通：接続でき、認証が通るか
2. 正常系：1明細・複数明細の発注が登録されるか
3. 再送・重複：同じ発注番号を2回送ったときの扱い
4. 変更・取消：受諾前と受諾後の扱い
5. 回答受信：数量変更・納期変更・分納の反映

仕入先ごとに仕様書の書き方や対応方式が違うと、自社の基幹システムで何を用意すれば足りるのかを、社内だけで見極めるのは難しくなります。

受け取った仕様書と自社の発注データの出所を照らし合わせ、識別子・再送・回答受信のどこに確認が残っているかを整理できます。無料相談で要件を整理する

要点の整理

軸	基準
つなぐ範囲	発注の送信・変更/取消・回答の受信・状態の確認のどこまでを自動化するか先に決める
識別子	発注番号と明細を誰が採番し、変更や回答をどの番号で照合するか
二重発注	同じ発注を2回受け取ったときの扱いと、登録の有無を照会する手段
回答の受信	ポーリングか通知か、取りこぼした回答を取得する手段、自社項目への反映先
方式の選択	仕入先の対応状況と発注件数で、仕入先ごとに割り当てる
共通EDI	仕入先にも同標準対応のプロバイダー契約が必要
切替	試験を積み上げ、仕入先単位で並行期間を経て本番へ

方式の割り当てや仕入先との調整の順番は、取引先の数や発注の偏りによって答えが変わります。 仕入先別の発注件数と対応状況をもとに、どの仕入先から、どの方式で切り替えるかの順序を確かめられます。

よくある質問

仕入先がAPIに対応していないとき、発注側は何から始めればよいですか。

まず、その仕入先がどの方式なら対応できるか、今後対応する意向があるかを尋ねます。
CSVファイルや仕入先が用意するWeb画面で受け付けられるなら、それで始めるのも選択肢です。
共通EDIを候補にする場合は、自社だけでなく仕入先にも同標準に対応したプロバイダーとの契約が必要になります¹。
どの方式にもすぐ対応できない仕入先には、当面メールやFAXを残します。
そのうえで、発注件数の多い仕入先から調整を進めると無理がありません。

通信エラーで発注が届いたか分からないとき、そのまま再送してよいですか。

仕入先の仕様に重複判定の仕組みがあるかどうかで判断が変わります。
同じ発注番号や重複防止キーで2回目を新規登録しない仕様なら、同じ番号で再送できます。
発注番号で登録の有無を照会できるなら、照会して未登録だった場合だけ送り直します。
どちらの仕組みもない場合は、機械的に再送すると二重発注になりえます。
仕入先へ確認してから送り直すほうが安全です。

共通EDIを使う場合、自社の既存システムは作り直す必要がありますか。

共通EDIでは、受発注双方が同標準に対応したプロバイダーと契約すると、プロバイダーが情報を変換します。
そのため、発注側は独自のシステムを引き続き使えるとされています¹。
ただし、自社のシステムからプロバイダーへどの形でデータを渡すかは、契約するプロバイダーの条件によります。
紹介資料は2018年公開の初版標準を扱っているため、現在の対応状況はプロバイダーに確かめてください。

変更・取消や回答（納期・数量）は、APIでどこまで自動化できますか。

仕入先のAPIが変更・取消や回答のやり取りを備えているか、自社の基幹システムがその内容を受け止められるかの両方で決まります。
受諾後の変更をAPIで受け付けず個別調整とする仕様もあります。
また、分納のように1つの明細に複数の納期が付く回答は、自社側がその形を持てなければ自動では取り込めません。
自動で取り込める回答と、人が確認する回答を分けて運用を組むのが現実的です。

仕入先ごとに連携方式が違うとき、確認項目表はどう共通化すればよいですか。

行は、注文の流れ（発注の送信、変更・取消、回答の受信、状態の確認）と、識別子・認証・重複の扱い・エラー・テスト環境といった確認点で固定します。
列を仕入先ごとに設け、方式によって当てはまらない行は「該当なし」と記入してもらいます。
行を揃えておけば、方式が違っても、どの仕入先で人の確認が残るのかを同じ表の上で見比べられます。

1. 1　出典：中小企業基盤整備機構（ミラサポplus）「中小企業共通EDI」（2018年公開の標準を紹介）
2. 2　出典：IETF（RFC Editor）「RFC 9110 HTTP Semantics」（2022年）
3. 3　出典：IETF httpapi WG「The Idempotency-Key HTTP Header Field（draft-ietf-httpapi-idempotency-key-header）」（2025年、失効済みのInternet-Draft）