AI API ゲートウェイを選ぶという課題は、2年前とは同じではありません。2024 年当時、多くの開発者は OpenAI を直接呼び出すか、ローカルで LiteLLM を立ち上げていました。現在は、料金ダッシュボード、キーごとのクレジット上限、数十のプロバイダーにまたがるモデルカタログを備えたホスティング型の選択肢があります。このカテゴリは十分に拡大しており、誤った選択をすると、後で実際の統合作業をやり直すことになりかねません。
本記事では、開発者の議論に繰り返し登場する 4 つのゲートウェイ、CometAPI、Portkey、LiteLLM、Cloudflare AI Gateway を比較します。勝者を決めることが目的ではありません — それぞれが適する状況は異なるため — 実際に各ツールが何をしているのかを整理し、ユースケースに合ったツールを選べるようにすることが目的です。
モデル名に関する注意: 本記事で使用しているモデル識別子(
gpt-5.4、claude-opus-4-7など)は CometAPI プラットフォームの識別子です。OpenAI や Anthropic の公式名称ではなく、それぞれの命名規則は異なります。
これらのツールが実際に行うこと
機能比較に入る前に、AI API ゲートウェイが何をするのかを正確に押さえておきましょう。最低限の役割は、あなたのアプリケーションと 1 つ以上の AI プロバイダーの間に位置し、リクエストを転送しレスポンスを返すことです。そこから先は、ゲートウェイごとに大きく分岐します。
一部のゲートウェイ — 例えば Cloudflare AI Gateway — は主にパススルー層で、あなたの API キーや料金体系に触れることなく、ロギングやキャッシュを追加します。別のタイプとして CometAPI のようにリセラーとして機能するものがあります。あなたは CometAPI に支払い、CometAPI が基盤プロバイダーに支払い、その価格差がバリュープロポジションの一部になります。LiteLLM はさらに異なり、ホスト型サービスではなく、あなた自身が運用するソフトウェアです。
この違いを理解しておくことは、個別の機能を評価する前に重要です。
機能比較
以下の表は、各製品の公式ドキュメントまたは一般公開されているダッシュボードの 2026 年 5 月時点の情報に基づいています。ダッシュ(—)で示された機能は、執筆時点で公式情報により確認できなかった項目です。
| 機能 | CometAPI | Portkey | LiteLLM | Cloudflare AI Gateway |
|---|---|---|---|---|
| デプロイ形態 | ホスト型 (SaaS) | ホスト型 + セルフホスト | セルフホスト(オープンソース) | ホスト型(Cloudflare エッジ) |
| モデルカタログ | 複数プロバイダーで 500+ モデル | 統一 API で 1,600+ LLM | 構成次第 | OpenAI、Anthropic、Workers AI |
| 料金モデル | リセラー(CometAPI に支払い) | パススルー + プラットフォーム料金 | インフラ費用のみ | パススルー(フリーティアあり) |
| OpenAI 互換 API | Yes (api.cometapi.com/v1) | Yes (api.portkey.ai/v1) | Yes(ローカルまたはリモート) | Yes(ゲートウェイ URL 経由) |
| キーごとのクレジット上限 | Yes(ダッシュボード) | Yes | Yes(設定で) | — |
| グループ別価格比率 | Yes(デフォルト 0.8x、社内 0.1x) | — | — | — |
| リクエストログ | Yes(4 種類のログ) | Yes | Yes | Yes |
| 成功率モニタリング | Yes(30 日稼働状況ビュー) | Yes | Yes | Yes |
| フリーティア | Yes(新規アカウント) | Yes | オープンソース(インフラ費用) | Yes |
| セルフホストオプション | No(エンタープライズ: 専用サーバー) | Yes | Yes(中核ユースケース) | No |
出典: CometAPI ダッシュボード、Portkey ホームページ、LiteLLM GitHub、Cloudflare AI Gateway ドキュメント
各ゲートウェイへの接続
4 つすべてのゲートウェイは OpenAI 互換のエンドポイントを公開しており、同じクライアント構成がどれにも通用します — 変更が必要なのは base_url、認証情報、そして Portkey の場合はモデルの指定方法です。
Python
import osfrom openai import OpenAIdef require_env(name: str) -> str: """Raise a clear error if a required environment variable is missing.""" val = os.environ.get(name) if not val: raise ValueError(f"Missing required environment variable: {name}") return val# ── CometAPI ────────────────────────────────────────────────────────────────# Hosted reseller with 500+ models. Use CometAPI model identifiers (e.g. "gpt-5.4").cometapi_client = OpenAI( base_url="https://api.cometapi.com/v1", api_key=require_env("COMETAPI_KEY"),)# ── Portkey ─────────────────────────────────────────────────────────────────# Hosted gateway with observability and 1,600+ LLMs.# Route to a provider by prefixing the model name: "@openai/gpt-4o", "@anthropic/claude-3-5-sonnet", etc.# x-portkey-api-key is required; it authenticates requests to Portkey's gateway.portkey_client = OpenAI( base_url="https://api.portkey.ai/v1", api_key=require_env("PORTKEY_API_KEY"), default_headers={ "x-portkey-api-key": require_env("PORTKEY_API_KEY"), },)# ── LiteLLM ──────────────────────────────────────────────────────────────────# Self-hosted proxy. Provider credentials (OPENAI_API_KEY etc.) are set server-side.# By default the proxy does not validate the client API key — "anything" works.# If you have enabled virtual keys on your LiteLLM instance, pass a virtual key instead.litellm_client = OpenAI( base_url=os.environ.get("LITELLM_BASE_URL", "http://localhost:4000"), api_key=os.environ.get("LITELLM_API_KEY", "anything"),)# ── Cloudflare AI Gateway ───────────────────────────────────────────────────# URL-based pass-through. Keep your real provider API key — Cloudflare does not replace it.cf_account_id = require_env("CF_ACCOUNT_ID")cf_gateway_id = require_env("CF_GATEWAY_ID")cloudflare_client = OpenAI( base_url=( f"https://gateway.ai.cloudflare.com/v1" f"/{cf_account_id}/{cf_gateway_id}/openai" ), api_key=require_env("OPENAI_API_KEY"),)def ask(client: OpenAI, model: str, question: str) -> str: """ Minimal wrapper showing the common call pattern across all four gateways. Model format varies by gateway: CometAPI: "gpt-5.4", "claude-opus-4-7", etc. (CometAPI identifiers) Portkey: "@openai/gpt-4o", "@anthropic/claude-3-5-sonnet", etc. LiteLLM: whatever model names you configured in your proxy Cloudflare: standard OpenAI model names, e.g. "gpt-4o" This function does not handle finish_reason, tool_calls, or provider errors. For production error handling, see: How to Debug Failed AI API Generations. """ response = client.chat.completions.create( model=model, messages=[{"role": "user", "content": question}], ) return response.choices[0].message.content or ""
Node.js
import OpenAI from "openai";function requireEnv(name) { const val = process.env[name]; if (!val) throw new Error(`Missing required environment variable: ${name}`); return val;}// ── CometAPI ────────────────────────────────────────────────────────────────const cometClient = new OpenAI({ baseURL: "https://api.cometapi.com/v1", apiKey: requireEnv("COMETAPI_KEY"),});// ── Portkey ─────────────────────────────────────────────────────────────────// Route to a provider by prefixing the model: "@openai/gpt-4o", "@anthropic/claude-3-5-sonnet"const portkeyClient = new OpenAI({ baseURL: "https://api.portkey.ai/v1", apiKey: requireEnv("PORTKEY_API_KEY"), defaultHeaders: { "x-portkey-api-key": requireEnv("PORTKEY_API_KEY"), },});// ── LiteLLM ──────────────────────────────────────────────────────────────────// Self-hosted. Default mode accepts any API key value.// Set LITELLM_BASE_URL if your server runs on a different host or port.const litellmClient = new OpenAI({ baseURL: process.env.LITELLM_BASE_URL ?? "http://localhost:4000", apiKey: process.env.LITELLM_API_KEY ?? "anything",});// ── Cloudflare AI Gateway ───────────────────────────────────────────────────const cfClient = new OpenAI({ baseURL: `https://gateway.ai.cloudflare.com/v1/${requireEnv("CF_ACCOUNT_ID")}/${requireEnv("CF_GATEWAY_ID")}/openai`, apiKey: requireEnv("OPENAI_API_KEY"),});/** * Minimal wrapper showing the common call pattern. * Model format varies by gateway — see Python example above for details. * Does not handle finish_reason or error recovery; add those for production use. */async function ask(client, model, question) { const response = await client.chat.completions.create({ model, messages: [{ role: "user", content: question }], }); return response.choices[0].message.content ?? "";}
4 つとも接続パターンは同じです。差が出るのは別の部分、すなわち何が観測できるか、何を制御できるか、そして問題が発生したときに何が起きるかです。
各ツールの得意分野
CometAPI
CometAPI の主な提供価値は、テキストモデルに加えて画像・動画生成モデルも含む 500 以上のモデルエンドポイントを備えたホスト型カタログです。料金はグループベースの比率システムで運用され、デフォルトグループでは CometAPI の基本料金に 0.8x の乗数が適用されます。社内利用(0.1x)と有料顧客向けで異なる比率グループを設定できるため、アカウントを分けなくても段階的な料金のプロダクトを実用的に構築できます。
ダッシュボードには 4 種類のログ(標準 API 呼び出し、画像生成、動画生成、Midjourney)、30 日の稼働状況ビュー、キーごとのクレジット上限が用意されています。クレジット上限により、クライアントや外部委託先に API キーを配布する際、支出に上限を設けられるため、共有アカウントへのアクセスを配布する場合の実際的な課題に対応できます。
提供していないものとして、セルフホスト(エンタープライズでは専用サーバーをリクエスト可能だが、一般的なセルフホストではない)、ゲートウェイレベルのレート制限、SSO が挙げられます。
最適な用途: 1 つの API キーと 1 つの課金関係で多数のモデル — 画像・動画を含む — にルーティングしたいインディー開発者や小規模チームで、キーごとの予算管理が必要なケース。
Portkey
Portkey は観測性を中心に設計されたホスト型ゲートウェイです。統一 API を通じて 1,600 以上の LLM にアクセスでき、モデル名の前にプロバイダーを付ける(@openai/gpt-4o、@anthropic/claude-3-5-sonnet)ことでルーティングします。これにより、プロバイダーごとに別々のクライアント設定を用意する必要がなく、1 つの Portkey クライアントで全てを扱え、モデル文字列を入れ替えるだけで切り替えられます。
ルーティング以外にも、Portkey はリクエストトレーシング、プロンプトのバージョン管理、コードではなくダッシュボードで設定するフォールバックルーティングを提供します。セルフホストオプションにより、コンプライアンス要件がある場合は自社インフラ上で Portkey を運用できます。
Portkey のオープンソースゲートウェイの GitHub リポジトリは積極的にメンテナンスされています — 記載のスター数に依存せず、現在のスター数は直接確認してください。数値は頻繁に変わります。
最適な用途: 監査証跡が必要なチーム、単一のクライアント設定で複数プロバイダーへルーティングしたい場合、または開発者間での API キー露出を管理したい場合。
LiteLLM
LiteLLM はホスト型サービスではなく、Python パッケージ兼プロキシサーバーです。あなた自身で運用します。これは重要な違いで、第三者があなたのリクエストを扱ったり API キーを保持したりしません。プロバイダー資格情報(OpenAI キーや Anthropic キーなど)はサーバー側の環境変数として設定し、クライアントはローカルプロキシを指すだけです。
デフォルトでは、LiteLLM はクライアントが送る API キーを検証しません — どんな値でも通ります。仮想キー管理を有効にすると、クライアントは LiteLLM が自身のデータベースで検証する仮想キーを渡します。いずれの場合も、プロキシは OpenAI 形式のリクエストを上流プロバイダーが期待する形式に変換するため、新しいプロバイダーを追加してもアプリケーションコードは変える必要がありません。
その代わりに、運用上のオーバーヘッドがあります。サーバーの運用、スケーリング、更新はあなたの責任です。
最適な用途: DevOps キャパシティのあるチーム、第三者の API プロキシを禁じるコンプライアンス制約のある組織、または SaaS ベンダーにリクエスト内容を預けずにプロバイダー横断ルーティングを実現したい場合。
Cloudflare AI Gateway
Cloudflare AI Gateway は他の 3 つとは構造的に異なります。API キーを変更したり、モデルアクセスのために Cloudflare に支払うことはありません。その代わり、プロバイダーのベース URL を Cloudflare 管理の URL に置き換え、エッジでのロギング、キャッシュ、レート制限を追加します。
Cloudflare はあなたのアプリケーションとプロバイダーの間に位置するため、同一のリクエストをキャッシュできます — 同じプロンプトを繰り返し送るアプリケーションでは有用です。フリーティアはインディー開発者の大半の用途をカバーします。制約はスコープにあります。Cloudflare はプロバイダー横断でモデルを集約しません。利用する各プロバイダーごとに別々のアカウントとキーが必要です。
最適な用途: すでに Cloudflare のインフラを利用している開発者、または既存のプロバイダーアカウントの上にキャッシュとロギングを載せたいが、新しい課金関係を導入したり API キーを変えたりしたくない場合。
シナリオ別のマッチング
| シナリオ | 推奨ツール | 理由 |
|---|---|---|
| インディーアプリ、1 つの API キーで 10+ モデルを試したい | CometAPI | 幅広いカタログ、簡単なセットアップ、キーごとのクレジット上限 |
| 同一統合で画像 + 動画生成も必要 | CometAPI | テキスト・画像・動画モデルの統一エンドポイント |
| 5 人チーム、誰がどのモデルを使っているかを追跡したい | Portkey | リクエストトレーシング、チーム管理 |
| 1 つのクライアント設定で 1,600+ LLM にルーティング | Portkey | @provider/model によるルーティング、プロバイダーごとの設定不要 |
| コード変更なしでプロバイダー間フォールバックを実現したい | Portkey | ダッシュボードで宣言的にフォールバック設定 |
| データレジデンシー要件があるエンタープライズ | LiteLLM(セルフホスト) | 第三者がトラフィックを扱わない |
| 予算ゼロで、セルフマネジメントに抵抗がない | LiteLLM | オープンソース、プラットフォーム費用なし |
| すでに OpenAI を直接利用中で、キャッシュを入れたい | Cloudflare AI Gateway | URL の置き換えのみ、新たな課金関係なし |
| 複数チーム向けの RBAC が必要 | Portkey または LiteLLM | いずれもチーム/ロール管理あり。CometAPI と Cloudflare は非対応 |
この 4 つでカバーしない領域
ここで比較したのは、インディー開発者の議論に最も頻繁に登場するゲートウェイです。市場には他にも知っておくべき選択肢があります。Helicone はプロキシ化せずに観測性に特化し、OpenRouter はオープンウェイトや研究用途のモデルへのルーティングを専門とし、AWS Bedrock はエンタープライズワークロード向けの Amazon のマネージド AI サービスです。要件が上記 4 つに当てはまらない場合は、次にこれらを検討するとよいでしょう。
切り替え
現在プロバイダーを直接呼び出しており、ゲートウェイ導入を検討している場合、コード変更はわずかです。CometAPI では環境変数を 1 つ追加し、base_url を変更します。Portkey ではヘッダーを 1 つ追加し、モデルの指定方法を変更します(gpt-4o の代わりに @openai/gpt-4o)。Cloudflare では、プロバイダー API キーを触らずに URL を変更します。LiteLLM では、まずローカルサーバーを起動し、クライアントをそこに向けます。
より重要なのは「どう切り替えるか」ではなく「切り替える必要があるか」です。単一プロバイダーのみを呼び出し、コストの可視性の問題がなく、モデル横断ルーティングも不要であれば、ゲートウェイは複雑さを増すだけで利点はありません。複数プロバイダーを利用している、外部委託先にキーを配布している、予期せぬ請求が繰り返し発生しているといった状況なら、統合のオーバーヘッドに見合う価値があります。
FAQ
これらのゲートウェイは併用できますか?
はい。機密性の高いワークロードにはセルフホストの LiteLLM を使い、その他は CometAPI を使うチームもあります。Cloudflare AI Gateway は、CometAPI のリクエストの前段に置いて Cloudflare のキャッシュ層を重ねることもできます — ただしネットワークホップが 1 つ増えます。
これらのゲートウェイはプロンプトを保存しますか?
ツールと設定によります。Portkey と CometAPI はデフォルトでリクエストをログに記録し、保持期間の設定があります。LiteLLM はあなたが設定したものだけを、自社インフラ上に保存します。Cloudflare のロギング動作は AI Gateway のドキュメントに記載されています。機密データを送信する前に、あらゆるホスト型サービスのプライバシー規約を確認してください。
ゲートウェイがダウンしたらどうなりますか?
ホスト型ゲートウェイ(CometAPI、Portkey、Cloudflare)の場合、ゲートウェイのダウンは、その経路で AI プロバイダーに到達できないことを意味します。ローカルで稼働する LiteLLM も、自身のサーバーと同じ可用性特性を持ちます。本番利用でいずれかのホスト型ゲートウェイにコミットする前に、SLA と、ゲートウェイ自体が利用できない場合に直接プロバイダーへフォールバックできるかを確認してください。
コミット前に無料で評価する方法はありますか?
はい。CometAPI と Portkey にはフリーティアがあります。LiteLLM はオープンソースで、費用は運用するインフラのみです。Cloudflare AI Gateway も寛容な範囲で無料です。意思決定前に、同じテストプロンプトで 4 つすべてを試せます。
各ゲートウェイで正しいモデル名をどう選べばよいですか?
ゲートウェイごとに規則があります。CometAPI は独自の識別子(gpt-5.4、claude-opus-4-7)を使います。Portkey は @provider/model-name 形式(@openai/gpt-4o、@anthropic/claude-3-5-sonnet)を使います。LiteLLM はプロキシ設定であなたが定義したモデル名を使います。Cloudflare は標準のプロバイダーモデル名をそのまま通します。コードを書く前に、それぞれのゲートウェイのドキュメントで最新のモデルリストを確認してください。
ゲートウェイを切り替えると既存のレート制限に影響しますか?
はい。OpenAI への直接呼び出しから、プロバイダーとの関係をゲートウェイが管理するタイプ(CometAPI など)に移行すると、実効レート制限はあなたの個人アカウントではなく、ゲートウェイの OpenAI アカウントにより決まります。運用トラフィックを移行する前に、ゲートウェイでのレート制限の挙動を確認してください。
