2026年LLM Proxyランキング：4製品比較

APIキーが各サービスに分散し、障害時の切り替えと利用料金の把握に時間がかかっていませんか。

最短の選び方は、自社運用の標準をLiteLLM、コーディングAgentとオープンモデルの検証をSwitchyard、短期間の多社モデル接続をOpenRouter、監視・ガバナンスまで含める場合をPortkeyと分けることです。

最終更新：2026年8月13日。 ルーティング、フォールバック、認証、予算管理、可観測性、データ保持に関する情報を、各製品の公式ドキュメントと公式リポジトリで確認しています。機能、ポリシー、ライセンスが変わった場合は評価を見直してください。

この記事を読むべきチーム

統一モデル入口を構築しているAIプラットフォームチーム向けです。複数のLLM接続コードを減らしたいアプリ開発者にも適しています。

自社運用、マネージドなモデルルーティング、混合構成のいずれを選ぶか迷っている企業アーキテクトは、製品名ではなく「どこにデータと認証情報を置くか」から判断してください。

まず部署方式を分けて比較する

LLM Proxyには、大きく分けて2種類あります。LiteLLMやSwitchyardのように自分の環境へ配置するプロキシと、OpenRouterやPortkeyのように外部サービスを経由する構成です。

この2種類を同じ基準で順位付けすると、運用負担とデータ管理の違いが隠れます。そこで本記事では、チームの部署方式ごとに順位を付けます。

LiteLLMの公式ドキュメントは、認証・認可を備えた集中型API GatewayとしてProxy Serverを案内しています。SwitchyardはPython製のLLMトラフィック用プロキシで、OpenAI Chat、Anthropic Messages、OpenAI Responsesの3形式を変換できます。(docs.litellm.ai)

第一段階：個人開発と短期導入は外部ルーターを優先する

個人開発者や小規模チームでは、最初からデータベース、キャッシュ、ロードバランサー、監視基盤を用意すると、LLM機能よりゲートウェイ運用に時間を使うことになります。

この段階ではOpenRouterが扱いやすい候補です。公式資料では、複数プロバイダー間のルーティング、価格・レイテンシー・スループットを基準にした選択、障害時のフォールバックを提供しています。公式のプロバイダー申請ページでは、70以上のプロバイダーにまたがるルーティングが説明されています。(openrouter.ai)

ただし、APIキーを1つにまとめただけで安全になるわけではありません。次の3点を先に確認してください。

• OpenRouter側に保存される情報と、実際の推論プロバイダー側の保持方針を分けて確認する。
• 料金上限、モデルの自動切り替え、フォールバックの発生条件を記録する。
• 開発用キーと本番用キーを分離し、アプリケーションへ直接埋め込まない。

OpenRouterとLiteLLMの違いは、単なる機能数ではなく運用場所です。 OpenRouterは外部のモデルルーティング基盤を使う方式です。LiteLLMは自分のネットワーク内にプロキシを置き、接続先のAPIキー、認証、予算、ログの扱いを自分で設計する方式です。

第二段階：コーディングAgentはSwitchyardの適合範囲を確認する

Claude CodeやCodexのようなコーディングAgentで、複数のモデルやローカル推論エンドポイントを試したい場合は、Switchyardを候補に入れます。

公式リポジトリでは、OpenAI互換エンドポイント、vLLM、NVIDIA NIM、Ollamaなどを対象に、Agentが使うAPI形式を変換できる構成が説明されています。switchyard launch claudeやswitchyard launch codexのような起動方法も用意されています。(github.com)

ここで注意したいのは、Switchyardを企業向けの完成済み管理ポータルと考えないことです。ルーティング、バックエンド接続、統計取得には強みがありますが、組織横断の権限管理、長期ログ保管、承認フロー、監査レポートまで必要なら追加設計が必要です。

Switchyardを選ぶ条件

• コーディングAgentの接続先をOpenAI互換APIへ寄せたい。
• ローカルモデルや自社推論サーバーを同じAgent操作で試したい。
• ルーティングプロファイルをコードや設定ファイルで管理したい。

Switchyardを外す条件

• 部門ごとの予算上限と権限を管理画面で運用したい。
• 監査担当者が利用履歴を検索し、定期的に報告書を作る必要がある。
• ルーティング変更を承認ワークフローに通したい。

第三段階：自社運用の標準はLiteLLMから設計する

自社運用のLLM Gatewayを選ぶなら、第一候補はLiteLLMです。理由は、複数のモデルプロバイダーを共通の入口へまとめ、認証、仮想キー、予算、ルーティング、負荷分散を段階的に組み立てやすいからです。公式ドキュメントでも、集中型API Gateway、認証・認可、Proxyエンドポイントが主要機能として案内されています。(docs.litellm.ai)

ただし、LiteLLMを1つのコンテナで起動しただけでは本番基盤になりません。最低限、次の構成を分けて考える必要があります。

1. プロキシ本体を非公開ネットワークへ配置します。
2. APIキーを環境変数や秘密管理サービスで保管します。
3. チーム、アプリ、環境ごとに仮想キーを分けます。
4. モデルごとの上限、レート制限、フォールバック条件を設定します。
5. メタデータ、トークン数、エラー、選択モデルを監視へ送ります。
6. データベース、キャッシュ、バックアップ、更新手順を決めます。
7. 片系障害時に別インスタンスへ切り替える構成を検証します。

LiteLLMを外部公開する場合は、プロキシ自体が全プロバイダーの認証情報を集約する点に注意してください。Cloud Security Allianceの調査資料でも、AI Gatewayは認証情報とリクエストデータが集中するため、公開範囲を制限し、更新と防御を管理する必要があると指摘されています。(labs.cloudsecurityalliance.org)

第四段階：企業治理はPortkeyの境界を確認する

Portkeyは、単なるAPI形式変換よりも、ルーティング、キャッシュ、リトライ、ロードバランシング、ログ、ガードレール、予算制御をまとめて扱いたいチーム向けです。公式Gateway資料では、フォールバック、条件付きルーティング、サーキットブレーカー、カナリアテスト、レート制限などが説明されています。(portkey.ai)

ガードレールは入力と出力の検査に対応し、拒否、ログ記録、別モデルへのフォールバック、再試行などの動作を設定できます。公式ドキュメントでは、20種類以上の決定論的ガードレールが案内されています。(portkey.ai)

ログ管理もPortkeyの強みです。ログには時刻、利用モデル、トークン、コスト、リトライ、フォールバック、ロードバランシングの状態を記録できます。プランによって保持期間が異なり、Developerは3日、Productionは30日、Enterpriseは無制限と説明されています。(portkey.ai)

ただし、ログは便利であるほど情報漏えいの経路になります。Portkeyにはリクエストとレスポンス本文を保存せず、トークン数、コスト、レイテンシーなどの高レベル統計だけを残すdebug:falseの運用があります。機密性が高い処理では、本文ログを標準設定にしないでください。(portkey.ai)

Portkeyは複数モデルの統合管理に適していますか。 監視、ガードレール、キャッシュ、ルーティング、予算管理を同じ運用面で扱いたい場合は適しています。一方、推論リクエストを完全に自社ネットワーク内へ閉じ込めたい場合は、Portkeyのセルフホスト可能なGateway部分と、マネージド機能の境界を個別に確認してください。

第五段階：データ経路と予算を比較して最終判断する

OpenRouterでは、プロバイダーの順番、フォールバックの許可、対応パラメーター、データ収集、Zero Data Retention、価格上限などをリクエストのprovider設定で指定できます。ZDRを有効にすると、保持方針が確認されたエンドポイントに限定できますが、外部プロバイダーの契約条件まで自動的に審査できるわけではありません。(openrouter.ai)

また、OpenRouterのZDR設定は「自社にとって安全なデータ経路が完成した」という意味ではありません。プロンプトに個人情報、ソースコード、顧客データを送る場合は、契約、保存場所、学習利用、サポート担当者のアクセス条件を別途確認してください。

受け手別の最終ランキングと淘汰条件

個人開発・短期検証

1位：OpenRouter
初期のインフラ運用を減らし、複数プロバイダーをすぐ試したい場合に適しています。外部ルーターを使えない機密データ処理なら淘汰します。

2位：Switchyard
ローカルモデルやコーディングAgentの接続検証に向いています。認証、課金、監査を一体管理したい場合は候補から外します。

自社運用プラットフォーム

1位：LiteLLM
統一API、認証、予算、負荷分散を自社基盤へ組み込みたいチーム向けです。保守担当と監視基盤を用意できない場合は採用しません。

2位：Switchyard
Agent中心の小規模構成では有力です。複数部門の利用統制が必要になった時点でLiteLLMなど別の管理層を検討します。

マネージドなモデルルーティング

1位：OpenRouter
多くのモデルとプロバイダーを短期間で比較したい場合に適しています。プロバイダー契約を自社で直接締結し、経路を固定する要件には合いません。

2位：Portkey
ルーティングに加えてログやガードレールを重視する場合に向いています。完全な外部サービス依存を避けたい場合は、導入範囲を限定します。

企業の監視・治理

1位：Portkey
入力・出力の検査、ログ、キャッシュ、リトライ、予算をまとめて設計したい企業向けです。ネットワーク閉域と完全自社運用が必須なら採用条件を満たしません。

2位：LiteLLM
自社ネットワーク内で統制したい場合の基盤候補です。ただし、監査画面、アラート、長期ログ保管は別サービスを組み合わせる前提で評価します。

今週やるべき選定手順

1. まず、リクエスト本文を外部マネージドサービスへ送れるかを法務と確認します。
2. 次に、OpenAI互換、Anthropic形式、Responses APIのどれを既存Agentが使うかを棚卸しします。
3. その後、モデル切り替え、プロバイダーフォールバック、予算上限を1つのテストシナリオにします。
4. 開発用キーでログ本文、メタデータ、コスト表示を確認します。
5. 障害を意図的に発生させ、ストリーミング中に別プロバイダーへ切り替えられるかを確認します。
6. 最後に、導入後の担当者、更新周期、秘密情報のローテーション、削除手順を文書化します。

結論を急ぐなら、自社運用の標準はLiteLLM、コーディングAgentの検証はSwitchyard、外部ルーティングの迅速な導入はOpenRouter、治理込みの企業運用はPortkeyです。全チームに共通する絶対順位ではありません。

現在の環境からMac構成へ切り替える判断

既存の一般的なVPSやクラウド環境だけでLLM Proxyを運用すると、Linux向けのAPI検証には便利ですが、Apple Silicon上の開発ツール、macOS専用Agent、ローカル推論クライアントとの接続確認が後回しになりやすい点が弱点です。さらに、共有環境では物理構成を固定しにくく、開発者の手元と本番に近いMac環境の差分も残ります。

そのため、LLM Gatewayの本番をすぐMacへ移すのではなく、自社運用のGatewayは既存環境に残し、macOS向けクライアントやAgentの検証だけMac環境へ分離する方法が現実的です。Apple環境を短期間だけ確保したい場合は、まずVPSSparkのサービス概要を確認し、必要なら米国東部のMac環境で接続経路、CLI、ログ、キー管理を検証してください。

長期的に大量のLLMリクエストを処理し、GPUや物理インターフェースを固定したい場合は、自社サーバーや専用クラウドの方が適しています。一方、短期の開発、macOS対応確認、Agentの接続検証が目的なら、必要な期間だけMacをレンタルする方が、実機購入と保守費用を抱えずに現在のVPS構成との差分を確認できます。