OpenAI / 判断・確認の手順

APIエラーの原因を切り分け、再試行の可否を決める

HTTP番号だけでなく、エラーの種類・コードとリクエストIDを確認します。同じ429でも送信頻度・残高・支出上限で対応は変わります。

どんな時に使うか

API連携で失敗が起きたとき、原因に応じた対応を選ぶために使えます。

再現条件を記録する
発生時刻、HTTP番号、error.type / error.code、リクエストID、対象モデル、SDK版を保存する。
判断することAPIキーと入力データはログや問い合わせにそのまま含めない。
401・403・400を確認する
認証、組織・プロジェクトの対応、許可された地域・設定、入力形式を確認する。
判断すること設定・権限・入力に原因がある場合は修正してから再送する。
429の意味を分ける
頻度制限ならRetry-Afterとバックオフを考慮し送信量を落とす。残高・支出上限なら契約・予算を管理者と確認する。
判断すること予算や残高の問題を待機だけで解決しようとしない。上限を無条件に引き上げない。
5xx・通信失敗を照合する
稼働状況と発生範囲を確認し、回数・待ち時間を制限した再試行を検討する。
判断すること結果不明の処理は二重実行を防ぐ。復旧後に失敗分と完了分を照合する。

合成例：同じ429でもrate_limit系なら送信間隔を調整し、credit_balance_exhaustedなら残高の確認へ進む。ステータスの障害表示だけで判断しない。

説明用の合成例です。実際の障害・顧客事例ではありません。

機密情報を除いたエラー本文、リクエストID、時刻、モデル・設定、発生頻度、実施した確認、処理の重複有無を残す。

資料確認・手順の編集：2026-10-10。当社が整理した確認手順です。