powered by TechFeed
表示モード
Deep Dive

OpenRouterとVercel AI Gatewayは競合ではなく補完関係 — コスト・ルーティング・モデル数を実測比較して見えた使い分けの基準

8月3日、Zack Proserが「OpenRouter vs Vercel AI Gateway: Cost, Routing, and Model…」と題した記事を公開した。著者自身のコーディングエージェントではトークンの96.6%がキャッシュリードだったという実測値が示すように、LLMゲートウェイの選択はレート表の比較だけでは済まない。さらに、キャッシュヒット率を高めるには同一プロバイダーへの固定が必要な一方、冗長性のためにはフェイルオーバーで別プロバイダーへ切り替えられなければならない——この根本的なジレンマに、2つのゲートウェイは異なるアプローチで応えている。

8月3日、Zack Proserが「OpenRouter vs Vercel AI Gateway: Cost, Routing, and Model…」と題した記事を公開した。著者自身のコーディングエージェントではトークンの96.6%がキャッシュリードだったという実測値が示すように、LLMゲートウェイの選択はレート表の比較だけでは済まない。さらに、キャッシュヒット率を高めるには同一プロバイダーへの固定が必要な一方、冗長性のためにはフェイルオーバーで別プロバイダーへ切り替えられなければならない——この根本的なジレンマに、2つのゲートウェイは異なるアプローチで応えている。


結論から:2つは競合でなく補完関係

著者はOpenRouterとVercel AI Gatewayを両方本番環境で使用している。AWSで稼働するHermesエージェントはOpenRouter経由でモデルを呼び出し、VercelにデプロイしたエージェントフリートはVercel AI Gatewayを使う。

この記事の軸となる問いは、「Vercelがマークアップゼロを謳うなら、なぜOpenRouterを使い続けるのか?」だ。答えは「両者は異なるレイヤーを最適化している」という点に尽きる。OpenRouterはプロバイダー間の選択自由度とルーティング制御に強みを持ち、Vercel AI GatewayはVercelプラットフォーム上での統合コストの低さと可観測性に強みを持つ。どちらを選ぶかではなく、どのワークロードにどちらを当てるかが本質的な問いになる。


コスト:手数料だけで判断すると見誤る

Vercel AI Gatewayはトークン課金にマークアップを乗せない。BYOK(Bring Your Own Key:自分のAPIキーを持ち込む方式)でも同様で、チームアカウントには毎月$5のクレジットが付与される。

一方、OpenRouterはクレジット購入時に5.5%の手数料を徴収し、カード決済には最低$0.80が適用される。$5のチャージでは手数料$0.80が適用されるため実質16%相当になるケースもある($0.80 ÷ $5 = 16%。チャージ額が大きくなるほど実効手数料は5.5%へ近づく)。

しかし、同じ手数料比較でも話は単純ではない。オープンウェイトモデルはホスト側が価格を設定するため、利用可能なプロバイダーによってコストが大きく変わる。

記事では2026年8月3日時点のスナップショットとして具体的な数字を比較している:

  • openai/gpt-oss-120b(OpenAIがオープンウェイトとして公開した1200億パラメーター規模のモデル)のInputトークン:OpenRouterのCoreWeaveルートが**$0.03/百万トークン、Vercelの最安値(Baseten)が$0.10/百万トークン**
  • deepseek/deepseek-v4-flash-0731(DeepSeekが公開した高速・低コスト志向のオープンウェイトモデル)では両方ともDeepInfraが$0.09inと$0.18outで同条件

著者は「自分のコーディングエージェントのトークン内訳は96.6%がキャッシュリードだった」と明かしており、キャッシュリードの単価がインボイスを支配するケースでは、ルーティング選択の前にキャッシュ価格の比較が重要になる。

コストの実践的な比較手順は次の通り:

  1. 対象モデルで利用可能なプロバイダーを両者で列挙する
  2. Input・Output・キャッシュライト・キャッシュリードそれぞれを比較する
  3. OpenRouterのクレジット購入手数料を加算する
  4. 自分のトークン構成比でレートカードを計算する

モデル数:カタログ総数より「使えるルートの数」が重要

2026年8月3日時点のAPIレスポンスを実測した結果:

  • Vercel:313モデル(言語208、画像32、動画30、埋め込み24など)
  • OpenRouter:337エントリ、58クリエイタープレフィックス(公式ページでは400+と表記)

言語モデルの幅ではOpenRouterが優勢で、実験的リリースやオープンウェイトの派生モデル、無料エンドポイント、~anthropic/claude-sonnet-latestのようなローリングエイリアス(常に最新バージョンに自動解決されるエイリアス。翌週には別モデルIDに切り替わる可能性がある)が多い。著者は本番ではモデルIDを固定し、ラボではエイリアスを使うという方針を採っている。

Vercelのカタログは整理されており、コンテキストウィンドウ・対応パラメーター・キャッシュ価格・レイテンシ・稼働率まで一貫した構造で確認できる点を著者は高く評価している。


プロバイダー冗長性:オープンウェイトでOpenRouterが圧勝

プロプライエタリなフロンティアモデル(Claude、GPT-4oなど)はクリエイターが許可した経路しか使えないため、両ゲートウェイの差は小さい。しかしオープンウェイトモデルで差が開く

OpenRouterは独立した推論プロバイダーへのルートが多く、1つのプロバイダーがダウンしたり、レート制限に引っかかったりしたときの代替経路を多く持つ。さらに量子化設定(quantizations:モデルの重みを低ビット精度で表現することで推論速度とコストを下げる手法。精度とのトレードオフがある)・パラメーターサポート要件・価格上限・プロバイダーの許可リスト/拒否リストを細かく制御できる。「同じモデルIDを持つすべてのエンドポイントが等価ではない」というケースに対応できる設計だ。

Vercelもorderonly・タイムアウト・コスト/TTFT(Time To First Token:最初のトークンが返るまでの時間。応答の体感速度を左右する指標)/スループットによるソートなど主要な制御はカバーしており、障害があったプロバイダーを自動降格させる仕組みも持つ。ただしルーティングポリシーのデフォルトが異なる:Vercelは直近の稼働率とレイテンシを優先し、OpenRouterはコストにより大きな重みを置く。


ルーティング設計:セマンティックかデターミニスティックか

OpenRouterには「プロンプトの内容からモデルを選ぶ」ルーター(openrouter/auto-beta)がある。タスクを分類し、タスクタイプ別の直近利用実績や品質・コストのトレードオフ設定をもとにフォールバックリストを自動構築する。

Vercelのルーティングは決定論的で、指定したモデル→フォールバックモデルという順序で動く。ルーティングルール機能は現在ベータ段階で、モデル名を対象に動作しプロンプトの意味は参照しない。

著者の判断は明快だ。評価済みの本番パスには決定論的ルーティングが望ましく、モデルラボや一発勝負のトラフィック、コストを品質より優先する場合はOpenRouterの自動ルーティングが有効だとしている。


開発者体験:どこで動かすかで決まる

Vercelアプリ内での統合はシンプルだ:

import { generateText } from 'ai'
const result = await generateText({
  model: 'anthropic/claude-sonnet-5',
  prompt: 'Review this pull request.',
})

creator/model形式の文字列だけでAI GatewayがAI SDKのデフォルトプロバイダーとして機能し、OIDC認証(OpenID Connect:短期間有効なトークンを使ってサービス間の認証を行う仕組み。長期シークレットをコードや環境変数に埋め込まずに済む)により長期シークレットの管理が不要になる。

OpenRouterはVercel外での利用を想定すると強みが出る:

import { createOpenRouter } from '@openrouter/ai-sdk-provider'
import { generateText } from 'ai'
const openrouter = createOpenRouter({
  apiKey: process.env.OPENROUTER_API_KEY,
})
const result = await generateText({
  model: openrouter('anthropic/claude-sonnet-5'),
  prompt: 'Review this pull request.',
})

既存のOpenAI SDK使用コードはベースURLとAPIキーを変えるだけで動く場合が多く、AWS EC2上のエージェントなどVercel外の環境への依存を持ち込まずに使える。


キャッシュ親和性:OpenRouterに一歩分の優位

両製品ともプロンプトキャッシュの正規化と読み書きの記録に対応している。ただしOpenRouterにはプロバイダースティッキールーティングという機能がある。キャッシュヒット後、同じプロバイダーエンドポイントに会話を固定し、session_idで事前に親和性を確立できる。プロバイダーが落ちた場合のみルーティングが開放される。

Vercelには現時点でこれに相当する機能の文書が見当たらないため、著者はorderonlyでプロバイダーを固定し、そのルートが失敗したときだけフォールバックを許可するという手動対応を採っている。

これは冗長エージェントルーティングの本質的なジレンマだ。フェイルオーバーは自由を求め、プロンプトキャッシュは同一プロバイダーへの固定を求める。著者のトークン内訳で96.6%を占めるキャッシュリードを最大限に活かすには、この矛盾をどう解決するかが核心になる。OpenRouterはこれをセッションレベルのポリシーとして明示的に扱っており、Vercelでは現状手動制御で対処するしかない。


詳細はOpenRouter vs Vercel AI Gateway: Cost, Routing, and Model…を参照していただきたい。