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

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

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

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

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

TL;DR

問題: 起動一発目で「429 Resource Exhausted」が発生。原因は、良かれと思って実装した「モデル探索関数」によるリクエストの無駄遣いだった。
深層: 429を解決した直後に「404 Not Found」が発生。Gemini 1.5の世代交代による不安定さが真の要因と判明。
決断: APIの挙動に振り回されるのをやめ、開発速度を優先して Groq への乗り換え（損切り）を敢行。

1. 異変：昨日まで動いていたコードが「429 Resource Exhausted」
- 原因の特定
2. 対策：モデル名の固定（ハードコーディング）
3. 次なる壁：「404 models/gemini-1.5-flash is not found」
結論：外部APIに依存するリスクと「損切り」の重要性
今回の技術的教訓：開発者が肝に銘じるべき5つのポイント

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"

ペストマスク姿のAIエンジニアが、空になったGoogle AI APIのクォータ（利用枠）タンクを悲しげに見つめている。デスクにはエラーの原因となった複雑に絡まるフローチャートの赤い糸がある。 — 【悲報】起動一発目でAPIクォータが枯渇（429エラー）。原因は、利用可能モデルを動的に探す関数がリクエストを無駄に消費していたことだった。

つまり、 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.

夜のShinjukuの路地裏で、ペストマスクのエンジニアが古い「Gemini 1.5」の看板を探して迷い込んでいる。壁には彼が試行錯誤したモデル名のグラフィティがあり、周囲は「NOT FOUND」のホログラムで塞がれている。 — モデル名を固定しても現れる「404 Not Found」の壁。試行錯誤したエイリアス（別名）もすべて無効化された。

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

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

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

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

青白い光明を放つ「Groq」デバイスを起動させたペストマスクのエンジニア。爆速なレスポンス（光の速さでコンテンツを生成するLlama 3のロゴ）に驚き、喜んでいる。マスクの口からも希望の光が溢れている。 — Geminiとの決別、そしてGroq（Llama 3）への切り替え。その爆速なレスポンスは、APIエラーの絶望から救う「光明」。

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

参考

Gemini APIリリースノート

数日前まで動いていた 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）だけ。ネットの二次情報より、まずは一次ソースを確認する癖を。