THE TAKEAWAYS
この記事のポイント
- 連携先の再試行仕様と待機の指示を確認する
- 一つの依頼全体で再試行予算を管理する
- 送信済みか不明な処理を安易に再送しない
編集部の実務提案
再試行もサービスへの要求である
AI連携の途中で外部APIが429を返したとき、同じ要求をすぐに送り直すと、混雑を長引かせることがあります。Google Cloud Storageの公式資料は429などの一時的な問題と再試行戦略を説明しています。待機時間の指示が返るかどうかなどの詳細は、連携先APIの仕様も確認します。編集部では、失敗したら繰り返すという実装を避け、相手の応答と業務の許容時間を使って待ち方を決めることを勧めます。
編集部の実務提案
回数だけでなく全体の予算を置く
一回ずつの再試行に回数制限があっても、複数の工程がそれぞれ再試行すると合計の要求数は増えます。提案として、利用者の一つの依頼に対し、待ってよい合計時間と追加要求の回数を管理します。読み取りと送信では再実行の影響も異なります。特にメールや決済などの処理は、前の要求が完了したかを確認せずに再送しないよう、相手APIの重複防止の仕様を調べてください。
編集部の実務提案
待機中の表示と中断の動作をそろえる
画面には再試行中であること、結果がまだ確定していないこと、利用者が取れる次の行動を示します。「失敗」と表示した後も裏で送信を続ける構成は、利用者の再操作と重なるおそれがあります。中断した場合は、新しい試行を止めるのか、進行中の結果だけを確認するのかを決めます。再試行後に成功した依頼と、最初から成功した依頼を分けて観測すると、外部サービスの制限へ近付いていることに気付けます。
編集部の実務提案
時差のある担当者にも判断できる記録を残す
障害の引継ぎでは、相手先、状態コード、初回時刻、試行回数、最後に確認した結果を残します。認証情報や送信本文そのものをログへ入れる必要はありません。再開する担当者は、同じ仕事を最初から送るのではなく、既存の要求識別子で状態を確認してから判断します。相手サービス固有の上限や料金は別に存在するため、HTTP標準だけで再試行の適否を決めない運用が必要です。
編集部の実務提案
受入試験で具体例を確かめる
例えば、記事の送信後に応答が途切れた場合、未送信と決め付けてはいけません。相手側の識別子や記録を照合し、結果が不明な依頼を別枠へ置きます。担当者が確認する条件を決めれば、同じ内容を何度も送り直す運用を避けやすくなります。条件と期待する結果を同じ記録に残し、次の担当者が再現できる状態を確認します。判断できない点は未確認として明示し、必要な追加確認を担当者と共有します。
WITH OPERUN.
日々のAI管理を、チームへ。
今回の確認では、連携先の再試行仕様と待機の指示を確認する、一つの依頼全体で再試行予算を管理する、送信済みか不明な処理を安易に再送しないという観点を整理しました。担当者へ作業を渡すときは、期待する動作と確認結果を結び、利用者が次に取る行動まで確かめましょう。
作りたいもの・任せたい仕事を相談する参考にした一次情報
出典確認：2026年11月6日。本文の手順・チェックリストは、編集部の実務提案です。
- [1]
この記事を共有