1つのアプリで複数AIモデルを使う：アーキテクチャとコード

単一アプリケーションで複数AIモデルを運用することは贅沢ではありません——2026年の基本装備です。すべての次元でリードする単一のAIモデルはありません。複雑なデバッグにはClaude Opus。エージェントの信頼性にはGPT-5.5。マルチモーダルにはGemini。コストにはDeepSeek。単一モデルのアプリは能力を取りこぼしている——あるいは、より安いモデルが同等に処理するタスクに払いすぎています。

しかし、複数モデルを配線する——フォールバックチェーン、ルーティングロジック、統合モニタリング——部分は誰も教えてくれません。チュートリアルは1つのAPIの呼び出し方を示します。本番は4つ必要です。この記事は、「GPT-5.5を呼べる」を「私のアプリはすべてのリクエストに最適なモデルを自動で使い、オールフロンティアより70%安い」に変えるアーキテクチャを示します。

単一モデルアーキテクチャが負債になる理由

プロバイダー障害は起こります。 OpenAIは2026年上半期に3回の大規模障害がありました。直接APIユーザーはエラーを見ました。フォールバック付きマルチモデルアプリは、リクエストを黙ってClaudeやDeepSeekにルーティングしました。ユーザーは気づきませんでした。あなたのSLAは、リクエストを送る別の場所がある場合のみプロバイダー障害を乗り切れます。障害に加えて、レート制限——特に本番の429エラー——は、マルチモデルルーティングがプロバイダー間で負荷を分散して排除する、もう1つの単一プロバイダーリスクです。

モデル廃止は四半期ごとです。 OpenAIは過去1年で3つのモデルを廃止しました。Anthropicは1つ。移行には、プロンプト再調整と出力検証に数週間かかります——統合・テスト済みのフォールバックモデルがすでにあれば別ですが。マルチモデルアーキテクチャは、廃止を移行プロジェクトではなくルーティング変更にします。

すべてのタスクに最適な単一の価格帯はありません。 分類と抽出に、出力$30/MのGPT-5.5は不要です。DeepSeek V4 Flashは$0.28/Mで同等にこなします。

1日100,000件の分類リクエストでの差：$900/日 対 $8.40/日。マルチモデルルーターはこの差を自動で捉えます。単一モデルのアプリはすべてのリクエストでプレミアムを払います。

起こる必要のなかった実世界の失敗。 2026年第1四半期に私が関わったECチームは、フォールバックなしの単一モデルでAI不正検出を運用していました。火曜の午後、プロバイダーの内部ロードバランサーが故障し、47分間503エラーを返しました。その間のすべての取引が手動レビューにフラグされました：312件の注文、$47,000の売上が宙に浮きました。

サポートチケットは3倍に。エンジニアチームはその47分間、プロバイダーを切り替える緊急ホットフィックスをデプロイするのに費やしました——最初からマルチモデルで設計していれば設定トグル1つだった変更です。彼らは次のスプリントでフォールバックチェーンを出荷しました：30行のPythonと朝のテスト1回。

障害の総コスト：チャージバック、手動レビュー労力、カートを放棄した顧客からの失われた再購入で約$12,000。

統合クライアントパターン

マルチモデルアーキテクチャの基盤は、どのプロバイダーでも動く単一インターフェースです。アプリケーションコードはclient.chat()を呼びます。クライアントがルーティング、変換、フォールバックを処理します。

Python——UnifiedClientクラス：

from openai import OpenAI
import logging

class UnifiedLLMClient:
    def __init__(self, base_url: str, api_key: str):
        self.client = OpenAI(base_url=base_url, api_key=api_key)

    def chat(self, model: str, messages: list, **kwargs):
        """One method. Any model. Same parameters."""
        return self.client.chat.completions.create(
            model=model,
            messages=messages,
            **kwargs
        )

modelパラメータがプロバイダー間で変わる唯一のものです。他のすべて——メッセージ形式、ストリーミング、temperature、max_tokens——は同じまま。これがOpenAI互換標準が重要な理由です：マルチモデルアーキテクチャを統合問題ではなく設定問題にします。LiteLLMのルーターのようなツールは、この記事の5つの戦略すべてを設定オプションとして実装します。

集約プラットフォームはこれをさらに進めます：base_urlは、すでにすべてのプロバイダーにルーティングする1つのエンドポイントを指します。統合クライアントは、"gpt-5.5"、"claude-opus-4-8"、"gemini-3.1-pro"、"deepseek-v4-pro"を指定できるmodelパラメータを持つ単一API呼び出しになります——プロバイダー固有のコードは不要です。

フォールバックチェーン：リクエストを落とさない

最も単純なマルチモデルパターン——そして最も多くのインシデントを防ぐもの。

import logging
from openai import OpenAI

client = OpenAI(
    base_url="https://api.tokspan.com/v1",
    api_key="ts-your-key-here"
)

FALLBACK_CHAIN = [
    "claude-opus-4-8",      # Primary
    "gpt-5.5",               # First fallback
    "deepseek-v4-pro"        # Last resort
]

def chat_with_fallback(messages, model_chain=FALLBACK_CHAIN, timeout=30):
    """Try models in order. First success wins. All fail = raise."""
    last_error = None

    for model in model_chain:
        try:
            response = client.chat.completions.create(
                model=model,
                messages=messages,
                timeout=timeout
            )
            return response.choices[0].message.content
        except Exception as e:
            last_error = e
            logging.warning(f"Model {model} failed: {type(e).__name__}. Trying next in chain.")
            continue

    raise RuntimeError(f"All {len(model_chain)} models failed. Last error: {last_error}")

本番での考慮事項。 一貫して失敗するプロバイダーにはサーキットブレーカーを。30秒間5xxを返すプロバイダーは、次の60秒間スキップ——毎リクエストでリトライしない。単純な時間ベースフラグでプロバイダーごとのクールダウンを追跡。クールダウン終了後に1リクエストでプローブ。成功すればクールダウンを解除。失敗すればタイマーをリセット。

これが実際に節約するもの。 OpenAIは2026年上半期に3回の大規模障害を経験しました。GPT-5.5の単一モデルアプリは、それぞれ47分、23分、12分ダウン——80分超のユーザー向けエラー。上の3モデルフォールバックチェーンを運用するチームは、3つの障害すべてでゼロダウンタイム。OpenAIが復旧している間、リクエストは黙ってClaudeとDeepSeekにルーティングされました。実装コスト：10行のtry/exceptチェーン。実装しないコスト：80分のダウンタイムがあなたのビジネスにいくらかかるか。

5つのルーティング戦略：コストベースから品質ベースまで

フォールバックチェーンは障害を処理します。ルーティング戦略は残りの99.9%のリクエスト——すべてが稼働していて、各タスクに最適なモデルが欲しいとき——を処理します。

戦略1：コストベースルーティング。 各リクエストを、適切に処理できる最安モデルに送ります。

def cost_based_route(user_message: str) -> str:
    """Classify task complexity, route to cheapest capable model."""
    complexity = classify_complexity(user_message)  # Use a cheap model to classify
    if complexity == "simple":
        return "deepseek-v4-flash"     # $0.14/$0.28
    elif complexity == "medium":
        return "deepseek-v4-pro"       # $0.44/$0.87
    else:
        return "claude-sonnet-4-6"     # $3/$15

節約：オールフロンティア比70〜95%。 分類器はリクエストあたり約$0.000004。節約はドル単位で測れます。ルーティングを超えたコスト削減戦略の深掘りは、コスト削減戦略ガイドをご覧ください。

戦略2：レイテンシベースルーティング。 最低品質閾値を満たす最速モデルにルーティング。エンドポイントごとにレイテンシ予算——例えばp95 500ms——を設定。プライマリモデルがそれを超えたら、トラフィックはより速い代替に移行。本番では、DeepSeek V4 Flashは短い完了で平均180ms、Claude Opusは420ms——チャットインターフェースでユーザーが気づく240msの差。トレードオフ：高速モデルが内部評価ベンチマークで低い場合、レイテンシルーティングは黙って応答品質を劣化させ得ます。ルーティングされたリクエストの5%をサンプリングして出力をベースラインと比較する品質ゲートと組み合わせましょう。

戦略3：品質ベースルーティング。 タスクの複雑度（単純/中程度/複雑）を分類。適切な能力階層にルーティング。単純——DeepSeek Flash。中程度——Claude Sonnet。複雑——Claude Opus。

戦略4：加重配分付きラウンドロビン。 個々のレート制限内に収まるようプロバイダー間で負荷を分散。レート制限管理に加えて、加重配分はコストブレンドを可能にします：フロンティアと予算モデルを固定比率（60% GPT-5.5 / 40% DeepSeek V4 Pro）で混ぜ、予測可能なブレンドコストを実現。1日100,000リクエスト・60/40分割なら、出力トークンの平均$4.80/M——純粋フロンティアの$15/Mではなく——アプリケーションロジックを1行も変えずに68%削減。加重ルーティングは地域レイテンシのスパイクも平滑化します：プロバイダーBのus-east-1クラスターが劣化したら、復旧が確認されるまでその重みをプロバイダーAとCに再配分。

戦略5：フォールバック付き優先順位。 固定優先：「常にClaude Opus、フォールバックGPT-5.5、フォールバックDeepSeek」。実装が最も簡単。多くのチームに十分。

戦略比較：

戦略	最適な用途	複雑さ	コストへの影響	信頼性の向上
コストベース	高頻度・コスト重視のアプリ	中	70–95%の節約	低
レイテンシベース	リアルタイムチャット、音声	中	影響なし	低
品質ベース	混合ワークロード	中	50–90%の節約	中
ラウンドロビン	レート制限の管理	低	影響なし	高
優先順位	シンプルなフォールバック	非常に低	影響なし	高

多くのチームはPriority-Order（10行、障害を防止）から始めましょう。API請求が月$500を超えたらコストベースルーティングを追加。他の戦略は必要なときに追加する最適化です。フェイルオーバー、キャッシュ、コスト帰属付きの完全なルーティング実装は、カスタムルーティングドキュメントをご覧ください。

統合オブザーバビリティ

複数モデル＋複数プロバイダー＝オブザーバビリティは必須です。

統合ロギングスキーマ： すべてのAPI呼び出しをプロバイダーに関係なく同じフィールドでログ——OpenTelemetryのGenAIセマンティック規約が、ほとんどのオブザーバビリティプラットフォームが採用する標準スキーマを提供します。

import time, json

def log_request(model: str, messages: list, response, latency_ms: float):
    log_entry = {
        "timestamp": time.time(),
        "model": model,
        "provider": get_provider_for_model(model),
        "prompt_tokens": response.usage.prompt_tokens,
        "completion_tokens": response.usage.completion_tokens,
        "cost": calculate_cost(model, response.usage),
        "latency_ms": latency_ms,
        "status": "success"
    }
    # Write to your logging system —CloudWatch, Datadog, custom
    logging.info(json.dumps(log_entry))

実際に必要な3つのダッシュボード。 (1)モデル別・日別コスト——「$500の驚き」を起こる前にキャッチ。(2)プロバイダー別p50/p95レイテンシ——ユーザーが文句を言う前に劣化を検出。(3)プロバイダー別エラー率——サーキットブレーカーとフォールバックを自動トリガー。

集約プラットフォームはこれらのダッシュボードを標準装備しています。自分でマルチモデルシステムを構築するなら、オブザーバビリティ設定に2〜3日予算を——それは「何かおかしい」と「Claude Opusのp95レイテンシがこの1時間で300ms増加、トラフィックの30%をGPT-5.5にルーティング中」の違いです。

複数AIモデルを使うべきでないとき

複数AIモデルアーキテクチャにはコストの下限があります。1日1,000リクエスト未満のアプリでは、追加の複雑さが正当化されることは稀です。

単一モデルが正しい選択なのは：(1)月間API請求が$100未満——ルーティングの節約が、プロバイダー間のフォールバックチェーンとオブザーバビリティ管理の統合オーバーヘッドを相殺しない。(2)1つのプロバイダーを専用で使い、切り替えを不経済にするエンタープライズボリューム割引を交渉済み——GPT-5.5の出力$8/Mを固定する方が、標準レートで3プロバイダーに分散するより良い。(3)アプリが単一の狭いタスク型（例：固定ナレッジベースからのRAGベースQ&Aのみ）を実行し、1つのモデルクラスが一貫して最良で、プロバイダー間のコスト差が無視できる。(4)チームが小さい——エンジニア3人未満——帯域幅はインフラ抽象化層より製品機能に使う方が良い。

マルチモデルが純益になる閾値：およそ月10,000リクエスト。それ以下では、エンジニアリング時間を機能に。それ以上では、この記事のアーキテクチャは最初の月にコスト節約だけで元を取ります。

その閾値を越えるチームには、Priority-Orderフォールバックパターンから始めましょう——10行のコードで、完全なルーティング層なしに最大の障害モードを防ぎます。

FAQ

本番ではいくつのモデルを使うべきですか？

3つから：1つの安い主力モデル（DeepSeek V4 Flash）、1つの中級（Claude SonnetまたはGPT-5.4 Mini）、1つのフロンティア（Claude OpusまたはGPT-5.5）。ニーズが増えたら専門モデルを追加。5つ超は通常オーバーオプティマイゼーション——ルーティングの複雑さが限界的コスト節約を上回ります。

マルチモデルルーティングは大きなレイテンシを追加しますか？

ルーティングロジック自体：10ms未満。コストベースと品質ベースルーティングは分類ステップを追加（安いモデルで約200ms）。分類コストはリクエストあたり約$0.000004。単純タスクを安いモデルに送って1リクエストあたり$0.01〜0.05節約できるなら十分価値があります。

始められる最も単純なマルチモデルパターンは？

プライマリモデル＋1つのフォールバック。今日コードに追加しましょう：try: primary_model(); except: fallback_model()。10行。LLM関連ダウンタイムの最も一般的な原因を防ぎます。月間API請求が3桁になったらフルルーティングにアップグレード。

異なるモデルのコンテキストウィンドウをどう扱いますか？

クライアント設定でモデルごとにmax_tokensを設定。小さいコンテキストウィンドウのモデルにフォールバックするときは、収まるように会話履歴を切り詰めます。切り詰めイベントをログ——フォールバックモデルのコンテキスト上限をアップグレードする必要があるときがわかります。

集約プラットフォームなしでできますか？

はい。3〜5つのプロバイダーSDK、3〜5つの請求システム、3〜5つのレート制限ダッシュボードを管理し、独自のルーティング・フォールバック・オブザーバビリティ層を構築します。初期設定に1〜2週間、月4〜8時間のメンテナンスを見積もりましょう。集約プラットフォームはこれを、組み込みのルーティング・フォールバック・モニタリング付き単一エンドポイントに集約します。問題は、チームの時間をインフラ構築に使うか機能構築に使うかです。

マルチモデルアーキテクチャは複雑さのための複雑さではありません。コスト・品質・レイテンシ・能力を同時に最適化する単一プロバイダーは存在しないという認識です。この記事のアーキテクチャは単一モデルアプリに約50行のPythonを追加します——その見返りに、プロバイダー障害を障害モードから排除し、API請求を70%削減します。

あなたの番です：既存のAPI統合を開いてください。フォールバックモデルを追加——プライマリモデルからの失敗をキャッチしてバックアップにルーティングするtry/exceptの1行。それで10行。15分かかります。LLM関連ダウンタイムの最も一般的な原因を防ぎます。フォールバックが入ったら、戦略1のコストベース分類器を追加して請求が下がるのを見てください。アプリを再構築する必要はありません——決定ポイントを2つ追加するだけです。

この記事の冒頭のフォールバックチェーンは10行のPythonです。コストベースルーターはさらに40行。その1時間を製品機能に使いたいなら、集約プラットフォームは両方をインフラとして出荷します——OpenAIクライアントがすでに指しているエンドポイントが、プロバイダー間でルーティングし、フェイルオーバーを処理し、モデル別コストをログできます。ルーティング層を自分で構築するか既存のものを使うかにかかわらず、アーキテクチャ決定は同じです：1つのモデルは負債。2つは保険。3つが本番の標準です。