2026/8/2更新: 2026/10/26約12分で読めます

画面に出ないので再実行したら、注文が二重に。API連携で先に決めること

画面に結果が出なくても、注文の登録は済んでいることがあります。注文登録とAI要約の例で、待つ・結果を調べる・やり直す条件を比較。連携を頼む前に決めたい項目と、障害時の判断表を使えます。

影山湧亮 / NeoLogic株式会社代表取締役。元警視庁。現場業務の整理と生成AI活用・Webシステム開発を一貫して担当。

API連携では、画面に結果が出なくても、相手側への登録が済んでいることがあります。応答がないことを未登録と判断して送り直すと、同じ注文が二重に登録されるおそれがあります。

注文の取込みと、取り込んだ内容のAI要約をつなぐ場合も、工程ごとに結果を調べます。注文が登録済みで要約だけ未開始なら、注文全体をやり直さず、未開始の工程だけを再開できる条件を決めます。結果を調べられなければ、追加送信を保留して担当者が調べます。

まず、4,000円の注文を使うローカル教材の実行結果から、再送と内容の訂正をどう見分けるかを見ていきます。その後、実際の連携先へ依頼する要件と、障害時の判断表へ落とし込みます。

注文1件の応答を切り、登録結果を追ってみる

2026年10月26日、注文登録と要約開始を分けた再現用の教材（JavaScript）をNode.js 22環境で実行しました。手元のHTTP接続を登録後に切り、注文番号・金額・結果番号を照会する小さな模型です。外部APIやAIは呼び出していません。

試した操作	実行後に確認した結果	依頼する仕様へ写す点
4,000円の注文を登録した直後、応答を切る	送信側は通信エラー。登録は1件、要約開始は0回	通信エラーと未登録を区別できる照会先
同じ操作番号・同じ内容を送り直す	同じ結果番号が返り、登録は1件のまま	重複を判定する番号と内容の一致
同じ操作番号で金額だけ5,000円に変える	409の応答で拒否。保存した金額は4,000円のまま	再送と注文内容の訂正を別に扱う
未開始の要約だけ開始し、同じ操作をもう一度行う	注文は1件、要約開始は計1回	成功済みの工程を繰り返さず再開する
照会する番号が見つからない	追加登録をせず保留	見つからないことを、未実行の証明にしない

反例として、同じ業務注文を新しい操作番号で送り直すと、この模型では登録が2件に増えました。「毎回新しい番号を付ける」だけでは重複を防げません。実際には、操作番号の保存期限と、注文IDなどの業務上の重複をどう扱うかも決めます。

教材はローカルの一時ポートとメモリー内の記録だけを使います。保存して node api-order-recovery-demo-20261026.mjs を実行すると、上の結果と反例を確認できます。再起動後の記録保持、同時実行、実サービスの認証・AIの品質や費用は、この教材では確認していません。

何をつなぐか

APIは、システム同士が決められた形式で情報や処理をやり取りする窓口です。要件を決めるときは、受注確定、更新、取消など、どの出来事で何を渡すかから始めます。データごとの更新元、受け渡す方向、両側のIDの対応、連携対象外の項目を整理します。

この例では、注文内容は受注サービスで更新し、業務台帳へ取り込みます。台帳から受注サービスへ取込結果を返す場合も、注文内容の更新元は受注サービスに絞ります。通信が双方向でも、同じ項目の更新元を両側に増やさないようにします。

上段は受注サービスから業務台帳へ注文内容を一方向に渡す。下段は注文内容を台帳へ渡し、台帳から受注サービスへ取込結果を返す双方向の例。どちらも台帳の注文情報からAI要約を作り、人が読んでから台帳へ反映する。

図1　情報ごとに更新元と方向を決める（想定例）

反映期限は「次の仕事がいつ始まるか」から決めます。取込完了後に出荷準備を始めるなら、注文IDと必要な明細が台帳にそろったことを完了条件にします。AI要約は生成結果を読んで台帳へ反映するまでを別に追います。受付の応答だけで、この両方を完了扱いにしません。

実装・運用担当者へ：認証と権限

接続に使う認証情報は、担当者が交代しても管理できる保管先で扱います。必要な権限、利用先、有効期限、更新方法、失効時の再接続、退職時の扱いを決め、実際の秘密値を画面やログに出しません。OAuthを使う場合は、権限と利用先を必要な範囲に絞る考え方がRFC 9700に示されています。

ログイン済みでも、別の顧客や注文へアクセスしてよいとは限りません。受信した注文IDに対して、その利用者や接続元が読み書きできるかをサーバー側で確かめます。OWASPのAPI1:2023は、この対象ごとの権限確認が欠ける問題を扱っています。

認証が失効した場合は、同じ情報で再送し続けず、接続管理者へ知らせます。AIへ渡す注文情報も、要約に必要な項目だけに絞り、送信してよい情報とサービス側の保存条件を調べます。

実装・運用担当者へ：重複と順序

同じ業務操作を見分ける番号と、送信内容・処理状態・結果を対応させて残します。同じ番号と同じ内容なら以前の結果を返せ、内容が違えば処理を止める設計にします。同じ依頼を繰り返しても意図した効果が増えない性質を、冪等性といいます。

通信ごとに付ける要求ID、同じ業務操作を見分ける番号、相手が返す結果IDは、役割が異なる場合があります。再送のたびに重複判定用の番号まで変えないよう、どの番号を引き継ぐかを連携仕様に書きます。

HTTPの冪等性と再試行条件は、IETF／RFC EditorのRFC 9110の9.2.2節に定義されています。ただし、HTTPメソッド名だけで注文登録やAI利用の重複を防げるわけではありません。相手のAPIがどの番号を受け付け、いつまで同じ操作と見なすかを調べます。自社の要求IDを付けただけでは、相手側に重複防止機能は生まれません。

Webhookは、出来事を相手へ通知する方法です。受信時に提供元の方式で署名と時刻を検証し、イベントIDと処理状態で重複を見分けます。通知の保存と後続処理の完了は別に記録し、保存後に処理が止まったものを取りこぼさないようにします。

例えばStripeのWebhook仕様では、同じイベントの複数回配信や、発生順と異なる到着を想定します。署名が正しいことは、初回の通知である証明にはなりません。古い更新で新しい注文を上書きしないよう、更新番号や相手側の最新状態を照合します。時刻だけで順序を決めず、別サービスではその配信仕様を読みます。

応答がないとき

照合してから次の対応を決める

タイムアウトは、待っていた側が期限内に応答を受け取れなかった状態です。相手側では処理が済んでいる可能性があります。要求ID、相手側の結果ID、注文IDを使い、処理状態と内容を照合します。検索に出ないだけでは未実行と断定できません。反映の遅れや検索対象、結果の保存期限も調べます。

登録済みなら既存の結果を使い、未実行ならAPIの仕様と重複防止の条件を確かめて再処理します。処理中なら新しい依頼を作らず待ち、待つ期限を超えたら担当者へ引き継ぎます。照合手段がない場合は、結果不明のまま保留します。受注取込が済み、要約だけが未開始なら、注文全体をやり直す必要はありません。

AI要約を追加する場合の待ち時間と再試行

画面で待たせる時間、APIへの1回の接続期限、再試行を含む全体の期限を分けます。長い処理は受付後に進捗を照会できる方式を検討します。OpenAIのBackground modeでは、結果IDで待機中・処理中の状態を照会できます。終了状態になった場合も、成功したかを見てから結果を使います。

利用制限や一時障害は、エラー詳細で原因を見ます。OpenAIのRate limitsに従う例では、指定された待機時間があれば守り、なければ間隔を延ばして再試行します。回数と総時間に上限を設け、上限後の通知先も決めます。SDKという接続用ライブラリが自動で再試行する場合は、それも合算します。利用枠不足や支払設定など、人の対応が必要な原因は再送だけでは解消しません。

中断後の結果と費用を確認する

画面を閉じる操作、生成の中断を依頼する操作、中断が確定した状態を区別します。OpenAIのバックグラウンド処理では、通信が切れても生成が続く場合があり、中断用の操作が用意されています。再接続や結果の取得には条件と保存期限があるため、必要な結果IDを残します。この方式の適用範囲は同サービスです。別のAI APIでは、中断・保存・再開の条件を個別に調べます。

再生成では回答が変わる可能性があるため、採用する結果を一つに決め、前の結果を重ねて登録しないようにします。費用も、画面上の成功・失敗だけでは判断できません。OpenAIの料金表には入力・出力などの料金区分があります。最初の処理と追加の実行分を利用明細で調べ、中断したから無料と決めつけないようにします。個別の請求条件は利用先の契約・公式仕様で確かめます。

図2　応答後も処理結果を照合して進む（想定例）

障害時の判断表：10の事象

連携が止まったときの判断を10の場面で比べます（想定例）。番号や項目名は、利用するサービスの仕様に合わせてください。再送は、相手が同じ操作と認める期限や処理結果を調べ、安全に実行できる場合だけ行います。

記入済みの見本と入力用の空欄版は、障害時の判断表（Excel）から取得できます。Excelでは、同じ事象の8項目を1行で見られます。

まず、冒頭の注文で次の3場面を見分けます。担当者と照合に使う記録も同じ行で確認できます。

調べて分かった状態	次にすること	確かめる記録・担当
注文は登録済み	既存の結果を使い、注文を再送しない	連携運用担当が注文ID・処理結果・明細を照合。要約の二重開始も防ぐ
注文は登録済み、要約だけ未開始	安全に実行できる条件を確かめ、要約だけ開始する	連携運用担当が取込と要約を別に照合し、AI実行分を確認
結果を探す番号もなく、実行したか不明	追加送信を止め、利用先へ問い合わせる	AI運用担当が自社記録と相手窓口で調査。利用有無・請求も確定まで保留

全10事象の対応・記録・担当・費用を一緒に見る

起きたこと	相手側の状態	次の対応	照合する記録	担当・費用の見方
認証失効	拒否され、未登録	権限を戻す。未実行と重複防止の条件を確かめて再送する	認証エラーと取込記録	接続管理者。AIへの送信有無を調べる
利用制限	一時的に受け付けられない	一時制限の解消後に再試行する。利用枠不足なら停止して契約や利用量を見る	エラー詳細・利用枠	AI運用担当。利用枠・利用量を調べる
一時障害	処理結果が不明	登録結果を調べ、未実行と安全性が分かった場合だけ再送する	受注ID・相手側の処理記録	連携運用担当。後続のAI実行有無を調べる
応答が届かない	受注は登録済み	既存の登録結果を使い、注文を再送しない	受注ID・処理結果・内容	連携運用担当。要約の二重開始を防ぐ
同じ通知が届く	その通知は処理済み	保存済みの結果を使う	イベントID・処理状態	連携運用担当。要約の二重開始を防ぐ
古い通知が後から届く	新しい内容が先に反映済み	古い内容で上書きせず、更新元の最新版と見比べる	更新元の最新版・更新番号	連携運用担当。古い内容の再生成を防ぐ
一部だけ成功	受注は登録済み、要約は未開始	安全性を確かめ、未開始の要約だけ実行する	取込と要約を別々に照合	連携運用担当。要約の実行分を調べる
AIが処理中	受付済みで生成が続いている	結果を待つ。期限を超えたら担当者へ引き継ぐ	AIの結果IDで状態を照会	AI運用担当。終了後の利用量を調べる
中断を依頼した	停止したかはまだ不明	終了状態を調べてから、再生成の要否を決める	終了状態・生成結果	AI運用担当。無料と決めず利用明細を調べる
結果が分からない	結果を探す番号もない	追加の送信を止め、担当者が利用先へ問い合わせる	自社記録・相手側の確認窓口	AI運用担当。利用有無・請求は調べ終わるまで保留

実際の連携先で、止まった後の操作を試す

実際の連携先では、テスト用の注文1件を使い、登録後に応答が途切れた場合を試します。同じ注文が1件のまま、登録結果をたどれることが期待する結果です。次に、注文登録は済み、要約だけが未開始の状態を用意します。要約だけを開始でき、注文が増えないことを確かめます。各サービスが認める検証環境で行ってください。

復旧後は上の判断表を使い、受注ID・件数・明細と工程別の処理記録を照合して、不足分だけを再処理します。誤反映の訂正には理由を残します。

記録には調査に必要な番号、処理状態、結果、時刻を残し、生の受信内容や秘密情報を無期限に保存しません。保存項目と期間、失敗に気づく担当者、通知先、照合する頻度、停止と再開の手順を決めます。認証が失効した朝と、応答が失われた直後の操作を試すと、担当者が迷う箇所が分かります。

在庫の引当までつなぐ場合は、在庫管理を作る前に｜残数と注文に使える数の違いも参考になります。

ここまで決めた対応を連携仕様と完成条件へ写し、担当者が対象を絞って再開できるか、利用先の検証環境で確かめます。

利用中のツールを残して注文の受け渡しや反映確認を整える場合は、つなぐ情報と停止時の対応をまとめてご相談ください。

AIの要約も組み込む場合は、渡す情報と採用前の確認を整理します（生成AIの導入・組み込み）。戻った形式に加え、金額・日付・参照先を確かめる手順は、AIの出力を登録する前の確認で説明しています。

ツール・API連携の相談へ