Requesty、AI gatewayを5% markupとEU-first運用で企業向けcontrol planeへ変えた転換

Thibault JaiguとDaniel Trugmanは、LLMを使う企業がproviderごとのAPI差分と運用負担を抱える状況からRequestyを育てた。

公式Aboutは、最初にLLM interaction analyticsを作り、複数providerを扱う過程でschema差分の複雑さを理解し、LLM routingへ移ったと説明している。出典

Analyticsからroutingへ

最初の仮説は、LLMの入出力を分析すれば企業のAI活用を理解できるというものだった。

しかし、分析を成立させるためにproviderごとのAPIとデータ形式を扱ううち、問題の中心が「何が起きたかを見る」だけでなく「どのmodelへどう送るか」にあると見えてきた。

公式の言葉では、使命は「developersが各taskに最適なLLMを使いやすくする」ことに置かれている。出典

一つのendpointに寄せる

RequestyはOpenAI-compatible APIを入口にし、routing、fallback、load balancing、caching、analyticsを同じgatewayへまとめた。

これにより、アプリ側はproviderを直接切り替える実装から離れ、model選択と費用を運用面で管理できるようになる。出典

5% markupと統制面

公式pricingでは、Free tierから始め、Pay as you goではmodel costに5%を加える料金を示している。

EnterpriseではSSO、RBAC、approved models、guardrails、EU data residencyを追加し、個人の試用から組織の統制へ段階を作った。出典

EU-firstとproduction data

2025年9月、Requestyは20VC leadのseed roundで300万ドルを調達したと発表した。出典

その後の公式研究は、coding agentの費用、context size、cache hit rateなど、production gatewayで観測したデータを記事化している。出典

Requestyの転換は、LLMを呼び出すAPIを増やした話ではない。

providerの増加で生じた複雑さをgatewayへ集め、cost・reliability・governance・地域要件を一つのcontrol planeとして売る方向へ進んだ話だ。

今後は、宣伝値ではなく顧客の実ワークロードでその約束を検証できるかが問われる。

RequestyのPMFは、複数のLLM providerを使う企業が、providerごとのAPI差分・障害・コスト・権限を自前で束ねる痛みにある。

公式Aboutは、当初のLLM analytics開発でschema差分の複雑さを知り、routingへ移った経緯を説明している。出典

600以上のモデル、fallback、caching、spend controlを一つのOpenAI-compatible endpointに寄せることで、実験から本番への移行コストを下げる。

特にEU data residencyとgovernanceを同時に求めるチームに、単なるmodel catalogとは違う理由を作る。出典

moatはrouter単体ではなく、providerごとのschema・価格・latency・failureを運用し、team budgets・guardrails・EU routingへ落とす知識の蓄積にある。

production trafficのデータと評価方法が増えるほど、単純なproxyとの差は広がるが、API gateway自体は模倣されやすい。出典

強いconsumer network effectではない。

利用企業が増えるほどrouting・pricing・failureの観測データは増えるが、顧客同士が直接価値を交換するmarketplaceではない。

むしろ、複数providerと開発者workflowを一つに接続するecosystem effectが中心だ。出典

主対象は、複数LLMを本番利用するplatform engineer、AI application team、security/compliance team、そしてLLM costを管理するCFO・engineering managerである。

単一providerの小規模検証だけなら直接APIで足りるが、fallback・budget・residencyが必要になったチームほど適合する。出典

第一は、既存SDKのbase URLを変えるだけで使える入口だ。

第二は、routing・fallback・cache・analytics・guardrailsを一つの運用面にまとめたこと。

第三は、EU residencyとRBACを含むenterprise要件を、FreeとPAYGのdeveloper experienceから連続させたことだ。出典

公式blogは、model accessをApproved Models、Access Lists、expiring keysの三層で管理する設計を示している。

機能の多さより、platform teamの統制作業を設定へ変換した点が再現可能な要因になる。出典

最大のリスクは、gatewayが増えるほどprovider価格・モデルID・地域・障害挙動の差を継続的に吸収する必要があることだ。

公式の比較やpricingは自社説明であり、第三者環境での品質・latency・savingsは要検証である。出典

また、routingを任せるほど、モデル選択の透明性とデータ保持の説明責任が重くなる。

AI gateway市場にはOpenRouter、Portkey、LiteLLM、Cloudflareなどがあり、無料化やOSS化で価格競争が強まる可能性がある。出典

Free tierとOpenAI-compatible APIで個人・開発者の試用を作り、PAYGで実トラフィックを受け、enterpriseのSSO・RBAC・audit・DPAへ広げるland-and-expand型だ。

公式blog、比較ガイド、研究データは、検索流入と導入判断を同時に作るcontent-led distributionになっている。出典

5% markupはseat feeを避ける一方、顧客の利用量に連動する。

routing・cache・EU residency・MCPなど利用深度を上げるほど、同じ顧客内での拡張余地が増える。出典

主要チャネル: content, developerDocs, productLed, community, enterpriseSales, research

AI infrastructureの入口は、モデル性能の比較だけではなく、失敗時の運用を減らすことにある。

Requestyの例は、providerを増やすほど発生するfallback・cost attribution・policyを、アプリごとの実装ではなく共有gatewayへ戻す発想を示す。出典

ただしgatewayを信用するには、自社queryで品質、latency、cost、residencyを再計測できる必要がある。

比較記事の数字を採用条件にせず、検証可能性を製品価値の一部として設計したい。

日本では、金融・医療・自治体など、データ所在と監査ログを確認しながら複数モデルを使いたい企業に機会がある。

EU-firstのresidencyやPII maskingを、日本の個人情報・委託先管理・社内稟議の資料へ翻訳できれば、単なる安価なrouterとの差を作れる。出典

導入時は日本語品質だけでなく、国内リージョン、再委託、ログ保存、障害時の切替責任を契約で確認する必要がある。

これは公開情報だけでは判断できず、要確認である。