429エラーの真犯人は404？「爆速リトライ」の罠を解くエンジニアの推察と改善術

1. ワクワクを一瞬でぶった切る「429 Too Many Requests」の衝撃

「Velocity English」の開発フェーズ2。

前回の記事で作ったモックにいよいよ本物のAI（OpenAI API）を接続する、最高にエネルギッシュな瞬間がやってきた。

コードを書き換え、期待に胸を膨らませて「Generate」ボタンをクリック。しかし、画面に返ってきたのは期待した英文ではなく、無慈悲なエラーコードだった。

Error 429: Too Many Requests

「えっ、まだ1回しか投げてないのに？ OpenAIに嫌われたのか？」

エンジニアの卵なら誰もが一度は遭遇する、この「429」という数字。

ここから、俺と相棒（AI）の長く、熱いデバッグ大会が開催。

ここからは、このエラーをどう紐解き、解決へと導いたか。その**「エンジニア・マインド」**を詳しく伝えていこう。

エラーが出た時、初心者が陥りがちな罠がある。それは「エラーを消すために、安易にコードを足してしまう」ことだ。なぜなら、エラーメッセージにはこう書かれているから。

「クォータ（制限）を超えたなら待てばいい」

「モデルが見つからないなら指定を増やせばいい」

エラーメッセージって言葉通りの場合じゃない場合もあるんだよ。今回発生したのがそのいい例。

俺と相棒も、そのメッセージ通りに対応しようとしてドツボにハマった。

「回数制限なら、少し待ってから再試行すればいいはずだ！」と、指数関数的に待ち時間を増やす高度なリトライロジックを実装。 → 結果： 待ち時間が増えただけで、やっぱり429エラーは変わらず吐き出される。

「リクエストが重なってるのか？なら非同期で並列処理を制御しよう！」と、コードをさらに複雑に書き換え。 → 結果： コードは豪華になったが、429エラーは居座り続けたまま。

「コードを足せば足すほど、真実から遠ざかっていく……」

脳が煮詰まっていく中で深夜の画面を見つめていた俺は、ある決定的な「違和感」に気づいた。

袋小路に入った時、ふと浮かんだ疑問がある。

「APIのベースURLとモデル名の組み合わせが、利用しているライブラリのバージョンと噛み合っていない（404エラー）。だが、組み合わせをいくら合わせても解決しない……怪しいどころか、おかしい。となると、この429エラー（アクセス過多）も、本来そもそも発生しないはずなんじゃね？」

この「本来」というのはこういうことだ。

もしAPI処理にエラーがあるなら、429の原因となる「正常なリクエスト」が走るわけがない。モデル名が間違っているなら、404エラーを吐いて終わるはずなんだ。

そこで俺は、以下のような「異常なリクエストの連鎖」が起きていると推測した。

初期化プロセスの競合: API設定を読み込みきる前に、UI側の描画プロセスや別の関数が「その設定を使ってリクエストを投げよう」と割り込む。
不完全なリクエスト（404の原因）: API側からすれば「中身が空っぽ」のリクエストが届き、「そんなモデルは見当たらない（404）」と返す。
爆速リトライの暴走（429の原因）: ライブラリの仕様によっては、エラーが出た瞬間に「通信エラーかな？」と判断して、ミリ秒単位で自動的に再送を繰り返す設定になっていることがある。

つまり、「不完全なリクエスト（404）をプログラムが爆速でリトライし続けた結果、一瞬でリクエスト制限を使い果たして429になった」というわけだ。

目の前のpyファイルを眺める。「……これ、完全なスパゲッティコード（密結合）になってるじゃないか」そう確信した瞬間だった。