Gateway Comparisons2026年7月1日Big Y

マルチプロバイダーLLMルーターの比較：請求、ログ、クォータ、フォールバック

アカウント所有権、請求、リクエストログ、クォータ、フォールバック動作、移行のしやすさ、Flatkeyとの適合性の観点から、マルチプロバイダーLLMルーターの選択肢を比較します。

マルチプロバイダーLLMルーターは、単なるモデル数の問題だけでなく、運用上の問題に答えられる場合にのみ役立ちます。ルーターを比較するチームは、誰がプロバイダーアクセスを所有しているか、使用量はどのように請求されるか、どのログがリクエストパスを証明するか、どこでクォータが適用されるか、フォールバックの試行はどのように記録されるか、そして既存のSDKやワークフローを移行するのがどれほど難しいかを知る必要があります。

この比較は、2026年7月1日（アジア/上海時間）に、Flatkeyの公開ホームページ、価格設定ページ、ライブ価格APIスナップショット、およびLiteLLM、OpenRouter、Portkey、Cloudflare、Vercelの公式ドキュメントを基に確認されました。モデルの行、エンドポイントファミリー、製品の文言、ルーティング動作、請求に関する言語は、特定の時点での証拠として扱ってください。本番トラフィックをいずれかのルーター経由で送信する前に、現在のダッシュボード、モデルの行、プロバイダーコンソール、およびリクエストログを確認してください。

クイックアンサー：マルチプロバイダーLLMルーターが証明すべきこと

チームにとって最適なマルチプロバイダーLLMルーターは、プロバイダーリストが最も長いものではありません。それは、あなたの所有権モデルに合致するものです。財務部門が1つの前払い残高と1つの請求書を望む場合、ルーターは請求レビューを簡素化する必要があります。プラットフォームエンジニアリングがプロバイダーキーの制御を望む場合、ルーターは認証情報の所有権とルーティングルールを明確に公開する必要があります。製品チームが回復力を必要とする場合、フォールバックログは最初のプロバイダーが失敗した後に何が起こったかを示す必要があります。

ルーターパターン	最適な用途	選択前に確認すべきこと
マネージドワンキーゲートウェイ	モデルアクセス、請求、ルーティング、使用状況分析、リクエストログ、クォータ制御を求め、個別のプロバイダーアカウントを減らしたいチーム。	現在のモデルの行、エンドポイントファミリー、価格単位、クォータの動作、リクエストログのフィールド、フォールバックの証拠、請求パス。
プロバイダーマーケットプレイスルーター	幅広いモデルカタログ、プロバイダーの優先設定、フォールバックモデル、およびオプションのBYOK（Bring-Your-Own-Key）パスを望むチーム。	クレジット対BYOKの動作、プロバイダールーティングの順序、フォールバックのトリガー、データポリシーの優先設定、レート制限の所有権、および応答モデルの帰属。
セルフホスト型または設定可能なプロキシ	プロバイダーキー、ルーティング設定、Redisまたはデータベースの状態、カスタムコールバック、および内部ポリシーロジックを所有したいプラットフォームチーム。	誰がプロキシを運用するか、支出はどのように追跡されるか、ログはどのように保持されるか、アップグレードはどのように処理されるか、プロバイダーの制限はどのように同期されるか。
クラウドまたはプラットフォームAIゲートウェイ	そのクラウドまたはデプロイメントプラットフォームにすでに投資しており、分析、ログ、レート制限、リトライ、フォールバック、または統合されたモデルアクセスを求めているチーム。	サポートされているプロバイダー、BYOKサポート、使用状況のエクスポート、請求エンティティ、ルーティング制御、アプリの帰属、およびクォータの境界。

Flatkeyは、マネージドワンキーゲートウェイのパターンに適合します。現在のホームページには、Flatkeyは本番AIチーム向けの単一のAPIゲートウェイであり、モデルアクセス、ルーティング、請求、使用状況分析、および運用制御を統合すると記載されています。同じページには、チームは1つのAPIキーを取得して、各プロバイダーに個別に申し込むことなく接続されたAIモデルを呼び出し、自動切り替えと負荷分散で複数のアップストリームアカウントをルーティングし、実際の使用量に応じて請求し、クォータ制限を設定し、チームの消費を明確に保つことができると記載されています。

マルチプロバイダーLLMルーター比較マトリックス

このマルチプロバイダーLLMルーターマトリックスを購入者のチェックリストとして使用してください。これはランキングではありません。適切な選択は、チームがマネージドアクセス、直接的なプロバイダー所有権、プロキシ制御、クラウドネイティブの可観測性、またはフレームワークレベルの利便性のいずれを優先するかによって異なります。

オプション	アカウントと請求の体制	ログとクォータ	フォールバックとルーティング	実用的な適合性
Flatkey	Flatkeyの公開ページには、1つのAPIキー、個別のプロバイダーアカウントの削減、前払い残高、使用量ベースの請求、使用状況分析、コスト管理、エンタープライズ向け請求書発行、調達サポート、およびプロバイダー横断での単一請求書について記載されています。	Flatkeyの公開ページには、リクエストログ、使用状況分析、クォータ制限、および明確なチーム消費量について記載されています。この記事のためのライブ価格設定APIスナップショットでは、227のモデル行、23のベンダー、および`anthropic`、`gemini`、`image-generation`、`openai`、`openai-video`を含むエンドポイントファミリーが返されました。	Flatkeyの公開ページには、自動切り替えとロードバランシングを備えた複数のアップストリームアカウント間でのルーティングについて記載されています。ご自身のワークフローに合わせて、正確なフォールバックログとモデル行の動作を検証してください。	目標が単一キー、統一された請求レビュー、使用証跡、およびプロバイダーアカウント作業の削減である場合に、商業的に適しています。価格設定から始め、次にキーを取得して範囲を限定したテストを行ってください。
LiteLLM	LiteLLMは、チームが設定可能なルーター/プロキシレイヤーとプロバイダーキーの制御を望む場合によく評価されます。公式のルータードキュメントには、デプロイメントとプロバイダー間でのロードバランシングについて記載されています。	LiteLLMのドキュメントによると、本番環境でRedisを使用して、TPM/RPM制限のためのクールダウンサーバーと使用状況を追跡できます。ドキュメントには、APIキー、APIエンドポイント、使用モデル、および応答コストを追跡するためのカスタムコールバックも示されています。	LiteLLMの公式ルーティングドキュメントには、デプロイメントとプロバイダー間でのロードバランシング、クールダウン、フォールバック、タイムアウト、リトライ、およびルーティング戦略について記載されています。	プラットフォームエンジニアリングがより深いプロキシ制御を望み、ゲートウェイの状態、設定、キー、およびアップグレードを運用する準備ができている場合に適しています。
OpenRouter	OpenRouterのドキュメントには、OpenRouterクレジットとBYOKについて記載されています。BYOKのドキュメントによると、プロバイダーキーを使用すると、プロバイダーアカウントを介してレート制限とコストを直接制御できますが、OpenRouterクレジットでは、プロバイダーのレート制限はOpenRouterによって管理されます。	OpenRouterのプロバイダールーティングドキュメントでは、プロバイダーの順序、許可されたプロバイダー、フォールバックの許可、データ収集の優先設定、ZDRルーティング、プロバイダーのソート、および最大価格など、リクエストレベルのプロバイダー設定が公開されています。	OpenRouterのドキュメントには、プロバイダーのロードバランシング、バックアッププロバイダー、価格、スループット、またはレイテンシーによるプロバイダーのソート、および`models`配列を介したモデルのフォールバックについて記載されています。	チームが広範なモデルルーティング、明示的なプロバイダー設定、およびクレジットとBYOKの選択肢を望む場合に適しています。請求の所有権が決定要因である場合は、OpenRouterの代替案と比較してください。
Portkey	Portkeyのドキュメントによると、古いVirtual Keysの概念はModel Catalogに移行し、そこでは1つのPortkey APIキーで複数のプロバイダーとモデルにアクセスでき、プロバイダーの認証情報は一元的に保存されます。	PortkeyのModel Catalogドキュメントには、組織レベルの管理、詳細な予算、レート制限、モデルの許可リスト、認証情報管理、およびアクセス制御について記載されています。	Portkeyのフォールバックドキュメントには、優先順位付けされたプロバイダー/モデルターゲット、デフォルトでの非2xx応答時のフォールバック、カスタムステータスコードトリガー、および設定IDまたはトレースIDによるフォールバックリクエストの追跡について記載されています。	チームがモデルカタログのガバナンス、プロバイダーの認証情報管理、および追跡可能なフォールバックチェーンを備えたゲートウェイを望む場合に適しています。
Cloudflare AI Gateway	Cloudflare AI Gatewayのドキュメントでは、この製品をAIアプリケーションの可視性と制御を中心に位置付けており、Workers AI、Anthropic、Google Gemini、OpenAI、Replicateなどのサポートされているプロバイダーが含まれています。	Cloudflareのドキュメントでは、AI Gatewayの機能として、分析、ロギング、コスト/トークンメトリクス、キャッシング、およびレート制限が挙げられています。	Cloudflareのドキュメントでは、エラー発生時の回復性のための機能として、リクエストのリトライとモデルのフォールバックが挙げられています。	アプリケーションが既にCloudflareエコシステム内に存在する場合、またはエッジに近い可観測性と制御が中心となる場合に適しています。
Vercel AI Gateway	Vercelのドキュメントによると、AI Gatewayは、単一のキー、数百のモデル、統一されたAPI、支出監視、およびBYOKを含むトークンのマークアップなしを提供します。	Vercelのドキュメントでは、プロバイダー横断での使用状況、レイテンシー、および支出に関する可観測性、さらに価格設定とメトリクスに関する使用状況と請求のドキュメントが示されています。	Vercelのドキュメントによると、AI Gatewayは、1つのプロバイダーが失敗した場合に他のプロバイダーへのリクエストを自動的にリトライし、ルーティング、フォールバック、および設定のためのプロバイダーオプションを提供します。	フレームワークフレンドリーな複数モデルへのアクセスと組み込みの支出可視性を求めるVercel中心のチームに適しています。

請求：支払いを行うエンティティから始める

マルチプロバイダーLLMルーターは、コードを変更する前に財務業務を変更します。難しい問題は「Claude、GPT、Gemini、および画像モデルを呼び出せるか？」ではなく、「誰がリクエストの料金を支払い、後でその請求を証明できるか？」です。

Flatkeyの現在の価格設定ページによると、チームは前払い残高から始め、トップモデル間でルーティングし、固定の月額バンドルなしで使用量をスケールできます。このページには、モデル、トークンタイプ、リクエストログによる使用量の計測、使用状況分析、コスト管理、エンタープライズ向け請求書発行、調達サポート、およびプロバイダー横断での単一請求書についても記載されています。これらの主張により、購入者がルーターに散在するプロバイダー請求の削減を求めている場合に、Flatkeyは特に適切となります。

OpenRouterのBYOKドキュメントは、異なる境界線を描いています。それによると、OpenRouterはクレジットとBYOK（bring-your-own provider keys）の両方をサポートしています。OpenRouterクレジットでは、プロバイダーのレート制限はOpenRouterによって管理されます。プロバイダーキーを使用すると、ユーザーはプロバイダーアカウントを介してレート制限とコストを直接制御できます。これは意味のある区別です。クレジットはルーターを通じて支払いを一元化し、BYOKはより直接的なプロバイダーアカウントの所有権を維持します。

VercelのAI Gatewayドキュメントも、請求の姿勢を明確にしています。それによると、トークンはBYOKを含め、マークアップなしでプロバイダーから直接購入する場合と同じコストがかかります。Portkeyのドキュメントは、Model Catalogを通じて一元的に保存されるプロバイダーの認証情報と、予算やレート制限などのガバナンス制御を強調しています。LiteLLMのルータードキュメントは設定可能な制御を強調していますが、運用チームはプロバイダーの請求書、キーの所有権、チャージバックの記録をどこに置くかを決定する必要があります。

ログ：リクエストレベルの証跡を求める

有用なマルチプロバイダーLLMルーターのログは、ステータスコードとレイテンシーだけにとどまりません。モデルトラフィックの場合、ログは開発者が失敗したレスポンスをデバッグするのに役立ち、財務部門がコスト項目を説明するのに役立つべきです。つまり、リクエストログには、アプリキー、ルート、モデル、プロバイダー、エンドポイントファミリー、トークンまたはユニットの使用量、ステータス、再試行またはフォールバックの試行、および利用可能な場合はコスト記録が必要です。

ログフィールド	重要性	要求すべき証拠
アプリキーまたはプロジェクト	使用状況をワークフロー、チーム、環境、または顧客に結びつけます。	アプリキーからモデルの使用状況、請求記録まで追跡された1つのリクエスト。
モデルとプロバイダー	要求されたエイリアスだけでなく、実際のルートを示します。	要求されたモデル、提供されたモデル、プロバイダー、エンドポイントファミリーが同じレコードに含まれていること。
トークン、画像、動画、またはリクエストユニット	異なるモダリティのコスト基盤を説明します。	入力、出力、キャッシュ、画像、動画、またはリクエストユニットが明確に示されていること。
フォールバックの試行	最初のプロバイダーが失敗したかどうか、そしてルーターが次に何を試したかを示します。	トレースID、試行順序、ステータスコード、および最終的に提供されたルート。
コストまたは残高への影響	財務部門に照合の手段を提供します。	リクエストコスト、残高控除、請求書のグループ化、またはエクスポート可能な使用記録。

Portkeyのフォールバックドキュメントは、要求すべき証拠の種類の良い例です。それによると、Portkeyはフォールバックチェーン内のすべてのリクエストをログに記録し、Config IDとTrace IDでフィルタリングして単一のリクエストに対するすべての試行を検査することを提案しています。Cloudflare AI Gatewayのドキュメントによると、アナリティクスはリクエスト、トークン、コストを表示でき、ロギングはリクエストとエラーに関する洞察を提供します。LiteLLMのドキュメントは、APIキー、APIエンドポイント、使用されたモデル、レスポンスコストをキャプチャできるカスタムコールバックを示しています。

クォータとレート制限：どの制限が失敗したかを知る

マルチプロバイダーLLMルーターでは、クォータは誤解されやすいものです。ワークフローは、アプリキーのクォータ、チームの予算、ゲートウェイのレート制限、プロバイダーアカウントのRPM/TPM制限、前払い残高、またはモデル固有の可用性条件によって制約される場合があります。これらは互換性がありません。

Flatkeyの公開ホームページには、チームがクォータ制限を設定し、チームの消費を明確に保つことができると記載されています。Cloudflare AI Gatewayのドキュメントでは、リクエスト数を制限することでアプリケーションのスケーリングを制御する方法としてレート制限が挙げられています。Portkey Model Catalogのドキュメントでは、きめ細かい予算、レート制限、モデルの許可リストについて言及されています。LiteLLMのドキュメントでは、使用状況とTPM/RPM制限の本番環境での追跡にRedisを使用することが言及されています。OpenRouterのBYOKドキュメントによると、プロバイダーキーを使用するとプロバイダーアカウントのレート制限とコストを直接制御でき、OpenRouterクレジットを使用するとプロバイダーのレート制限管理がOpenRouterに移管されます。

ルーターを選択する前に、意図的に小さな制限でクォータテストを実行してください。どのエラーが表示されるか、ログがクォータのソースを特定するか、レート制限後にフォールバックが許可されるか、財務部門がブロックされたリクエストを使用状況、使用なし、または失敗した使用状況として確認できるかを確認してください。

フォールバック：ルーターを信頼する前にトリガーを定義する

フォールバックは、マルチプロバイダーLLMルーターが静かに驚きを生み出す可能性がある部分です。フォールバックは可用性を向上させる可能性がありますが、モデルの動作、レイテンシー、価格単位、データ処理、ツールコールサポート、またはレスポンスの形状を変更することもあります。ルーターはフォールバックのトリガーと最終的なルートを可視化する必要があります。

OpenRouterのモデルフォールバックドキュメントによると、modelsパラメータを使用すると、プライマリモデルのプロバイダーがダウンしている、レート制限されている、またはモデレーションのために返信を拒否した場合に、リクエストが他のモデルを試すことができます。同じドキュメントには、リクエストは最終的に使用されたモデルに基づいて価格設定され、そのモデルはレスポンスボディで返されると記載されています。Portkeyのドキュメントによると、フォールバックは優先順位付けされたプロバイダー/モデルターゲットを使用でき、429や503などの特定のステータスコードでトリガーできます。Cloudflareのドキュメントでは、リクエストの再試行とモデルのフォールバックが回復力機能として挙げられています。

本番環境のレビューでは、「フォールバックは存在しますか？」とだけ尋ねないでください。次の質問をしてください：

トリガー：フォールバックは、すべての非2xxレスポンス、選択されたステータスコードのみ、プロバイダーのダウンタイム、レート制限、モデレーション、またはタイムアウトで発生しますか？
互換性：バックアップモデルは、同じツール、構造化出力、コンテキスト長、ストリーミング動作、およびモダリティをサポートしていますか？
コスト：フォールバックモデルは、異なる価格単位またはプロバイダーアカウントを使用しますか？
ロギング：チームは、1つのトレースですべての試行を確認できますか？
レスポンスの帰属：最終的なレスポンスは、実際にリクエストを処理したモデルを公開しますか？
ロールバック：インシデント中に、オペレーターはフォールバックを無効にしたり、プロバイダーを固定したりできますか？

移行：ベースURLの変更は最初のステップにすぎない

多くのルーター移行は、単純なベースURLとAPIキーの変更から始まります。しかし、それは完全な移行ではありません。マルチプロバイダーLLMルーターへの移行では、SDKリクエスト、レスポンスの形状、ストリーミングパス、ツール呼び出しの動作、使用記録、クォータの動作、およびロールバックパスが引き続き機能することを証明する必要があります。

本番環境に近いワークフローを1つ選択する：すべてのモデルから始めるのではなく、実際のプロンプト、期待されるレスポンスの形状、既知のコスト基準を持つルートを1つ選択します。
モデルエイリアスをマッピングする：リクエストされたモデル名、プロバイダールート、エンドポイントファミリー、およびフォールバック候補を文書化します。
追跡可能なリクエストを10件実行する：通常の呼び出し1件、ストリーミング呼び出しを使用している場合は1件、ツール呼び出しを使用している場合は1件、クォータテスト1件、意図的なプロバイダーまたはモデルの障害1件、および再試行/フォールバックテスト1件を含めます。
ログを比較する：アプリキー、ルート、モデル、プロバイダー、トークンまたはユニット数、ステータス、レイテンシー、フォールバックの試行、およびコスト記録を確認します。
請求を確認する：これらの同じリクエストを、プリペイド残高、クレジット、プロバイダーアカウント、請求書、または内部チャージバックまで追跡します。
ロールバックルールを作成する：ルーターが予期せず動作した場合に、直接プロバイダーアクセスに戻る方法、または既知のルートを固定する方法を文書化します。

移行に関するより詳しいコンテキストについては、このページをLiteLLMの代替製品およびエンタープライズAI APIゲートウェイのチェックリストと比較してください。ルーターの決定は、技術的な側面、財務的な側面、そして運用的な側面からなります。

ルーターの候補リストにおけるFlatkeyの位置付け

このマルチプロバイダーLLMルーターの比較において、Flatkeyが最も強みを発揮するのは、購入者がプロバイダーアカウントの作業を減らし、より明確な使用状況の運用を望む場合です。この記事のために確認された公開情報は、Flatkeyの以下の主張を裏付けています：

本番AIチーム向けの単一のAPIゲートウェイ。
各プロバイダーに個別に申し込むことなく、接続されたAIモデルに単一のAPIキーでアクセス。
個別のプロバイダーアカウント、散在するAPIキー、一貫性のないルーティング、断片化された使用状況追跡の削減。
自動切り替えとロードバランシングによる、複数のアップストリームアカウントをまたいだルーティング。
使用量ベースの請求、プリペイド残高、リクエストログ、使用状況分析、コスト管理、クォータ制限、エンタープライズ向け請求書発行、調達サポート、およびプロバイダー横断の単一請求書。
2026年7月1日のライブ価格APIスナップショットでは、227のモデル行、23のベンダー、およびエンドポイントファミリーanthropic、gemini、image-generation、openai、openai-videoが返されます。

その証拠は、すべてのモデル行があなたのアカウントで利用可能であること、特定のプロバイダールートが恒久的な価格を持つこと、またはフォールバックがあなたの正確な本番環境の動作と一致することを証明するものではありません。次の適切なステップは、範囲を限定した実証を行うことです。Flatkeyの価格ページを開き、現在のモデル行とエンドポイントファミリーを確認し、次にキーを取得して、上記の10リクエストの移行実証を実行します。

ルーター決定記録テンプレート

本番ワークフローでマルチプロバイダーLLMルーターを承認する前に、このテンプレートを使用してください。

決定項目	記録
ワークフローの所有者	チーム、アプリ、環境、およびビジネスオーナー。
プライマリモデルルート	リクエストされたモデル、提供されたモデル、プロバイダー、エンドポイントファミリー、およびアカウントまたはゲートウェイの認証情報ソース。
請求の所有者	プリペイド残高、ゲートウェイクレジット、BYOKプロバイダーアカウント、直接請求書、または内部チャージバックパス。
必須ログ	アプリキー、モデル、プロバイダー、使用単位、ステータス、レイテンシー、フォールバックトレース、およびコスト記録。
クォータのソース	アプリキークォータ、チーム予算、ゲートウェイのレート制限、プロバイダーのRPM/TPM、プリペイド残高、またはアカウントレベルの制限。
フォールバックポリシー	トリガー、バックアップルート、互換性チェック、最大試行回数、コスト予測、およびロールバックスイッチ。
承認の証明	10件の追跡可能なリクエスト、請求レビュー、フォールバックテスト、クォータテスト、およびロールバックテスト。

よくある質問

マルチプロバイダーLLMルーターとは何ですか？

マルチプロバイダーLLMルーターとは、複数のLLMプロバイダーにモデルリクエストを送信できるゲートウェイ、プロキシ、またはプラットフォームレイヤーのことです。本番環境では、認証情報、ルーティングポリシー、請求証跡、リクエストログ、クォータ、再試行、フォールバック動作の管理にも役立つべきです。

マルチプロバイダーLLMルーターはAI APIゲートウェイと同じですか？

これらは重複しますが、用語は必ずしも同じではありません。マルチプロバイダーLLMルーターは、プロバイダーとモデル間の選択を重視します。AI APIゲートウェイは通常、ログ、分析、クォータ、請求の可視性、アクセスポリシー、モデルトラフィックのガバナンスなど、より広範な運用管理機能を含みます。

マルチプロバイダーLLMルーターは、直接のプロバイダーアカウントを置き換えますか？

常にではありませんが、置き換える場合もあります。マネージドゲートウェイは、多くのワークフローで個別のプロバイダーアカウントを減らすことができます。BYOK（Bring Your Own Key）や自己ホスト型プロキシのパターンでは、ルーティングとロギングを一元化しながら、プロバイダーアカウントを自社の管理下に置くことができます。重要なのは、認証情報、レート制限、請求書、サポートパスを誰が所有するかを決定することです。

ルーターはどのようなログを公開すべきですか？

最低限、アプリキーまたはプロジェクト、リクエストされたモデル、提供されたモデル、プロバイダー、エンドポイントファミリー、ステータス、レイテンシ、トークンまたはユニット使用量、リトライ試行、フォールバックトレース、コストまたは残高への影響を要求してください。ログは、開発者と財務担当者の両方が同じリクエストを確認するのに役立つべきです。

フォールバックはどのようにテストすべきですか？

ドキュメントを読むだけでなく、制御された障害でフォールバックをテストしてください。トリガー、試行順序、最終的に提供されたモデル、ステータスコード、コストへの影響、レスポンスの形状、トレースの可視性を確認してください。ストリーミングやツール呼び出しのワークフローについては、それらのパスを個別にテストしてください。

どのような場合にFlatkeyを候補リストに入れるべきですか？

チームが単一のキー、プロバイダーアカウント作業の削減、統一された使用証跡、リクエストログ、クォータ制限、前払い残高、およびモデルトラフィック全体の請求書レビューを求めている場合は、Flatkeyを候補リストに入れてください。価格設定で現在のモデル行を確認し、次にキーを取得して、範囲を限定した実証実行を行ってください。

キーの取得：Flatkeyサインアップから始め、価格設定で最初のモデル行を確認し、本番展開前に請求、ログ、クォータ、フォールバックの動作を証明する小規模なリクエストセットを実行してください。