結論：AI APIは「水・電気」になった
最近、AI API を業務やプロダクトに組み込むのが当たり前になってきました。
でもこれ、冷静に見ると 水道・電気と同じインフラ です。
- クレジット切れ
- レート制限（429）
- プロバイダー側の障害
- 支払い失敗（カード更新忘れとか）
どれか1つで、急に“停電”。AI 前提の機能はまとめて止まります。
あるある：月末に「真っ白」になるやつ（1例だけ）
問い合わせ自動化（要約・分類・テンプレ返信）を API に寄せて運用してた。
月末、クレジットが尽きて API が止まる。
画面は真っ白、処理は 401/429 で落ちる。
結果：
- 自動分類が止まる
- 対応待ちが一気に積み上がる
- 人力で巻き取って疲弊する
→ 停電です。しかも復旧するまで何もできない。
解決策：Multi AI（マルチプロバイダー）を前提にする
Multi-Cloud と同じで、AI も 1社に依存しない設計にします。
- OpenAI
- Anthropic
- OCI Generative AI
- （必要なら）ローカルモデル
どれが優れてる、という話じゃなくて、目的はひとつ。
「どこかが落ちても、サービスは落とさない」
最小構成：順番に試してダメなら次へ
providers = [
openai,
anthropic,
google,
oci_generative_ai,
local_llm, # 最終防衛ライン
]
…で、呼び出し側は「フェイルオーバー」と「正しいリトライ」を一緒に持たせます。
“正しいリトライ”も込みの、最小実装（これだけでだいぶ強い）
429（混雑）に対して即リトライすると、だいたい悪化します。
みんなが同じタイミングで再突撃して、さらに詰まるんですよね。
なので定番はこれ：
- 指数バックオフ：待ち時間を 1秒→2秒→4秒…と増やす
- ジッター：待ち時間にランダムな揺らぎを入れて、再突撃の同期を崩す
それを含めて、記事用に短くまとめるとこう。
import random, time
providers = [openai, anthropic, google, oci_generative_ai, local_llm]
def ask_ai(prompt, max_tries=6, base=0.5, cap=8.0):
last_err = None
for p in providers:
for i in range(max_tries):
try:
return p.call(prompt)
except Exception as e:
last_err = e
# backoff + jitter（429/一時障害を想定）
sleep = min(cap, base * (2 ** i)) + random.uniform(0, 0.3)
time.sleep(sleep)
# このプロバイダーがダメなら次へ（フェイルオーバー）
raise RuntimeError(f"all providers failed: {last_err}")
-
base * (2 ** i)が 指数バックオフ -
random.uniform(0, 0.3)が ジッター -
capは待ちすぎ防止（「いつまでも待つ」にならないように）
ここまで入ってると、
「一時的な混雑」 と 「どこかの障害」 にだいぶ強くなります。
さらに効く“現実的な”対策
1) キャッシュ：同じ質問は二度払わない
FAQ や定型問い合わせは特に効きます。コストも遅延も減る。
2) キュー：その場で失敗させず、溜めて後で処理
API が詰まってる時間に「失敗」で返さない。
後で順番に流すだけで、体験が全然変わります。
3) “軽い返し”のフォールバック
完全な回答が無理でも、
- 要約だけ返す
- 受付だけ返す（人が後で見る）
みたいに 最低限の継続ができます。
4) ローカルモデル：最悪でも動く“自家発電”
品質はクラウドに負けることもあるけど、ゼロにはならない。
「完全停止だけは避けたい」用途に刺さります。
まとめ：AIは“魔法”じゃなく“ライフライン”
- 1社依存は、停電1回で詰む
- 対策は Multi AI（+ 正しいリトライ + キャッシュ + キュー + ローカル）
- 目的は「どこが落ちても、サービスは落とさない」
停電は起きる前提で設計する。
それだけで事故率がガクっと下がります。