LLM Gateway vs Router vs Inference Provider：アーキテクチャの境界線

LLMゲートウェイ、ルーター、インファレンスプロバイダーは、モデルサービングスタックにおける3つの異なるレイヤーです。AI製品を設計する際、これらを混同してしまうことがチームにとって最も一般的なミスとなっています。ゲートウェイはアプリケーションに最も近く、認証、正規化、可観測性を処理します。ルーターは、特定の要求をどのモデルやプロバイダーが処理するかを決定します。インファレンスプロバイダーは、実際に重みを実行し、トークンを返す実体です。

この境界線を誤ると、統合が脆弱になります。ある単一プロバイダーのSDKをハードコーディングしてしまったチームが、数ヶ月後にフォールバックモデルを追加したり、Claude Sonnet 5、GPT-5.5、DeepSeek V4 Flash間でコストを比較しようとした際に、リクエスト処理の大部分を書き直さなければならない事態に陥るのです。本記事では、これら3つのレイヤーを分離し、それぞれの責任範囲を明確にした上で、各カテゴリーのベンダーを評価するための意思決定フレームワークを提示します。

重要なポイント

• インファレンスプロバイダーはモデルの重みを実行し、APIを公開します（OpenAI、Anthropic、Google、DeepSeek、またはvLLMのようなセルフホスト型エンジン）。ルーターはリクエストごとにプロバイダーやモデルを選択します。ゲートウェイは、認証、フォーマット、ログ記録、フェイルオーバーを統合するアプリケーション側のレイヤーです。
• ルーティングロジック（コストベース、レイテンシベース、または能力ベースの選択）は、スタンドアロンのサービスとして存在することも、ゲートウェイ内の機能として存在することもあります。これはゲートウェイそのものとは別物です。
• インファレンスプロバイダーのセルフホスト、APIベースのプロバイダーの利用、マルチプロバイダーゲートウェイの利用は、相互に排他的ではありません。本番環境のシステムでは、モデルやワークロードに応じてこれら3つを組み合わせることがよくあります。
• ベンダーを評価する際は、そのベンダーがどのレイヤーで実際に動作しているかを問いかけてください。「ルーター」として販売されている製品が、自社でホストしていないOpenAI互換エンドポイント間をルーティングするだけの場合もあれば、「ゲートウェイ」が、現時点では不要なガバナンス機能とルーティングをバンドルしている場合もあるためです。

インファレンスプロバイダーの実際の役割

インファレンスプロバイダーは、モデルの重み、GPU（または同等のアクセラレータ）、および低レベルのサービングエンジンを所有するレイヤーです。これには、Anthropic (Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5)、OpenAI (GPT-5.5)、Google (Gemini 3.5 Flash)、Zhipu (GLM-5.2)、DeepSeek (DeepSeek V4 Pro, DeepSeek V4 Flash) といった商用APIプロバイダーや、Qwen3.7 Plus、MiniMax M3、Kimi K2.7 Codeのようなオープンウェイトモデルのセルフホストデプロイメントが含まれます。

セルフホストする場合、インファレンスプロバイダーのレイヤーは自身で実行するソフトウェアとなります。vLLMのサービングドキュメントでは、LLMワークロードを大規模に処理するための連続バッチ処理とメモリ効率の高いアテンション処理に基づいたインファレンスエンジンについて説明されており、これがセルフホストモデルのデプロイメントの直下に配置されるコンポーネントです。vLLM（または同等のエンジン）を実行することは、あなたがそのモデルのインファレンスプロバイダーになることを意味し、コストとデータローカリティを制御する代わりに、GPUのキャパシティプランニング、スケーリング、稼働時間を管理する責任を負うことになります。

商用APIを使用する場合、プロバイダーのインフラストラクチャとレート制限が制約となります。各プロバイダーには独自の認証スキーム、リクエストおよびレスポンスのスキーマ、エラーコード、レート制限の動作があります。モデルの品質、コンテキストウィンドウ、生のレイテンシが実際に決定されるのはこのレイヤーです。ルーターやゲートウェイがインファレンスプロバイダーの能力を変えることはできず、それらはプロバイダーへの到達方法を変えるだけです。

ルーターの役割

ルーターは、着信リクエストに対して宛先、モデル、またはプロバイダーを選択する意思決定ロジックです。ルーティングは、コスト（単純なクエリはDeepSeek V4 FlashやGemini 3.5 Flashに送り、複雑なものはClaude Opus 4.8に予約する）、レイテンシ（特定のモデルに対して現在最も応答が速いプロバイダーを優先する）、可用性（最初のプロバイダーが低下した場合に2番目のプロバイダーにフェイルオーバーする）といった複数の軸で行うことができます。

OpenRouterのモデルルーティングに関する公開解説では、このパターンがモデルレベルで説明されています。オープンウェイトモデルへのリクエストは、同じ重みをホストする複数のプロバイダー間でルーティングできるため、単一の論理的なモデル呼び出しを複数のバックエンドのいずれかで満たすことができます。OpenRouterのプロバイダー選択ドキュメントでは、順序の優先順位を表現したり、特定のプロバイダーを検討対象から除外したりするためのパラメータがさらに説明されており、これは呼び出し側がプラットフォームに完全に任せるのではなく、ルーティングの意図を明示的に表現するためのメカニズムです。

重要なアーキテクチャ上のポイントは、ルーティングはポリシーであり、それ自体が製品カテゴリーではないということです。基本的なルーティングはアプリケーションコード内で（タスクタイプによる単純なif/elseやエラー時の再試行ループなど）実装することも、専用のルーティングレイヤーとして購入することも、より広範なゲートウェイ内にバンドルされたものを利用することもできます。ルーティング能力を評価する際は、どのようなシグナル（価格、レイテンシ、エラー率、モデル能力）を使用しているか、またそれらのシグナルが設定可能か固定かを問いかけてください。

ゲートウェイの役割

ゲートウェイは、アプリケーションコードが実際に通信するレイヤーです。その仕事は、最終的にどのインファレンスプロバイダーがリクエストを処理するかに関わらず、一貫したインターフェースを提供することです。ゲートウェイには通常、以下が含まれます。

• プロバイダー間での統一されたリクエストおよびレスポンススキーマ。これにより、GPT-5.5からClaude Sonnet 5への切り替えに際して、パースロジックを書き直す必要がなくなります。
• 認証とキー管理。これにより、プロバイダーの資格情報がアプリケーションコード全体に散らばることを防ぎます。
• 使用中のすべてのモデルとプロバイダーにわたるログ記録、使用状況の追跡、およびコストの帰属管理。
• プロバイダーが低速、レート制限中、またはエラーを返した場合のフェイルオーバーと再試行の動作。
• オプションとして、製品全体ではなく、複数の機能の一つとしてのルーティングロジック。

TokenLabのモデルリサーチページでは、フロンティアモデル（Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5, GPT-5.5, GLM-5.2, Gemini 3.5 Flash）、コーディング指向モデル（Claude Sonnet 5, Kimi K2.7 Code, DeepSeek V4 Pro, DeepSeek V4 Flash）、および低コストのルーティング候補（DeepSeek V4 Flash, GLM-5.2, Laguna XS 2.1, Hy3, Qwen3.7 Plus, MiniMax M3）など、プロバイダー全体の現在のモデルがカタログ化されています。これはゲートウェイのユーザーが何にルーティングするかを決定する際に必要なリファレンスです。統一問題そのものに関するより詳細な解説については、TokenLabの「なぜ2026年に統一されたAI APIゲートウェイが重要なのか」という記事を参照してください。

アーキテクチャの境界線を具体的に見る

この境界線は、単一のリクエストが3つのレイヤーすべてを通過する様子を追うと最も分かりやすくなります。

1. アプリケーションがゲートウェイエンドポイントにチャットコンプリーションリクエストを送信し、タスクタイプやモデルの優先順位を指定します。
2. ゲートウェイがリクエストを認証し、各候補プロバイダーの期待するスキーマに正規化し、ルーティングロジックに渡します。
3. ルーターが設定されたポリシー（コスト上限、レイテンシ目標、または明示的なプロバイダー順序）を評価し、宛先を選択します（例：AnthropicのAPI経由のClaude Sonnet 5、またはvLLM経由で提供されるセルフホスト型のDeepSeek V4 Proインスタンスなど）。
4. インファレンスプロバイダーがモデルを実行し、トークンを返します。
5. ゲートウェイがレスポンスを一貫した形状に正規化し、結果（レイテンシ、コスト、使用されたプロバイダー、成功または失敗）を可観測性レイヤーのためにログに記録します。

各レイヤーは独立して故障する可能性があります。プロバイダーの停止はインファレンスレイヤーの問題であり、誤ったルーティング決定（コンテキストウィンドウが小さいモデルに長いコンテキストのリクエストを送るなど）はルーターレイヤーの問題であり、パーサーを壊す一貫性のないレスポンススキーマはゲートウェイレイヤーの問題です。どのレイヤーが特定の障害を引き起こしたかを理解することが、デバッグを容易にします。TokenLabの「AI APIのための信頼性インフラストラクチャ」に関する記事では、これらのレイヤー間での障害分離についてより深く掘り下げています。

意思決定チェックリスト

ゲートウェイ、ルーター、直接的なプロバイダー統合、あるいはそれらの組み合わせが必要かどうかを評価する際は、このチェックリストを使用してください。

質問	はいの場合	いいえの場合
現在複数のモデルやプロバイダーを呼び出しているか、あるいは12ヶ月以内にそうする予定があるか？	プロバイダーごとの直接SDK呼び出しではなく、ゲートウェイまたはルーターレイヤーが必要です。	短期的には直接的なプロバイダーSDK統合で十分かもしれません。
プロバイダーが低下またはレート制限されたときに自動フェイルオーバーが必要か？	ヘルスチェックとフォールバック順序を備えたルーターレベルのロジックが必要です。	最初はアプリケーションコード内の手動再試行で許容できるかもしれません。
プロバイダー全体にわたるモデルごとのコストと使用状況の可視化が一箇所で必要か？	ゲートウェイレベルのログ記録と帰属管理が必要です。	プロバイダーネイティブのダッシュボードで当面は十分かもしれません。
オープンウェイトモデル（GLM-5.2, DeepSeek V4 Pro, Qwen3.7 Plus, Kimi K2.7 Code）をセルフホストしているか？	インファレンスプロバイダーレイヤーも運用しており、vLLMのようなサービングインフラが必要です。	商用APIプロバイダーに完全に依存できます。
タスクタイプごとにルーティングする必要があるか（分類には安価なモデル、推論にはフロンティアモデルなど）？	単なるフェイルオーバーではなく、明示的なルーターポリシーが必要です。	単一のデフォルトモデルで十分かもしれません。

リクエスト形状の例

以下の例は、プライマリモデルの優先順位とフォールバックリストの両方を表現するゲートウェイ型リクエストの一般的な形状を示しています。これは、OpenRouterのプロバイダー選択ドキュメントでルーティングの優先順位を表現する方法と一致するパターンです。フィールド名は例示として扱い、出荷前に選択したゲートウェイの現在のAPIリファレンスと照らし合わせて正確なパラメータを確認してください。

POST /v1/chat/completions
Content-Type: application/json
Authorization: Bearer <api_key>

{
  "model": "claude-sonnet-5",
  "fallback_models": ["gpt-5.5", "deepseek-v4-flash"],
  "routing_policy": {
    "strategy": "cost_then_latency",
    "max_cost_per_1k_tokens": 0.01
  },
  "messages": [
    {"role": "user", "content": "Summarize the attached incident report."}
  ]
}

この形状では、ゲートウェイがリクエストの正規化とレスポンスの契約を所有し、ルーターがrouting_policyとfallback_modelsの解釈を所有し、最終的に選択されたプロバイダーが実際にコンプリーションを生成することを所有します。本番環境で特定のフィールド名に依存する前に、現在のドキュメントと照らし合わせて正確なリクエストおよびレスポンススキーマを確認してください。

制限事項

OpenRouterやvLLMの公開ドキュメントは、一般的なルーティングおよびサービングのメカニズムを説明するものであり、普遍的な保証ではありません。正確なレイテンシ、価格設定、フェイルオーバーの動作はプロバイダーによって異なり、時間の経過とともに変化するため、本記事ではなくプロバイダーのドキュメントと照らし合わせて現在の数値を直接確認してください。vLLMによるセルフホストは、運用上の責任（キャパシティプランニング、スケーリング、パッチ適用）をチームに移すものであり、インフラ作業を排除するのではなく、場所を移動させるだけです。どのようなルーティングポリシーも、根本的に不適切なモデル選択（長いコンテキストの推論が必要なタスクを、それに適していないモデルに送るなど）を補うことはできません。ルーターの設定は、ワークロードに対してモデルの能力を評価することの代わりにはなりません。そのため、TokenLabのモデルリサーチのような最新のモデルリファレンスを維持することが重要なのです。

FAQ

ゲートウェイはルーターと同じですか？ いいえ。ルーターはモデルやプロバイダーを選択するための意思決定ロジックであり、ゲートウェイは認証、正規化、ログ記録と並んでルーティングを一つの機能として含む、より広範なアプリケーション側のレイヤーです。

自分でインファレンスプロバイダーになりつつ、ゲートウェイを使用することはできますか？ はい。vLLMのようなエンジンを通じて提供されるセルフホストモデルは、ゲートウェイがカスタムエンドポイントまたはOpenAI互換エンドポイントをサポートしている限り、商用APIプロバイダーと同じゲートウェイの背後に配置できます。

初日から3つのレイヤーすべてが必要ですか？ 必ずしもそうではありません。初期のプロトタイプであれば、単一プロバイダーの直接統合で十分です。フェイルオーバー、マルチモデルのコスト管理、またはプロバイダー比較が必要になった時点で、ルーティングを備えたゲートウェイを導入することはエンジニアリングコストに見合うものとなります。

最初にどのレイヤーを採用すべきか検討している場合は、TokenLabのモデルリサーチページで現在のモデルオプションを確認し、統合を最初から一つに固定するのではなく、ルーティングやプロバイダーを段階的に追加できるゲートウェイ設定から始めてみてください。