モデルを1つに決めない — OpenRouter で切り替え前提に設計する

何が解決されるか

OpenRouter は数百のモデルを1つの OpenAI 互換APIの背後に置く。モデルを変えるときに変わるのは `model` の値だけで、認証もリクエスト形式も変わらない。提供元の価格に上乗せはしないと明記されている。

• ベンダーごとにアカウントとキーを持たなくてよい
• モデルの切り替えが設定値の変更で済む
• `:free` 付きのモデルは無料で使える（日次のレート制限あり）
• 障害時に別のモデルへ逃がす設計が取りやすい

最低限やることは、モデル名をコードに直書きしないことだけである。環境変数か設定ファイルに出しておけば、乗り換えがデプロイで済む。

もう一段進めるなら、用途ごとにモデルを分ける。分類や抽出のような単純な処理は安いモデル、最終的な文章生成は賢いモデル、という割り当てを設定で持つ。これだけで費用が半分以下になることがある。

中継を挟むデメリット

• 経路が1段増えるぶん、わずかに遅延が乗る
• 中継側が落ちると全モデルが使えなくなる
• 最新モデルの提供が本家より遅れることがある
• プロバイダ固有の機能が使えない場合がある

2つめが本番での懸念になる。可用性を重視するなら、中継経由を既定にしつつ、主要モデルへの直接接続も実装してフォールバックできるようにしておく。

無料モデルの使いどころ

`:free` 付きのモデルは費用ゼロで使えるが、日次のレート制限がある。本番のユーザー向け処理には向かないが、開発時の動作確認、プロンプトの試行錯誤、社内の実験には十分である。クレジットを購入すると制限が上がる。

費用の可視化

複数モデルを使い分けると、どこに費用がかかっているかが見えにくくなる。OpenRouter 側のダッシュボードに加えて、自分のアプリ側でもモデル別のトークン数を記録しておく。Langfuse のような観測ツールを併用すると、用途ごとの単価が出せる。

よくある質問

Q. 本当に上乗せはありませんか。

A. 提供元の価格に上乗せしないと明記されています。収益モデルについては公式の価格ページで最新の条件を確認してください。

Q. 自分のAPIキーを使えますか。

A. BYOK に対応していますが、条件は公式ページで確認してください。既存のベンダー契約を活かしつつ、呼び出しだけ統一する使い方ができます。