本番運用ベストプラクティス

ToRouter を本番で動かすための短いチェックリストです。どれも特別なものではなく、初めてのインシデントの前にやっておけばよかったと誰もが思うものです。

1. 環境ごとに 1 つのキー

dev、staging、prod で別々のキーを作成しましょう。クォータ上限を厳しくした dev キーが漏れても困るだけですが、上限なしの prod キーが漏れたら請求が来ます。

2. 本番キーには IP ホワイトリストを設定

/keys で本番 egress（Fly.io リージョン、VPC NAT、k8s egress gateway など）の CIDR を追加します。ホワイトリスト外で漏洩したキーは使えなくなります。

3. キーごとに支出上限を設定

すべてのキーに、コンソールで支出上限（USD または CNY）を設定してください。暴走ループが短時間で請求を膨らませた場合でも、ゲートウェイが 429 で止めます。

目安：本番 は月次予算の約 9 割、ステージング は数十ドル規模、開発 は十ドル程度から /keys で調整してください。

4. モデルのバージョンを固定

# よい例
model="claude-opus-4-7"
model="gpt-5.3-codex"

# 悪い例 — 時間とともに静かに挙動が変わる
model="claude"
model="gpt-4"

バージョンを固定すれば、プロバイダのスケジュールではなく自分のスケジュールで次バージョンと A/B 比較できます。

5. 429 と一時的な 5xx は指数バックオフでリトライ

OpenAI と Anthropic の SDK は max_retries を設定すれば自動で処理します。生 HTTP の場合は レートリミット超過 に最小実装があります。4xx（400/401/403/404）を絶対にリトライしないでください — 同じレスポンスが返ってきます。

6. 常に x-request-id をログに残す

resp = client.chat.completions.with_raw_response.create(...)
print(resp.headers["x-request-id"])

サポートチケットを切る必要があるとき、これがゲートウェイ、スケジューラ、上流を数秒で追跡できる唯一の手がかりになります。

7. フォールバックモデルを用意

主モデルが gpt-5 で全面ダウンしたとき、エンジニアを呼ぶ前に claude-opus-4-7（または同じグループ内の別モデル）を試すコードを書きましょう：

def chat(messages, primary="gpt-5", fallback="claude-opus-4-7"):
    try:
        return client.chat.completions.create(model=primary, messages=messages)
    except Exception:
        return client.chat.completions.create(model=fallback, messages=messages)

8. ダッシュボードと支出を把握する

• /dashboard を週 1 回は開く — モデル別・キー別の異常な支出スパイクを探します。
• トラフィックが増える前に チャージ で十分な残高を確保し、突然の 402 を避けます。
• 支出がおかしいときは 利用状況の詳細 でリクエスト単位に掘り下げます。

次のステップ