Agent Routerとは｜AAIF加盟のAIゲートウェイと法人の導入判断

「Claude を使うか GPT を使うか、部門ごとに違うんです。全部つなぎ直すの、もう無理じゃないですか」

研修や顧問の場で、この種の相談が増えました。営業部門は ChatGPT、開発部門は Claude、経営企画は Gemini。API キーは各部門が別々に持ち、請求書も別々に届く。あるモデルが値上げされても、乗り換えるにはアプリ側のコードを書き直さなければならない。しかも MCP サーバを社内ツールにつなぎ始めた途端、「誰がどのツールを呼べるのか」を管理する場所がどこにも無いことに気づく。生成 AI が「試す段階」から「基盤として運用する段階」に入った会社ほど、この壁にぶつかります。

この壁に対する業界の答えが「AI ゲートウェイ」で、その代表格だった Envoy AI Gateway が 2026年9月10日、Linux Foundation 傘下の AAIF（Agentic AI Foundation）に加わり「Agent Router」と名前を変えました。MCP・AGENTS.md・A2A と同じ団体が、モデルとツールへの「入口」そのものを標準化の対象にしたという意味で、法人の AI 基盤設計に直接影響する出来事です。

この記事では、公式発表・公式ドキュメント・GitHub の一次情報だけを根拠に、Agent Router の定義、改名で変わること・変わらないこと、主要機能と対応プロバイダの一覧、そして「自社に要るのか」「自社で立てるのか SaaS に任せるのか」の判断の型までを整理します。コピペで使えるプロンプトと、ローカルで試す手順も載せました。

Agent Routerとは｜旧Envoy AI GatewayがAAIFの正式プロジェクトになった

AAIF のプロジェクトページは Agent Router を「Envoy 上に構築されたオープンソースの AI ゲートウェイで、プラットフォームチームがアクセス・ルーティング・使用量を管理しながら、アプリケーションをモデルと MCP ツールに接続する」と説明しています（AAIF: Agent Router）。プロジェクトサイトの一言は「Integrate once. Switch models without rewriting.（一度つなげば、書き換えずにモデルを切り替えられる）」です。

発表の経緯（2026年9月）

時系列は次のとおりです。

プロジェクトの歩みも公開情報から追えます。GitHub のリポジトリは 2024年10月21日に作られ、Bloomberg と Tetrate の技術者が立ち上げました。2025年11月の v0.4.0 で MCP Gateway（MCPRoute CRD・Streamable HTTP・OAuth 2.0 認可・複数サーバの多重化）が入り、2026年6月23日の v1.0.0 で「安定した本番利用可能な AI ゲートウェイ」として一般提供、2026年8月21日の v1.1.0 が 1.x 系で最初のマイナーリリースです。v1.0 の発表では「重大なセキュリティ問題が無い限り API を壊さない」という互換性の約束が明文化されています。

規模の数字は次のとおりです（数値はいずれも 2026年9月16日に確認）。

• GitHub スター 2,099・フォーク 374（GitHub API・2026年9月16日時点）
• 公開されている採用組織は 11。Bloomberg・Tetrate・Tencent Cloud・Nutanix・LY Corporation（LINEヤフー）・National Research Platform など（AAIF ブログ）
• メンテナ席は 9 で、Bloomberg・Nutanix・AMD・Tetrate・Netflix に分散。貢献者は 21 組織・132 名（AAIF ブログ）
• v1.0 時点で対応プロバイダは 16（v0.1 の 2 から拡大・v1.0 リリース発表）

AAIF（Agentic AI Foundation）とは

AAIF は Linux Foundation 傘下の団体で、AI エージェント向けのオープンな技術と標準を共同開発する場です。gihyo.jp の記事によれば 2025年12月に設立されました。2026年9月時点でホストするプロジェクトは、AAIF のプロジェクト一覧ページによると Model Context Protocol（MCP）・goose・AGENTS.md・agentgateway・Agent2Agent（A2A）・Agent Router の 6 つです。プラチナメンバーには Amazon Web Services・Anthropic・Block・Bloomberg・Cloudflare・Google・Microsoft・OpenAI が名を連ね、Technical Committee の議長は MCP の共同開発者である Anthropic の David Soria Parra 氏です（AAIF About ページ）。

つまり「モデルとツールをつなぐ規格（MCP）」「エージェント同士をつなぐ規格（A2A）」「コーディングエージェントへの指示書式（AGENTS.md）」を持つ団体が、その通信が実際に通る「入口」のソフトウェアまで自分の傘下に置いたことになります。

「業界標準へ」をどう読むか

Publickey の見出しは「Linux Foundation 傘下で業界標準へ」ですが、正確に読むと 2 つの注意点があります。第一に、AAIF は 2026年6月4日に Solo.io が主導する agentgateway（MCP・A2A・LLM 推論・HTTP・gRPC に対応するゲートウェイ）も 4 番目のプロジェクトとして迎えており、AAIF 傘下のゲートウェイは 2026年9月時点で 2 つあります。「AAIF が唯一の標準ゲートウェイを決めた」わけではありません。第二に、Agent Router の強みは Envoy という実績ある通信基盤の上に載っていることで、Kubernetes を運用している会社ほど恩恵が大きい一方、Kubernetes を持たない会社には別の選択肢（後述の SaaS 型）が現実的です。

AAIF加盟で何が変わり、何が変わらないのか

すでに Envoy AI Gateway を使っている会社にとって最も重要なのは「移行作業が要るのか」です。メンテナのブログは「Same code. Same maintainers. New home.（同じコード、同じメンテナ、新しい所属）」と書き、変わる点と変わらない点を明示しています（Envoy AI Gateway is becoming Agent Router）。

実務上の結論は「既存のマニフェストはそのまま動く。ドキュメントのブックマークと社内手順書の URL・名称だけ書き換える」です。逆に言えば、名前が変わっただけで API 面の変化は無いので、「新しい製品が出た」と構えて評価をやり直す必要はありません。

Agent Routerの主要機能｜OpenAI互換API・MCP Gateway・トラフィック管理・可観測性

公式ドキュメントの Capabilities は、機能を LLM プロバイダ統合・推論最適化・ゲートウェイ設定・トラフィック管理・セキュリティ・MCP・可観測性の 7 分類で整理しています。法人視点で重要な順に並べ直すと次のとおりです。

1 本の API で全プロバイダを呼ぶ

対応エンドポイントは、公式の Supported Endpoints によると Chat Completions（POST /v1/chat/completions）・Anthropic Messages（POST /anthropic/v1/messages）・Completions・Embeddings・Responses（POST /v1/responses、MCP ツールと推論に対応）が「対応・テスト済み」で、画像生成・音声の書き起こしと翻訳・/tokenize・Cohere の rerank は部分対応または開発中です。モデル一覧は GET /v1/models で返ります。Anthropic 向けには /anthropic/v1/models も v1.1 で追加され、Claude 系クライアントがそのまま使えるようになりました。

MCP Gateway で認証を一か所に集める

公式ドキュメント（MCP Gateway）によれば、MCPRoute という CRD で複数の MCP サーバを backendRefs に並べると、それらが 1 つのエンドポイントに集約され、ツール名には「github__issue_read」のようにバックエンド名の接頭辞が自動で付きます。認可は MCP 仕様に沿った OAuth（issuer・audiences・protectedResourceMetadata）で、JWT のスコープやクレームに基づくアクセス制御、CEL 式による条件、ツール単位の Allow／Deny ルールが書けます。どのツールを公開するかは toolSelector の include（完全一致）または includeRegex（正規表現）で絞り込みます。トランスポートは 2025年6月版 MCP 仕様の Streamable HTTP に対応し、SSE 再接続のための Last-Event-ID もサポートします。v1.1.0 ではホスト名によるルーティングと CEL によるバックエンド選択が加わりました。

MCP をこれから本番に載せる会社は、仕様の企業向け要点を MCP 仕様刷新（2026年7月）で企業が確認すべき 3 点 で先に押さえておくと、MCPRoute の設定項目が何を守っているのかが読み取りやすくなります。

トラフィック管理｜フォールバック・モデル仮想化・トークン上限

フォールバックは AIGatewayRoute の backendRefs に priority（0 が主系、1 以降が待機系）を付けて優先順位を並べ、BackendTrafficPolicy のリトライ条件（接続失敗や 500 系など）で発火させます。主系が不健全になると次の健全なバックエンドへ自動で流れます。v1.1.0 ではストリーミング中のアイドルタイムアウトでもフォールバックするようになりました。

モデル名の仮想化は、同じ Claude Sonnet でも Vertex AI では「claude-sonnet-4@20250514」、Amazon Bedrock では「anthropic.claude-sonnet-4-20250514-v1:0」と名前が違う問題を、backendRefs の modelNameOverride で吸収する機能です。アプリは 1 つの仮想モデル名を使い続け、ゲートウェイが裏で実名に変換します。フォールバック先で安価なモデルに差し替える、といった使い方も公式ドキュメントに載っています。

トークン上限は 2 種類あります。QuotaPolicy はトークン総量の予算管理で、モデル単位、または clientSelectors で「x-tenant-id」などのヘッダー値ごと（チーム・アプリ単位）に上限を置き、超えると 429 Too Many Requests を返します。コストは CEL 式で「キャッシュ済み入力トークンは通常の 1/10、出力トークンは 6 倍」のように重み付けでき、変数は input_tokens・output_tokens・total_tokens・cached_input_tokens・cache_creation_input_tokens・reasoning_tokens です。期間は 1s・1m・1h・1d の固定値だけで「30s」「15m」のような任意倍数は使えません。テスト用に「決して強制しない」シャドウモードもあります。使用量ベースのレート制限は BackendTrafficPolicy 側で、ヘッダーの x-tenant-id（利用者）や x-ai-eg-model（モデル名）を単位に窓あたりの許容量を決めます。どちらも Redis の配置と Envoy Gateway 側のレート制限設定が前提です。

注意点として、公式ドキュメントは QuotaPolicy の serviceQuota（バックエンド全体の割当）を「まだ強制されない」、clientSelectors の sourceCIDR・methods・path・queryParams を「スキーマは受け付けるがまだ効かない」と明記しています。また、すでに受け付けたストリームは上限を超えても途中で切られず、完了後に使用量が計上されて次のリクエストから 429 になります。2026年9月時点では「ヘッダー単位の予算」が実装済みの範囲だと理解しておくのが安全です。

セキュリティ｜鍵をアプリから引き剥がす

上流の認証は BackendSecurityPolicy で扱い、API キーは Kubernetes の Secret に置いて管理者が管理します。クラウド ID を使う場合、AWS Bedrock は OIDC と STS による一時クレデンシャル、Azure OpenAI は Entra ID の短命トークン、GCP Vertex AI はワークロード連携と Google STS を使う、と公式の Upstream Authentication に書かれています。v1.1.0 の credentialOverride を使うと、信頼済みフィルタからリクエストごとに上流の認証情報を供給することもできます。アプリケーションのコードや環境変数に各社の API キーをばらまかなくて済むのが、ガバナンス上の最大の利点です。

可観測性｜誰がどのモデルにいくら使ったか

公式の Metrics ページによれば、OpenTelemetry の GenAI セマンティック規約に沿って gen_ai.client.token.usage（トークン数・入力／出力／合計の区別）、gen_ai.server.request.duration、gen_ai.server.time_to_first_token、gen_ai.server.time_per_output_token の 4 系統を収集し、属性として操作名・要求モデル・実際に応答したモデル・プロバイダ名が付きます。Prometheus へ出力でき、v1.1.0 で GenAI 規約のトレーシングも任意で有効化できます。「部門別のトークン消費」を出す材料が、アプリ側に手を入れずに揃うということです。

対応プロバイダとAPIエンドポイントの一覧

公式の Supported Providers ページに載る主なプロバイダは次のとおりです。Publickey の記事が挙げた 17 の接続先（16 社とセルフホスト）と一致します。

エンドポイント別のプロバイダ対応（公式表の抜粋）では、Chat Completions は OpenAI・AWS Bedrock・Azure OpenAI・GCP Vertex AI・Anthropic・vLLM のすべてで対応済み、Embeddings は Anthropic 以外で対応済み、Anthropic Messages は OpenAI と Anthropic で対応済み、/tokenize は GCP Vertex AI と vLLM で対応済みです。

動作要件は互換性表で確認できます。v1.1.x は Envoy Gateway v1.8.1 以上（Envoy Proxy v1.38.x）・Kubernetes v1.32 以上・Gateway API v1.5.x が検証済みの組み合わせで、v1.0.x も同じ要件です（公式 Compatibility ページ）。

法人の生成AIガバナンスにどう効くか｜ロックイン回避・コスト管理・監査

ここからが本題です。Agent Router の機能を、法人が生成 AI で必ず突き当たる 3 つのガバナンス課題に対応させます。

課題 1｜ベンダーロックイン：モデルをアプリ側で書き換えずに切り替える

モデルの価格改定・提供終了・性能逆転は、2026年に入ってからも数か月単位で起きています。切り替えのたびにアプリのコードを直していると、切り替え自体をあきらめる会社が出てきます。Agent Router を挟むと、アプリは OpenAI 互換の 1 形式と仮想モデル名だけを知っていればよく、実際にどの会社のどのモデルへ流すかはゲートウェイ側の設定（AIServiceBackend と modelNameOverride）で決まります。フォールバックを併用すれば「主系が落ちたら別会社のモデルへ」も自動です。抽象化の選択肢全体は AI ベンダーロックイン回避戦略｜抽象化レイヤー 7 パターン で比較していますが、Kubernetes 上でネットワーク層の抽象化を取りたい会社にとって、財団がホストする Agent Router は有力な 8 番目の選択肢になりました。

課題 2｜MCP の本番運用：認証と権限を一か所に集める

MCP サーバは便利な反面、「社内の DB・チケット・ドキュメントにエージェントが直接触る」仕組みです。サーバごとに API キーを配り、ツールごとの可否を各アプリで判断していると、誰がどのツールを呼べるのかを後から説明できません。MCPRoute で全 MCP サーバを 1 つの入口に集め、OAuth と JWT のスコープでアクセス制御を掛け、toolSelector で公開ツールを絞り、ツール単位の Allow／Deny を書く。この一か所化が「MCP の監査可能性」を作ります。ツール名にバックエンド名の接頭辞が自動で付くので、ログを見れば「どのサーバのどのツール」が一目で分かるのも実務では効きます。

課題 3｜コスト管理と部門課金：チームごとのトークン上限

生成 AI のコストは「気づいたら月末に膨らんでいた」型の事故が多く、原因はたいてい一部のアプリや部門の暴走です。QuotaPolicy でヘッダー（x-tenant-id など）単位に予算を置けば、部門・アプリごとの上限を基盤側で強制できます。メトリクスは部門・モデル別のトークン消費として Prometheus に出るので、月次の按分と請求書の突き合わせが機械的にできます。上限に達したときの 429 をアプリがどう扱うか（待つ・安価なモデルへ落とす・利用者に知らせる）は、導入前に決めておく必要があります。

ゲートウェイ自体が重要インフラになる、という裏面

忘れてはいけないのは、全部の AI 通信が通る場所を 1 つ作るということは、そこが落ちれば全部止まり、そこが乗っ取られれば全部の鍵が漏れる、という裏面です。2026年3月に起きた LiteLLM のサプライチェーン攻撃 は、まさに「ゲートウェイの依存パッケージ」が狙われた事件でした。だからこそ、単一企業の製品ではなく、Linux Foundation 傘下の財団がガバナンスし、メンテナ席が 5 社に分散し、Apache 2.0 で誰でも監査できる Agent Router のような選択肢に意味があります。財団加盟は「ブランドが変わった」話ではなく、「自社の重要インフラの供給元をどこに置くか」の話として読むべきです。

まず自社の現状を棚卸しするプロンプトです。ChatGPT・Claude・Gemini のどれでも動きます。

あなたは企業の生成AI基盤を設計する情報システム部門のアドバイザーです。
以下の情報をもとに、当社に「AIゲートウェイ（Agent Router のような OpenAI 互換の単一 API・MCP 集約・トークン上限を持つ基盤）」が必要かどうかを判定してください。

【利用状況】
- 利用中の AI ベンダーとモデル: {例: OpenAI GPT-5、Anthropic Claude、Google Gemini}
- 利用している部門とおおよその人数: {例: 営業 40 名、開発 15 名、CS 30 名}
- API キーの管理方法: {例: 各部門が個別に保有}
- MCP サーバの利用: {例: 社内 DB 接続 2 本を検証中／本番は未定}
- Kubernetes の運用チーム: {あり／なし}
- 月間の AI 利用料の概算: {分かる範囲で・不明なら「不明」}

【出力】
1. 必要性の判定（要る／今は要らない／SaaS 型で十分）と理由を 3 行以内
2. 判定の根拠になった項目と、逆の判定になる条件
3. 判定に足りない情報があれば質問を 3 つまで

注意: 分からない数値は推測せず「不明」と書き、根拠のない数字を作らないでください。

導入判断の型｜Agent Routerが要る会社・要らない会社

判断は「機能が良いか」ではなく「自社の状況に当てはまるか」で決めます。次のチェックリストで 2 つ以上に該当するなら、AI ゲートウェイの導入検討に進む価値があります。

「要る」寄りが多くても Kubernetes の運用チームが無い場合は、次の節の SaaS 型（Tetrate Agent Router Service や OpenRouter）を先に検討してください。逆に「要らない」寄りが多くても、MCP を本番に載せる計画が具体化した時点で再判定するのが現実的です。

MCP の本番運用を判断する前に、社内の MCP サーバを棚卸しするプロンプトです。

社内で利用中・検証中の MCP サーバを棚卸しし、AI ゲートウェイの MCPRoute で集約する前提の一覧表を作ってください。

【入力】（1 行 1 サーバで貼り付け）
{サーバ名 / 接続先システム / 提供するツール名 / 認証方式 / 利用部門 / 本番か検証か}

【出力の列】
サーバ名｜接続先｜ツール数｜読み取り専用か書き込みありか｜認証方式（OAuth／APIキー／なし）｜利用部門｜公開範囲の推奨（全社／部門限定／禁止）｜理由

【ルール】
- 書き込みを伴うツールは「部門限定」以上を推奨し、理由に「書き込みあり」と明記する
- 認証方式が「なし」のサーバは「本番投入不可」と表示する
- 入力に無い情報は「未記載」とし、推測で埋めない

自社で立てるか、SaaS型ゲートウェイに任せるか

AI ゲートウェイには「自社で立てる OSS」と「他社が運用する SaaS」の 2 系統があり、Agent Router は前者の代表です。同じ系統に AAIF の agentgateway や LiteLLM があり、後者には OpenRouter や Tetrate Agent Router Service があります。

判断の軸は 3 つです。第一に「通信と鍵を自社の境界の内側に置く必要があるか」（規制業種・機密データなら自社運用寄り）。第二に「Kubernetes を運用できるか」（できないなら SaaS 寄り）。第三に「MCP を本番で何本つなぐか」（多いほど MCPRoute のツール単位の認可が効く）。SaaS 型は初期の速さで勝ち、OSS 型は本番の統制で勝つ、と覚えておくと迷いません。

なお、検索で「Agent Router」と入れると、Tetrate のホスト型サービスや、無料クレジットの配布をうたう同名・類似名の別サービスが並びます。この記事で扱う AAIF の Agent Router は Apache 2.0 の OSS で、クレジット配布や会員登録の仕組みはありません。社内で稟議を書く時は「AAIF がホストする OSS の Agent Router（旧 Envoy AI Gateway）」と書き分けてください。

自社運用と SaaS の比較表を、自社の条件で作るプロンプトです。

AI ゲートウェイの「自社運用（OSS の Agent Router を Kubernetes 上で運用）」と「SaaS 型（ホスト型のゲートウェイを利用）」を、当社の条件で比較する表を作ってください。

【当社の条件】
- 扱うデータの機密区分: {例: 顧客個人情報を含む／含まない}
- 適用される規制・監査: {例: ISMS 取得済み、金融の委託先管理あり／特になし}
- Kubernetes の運用体制: {例: SRE 2 名で運用中／なし}
- 併用する AI ベンダー数: {例: 3 社}
- 本番で接続予定の MCP サーバ数: {例: 4 本}
- 想定利用者数: {例: 全社 500 名}

【比較の行】
初期構築の工数／月次の運用工数／通信と鍵の所在／MCP のツール単位の認可／部門別の上限管理／障害時の責任分界／将来の乗り換えやすさ

【出力】
- 各行を「自社運用」「SaaS 型」の 2 列で比較し、当社条件に照らした推奨を最後に 1 つ
- 工数の数字は「当社条件からの推定」と明記し、根拠を併記する。根拠が無い場合は「要見積」と書く

導入の最短手順｜ローカル検証からKubernetes本番まで

手順 1｜ローカルで試す

公式の Getting Started には、CLI の aigw を使って手元のマシンでスタンドアロンのプロキシとして動かす手順があります（公式は「60 秒で」と案内・対応 OS は Linux と macOS）。OpenAI の API キーを環境変数に入れて起動します。

OPENAI_API_KEY=sk-your-key aigw run

起動後は localhost の 1975 番ポートに OpenAI 互換のエンドポイントが立ちます。公式のサンプルリクエストは次のとおりです。

curl http://localhost:1975/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "gpt-5", "messages": [{"role": "user", "content": "Say this is a test!"}]}'

公式ドキュメントは「OpenAI SDK と同じ環境変数で自動設定される」「Ollama・vLLM・MCP サーバにも接続できる」と説明しています。ただし CLI は「実験的で開発中」と明記されているので、ローカル検証用と割り切ってください。

手順 2｜Kubernetes に載せる

本番は Envoy Gateway 上のコントロールプレーンとして動かします。前提は互換性表のとおり Envoy Gateway v1.8.1 以上・Kubernetes v1.32 以上・Gateway API v1.5.x です。インストールの具体的なコマンドとチャート名は公式 Getting Started の Installation ページに版ごとの記載があるので、そのまま使ってください（この記事では版で変わるコマンドを転記しません）。

手順 3｜設定を「4 つの CRD」で組む

設定は主に次の CRD で組みます。フィールド名はいずれも公式ドキュメントに記載のものです。

• AIServiceBackend: 接続先のプロバイダ（OpenAI・Bedrock・Vertex AI など）を定義する
• BackendSecurityPolicy: 上流の API キーやクラウド ID をゲートウェイ側で管理する
• AIGatewayRoute: backendRefs に priority 順でバックエンドを並べ、modelNameOverride で仮想モデル名を実名に変換し、llmRequestCosts でトークン種別をメタデータに書き出す
• MCPRoute: MCP サーバを backendRefs に並べ、toolSelector の include または includeRegex で公開ツールを絞り、securityPolicy で OAuth や API キーを掛ける

上限管理は QuotaPolicy と BackendTrafficPolicy を追加し、Redis を配置して Envoy Gateway のレート制限を有効にします。メトリクスは OpenTelemetry 経由で Prometheus に出し、gen_ai.client.token.usage をプロバイダ・モデル・テナント別に集計すれば、部門別の月次レポートの材料になります。

導入後の部門別トークン予算を設計するプロンプトです。

AI ゲートウェイの QuotaPolicy で部門ごとのトークン上限を設計します。以下の情報から、部門別の月間予算案と上限到達時の運用ルールを作ってください。

【入力】
- 部門と人数: {例: 営業 40 名、開発 15 名、CS 30 名}
- 各部門の主な用途: {例: 営業＝提案書下書き、開発＝コード生成、CS＝問い合わせ要約}
- 直近 3 か月の部門別トークン消費（分かれば）: {入力／出力を分けて}
- 会社全体の月間予算の上限（円）: {数値}
- 使用するモデルの単価（公式料金表から転記）: {入力／出力それぞれ}

【出力】
1. 部門別の月間トークン上限（入力・出力を分けて）と、その根拠となる計算式
2. 期間の単位（QuotaPolicy で使える 1s・1m・1h・1d のどれを使うか）と理由
3. 上限到達（429）時の運用ルール案を「待つ／安価なモデルへ切替／利用者に通知」の 3 案で
4. 予算案の前提（単価の出典・為替・想定利用日数）を箇条書きで

注意: 単価は入力された公式料金表の値だけを使い、推測の単価で計算しないでください。

【要注意】導入でつまずく失敗パターン

研修や相談の場で見かける、AI ゲートウェイ導入の典型的なつまずき方です。

❌ 失敗 1: 「ゲートウェイを入れれば全モデルが同じ挙動になる」と思い込む
⭕ 対策: 統一されるのは API の形式であって、モデルの出力品質やツール呼び出しの挙動ではありません。公式の Supported Endpoints でも、プロバイダによって対応エンドポイントが「対応済み」「動作見込み」「開発中」に分かれています。切り替え候補のモデルごとに、自社の主要プロンプトで出力を比較する評価セットを先に作ってください。

❌ 失敗 2: トークン上限を入れたのに Redis を置いていない
⭕ 対策: QuotaPolicy も使用量ベースのレート制限も、Redis と Envoy Gateway 側のレート制限設定が前提です。設定だけ書いて「効いているつもり」になるのが一番危険なので、公式が用意しているシャドウモードで計上だけを先に確認し、その後に強制へ切り替えてください。

❌ 失敗 3: MCP サーバを全部つないで、全ツールを全員に公開する
⭕ 対策: MCPRoute の toolSelector で公開ツールを絞り、書き込みを伴うツールはツール単位の Allow／Deny と JWT スコープで部門限定にします。「読み取り専用のツールから公開し、書き込み系は申請制」が安全な初期設定です。

❌ 失敗 4: 名前が変わったのを「新製品」と誤解し、評価をやり直す
⭕ 対策: 公式が「同じコード、同じメンテナ」と明言し、CRD・API グループ・CLI・ネームスペースは据え置きです。既存の評価結果と PoC はそのまま有効なので、社内手順書の名称と URL だけを更新してください。

よくある質問

Agent Router と Envoy AI Gateway は別物ですか？

同じプロジェクトです。2026年9月10日に Envoy AI Gateway が Agent Router に改名し、Envoy のサブプロジェクトから AAIF の独立プロジェクトになりました。コード・メンテナ・CRD・API グループ・CLI 名はそのままです。

AAIF に加盟すると、企業にとって何が変わりますか？

直接の機能変化はありません。変わるのは「供給元のガバナンス」で、単一企業ではなく Linux Foundation 傘下の中立団体がホストし、メンテナ席が Bloomberg・Nutanix・AMD・Tetrate・Netflix に分散している点が、長期利用の安心材料になります。

Kubernetes が無くても使えますか？

ローカル検証は CLI の aigw run で Kubernetes なしに動きます（Linux・macOS）。ただし CLI は「実験的」と明記されており、本番は Envoy Gateway 上のコントロールプレーンとして Kubernetes v1.32 以上で運用する前提です。Kubernetes を運用しない会社は Tetrate Agent Router Service などのホスト型を検討してください。

OpenRouter と何が違いますか？

OpenRouter は他社が運用する SaaS で、登録してすぐ複数モデルを 1 つの API で呼べます。Agent Router は自社の Kubernetes 上で動かす OSS で、通信・鍵・上限管理を自社の境界内に置けます。速さなら SaaS、統制なら OSS です。

料金はかかりますか？

Agent Router 自体は Apache 2.0 の OSS で無償です。かかるのは自社のインフラ費用（Kubernetes・Redis 等）と、各 AI ベンダーへの API 利用料です。ホスト型の Tetrate Agent Router Service は Flex プランがモデル提供元のコストに 5% の手数料を加える従量課金と公式サイトに記載されています。

部門ごとのトークン上限はどの単位で設定できますか？

公式ドキュメントによれば、モデル単位と、clientSelectors で指定するヘッダー値（x-tenant-id など）単位です。期間は 1s・1m・1h・1d の固定値で、バックエンド全体の割当（serviceQuota）は 2026年9月時点で「まだ強制されない」と明記されています。

MCP サーバは何本まで束ねられますか？

公式ドキュメントに本数の上限は書かれていません。MCPRoute の backendRefs に複数サーバを並べる方式で、ツール名にはバックエンド名の接頭辞が自動で付きます。上限値は 2026年9月時点で公式に確認できていないため、本番前に自社構成で検証してください。

Agent Router の X（旧 Twitter）で見かける「無料クレジット」は本物ですか？

AAIF の Agent Router（OSS）にはクレジット配布や会員登録の仕組みはありません。検索や SNS で見かける「無料クレジット」は、ホスト型の Tetrate Agent Router Service（法人メール登録で 5 ドル）か、名前が似た別サービスのものです。稟議や社内説明では「AAIF がホストする OSS」と書き分けてください。

まとめ：今日から始める3つのアクション

1. 今日やること: 本文の「導入判断の型」チェックリストを自社に当て、要る／今は要らない／SaaS で十分、のどれかを 1 行で書く。迷うなら最初のプロンプトに自社の利用状況を入れて判定させる
2. 今週中: 利用中の AI ベンダーと API キーの所在、検証中の MCP サーバを棚卸しする（2 つ目のプロンプト）。鍵が部門に散っている事実が見えた時点で、ゲートウェイの議論は始められる
3. 今月中: Kubernetes を運用しているなら aigw run と公式 Getting Started で PoC を 1 本、していないならホスト型の Flex プランで同じ検証をして、部門別のトークン予算案（4 つ目のプロンプト）を経営に出す

最後に、稟議書の骨子を作るプロンプトを置いておきます。

AI ゲートウェイ（AAIF がホストする OSS「Agent Router」、旧 Envoy AI Gateway）の導入に関する社内稟議書の骨子を作ってください。

【前提として使ってよい事実】（公式情報・2026年9月時点）
- 2026年9月10日に Linux Foundation 傘下の AAIF の正式プロジェクトになった。ライセンスは Apache 2.0
- OpenAI 互換の単一 API で 16 社以上のモデル提供元とセルフホスト推論に接続できる
- 複数の MCP サーバを 1 つの入口に集約し、OAuth とツール単位の許可・拒否を設定できる
- モデル単位・ヘッダー（部門）単位のトークン上限を設定でき、超過時は 429 を返す
- 本番は Kubernetes v1.32 以上・Envoy Gateway v1.8.1 以上が前提

【当社の情報】
- 導入目的（上位 2 つ）: {例: ベンダー切替の容易化、部門別のコスト管理}
- 現状の課題: {具体的に}
- 体制: {運用担当・人数}
- 概算費用と期間: {分かる範囲で。不明は「要見積」}

【出力】
1. 件名・目的・背景（各 2 行以内）
2. 導入方式の比較（自社運用／ホスト型）と推奨案
3. 費用・体制・スケジュール（不明項目は「要見積」と明記）
4. リスクと対策（ゲートウェイの単一障害点、鍵の集中管理、上限到達時の運用）
5. 決裁者への質問想定 3 つと回答案

注意: 上記「前提として使ってよい事実」以外の数値や実績を作らないでください。

あわせて読みたい:

• OpenRouter とは｜Stripe 買収報道で注目の AI ゲートウェイ完全ガイド — SaaS 型ゲートウェイの使い方と企業利用の観点
• AI ベンダーロックイン回避戦略｜中小企業が選ぶ抽象化レイヤー 7 パターン — SDK・SaaS・クラウド各社の抽象化を比較
• MCP 仕様刷新（2026年7月）｜AI エージェント連携で企業が確認すべき 3 点 — MCPRoute の設定が守っている仕様の要点

著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』『Claude仕事術』（SBクリエイティブ・シリーズ累計約6万部）。
SBクリエイティブ「ビジネス+IT」ほかで生成AI連載を執筆（NewsPicks最大1,125ピックス）。

ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。

参考・出典

• Envoy AI Gateway is becoming Agent Router, an Agentic AI Foundation project — Agent Router メンテナブログ（2026年9月9日公開・参照日: 2026-09-16）
• Agent Router Joins AAIF — Agentic AI Foundation ブログ（2026年9月9日公開・参照日: 2026-09-16）
• Agent Router — Projects — Agentic AI Foundation（参照日: 2026-09-16）
• Projects — Agentic AI Foundation（ホストプロジェクト一覧・参照日: 2026-09-16）
• About AAIF — Agentic AI Foundation（メンバー・役員・参照日: 2026-09-16）
• agentgateway Joins AAIF as an Open Gateway for Agentic AI Infrastructure — Agentic AI Foundation ブログ（2026年6月4日公開・参照日: 2026-09-16）
• Agent Router 公式サイト（対応プロバイダ・採用組織・参照日: 2026-09-16）
• Agent Router Docs: Capabilities（MCP Gateway・Quota Policy・Usage-based Rate Limiting・Provider Fallback・Model Name Virtualization・Metrics・Upstream Authentication・Supported Providers・Supported Endpoints の各ページ・参照日: 2026-09-16）
• Agent Router Docs: Getting Started（aigw run とサンプルリクエスト・参照日: 2026-09-16）
• Agent Router Docs: Compatibility（Envoy Gateway・Kubernetes・Gateway API の対応表・参照日: 2026-09-16）
• Agent Router v1.1.x Release Series（2026年8月21日公開・参照日: 2026-09-16）
• Announcing Envoy AI Gateway 1.0（2026年6月23日公開・参照日: 2026-09-16）
• theagentrouter/agent-router — GitHub（README・Releases・スター数は 2026年9月16日時点・参照日: 2026-09-16）
• [Project Proposal] Agent Router (previously Envoy AI Gateway) — aaif/project-proposals Issue #18（2026年4月24日起票・参照日: 2026-09-16）
• AGNTCon + MCPCon Japan to Convene Builders Advancing Production-Ready Agentic AI — The Linux Foundation プレスリリース（2026年8月25日公開・参照日: 2026-09-16）
• Tetrate Agent Router Service — Tetrate（料金プラン・参照日: 2026-09-16）
• OpenAIやAnthropicなどAIベンダごとのAPIの違いを吸収し統合する「Agent Router」、Linux Foundation傘下で業界標準へ — Publickey（2026年9月15日公開・参照日: 2026-09-16）
• AAIF、Agent Routerの参加を発表 ——AIモデルとMCPツールへの接続を仲介するOSS — gihyo.jp（2026年9月10日公開・参照日: 2026-09-16）