AIゲートウェイ比較2026：3製品の選び方

最終判断

Switchyardの公式リポジトリは、現時点で「pre-alpha」「本番利用向けではない」と明記しています。したがって、2026年8月14日時点のAIゲートウェイ比較 2026では、Claude Codeなどのコーディングエージェントで自社ルーティングを試すならSwitchyard、幅広いモデル接続と成熟したプロキシ機能を重視するならLiteLLM、管理画面・可観測性・統制ワークフローを優先するならPortkey、という順で評価するのが安全です。(Switchyard公式リポジトリ)

この比較は、複数モデルを統一APIで呼び出したいAIアプリ開発チーム、認証情報・回退・利用記録を管理するプラットフォーム担当者、Claude Codeなどにモデルルーティングを設定したい開発チーム向けです。単一モデルを個人の開発環境から呼ぶだけであれば、ゲートウェイを導入する前に運用コストを確認してください。

最終更新：2026年8月14日。機能、開発状態、対応方式は、各製品の公式リポジトリと公式ドキュメントを照合しています。

比較軸の整理

AIゲートウェイは、単にAPIの接続先を切り替える中継サーバーではありません。実際の選定では、次の制限が同時に発生します。

• クライアントごとに、OpenAI互換API、Anthropic Messages、独自SDKなどの呼び出し形式が異なります。
• ツール呼び出し、ストリーミング、構造化出力、提供元固有の拡張フィールドは、単純なチャット応答より互換性の確認が難しくなります。
• 障害時の再試行やモデル回退は、認証エラー、レート制限、タイムアウト、内容品質の低下を同じ扱いにできません。
• ログに入力・出力を保存すると、個人情報やソースコードが運用基盤に残るため、マスキングと保存期間が必要です。
• オープンソース版、自社運用版、クラウド版、企業向け機能は別物であり、同じ製品名だけで機能を比較すると判断を誤ります。

まずは、次のように製品の中心用途を切り分けます。

製品	主な強み	向いている初期用途	注意点
Switchyard	Rust製プロキシ、API変換、ステージ型ルーティング	Claude Codeやコーディングエージェントの検証	pre-alphaで、本番運用の前提にはしにくい
LiteLLM	多数のモデルを統一形式で接続、プロキシ、認証、予算管理	複数プロバイダーをまとめるAIアプリ基盤	機能範囲が広く、設定と更新管理が必要
Portkey	ルーティング、ログ、ガードレール、管理ワークフロー	管理画面と可観測性を重視するチーム	クラウド、オープンソース、企業向けの境界確認が必要

LiteLLMは公式ドキュメントで、統一形式による多数のLLM接続、リトライとフォールバック、プロジェクト単位の予算管理を案内しています。Portkeyは公式ゲートウェイ資料で、フォールバック、条件付きルーティング、ロードバランシング、レート制限、予算上限などを説明しています。(LiteLLM公式ドキュメント) (Portkey公式ゲートウェイドキュメント)

接続方式とモデル対応

Switchyardは、OpenAI Chat、OpenAI Responses、Anthropic Messagesの形式を変換し、クライアント側のAPI形式を保ったまま、vLLM、NVIDIA NIM、Ollama、OpenAI互換エンドポイントなどへ接続する設計です。Claude Codeを既存の呼び出し形式のまま別のバックエンドへ向けたい場合、接続経路が明確なのが利点です。

一方、LiteLLMはPython SDKとProxy Serverの両方を用意し、公式ドキュメントではOpenAI、Anthropic、Azure、Vertex AI、Ollamaなど複数の接続先を例示しています。モデル数の多さだけで決めず、対象モデルがストリーミング、ツール呼び出し、構造化出力をどこまで維持できるかを、実際のクライアントで確認する必要があります。(LiteLLMのモデル接続仕様)

Portkeyも統一API、SDK、複数モデル接続を提供し、公式ゲートウェイ資料ではチャット、埋め込み、画像、音声、リアルタイム通信などを扱う構成が示されています。ただし、特定の提供元に固有のパラメーターや応答形式が必要な場合は、共通APIに変換した後も拡張フィールドが残るかを確認してください。

確認項目	Switchyard	LiteLLM	Portkey
OpenAI系API	対応	対応	対応
Anthropic系API	変換対象	接続対象	接続対象
ストリーミング	公式の変換・型定義で確認	公式ドキュメントに専用項目あり	API・SDK単位で確認
ツール呼び出し	クライアントとバックエンドの組み合わせで検証	プロバイダー別に検証	サンプルと対象モデルで検証
ローカル推論	vLLM、Ollamaなどを想定	Ollamaなどを接続可能	自社運用構成や接続方式を確認
SDKの位置付け	CLI、サーバー、Rustライブラリ	Python SDKとProxy	REST、SDK、ゲートウェイ設定

この表で「対応」となっていても、基本的なテキスト応答が通るという意味に限定されます。特にClaude Codeでは、長いコンテキスト、ツール結果、ストリーミング、エラー形式を一連の操作で確認してください。

ルーティングと回退の設計

SwitchyardとLiteLLMはClaude Codeでどう使い分けるか

Claude Codeのようなコーディングエージェントでは、毎回同じモデルを呼ぶより、作業段階やツール結果に応じて処理先を切り替えたい場面があります。Switchyardは、LLM分類、ステージルーター、エスカレーション、ランダム分割などのルーティング方式を公式に示しており、特に会話中のツール結果やエラーなどを利用するステージ型ルーティングが特徴です。(Switchyardのルーティング設計)

LiteLLMは、複数デプロイメント間の再試行、フォールバック、ロードバランシングをプロキシまたはSDKから設定できます。安定したモデル名をアプリ側に公開し、背後の提供元やデプロイメントを差し替える構成では、LiteLLMのほうが一般的な運用に合わせやすいでしょう。(LiteLLMのフォールバックとロードバランシング)

Portkeyは、フォールバック、条件付きルーティング、ロードバランシング、サーキットブレーカー、タイムアウトをゲートウェイ設定として組み合わせられます。利用者区分、環境、メタデータなどを条件にした振り分けを管理したい場合は、設定中心で組み立てやすい構成です。(Portkeyのルーティング機能)

ただし、「高性能モデルが失敗したら安価なモデルへ回退する」だけでは不十分です。認証失敗やレート制限は回退候補に切り替えやすい一方、応答品質の低下やツール呼び出しの不整合は、HTTPエラーだけでは検出できません。実運用前に、正常応答、タイムアウト、429系エラー、空応答、無効なツール引数を個別に注入し、ルーティングログと最終結果を確認してください。

認証・予算・ログ管理

LiteLLM Proxyは、認証フック、ログフック、コスト追跡、レート制限、仮想キー、プロジェクト別の利用管理を備える構成を公式に説明しています。チーム別にモデルへのアクセス範囲や予算を分けたい場合、オープンソースのプロキシを基盤にして段階的に管理機能を追加できます。(LiteLLM Proxyの認証と利用管理)

Portkeyは、利用量、コスト、ルーティング、ガードレール、ログを一体化した運用を重視しています。ハイブリッド構成では、データプレーンを自社のクラウド環境に置き、管理や分析を担うコントロールプレーンと分離する方式も公式資料に記載されています。機密データを外部へ送れない場合は、クラウド版の名称だけでなく、ログ保存先と管理メタデータの範囲まで確認してください。(Portkey公式サイト)

Switchyardは、リクエスト数、エラー、遅延、トークン、ルーティングのオーバーヘッドをPrometheusメトリクスで扱う設計です。ただし、公式リポジトリ自身が実験段階と説明しているため、チーム権限、予算上限、監査ログをSwitchyardだけに任せる判断は避けるべきです。

自社運用の負担

自社運用AIゲートウェイを選ぶ場合、比較すべきなのはインストールの簡単さだけではありません。次の項目を確認してください。

• [ ] APIキーを環境変数、シークレット管理基盤、仮想キーのどこで保持するか決めたか
• [ ] モデルごとのタイムアウト、再試行回数、回退条件を分けたか
• [ ] 入出力ログのマスキング、保存期間、アクセス権を定義したか
• [ ] 設定ファイルをバージョン管理し、前バージョンへ戻せるか
• [ ] ストリーミング、ツール呼び出し、構造化出力を本番相当のクライアントで確認したか
• [ ] 429系エラー、認証エラー、接続断、遅い応答を個別に再現したか
• [ ] 開発用と本番用でモデルキーとログ保存先を分離したか

SwitchyardはRustとCargoを使うサーバー経路、CLI経路、ライブラリ経路を持ちます。LiteLLMはPython SDKまたはProxy Serverを導入する構成です。Portkeyのオープンソースゲートウェイはコンテナ、Node.js、Kubernetesなど複数の展開方式を示していますが、管理画面や企業向け統制まで必要なら、オープンソース版とマネージド機能を分けて見積もる必要があります。

チーム別の選択

個人開発者や少人数のコーディングエージェントチームは、まずSwitchyardを検証候補にできます。ただし、pre-alphaであるため、本番トラフィックを移すのではなく、Claude Codeからローカル推論や別モデルへ接続し、段階ルーティングの挙動を確認する用途に限定するのが妥当です。

急速に成長するAIアプリでは、LiteLLMが第一候補になります。モデル提供元を増やしながら、統一API、仮想キー、利用量、フォールバックをまとめたい場合に向いています。ただし、アップグレード前に設定互換性とエラー形式を確認し、ゲートウェイ自体が単一障害点にならない構成を取ってください。

企業のプラットフォームチームは、Portkeyを評価対象に入れる価値があります。管理画面、ログ、ガードレール、条件付きルーティング、ハイブリッド配置を一つの運用モデルで扱えるためです。ただし、保存データの所在、企業機能の契約範囲、クラウド依存の有無は、導入前に個別確認が必要です。

自社で実施する5段階の受け入れ手順

1. 実際に使うClaude Code、社内AIアプリ、SDKを固定します。
2. OpenAI互換、Anthropic形式、ストリーミング、ツール呼び出し、構造化出力のサンプルを用意します。
3. 同じモデルと同じ入力を3製品へ送り、応答形式、遅延、トークン記録、ルーティング理由を比較します。
4. タイムアウト、レート制限、認証失敗、空応答を注入し、回退先と再試行の挙動を確認します。
5. ログのマスキング、権限、予算上限、設定のロールバックを確認してから、少量の本番トラフィックで段階導入します。

自社の開発環境を短期間だけ分離したい場合は、日本リージョンのMac環境でゲートウェイとコーディングエージェントを検証し、チーム共有が必要なら米国西部のMac環境も比較候補になります。長期運用の前に、環境の再現性、接続元IP、シークレットの受け渡し方法を確認してください。

現在の環境からMac環境へ移す判断

既存のWindowsやLinux環境で自社ゲートウェイを動かす方法は、すでにCI/CDやコンテナ基盤が整っているチームには合理的です。しかし、開発端末ごとに依存関係が異なる、Claude Codeの接続確認を複数人で揃えにくい、物理端末の貸し出しや初期設定に時間がかかる、といった欠点も残ります。

短期の検証、顧客向けデモ、障害再現、チーム内の同一環境づくりが目的なら、Macを購入して固定資産化するより、nuvcloudのMac環境をレンタルして必要な期間だけ使うほうが判断しやすい場合があります。反対に、長期の常時稼働、物理USB機器、特定のGPU構成、社内ネットワークへの専用接続が必要なら、自社設備や既存クラウドのほうが適しています。

AIゲートウェイの選定では、製品名だけで決めず、実際のクライアント、実際のモデル、実際の障害を同じ環境で通すことが重要です。まずは分離されたMac環境で受け入れ試験を行い、結果が確認できた段階で本番基盤へ移行すると、Switchyard、LiteLLM、Portkeyの違いを機能表ではなく運用結果として判断できます。