企業向けAIゲートウェイ・モデルルーター選定ガイド
この記事で学べること
- AIゲートウェイ、モデルルーター、利用状況の記録、品質評価の役割の違い
- Cloudflare、Vercel、Portkey、LiteLLM、Envoy、Kongがそれぞれ向く利用環境
- RouteLLM、vLLM Semantic Router、Amazon Bedrock、Microsoft Foundryの使い分け
- Langfuse、Phoenix、OpenTelemetryによる利用状況と品質の確認方法
- チームでの検証から全社導入、規制対象の業務までの選定基準と自動化の留意点
AIゲートウェイとモデルルーターの役割の違い
AIモデルは、回答や判断を担うAIの中核で、種類によって得意な仕事や費用が異なります。アプリは、文書の要約などを依頼する利用画面やプログラムです。AIゲートウェイ(アプリからAIへの依頼をまとめて受け付け、利用ルールや送信先を管理する仕組み)と、モデルルーター(依頼に応じて使うAIモデルを選ぶ仕組み)は、役割が異なります。企業でAIを運用するには、この2つに加えて、実際の利用状況を記録し、回答の品質を評価する仕組みも必要です。外部企業から借りて使う処理・保存設備をクラウドと呼びます。
たとえば、社内文書を要約するアプリなら、「この文書を外部のAIへ送ってよいか」という利用ルールと、「どのモデルに要約させるか」という選択を分けて考えます。実行後には、使ったモデルや費用を記録し、要約に必要な情報が残っているかを評価します。送信先を選べることと、業務に使える回答を得られることは、別々に確かめる必要があります。
ゲートウェイだけで、回答の品質評価や、成果に対する費用の割り当てまで自動的に整うわけではありません。ルーターも、扱えるデータの区分、予算、監査(決めたルールが守られたかを記録で確かめること)、障害時の停止をすべて担うものではありません。
この記事では、利用ルールの適用、モデル選択、利用状況の記録、品質評価の4つに分けて、製品の選び方と導入の順序を整理します。最後まで読むと、自社の運用体制に合う組み合わせと、本番利用へ進むための確認事項を判断できます。
企業のAI運用を支える4つの役割と責任者
本記事では、AI運用を「強制・選択・観測・評価」の4層に分けます。ここでいう「層」は役割の区分です。4つの製品を必ず導入する、という意味ではありません。
| 役割 | 担当すること | 判断する問い | 主な選択肢 |
|---|---|---|---|
| 強制:利用ルールの適用 | 利用者と権限の確認、データの取り扱い、利用上限、失敗時の再試行や停止 | 誰が、どのデータを、どこへ送ってよいか | Cloudflare、Portkey、LiteLLM、Envoy、Kongのゲートウェイ、クラウド標準機能 |
| 選択:モデルと送信先の決定 | モデル・提供事業者の選択、障害時の代替、新しい経路の一部試行、品質不足時の上位モデルへの切り替え | この仕事を、どのモデルに任せるか | ゲートウェイの振り分け機能、RouteLLM、vLLM Semantic Router、Bedrock、Microsoft Foundry |
| 観測:利用状況と費用の記録 | 処理の経過、使用量、応答時間、エラー、保存済み情報の再利用、部門ごとの費用の割り当て | 実際に何が起き、誰の費用になったか | OpenTelemetry、Langfuse、Phoenix、各ゲートウェイの記録 |
| 評価:回答と業務結果の確認 | 品質、安全性、業務の完了率、変更後の品質低下、費用対効果 | 安いモデルへ切り替えても、業務の合格条件を満たすか | Langfuse、Phoenix、自社の評価環境、クラウドの評価機能 |
一つの製品が複数の役割を担う場合も、責任者は明確にします。障害や品質低下が起きたとき、誰が何を判断するか分かるようにするためです。
セキュリティ担当は利用を許可する条件、基盤運用担当は送信経路とサービスの稼働、FinOps担当(技術・財務・業務部門と協力し、クラウド費用と価値を管理する担当)は費用配賦(共有費用を部門や用途に割り当てること)と予算を受け持ちます。業務部門は、回答の品質と仕事の成果を判断します。
例外的な利用を認める場合も、一人が申請・承認・実装・評価をすべて行わないようにします。こうした職務分離(申請する人と承認する人などを分けること)は、規制対象でない業務でも変更時の事故を減らすために役立ちます。
既存の利用環境に合うAIゲートウェイの選定
ゲートウェイは、導入までの時間、自社で運用する必要性、既存のネットワーク、規制、運用人員を基準に選びます。運用担当が少ない企業では、提供会社が運用を担う管理型サービスと、一つの評価基盤を組み合わせる方法が現実的です。
自社で導入・運用するセルフホストを選ぶ場合は、ライセンス費用だけで比較しません。保存した記録の維持、障害が起きても稼働を続ける構成、サービスの利用許可を示すキーの定期更新、提供事業者の仕様変更への対応、夜間や休日の障害対応まで含めた費用を見積もります。
既存環境には、アプリ開発用の部品、クラウド、依頼を通す通信経路が含まれます。認証キーは、サービスの利用許可を確認するための情報です。
次の表は、候補を絞るための比較です。機能の有無だけでなく、費用と障害対応の責任範囲を確認します。
| 選択肢 | 向く利用環境 | 導入前の主な確認事項 |
|---|---|---|
| Cloudflare AI Gateway | Cloudflareを共通の通信経路に使い、複数モデルの送信先と予算を管理したい | 支出上限の集計方法、設定できるルール数、対応事業者、データの送信経路 [1][2] |
| Vercel AI Gateway | VercelやAI SDK(アプリからAIを呼び出すための開発用部品)を使ったアプリ開発が中心 | 持ち込みの認証キーで直接支払う費用と、予算管理の対象範囲 [3][4] |
| Portkey | AIの送信先・費用・利用ルールをまとめて管理したい | プランごとの機能、保存済み回答の再利用条件、データ保管、自社運用できる範囲 [5] |
| LiteLLM Proxy | Python(プログラミング言語)を使い、幅広いモデルへの接続を自社で運用したい | 予算の使用額を保存する仕組み、障害時に通信を許可する条件、無料・有償機能の境界、運用責任 [6] |
| Envoy AI Gateway | Kubernetes(複数のサーバー上でアプリの配置・稼働を管理する基盤)を標準に使い、ネットワーク担当が通信処理を管理している | 変化の速い仕様への対応、別途用意する管理画面と評価機能 [7] |
| Kong AI Gateway | 設定管理と通信処理を分けたい、または既存のKong環境を使いたい | AI Gateway 2.xとKong Gatewayの構成差、有償機能、入力内容の意味で処理を選ぶ際に必要な保存設備、障害検知の方式 [8][21] |
| AWS・Azureの標準機能 | データ、利用者の権限、監査を既存クラウドへ統一したい | 選べるモデルと振り分け条件、他クラウドへの移しやすさ、同じ条件で評価できるか [11][12] |
予算機能の対象範囲には注意が必要です。Cloudflareの支出上限は推定値と遅れて反映される集計に基づくため、請求を上限額で厳密に止める会計台帳の代わりにはなりません。[2] Vercelでは、自分で用意した認証キーで提供事業者へ直接支払う費用は、Vercel側の予算に含まれません。[4]
Kong AI Gateway 2.xとKong Gateway上のAI向け拡張機能は、設定や認証情報をそのまま共有する構成ではありません。既存環境から移る場合も対応関係を確認します。[8][21] 旧Envoy AI Gatewayの資料はAgent Routerのサイトへ移転しているため、対象プロジェクトと版も確認対象です。[7]
モデルルーターの選択肢と適用条件
モデルルーターは、仕事に応じてモデルを選び、品質と費用のバランスを調整します。利用ルールや監査を担うゲートウェイと組み合わせ、自社の業務で品質を確かめた範囲に適用します。
RouteLLMとvLLM Semantic Routerの比較範囲と自社運用
RouteLLMは、高性能なモデルと比較的低コストなモデルの振り分けを評価・提供する、研究向けのフレームワーク(実装や検証の土台となるソフトウェア)です。公開ベンチマーク(同じ課題を使った性能比較)のMT-Benchでは、GPT-4の性能の95%を維持しながら、最大85%の費用削減を報告しています。[9]
これは特定の評価条件での結果です。自社の仕事でも同じ削減率や品質になるとは限りません。
vLLM Semantic Routerは、入力内容や方針に応じてモデル、利用するツール、推論経路(AIが回答を導く処理の進め方)を選ぶ、ソースコード(動作を記述したプログラム)が公開されたソフトウェアです。ライセンスはApache-2.0(条件に従って利用・改変・再配布できるライセンス)です。[10]
自社で運用するモデルも含め、細かな選択ルールを作りたいチームに向いています。ただし、モデルを稼働させる基盤、利用者の認証、監査、品質評価まで、すべてを置き換えるものではありません。
BedrockとFoundryの対応モデルと評価条件
Amazon Bedrock Intelligent Prompt Routingは、同じモデル群の中から2モデルを設定し、依頼ごとに品質と費用のバランスを取ります。英語の入力に最適化されており、アプリ固有の実績データを使って振り分けを調整することはできません。基準モデルともう一つのモデルを指定するため、対象言語と評価条件が自社の用途に合うかを先に確認します。[11]
Microsoft Foundryのmodel routerでは、Balanced(品質と費用のバランス)、Quality(品質重視)、Cost(費用重視)などの方式と、選択対象にするモデル群を指定できます。公式ガイドは、実際の利用を代表する負荷で、品質、費用、末尾遅延(応答が特に遅い一部の処理の待ち時間)、利用ルールへの適合を評価するよう求めています。[12][13]
利用状況の記録と品質評価のためのツール
どのモデルが使われ、いくらかかったかの記録と、その結果が業務に使えるかの評価は、組み合わせて運用します。可観測性(処理の記録から、内部で何が起きたかを調べられること)と評価の候補になるのが、LangfuseとPhoenixです。
Langfuseは、依頼の受け付けから応答までの処理記録、プロンプト(AIへ渡す指示や情報)、品質評価、データセット(評価などに使う課題やデータの集まり)、実験を公開ソフトウェアの中核機能として提供します。企業向けには、細かな権限管理、監査、保存期間の管理、SCIM(社員の入退社などに合わせてアカウント情報を同期する仕組み)、サーバー側でのマスキング(受け取った情報の機密部分を伏せる処理)を追加します。[14]
Phoenixは、OpenTelemetryを基礎に、依頼の受け付けから応答までの処理記録、評価、データセット、実験、プレイグラウンド(指示やモデルを変えて応答を試す画面)を扱える公開ソフトウェアです。手元の環境や、自社で運用する環境でも使えます。[15]
OpenTelemetryは、これらと同じ役割の評価製品ではありません。異なるツールでも記録を扱えるようにするための共通の基準です。生成AI向けの記録項目には、入力・出力のトークン数(AIが文章を分けて処理し、使用量を数える単位)に加えて、保存済みの入力処理を再利用するキャッシュのトークン数、AIが回答を考える処理で使った量があります。[16]
仕様が変わっても記録の意味を追えるよう、採用した仕様の版と、自社で追加した項目を残します。何をどの形式で記録するかを、データを送る側と受け取る側で共有するためです。
ガバナンスの3段階に応じた推奨構成
ガバナンス(誰が判断し、どのルールでAIを使い、どう確認するかを決めること)の要件は、チーム内での検証と、全社利用、規制対象の業務で異なります。本記事では、必要な管理の範囲に応じて次の3段階に分けます。
変更を試す環境と実際の業務で使う環境を分け、利用できるモデル、例外の承認者、設定を戻す方法を確認します。
| 段階 | 想定する利用 | 推奨構成 | 本番利用へ進む条件 |
|---|---|---|---|
| 1.チームでの検証 | 1〜3チームで、影響の小さい業務から利用状況を把握したい | 既存クラウド、またはVercel・Cloudflare・Portkeyの管理型ゲートウェイ+OpenTelemetry+LangfuseかPhoenix | 利用者・用途の記録、利用上限、処理記録、固定の評価課題がある |
| 2.全社共通基盤 | 複数部門で複数の提供事業者を使い、費用を部門へ割り当てたい | 管理型ゲートウェイ、またはLiteLLM・Envoy・Kong AI Gateway 2.x・Kong GatewayのAIプラグイン。共通ログイン、認証情報の管理、記録の集約、変更時の自動評価を組み合わせる | 開発・本番の分離、利用できるモデルの一覧、部門予算、例外承認、以前の設定へ戻す処理を自動化している |
| 3.規制対象・影響の大きい業務 | 機密情報や顧客に関する判断を扱い、厳格な監査が必要 | 承認済みの地域で動くクラウド、または専用の通信処理基盤。利用ルールの適用、改ざんに強い監査記録、人による承認を組み合わせる | データ区分、保存・削除、職務分離、変更審査、定期的な独立評価の証拠がある |
全社共通基盤で使うSSO(複数のサービスへ共通のアカウントでログインする仕組み)や秘密管理(認証キーなどを保管し、必要な処理だけに渡す仕組み)は、利用者と権限を管理するためのものです。評価CI(設定やコードの変更ごとに評価を自動実行する仕組み)は、変更による品質低下を見つけるために使います。
NIST AI RMF(AIのリスクを管理するための枠組み)は、Govern(管理体制の整備)、Map(利用状況とリスクの把握)、Measure(測定・評価)、Manage(リスクへの対処)を継続的に行う考え方です。ISO/IEC 42001(組織のAI管理体制に関する国際規格)は、継続的な改善を定めています。[17][18]
これらは、製品の機能一覧を確認するだけで対応できるものではありません。責任者、評価方法、例外の扱い、残す証拠、見直しの周期を決めるために使います。
費用配賦では、FinOpsの考え方に沿い、利用者、アプリ、部門、開発・本番の区分、ワークフロー(一連の業務手順)などを依頼時に記録します。複数部門で共有する費用を、どの方法で割り当てるかも明確にします。[19]
モデル選択の自動化を支える可視性・利用ルール・評価
モデル選択の自動化には、どの業務で何が起きたかを追える記録、利用してよいデータとモデルのルール、業務ごとの品質評価が必要です。費用や品質が変わったとき、原因を特定して元の構成へ戻せることも確認します。
| 前提 | 比較・記録すること |
|---|---|
| 利用状況の把握 | 用途、部署、モデル、入力・出力の使用量、費用、応答時間、失敗率 |
| 利用ルール | 送信できるデータ、処理地域、予算、操作権限、障害時の停止・代替経路 |
| 品質評価 | 同じ業務事例での合格率、重大な誤り、人の修正工数、変更後の品質低下 |
この表は運用上の整理です。記録には部門や用途を対応付けつつ、機密性の高い入力全文を無条件に保存しません。[16][19]
キャッシュには、入力の共通部分の処理を再利用するものと、回答そのものを再利用するものがあります。利用条件や効果は、モデル・提供先・方式で変わります。[20][22] 費用を比べる際は、キャッシュの利用条件、再試行、人の修正工数をそろえます。回答を再利用する場合は、前提や権限が違う依頼に保存済み回答を使わないかも検証します。
入力を短くしても品質が安定し、誤りを修正できる業務は、自動振り分けの候補です。高リスクな判断や契約上モデルを固定する業務では、費用が下がる可能性だけを理由に切り替えません。検証した版と構成を残し、品質低下や障害時に元へ戻す条件を決めます。
まとめ:運用体制に合う組み合わせと、評価後の段階的な自動化
企業のAI基盤は、利用ルール、モデル選択、利用記録、品質評価の担当を決め、既存環境と運用人員に合うツールを組み合わせることで選定できます。費用だけでなく、品質、応答の遅さ、失敗率、元に戻せることを確認してから対象を広げれば、低コスト化と業務上の合格条件を一緒に判断できます。
自動化の適否は、利用状況を追えることと、業務ごとの評価に基づいて判断できます。特定モデルでの再現性が必要な業務では、固定経路と変更承認を維持する方が適しています。
本記事は一般的な情報整理であり、法的・セキュリティ上の助言ではありません。実務判断は自社の専門担当者と確認してください。
参考文献
- Cloudflare, Dynamic routing, AI Gateway Docs
- Cloudflare, Spend limits, AI Gateway Docs
- Vercel, Provider Options, AI Gateway Docs
- Vercel, Budgets, AI Gateway Docs
- Portkey, AI Gateway, Documentation
- LiteLLM, LiteLLM Proxy Server, Documentation
- Envoy AI Gateway, Data Plane, Documentation
- Kong, AI Gateway architecture
- LMSYS Org, RouteLLM, GitHub
- vLLM Project, vLLM Semantic Router, GitHub
- Amazon Web Services, Use intelligent prompt routing with Amazon Bedrock, Documentation
- Microsoft, How to use model router for Microsoft Foundry Models, Microsoft Learn
- Microsoft, Evaluate model router for your workload, Microsoft Learn
- Langfuse, Self-hosting and product editions, Documentation
- Arize AI, Phoenix, GitHub
- OpenTelemetry, Generative AI Attributes, Semantic Conventions
- National Institute of Standards and Technology, AI RMF Core, AI Risk Management Framework
- International Organization for Standardization, ISO/IEC 42001:2023, 2023年12月
- FinOps Foundation, Capability: Allocation, FinOps Framework
- Amazon Web Services, Prompt caching for faster model inference, Amazon Bedrock User Guide
- Kong, Configure Kong AI Gateway on-prem
- Cloudflare, Caching, Cloudflare AI Gateway Docs
最新の機能、料金、ライセンス、提供地域は、各サービスの公式サイトと公式ドキュメントを確認してください。