AI基盤の整備が急速に進む中、プラットフォームチームが直面する現実的な課題がある。「AIを誰もが使えるようにしたいが、1つのアプリがクォータを食い尽くして全体が止まる」という問題だ。その解決策として、Azure Kubernetes Service（AKS）のApplication Network（AppNet、現在パブリックプレビュー）とオープンソースのagentgatewayを組み合わせた、アプリケーション単位のトークンレート制限機能が公開された。シークレットの配布なしにAIコストを一元管理するというプラットフォーム設計の考え方は、今後のAI基盤運用の標準的なアーキテクチャになり得る。

従来のAI API管理の限界

AI推論ワークフローの典型的な構成はシンプルだ。AIプロバイダーのアカウントを作成し、APIキーを配布して、アプリケーションからAPIを呼ぶ。しかし利用規模が拡大すると、避けられない問題が発生する——403: Insufficient Quota。クォータが枯渇した瞬間、全アプリケーションが同時に停止し、どのワークロードが原因かすら特定できない。

一対一でAPIキーを発行する対策も一般的だが、これはこれで問題がある。キーのプロビジョニング・ローテーション・配布といった運用負担が積み重なり、新しいアプリケーションのオンボーディングが遅くなる。「AIを使いたい」という開発チームの要求に対して、プラットフォームそのものが障害になるという本末転倒な状況だ。

プラットフォーム層でのレート制限という考え方

AppNetとagentgatewayが解決するのは、まさにこの構造的問題だ。

キーアイデアは「アプリケーションをシークレットではなくIDで識別する」こと。

Azure Kubernetes Application NetworkはIstioのztunnelプロキシを通じて、クラスター内の全トラフィックにmTLS（相互TLS）による自動ワークロードID認証を確立する。このIDをベースに、agentgatewayがCEL（Common Expression Language）式を使ってアプリケーションごとのトークンバジェットを定義・適用できる。

具体的な構成要素は以下のとおりだ：

  • AppNet: 全トラフィックにmTLSを自動適用し、アプリケーションのID情報をワイヤー上で伝搬する
  • agentgateway: mTLSを終端し、IstioウェイポイントとしてネットワークへTLSIDを直接読み取りトークンレート制限を適用する
  • Azure Foundry APIキー: agentgatewayのみがアクセス。アプリケーションチームはシークレットを一切扱わない

この構成の最大の利点は、アプリケーション側のコードを変更することなく、プラットフォーム層でAIコストを一元管理できることだ。

実務への影響

コスト管理の民主化とガバナンスの両立

AI利用を「使いたい人に使わせる」ながら「特定のチームがコストを独占しない」という、一見矛盾した要件を同時に満たせる。予算管理部門が求める可視性と、開発チームが求める利便性を同時に実現できる。

オンボーディングの高速化

新しいアプリケーションがAI機能を使い始めるとき、APIキーの発行申請・承認・配布というプロセスが不要になる。ワークロードIDが自動的に認証基盤となるため、セキュリティレビューが完了していれば即日利用開始できる。

インシデント対応の改善

クォータ超過時に「誰が使ったか」を正確に特定できる。AIコストのFinOps的な分析が現実的なレベルで可能になる。

明日から試せる具体的アクション

  • AKSクラスターにApplication Networkを有効化（パブリックプレビュー）
  • agentgatewayをデプロイし、AppNetのIstio準拠コントロールプレーンと連携設定
  • CEL式でアプリケーションごとのトークンバジェットポリシーを定義
  • Azure Foundry（Azure AI Services）のAPIキーはagentgatewayにのみ設定し、アプリケーションチームへのシークレット配布をゼロにする

筆者の見解

このアーキテクチャを見て率直に感じるのは、「これはAIの問題ではなく、アイデンティティの問題だ」という点だ。

シークレットを配布してアクセス制御するというモデルは、VPNと同じ発想の延長線上にある。静的な認証情報を配布して管理する構造は、どこかで必ず運用コストと漏洩リスクに転化する。それに対してmTLSとワークロードIDによる動的な認証は、ゼロトラストのアーキテクチャ原則に合致した正しい方向性だ。

NHI（Non-Human Identity＝非人間アイデンティティ）の管理という観点でも重要な意味を持つ。AI活用を本気でスケールさせるなら、AIワークロード自体のIDをどう管理するかが業務効率のボトルネックになる。「人間が手動でAPIキーを発行・ローテーションする」構造のままでは、AI活用の速度がその運用作業に律速されてしまう。

Azureが描くプラットフォームの方向性——エージェントの管制塔としてEntra IDを活用し、AI利用を安全かつ自律的に許可していく——は長期的に正しいと考える。AppNetとagentgatewayの組み合わせはその具体的な実装例であり、「どのAIモデルを使うか」よりも「どうガバナンスするか」を先に固めるという、プラットフォームエンジニアリングの本来の仕事に戻ってきた感がある。

AI利用のゲートを閉じるのではなく、安全に使える仕組みを作って開放する。その正しい実装を今のうちに整えておくことが、今後のAI活用競争で組織が後れを取らないための基盤になる。プラットフォームが価値を生む時代は、まだ始まったばかりだ。

出典: この記事は Control AI spend with per-application token rate limiting using Application Network and agentgateway の内容をもとに、筆者の見解を加えて独自に執筆したものです。