Microsoftは、Azure API Management (APIM) に専用の AI Gateway tier を追加しました。この動きは、LLM呼び出しが単なる一つのAPIエンドポイントではなく、独立したワークロードとして扱われるようになったことを示しています。

なぜLLMトラフィックは従来のゲートウェイでは対応できないのか

たった一つのプロンプトが他のプロンプトの100倍のコストがかかることもありますが、標準的なAPIゲートウェイは両方を単一のリクエストとして認識します。ゲートウェイがカウントするのは呼び出し回数であり、モデルが処理するトークン数ではありません。数百トークンを送信するリクエストと、数千トークンを送信するリクエストは、後者の方が桁違いにコストがかかる可能性があるにもかかわらず、リクエスト回数のメトリクスとしては同一として記録されます。

リクエストベースの制限がAIにおいて役に立たない4つの理由:

  • コスト ≠ リクエスト数。 課金はHTTP呼び出しの回数ではなく、トークン数に紐付いています。
  • トークン量が大きく変動する。 あるクエリは短い質問かもしれませんが、別のクエリは長いドキュメントを含むかもしれません。
  • モデルの選択によって価格が変わる。 LLMによって、トークンあたりの料金が異なります。
  • ストリーミングによって最終的な請求額が隠れる。 レスポンスがストリーミングされる場合、ストリームが終了するまで総トークン数は分かりません。

リクエスト数のみを測定し続けると、実際の支出について何も教えてくれないモニタリングデータしか得られなくなります。

AI Gateway tier が変えるもの

トークン使用量を制御するために必要なポリシーの多くは、標準のAPIMティアにすでに存在しています。それらはXMLルールとして記述され、カスタムダッシュボードに表示されています。AIティアは、それらの機能を専用の体験としてパッケージ化しています:

  • AIトラフィックのためのスケーリングの分離
  • 手動で作成したXMLポリシーを不要にする簡素化された設定

中心となる変化は運用面です。トークン予算を適用するために、複雑なコードを書いたり、個別のダッシュボードを維持したりする必要がなくなります。このティアは、それらの制御のための既成のインターフェースを提供します。

切り替えのタイミング – トラフィックに基づくガイド

  • AIがトラフィックのわずかな割合である場合。 既存のAPIMティアを使い続け、きめ細かな制御が必要な場合はトークンポリシーを追加してください。
  • AIが呼び出しの大部分を占める場合。 スケーリングを分離し、コストガバナンスを明確に保つためにAIティアに移行してください。
  • エンジニアリングのオーバーヘッドを避けたい場合。 このティアの組み込みツールにより、カスタムポリシーの構築や維持に費やす時間を削減できます。

最大の出費はサブスクリプション料金ではなく、汎用的なゲートウェイにトークン経済学を理解させるために、欠陥を修正するエンジニアリング工数です。

プレビューフェーズのプレイブック

Microsoftは現在、AIティアをプレビューとして提供しています。本番環境への導入ではなく、テストベッドとして扱ってください。

  1. ボリュームの大きい内部AIワークロードを選択する。 最も多くのトークントラフィックを生成するサービスを選びます。
  2. そのワークロードをAIティア経由でルーティングする。 新しい設定を使用して、コンシューマーごとのトークン使用量をキャプチャします。
  3. 数週間にわたってトークン支出データを収集する。 トークン数と関連コストを、既存のモニタリングと比較します。
  4. ベースラインを予算策定に活用する。 このティアのコスト管理のメリットが、プレビューフェーズの制限を上回るかどうかを判断します。

一般提供(GA)が開始されるまで、ミッションクリティカルな本番ワークロードをプレビューサービスに移行しないでください。

反論:全員に別ティアが必要なわけではない

組織がLLMへの呼び出しをたまに行う程度であれば、AIティアの追加コストは正当化されないかもしれません。既存のポリシーフレームワークを使用すれば、手作業は増えますが、トークンレベルのガバナンスを実現することは可能です。このティアが真価を発揮するのは、AIトラフィックがAPIサーフェスの実質的かつ成長中の部分である場合です。

まとめ

AI Gateway tierは、LLMトラフィックが従来のAPI呼び出しとは根本的に異なる挙動をすることを認めています。リクエストのカウントからトークンベースのガバナンスへと移行することで、開発者はカスタムコードに溺れることなく、AI支出を抑制するための実用的な手段を得られます。AIの使用量がすでに相当な規模である、あるいは拡大が見込まれるチームにとって、今プレビューをテストすることは、トークン支出のベースラインを構築するのに役立ちます。