【Azure AI入門⑥】Azure AI Foundryの運用｜クォータ・監視・コスト最適化・本番デプロイ

Azure

いよいよ最終回です。モデルを選び、エージェント・RAG を作り、評価と安全性まで固めました。残るは「本番で安定して回し続ける」ための運用です。生成 AI は、放っておくと429（レート制限）で止まる・コストが青天井になる・どこが遅いか分からない——といった問題が起きがち。ここを設計してこそ、実務で「使える」状態になります。

本番で急に429エラーが出たり、月末にコストがすごいことになったり…。運用で気をつけることを整理したい！

この記事は Azure AI Foundry シリーズの第6回（最終回）として、運用を次の流れで整理します。

  • クォータ / レート制限（TPM / RPM）を管理できる
  • 監視・トレース（トークン使用量・オブザーバビリティ）を確認できる
  • コスト管理・最適化（デプロイ種別 / バッチ / キャッシュ）を理解している
  • アプリ / エージェントをデプロイして本番公開できる

クォータ / レート制限｜TPM と RPM、そして 429

本番で最初にぶつかる壁がレート制限です。第3回でモデルをデプロイするとき TPM を指定しましたが、これがそのまま「どれだけ捌けるか」の上限になります。

用語意味
TPM（Tokens Per Minute）1分あたりに処理できるトークン数の上限。デプロイに割り当てる
RPM（Requests Per Minute）1分あたりのリクエスト数の上限。TPM から連動して算出される
429上限を超えたときに返るエラー（Too Many Requests）

ポイントは、TPM を割り当てると RPM が連動して決まり、どちらかを超えると 429 が返ることです。本番でトラフィックが増えて 429 が頻発したら、デプロイの TPM を引き上げる（＝クォータ調整）か、アプリ側でリトライ（指数バックオフ）を入れて捌きます。「429 は障害ではなく、設計で織り込むもの」と捉えるのが実務的です。

チームで共有するなら、APIM（API Management）を前段に置いてキー単位でトークン上限をかける手もあるよ。「共有地の悲劇」を防ぐ設計は別記事で詳しく書いてるよ！

【ここが説明できればOK①】
「デプロイに TPM を割り当てると RPM が連動し、超えると 429 が返る。トラフィック増にはクォータ調整とリトライで対処する」——これを言えればOKです。

監視・トレース｜どこが遅い・どれだけ使ったを可視化する

生成 AI アプリは「ブラックボックス」になりがちです。「なぜか遅い」「なぜかコストが高い」を放置しないために、オブザーバビリティ（可観測性）を仕込みます。Foundry は Application Insights と連携できます。

連携すると、次のようなものが可視化できます。

  • トレース：1リクエストが「検索 → LLM 呼び出し → ツール実行」のどこで時間を食っているか。
  • トークン使用量：入力／出力トークンをリクエスト単位で追える。コストの内訳が見える。
  • レイテンシ・エラー率：遅延や 429/500 の発生状況。
  • 評価スコア：第5回のオンライン評価と繋げば、品質の推移も同じ画面で。

Application Insights のデータは KQL（Kusto Query Language）で深掘りできます。「どのエンドポイントが遅いか」「トークンを食っているのはどの機能か」を KQL で集計すれば、改善すべき箇所がピンポイントで見えてきます。インフラ監視の延長線として、生成 AI アプリにも同じ「可観測性の型」を当てはめるイメージです。

【ここが説明できればOK②】
「Application Insights 連携でトレース・トークン使用量・レイテンシ・評価スコアを可視化し、KQL で遅い箇所やコストの内訳を深掘りできる」——これを言えればOKです。

コスト管理・最適化｜デプロイ種別・バッチ・キャッシュ

生成 AI は使うほど課金されるので、コスト設計を後回しにすると痛い目を見ます。最適化の打ち手を整理します。まず土台となるのがデプロイ種別の選択です。

デプロイ種別課金向いている場面
Standard（従量）使ったトークン分だけトラフィックが読めない・変動が大きい
Provisioned（PTU）スループットを予約購入（固定）安定した高負荷・レイテンシを保証したい
Global / Data Zone配置範囲で単価・可用性が変わるコストと配置要件のバランス調整

「まず Standard（従量）で始め、負荷が安定して大きくなったら PTU で単価を抑える」が王道です。さらに、種別選択とは別に使い方での最適化も効きます。

  • Batch API：急がない一括処理（夜間のまとめ処理など）を割引価格で非同期実行。
  • プロンプトキャッシュ：繰り返し使う長い前置き（システムメッセージ等）をキャッシュし、入力トークンのコストを削減。
  • モデルの適正化：第3回の通り、評価で問題なければ軽量モデルに落とすのが最も効くコスト削減。

【ここが説明できればOK③】
「Standard（従量）と Provisioned（PTU）を負荷で使い分け、Batch API の割引・プロンプトキャッシュ・軽量モデル化でコストを最適化する」——これを言えればOKです。

本番デプロイ｜アプリ・エージェントを公開する

最後は公開です。プレイグラウンドやプロンプトフローで作ったものを、実際にユーザーが使える形にデプロイします。

大きく2つのパターンがあります。1つは、プロンプトフローやチャットアプリをマネージドエンドポイント / Web アプリとして Foundry からデプロイする方法。もう1つは、Foundry のモデル / エージェントをAPI として呼び出す自作アプリ（App Service や Container Apps）を用意する方法です。後者なら、第2回で固めたマネージド ID + キーレス認証 + Private Endpoint をそのまま活かせます。

【パターンA】Foundry から直接デプロイ
  プロンプトフロー / チャットアプリ
    → マネージドエンドポイント / Web アプリ

【パターンB】自作アプリから API 呼び出し（推奨・柔軟）
  App Service / Container Apps
    → マネージドID（キーレス）で Foundry を呼ぶ
    → Private Endpoint で閉域化
    → App Insights で監視

→ 本番はBが定番。第2回の土台がそのまま効く

本番公開したら、そこがゴールではなくスタートです。第5回のオンライン評価と、この回の監視・コストを回し続けることで、品質とコストを保ったまま運用できます。「作って終わり」ではなく「測って回し続ける」——これが生成 AI 運用の肝です。

【ここが説明できればOK④】
「Foundry から直接マネージドエンドポイントで出す方法と、自作アプリ（App Service / Container Apps）から API 呼び出しする方法がある。本番は後者が定番で、キーレス認証・Private Endpoint・監視の土台が活きる」——これを言えればOKです。

まとめ｜Azure AI Foundry シリーズ 全6回

今回のポイントです。

  • TPM / RPM / 429を理解し、クォータ調整とリトライでレート制限を捌く
  • Application Insights + KQLでトレース・トークン・レイテンシを可視化
  • Standard / PTUの使い分け＋バッチ・キャッシュ・軽量モデル化でコスト最適化
  • 本番は自作アプリ + キーレス + Private Endpoint + 監視で公開

ここまでお疲れさまでした。全6回を通して、Azure AI Foundry を「概要 → 土台（認証・閉域）→ モデル → エージェント・RAG → 評価・安全性 → 運用」という順で一周しました。この流れを押さえれば、生成 AI アプリを安全に・品質を測りながら・コストを管理して本番運用できます。あとは実際に手を動かして、自分の言葉で説明できるレベルまで落とし込んでいきましょう。

Azure AI Foundry シリーズ 全6回

あわせて読みたい

タイトルとURLをコピーしました