爆速で便利なGroq APIが突然動かなくなった朝の話。モデル移行と個人開発の付き合い方

今朝、毎日の習慣にしている自作RSSリーダーを開いたところ、記事の要約がすべて真っ白のまま止まっていました。

ログを確認してみると、APIから返ってきていたのは見慣れない 404 model_not_found というエラーでした。

GroqのAPIを使ってツールやアプリを作っている人は、まだそれほど多くないかもしれません。

ですが、圧倒的なレスポンス速度と、無料枠でもかなり実用的に動く手軽さは、個人開発において非常に魅力的な選択肢だと私は感じています。

この記事では、今回起きた「突然の404エラー」の正体と、呼び出し側の移行作業で私が確認したポイントを整理してお伝えします。

外部APIを利用するうえで避けては通れないモデルの世代交代と、どう付き合っていくべきか、一緒に考えるきっかけになれば幸いです。

なぜ認証エラーではなく「404」で止まったのか

最初、私はAPIキーの期限切れや、一時的なサーバー障害を疑いました。

しかし、ステータスコードは認証失敗の401でも、アクセス過多の429でもなく、「404」でした。

調べてみると、原因はAPI側の障害ではなく、指定していたモデル llama-3.3-70b-versatile が2026年8月16日をもって提供終了となっていたことでした。

Groqでは2026年6月中旬にDeveloperプランおよびFreeプラン向けの一部モデル廃止がアナウンスされており、期日を迎えて削除された形です。

利用していたモデル自体が提供終了している以上、アプリ側から指定するモデルIDを現行のものへ差し替える必要があります。

私が実際に変更したのはどこだったか

幸いなことに、Groqが提供しているOpenAI互換のエンドポイントや、リクエストの基本的な構造そのものは変わっていませんでした。

変更が必要だったのは、リクエストボディ内の model パラメータです。

現在、Groqの公式ドキュメントで案内されている主な推奨移行先は、次のような構成になっています。

• openai/gpt-oss-120b: 旧 llama-3.3-70b-versatile からの移行先。文章の品質や表現力を優先したい翻訳・要約・一般的な対話に向いている

• qwen/qwen3.6-27b: 旧 llama-3.3-70b-versatile からの移行先。別の系統のモデルで精度や挙動を比較したい場合に向いている

• openai/gpt-oss-20b: 旧 llama-3.1-8b-instant からの移行先。速度や軽量性を重視する処理に向いている

今回はRSS記事の日本語要約と構造化データの抽出が目的だったため、私は品質を重視して openai/gpt-oss-120b を採用することにしました。

// アプリ内で保持していたデフォルトのモデル定数を更新
const val DEFAULT_MODEL = "openai/gpt-oss-120b"

呼び出し側のJSON構造は今までどおりで問題ありません。

{
  "model": "openai/gpt-oss-120b",
  "messages": [
    { "role": "user", "content": "この記事を日本語で要約してください" }
  ]
}

これで再度リクエストを送ると、何事もなかったかのように一瞬で要約が返ってくるようになりました。

これだけでは足りなかった、切り替え後の注意点

モデルIDを書き換えてエラーが消えたからといって、そのまま作業完了とするのは少し危険だと感じました。

モデルが変わると、内部のパラメータや学習データが異なるため、出力される日本語の言い回しや指示追従性に微妙な変化が生まれるからです。

特に私が運用しているアプリでは「結論」「要点」「背景」という決まった見出し構成をプロンプトで指定していたため、代表的な記事をいくつか流して出力を確認しました。

具体的には、以下の項目を意識して見直しています。

• 日本語の文章として不自然な表現や言い回しが混ざっていないか

• プロンプトで指定した文字数やフォーマット（箇条書き、見出し）を正しく守れているか

• 長文記事や極端に短い記事を渡した際に、意図しない挙動にならないか

• 応答速度や消費トークン数に極端な変化がないか

また、今回の経験から、アプリ側のエラーハンドリング設計も見直すことにしました。

一時的なネットワークエラーやサーバー負荷（500系や429）であれば自動リトライが有効ですが、404エラーの場合は何度リトライしても回復しません。

そのため、404を受け取った際は無駄な再試行を即座に止め、「指定モデルは現在利用できません」と利用者に分かりやすく伝える設計へ変更しました。

あわせて、モデルIDをコードの複数箇所に散らさず1箇所に集約することや、APIキー（gsk_...）をクライアントアプリに直接埋め込まないよう環境変数やバックエンド経由で管理することも、改めて意識しておきたいポイントです。

たまに手入れは必要だけれど、Groqはやっぱりおすすめできる

外部のクラウドAPIを利用していると、今回のようにモデルの廃止や仕様変更への対応がどうしても発生します。

「予告なしに動かなくなるのが怖い」「定期的なメンテナンスが面倒だ」と感じる方には、少し扱いづらい部分もあるかもしれません。

それでも、ボタンを押した瞬間にテキストが返ってくるあの圧倒的な速度と、個人開発でも気軽に試せる無料枠の寛大さは、他のサービスにはない大きな魅力です。

普段のちょっとした作業の自動化や、個人で使うツールのバックエンドとして、GroqのAPIは試してみる価値が十分にあると感じています。

みなさんの開発環境でも、もし「APIの呼び出しが急に止まった」という場面に出くわしたら、まずはモデルの提供状況を確認してみてはいかがでしょうか。