Azure API Managementのトークンメトリクスは、これまで中心だったprompt tokensやcompletion tokensだけでなく、cached、reasoning、thinkingなど新しいトークン種別まで把握できる方向に拡張されています。結論から言うと、AIアプリの利用量管理、部門別のコスト配賦、予算アラート、モデル選定の判断をより現実に近いデータで行えるようになる変更です。
特に、Azure API ManagementをAI Gatewayとして使い、Microsoft Foundry、OpenAI、Amazon Bedrock、Google Vertex AIなど複数のモデルプロバイダーをまたいで運用している組織では、早めに確認すべきアップデートです。Application Insights連携、llm-emit-token-metricポリシー、カスタムディメンション設計を見直すことで、トークン消費の「見える化」の精度を高められます。Microsoft Learnでは、llm-emit-token-metricポリシーがLLM API経由のトークン消費をApplication Insightsのカスタムメトリクスとして送信し、プレビューではcached、reasoning、thinkingなどのカテゴリを含められると説明されています。(Microsoft Learn)
Microsoft AzureのAzure API Managementで何が変わるのか
今回のポイントは、Azure API ManagementがLLM APIのトークンメトリクスを、より広いトークン種別で扱えるようになることです。
従来のトークン監視では、多くの場合、次のような分類が中心でした。
| 従来よく見ていた項目 | 意味 | 主な用途 |
|---|---|---|
| prompt tokens | ユーザー入力やシステムプロンプトなど、モデルに渡す入力側のトークン | 入力量の把握、長いプロンプトの最適化 |
| completion tokens | モデルが生成した出力側のトークン | 回答長の制御、生成コストの把握 |
| total tokens | 入力と出力を合計したトークン | 概算の利用量管理、上限設定 |
しかし、近年の生成AIモデルでは、これだけでは実態を捉えにくくなっています。たとえば、同じプロンプトの再利用によるキャッシュ、推論モデルで内部的に使われるreasoning tokens、モデルやプロバイダー固有のthinking tokensなど、利用量や遅延、コストに影響する要素が増えているためです。
今回のPublic Previewでは、こうした新しいトークンカテゴリを含めてメトリクスを取得できるようになります。MicrosoftのAzure Updatesでは、この更新が「Public Preview: Azure API Management now supports token metrics for all token types」として掲載され、API ManagementのLaunched / Previewの更新として示されています。(Microsoft Azure)
対象になる主な利用者
この変更の影響を受けやすいのは、単にAzure API Managementを使っているすべての利用者ではなく、APIMをAI Gatewayとして使っている管理者や開発チームです。
| 対象者 | 確認すべき理由 |
|---|---|
| Azure管理者 | Application Insights連携、Azure Monitor、カスタムメトリクスの制限を確認する必要がある |
| API基盤チーム | APIMポリシーの適用範囲、ディメンション設計、ログ出力方針を見直す必要がある |
| AIアプリ開発者 | 利用量、レスポンス遅延、モデル別コストの見え方が変わる可能性がある |
| FinOps・IT企画担当 | 部門別・アプリ別のAI利用コスト配賦をより細かく設計できる |
| セキュリティ・ガバナンス担当 | AI利用状況の監査、異常利用の検知、予算超過リスクの把握に活用できる |
特に、複数のアプリケーションが同じAIバックエンドを共有している環境では重要です。Azure API ManagementのAI Gateway機能は、AIモデル、エージェント、ツールを保護、スケール、監視、統制するための機能群として説明されており、Microsoft FoundryやAmazon Bedrockなど複数環境のモデル管理にも触れられています。(Microsoft Learn)
なぜ「全トークン種別」のメトリクスが重要なのか
生成AIの運用では、「API呼び出し回数」だけを見てもコストや負荷を正しく判断できません。同じ1回のリクエストでも、短い質問と長い社内文書の要約では消費トークンが大きく異なります。さらに推論モデルでは、ユーザーに見える出力が短くても、内部処理に多くの推論トークンを使う場合があります。
今回の変更で重要になる観点は、次の3つです。
| 観点 | これまで起きやすかった問題 | 期待できる改善 |
|---|---|---|
| コスト把握 | prompt / completionだけでは実際の消費構造を説明しづらい | cached、reasoning、thinkingを含めた分析がしやすくなる |
| 予算アラート | total tokensだけを基準にすると、モデル変更後の増加要因が分かりにくい | どのトークン種別が増えているかを分解して確認できる |
| モデル評価 | レスポンス品質だけで比較し、運用コストを見落としやすい | モデル別・API別の消費傾向を比較しやすくなる |
たとえば、問い合わせ対応チャットボットでキャッシュが効いている場合、cached tokensを含めて見れば、同じFAQが繰り返し呼ばれていることや、キャッシュ施策がどれほど効果を出しているかを判断しやすくなります。一方、複雑な調査やコード生成でreasoning tokensが増えている場合は、モデル選定やプロンプト設計を見直す判断材料になります。
対応するAPI形式とモデルプロバイダーの確認
llm-emit-token-metricポリシーのドキュメントでは、対応するLLM APIスキーマとして、OpenAI Chat CompletionsまたはResponses API、Anthropic Messages API、Google Vertex AI APIが挙げられています。Anthropic Messages APIについては、API Management v2 tiersで現在サポートされる旨も記載されています。(Microsoft Learn)
実務では、次のように整理して確認すると分かりやすくなります。
| 確認項目 | 見るべきポイント |
|---|---|
| 利用中のAPI形式 | Chat Completions、Responses、Anthropic Messages、Vertex AI APIなど、APIM側で認識できる形式か |
| バックエンド | Microsoft Foundry、Azure OpenAI、外部プロバイダー、セルフホストモデルなど |
| APIMの階層 | v2、classic、self-hosted、workspaceなど、利用中のゲートウェイで対象ポリシーを使えるか |
| メトリクスの出力先 | Application Insightsが接続済みか、カスタムメトリクスが有効か |
| ストリーミング利用 | stream=trueのリクエストでは、トークンメトリクスが推定値になる点を考慮する |
重要なのは、「Azure API Managementを通せば必ずすべてのモデルで完全に同じ粒度のメトリクスが取れる」と考えないことです。トークン数やカテゴリはモデルやプロバイダーに依存します。Microsoft Learnでも、トークンカウントメトリクスはモデルおよびプロバイダー依存であり、利用可能な場合はLLM APIレスポンスのusageセクションの値を使うと説明されています。(Microsoft Learn)
管理者が確認すべき設定
Azure管理者やAPI基盤チームは、まず次の4点を確認してください。
| 確認項目 | チェック内容 | 見落とすと起きること |
|---|---|---|
| Application Insights連携 | APIMインスタンスとApplication Insightsが接続されているか | メトリクスが送信されない |
| LLM APIのログ設定 | 対象APIでApplication Insights loggingが有効か | 特定APIだけデータが取れない |
| カスタムメトリクス | Application Insightsでディメンション付きカスタムメトリクスが有効か | API別・ユーザー別の分析ができない |
| ポリシー適用範囲 | global、workspace、product、API、operationのどこに適用するか | 不要なAPIまで集計される、または必要なAPIが漏れる |
Application Insightsとの統合では、APIMにApplication Insightsロガーを作成し、対象APIでログを有効化します。Microsoftの日本語ドキュメントでも、APIMとApplication Insightsの接続作成、APIごとのApplication Insightsログ有効化、カスタムメトリクスの有効化手順が説明されています。(Microsoft Learn)
最小構成のポリシー例
まずは、API IDをディメンションとして出力する最小構成から始めるのが安全です。
<policies>
<inbound>
<llm-emit-token-metric namespace="MyLLM">
<dimension name="API ID" />
</llm-emit-token-metric>
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>この構成なら、APIごとのトークン消費傾向を把握しやすくなります。最初からユーザーID、部門ID、アプリID、モデル名などを大量に追加するのは避けたほうが安全です。
カスタムディメンション設計で失敗しやすいポイント
この機能を実務で使う際に最も注意したいのは、カスタムディメンションの増やしすぎです。
Azure Monitorのカスタムメトリクスには制限があります。llm-emit-token-metricのドキュメントでは、Azure Monitorの制限として、1メトリックあたり10個のディメンションキー、サブスクリプション内のリージョン単位で12時間あたり50,000のアクティブ時系列といった制限が例示されています。またAPIMでは既定ディメンションに一部が使われるため、このポリシーで構成できるカスタムディメンションは最大5個とされています。(Microsoft Learn)
| 避けたい設計 | 理由 | 推奨される考え方 |
|---|---|---|
| リクエストIDをディメンションにする | 値が毎回変わり、時系列数が爆発しやすい | ログ側で追跡し、メトリクスには使わない |
| 生のユーザーメールアドレスを入れる | 個人情報・運用リスクが高い | 部門ID、アプリID、匿名化IDを検討する |
| すべてのAPIに一律適用する | 不要なデータまで出力される | まずAI関連APIに限定する |
| 開発・検証・本番を同じ名前空間に混在させる | ダッシュボードやアラートが読みづらくなる | 環境名を整理して設計する |
| モデル名の表記ゆれを放置する | モデル別集計が崩れる | APIMポリシーやバックエンド設定で命名を統一する |
実務では、最初のディメンションは「API ID」「Product ID」「Subscription ID」程度に絞るのがおすすめです。その後、コスト配賦が必要なら「部門」「アプリケーション種別」、性能分析が必要なら「Backend ID」「Location」を検討します。
開発者が確認すべき影響範囲
開発者側では、アプリケーションコードの大幅な変更が必要になるとは限りません。Azure API Management側でメトリクスを発行する構成のため、既存のLLM API呼び出しをAPIM経由に集約している場合は、主にAPIMポリシーと監視基盤の変更が中心になります。
ただし、次の点は開発チームでも確認しておくべきです。
| 確認ポイント | 理由 |
|---|---|
| すべてのAI呼び出しがAPIMを経由しているか | 直接バックエンドを呼ぶ経路があると利用量が漏れる |
| ストリーミング応答を使っているか | token metricsが推定になる可能性がある |
| APIレスポンスのusage情報を利用しているか | アプリ側の集計とAPIM側の集計に差が出る場合がある |
| プロンプトキャッシュを使っているか | cached tokensの増減が性能・コスト分析に関係する |
| 推論モデルを使っているか | reasoning tokensの増加がレイテンシやコストに影響する可能性がある |
特に注意したいのは、アプリ側で独自にトークン消費を集計している場合です。APIM側の新しいメトリクスと集計ロジックが二重管理になると、ダッシュボード間で数値がずれる可能性があります。既存の集計をすぐ廃止するのではなく、一定期間は並行稼働させ、差分の原因を確認してください。
移行・展開時のおすすめ手順
本番環境へいきなり適用するのではなく、段階的に展開するのが安全です。
| ステップ | 作業内容 | 判断基準 |
|---|---|---|
| 事前調査 | AI API一覧、モデル、プロバイダー、APIM経由有無を棚卸しする | 監視対象の漏れがないか |
| 検証環境で有効化 | Application Insights連携とllm-emit-token-metricを設定する | メトリクスが期待どおり送信されるか |
| ディメンションを最小化 | API IDやProduct IDなど少数で開始する | 時系列数が増えすぎないか |
| ダッシュボード作成 | API別、モデル別、利用者別のトークン傾向を見る | 運用判断に使える粒度か |
| アラート設定 | 急増、予算超過、異常利用を検知する | 通知が多すぎないか |
| 本番展開 | 対象APIを段階的に広げる | コスト・性能・ログ量に問題がないか |
最初の目的は、完璧な可視化ではなく「どのAPIが、どのモデルで、どの程度トークンを消費しているか」を安定して把握することです。細かい分析軸は、実データを見ながら追加していくほうが失敗しにくくなります。
コスト管理で見るべきメトリクス例
Azure API Managementのトークンメトリクスを活用するなら、単にtotal tokensをグラフ化するだけでは不十分です。運用では、次のような切り口を用意すると、問題発見が早くなります。
| ダッシュボード項目 | 目的 |
|---|---|
| API別トークン消費 | どのAI機能が最も使われているかを把握する |
| サブスクリプション別トークン消費 | チーム・アプリ・顧客単位の利用量を把握する |
| モデル別トークン消費 | 高コストなモデルへの偏りを見つける |
| cached tokens比率 | キャッシュが効いているかを評価する |
| reasoning / thinking tokensの増加 | 推論系モデルの利用増やレイテンシ要因を確認する |
| 時間帯別トークン消費 | バッチ処理やピーク時間の影響を把握する |
たとえば、総トークン数は横ばいなのにコストが増えている場合、より高価なモデルへトラフィックが移っている、reasoning tokensが増えている、キャッシュが効かなくなっている、といった可能性があります。メトリクスを分解して見られるようになると、単なる「使いすぎ」ではなく、原因に応じた対策を取りやすくなります。
セキュリティとログ設計の注意点
トークンメトリクスの強化は便利ですが、ログ設計を誤ると別のリスクが生まれます。特に、プロンプトやレスポンス本文をログに含める設定には注意が必要です。
Microsoft Learnでは、Azure API ManagementのAI Gatewayがプロンプトや補完のログ、Application Insightsでの消費者別トークンメトリクス、組み込みダッシュボード、トークンクォータ管理などに対応することが説明されています。(Microsoft Learn) 一方で、実務上は「どこまで記録するか」を組織のデータ分類ルールに合わせて決める必要があります。
| 項目 | 推奨方針 |
|---|---|
| プロンプト本文 | 個人情報、機密情報、顧客データが含まれる可能性があるため、必要性を明確にする |
| レスポンス本文 | 監査や品質改善に必要な場合のみ、保存期間と閲覧権限を制限する |
| ユーザー識別子 | 生のメールアドレスではなく、匿名化IDや部門IDを検討する |
| 保存期間 | コスト管理目的なら長期保存、トラブルシュート目的なら短期保存など用途別に分ける |
| アクセス権 | Application InsightsやLog Analyticsの閲覧権限を最小化する |
「メトリクス」と「本文ログ」は分けて考えるのが重要です。コスト管理や予算アラートが目的なら、必ずしもプロンプト本文を保存する必要はありません。
既存環境でまず確認するチェックリスト
すでにAzure API ManagementでAI APIを公開している場合は、次の順に確認してください。
| チェック | 内容 |
|---|---|
| APIM経由の統一 | 生成AIアプリがAPIMを経由しているか |
| 対象API形式 | OpenAI Chat Completions、Responses、Anthropic Messages、Google Vertex AI APIなどの対象形式か |
| Application Insights | APIMインスタンスと接続済みか |
| LLM APIログ | 対象APIでログが有効か |
| カスタムメトリクス | ディメンション付きで有効化されているか |
| ポリシー | llm-emit-token-metricがinboundに設定されているか |
| ディメンション | 最大5個の範囲で、低カーディナリティな値を選んでいるか |
| ストリーミング | 推定値として扱う運用ルールがあるか |
| アラート | 急増、月次予算、部門別上限を検知できるか |
| 権限 | ログ・メトリクス閲覧者が必要最小限か |
このチェックリストで問題が多い場合は、まず本番の前に1つのAI APIだけを対象に検証するのが現実的です。
今回のアップデートを活かす運用例
実際の活用シーンとしては、次のようなものが考えられます。
部門別の生成AI利用コストを可視化する
Product IDやSubscription IDをディメンションに含めると、部門やアプリケーション単位でトークン消費を追いやすくなります。社内チャットボット、文書要約、コード生成支援などが同じAI基盤を使っている場合、どの用途がコストを押し上げているかを説明しやすくなります。
推論モデルの使いどころを見直す
reasoning tokensやthinking tokensの増加が目立つAPIでは、すべてのリクエストに高性能な推論モデルを使う必要があるかを見直せます。たとえば、FAQ回答は軽量モデル、複雑な調査やコードレビューは推論モデル、というルーティング設計にすることで、品質とコストのバランスを取りやすくなります。
キャッシュ施策の効果を確認する
cached tokensが見えるようになると、プロンプトキャッシュやセマンティックキャッシュの効果を判断しやすくなります。Azure API ManagementのAI Gatewayドキュメントでは、セマンティックキャッシュによりバックエンドAIサービスへの呼び出しを減らし、応答時間やコスト削減に役立つと説明されています。(Microsoft Learn)
導入時にやるべきこと
今回のAzure API Managementのトークンメトリクス拡張は、生成AIアプリの運用を「呼び出し回数ベース」から「実際のトークン消費ベース」へ近づける変更です。特に、cached、reasoning、thinkingなどのトークン種別を把握できるようになることで、AI利用コスト、性能、モデル選定、キャッシュ効果をより具体的に分析できます。
まず取り組むべきことはシンプルです。APIM経由のAI APIを棚卸しし、Application Insights連携を確認し、llm-emit-token-metricを検証環境で有効化してください。そのうえで、ディメンションは最小限から始め、API別・アプリ別・モデル別の消費傾向を見ながら本番展開するのが安全です。
生成AIの利用が広がるほど、コスト管理は後追いでは難しくなります。今回のPublic Previewは、Azure上のAI Gateway運用を見直すよいタイミングです。
コメント