マルチモデルAIアプリ構築：ルーティングとフォールバック

本番運用のAIアプリは、モデル障害が起きても誰も夜中に叩き起こされずに乗り切れるべきです。 そこへ到達するためのパターンは、地味ですが確実です。OpenAI互換クライアントを1つ、優先順位付きのモデルリスト、安価かつ健全なプロバイダーを優先するルーティングルール、そして厳格な価格上限。これだけです。

このチュートリアルで作るもの：

• 文字列を1つ変えるだけで GPT、Claude、Gemini、DeepSeek などを呼び分けられる単一クライアント

• 自動フォールバック — プライマリモデルがエラーやタイムアウトになったら、リスト内の次のモデルでリクエストを自動リトライ

• コスト管理 — 最安優先ルーティングと max_price 上限で、トラフィック急増が予算を焼き尽くす事態を防止

• 支出の可視化 — ログに残してアラートを設定できる、リクエスト単位のコスト計上

以下ではルーティング層として OpenRouter を使います。同じアーキテクチャはOpenAI互換のゲートウェイならどれでも機能し、同じアプリで画像・動画・音声モデルが必要になったときは APIMart でも使えます。

シングルモデルよりマルチモデルが強い理由

障害は「起きるかどうか」ではなく「いつ起きるか」

大手プロバイダーはどこも目に見える障害を起こしています。アプリが1つのベンダーをハードコードしていれば、その障害はすべてあなたの障害になります。フォールバックチェーンがあれば、「プロバイダーダウン」は一瞬のレイテンシ増で済みます。

モデルごとに得意分野が違う

安くて速いモデルは分類や抽出を担当し、フロンティアモデルは推論の重い生成を担当します。タスクごとにティアを使い分けるだけで、推論コストが半分以下になることは珍しくありません。

価格は毎月変わる

モデル価格は下がり続けています。モデルの切り替えが1行の変更で済むなら、移行プロジェクトなしで四半期ごとに最良の価格性能比を追いかけられます。

ステップ1：1つのクライアントで多数のモデルを

公式のOpenAI SDKをゲートウェイに向けるだけで、独自のHTTPコードは不要です。

from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key="sk-or-..."
)

resp = client.chat.completions.create(
    model="anthropic/claude-sonnet-4.5",
    messages=[{"role": "user", "content": "Summarize this contract clause..."}],
)
print(resp.choices[0].message.content)

deepseek/deepseek-chat や google/gemini-2.5-pro への切り替えは、model の文字列を変えるだけです。モデル名はコードではなく設定に置きましょう。

TypeScript版

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://openrouter.ai/api/v1",
  apiKey: process.env.OPENROUTER_API_KEY,
});

const resp = await client.chat.completions.create({
  model: "deepseek/deepseek-chat",
  messages: [{ role: "user", content: "Classify this ticket: ..." }],
});

文字列を散らばらせず、モデルレジストリに

タスク→モデルティアのマッピングは1か所に集約します。

{
  "extract": "deepseek/deepseek-chat",
  "chat": "anthropic/claude-sonnet-4.5",
  "reason": "openai/gpt-5.2"
}

ステップ2：自動的に発動するフォールバック

models 配列

プライマリモデルがエラー、レート制限、タイムアウトになると、OpenRouterはサーバー側で優先順位付きリストに沿ってリクエストをリトライします ^[1]。

{
  "model": "openai/gpt-5.2",
  "models": ["anthropic/claude-sonnet-4.5", "deepseek/deepseek-chat"],
  "messages": [{ "role": "user", "content": "..." }]
}

レスポンスには実際にどのモデルがリクエストを処理したかが含まれます。必ずログに残しましょう。

プロバイダーレベルのフェイルオーバー

モデルフォールバックの下の層では、各モデルは複数のプロバイダーから提供されることがあります。ルーティング設定で特定のアップストリームを固定したり除外したりできます ^[2]。

{
  "model": "meta-llama/llama-3.3-70b-instruct",
  "provider": {
    "order": ["deepinfra", "together"],
    "allow_fallbacks": true
  }
}

クライアント側の最後の砦

ルーター自体に到達できない稀なケースに備えて、別ゲートウェイ（またはキャッシュ済みレスポンス）への1回だけのリトライで呼び出しをラップします。リトライは1回に留めること — リトライストームは自業自得の障害です。

ステップ3：回避できないコスト管理

最安優先ルーティング

レイテンシが二の次で良いなら、プロバイダーを価格順にソートします。リクエスト単位なら（"provider": {"sort": "price"}）、バッチジョブならモデルサフィックス :floor を使います。

厳格な価格上限

max_price は、上限（100万トークンあたりのドル額）を超える見積もりのプロバイダーをすべて拒否します。

{
  "model": "openai/gpt-5.2",
  "max_price": { "prompt": 1.5, "completion": 10 },
  "messages": [{ "role": "user", "content": "..." }]
}

これは希望条件ではなく保証です。上限内で処理できないリクエストは、静かに高くつく代わりに即座に失敗します。

リクエスト単位でコストを追跡

レスポンスにはusageが含まれます。実際に処理したモデルの料金を掛け合わせ、メトリクスとして送出しましょう。総支出だけでなくタスク単位コストのドリフトにアラートを張ること — 高価なモデルへの静かなフォールバックは、ドリフトとして表面化します。

テキストの先へ：画像・動画・音声にも同じパターンを

LLMルーターは言語モデル止まりです。実際のプロダクトは画像・動画・音声も生成します。そこでベンダーSDKをさらに5つも抱え込めば、いま解決したばかりの問題がそのまま再発します。

全モダリティを1つのゲートウェイで

APIMart は500以上のモデル — チャットに加えて GPT-Image-2、Sora 2、Kling、Veo、Suno — を、1つのOpenAI互換APIと1つの残高で提供します。

馴染みのある統合方法と割引価格

クライアントの設定はステップ1と同じで、base URLを変えるだけです。モデル単価は公式定価より約20%安く設定されています。正確なモデル別料金は料金ページをご覧ください。

ルーターの併用はまったく問題なし

よくある本番構成はこうです。テキストはOpenRouterか直接API、メディア生成はAPIMart — どちらもコード内では同じ抽象の背後にあり、どちらも設定だけで差し替え可能です。

本番リリース前チェックリスト

次の5つを揃えてリリースしましょう。設定駆動のモデルレジストリ、サーバー側フォールバックチェーン、レイテンシが許す範囲での最安優先ルーティング、全呼び出しへの max_price 上限、そしてドリフトアラート付きのリクエスト単位コストメトリクス。この組み合わせこそが、2人チームでも専任のオンコール当番なしにマルチモデルアプリを運用できる理由です。