Perplexity、AIゲートウェイの仕組みと限界を解説

Perplexityは2026年10月20日、AIゲートウェイがアプリケーションと大規模言語モデルの間のトラフィックをどのようにルーティング、計測、管理するのか、また組織がどのような場合に導入を必要とするのかを解説するガイドを公開した。「AIゲートウェイとは何か？ LLMとエージェントのトラフィックにおけるルーティング、コスト管理、ガバナンスのガイド」と題された記事は、同社ブログの最新記事として掲載された。

定義とリクエスト処理

このガイドでは、AIゲートウェイを、組織のアプリケーションやAIエージェントと、それらが呼び出す大規模言語モデルやツールとの間に設置する中央のプロキシ層と定義している。ルーティング、コスト管理、セキュリティの適用、利用状況の監視を一元的に担う。各プロバイダー（ガイドではOpenAI、Anthropic、Google、オープンソースモデル、セルフホスト型エンドポイントを例に挙げている）が独自のSDK、APIキー、リクエスト形式を提供するため、ゲートウェイは標準化されたリクエストを受け付け、呼び出し先のプロバイダーに合わせて変換する。モデルの追加、切り替え、廃止は、アプリケーションのコードではなく、ゲートウェイの設定を通じて行う。

ガイドによると、ゲートウェイのベースURLに送られたすべてのリクエストは、同じ4段階の処理を経る。まず、ゲートウェイがキーとロールに基づいて呼び出し元を認証・認可する。次に、トークン上限、予算、PII（個人を特定できる情報）の削除などのガードレールを含むポリシーを適用する。その後、コスト、レイテンシ、可用性に応じてモデルまたはプロバイダーにルーティングし、障害発生時にはバックアップに切り替えるとともに、リクエストを接続先プロバイダーの形式に変換する。最後に、支出の追跡やデバッグに使えるよう、モデル、トークン数、レイテンシ、処理結果を記録する。

機能と明示された制限

ガイドでは、6つの機能領域を紹介している。ルーティングとフェイルオーバーでは、コスト、レイテンシ、機能に応じてモデルを選び、プロバイダーが停止した場合やレート制限に達した場合には、リクエストを自動的に別の接続先へ振り分ける。トークンベースのレート制限と予算では、チーム、プロジェクト、ユーザーごとに利用量に上限を設け、割り当てに達するとリクエストを拒否する。セマンティックキャッシュでは、新しいプロンプトを意味に基づいて保存済みの回答と照合し、十分に近いプロンプトであればモデルを呼び出さず、保存された応答を返す。ガードレールは各プロンプトと応答を検査し、プロバイダーに届く前に個人情報や機微情報を削除してプロンプトインジェクションのリスクを軽減するとともに、望ましくないコンテンツをフィルタリングする。可観測性機能は、実行されたモデル、トークンの使用量、レイテンシ、失敗を記録する。ガバナンス機能は、ロールに基づいてモデルへのアクセスを許可し、すべての呼び出しの監査ログを保持する。

制限について、ガイドは、ゲートウェイによってレイテンシが増加するものの、LLMのトラフィックにおける遅延は比較的小さいと説明している。また、BroadcomのVMware Cloud Foundationチームが2026年6月に実施した独立ベンチマークを引用している。同ベンチマークでは、調整済みのEnvoy AI Gatewayは、最大224人の同時利用者に対し、コンテンツ検査を行わずにルーティングとレート制限を実施した場合、リクエスト当たり約2ミリ秒の遅延を追加した。引用された同じベンチマークによると、ガードレールとセマンティックキャッシュを使用すると、数十ミリ秒から数百ミリ秒の遅延が加わる可能性がある。さらにガイドは、ゲートウェイはモデルに何を尋ねるかを決めたり、会話を記憶したり、エージェントの段階的な処理ロジックを実行したり、回答の質を評価したりするものではないと述べている。また、コストを重視したルーティングでは、より安価なモデルが劣る回答を返した場合、品質が低下する可能性があると警告している。

ゲートウェイの種類とエージェントのトラフィック

ガイドでは、AIゲートウェイと従来のAPIゲートウェイを、いくつかの点で比較している。トークン計測とリクエスト数の制限、意味に基づくキャッシュと完全一致によるキャッシュ、機微情報や隠された指示を検出するプロンプト検査とキー認証、コスト・レイテンシ・機能に基づくモデルへのルーティングとバックエンドサービスへのルーティングだ。また、より限定的な2つの用語も区別している。LLMゲートウェイはモデル呼び出し自体を処理する一方、MCPゲートウェイは、エージェントがModel Context Protocolを通じてアクセスできるツールやデータソースを管理する。ガイドによると、LiteLLM、Portkey、Azure API Management、Envoy AI Gatewayは現在、MCPガバナンスにも対応しており、これらの用語が重なり合う制御レイヤーを指す場合もある。

ガイドでは、エージェントはタスクが完了するまで、モデル呼び出しとツール利用のループを繰り返すものと説明されている。ゲートウェイは、エージェントが開始するすべてのトラフィックを制御・監視し、エージェントがアクセスできるツールやデータソースを認可するとともに、モデルとツールのすべての呼び出しを監査ログに記録する。

引用された導入状況のデータと導入に関する指針

需要規模を把握するため、ガイドは第三者機関の数値を引用している。Ciscoの「AI Readiness Index 2025」によると、従業員数が500人を超える組織の上級ビジネスリーダー8,039人のうち、83%がAIエージェントの開発または導入を計画している。また、Gartnerは、企業向けアプリケーションにおけるタスク特化型エージェントの割合が、2025年の5%未満から2026年末までに40%に達すると予測している。コストについて、ガイドはDoiT/Sapioの2026年調査を引用しており、参加した財務責任者の79%が、過去1年間にAI予算を超過したと回答した。さらに、DataikuとHarris Pollが2026年に実施した調査では、企業のCIOの93%が、ユースケースによって優れた性能を発揮するモデルは異なると回答し、企業の81%が2つ以上のモデルプロバイダーを利用する見込みで、55%が少なくとも一度はLLMプロバイダーを切り替えたとされた。

ガイドが引用する独立した監視データによると、主要なLLMプロバイダーの稼働率は2026年5月時点で約99.85～99.9%で、ガイドではこれを年間およそ9～13時間のダウンタイムに相当するとしている。また、Cockroach Labsが2026年にインフラ担当の上級幹部1,125人を対象に実施した調査では、AIのダウンタイムが1時間発生すると、自社に10万ドルを超える損失が生じると回答した人は3分の2に上った。さらにガイドは、OWASPが2025年にプロンプトインジェクションをLLMのセキュリティリスクの筆頭に挙げたことと、Zscaler ThreatLabzの調査で、AIアプリケーションに送信された企業データが1年間で93%増加し、ChatGPTだけでデータ損失防止の違反が4億1,000万件発生したことを紹介している。

ガイドは、組織にゲートウェイが必要となる兆候として、複数のコードベースにプロバイダーのキーがハードコードされていること、経理部門が割り当て先を特定できないモデル利用料、単一プロバイダーへの依存に起因するレート制限やダウンタイムのエラー、機密データを含むプロンプトが検査されていないこと、チームごとにプロバイダー連携が重複していること、MCPツールとの連携、セキュリティやコンプライアンスの全体像を把握できていないことを挙げている。一方、単一のプロトタイプや利用量の少ないサイドプロジェクト、セキュリティ要件が最小限の環境で単一のモデルエンドポイントを呼び出す場合には、ゲートウェイは必要ないとしている。セルフホスト型の選択肢として、プライベートクラウド、Kubernetes、またはオンプレミスのインフラ上で利用するLiteLLM、Portkey、Apache APISIXを挙げ、マネージド型の選択肢としてCloudflare AI Gateway、Azure API Management、Amazon Bedrock AgentCore Gatewayを挙げている。ガイドは、データの管理とプライバシー、PostgreSQL、Redis、etcdなどの状態保存先を含む運用負荷、導入の速さ、各種連携を基準に選択肢を検討している。FAQでは、「生成AIゲートウェイ」と「AIゲートウェイ」は同じ意味で使われ、最良のオープンソースAIゲートウェイが一つに定まるわけではないとしている。