Agent Router を採用する前に読む、Envoy ベース AI ゲートウェイの実像
Manages Unified Access to Generative AI Services built on Envoy Gateway
ひと目でわかる
- これは何？
- Agent Router は、OpenAI 互換の単一 API で複数の生成 AI プロバイダと自前推論を束ねる Envoy Gateway 上のコントロールプレーンである。旧 Envoy AI Gateway からの改名で、CRD と CLI は変わっていない。本稿は README とリポジトリ情報だけを根拠に、仕組みと導入判断の境界を整理する。
- 誰に向いている？
- Kubernetes 上で複数の LLM プロバイダと自前推論をひとつの OpenAI 互換エンドポイントにまとめ、クレデンシャルとクォータを Envoy 側で集中管理したいプラットフォームチームには向く。単一プロバイダしか使わず、Envoy Gateway を既に運用していないチームには、導入する理由が薄い。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Go です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
改名してもマニフェストが壊れない理由
このプロジェクトは Envoy AI Gateway から Agent Router へと名称を変えた。改名であり、フォークでも再設計でもない。README は「Same code, same maintainers, same release cadence and Apache 2.0 license」と明記し、デプロイ済みのリソース名は変えないとしている。具体的には CRD の AIGatewayRoute、AIServiceBackend、BackendSecurityPolicy、および API グループ aigateway.envoyproxy.io はそのまま残る。CLI は aigw のままで、名前空間 envoy-ai-gateway-system も維持される。コンテナイメージは docker.io/envoyproxy/ai-gateway-*、Go モジュールパスは github.com/envoyproxy/ai-gateway で、こちらも変更されていない。
変わったのはリポジトリの場所とウェブサイトのドメインだけである。旧 envoyproxy/ai-gateway のリンクはリダイレクトされ、aigateway.envoyproxy.io の各ページも同じ内容へ転送される。
この種の改名で普通に起きる事故は、イメージ名や API グループが変わって既存のマニフェストが適用できなくなることだ。ここではその線を意図的に切っていない。運用側から見れば、アップグレード時に書き換えるべきものが実質的に存在しない。ただし「Nothing you deploy is renamed」という主張は README の記述であって、実際の差分を筆者が検証したわけではない。v1.0.0 と v1.1.0 の間で CRD のフィールドが増減していないかは、リリースノート側で確認する必要がある。
Two-Tier Gateway という分割の意味
README は利用形態として「two-tier gateway pattern」を挙げている。Tier One Gateway は集中エントリポイントとして認証、トップレベルルーティング、グローバルなレート制限を担う。Tier Two Gateway は自前でホストするモデル配信クラスタへのイングレスを扱い、エンドポイントピッカーによる LLM 推論の最適化を可能にする。
この分割は、責任の所在をネットワーク境界で切る設計だ。プロバイダの API キーやクォータは Tier One に集まり、GPU ノードの近くにあるルーティング判断は Tier Two に残る。両者を別々のクラスタや別のチームが持つことも想定できる。逆に言えば、両方を一人で運用する小規模チームには層が増えるだけで、設定ファイルが二箇所に散る。自前推論を一切動かさずホスト型プロバイダだけを使うなら、Tier Two を立てる理由は README の説明からは読み取れない。
図として site/blog/images/aigw-ref.drawio.png が参照されているが、本文中の説明はこの二層の役割分担までである。具体的なデータフロー、たとえばリクエストが Tier One から Tier Two へどう転送され、どの時点でモデル名が解決されるかは、README には書かれていない。Concepts のドキュメントを読むまで判断を保留すべき部分だ。
aigw run で始める最短経路と Kubernetes 経路
ラップトップ上で試す場合、README が示すコマンドは一行である。
OPENAI_API_KEY=sk-your-key aigw run
起動後、OpenAI 互換のクライアントを http://localhost:1975/v1 に向ける。ポート番号 1975 が既定である点は設定を書く前に把握しておきたい。プロバイダの自動構成については CLI ガイド、Kubernetes 上で Envoy Gateway と組み合わせる手順は Getting Started ガイドに分かれている。
ここで注意したいのは、この一行が動く前提だ。aigw バイナリがインストールされている必要があり、その手順は CLI ガイド側にある。README にはインストールコマンドが載っていないので、環境変数を渡せば何もなく動くという意味ではない。また aigw run はスタンドアロンのルータとして動作するモードであり、Kubernetes 上の CRD ベースの構成とは別物である。検証のためにローカルで試した設定をそのまま本番のマニフェストに持ち込めるわけではない。
Kubernetes 側では Envoy Gateway が前提となり、AIGatewayRoute や AIServiceBackend といった CRD を適用する形になる。README はどの CRD をどの順で適用するかまでは示していない。
対応プロバイダの一覧が示すものと示さないもの
README の表には OpenAI、Azure OpenAI、Google Gemini、Vertex AI、AWS Bedrock、Mistral、Cohere、Groq、Together AI、DeepInfra、DeepSeek、Hunyuan、SambaNova、Grok、Tetrate Agent Router Service、Anthropic が並ぶ。ホスト型の商用 API が中心で、これに自前推論と MCP サーバが加わる構成だと説明されている。
一覧は「接続できる」ことの証拠にはなるが、「同じように動く」ことの証拠にはならない。プロバイダごとに認証方式もストリーミングの挙動も異なる。どの差分が BackendSecurityPolicy で吸収され、どの差分が利用側のコードに漏れるのかは、この表からは分からない。特に Anthropic や Google Gemini のように OpenAI とは API 形状が異なるプロバイダを OpenAI 互換に変換する場合、変換層で落ちるパラメータが必ず出る。README はその互換性の範囲を明示していない。
プロバイダを選ぶ際は、表に名前があるかどうかではなく、自分のユースケースで使うパラメータが変換後も維持されるかを個別に確かめるべきである。
Envoy に寄せる設計が向かない場面
このプロジェクトの中核は「Agent Router controls. Envoy carries.」という分担にある。制御は Agent Router が持ち、実際のトラフィックは Envoy が運ぶ。つまりデータパスは Envoy であり、Envoy Gateway の運用知識が前提になる。
これが制約になるのは、Envoy を既に使っていない組織だ。Gateway API や Envoy の設定体系を新たに学ぶコストが、LLM ルーティングを一本化する利益に上乗せされる。マネージドの API ゲートウェイで足りている小規模構成では、CRD を増やす分だけ運用対象が広がる。
もうひとつの限界は、README が想定するスコープの外側だ。プロンプトの内容に基づくガードレール、レスポンスの評価、コスト最適化のためのモデル自動選択といった機能は、この README には記述がない。レート制限はグローバルなものとして Tier One の役割に挙げられているが、トークン数ベースの課金制御ができるのかは読み取れない。LLM ゲートウェイに課金や監査の機能まで期待するなら、候補として不十分な可能性がある。
さらに、プロジェクトの最終更新は 2026-09-10、最新リリースは v1.1.0（2026-08-21）である。リリースは v1.0.0 が 2026-06-23、v1.1.0 が約二ヶ月後。活発ではあるが、後述するようにメジャー番号はまだ 1 で、API の安定性を長期で保証する段階とは言い切れない。
代替手段との分かれ目はデータパスの所有権
同じ問題を解く方法として、アプリケーション側の SDK でプロバイダを切り替える実装がある。LiteLLM のようなライブラリを各サービスに組み込めば、ゲートウェイを立てずに複数プロバイダを扱える。違いは制御点の位置だ。SDK 方式ではクレデンシャルとレート制限が各アプリケーションに分散する。Agent Router はそれを Envoy 側の一箇所に集める。アプリケーションの言語やフレームワークが混在しているほど、後者の利点は大きくなる。逆に単一のサービスしか LLM を呼ばないなら、SDK 方式のほうが構成要素が少ない。
もうひとつの比較対象は、Envoy Gateway をそのまま使う方法である。Envoy Gateway 自体は汎用のゲートウェイであり、拡張フィルタを書けば LLM 向けのルーティングも実装できる。Agent Router はその作業を CRD としてパッケージ化したものだと位置づけられる。独自のフィルタを保守する覚悟があるなら素の Envoy Gateway でも成立するが、モデル名のマッピングやプロバイダ認証の変換を自前で書き続けることになる。
どちらを選ぶかは、LLM 固有のルーティングロジックを自分たちの資産として持つか、プロジェクトに委ねるかの判断に帰着する。
Apache-2.0 と改名に伴う確認事項
ライセンスは Apache-2.0 で、改名後も維持されると README は述べている。旧 Envoy AI Gateway 時代と同じライセンスであり、名称変更に伴うライセンス条件の変更は説明されていない。ただしこれは README の記述であって、リポジトリの LICENSE ファイルや各リリースの表記を確認したわけではない。導入前にリポジトリ直下のライセンス表記と、依存する Envoy 本体および Envoy Gateway のライセンスを自組織のポリシーに照らして確認する必要がある。ここで法的な助言はできない。
保守コストの観点では、改名は一見無害だが、追跡すべき情報源が増えている。リポジトリは theagentrouter/agent-router に移り、ウェブサイトは theagentrouter.ai になった。社内のドキュメントや CI に旧 URL を直接書いている場合、リダイレクトに依存することになる。リダイレクトがいつまで維持されるかは README に記載がない。
アップグレードの頻度は v1.0.0 から v1.1.0 まで約二ヶ月で、リリースケイデンスは変わらないとされている。Envoy Gateway 本体のバージョンとの整合を取る必要があるため、Agent Router だけを更新する運用は現実的でない。Kubernetes のコントロールプレーンを動かすチームにとっては、CRD の更新と Envoy Gateway の更新を一組として扱う計画が要る。
編集部の結論
Kubernetes 上で複数の LLM プロバイダと自前推論をひとつの OpenAI 互換エンドポイントにまとめ、クレデンシャルとクォータを Envoy 側で集中管理したいプラットフォームチームには向く。単一プロバイダしか使わず、Envoy Gateway を既に運用していないチームには、導入する理由が薄い。最初に確認すべきは、Tier One と Tier Two のどちらを今回構築するのか、既存マニフェストが使う API グループ aigateway.envoyproxy.io が現在の配布物でも同一か、そして v1.0.0 から v1.1.0 の間に CRD のスキーマ変更がなかったかである。
コミュニティノート