Azure OpenAI Service

解決する課題

• 大規模モデルを自前で運用するのは非現実的 → 推論基盤をマネージドな API として利用したい
• 生成 AI を使いたいが、社内データや機密の取り扱い・コンプライアンスを満たす必要がある
• 既存の Azure 環境（認証・ネットワーク・監視）と一貫したガバナンスで AI を組み込みたい
• チャット・要約・分類・コード生成・埋め込み生成などを共通の APIでまとめて使いたい

主要概念と用語

• 基盤モデル（Foundation Model）: GPT 系の言語モデルや埋め込みモデルなど、汎用的に学習済みの大規模モデル
• デプロイ: 特定モデルを自分のリソースに紐づけて呼び出せる状態にしたエンドポイント単位。アプリはこのデプロイ名を指定して推論する
• トークン: 課金とモデルの入出力長の基本単位。入力トークンと出力トークンを合算して扱う
• コンテキスト長: 1 リクエストで扱える入力と出力のトークン上限
• 埋め込み（Embedding）: テキストをベクトル化する機能。検索や RAG の基盤になる
• RAG: 外部データを検索して根拠としてモデルに渡す手法。Azure AI Search などと組み合わせる
• コンテンツフィルター: 有害な入出力を検出・抑制する安全機構
• リージョン / クォータ: モデルが使えるリージョンと、利用可能なスループットの割り当て

仕様・制限・クォータ

• モデルや機能（チャット、埋め込み、画像など）の提供可否はリージョンによって異なる
• 利用枠はトークン毎分やリクエスト毎分のクォータとして割り当てられ、超過時はスロットリングされる
• 予測可能な高負荷向けに、スループットを事前確保するプロビジョニング型の課金も選べる
• コンテキスト長はモデルごとに上限があり、長文は分割や要約が必要になる
• 一部のモデルや機能は申請・承認が前提となる場合がある（提供条件は変動するため最新情報を要確認）

内部の仕組み

利用者はモデルそのものを管理せず、Azure がモデルの実行基盤をホストします。リソースを作成し、使いたいモデルをデプロイとして登録すると、固有のエンドポイントとデプロイ名が得られます。アプリは REST または各言語の SDK でそのエンドポイントを呼び出し、プロンプト（とパラメーター）を送ると推論結果が返ります。

入出力はトークン単位で処理され、リクエストはクォータの範囲内でスケジューリングされます。入出力にはコンテンツフィルターが適用され、安全性のチェックが入ります。認証は API キーに加えて Microsoft Entra ID（旧 Azure AD） によるトークン認証が使え、ネットワークはプライベート接続で閉域化できます。

設計パターン / ベストプラクティス

• RAG を基本に据える: モデルの内部知識に頼らず、Azure AI Search などで根拠を検索して渡し、回答の正確性と更新性を確保する
• プロンプトとパラメーターを外部化: 温度や最大トークンなどを設定として管理し、再現性とチューニングを容易にする
• リトライとバックオフ: スロットリング（レート超過）を前提に指数バックオフで再試行する
• 出力の検証: 構造化出力（スキーマ指定）や後段バリデーションで不正な応答を弾く
• モデル選択の最適化: 用途に応じて軽量モデルと高性能モデルを使い分け、コストと品質を両立する
• デプロイ名の抽象化: アプリ側はデプロイ名を設定値として持ち、モデル更新時の差し替えを容易にする

運用・監視

• メトリクスとログ: 呼び出し数、レイテンシ、トークン使用量、エラー率などを Azure Monitor で監視する
• 診断ログ: リクエストやコンテンツフィルターの挙動を診断設定でログ出力し、Log Analytics に集約する
• クォータ監視: スロットリングの兆候を捉え、必要に応じてクォータ引き上げやプロビジョニング型へ移行する
• コスト可視化: トークン使用量を機能やテナント単位で集計し、想定外の急増を検知する
• モデルのバージョン管理: モデルは更新・廃止されるため、サポート期限を追い、移行計画を持つ

コスト

• 基本はトークン量に応じた従量課金で、入力トークンと出力トークンの合計で増える
• モデルの性能が高いほど単価も高い傾向があり、用途に合った最小限のモデルを選ぶと無駄が減る
• 出力が長いほどコストが増えるため、最大出力トークンの制限やプロンプト設計でムダを抑える
• 安定して高負荷をかける場合は、**スループット確保型（プロビジョニング）**の方が予測しやすくなることがある
• 具体的な単価は変動するため、断定せず公式の料金ページで最新値を確認すること

セキュリティ

• 認証: API キーに加え、Entra ID とマネージド ID を使ったキーレス認証で資格情報の漏えいリスクを下げる
• ネットワーク: プライベートエンドポイントで閉域化し、パブリックアクセスを制限する
• 権限管理: ロールベースアクセス制御で最小権限を割り当てる
• データ保護: 送受信データは暗号化され、独自の暗号鍵による管理にも対応する
• コンテンツ安全性: コンテンツフィルターで有害な入出力を抑制し、プロンプトインジェクション対策も設計に含める
• 入力検証: ユーザー入力をそのままプロンプトに連結せず、検証とサニタイズを行う

Well-Architected の観点

• 運用上の優秀性: モデルの実行基盤はマネージドで、IaC によるデプロイ管理や Azure Monitor での一元監視がしやすい
• セキュリティ: Entra ID 認証、プライベートエンドポイント、ロールベースアクセス制御、コンテンツフィルターで企業要件を満たしやすい
• 信頼性: クォータとリトライ設計、リージョン分散で可用性を高める
• コスト最適化: モデル選択と出力制御、従量とプロビジョニングの使い分けで最適化する
• パフォーマンス効率: 用途別のモデル選択とプロビジョニング型でレイテンシとスループットを調整する

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# Azure OpenAI リソースを作成
az cognitiveservices account create \
  --name my-openai \
  --resource-group my-rg \
  --kind OpenAI \
  --sku S0 \
  --location eastus

# モデルをデプロイとして登録（モデル名やバージョンは提供状況に合わせる）
az cognitiveservices account deployment create \
  --name my-openai \
  --resource-group my-rg \
  --deployment-name gpt-chat \
  --model-name gpt-4o \
  --model-version "2024-08-06" \
  --model-format OpenAI \
  --sku-name Standard \
  --sku-capacity 1

# エンドポイントとキーを確認
az cognitiveservices account show \
  --name my-openai --resource-group my-rg \
  --query "properties.endpoint" -o tsv
az cognitiveservices account keys list \
  --name my-openai --resource-group my-rg