【実録】Gemini API 429/404エラーと決別の記録

Velocity English開発記：要件定義編を経て、「いざ開発開始！」と思いきや。

突如として429エラーが発生・・・。要件定義をしたのは3日前で、その際は間違いなくアプリは正常に稼働していた。

429エラーはリソース枯渇を示すのエラー。しかし、枯渇するほど利用などしていない。というかアプリ立ち上げて一発目のテスト・・・。

さて、このエラーが何故起こったのか。記事にしていきます。

1. 異変：昨日まで動いていたコードが「429 Resource Exhausted」

開発中のアプリ『Velocity English』にて、今日一発目の起動にもかかわらず以下のエラーが発生。

Bash

google.api_core.exceptions.ResourceExhausted: 429 You exceeded your current quota...

原因の特定

まず、エラーコード429の言葉通りに、コーディングに問題がある可能性を考えた。

つまり、APIリクエストが短時間で複数回起こっている可能性だ。

コードを解析した結果、良かれと思ってGemini1.5が使用できない場合に他の利用可能モデルを動的に探す関数を使っていたことに気づく。

Python

def get_best_model_name(): """環境で利用可能なFlashモデル名を探索""" try: model_list = [m.name for m in genai.list_models() if 'generateContent' in m.supported_generation_methods] # 1.5 flash を優先的に探す for name in model_list: if "gemini-1.5-flash" in name: return name return model_list[0] if model_list else "models/gemini-1.5-flash" except Exception: return "models/gemini-1.5-flash"

つまり、 1回のボタン操作で「モデル探索」と「コンテンツ生成」の2回リクエストが飛んでいた。

現在はgemini1.5を明示的に使用している設定のため、これはもう削除することに。

2. 対策：モデル名の固定（ハードコーディング）

APIリクエストを節約するため、探索処理を廃止し、モデル名を直接指定する運用に変更。

Python

# 変更前
# target_model = get_best_model_name()
# 変更後
TARGET_MODEL = "gemini-1.5-flash"

3. 次なる壁：「404 models/gemini-1.5-flash is not found」

「さて動くかな？いやなんか動かない気がする」と思いつつも、アプリを実行してみると今度は404エラーが眼に入る。

Bash

google.api_core.exceptions.NotFound: 404 models/gemini-1.5-flash is not found for API version v1beta, or is not supported for generateContent. Call ListModels to see the list of available models and their supported methods. 

根拠はなく、エンジニアとしての勘になるのだが、エラーというのは、単純なように見えて実は内部的には複数のエラーが存在していることが多くあり、その数あるエラーの中でも上辺のエラーのみが浮上する。今回がそのケースだ。

一応、試行錯誤したパターンを列挙

• gemini-1.5-flash
• models/gemini-1.5-flash-latest
• gemini-flash-latest

結論：外部APIに依存するリスクと「損切り」の重要性

「これは・・・not supportのほうか？」と調べてみると以下の情報が。

数日前まで動いていた 1.5-flash 系が、特定のAPIバージョンやリージョンにおいて、予告なく（あるいは急激な世代交代により）利用不可になるケース。

開発速度を優先するため、今回はGeminiの機嫌を伺い続けるのではなく、よりレスポンスが速く制限の少ない Groq (Llama 3等) への乗り換えを決断。という事で、今回はここまでにします。

今回の技術的教訓：開発者が肝に銘じるべき5つのポイント

今回のトラブル劇を経て、あらためて痛感した教訓をまとめます。外部APIを利用するすべてのエンジニアに捧ぐ。

• エラーの多重構造を疑う
  表層の「429 Resource Exhausted（リソース枯渇）」を解決した先に、真の死因である「404 Not Found（リソース不在）」が隠れていることがある。エラーメッセージは常に氷山の一角であり、深層の原因を突き止める姿勢が不可欠。
• APIの「エイリアス」は永遠ではない
  最新モデルを指し示す便宜上の名前（例：gemini-1.5-flash-latest）は、バージョン更新やリージョンの都合で突如として「未サポート」になるリスクがある。安定稼働を狙うなら、特定のバージョンを明示する運用の検討も必要。
• 利便性とリクエストのトレードオフ
  実行時にモデルを動的に探索するような「親切な関数」は、それ自体がAPIリクエストのクォータ（利用枠）を浪費し、一発目の実行で自爆する原因になりかねない。開発初期こそ、極力シンプルで静的な構成を優先すべき。
• 「損切り」という勇気ある撤退
  特定のAPIの不機嫌に数時間を溶かすくらいなら、より安定し、レスポンスの速い別プラットフォーム（今回はGroq）へスイッチする決断を下すべき。開発速度を最大化することこそが、個人開発の生命線。
• 公式Changelogは「事件現場」の目撃証言
  「昨日まで動いていた」が通用しなくなった時、唯一の客観的事実が記されているのは公式の変更履歴（Changelog）だけ。ネットの二次情報より、まずは一次ソースを確認する癖を。