PerplexityがLLMゲートウェイの仕組みと本番環境でのリスクを解説

Perplexityは2026年10月27日、LLMゲートウェイの実践ガイドを公開した。エンジニアリングチームに向けて、中間レイヤーがモデル呼び出しをどのようにルーティング、認証、キャッシュ、ログ記録するかを解説するとともに、プロバイダーの認証情報を1つのサービスに集約することで生じるセキュリティと信頼性のリスクをまとめている。

ゲートウェイの定義と分類

このガイドでは、LLMゲートウェイをモデル呼び出しのリバースプロキシと定義している。アプリケーションはOpenAI、Anthropic、Googleなどのプロバイダーに直接リクエストを送るのではなく、ゲートウェイに送信し、ゲートウェイは運用者のルールを適用したうえでリクエストを転送する。このカテゴリーは、ツールの乱立に対する解決策として紹介されている。冒頭では、2026年9月にRedditのr/LLMDevsへ投稿された内容を取り上げており、あるエンジニアが、職場の全員がClaude、OpenAI、AWS Bedrockなどの推論プロバイダー用にそれぞれ独自のキーを持っていた状況を説明している。

このガイドの比較表では、ゲートウェイを4種類に分けている。APIゲートウェイはバックエンドサービスの前段に置かれ、クライアントが認証済みか、レート制限を超えていないかを判断する。LLMゲートウェイはモデルプロバイダーの前段に置かれ、どのモデルにリクエストを送るか、費用を誰が負担するか、応答が返ってきたかどうかを判断する。MCPゲートウェイは、エージェントが所定の引数を使って特定のツールを呼び出してよいかを判断する。このガイドでは、これらの役割の一部または全部を組み合わせたベンダー製品を「AIゲートウェイ」と呼んでいる。

リクエスト処理の6つのステップ

このガイドでは、アプリケーションからモデルへ、さらに戻ってくるまでの1件のリクエストを追うことで、仕組みを解説している。まずアプリケーションが、OpenAI互換形式であることが多いチャットリクエストを、ゲートウェイのエンドポイントに送信する。ゲートウェイは認証情報を検証する。多くの場合、それはチームや製品に発行された仮想キーだ。また、入力ガードレールが組み込まれている場合は、プロンプトをスキャンし、機密データやモデルの指示を上書きしようとする試みがないか確認できる。キャッシュが有効であれば、条件に合致するリクエストには保存済みの応答を返せる。ゲートウェイによっては、完全に一致するリクエストではなく、類似していると判定されたリクエストを照合するセマンティックキャッシュも利用できる。その後、ゲートウェイは設定から一致するルートを探し、最初のプロバイダーがタイムアウトした場合には、予備のプロバイダーに切り替えられる。リクエストを選択したプロバイダーの形式に変換し、送信する呼び出しを認証してから、応答をアプリケーション向けに再変換する。ログ記録が有効な場合は、誰が呼び出したか、どのモデルが処理したか、トークン数、レイテンシ、費用を記録する。

セキュリティと信頼性のリスク

このガイドが中心的な警告として挙げているのは、ゲートウェイに認証情報が集約されることです。Microsoftのセキュリティチームは、LiteLLMのデプロイ環境が保持または取得する可能性のある情報として、プロバイダーのAPIキー、LiteLLMのマスターキー、仮想キーの記録、データベース接続文字列、ルーティング設定、テナントのポリシーデータを列挙しています。2026年8月26日の投稿で、Microsoftは、攻撃者がゲートウェイの実行環境から認証情報を窃取した、実際に確認されたLiteLLMゲートウェイへの侵害について説明しました。

2026年10月13日、Check Point ResearchはLiteLLMにおけるリスクの高い脆弱性を2件公表しました。CVE-2026-35029は、読み取り専用ユーザーを含む認証済みユーザーが管理機能にアクセスしてゲートウェイを乗っ取ることを可能にする、アクセス制御上の欠陥です。CVE-2026-59823は、ユーザーがゲートウェイのリクエストを攻撃者の管理するサーバーに転送し、AIプロバイダーのAPIキーを取得できる、サーバーサイドリクエストフォージェリの脆弱性です。どちらもLiteLLMバージョン1.83.9で修正されています。Check Pointによると、LiteLLMのダウンロード数は月間9,700万回、GitHubのスター数は59,000件を超えており、LiteLLMへの協調的な脆弱性開示は2025年10月に始まりました。

このガイドは、ガードレールが機能しない場合の対応方針も設定するようチームに促している。フックについては、ゲートウェイがリクエストの処理経路でコンテンツを外部スキャナーに渡し、判定を受ける箇所と説明している。Portkeyのドキュメントではbefore_request_hooksとafter_request_hooksという名称が使われており、TrueFoundryは4つのフックを実行して、MCPツールの呼び出し前後にもチェックを追加する。

信頼性について、このガイドは記録されているサービス停止事例を取り上げています。Cloudflareが2025年6月12日の障害について自ら公表した説明によると、AI Gatewayはクライアント設定と内部設定にWorkers KVを利用していたため、リクエストの97%でエラー率がピークに達しました。障害全体は2時間28分続きました。OpenRouterが2026年2月17日と19日の障害について公表した事後検証報告によると、サードパーティのキャッシュ依存先の障害を受け、各インシデントはそれぞれ38分と35分続きました。また、「User not found」という401エラーが発生し、回路遮断器の導入や、インフラの問題によって認可情報の照会が妨げられた場合に401ではなく503を返すことなどの対策が実施されました。

導入方法、料金、各ベンダーの特徴

このガイドでは、4つの導入方法を紹介している。チームが社内で最小限のゲートウェイを開発する方法がある。リクエストを受け付け、呼び出し元のキーを確認し、プロバイダーの認証情報を付与して呼び出しを転送し、結果を記録する仕組みだ。あるいは、LiteLLM、Bifrost、Heliconeなどを選択肢として、オープンソースのゲートウェイをセルフホストできる。マネージド型のゲートウェイとしては、Cloudflare AI Gateway、Vercel AI Gateway、OpenRouter、Portkeyのホステッドゲートウェイが挙げられている。4つ目の方法は、企業がすでに運用しているAPIゲートウェイを拡張することで、例としてKong AI Gateway、ApigeeのAIゲートウェイポリシー、Azure API ManagementのAIゲートウェイが紹介されている。

コストについて、このガイドは、LLMゲートウェイには無料のオープンソースソフトウェアから、月額約50ドルからの有料プラン、個別見積もりのエンタープライズ向け料金まで幅があると説明しています。また、代わりに購入額の一定割合を課金するサービスもあり、OpenRouterのStandardプランではクレジットの購入額に5.5%が上乗せされるとしています。

このガイドは最後に、ベンダーごとの質問に回答しています。Amazon Bedrock AgentCore Gatewayは、AWSが「推論ターゲット」と呼ぶ仕組みを通じたモデル呼び出しに対応しており、アプリケーションは単一のエンドポイントからAmazon Bedrock、OpenAI、Anthropicなどのプロバイダーに接続できます。また、Perplexity独自のAgent APIはOpenAIのResponses APIインターフェースに対応しているため、チームは既存のOpenAIクライアントライブラリを再利用できます。さらに、このAgent APIでは、異なるプロバイダーのモデルを含め、最大5つのモデルを優先順に指定できます。このガイドでは、Perplexityのオープンソース「Numbat」も紹介しています。Numbatはローカルフックを介して対応エージェントに接続し、シェルコマンドやファイルへの書き込みなど、実行前の予定されたアクションを検査できます。ブロック機能は任意で、デフォルトではオフになっています。