API 開発 / レッスン 05
失敗・使用量・再試行を扱う
入力エラー、一時的な障害、未完了の出力を区別する。
前の例とシミュレーションで先に確認します。API キーやユーザー文書全体を記録せず、再試行の利用量と書き込みの重複に注意します。
1. ステータスで分類
400 は内容や支出上限、401 はキー、403 は権限、404 はパスやモデル、429 は制限と retry-after を確認します。500／529 の一時障害は回数限定で再試行します。Worker 例は上流エラーを upstream_status 付き 502 にします。
2. 必要な場合だけ再試行
一時障害には retry-after を尊重し、上限付きの指数バックオフと揺らぎを使います。支出上限の 429 を無限に繰り返しません。不正入力・失効キー・権限不足は修正が必要です。fetch 例は自動再試行せず、SDK 独自の再試行を重ねないように設定します。
3. 診断情報と途中終了を確認
ステータス・安全なエラー分類・request-id・時間・usage を残します。200 でも stop_reason とツール失敗を見ます。max_tokens は未完了です。ストリームはヘッダー送信後にも失敗するため、イベントのエラーも扱います。
4. 処理量を制限する
出力・ラウンド・入力サイズを制限し、読み取りと書き込みを分けます。Console で支出上限と実際の利用を確認します。ツール定義と結果もトークンを使い、ループは複数のモデル要求になり得ます。無料無制限ではありません。
練習と確認
YOUR TURN / 実践
401、retry-after 付き 429、max_tokens、ツール失敗を模擬し、修正・再試行・利用者への表示を判断します。
終わったら、振り返ってみましょう：
公式資料を読む
CLI の操作は公式文書と照合し、API のサンプルは模擬応答で検証しました。実アカウントでの一連の操作は未実施です。