いよいよ最終回です。モデルを動かし、基本を押さえ、守りと拡張まで固めました。残るは「本番で安定して回し続ける」運用。生成 AI は、放っておくと429（レート制限）で止まる・コストが青天井になる・どこが遅いか分からない——ここを設計してこそ、実務で「使える」状態になります。
本番で急に429エラーが頻発したり、月末に請求を見て青ざめたり…。運用で押さえるべきポイントを整理したい！
この記事は Azure OpenAI シリーズの第5回（最終回）として、運用と最適化を次の流れで整理します。
- クォータ / レート制限（TPM / RPM）を管理できる
- Provisioned Throughput Unit（PTU）の考え方を理解している
- ログ / 監視（診断ログ・トークン使用量）を確認できる
- バッチ / ストリーミング / キャッシュでコスト最適化できる
クォータ / レート制限｜TPM・RPM・そして 429
本番で最初にぶつかる壁がレート制限です。第2回でデプロイに TPM を割り当てましたが、これがそのまま「どれだけ捌けるか」の上限になります。
| 用語 | 意味 |
|---|---|
| TPM（Tokens Per Minute） | 1分あたりに処理できるトークン数の上限。デプロイに割り当てる |
| RPM（Requests Per Minute） | 1分あたりのリクエスト数の上限。TPM から連動して算出される |
| 429 | 上限を超えたときに返るエラー（Too Many Requests） |
仕組みは、TPM を割り当てると RPM が連動して決まり、どちらかを超えると 429 が返る、というものです。本番でトラフィックが増えて 429 が頻発したら、対処は2方向あります。
- クォータ調整：デプロイの TPM を引き上げる（そのリージョンのクォータ上限内で）。
- アプリ側でリトライ：429 が返ったら指数バックオフで少し待って再送する。SDK には標準のリトライ機構もある。
「429 は障害ではなく、設計で織り込むもの」と捉えるのが実務のコツです。チームで1つのリソースを共有するなら、APIM（API Management）を前段に置いてキー単位でトークン上限をかける手もあります（「共有地の悲劇」対策）。
【ここが説明できればOK①】
「デプロイに TPM を割り当てると RPM が連動し、超えると 429 が返る。対処はクォータ調整と指数バックオフのリトライ」——これを言えればOKです。
PTU（Provisioned Throughput Unit）｜スループットを予約する
従量（Standard）で運用していると、混雑時にレイテンシがブレたり、429 が出たりします。「応答速度と容量を安定させたい」という要件が出てきたときの選択肢が PTU です。
PTU（Provisioned Throughput Unit）とは、専用のスループットを予約購入する課金モデルです。従量課金と違い、あらかじめ確保した容量の範囲で安定したレイテンシと処理量を得られます。
| 観点 | Standard（従量） | Provisioned（PTU） |
|---|---|---|
| 課金 | 使ったトークン分だけ | 予約した容量分を固定で |
| レイテンシ | 混雑時にブレる可能性 | 安定（予約分は確保） |
| 向く場面 | 変動が大きい・まず始める | 安定した高負荷・速度保証が必要 |
判断はシンプルです。「トラフィックが読めない・少ない」なら Standard、「安定して大量・速度保証が要る」なら PTU。多くのプロジェクトは Standard で始め、負荷が育ってから PTU を検討する、という流れになります。
【ここが説明できればOK②】
「PTU は専用スループットを予約購入し、安定したレイテンシと容量を確保する課金モデル。安定した高負荷や速度保証が要る場面で従量から切り替える」——これを言えればOKです。
ログ / 監視｜診断ログとトークン使用量を見る
生成 AI アプリは「ブラックボックス」になりがちです。「なぜか遅い」「なぜかコストが高い」を放置しないために、監視を仕込みます。Azure OpenAI は 診断設定を有効化して Azure Monitor に流せます。
監視で見るべき代表的なものはこれです。
- トークン使用量：入力／出力トークンをメトリックで追える。コストの内訳が見える。
- リクエスト数・レイテンシ：どれだけ呼ばれ、どれだけ待たされているか。
- エラー率（429/500）：レート制限や障害の発生状況。
診断ログを Log Analytics に送れば、KQL（Kusto Query Language）で深掘りできます。「トークンを食っているのはどの時間帯・どの機能か」「429 はいつ増えたか」を KQL で集計すれば、クォータ調整やコスト削減の判断材料になります。インフラ監視と同じ「可観測性の型」を、生成 AI にも当てはめるイメージです。
【ここが説明できればOK③】
「診断設定を有効化して Azure Monitor / Log Analytics に流し、トークン使用量・リクエスト数・レイテンシ・エラー率を確認。KQL で深掘りできる」——これを言えればOKです。
コスト最適化｜バッチ・ストリーミング・キャッシュ
最後はコスト最適化です。生成 AI は使うほど課金されるので、いくつかの手筋を知っているだけで請求額が変わります。
- Batch API：急がない一括処理（夜間のまとめ処理など）を割引価格で非同期実行。リアルタイム性が要らない処理はこれに寄せる。
- ストリーミング：応答を1トークンずつ順次返す。総コストは変わらないが、体感速度が上がり「待たされている感」を減らせる（UX の最適化）。
- プロンプトキャッシュ：毎回同じ長い前置き（システムメッセージ等）をキャッシュし、入力トークンのコストを削減。
- モデルの適正化：品質が保てるなら軽量モデル（mini 系）に落とすのが最も効く。第3回の「入力/出力の課金差」と合わせて判断。
「急がない処理→Batch」「長い前置き→キャッシュ」「体感速度→ストリーミング」「そもそも→軽量モデル化」。この4枚のカードを状況で切ればコストは大きく下がるよ！
【ここが説明できればOK④】
「Batch API の割引・ストリーミングの体感速度改善・プロンプトキャッシュ・軽量モデル化でコストと UX を最適化する」——これを言えればOKです。
まとめ｜Azure OpenAI シリーズ 全5回
今回のポイントです。
- TPM / RPM / 429を理解し、クォータ調整とリトライで捌く
- PTUでスループットを予約し、安定したレイテンシ・容量を確保
- 診断ログ + KQLでトークン・レイテンシ・エラーを可視化
- Batch / ストリーミング / キャッシュ / 軽量モデル化でコスト最適化
お疲れさまでした。全5回で、Azure OpenAI を「概要 → 作成・デプロイ → 基本概念 → 守りと拡張 → 運用」という順に一周しました。この流れを押さえれば、GPT を安全に・コストを管理して・自社データと繋いで業務システムに組み込めます。さらに一歩進んで、複数モデル・エージェント・評価まで束ねたいときは、上位プラットフォームの Azure AI Foundry シリーズへ進みましょう。
Azure OpenAI シリーズ 全5回
- ①概要｜本家OpenAIとの違い・モデル・リージョン
- ②作成・デプロイ｜リソース作成・デプロイ・API/SDK呼び出し
- ③基本概念｜トークン・コンテキスト・課金・パラメータ
- ④セキュリティ・拡張｜キーレス・閉域・フィルター・RAG・関数
- ⑤運用・最適化（この記事）｜クォータ・PTU・監視・コスト
