「AIの利用料、先月いくらでしたか」と聞くと、複数の答えが返ってくる会社があります。営業部が契約したもの、開発部が検証で使っているもの、情シスが試しているもの。それぞれ別のAPIキーで、別の請求書になっていて、全体でいくら使っているかを知っている人がいない状態です。
金額だけの話なら経理で足し算すれば済みます。厄介なのは、どのデータがどのモデルに送られているかも、同じように分からなくなっていることです。そして各部署のコードには、それぞれのベンダーのSDKが直接書き込まれています。
この状態を整理する道具が、AIゲートウェイと呼ばれるものです。2026年9月、この領域のOSSがひとつ、業界標準化の枠組みに入りました。
AIゲートウェイは、何をする1枚なのか
やっていることは単純で、アプリケーションとAIモデルの間に1枚挟んで、通信を全部そこに通すだけです。効果は挟んだ結果として出てきます。
- 接続先がひとつになる。 アプリ側は、モデルごとに違うSDKやエンドポイントを書かずに済みます。Agent Routerの場合、すべてのモデルに対してOpenAI互換のAPIひとつで話せます
- 誰がいくら使ったかが分かる。 全部が1か所を通るので、部署別・用途別の利用量が取れます。上限を設けることもできます
- 送っている中身が見える。 どのデータが外部のモデルに出ているかを、1か所で記録・検査できます
- モデルを差し替えられる。 アプリのコードを触らずに、裏側のモデルを変えられます
4つ目が、いわゆるベンダーロックインの話です。ただし注意が必要で、ゲートウェイを挟めばモデルを自由に入れ替えられる、というほど単純ではありません。プロンプトの書き方やツール呼び出しの挙動はモデルごとに違うので、差し替えたら品質も変わります。 変えられるのは接続の手間の部分であって、品質の再検証まで消えるわけではありません。このあたりの実際はマルチモデル運用のコストと品質のトレードオフに整理しています。
Envoy AI Gateway が Agent Router になった
2026年9月、Envoy AI Gateway が Agentic AI Foundation（AAIF）に参加し、名称を Agent Router に変更しました。コード、メンテナ、APIはそのまま引き継がれています。改名だけを見ると大した話ではありませんが、行き先に意味があります。
AAIFは Linux Foundation 傘下の団体で、MCP・AGENTS.md・Agent2Agent プロトコルといった、AIエージェント周辺の技術の標準化を進めています。つまり Agent Router は、特定のベンダーの製品ではなく、中立な団体が持つ部品になったということです。
Agent Router が扱うのは、モデルへの接続だけではありません。MCPツールへの接続も同じ1枚を通ります。 エージェントから見ると、すべてのモデルに対してひとつのOpenAI互換API、すべてのMCPツールに対してひとつのルーター、という形になります。社内システムをMCPサーバーとして公開していく方針を取るなら、この構成は相性が良いはずです。MCPそのものの整理はMCP完全ガイドにあります。
本番利用の実績としては、Bloomberg、Tencent Cloud、Nutanix といった名前が挙がっています。少なくとも、検証止まりのプロジェクトではありません。
なお、名前の似たものに agentgateway という別プロジェクトがあります。こちらは Solo.io が Linux Foundation に寄贈したもので、Agent Router とは別物です。社内で技術選定の話をするときに混同されやすいので、URLまで含めて指定したほうが安全です。
自前で建てるか、マネージドで済ませるか
OSSのゲートウェイを自社で運用するのか、クラウド事業者のマネージドサービスを使うのか。ここが最初の分岐です。
| 自前で運用（Agent Router 等） | マネージド（クラウド事業者の提供） | |
|---|---|---|
| 向く条件 | すでにKubernetesを運用している。ログや通信の経路を自社内に閉じたい | インフラ担当が1〜2名。まず利用量の可視化だけしたい |
| 手間 | 構築と運用の工数がかかる。Envoyの知識が要る | 設定だけで始められる |
| 注意点 | 止まると社内のAI利用が全部止まる。冗長化が前提 | 事業者のサービス終了・仕様変更の影響を受ける |
社員50人規模で、インフラ専任がいない会社であれば、まずはマネージドのほうが現実的です。利用量の上限設定から始める考え方はAIゲートウェイでの費用の上限管理に書いています。
自前で建てる判断が正当化されるのは、プロンプトやレスポンスの内容を自社の外に出したくないという要件がある場合です。この要件があるなら、運用工数はその対価として見積もるべきものになります。
入れる前に決めておくこと
ゲートウェイは、入れた瞬間に社内AI利用の単一障害点になります。技術選定の前に、次の3つを決めておいてください。
- 止まったときにどうするか。 ゲートウェイが落ちたとき、各アプリは直接モデルを叩くフォールバックを持つのか、それとも止まってよいのか。業務が止まる範囲を先に把握します
- ログをどこまで残すか。 プロンプトの全文を残すと、そのログ自体が機微情報の塊になります。残す範囲と保存期間を、記録を取る前に決めます
- 誰が上限を決めるのか。 部署別の利用上限は、情シスが決めるのか、各部署が申請するのか。ここを決めずに導入すると、上限に当たるたびに情シスへ問い合わせが来ます
ベンダーロックインを避ける動機で導入する場合、ゲートウェイ自体が新しいロックインにならないかも見ておく価値があります。中立な団体が持つOSSであることは、その点では安心材料のひとつです。判断の枠組みはベンダーロックインの避け方に整理しています。
次にやること
まず、社内で発行されているAI関連のAPIキーを数えてください。経理側の請求と、実際に発行されているキーの数が合わないことは珍しくありません。数が3つ以下なら、ゲートウェイを入れるより先に、使う人を決めるほうが効きます。 10を超えていて、誰が何に使っているか説明できないなら、1枚挟む検討に入る段階です。
社内AI基盤の構成設計、利用量とログの管理方針、既存アプリからの移行については、グリームハブの開発・AI・自動化のご相談で承っています。現在の利用状況と体制によって適した構成が変わるため、お問い合わせからご相談ください。
