Agent Routerは、Envoy Proxy と Envoy Gateway の上で動くオープンソースのAIゲートウェイです。2026年9月10日にEnvoyのサブプロジェクトから離れ、Linux Foundation傘下のAgentic AI Foundation（AAIF）のプロジェクトになりました。名前は新しく見えますが、実体は旧Envoy AI Gatewayそのもので、CRDもAPIグループも据え置かれたままです。この記事では、改称で動いた範囲、Kubernetes 1.32以上という前提条件、helmでの導入手順、MCPRouteでエージェントに見せるツールを絞り込む書き方を、公式ドキュメントの記述に当たって整理します。名前がよく似たagentgatewayや同名の別サービスとの見分け方、採用する条件と見送る線まで引きます。
まとめ：Agent Routerの位置づけと移行で変わらない3点
Agent Routerは、アプリとモデル・ツールの間に置く1枚のゲートウェイです。開発者側にはOpenAI互換のエンドポイントを1つだけ見せ、その裏で16社のモデルプロバイダーとMCPサーバー群に振り分けます。認証、トークン使用量の制限、プロバイダー間のフェイルオーバーは、アプリのコードではなくKubernetesのカスタムリソースで宣言します。
移行で押さえる点は3つです。第1に、改称はドキュメントと配布物の呼称だけで、AIGatewayRoute・AIServiceBackend・BackendSecurityPolicy と aigateway.envoyproxy.io APIグループは変わりません。既存クラスタのマニフェスト修正は不要です。第2に、コードとメンテナー体制も継続しており、v1.0.0のGAは2026年6月23日、直近のv1.1.0は2026年8月21日と、改称の前後でリリースの流れは途切れていません。第3に、同じAAIFの傘下にagentgatewayという別のゲートウェイがあり、無関係の同名サービスも存在するため、情報はドキュメントのドメインとCRD名で当たりを付けます。
導入の下限はKubernetes 1.32とEnvoy Gateway 1.8.1。この2つを満たせないクラスタでは選択肢に入りません。
Envoy AI Gatewayから改称した経緯とAAIF移管で変わる範囲
改称の告知は公式ブログに2026年9月9日付で掲載され、移管日は翌9月10日です。Envoyのサブプロジェクトという立ち位置から、AAIFのスタンドアロンプロジェクトへ移りました。狙いはエージェント系エコシステムへの接近で、技術的な作り替えではありません。
2026年9月10日の移管で変わった名前と据え置かれた3つのCRD
公式ブログは、この移行を「Same code. Same maintainers.」と書いています。実務で効くのは後方互換の範囲です。改称の告知ページには、デプロイ済みリソースの名前は変えない、CRDとAPIグループは現状のまま、と明記されています。対象は AIGatewayRoute、AIServiceBackend、BackendSecurityPolicy の3つと、aigateway.envoyproxy.io というAPIグループです。
配布物も同じで、Helmチャートは oci://docker.io/envoyproxy/ai-gateway-helm のままです。名前空間の既定値も envoy-ai-gateway-system が使われます。運用中のクラスタがあっても、改称に合わせてやることはありません。読み替えが要るのはドキュメントと検索のときだけです。マニフェストの envoyproxy という文字列を見て「古い情報を掴んだ」と判断すると誤ります。
Bloomberg・Tencent Cloud・Nutanixが本番で使う実績
プロジェクトはBloombergとTetrateのエンジニアが立ち上げました。AAIFのプロジェクトページには、本番環境での利用者としてBloomberg、Tencent Cloud、Nutanixが挙がっています。ライセンスはApache 2.0です。
採用判断で見るのはリリースの刻みです。リリースノートによると、v0.7.0が2026年6月4日、v1.0.0のGAが6月23日、v1.1.0が8月21日。GAの時点で16のLLMプロバイダー、MCPゲートウェイ、マルチモーダルと音声のエンドポイントが揃い、コントロールプレーンAPIに安定性の保証が付きました。GAから3か月でマイナー1本という刻みは、設定を毎月書き換える段階を抜けた後の速度です。
モデル接続とMCP接続を1つの入口に束ねるAgent Routerの構成
Agent Routerが引き受けるのは2系統の通信です。モデルへの推論リクエストと、MCPサーバーへのツール呼び出し。どちらもEnvoy Proxyのデータプレーンを通り、ポリシーはEnvoy Gatewayの拡張として宣言します。
OpenAI互換APIで16プロバイダーを1つのエンドポイントに寄せる
モデル側の入口はOpenAI互換です。GitHubリポジトリが挙げる対応プロバイダーは、OpenAI、Azure OpenAI、Google Gemini、Vertex AI、AWS Bedrock、Anthropic、Mistral、Cohere、Groq、Together AI、DeepInfra、DeepSeek、Hunyuan、SambaNova、Grok、Tetrate Agent Router Serviceの16社です。AnthropicのリクエストをAWS Bedrock向けに変換する機能はv0.7.0で入りました。
プロバイダーを1社つなぐ手順は、公式のサンプルをそのまま適用する形です。OpenAI接続のドキュメントは、テンプレートを取得してAPIキーを差し替え、適用してcurlで叩くところまでを示しています。
curl -O https://raw.githubusercontent.com/theagentrouter/agent-router/main/examples/basic/openai.yaml
# openai.yaml の OPENAI_API_KEY を実際のキーに置き換える
kubectl apply -f openai.yaml
curl -H "Content-Type: application/json" \
-d '{"model": "gpt-4o-mini", "messages": [{"role": "user", "content": "Hi."}]}' \
$GATEWAY_URL/v1/chat/completionsモデルの差し替えは、リクエストの model フィールドの値か、ゲートウェイ側のルーティング規則の書き換えで済みます。SDKの入れ替えもクライアント側の分岐も要りません。
aigw runで60秒で動かすローカル起動とlocalhost:1975
評価だけならKubernetesは不要です。CLIの aigw をスタンドアロンで起動すると、ローカルにOpenAI互換のエンドポイントが立ちます。
OPENAI_API_KEY=sk-your-key aigw run
# http://localhost:1975/v1 でOpenAI互換のエンドポイントが応答するポートは1975。技術選定の初手としては、この段階で自社アプリのSDKをエンドポイントだけ差し替えて動くかを確かめるのが早道です。動かないSDKがあれば、Kubernetesの構築に入る前に分かります。
Kubernetes環境への導入手順とv1.1.0で追加された機能
クラスタへ入れる場合は、Envoy Gatewayを土台にして、その上にAgent Routerのコントローラを載せます。直近のv1.1.0では、トークン数の計測、リクエスト単位の認証情報、ストリームのアイドルタイムアウト、MCPのホスト名ルーティングが加わり、OpenTelemetryのGenAIトレーシングにも対応しました。使用量をチーム単位で見る構成なら、v1.1.0以降が前提です。
Kubernetes 1.32とEnvoy Gateway 1.8.1という前提条件
公式の前提条件は、Kubernetes 1.32以上とEnvoy Gateway 1.8.1以上です。ツールはkubectl、helm、curlの3つで、バージョンの下限は指定されていません。
詰まるのは、たいてい既存クラスタの側です。自社クラスタが何番で、いつEOLを迎えるかはKubernetesの最新バージョンと確認方法をまとめた記事で先に押さえておくと、導入可否の判断が1回で終わります。Envoy Gateway側も1.8.1という下限があり、Gateway APIのリソースを既に運用している環境ではアップグレードの調整が入ります。
helmでCRDと本体を分けて入れる2段構えのインストール手順
インストールは、CRDのチャートとコントローラのチャートを順に入れる2段構えです。インストール手順が示すコマンドは次のとおりです。
helm upgrade -i aieg-crd oci://docker.io/envoyproxy/ai-gateway-crds-helm \
--version v0.0.0-latest \
--namespace envoy-ai-gateway-system \
--create-namespace
helm upgrade -i aieg oci://docker.io/envoyproxy/ai-gateway-helm \
--version v0.0.0-latest \
--namespace envoy-ai-gateway-system \
--create-namespace
kubectl wait --timeout=2m -n envoy-ai-gateway-system \
deployment/ai-gateway-controller --for=condition=Available注意点が2つあります。--version v0.0.0-latest は開発版を指す可変タグなので、本番クラスタではリリースノートで確認した番号に固定して運用するのが原則です。もう1つは、旧構成から上げるときにCRDの所有権をCRDチャート側へ移す必要がある点で、その場合は --take-ownership を付けた helm upgrade を先に実行します。この順番を逆にすると、コントローラのチャートがCRDを掴んだままになり、以降のCRD更新が通らなくなります。
MCPゲートウェイでツールを絞り込むMCPRouteの書き方と認証
もう一方の系統がMCPです。MCPはAIと外部ツールをつなぐ標準規格で、AAIFがホストするプロジェクトの1つでもあります。Agent RouterのMCPゲートウェイはStreamable HTTPトランスポートに対応し、2025年6月版のMCP仕様に沿って、ステートフルなセッションと複数パートに分かれたJSON-RPCメッセージを扱います。
toolSelectorで公開するツールを正規表現で限定する設計
MCPサーバーの公開は MCPRoute というカスタムリソースで宣言します。MCPゲートウェイのドキュメントに載っている構成は次の形です。
apiVersion: aigateway.envoyproxy.io/v1beta1
kind: MCPRoute
metadata:
name: mcp-route
namespace: default
spec:
parentRefs:
- name: aigw-run
kind: Gateway
path: "/mcp"
backendRefs:
- name: github
kind: Backend
toolSelector:
includeRegex:
- .*issues?.*
securityPolicy:
apiKey:
secretRef:
name: github-token効きどころは toolSelector です。バックエンドのMCPサーバーが数十のツールを持っていても、正規表現に一致したものだけがクライアントに見え、上の例ではissue系だけが通ります。エージェントに渡すツール定義はそのままコンテキストを消費するため、公開範囲を絞る設計はトークン単価にも影響する要素です。クライアント側での扱いはMCP Appsのサンドボックス実装を解説した記事と合わせて見ると、サーバー側で絞る設計との分担が掴めます。
APIキーとOAuthの使い分けとforwardHeadersの注意点
認証は securityPolicy の下で切り替えます。apiKey はSecretを参照する共有トークン方式、oauth はPKCE付きの認可コードフローです。加えて forwardHeaders でクライアントから来たヘッダを個別に転送でき、JWTのスコープやクレームによるアクセス制御も組めます。
分け方の基準は、監査の単位をどこに置くかです。社内のバッチが1つのGitHubトークンで動く構成なら apiKey で必要な認証をまかなえる構成です。誰がどのツールを呼んだかをMCPサーバー側のログで追うなら、共有トークンでは追跡できないので oauth か forwardHeaders を選びます。共有トークンで通すと、後から利用者単位の権限を入れる段でMCPサーバー側の設計をやり直す羽目になります。
名前が似たagentgatewayなど3製品との違いと選び分けの境界
このジャンルは名前の衝突が起きています。調べ物の前に、どれを見ているのか固定しておく必要があります。
同じAAIF傘下のagentgatewayと役割が重なる部分
AAIFのプロジェクト一覧には、Model Context Protocol、goose、AGENTS.md、agentgateway、Agent2Agent（A2A）、Agent Routerの6つが並びます。つまりagentgatewayとAgent Routerは、同じ財団の下にある別プロジェクトです。
agentgatewayはSolo.ioが開発して寄贈したもので、MCP、A2A、LLMの3系統に加えてHTTPとgRPCのトラフィックも単一のデータプレーンで扱います。Agent RouterはEnvoy ProxyとEnvoy Gatewayを土台にし、Gateway APIのCRDとして構成を書きます。
選び分けの線ははっきりしています。Envoy GatewayでIngressを既に運用しているなら、同じコントロールプレーンに乗せられるAgent Routerを選びます。LangChainやCrewAIのエージェント同士をA2Aで呼び合わせる構成が主役なら、A2Aを一等市民として扱うagentgatewayが素直です。両方を並べる構成は、Envoyの設定が二重になるだけなので採りません。
agent-router.orgのAgentRouterは別物という見分け方
検索で最も混ざりやすいのが agent-router.org のAgentRouterです。こちらはTim Brauer氏が公開しているMCPベースの委譲プラットフォームで、MCPのURLを1本追加すると800以上の専門エージェントがツールとして現れる、というSaaSです。OSSのゲートウェイではなく、Claude DesktopやCursorから使うサービス側の製品に当たります。
見分け方は3つ。公式サイトは theagentrouter.ai、リポジトリは github.com/theagentrouter/agent-router、マニフェストのAPIグループは aigateway.envoyproxy.io。どれかが一致しなければ別の製品なので、設定例をコピーしても動きません。
Agent Routerを採用する条件と受託開発で見送ると決める場面
ゲートウェイを1枚挟むと、アプリのコードは軽くなる代わりにKubernetesの運用対象が2つ増えます。割に合う規模の境目を条件で示します。
複数のモデルとMCPサーバーを1か所で束ねる構成で効く採用条件
次の条件のうち3つ以上が当てはまるなら、導入する価値があります。
- モデルプロバイダーを2社以上使い、障害時に切り替えたい
- MCPサーバーを複数のチームやアプリに公開し、見せるツールを相手ごとに変えたい
- トークン使用量をチーム単位・アプリ単位で計測し、上限をかけたい
- Envoy GatewayまたはGateway APIを既に運用しており、コントロールプレーンを共有できる
- モデルの呼び出し口を1つに寄せて、監査ログを集約したい
裏を返せば、これらはアプリ側に散らばると保守が効かなくなる関心事です。どのモデルにどれだけ投げたかを追えない構成は、費用の内訳を説明できなくなった時点で見直しになります。社内の生成AI基盤をこれから設計する段階なら、生成AI導入支援のように、ゲートウェイの要否を含む構成の選定から相談できる体制で進めるほうが後戻りは小さく済みます。
単一プロバイダーの小規模構成でAgent Routerを見送る線
使うモデルがOpenAIの1社だけで、呼び出すアプリも1本。この構成では採用しません。Kubernetes 1.32とEnvoy Gateway 1.8.1を満たすクラスタを用意し、Helmチャート2本の更新を追い続けるコストが、公式SDKにリトライとタイムアウトを書く手間を上回ります。ローカルの aigw run で試したうえで、そのまま使わない判断をして構いません。
もう1つの典型が、フェイルオーバーだけを目当てに入れるケースです。OpenAI互換の入口に寄せても、プロバイダーごとにツール呼び出しの形式、コンテキスト長、ストリーミングの挙動は揃いません。切り替え先で出力の質が落ち、結局1社に固定して戻す展開になりがちです。この目的で選ぶなら、切り替え先のモデルで主要なプロンプトが通ることを先に検証し、その検証を回し続ける体制まで込みで判断します。
よくある質問
Agent Routerの導入判断でよく出る5つの疑問に、公式ドキュメントの記述をもとに答えます。
Envoy AI Gatewayで作ったマニフェストはそのまま動きますか？
動きます。改称の告知に、デプロイ済みリソースのリネームは行わないと明記されています。3つのCRDと aigateway.envoyproxy.io というAPIグループは据え置きで、HelmチャートのOCIパスも docker.io/envoyproxy/ 配下のままです。変わったのは製品名の表記とドキュメントの置き場所だけになります。
同じAAIFのagentgatewayとどちらを選べばよいですか？
土台に合わせて決めます。Envoy GatewayでIngressを運用しているなら、Gateway APIの拡張として乗るAgent Routerが一本化しやすい構成です。エージェント同士のA2A通信をルーティングの中心に据えるなら、A2Aを正面から扱うagentgatewayが向きます。どちらもAAIFがホストする別プロジェクトで、統合の予定は公開されていません。
Kubernetesを用意せずに試せますか？
試せます。CLIを aigw run で起動すると、localhost:1975/v1 にOpenAI互換のエンドポイントが立ちます。環境変数にAPIキーを渡すだけで、クラスタもHelmも不要です。ただしトークン制限やMCPRouteによるツールの絞り込みはKubernetes上のカスタムリソースで宣言するため、本番相当の検証にはクラスタが要ります。
本番で使うならどのバージョンを選べばよいですか？
v1.0.0以降です。2026年6月23日のv1.0.0で一般提供となり、コントロールプレーンAPIに安定性の保証が付きました。使用量の計測やOpenTelemetryのGenAIトレーシングを使うなら、2026年8月21日のv1.1.0が下限です。公式手順の --version v0.0.0-latest は可変タグなので、本番では番号を固定して運用します。
MCPサーバーごとに見せるツールを変えられますか？
変えられます。MCPRoute の backendRefs ごとに toolSelector を書き、includeRegex に正規表現を並べると、一致したツールだけがクライアントに公開されます。issue操作だけ、読み取りだけ、といった粒度での切り出しが可能です。認証も securityPolicy でバックエンド単位に指定できます。
関連記事
- MCP（Model Context Protocol）とは？AIと外部ツールをつなぐ標準規格の仕組みをわかりやすく解説：Agent RouterのMCPゲートウェイが前提にしているプロトコルそのものの定義と仕組み
- MCP Appsとは？サンドボックスiframeで動く対話型UI拡張の仕組みと採用判断：ゲートウェイで絞ったツールをクライアント側でどう見せるかの設計
- Kubernetesの最新バージョンは1.37｜確認方法・EOL一覧とアップグレード手順：前提条件のKubernetes 1.32以上を自社クラスタが満たすかの確認手順
