Ramp Router登場 LLMコストを3割削減する新しい選択肢

Rampが自社のLLMコストを3割削減してきた内製ゲートウェイ「Ramp Router」を、2026年7月20日に無料ベータで外部公開しました。

月間2.75兆トークンをさばいてきた実運用の基盤が、ウェイトリスト経由とはいえ社外から使える状態になったというニュースです。

何が起きたか、なぜ3割減るのか、OpenRouterやPortkeyとどう違うのか、社内導入前に確認すべきことを整理します。

Ramp Router登場 LLMコストを3割減らした社内基盤の中身

Rampというサービス自体は、法人カードと経費精算SaaSを提供するアメリカのフィンテックです。

顧客数は約70,000社、社内には100を超えるAI機能が動いていて、それらすべてをRamp Routerが3年間支えてきました。

処理量は月間2.75兆トークン。

「そこそこの実験基盤」ではなく、事業を回している本番インフラで鍛えられてきた設計だとわかります。

内部で30%のLLMコストを削減してきた、という数字はRamp公式ページに明記されています。

3年かけて磨いた基盤を無料ベータで外部公開

1つ押さえておきたいのが、これは「オープンソース化」ではないという点です。

ソースコードが公開されたわけではなく、社内で使ってきたインフラをプロダクトとして提供開始した、というのが正確なところです。

現在はウェイトリスト制のクローズドベータで、コード自体は非公開のままです。

料金はベータ期間中は無料。

ただし各モデルのトークン利用分は定価で乗ってきます。

先着500名のウェイトリスト登録者には100ドル（約1.5万円）分のクレジットが付与されるとのこと。

「使いたい放題」ではなく「ゲートウェイの利用手数料が今はゼロ」という理解が正しいですね。

Ramp Router

Ramp Router sends every AI request to the lowest-cost approved model that clears your quality bar. One endpoint, automatic routing, less spend.

ramp.com

OpenAI互換エンドポイントで乗り換えは1行の変更

API仕様はOpenAI互換です。

既存のコードから移行する場合、ベースURLを差し替えるだけで動きます。

「1行の書き換え」というのは誇張ではなくて、OpenAI SDKを使っているならbase_urlの一箇所を変えれば済みます。

対応プロバイダーは公式ページの記載を見る限り、OpenAI、Gemini、それに一部のオープンウェイトモデル（Kimi含む）です。

プロダクトが依存しているモデルが対応リストに入っているか、事前にllms.txtで確認しておくと安全です。

LLMコストが3割下がった理由 Thompson Samplingという仕組み

「なぜ振り分けるだけで3割も削減できるのか」という疑問、当然出てきますよね。

Rampのエンジニアリングブログを追ってみると、単に「安いモデルに寄せる」だけの仕組みではないことがわかります。

内部実験では、大規模なトラフィックで25%のコスト削減を品質低下なしで達成しています。

ストリーミング対応版を社内の主要ストリーミング用途に投入したときは30%の削減。

この30%が公式サイトの見出しになっている数字ですね。

Online Learning for Cost-Efficient LLM Routing

How our LLM gateway uses Thompson sampling over lognormal latency posteriors to pick the fastest, most reliable model route per request

builders.ramp.com

障害率と速度を学習しながら安いモデルに寄せる

中身は2つのオンライン学習の組み合わせです。

1つ目は各モデルの障害率をEWMA（指数加重移動平均）で追跡すること。

プロバイダー側で起きた本物のエラーだけを数えるので、瞬間的に不調だったモデルは自動で優先度が下がります。

2つ目はThompson Samplingでレイテンシ分布を学習すること。

時間帯ごとに「このモデルはどれくらい遅くなりがちか」を確率分布として持っておいて、リクエストが来るたびに更新していきます。

この2つを合わせて、モデルごとに「悪い結果になる確率」を計算します。

式にすると「失敗する確率＋失敗しなくても期限を超える確率」。

この確率と、モデル自体のコストを組み合わせてスコアリングします。

ここが面白いところで、期限内に収まって失敗率も低い候補が複数ある場合、そのなかで一番安いオプションを選ぶ、という設計になっています。

品質を維持しながら安い方に寄せる、を毎リクエストで判断し続けているわけです。

OpenRouterやPortkeyとの違い LLMゲートウェイの中でのRamp Routerの立ち位置

LLMゲートウェイという市場カテゴリ自体は、既に複数のプレイヤーがいます。

プロダクトが「どれを選ぶか」を検討するときに、Ramp Routerがどのポジションに立つのかを整理しておきます。

OpenRouterとの違いは規模とマークアップ手数料

OpenRouterはSaaS型のマーケットプレイスで、300以上のモデルを扱い、月間約100兆トークンを処理する規模です。

ただし利用トークンに対して5.5%のマークアップが乗ります。

ここが料金の議論点です。

Ramp Routerは対応モデルを絞り込む代わりに、この手数料がベータ期間中はゼロ、というポジションを取っています。

「幅広く試したい」ならOpenRouter、「1社が磨いた基盤で運用したい」ならRamp Router、という使い分けの構図になりそうです。

LiteLLMやPortkeyとの違いはセルフホストか丸ごと任せるか

@LiteLLMはOSSで自分たちがセルフホストします。マークアップはないですが、運用は自社の責任です。データ主権を重視するプロダクトが選ぶことが多いですね。

@Portkeyは2026年にPalo Alto Networksに買収され、AIエージェント向けセキュリティ製品「Prisma AIRS」の一部に組み込まれました。純粋なゲートウェイ機能というより、エンタープライズの可観測性とガバナンス寄りにポジションが動いています。

@Fireworks AIは振り分け役ではなく、特定のオープンウェイトモデルに最適化した推論プラットフォームです。同列に並べると選定を誤りやすいので、Fireworks AIは「振り分ける側」ではなく「推論を担う先」として位置づけるほうが正確です。

社内にAIゲートウェイを導入する前に確認すべきこと

魅力的なプロダクトですが、私が担当しているプロダクトにこのまま入れるかというと、いくつか確認しておきたいことがあります。

• ウェイトリスト制で今日から使えるわけではない。社内提案するなら「順番待ち中に何を試すか」もセットで用意する
• ベンダーロックインの論点。決済会社のインフラにAIトラフィックを預けることへの社内の温度感を先に確認する
• データガバナンス。プロンプトと出力のログ保持ポリシー、自社のセキュリティ基準との照合
• 30%削減はRampの自社ワークロードでの数字。タスク構成が違えば削減率も当然変わる
• 対応モデルに自社が使っているものが含まれているか（llms.txtで事前確認）

「今日から動かせる代替」を持っておくのも実務的です。

OpenRouterで先にモデル振り分けの効果を測っておいて、その数字を持ってRamp Routerのベータ枠を待つ、という順番なら社内議論も進めやすいですね。

LLMコスト削減はモデル選びの自動化から始まる

LLMコストの削減って、「一律で安いモデルに乗り換える」話に流れがちです。

でもRampのやり方を見ると設計思想はまったく逆で、リクエスト単位でその瞬間の最適解を選び続けるという発想が土台にあります。

自社のAI機能が今どのモデルにどれくらいのトークンを流しているのか、そこを可視化するだけでも十分に価値のある一歩です。

3割削減という数字は、その先の話ですね。