無料枠 AI API を本番で使ったときの失敗談（2026年2月時点）

結論

kimura512.dev のチャット機能では、無料枠の AI API を本番で使っています。無料枠は開発用と割り切り、本番ではフォールバックと上限の見える化が必須です。2026年2月時点で、夜間のアクセス集中とモデル名の突然の非推奨に何度か困りました。ここでは、そのとき実際にやった対処を整理します。

1. レート制限

小規模サイトでもピーク時に HTTP 429 が返ります。個人サイトでも、短時間に同じ機能へアクセスが集まると上限に達します。API 選定記事 で書いた3社を優先順位付きで呼び、第一候補が失敗したら次へ回します。画面にはプロバイダ名は出さず、「しばらく待って再試行」といった短い案内だけ見せています。

2. モデル ID の寿命

ドキュメントに載っているモデル名が、通知なしに応答不能になることがあります。コードにモデル名を直書きすると、変更のたびに修正とデプロイが必要になります。Workers のシークレットや環境変数で差し替えられるようにし、デプロイ後は短いプロンプトで smoke test を必ず流します。モデル変更は「アプリのバグ」ではなく「外部依存の更新」として扱うと、対応が早くなりました。

3. ログに残す数字

障害のあと振り返るとき、日付（JST）、プロバイダ名、HTTP ステータス、入力トークンの概算を残しています。感覚だけでは「最近よく落ちる」で終わり、再発防止の判断ができません。課金前の個人開発でも、こうしたログがあとから運用を説明する材料になります。ログは利用者向けには出さず、サーバー側だけに集約します。

4. 2026年2月18日の例

Groq で短時間 503 が続き、フォールバック先まで詰まった日がありました。当日は機能フラグで AI 補助をオフにし、サイト本体の閲覧は止めずに済ませました。翌日プロバイダの優先順位を入れ替えて復旧し、ログを見直して「単発か連続か」を切り分けました。ユーザー数が少なくても、外部 API は一度は必ず止まると想定した方が楽です。

5. 監視

外形監視は1エンドポイント、AI 失敗はログの 5xx 件数を週次で見ます。すべてを細かく監視すると個人開発では続きません。ユーザーに影響するエンドポイントだけに絞り、週に一度まとめて確認する程度にしています。

6. フォールバックの実装

第一候補が失敗したら第二、第三へ自動で切り替えます。切替時は待ち時間を短く保ち、プロバイダ名は画面に出しません。切替ログはサーバー側にだけ残し、週次で失敗率を確認します。障害時に利用者の不安を煽る表示は、復旧より先に離脱を増やすことがあります。

7. 規約の再確認

無料枠の商用可否は四半期ごとに Terms を読み直します。以前使えていた条件が変わることもあるため、判断した日付を記事やメモに残しています。2026年2月時点の運用方針は、記事内の日付とセットで見てください。

個人開発で AI を触るなら、失敗ログをそのまま記事に残す癖が効きます。同じ障害の二度目は、ログの型が既にあると切り分けが早くなります。

チャット以外に AI を使う機能を足すときも、同じフォールバックとログの型を流用しています。機能ごとに別実装にすると、障害時にどこを見ればよいか分からなくなるためです。無料枠のまま運用する限り、「止まらない」より「止まってもサイト全体は生きる」設計を優先します。

運用メモ

Q. 無料枠だけで収益化できる？

小規模なら可能性はありますが、429 と規約変更は前提にします。収益を見込むなら、無料枠の条件変更で止まらない構成にしておく必要があります。

Q. ログはどこに？

Workers のログとアプリ側の構造化ログの両方に同じ request id を付けます。二つのログを突き合わせると、原因追跡が楽になります。

Q. ユーザーに見せるエラーは？

技術詳細は隠し、再試行か時間を置く案内だけにします。エラーコードをそのまま見せても、利用者が取れる行動はほとんどありません。

Q. 課金したらログは変える？

有料プランに移行したときは、レート制限の閾値とアラート条件を見直します。無料枠用に書いたフォールバックは残し、障害時の挙動だけ変えないようにしています。

障害の記録は、公開記事用に整形する前に、日付・エンドポイント・HTTP ステータス・対応したかだけをメモに残します。後から数字を盛らないためのルールです。