フリーランス向けの契約書・請求書を自動生成するツールが、Groq経由のLlama 3.1やOllamaによるローカル推論を組み合わせて開発されています。この事例は、オープンウェイトモデル（重みが公開され誰でも推論に使えるAIモデル）をプロダクトに組み込む際に、特定のAPIベンダーに縛られないという利点を示す一方で、見落としがちな落とし穴も含んでいます。
個人開発やスタートアップでLLM（大規模言語モデル）を使ったSaaSを作っている方、あるいは社内ツールにAI機能を組み込もうとしているエンジニアに向けて、この事例から読み取れる注意点を整理します。
何が起きるか: モデルが突然使えなくなる
開発中にllama-3.3-70b-versatileというモデルのエンドポイントが非推奨（deprecated）になり、別のモデルqwenが出力トークンのレート制限に引っかかったという出来事が起きています。
これは珍しい話ではありません。Groqのような推論APIプロバイダーは、提供するオープンウェイトモデルのラインナップを頻繁に入れ替えます。昨日まで動いていたモデルIDが、今日になって404エラーを返すことがあります。
本番環境でこれが起きると、ユーザー向けの機能が突然止まります。契約書生成のような「1回のリクエストで完結する」機能であっても、障害時はサポート対応に追われることになります。
なぜ起きるか: モデルIDのハードコードと単一プロバイダー依存
原因を段階的に分解すると、まず「モデルIDを文字列として直接コードに書いている」ことが挙げられます。たとえばOpenAIのAPIクライアントでmodel="gpt-4"のように固定値を渡すコードは、多くのチュートリアルで見かけますが、これをそのまま本番コードに持ち込むとモデル廃止時に全箇所を書き換える必要が出てきます。
次に「推論プロバイダーを1社にしか依存していない」ことも原因になります。GroqでもOpenRouterでもAWS Bedrockでも、単一のAPIだけを呼ぶ構成にしていると、そのサービス側の障害やレート制限がそのままアプリの障害になります。
さらに「レート制限（一定時間あたりのリクエスト数・トークン数の上限）への対処がない」ことも見落とされがちです。無料枠や低価格プランのAPIは、トラフィックが増えると簡単に制限に達します。qwenが出力トークンのレート制限に達したという状況は、まさにこのパターンです。
自分のプロジェクトが該当するか確認する方法
まず自分のコードベースでモデルIDがどう扱われているか確認します。
grep -rn "gpt-4\|llama-3\|claude-3\|gemini-" --include="*.py" --include="*.ts" .このコマンドで検索結果が環境変数や設定ファイルからの読み込みではなく、関数呼び出しの引数に直接文字列で書かれている箇所が多い場合、そのプロジェクトは該当します。
次に使用しているAPIプロバイダーの「モデル一覧取得エンドポイント」をドキュメントで確認します。Groqであれば/openai/v1/models、OpenAIであれば/v1/modelsというエンドポイントが用意されており、現在利用可能なモデルを動的に取得できます。これを呼び出すコードが存在するかどうかもチェックポイントです。
またOllama（ローカルでLLMを動かすためのランタイム）を使っている場合は、ローカルサーバーが起動しているか次のコマンドで確認できます。
curl http://localhost:11434/api/tagsこのエンドポイントはローカルにダウンロード済みのモデル一覧を返します。レスポンスが空であればollama pull llama3.2のようなコマンドでモデルを取得する必要があります。
対策の手順
1. モデルIDを設定から切り離す
モデル名は環境変数か設定ファイル（config.yamlや.env）に外出しします。コード中ではos.environ.get("LLM_MODEL", "llama-3.1-8b-instant")のようにデフォルト値付きで参照する形にしておくと、障害時に環境変数を書き換えるだけで切り替えられます。
2. 動的モデル検出を実装する
アプリ起動時またはリクエスト時にプロバイダーのモデル一覧APIを叩き、存在しないモデルIDを指定していないか検証する処理を挟みます。これにより、廃止されたモデルを呼び続けてエラーを量産する事態を防げます。
3. フォールバック先を最低1つ用意する
主力モデルが応答しない、またはレート制限に達した場合に備えて、代替モデルへの切り替えロジックを用意します。たとえばGroq上のllama-3.1-8b-instantが使えない場合はMixtral 8x7Bやgemma2-9b-itに切り替える、といった具合です。クラウド側が全滅した場合の最終手段として、Ollamaによるローカル推論への切り替えパスを持っておくのも有効です。
4. 機密データを扱う機能はローカル推論を検討する
契約条件や見積金額など、取引先に関わる機微な情報をプロンプトに含める場合、外部APIへの送信自体がリスクになることがあります。Ollamaでllama3.2のような軽量モデルをローカル実行すれば、8GB RAM程度のノートPCでもオフラインで推論が完結し、データが外部サーバーに渡りません。すべての処理をローカルに寄せる必要はありませんが、機密性の高い処理だけローカル推論に切り出す設計は検討に値します。
5. コスト構造を点検する
クローズドな最先端モデルのAPIを使い続けると、利用量に応じたトークン課金が重くのしかかり、月額数ドルといった低価格プランの事業は成立しにくくなります。オープンウェイトモデルを使い、推論コストをほぼゼロに近づけることで、薄利の個人開発や副業プロダクトでも粗利率を確保できる可能性があります。自分のプロダクトの価格設定とAPIコストを一度並べて計算してみることをおすすめします。
まとめ
オープンウェイトモデルを使ったLLMアプリ開発では、モデルの非推奨化やレート制限によって機能が突然止まるリスクが常にあります。
まずは手元のコードでgrepを使いモデルIDのハードコードがないか確認し、プロバイダーのモデル一覧APIを使った動的検出を導入することから始めてみてください。
あわせて機密情報を扱う処理についてはOllamaなどのローカル推論への切り出しを検討し、コスト構造も一度見直しておくと、長期運用での安定性が高まります。