ほとんどのAIエージェントは、すべての処理に単一のモデルを使用しています。プランニング、ツール呼び出し、要約、エラーリカバリなど、すべてです。これはデモには適していますが、本番環境では非効率的です。
高度な推論を必要とするプランニングのステップには、JSON抽出のステップと同じモデルは必要ありません。コード生成タスクには、分類タスクとは異なる要件があります。日付文字列のフォーマットに Claude Opus 4.6（出力100万 token あたり25ドル）を使用するのは、壁を塗るためにシニアアーキテクトを雇うようなものです。
ここでは、各ステップを最適なモデルにルーティングするエージェントの構築方法を解説します。
エージェントレイヤーではなく API レイヤーに取り組んでいる場合は、このページと併せて「Agent-First API Design」および「Why Teams Switch from Direct Model APIs to a Unified AI API」を読んでください。マルチモデルエージェントは、基盤となる API サーフェスが十分に安定しており、オーケストレーションコードを書き直すことなくモデルを入れ替えられる場合に最も効果的に機能します。
マルチモデルエージェントのアーキテクチャ
ユーザーリクエスト
│
▼
┌─────────────┐
│ ルーター │ ← タスクの複雑さを分類
│ (高速モデル) │
└──────┬──────┘
│
┌───┴───┐
▼ ▼
┌──────┐ ┌──────┐
│単純な│ │複雑な│
│モデル│ │モデル│
└──┬───┘ └──┬───┘
│ │
▼ ▼
┌─────────────┐
│アグリゲーター│ ← 結果を統合
│ (高速モデル) │
└─────────────┘
3つのコンポーネント：
- 入ってくるタスクを複雑さによって分類するルーター
- 異なるタスクタイプに適合させたモデルのプール
- 必要に応じて結果を統合するアグリゲーター
実際には、本番環境のエージェントには通常、さらに2つの要素が必要です：
- 優先モデルが失敗したり遅延したりした場合のフォールバックポリシー
- ステップごとのモデルの選択、レイテンシ、コストを記録するテレメトリレイヤー
これら2つがないと、マルチモデルエージェントはすぐに予測不可能な挙動を示すブラックボックスになってしまいます。
OpenAI SDK を使用した実装
アグリゲーターを介して単一の API キーを使用することで、複数の SDK を管理することなくすべてのモデルにアクセスできます。
from openai import OpenAI
client = OpenAI(
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
# コスト/能力ティアごとのモデルプール
MODELS = {
"router": "gpt-4.1-mini", # $0.40/1M in - 高速な分類
"simple": "gpt-4.1-mini", # $0.40/1M in - 抽出、フォーマット
"reasoning": "claude-sonnet-4-6", # $3.00/1M in - プランニング、分析
"complex": "gpt-4.1", # $2.00/1M in - コード生成、マルチステップ
"budget": "deepseek-chat", # $0.28/1M in - 大量処理
}
def route_task(task: str) -> str:
"""安価なモデルを使用してタスクの複雑さを分類する。"""
response = client.chat.completions.create(
model=MODELS["router"],
messages=[
{"role": "system", "content": """このタスクを以下のいずれかのカテゴリに分類してください：
- 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
実例エージェント：コードレビュー・パイプライン
プルリクエストをレビューする実践的なマルチモデルエージェントの例です：
def review_pr(diff: str) -> dict:
"""マルチモデル PR レビュー・パイプライン。"""
# ステップ 1: 変更内容の分類（安価なモデル）
classification = client.chat.completions.create(
model="gpt-4.1-mini",
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-4-6",
messages=[{
"role": "system",
"content": "あなたはセキュリティレビューアーです。以下をチェックしてください： "
"SQL インジェクション、XSS、認証バイパス、コード内のシークレット、 "
"安全でないデシリアライゼーション。行番号を具体的に指定してください。"
}, {
"role": "user",
"content": f"この diff のセキュリティ問題をレビューしてください:\n{diff}"
}]
).choices[0].message.content
# ステップ 3: コード品質（汎用モデル）
quality = client.chat.completions.create(
model="gpt-4.1",
messages=[{
"role": "user",
"content": f"コード品質をレビューしてください：命名、構造、 "
f"エラーハンドリング、テストカバレッジ。\n{diff}"
}]
).choices[0].message.content
# ステップ 4: 要約（安価なモデル）
summary = client.chat.completions.create(
model="gpt-4.1-mini",
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
}
一般的な PR レビュー（2K token の diff）のコスト内訳：
| ステップ | モデル | 入力 Token 数 | コスト |
|---|---|---|---|
| 分類 | GPT-4.1-mini | ~2,100 | $0.0008 |
| セキュリティ | Claude Sonnet 4.6 | ~2,500 | $0.0075 |
| 品質 | GPT-4.1 | ~2,500 | $0.0050 |
| 要約 | GPT-4.1-mini | ~1,200 | $0.0005 |
| 合計 | ~$0.014 |
4つのステップすべてに Claude Sonnet 4.6 を使用した場合、コストは約0.028ドルになります。マルチモデルアプローチを採用することで、最も重要な部分（セキュリティレビュー）に最強のモデルを使いつつ、コストを50%削減できます。
価格だけでなく、能力によるルーティング
多くのチームは、「高価なタスクは高価なモデルへ、安価なタスクは安価なモデルへ」という単純なルールからマルチモデルルーティングを開始します。
これは最初のステップとしては良いですが、それだけでは不十分です。
より強力なルーティングポリシーは、以下の4つの次元を考慮します：
- 推論の深さ
- コンテキスト長
- tool-use の信頼性
- レイテンシ感度
これにより、より優れたルールが導き出されます：
- プランニングと分解は、推論に強いモデルに任せる
- 抽出とフォーマットは、安価で高速なモデルに任せる
- コードレビューは、バグ発見能力が最も高いモデルに任せる
- リポジトリ全体の分析は、コンテキストウィンドウが最大のモデルに任せる
これが、コーディングモデルの比較や価格比較を、単なる調査資料として眠らせておくのではなく、ルーターの判断材料にすべき理由です。
LangChain との統合
from langchain_openai import ChatOpenAI
# 異なる設定でモデルインスタンスを作成
fast = ChatOpenAI(
model="gpt-4.1-mini",
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
reasoning = ChatOpenAI(
model="claude-sonnet-4-6",
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
# LangChain のチェーンで使用
from langchain_core.prompts import ChatPromptTemplate
classify_chain = ChatPromptTemplate.from_template(
"Classify: {input}"
) | fast
analyze_chain = ChatPromptTemplate.from_template(
"Analyze in depth: {input}"
) | reasoning
マルチモデルエージェントを使用すべきケース
マルチモデルルーティングは複雑さを増大させます。以下の条件に当てはまる場合は、その価値があります：
- エージェントが（チャットだけでなく）多様なタスクタイプを処理する場合
- 月間の API コストが100ドルを超える場合（節約が意味を持つようになる）
- 特定のモデルの強みが必要な場合（コードには Claude、長いコンテキストには Gemini、速度には GPT など）
- 一部のステップではレイテンシが重要だが、他のステップではそうでない場合
シンプルなチャットボットや単一目的のエージェントであれば、単一のモデルで十分です。すべてのリクエストに同じ能力が必要な場合、ルーティングのオーバーヘッドは正当化されません。
転換点は通常、以下のいずれかです：
- 価値の低いタスクに対して、ハイエンドな推論コストを支払っている
- 特定のプロバイダーの障害が、現実的なビジネスリスクになっている
- ワークフロー全体でコンテキストのニーズが大きく異なる
- 1つの高価なコアステージの周囲に、より安価なレビュー/抽出/要約ステージが必要である
これらが当てはまらない場合は、単一モデルが依然として正解です。
よくある失敗パターン
マルチモデルシステムは、予測可能な形で失敗します：
1. ルーターが賢すぎる
ルーターのプロンプトが巨大な分類作業になってしまうと、何をするかを決めるためだけにコストがかかりすぎてしまいます。ルーターは安価で大まかなものに留めておきましょう。
2. 出力コントラクトの乖離
あるモデルはクリーンな JSON を返し、別のモデルは JSON ブロックを含む文章を返し、その結果、下流のパーサーが壊れるという事態です。すべての受け渡しにおいて、明示的なスキーマとバリデーションを使用してください。
3. フォールバックによる品質のサイレントな変化
プロバイダーの負荷時に安価なモデルにルーティングすると、ユーザーから見て品質プロファイルが全く異なってしまい、エージェントが不安定に見えることがあります。そのため、レート制限戦略は後付けではなく、設計に組み込むべきです。
4. コスト報告の欠如
ステップごとのモデル選択、コスト、レイテンシを記録していないと、マルチモデル設計が実際にコスト削減に繋がっているかどうかを判断できません。
最小限の評価ループ
マルチモデルエージェントを責任を持って運用するために、巨大な評価プラットフォームは必要ありません。
まずは、実行ごとに1つのシートまたはデータベーステーブルから始めましょう：
- ユーザータスクのカテゴリ
- ルーターの決定
- 各ステップで使用された最終モデル
- ステップごとのレイテンシ
- 合計 token コスト
- フォールバックがトリガーされたかどうか
- ユーザーが回答を受け入れたかどうか
これだけで、重要な問いに答えるための十分なシグナルが得られます：
- ルーターは適切な頻度で正しい高価なモデルを選択しているか？
- どのステップが予算の大部分を消費しているか？
- フォールバックは実行を救っているのか、それとも単に不安定さを隠しているだけか？
- 反復的なタスクに対して、安価なパスは十分に機能しているか？
これが、統合ゲートウェイが役立つ理由でもあります。モデルの使用が多くのプロバイダーに分散していると、比較可能な1つの実行ログを組み立てるのが難しくなります。すべてが1つの API レイヤーを経由していれば、計測の負担が激減します。
アーキテクチャを「退屈」に保つ
優れたマルチモデルエージェントは、エキゾチックな感じがしません。運用上、退屈に感じられるものです。
それはつまり：
- オーケストレーションレイヤーへのリクエスト形状が1つで安定している
- ルーティングルールを定義する場所が1箇所である
- コストとレイテンシを確認する場所が1箇所である
- タスクファミリーごとに1つのフォールバックポリシーがある
- モデルの許可リストの信頼できる情報源が1つである
エージェントのグラフが巧妙に見えても、運用担当者がなぜリクエストがあるモデルではなく別のモデルに送られたのかを説明できないのであれば、その設計は未完成です。
マルチモデルエージェントを使用すべきでないケース
シンプルな設計が勝る明確なケースもあります。
モデルカタログが豊富だからという理由だけでルーティングを追加しないでください。
以下の場合には、単一モデルを使い続けてください：
- 製品が1つの狭いタスクを繰り返し実行する場合
- モデル間の品質の差がユーザーにとって無関係な場合
- トラフィックが少なすぎて、コスト最適化が重要でない場合
- 運用面での計測がまだ不十分な場合
- ルーティングが功を奏したか、あるいは悪影響を及ぼしたかを判断できるほど強力な評価（evals）がまだない場合
適切に選択された単一のモデルに、優れたリトライ、プロンプトの整理、オブザーバビリティを組み合わせた方が、誰も信頼していない派手なマルチモデルグラフよりも優れていることがよくあります。
正しい問いは「ルーティングできるか？」ではなく、「ルーティングによって、このワークフローの品質向上、コスト削減、またはより安全な失敗挙動が実現するか？」です。
答えが曖昧な場合は、ワークフロー自体がより多様になるまで、アーキテクチャをシンプルに保ちましょう。
重要なポイント
- 各ステップを適切に処理できる、最も安価なモデルを使用する
- 高価なモデルは、真にそれを必要とするタスクのために予約する
- 分類/ルーティングのステップには、常に利用可能な最も安価なモデルを使用する
- 単なる token 単価ではなく、エージェント実行あたりの実際のコストを測定する
- 1つのキーを持つ API アグリゲーターを使用すると、マルチモデルへのアクセスが大幅に簡素化される
マルチモデルエージェントは、本質的に優れているわけではありません。ワークフローに真に異なる種類の作業が含まれている場合に、初めてその真価を発揮します。
1つの API ですべてのモデルにアクセス：LemonData は、単一の API キーで300以上のモデルを提供します。複数のプロバイダーアカウントを管理したり、プロバイダーの組み合わせごとにルーティングを再発明したりすることなく、マルチモデルエージェントを構築できます。