多くのAIエージェントは、実行のあらゆるフェーズを単一のモデルに依存しています。計画立案、ツール呼び出し、データ抽出、要約、エラー復旧のすべてが同一のLLMを通じて処理されます。このアプローチは初期のプロトタイプ作成には適していますが、本番環境では大きな非効率性を招きます。
高度な推論を必要とする計画立案ステップと、基本的なJSON抽出ステップに同じモデルは必要ありません。コード生成タスクと分類タスクでは、求められる要件が異なります。日付文字列をフォーマットするためにClaude Fable 5やClaude Opus 4.8のような上位の推論モデルを使用することは、リソースの無駄遣いです。
複数のモデルを使用してAIエージェントを構築することで、ワークフローの各ステップをそのタスクに最適なモデルにルーティングできるようになります。本ガイドでは、こうしたマルチモデルアーキテクチャの設計、実装、管理方法について解説します。
エージェントオーケストレーション層ではなくAPI層に取り組んでいる場合は、本ガイドと併せてAgent-First API DesignおよびWhy Teams Switch from Direct Model APIs to a Unified AI APIを参照してください。マルチモデルエージェントは、オーケストレーションコードを書き直すことなくモデルを切り替えられるほど、基盤となるAPIインターフェースが安定している場合に最も信頼性が高く動作します。
:::info
重要なポイント
- タスクの複雑さにモデルを合わせる：ルーティング、抽出、フォーマットには高速な小型モデルを使用し、計画立案や複雑な分析には大規模な推論モデルを割り当てる。
- スキーマを標準化する：モデルプロバイダーを切り替える際のコントラクトの乖離を防ぐため、すべての受け渡し地点で厳格な出力検証（Pydanticなど）を実装する。
- フォールバックを設計する：レート制限、プロバイダーの停止、レイテンシの急増が発生してもエージェントのワークフローを中断させないよう、自動フォールバック経路を構築する。
- テレメトリを一元化する：ステップごとのレイテンシ、入出力トークン数、コストを追跡し、ルーティングロジックを継続的に最適化する。 :::
マルチモデルエージェントのアーキテクチャ
マルチモデルエージェントアーキテクチャは、複雑さ、コスト、レイテンシの要件に基づいて、専門化されたモデルにタスクを分散させます。
ユーザーのリクエスト
│
▼
┌─────────────┐
│ ルーター │ ← タスクの複雑さを分類
│ (高速モデル) │
└──────┬──────┘
│
┌───┴───┐
▼ ▼
┌──────┐ ┌──────┐
│単純な │ │複雑な │
│モデル │ │モデル │
└──┬───┘ └──┬───┘
│ │
▼ ▼
┌─────────────┐
│ アグリゲータ │ ← 結果を統合
│ (高速モデル) │
└─────────────┘
中核となるアーキテクチャは、以下の5つの主要コンポーネントで構成されます。
- ルーター：タスクの複雑さと意図を分類する、高速かつ低コストなモデル。
- モデルプール：タスクの種類（推論、抽出、コード生成など）に合わせて最適化されたモデルの集合。
- アグリゲータ：並列ステップの結果を統合し、最終的な回答を作成する高速モデル。
- フォールバックポリシー：メインのモデルが失敗、タイムアウト、またはレート制限に達した場合に使用するモデルを決定するルール。
- テレメトリ層：モデルの選択、レイテンシ、ステップごとの正確なトークンコストを記録するログシステム。
フォールバックポリシーとテレメトリがなければ、マルチモデルエージェントはデバッグが困難になり、レイテンシやコストの予測が難しくなります。
OpenAI SDKによる実装
統合APIゲートウェイを使用すると、単一のSDKとAPIキーで異なるプロバイダーのモデルにアクセスできます。これにより、モデルの切り替えやルーティングが簡素化されます。
以下の例は、基本的なルーティングの実装を示しています。モデルの可用性と価格については、TokenLabモデルディレクトリで確認してください。
from openai import OpenAI
client = OpenAI(
api_key="sk-tokenlab-xxx",
base_url="https://api.tokenlab.sh/v1"
)
# コストと能力に応じたモデルプール
MODELS = {
"router": "deepseek-v4-flash", # 高速な分類
"simple": "deepseek-v4-flash", # 抽出、フォーマット
"reasoning": "claude-sonnet-5", # 計画立案、分析
"complex": "gpt-5.5", # コード生成、複雑なロジック
"budget": "deepseek-v4-flash", # 一括処理
}
def route_task(task: str) -> str:
"""低コストモデルを使用してタスクの複雑さを分類する"""
response = client.chat.completions.create(
model=MODELS["router"],
messages=[
{"role": "system", "content": """以下のタスクを1つのカテゴリに分類してください:
- simple: データ抽出、フォーマット、翻訳
- reasoning: 分析、計画立案、比較
- complex: コード生成、多段階の問題解決
- budget: 一括処理、重要度の低いタスク
カテゴリ名のみを小文字で返してください。"""},
{"role": "user", "content": task}
],
max_tokens=10
)
category = response.choices[0].message.content.strip().lower()
return MODELS.get(category, MODELS["simple"])
def execute_task(task: str, context: str = "") -> str:
"""タスクを選択したモデルにルーティングして実行する"""
model = route_task(task)
messages = []
if context:
messages.append({"role": "system", "content": context})
messages.append({"role": "user", "content": task})
response = client.chat.completions.create(
model=model,
messages=messages
)
return response.choices[0].message.content
実用的なエージェント：コードレビューパイプライン
複数のモデルでAIエージェントを構築する実際の影響を確認するために、プルリクエスト（PR）をレビューするパイプラインを考えてみましょう。このワークフローでは、コードの差分全体を単一の高価なモデルに送るのではなく、レビューを専門的なステップに分割します。
def review_pr(diff: str) -> dict:
"""マルチモデルPRレビューパイプライン"""
# ステップ1: 高速・低コストモデルで変更内容を分類
classification = client.chat.completions.create(
model="deepseek-v4-flash",
messages=[{
"role": "user",
"content": f"以下のコード変更を分類してください: {diff[:2000]}\n"
"カテゴリ: bugfix, feature, refactor, docs, test"
}],
max_tokens=20
).choices[0].message.content
# ステップ2: 強力な推論モデルでセキュリティスキャンを実行
security = client.chat.completions.create(
model="claude-sonnet-5",
messages=[{
"role": "system",
"content": "あなたはセキュリティレビュー担当者です。以下を確認してください: "
"SQLインジェクション、XSS、認証バイパス、コード内のシークレット、"
"安全でないデシリアライズ。行番号を具体的に指摘してください。"
}, {
"role": "user",
"content": f"この差分をセキュリティの観点でレビューしてください:\n{diff}"
}]
).choices[0].message.content
# ステップ3: 汎用モデルでコード品質を分析
quality = client.chat.completions.create(
model="gpt-5.5",
messages=[{
"role": "user",
"content": f"コード品質をレビューしてください: 命名、構造、"
f"エラーハンドリング、テストカバレッジ。\n{diff}"
}]
).choices[0].message.content
# ステップ4: 高速・低コストモデルで要約を生成
summary = client.chat.completions.create(
model="deepseek-v4-flash",
messages=[{
"role": "user",
"content": f"このPRレビューを3つの箇条書きで要約してください:\n"
f"タイプ: {classification}\n"
f"セキュリティ: {security[:500]}\n"
f"品質: {quality[:500]}"
}]
).choices[0].message.content
return {
"classification": classification,
"security": security,
"quality": quality,
"summary": summary
}
コストと効率の最適化
以下の表は、このパイプラインにおけるモデルの割り当てを示しています。正確な価格はプロバイダーやボリュームによって異なります。最新の料金はTokenLabモデルディレクトリで確認してください。
| ステップ | モデル | 入力トークン | 役割 / 特化分野 |
|---|---|---|---|
| 1. 分類 | DeepSeek V4 Flash | ~2,100 | 高速な分類、低コストルーティング |
| 2. セキュリティ | Claude Sonnet 5 | ~2,500 | 深い推論、セキュリティ分析 |
| 3. 品質 | GPT-5.5 | ~2,500 | 高度なコード品質および構造レビュー |
| 4. 要約 | DeepSeek V4 Flash | ~1,200 | 高速、低コストなテキスト集約 |
これら4つのステップすべてをClaude Sonnet 5やGPT-5.5のようなフラッグシップ推論モデルで実行すると、コストが大幅に増加します。単純なタスクをDeepSeek V4 Flashのような低コストモデルにルーティングすることで、マルチモデルパイプラインは重要なセキュリティ分析ステップのために深い推論能力を維持しつつ、全体的なトークン消費を削減します。
価格だけでなく「能力」によるルーティング
コスト削減は一般的な目標ですが、ルーティングの決定は特定のモデルの能力も考慮すべきです。堅牢なルーティングポリシーは、以下の4つの主要な側面でモデルを評価します。
- 推論の深さ：複雑なロジック、計画立案、多段階の推論。
- コンテキストウィンドウ：タスクに必要な背景情報やコードの量。
- ツール使用の信頼性：関数呼び出しと構造化出力生成の正確性。
- レイテンシ感度：ユーザー向けアプリケーションの速度要件。
これらの側面は、明確なルーティングルールを確立するのに役立ちます。
- 分解や計画立案タスクは、推論能力の高いモデルにルーティングする。
- データ抽出やフォーマットタスクは、高速で低コストなモデルにルーティングする。
- コード生成や構文解析は、コーディングタスクに最適化されたモデルにルーティングする。
- リポジトリ全体の分析タスクは、大きなコンテキストウィンドウを持つモデルにルーティングする。
ルーターをこれらの要件に合わせるには、コーディングモデルの比較や価格比較を参照し、ワークフローのステップと現在のモデルベンチマークを照らし合わせてください。
LangChainとの統合
LangChainのようなオーケストレーションフレームワーク内でもマルチモデルルーティングを実装できます。以下の例では、統合APIベースURLを使用して異なるモデルを設定しています。
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
# 異なる設定でモデルを初期化
fast_model = ChatOpenAI(
model="deepseek-v4-flash",
api_key="sk-tokenlab-xxx",
base_url="https://api.tokenlab.sh/v1"
)
reasoning_model = ChatOpenAI(
model="claude-sonnet-5",
api_key="sk-tokenlab-xxx",
base_url="https://api.tokenlab.sh/v1"
)
# 専門的なチェーンを定義
classify_chain = ChatPromptTemplate.from_template(
"このリクエストの意図を分類してください: {input}"
) | fast_model
analyze_chain = ChatPromptTemplate.from_template(
"この問題の詳細な分析を実行してください: {input}"
) | reasoning_model
マルチモデルエージェントを使用すべきタイミング
複数のモデルを導入するとアーキテクチャが複雑になります。このアプローチは、通常以下の場合に最も有益です。
- 多様なタスク要件：エージェントが単純なタスク（分類やフォーマットなど）と複雑なタスク（戦略的計画やコード生成など）の両方を処理する場合。
- 高いボリュームとコスト：月間のAPI支出が高く、最適化によって意味のある節約が見込める場合。
- 専門的なモデルの強み：Geminiのコンテキストウィンドウ、Claudeのコーディング能力、GPTのツール使用速度など、特定のプロバイダーの強みをワークフローで活かせる場合。
- 非対称なレイテンシニーズ：ワークフローの一部は即座に結果を返す必要があり、他のバックグラウンドステップは時間がかかっても許容される場合。
単一目的のエージェントや単純なチャットインターフェースの場合、単一モデルの方が維持管理が容易です。すべてのリクエストに同じレベルの能力が必要な場合、ルーティングの運用オーバーヘッドは正当化されない可能性があります。
一般的な失敗モード
マルチモデルアーキテクチャには、緩和策が必要な特有の失敗モードが存在します。
1. 過剰に設計されたルーター
ルーターのプロンプトが複雑になりすぎると、分類ステップ自体が遅く高価になります。ルーティングプロンプトは簡潔に保ち、分類カテゴリは広く設定してください。
2. 出力コントラクトの乖離
JSONを返すように指示しても、モデルによってフォーマットが異なる場合があります。あるモデルは生のJSONを返し、別のモデルはマークダウンブロックで囲むかもしれません。後続のパーサーの失敗を防ぐため、ステップの受け渡しごとにPydanticのような検証ライブラリを使用して厳格なスキーマを強制してください。
3. 静かな品質低下
メインのプロバイダーの停止中にフォールバックポリシーが下位モデルにリクエストをルーティングした場合、エージェントはエラーを発生させずに品質の低い回答を返す可能性があります。明確なレート制限戦略とアラートシステムを実装し、フォールバックがいつアクティブになったかを追跡してください。
4. 断片化されたテレメトリ
モデルの使用状況が複数の直接プロバイダーAPIに分散していると、コストやパフォーマンスの指標を集計するのが困難になります。単一のゲートウェイを通じてリクエストを一元化することで、ログ記録とコスト追跡が簡素化されます。
最小限の評価ループ
マルチモデルエージェントを維持するために、パフォーマンスを追跡する基本的な評価ループを確立してください。各実行について、以下の指標をデータベーステーブルに記録できます。
- タスクカテゴリ：ルーターによって割り当てられた分類。
- 選択されたモデル：各ステップで選択されたモデル。
- ステップレイテンシ：各ステップの完了にかかった時間。
- トークン使用量：正確な入力および出力トークン数。
- フォールバックステータス：フォールバックモデルがトリガーされたかどうか。
- ユーザーフィードバック：最終的な出力が成功したかどうかのバイナリ指標。
このデータを分析することで、ルーターが正しいモデルを選択しているか、どのステップがコストの大部分を占めているか、フォールバックモデルが許容可能な品質を維持しているかを確認できます。
FAQ
モデル間で異なるプロンプト形式をどのように処理しますか？
モデルによって最適なプロンプト構造は異なります。例えば、システムプロンプトでうまく機能するモデルもあれば、ユーザープロンプトに指示を埋め込む方が好ましいモデルもあります。これに対処するには、すべてのモデルに同一の生の文字列を送るのではなく、ターゲットモデルに基づいて適応するテンプレートにプロンプトを抽象化してください。
ルーティングはユーザー向けアプリケーションに過度なレイテンシを追加しますか？
ルーティングは分類ステップのためにわずかなレイテンシを追加します。これは、ルーターに高度に最適化された低レイテンシモデルを使用し、最大トークン制限を低く（10トークン未満）抑えるか、ユーザーのアプリケーション状態やエントリーポイントから分類を推論できる場合にステップを並列化することで最小限に抑えられます。
モデルを切り替える際のJSON解析エラーをどのように防ぎますか？
解析エラーを防ぐには、モデルプロバイダーがサポートする構造化出力機能（JSONモードやツール呼び出しなど）を使用してください。さらに、すべてのモデル出力をPydanticなどのライブラリを使用した検証層でラップし、パイプラインの次のステップに渡す前にペイロードを解析、検証、修復してください。
すべてのモデルに1つのAPIでアクセス：TokenLabを始めると、単一のAPIキーで300以上のモデルにアクセスできます。複数のプロバイダーアカウントを管理したり、APIごとにルーティングロジックを書き直したりすることなく、マルチモデルエージェントを構築しましょう。
出典
価格確認日 2026-07-07
- TokenLab model directory2026-07-07 時点で確認
- Berkeley Function Calling Leaderboard2026-07-09 時点で確認
- SWE-bench2026-07-09 時点で確認
- RouteLLM paper2026-07-09 時点で確認
- Braintrust LLM router guide2026-07-09 時点で確認
