Gateway Comparisons2026年7月1日Big Y

OpenRouter、LiteLLM、Flatkeyの比較：ホスト型ルーター、自己ホスト型プロキシ、ワンキーゲートウェイ

OpenRouter、LiteLLM、Flatkeyを、アカウント所有権、請求、BYOK、ログ、クォータ、フォールバック動作、移行の手間、プルーフチェックの観点から比較します。

OpenRouterとLiteLLMの比較は、単なるモデルカタログの比較ではありません。現実的な選択は、チームがホスト型ルーター、自己ホスト型または高度に設定可能なプロキシ、あるいはプロバイダーアカウントと請求業務を削減するマネージドワンキーゲートウェイのどれを望むかということです。

この比較は2026年7月1日に、Flatkeyの公開ページ、Flatkeyのライブ価格APIスナップショット、および公式のOpenRouterとLiteLLMのドキュメントと照合して確認されました。プロバイダーのルーティング動作、モデルの行、レート制限、価格単位、製品の文言は、特定の時点での証拠として扱ってください。本番環境への展開前に、ご自身のアカウントで現在のプロバイダーコンソール、ゲートウェイダッシュボード、リクエストログ、クォータ、請求エクスポートを確認してください。

OpenRouter、LiteLLM、Flatkeyの比較：迅速な意思決定

OpenRouterとLiteLLMの比較の要約が必要な場合：OpenRouterは、プロバイダーのルーティング制御を備えた多くのモデルへのホスト型アクセスと、OpenRouterクレジットとBYOK（Bring Your Own Key）の選択肢を求める場合に最も強力です。LiteLLMは、プラットフォームチームがプロキシレイヤーを運用し、設定を所有し、予算、仮想キー、コールバック、プロバイダーの認証情報をインフラストラクチャに組み込みたい場合に最も強力です。Flatkeyは、問題がプロキシの構築よりも、単一のキー、統一された使用証跡、リクエストログ、クォータ制御、そして財務部門がレビューできる請求経路を得ることにある場合に、候補リストに加えられるべきです。

選択肢	最適なケース	検証すべき主なトレードオフ
OpenRouter	ホスト型のモデルルーター、プロバイダーの優先設定、フォールバックモデル、OpenRouterクレジット、または独自のプロバイダーキーの持ち込みを望むチーム。	各リクエストのレート制限、コスト、プロバイダー選択、フォールバック動作、データポリシーの優先設定をどのアカウントが所有するか。
LiteLLM	設定、自己ホストが可能で、内部の予算、キー、ロギングシステムと統合できるOpenAI互換のプロキシ/ゲートウェイを望むプラットフォームチーム。	誰がプロキシ、データベースまたはRedisの状態、プロバイダーのシークレット、ロギングの保持、アップグレード、インシデント対応を運用するか。
Flatkey	単一のAPIキー、モデルアクセス、使用状況分析、リクエストログ、クォータ、および統合された請求レビューを望む開発者、AI製品チーム、自動化構築者、財務担当者。	現在のFlatkeyのモデルの行、エンドポイントファミリー、クォータの動作、リクエストログが本番ワークフローに適合するかどうか。

核心的な違い：ホスト型ルーター、プロキシ、またはワンキーゲートウェイ

OpenRouterとLiteLLMの決定は通常、ルーティングから始まりますが、所有権で終わるべきです。ホスト型ルーティング、自己ホスト型プロキシ、ワンキーゲートウェイアクセスは、それぞれ異なる組織的な問題を解決します。

OpenRouterの公式プロバイダールーティングドキュメントには、プロバイダーの順序、許可されたプロバイダー、無視されたプロバイダー、フォールバックの許可、価格、スループット、またはレイテンシーによるソート、最大価格フィルタリングなどのリクエストレベルのプロバイダー設定が記載されています。そのモデルフォールバックドキュメントには、選択したモデルがエラー（レート制限、ダウンタイム、モデレーションフラグ、コンテキスト長の検証エラーを含む）を返した場合のフォールバックモデルが記載されています。そのBYOKドキュメントでは、OpenRouterクレジットとプロバイダーキーも区別されています。OpenRouterはクレジットのプロバイダーレート制限を管理しますが、プロバイダーキーを使用すると、プロバイダーアカウントを通じてレート制限とコストを直接制御できます。

LiteLLMの公式ドキュメントでは、プロキシサーバー、つまりLLMゲートウェイを、自己ホスト型のOpenAI互換ゲートウェイとして説明しています。同じドキュメントには、リトライ、フォールバック、ロードバランシングのためのルーターの動作、キーごと、チームごと、またはユーザーごとの予算を持つ仮想キー、集中ロギング、ガードレール、キャッシング、そして監視用の管理UIが記載されています。LiteLLMのアーキテクチャドキュメントによると、リクエストは仮想キー、レート制限、そしてLLM APIデプロイメントのロードバランシング、フォールバック、リトライを処理するLiteLLMルーターのチェックを通過します。

Flatkeyの現在のホームページでは、Flatkeyを、モデルアクセス、ルーティング、請求、使用状況分析、運用管理を統合する、本番AIチーム向けの単一のAPIゲートウェイとして説明しています。チームは各プロバイダーに個別に申し込むことなく、接続されたAIモデル用の単一のAPIキーを取得し、自動切り替えとロードバランシングで複数のアップストリームアカウントにまたがってルーティングし、実際の使用量に応じて請求し、クォータ制限を設定し、チームの消費を明確に保つことができると述べられています。価格ページには、前払い残高、モデル、トークンタイプ、リクエストログによる使用量計測、使用状況分析、コスト管理、エンタープライズ向け請求書発行、調達サポート、およびプロバイダー横断の単一請求書についても記載されています。

比較マトリックス

このOpenRouterとLiteLLMの比較マトリックスを購入チェックリストとして使用してください。これはランキングではありません。なぜなら、正しい答えは、チームがホスト型アクセス、インフラストラクチャの制御、または統合された運用のどれを優先するかによって異なるからです。

決定領域	OpenRouter	LiteLLM	Flatkey
運用モデル	OpenRouterによって文書化されたプロバイダーとモデルのルーティング制御を備えたホスト型ルーター。	チームが運用する自己ホスト型または設定可能なOpenAI互換のプロキシ/ゲートウェイ。	アクセス、ルーティング、使用状況、クォータ、請求を1か所で管理したいチーム向けのマネージドワンキーゲートウェイ。
プロバイダーアカウントの所有権	OpenRouterクレジットまたはBYOKを使用可能。プロバイダーキーは、レート制限とコスト管理をプロバイダーアカウントに結び付けます。	通常、チームがプロバイダーの認証情報とプロキシ設定を所有します。	接続されたモデルの個別のプロバイダーアカウント作業を削減するように設計されています。ワークフローの正確なアカウントとサポートの境界を検証してください。
請求レビュー	クレジットかBYOKか、そして最終的に使用されたモデル/プロバイダーによって異なります。	プロバイダーの請求書、コスト追跡、およびプロキシ周辺の内部チャージバックをどのように結びつけるかによって異なります。	公開ページには、プリペイド残高、使用量ベースの請求、コスト管理、エンタープライズ向け請求書発行、調達サポート、およびプロバイダー横断の単一請求書について記載されています。
ルーティングとフォールバック	プロバイダーのルーティング、バックアッププロバイダー、ソートされたプロバイダー、最大価格、およびモデルのフォールバック制御が文書化されています。	ルーターのドキュメントには、ロードバランシング、フォールバック、リトライ、およびレート制限を考慮したインフラストラクチャパターンが記載されています。	公開ページには、自動切り替えとロードバランシングを備えたアップストリームアカウント間のルーティングが記載されています。リクエストログで正確なフォールバックの証拠を確認してください。
ログとクォータ	アカウントのレスポンス属性、使用制限、クレジット残高、およびBYOKリクエストの動作を検証してください。	ドキュメントには、仮想キー、予算、RPM/TPM制限、ロギング、コールバック、および支出追跡が記載されています。	公開ページには、リクエストログ、使用状況分析、クォータ制限、および明確なチームの消費量が記載されています。
移行作業	通常、ベースURL/API統合とプロバイダールーティングルールの設定から始まります。	プロキシのデプロイ、設定、シークレット、データストアの決定、監視、およびアップグレードの所有権が必要です。	通常、1つのキー、価格/モデル行の検証、およびスコープを限定したリクエストログの証明実行から始まります。

アカウントの所有権：誰がキーを管理するかから始める

OpenRouterとLiteLLMを比較する上で最も重要な問いは、「どちらがそのモデルをサポートしているか？」ではありません。それは、「誰がアカウント、プロバイダーキー、レート制限、そして請求書を所有しているか？」です。

OpenRouterは、その境界をBYOKドキュメントで明確にしています。OpenRouterクレジットを使用する場合、プロバイダーのレート制限はOpenRouterによって管理されます。プロバイダーキーを使用する場合、ユーザーはプロバイダーアカウントを通じてレート制限とコストを直接管理できます。OpenRouterはまた、OpenRouterエンドポイントの前後に試行されるプロバイダーキーを含む、キーの優先順位とフォールバックのセクションも文書化しています。これは、プラットフォームチームがプロバイダーアカウントの管理を必要としながらも、ホスト型のルーティングレイヤーを望む場合に役立ちます。

LiteLLMは、より多くの所有権をチームに移行します。そのドキュメントでは、LiteLLM Proxyを自己ホスト型のOpenAI互換ゲートウェイとして説明しています。これは、プロバイダーの認証情報、ルーティング設定、内部ポリシー、データベース、Redis、コールバック、および可観測性を制御したい場合に適切なアーキテクチャとなり得ます。トレードオフは運用面です。誰かがデプロイ、アップグレード、シークレット、ログ、スケーリング、およびインシデント対応を所有する必要があります。

Flatkeyは異なる姿勢を取ります。Flatkeyの公開ページでは、1つのAPIキー、個別のプロバイダーアカウントの削減、統一されたルーティング、リクエストログ、使用状況分析、クォータ制御、および請求の可視性が強調されています。これは、購入者がプラットフォームのロードマップにプロキシプロジェクトを追加する代わりに、ゲートウェイによってアカウントの乱立を減らしたい場合に適しています。

請求：クレジット、プロバイダーアカウント、単一請求書の比較

請求は、OpenRouterとLiteLLMの比較が財務上の決定となり得る領域です。ホスト型クレジット、BYOKプロバイダー請求、自己ホスト型プロキシのチャージバック、およびマネージドゲートウェイの請求書発行は、それぞれ異なるレビューの軌跡を生み出します。

OpenRouterの場合、実質的な分割はクレジット対BYOKです。OpenRouterのBYOKドキュメントには、プロバイダーキーを使用するとプロバイダーアカウントを通じてレート制限とコストを直接管理できる一方、OpenRouterクレジットではプロバイダーのレート制限はOpenRouterによって管理されると記載されています。モデルフォールバックのドキュメントには、リクエストは最終的に使用されたモデルに基づいて価格設定され、そのモデルはレスポンスボディで返されると記載されています。これは、請求レビューでは、リクエストされたモデル、提供されたモデル、および実際にリクエストを処理したルートを追跡する必要があることを意味します。

LiteLLMの場合、請求はチームが追跡をどのように設定するかに依存します。LiteLLMのドキュメントには、支出追跡、予算、仮想キー、チーム、ユーザー、およびコールバックが記載されています。これは内部チャージバックをサポートできますが、直接のプロバイダー請求書、プロキシログ、および独自の会計モデルを調整する必要性をなくすものではありません。

Flatkeyの場合、公開されている価格ページには、セルフサービスプランはプリペイドのトップアップ方式であり、残高はAPIリクエストがモデルを使用した場合にのみ消費されると記載されています。また、モデル、トークンタイプ、リクエストログによる使用量の計測、さらに使用状況分析、コスト管理、エンタープライズ向け請求書発行、調達サポート、およびプロバイダー横断の単一請求書についても説明されています。この記事の2026年7月1日の価格APIスナップショットでは、Flatkeyはsuccess: true、214のモデル行、30のユニークなベンダー、およびanthropic、gemini、image-generation、openaiを含むエンドポイントファミリーを返しました。これは日付の入った証拠のスナップショットとして扱い、すべての行や価格単位が変更されないことを約束するものではないと理解してください。

ルーティングとフォールバック：トリガーを定義する

フォールバックは、OpenRouterとLiteLLMの比較において、最もライブテストが必要となる部分です。フォールバックはリカバリーを向上させることができますが、提供されるモデル、プロバイダー、動作、価格単位、ツールサポート、データ処理の姿勢、またはレスポンスの形状を変更する可能性もあります。

OpenRouterのプロバイダールーティングに関するドキュメントには、プロバイダーのソートとフォールバックの動作が記述されており、これにはデフォルトの価格ベースのロードバランシング戦略や、プライマリルートが利用できない場合のバックアッププロバイダーが含まれます。そのモデルフォールバックに関するドキュメントによると、デフォルトでは、コンテキスト長の検証エラー、モデレーションフラグ、レート制限、ダウンタイムなど、あらゆるエラーがフォールバックをトリガーする可能性があります。また、フォールバックリストには制限があるため、無制限のリカバリーチェーンを想定してはならないとも記載されています。

LiteLLMのドキュメントには、LLM APIデプロイメントのためのロードバランシング、フォールバック、リトライをルーターが処理することが記述されています。そのドキュメントはまた、仮想キー、ユーザー、チーム、およびグローバルサーバー制限にわたるレート制限と予算チェックについても言及しています。本番環境では、これは運用予定のRedis、データベース、レート制限、プロバイダーキーのセットアップと同じものに対してフォールバックの動作をテストする必要があることを意味します。

Flatkeyの公開ページには、自動切り替えとロードバランシングを備えた複数のアップストリームアカウントにわたるルーティングが記述されています。本番環境での実証実行のためには、その製品の主張だけで止めないでください。選択したモデルとエンドポイントファミリーについて、試行されたルート、最終的なルート、ステータス、単位使用量、およびコストまたは残高への影響を示すリクエストログを要求してください。

ログ、クォータ、レート制限

有用なOpenRouterとLiteLLMの評価には、意図的なクォータ超過を含めるべきです。このテストがなければ、チームはプロバイダーのRPM/TPM、ゲートウェイのレート制限、アプリキーの予算、前払い残高、モデルの可用性を混同しがちです。

証明項目	重要である理由	ルーターに表示を求めるべき内容
リクエストされたモデルと提供されたモデル	フォールバックとプロバイダールーティングは、実際にリクエストを処理したルートを変更する可能性があります。	リクエストされたモデル、提供されたモデル、プロバイダー、エンドポイントファミリー、およびレスポンスの帰属。
認証情報ソース	クレジット、BYOK、プロバイダーアカウント、およびマネージドゲートウェイの残高は、異なる所有権パスを作成します。	どのキー、アカウント、ワークスペース、プロジェクト、または残高がリクエストを承認したか。
クォータソース	失敗した制限は、アプリ、チーム、ゲートウェイ、プロバイダー、残高、またはモデル固有のものである可能性があります。	エラーの種類、制限名、リセット動作、および失敗後にフォールバックが試行されたかどうか。
使用単位	テキスト、画像、音声、動画、キャッシュ、およびリクエスト単位は、異なる方法で計測される場合があります。	ステータスと同じレコード内の入力/出力トークンまたはモダリティ固有の単位。
請求の証拠	財務部門は、開発者がデバッグに使用するのと同じリクエストトレースを必要とします。	コスト、残高控除、クレジット使用量、プロバイダーアカウントへの請求、請求書のグループ化、またはエクスポート行。

OpenRouterの制限に関するドキュメントには、クレジットと使用状況を確認するための主要なエンドポイントが記述されており、そのBYOKドキュメントは外部のBYOK使用とアカウントの使用を区別しています。LiteLLMのドキュメントには、プロキシ、ユーザー、チーム、顧客、キー、モデル、タグ、エージェントにわたる予算、さらに生成されたキーに対するRPMおよびTPM制御が記述されています。Flatkeyの公開ページには、リクエストログ、クォータ制限、および使用状況分析が記述されています。適切なテストは、小さな制限を設定し、意図的にそれに達し、どのシステムがその失敗を説明するかを確認することです。

OpenRouter、LiteLLM、Flatkeyの移行チェックリスト

多くのチームは、OpenRouterとLiteLLMの移行をベースURLの変更に単純化してしまいます。それは最初のステップにすぎません。ルーターの移行は、本番トラフィックを移動する前に、動作、証拠、およびロールバックを証明する必要があります。

1つのワークフローを選択：1つのモデルルート、プロンプトタイプ、エンドポイントファミリー、および期待されるレスポンス形状を選択します。
所有権を文書化：プロバイダーアカウント、ゲートウェイキー、請求、サポート、およびインシデント対応の所有者を記録します。
リクエストフィールドをマッピング：リクエストされたモデル、提供されたモデル、プロバイダー、エンドポイント、ユーザーまたはアプリキー、およびフォールバック候補。
通常のリクエストを実行：アプリが使用している場合は、非ストリーミング、ストリーミング、およびツールまたは構造化出力の呼び出しを含めます。
失敗リクエストを実行：制御された方法で、クォータ超過、プロバイダーの障害、または無効なモデルルートをトリガーします。
ログを比較：ステータス、ルート、使用単位、フォールバックの試行、最終モデル、およびコストの証拠を確認します。
請求を確認：同じリクエストをクレジット、プロバイダーアカウント、前払い残高、請求書、または内部チャージバックまで追跡します。
ロールバックを記述：ルートの固定、フォールバックの無効化、ゲートウェイの切り替え、またはプロバイダーへの直接アクセスに戻る方法を定義します。
監視のしきい値を設定：どのレイテンシー、エラー、支出、またはクォータのシグナルがロールアウトを停止するかを決定します。

より運用上のコンテキストについては、この記事をOpenRouterの代替、LiteLLMの代替、およびエンタープライズAI APIゲートウェイチェックリストと比較してください。

OpenRouterを選択すべき場合

OpenRouterとLiteLLMの決定が、ホスト型ルーティング、プロバイダー/モデルオプションへの迅速なアクセス、プロバイダー選択制御、およびチームが受け入れ可能なクレジットまたはBYOKモデルに傾いている場合にOpenRouterを選択してください。特に、開発者がプロキシインフラストラクチャを運用せずにルーティング制御を望む場合に適しています。

OpenRouterを本番環境で承認する前に、ワークフローがOpenRouterクレジットまたはプロバイダーキーを使用するか、レート制限がどのように適用されるか、フォールバックがどのようにトリガーされるか、最終的に提供されたモデルがレスポンスにどのように表示されるか、そして財務部門が実際に使用されたモデル/プロバイダーをどのように照合するかを確認してください。

LiteLLMを選択する場合

OpenRouter vs LiteLLM の決定がインフラストラクチャの所有権に傾く場合は、LiteLLMを選択してください。LiteLLMは、OpenAI互換のプロキシ、プロバイダーの認証情報管理、設定可能なルーティング、仮想キー、予算、コールバック、ロギング、およびエンタープライズガバナンスオプションを求めるプラットフォームチームに最適です。

LiteLLMを承認する前に、デプロイメント、データベースとRedisの選択、プロバイダーのシークレットストレージ、アップグレードの頻度、可観測性、支出の照合、保持、およびオンコール対応を誰が担当するかを確認してください。より多くの制御権を持つことは、より多くの運用責任を負うことでもあります。

Flatkeyを候補に入れる場合

OpenRouter vs LiteLLM の選択が3つ目の問題、つまりチームがプロキシを運用したくなく、財務部門が散在するプロバイダーアカウントを望まないという問題を露呈した場合は、Flatkeyを候補に入れてください。Flatkeyの公開ページは、ワンキーゲートウェイのストーリーをサポートしています。つまり、接続されたモデル、モデルアクセス、ルーティング、請求、使用状況分析、運用管理、リクエストログ、クォータ制限、前払い残高、コスト管理、調達サポート、そしてプロバイダーを横断する1つの請求書に対して、1つのAPIキーで対応します。

Flatkeyは証明の代わりにはなりません。現在のFlatkeyの料金ページを使用してモデルの行とエンドポイントファミリーを確認し、次にキーを取得して上記の移行チェックリストを実行してください。決定は、ご自身のワークフローにおけるリクエストログ、クォータの動作、請求の証拠、およびロールバックの信頼性に基づいて行う必要があります。

決定記録テンプレート

OpenRouter vs LiteLLM の決定を承認する前、またはFlatkeyをワンキーゲートウェイのパスとして追加する前に、このテンプレートを使用してください。

項目	記録
ワークフローの所有者	チーム、アプリ、環境、およびビジネスオーナー。
選択されたパターン	ホスト型ルーター、自己ホスト型プロキシ、またはマネージドワンキーゲートウェイ。
認証情報の所有者	ルータークレジット、BYOKプロバイダーアカウント、自己ホスト型プロバイダーシークレット、またはFlatkeyキー。
請求パス	クレジット、プロバイダーからの直接請求書、前払い残高、単一請求書、または内部チャージバック。
ルーティングポリシー	プロバイダーの順序、許可されたプロバイダー、フォールバックモデルリスト、負荷分散ルール、または固定ルート。
クォータのソース	アプリキー、チーム予算、グローバルサーバー制限、プロバイダーのRPM/TPM、残高、またはモデル固有の制限。
必要な証拠	リクエストログ、最終的に提供されたモデル、使用単位、コスト/残高記録、フォールバックトレース、および請求エクスポート。
ロールバックルール	フォールバックを無効にする方法、プロバイダーを固定する方法、ゲートウェイを切り替える方法、またはプロバイダーへの直接アクセスに戻す方法。

よくある質問

OpenRouterとLiteLLMの主な違いは何ですか？

OpenRouter vs LiteLLM の主な違いは運用モデルです。OpenRouterは、プロバイダーとモデルのルーティング制御を備えたホスト型ルーターです。LiteLLMは、チームが自己ホストまたは詳細に設定できるOpenAI互換のプロキシ/ゲートウェイとして一般的に評価されています。

LiteLLMはオープンソースですか？

LiteLLMの公式エンタープライズドキュメントでは、LiteLLM OSSとエンタープライズ機能を区別しており、LiteLLM OSSはOpenAI互換のゲートウェイ、仮想キー、支出追跡、予算、フォールバック、リクエスト/レスポンスのロギングをカバーしていると記載されています。ライセンスや機能の前提に基づいて調達を決定する前に、現在のLiteLLMのドキュメントとリポジトリを確認してください。

OpenRouterはBYOKをサポートしていますか？

はい。OpenRouterのBYOKドキュメントには、独自のプロバイダーキーを使用する方法が記載されています。プロバイダーキーを使用すると、プロバイダーアカウントを通じてレート制限とコストを直接制御できますが、OpenRouterクレジットの場合は、プロバイダーのレート制限はOpenRouterによって管理されると記載されています。

なぜOpenRouterとLiteLLMの比較にFlatkeyを含めるのですか？

Flatkeyは、異なる購入者の質問に答えます。チームがプロバイダーアカウントの数を減らし、1つのキー、リクエストログ、使用状況分析、クォータ制御、前払い残高、およびプロバイダーを横断する請求書のレビューを望む場合、Flatkeyはホスト型のマーケットプレイスルーターや自己ホスト型のプロキシよりも実用的な証明パスとなる可能性があります。

選択する前にフォールバックをどのようにテストすべきですか？

制御された障害をトリガーし、トレースを検査します。トリガー、試行順序、最終的に提供されたモデル、プロバイダー、ステータス、使用単位、コストまたは残高への影響、そしてレスポンスの形式がまだアプリと一致するかどうかを確認してください。

ルーターを承認する前に財務部門は何をレビューすべきですか？

財務部門は、誰がアカウントを所有しているか、リクエストがどのように計測されるか、コストがどこに表示されるか、フォールバックによって請求されるモデルやプロバイダーが変更されるか、請求書やクレジットがどのようにグループ化されるか、そしてログがリクエストレベルの使用状況を請求記録と照合できるかどうかをレビューする必要があります。

キーの取得： まずFlatkeyの料金から始め、ワークフローの現在のモデル行を確認し、次にキーを取得して、本番展開前にログ、クォータ、請求、フォールバックの動作をチェックする小規模な証明を実行してください。