Azure OpenAI Serviceとは？Microsoft Foundry時代の最新モデル・料金・セキュリティを解説

Azure OpenAI Service(アジュール・オープンエーアイ・サービス)は、OpenAIの最先端モデルを、Microsoft Azureの統制基盤上で安全に利用できる企業向けプラットフォームです。

2025年11月のIgniteで「Azure AI Foundry」が「Microsoft Foundry」へ改名され、Azure OpenAI Service はその配下サービスとして位置づけが整理されました。

本記事では、Microsoft Foundry時代の現在地、主要モデルと用途別の選び方、料金設計(PAYG／PTU／Reservations)、Foundry IQ を含む活用パターン、Guardrails を含むセキュリティ、導入前に確認すべき制約までを、2026年6月時点の最新情報で体系的に解説します。

Azure OpenAI Serviceとは｜Microsoft Foundry時代の現在地

Azure OpenAI Service(アジュール・オープンエーアイ・サービス)は、OpenAIの最先端モデルを、Microsoft Azure の統制基盤上で安全に利用できる企業向けプラットフォームです。
　
GPT-5 系のテキスト生成・推論モデル、Codex 系の開発支援モデル、gpt-image 系の画像生成、sora-2 の動画生成、gpt-realtime 系の音声リアルタイム対話まで、用途の異なる OpenAI モデル群を、Azure のサブスクリプション・閉域ネットワーク・コンプライアンス認定の下で一元的に呼び出せます。

入力データはモデル学習や他顧客への提供に使われず、データレジデンシー・閉域接続・コンテンツフィルター(Guardrails)が標準で組み込まれているため、ChatGPT を直接業務利用する場合に比べて、機密情報を扱う企業システムとの統合がしやすいのが特徴です。
　

Microsoft Foundryへの改名と現在地

Azure OpenAI Service の提供母体だった「Azure AI Foundry」は、2025年11月の Microsoft Ignite で「Microsoft Foundry」へ改名されました。

旧称の「Azure AI Studio(2023年11月)」「Azure AI Foundry(2024年11月)」を経て3度目の名称改定で、Azure 配下の AI サービスではなく、Microsoft 全体の AI プラットフォームとして再定義された格好です。

この改名後、Azure OpenAI Service は Microsoft Foundry の中の「Foundry Models sold by Azure(Azure 直販モデル)」カテゴリに属する OpenAI モデル群として整理されています。サービスそのものが廃止されたわけではなく、既存のデプロイ・APIキー・SDK は引き続き同じ仕様で動作します。

公式の Foundry Models カタログでは、OpenAI 直販系のほかに、Microsoft MAI・xAI Grok・Anthropic Claude・Mistral・Meta Llama・Cohere など複数パブリッシャーのモデルが横並びで提供されており、Foundry Models 全体では1,900以上のモデルが利用可能とされています。Azure OpenAI Service という名称は残りつつも、実態は「Microsoft Foundry 配下の OpenAI モデル領域」を指す位置づけに変わっています。

OpenAI API(本家)との役割の違い

混同しやすいのが、OpenAI 本家が直接提供する OpenAI API（ChatGPT API） と、Microsoft が Azure 経由で提供する Azure OpenAI Service の役割の違いです。

利用できるモデル本体は同じ OpenAI のものですが、契約主体・SLA・データ取り扱い・統合先のエコシステムが異なります。以下の表で、両者の主な違いを整理しました。

観点	OpenAI API(本家)	Azure OpenAI Service
契約主体	OpenAI	Microsoft(Azure サブスクリプション)
SLA	OpenAI 規定	Azure SLA に準拠
データ取り扱い	OpenAI 規約	入力データはモデル学習に使われず、データレジデンシー指定可
閉域接続	標準では不可	VNet ／ Private Endpoint 対応
コンプライアンス認定	OpenAI 単体	Azure 全体の認定(SOC・ISO・HIPAA・GDPR 等)に組み込み
統合先	OpenAI 単体エコシステム	Azure AI Search・Foundry Agent Service・Microsoft 365・Power Platform

OpenAI API は最新モデルが先行して提供されることが多い反面、企業システムへの組み込みでは Azure 側の認証・課金・閉域接続・統制の仕組みを使う方が運用負担が軽いケースが多くなります。

「個人や少人数のプロトタイプは OpenAI API、業務システムや大規模本番は Azure OpenAI Service」という棲み分けが、AI総研の支援現場でも一般的です。

Microsoft 365 Copilot との役割の違い

Microsoft 365 Copilot は、Word・Excel・Teams・Outlook など Microsoft 365 アプリ上で動く SaaS 型の生成AI機能です。エンドユーザーがすぐ使える完成品である代わりに、機能カスタマイズや独自データとの統合は限定的です。

一方で Azure OpenAI Service は、自社で UI・データ連携・業務ロジックを構築する開発者向けの基盤です。GPT-5 系を呼び出す API として動き、独自アプリ・社内チャットボット・エージェントの内部エンジンに組み込みます。

「すぐに使いたい」なら Microsoft 365 Copilot、「自社業務に合わせて作り込みたい」なら Azure OpenAI Service という整理が、初期の意思決定では分かりやすい軸になります。

【関連記事】
Microsoft 365 Copilotとは？特徴・料金・導入方法を徹底解説

---

Azure OpenAI Serviceでできることと向いている用途

Azure OpenAI Service の活用範囲は、テキスト・コード・マルチモーダル・エージェント・音声まで広がっています。

本セクションでは、業務カテゴリごとに「何ができるか」「Azure OpenAI が向いているか／向いていないか」を整理します。モデル個別の選び方は次のセクションで扱うので、ここではユースケース側の俯瞰に絞ります。

テキスト処理(要約・翻訳・分類・抽出)

最も導入されているのが、業務文書の要約・翻訳・分類・情報抽出です。

契約書・議事録・問い合わせメール・社内マニュアルなど、構造化されていないテキストから要点を取り出すタスクは、GPT-5 系や o-series 推論モデルが得意とします。

大量の文書を継続処理する場合は、Batch API(公式の50%割引)と組み合わせて夜間バッチで回す設計が一般的です。リアルタイム性が要らないなら、PAYG をそのまま使うよりコストを大幅に下げられます。

コード生成・開発支援(Codex 系)

Codex シリーズ(gpt-5-codex から gpt-5.3-codex まで段階的にリリース)は、開発エージェント用途に特化したモデルです。コードレビュー、自動修正、テスト生成、リファクタリング提案を、人間レビュアーに近い精度で実行できます。

Codex CLI や VS Code Codex 拡張から呼び出すと、ローカル開発環境でそのまま使えます。GitHub Copilot と並んで、社内開発の生産性指標を変えるレベルのインパクトを出している領域です。

マルチモーダル生成と分析(画像・動画・音声)

画像生成・編集は gpt-image-2(GA)を中心に gpt-image-1.5(顔の同一性保持・inpainting対応)、動画生成は sora-2(執筆時点でプレビュー)、音声は gpt-realtime-2・gpt-realtime-whisper・gpt-realtime-translate と、用途別にモデルが揃っています。

製品マーケティング素材の生成、コールセンターの音声文字起こし、製造現場の画像検査支援など、テキスト以外のモダリティを業務に組み込むハードルが大きく下がりました。

エージェント／ナレッジ検索

社内ナレッジを横断検索して回答するエージェント、業務手順を自動化するワークフローエージェントなど、「対話だけでなく行動する」AI を構築する用途も主流になっています。

2026年時点では、後述する Foundry Agent Service ＋ Foundry IQ を活用パターンの中心に置くのが公式推奨です。旧 On Your Data は classic 扱いで新規モデル追加が停止しているため、新規実装は Foundry IQ 前提で設計します。

顧客接点の自動化(Realtime API＋SIP)

2025年10月の Realtime API SIP 対応により、電話回線を経由した音声対話 AI を組みやすくなりました。

コールセンターの一次対応、注文受付、予約変更といった「電話越しの定型業務」を、低レイテンシーの音声対話として実装しやすくなっています。gpt-realtime-2 では推論対応と指示追従の強化が入っており、会話の文脈を保持したまま複雑な処理を回せる水準に達しています。

向いている用途／向いていない用途

万能ではなく、得意領域と苦手領域があります。以下の表で、Azure OpenAI Service が「向いている」「条件付きで向いている」「向いていない」用途を整理しました。

評価	用途の例	理由
向いている	社内文書の要約・分類・抽出／コード生成・レビュー／RAGによる社内QA／マルチモーダル生成／音声リアルタイム業務	Foundry の統制と OpenAI モデルの汎用能力の両方を活かせる
条件付きで向いている	大規模・常時稼働の本番ワークロード(PTU 必須)／規制業界のミッションクリティカル用途(追加統制が必要)	コスト設計とガバナンス設計を別途必要とする
向いていない	完全オフラインでの推論／極端な低レイテンシー(数ミリ秒)要件／オープンウェイトを自社環境で改造する用途	クラウド前提・SaaS 型の制約があるため、自前ホスティング要件には不向き

規制が厳しい業界や、機密データを自社環境から一切出せないケースでは、Azure 自体の閉域接続では足りない場合があります。その際は、オンプレ向け Microsoft Foundry Local の検討や、業務切り分けによる段階導入が選択肢になります。

「全社で標準化したい AI 基盤」としてはほぼ第一候補ですが、用途次第では他クラウド AI (AWS Bedrock や Vertex AI) との組み合わせ・棲み分けも検討する価値があります。

---

Azure OpenAI Serviceの主要モデルと選び方

Microsoft Foundry 配下になった2026年時点では、Azure OpenAI Service で利用できるモデル数が大きく増えています。本セクションでは、用途別にどのモデルを選ぶかという観点で整理します。

個別モデルの最新リストは更新頻度が高いため、本文では2026年6月時点の主要ファミリーを示し、最新版は Microsoft Foundry 公式モデルカタログで確認してください。

GPT 汎用シリーズ(gpt-5 系)

テキスト生成・対話・知識回答の主力となるのが GPT-5 系です。基準モデルの gpt-5 に加え、2026年に順次追加された gpt-5.3 / gpt-5.4 / gpt-5.5、軽量版 gpt-5-mini ／ gpt-5-nano、自動アップデートで最新版に追随する gpt-chat-latest までが提供されており、Microsoft Foundry のカタログから直接デプロイできます。

対話用途では、自動更新で最新版に追随する gpt-chat-latest を優先的に検討するのが基本です。従来の対話特化モデル gpt-5-chat は 2026年6月29日に退役予定 で、置き換え先として gpt-chat-latest が案内されています。新規採用時は最新の モデル退役スケジュール を確認してください。

gpt-5 の入出力単価は100万トークンあたり入力 $1.25・出力 $10(2026年6月時点、PAYG)が基準価格帯で、gpt-5-nano は入力 $0.05・出力 $0.40 と桁違いに安く、簡単な分類・抽出を大量に回す用途に向いています。最新世代の gpt-5.5 などは性能と単価のバランスが gpt-5 と異なるため、公式 pricing ページで都度確認してください。

汎用 QA・要約・対話・分類は GPT-5 系で大半カバーできます。タスクの難易度が低い場合は gpt-5-mini ／ gpt-5-nano でコストを下げ、複雑な思考が必要な場合は次の推論モデルに切り替える、という使い分けが基本です。

推論モデル(o3 ／ o4-mini ／ o3-pro)

推論モデルは、「考えてから答える」を明示的に行うモデルです。複雑な数学・コード生成・法務分析など、ステップを踏んだ思考が必要な用途で精度が大きく改善します。

o3 が標準、o4-mini が軽量・高速版、o3-pro がより深い思考に最適化された上位版です。応答速度は GPT-5 系より遅く、トークン消費も多めなので、「ここぞ」というタスクに絞って使うのが定石です。

コード生成・開発支援(Codex シリーズ)

Codex シリーズは、コードに特化した GPT-5 派生モデルです。gpt-5-codex・gpt-5.1-codex・gpt-5.2-codex・gpt-5.3-codex が段階的にリリースされており、軽量版の codex-mini も用意されています。

Codex CLI や VS Code Codex 拡張から呼び出して、ローカルリポジトリのコードレビュー・テスト生成・リファクタリング提案を回すのが標準的な使い方です。社内の Pull Request 自動レビューに組み込めば、人間レビュアーの負荷を大きく削減できます。

画像生成モデル(gpt-image 系)

最新世代の gpt-image-2 が一般提供(GA)されており、これが画像生成・編集の第一候補になります。Limited Access として gpt-image-1 / gpt-image-1-mini / gpt-image-1.5(顔の同一性保持・inpainting 対応)も引き続き利用可能で、用途や登録状況に応じて使い分けます。

DALL-E 3 後継として、テキスト指示の精度・テキスト描画・画像入力(編集／inpainting)が大きく改善されており、マーケティング素材・モックアップ・商品写真の編集など、業務利用に耐える品質に到達しています。なお、画像の分類や異常検知のような視覚理解タスクは画像生成モデルではなく、GPT-5 系・GPT-4.1 系などの視覚理解対応モデル、または Azure AI Vision を使う点に注意してください。

動画生成モデル(sora ／ sora-2)

従来の sora に加え、最新版 sora-2(執筆時点でプレビュー)が動画生成を担います。sora-2 は Azure 公式ページで text-to-video のほか、入力素材を活用した派生生成にも対応していることが示されており、生成可能な動画の長さは 4 / 8 / 12 秒の短尺が指定値です。製品紹介動画・社内研修動画・SNS 用ショート動画の生成で編集工数を圧縮するユースケースが広がっています。

製品紹介動画・社内研修動画・SNS 用ショート動画の生成で、編集工数を大きく圧縮するユースケースが増えています。

音声・リアルタイムモデル

音声系は用途別に複数のモデルが並びます。以下の表で、主要モデルと用途を整理しました。

モデル	主用途	特徴
gpt-realtime-2	音声リアルタイム対話	推論対応・指示追従の強化
gpt-realtime-whisper	低レイテンシーストリーミング転写	ライブキャプション・録音監視向け
gpt-realtime-translate	リアルタイム翻訳	多言語イベント・カスタマーサポート向け
gpt-audio-1.5	音声生成・対話	tool calling と多言語性能の改善
gpt-4o-mini-transcribe	音声テキスト化(バッチ／オンデマンド)	低 WER ・低コスト
gpt-4o-mini-tts	テキスト読み上げ	自然な多言語音声合成

音声系モデルはコールセンター・電話受付・議事録自動化など、テキスト以外のチャネルでの業務自動化を後押ししています。提供ステータスは preview / GA がモデルごとに異なるため、利用前に公式モデルカタログでリージョン可用性と併せて確認するのが安全です。

運用を支える主な補助機能

モデルカタログだけでなく、運用を支える補助機能も整理しておきます。

• Model Router
  プロンプトを見て最適なモデルを自動選択する機能。GPT-5 系にも対応。コストと精度のバランスを動的に取りたいときに使う。
  
  

• Provisioned Spillover
  PTU の利用が枠を超えた場合に、自動で PAYG のデプロイへトラフィックを逃がす機能。2025年8月に GA。本番ワークロードの予測不能な負荷スパイクに耐える。
  
  

• Stored Completions / Prompt Cache
  プロンプトのキャッシュにより、繰り返し送る前提部分のコスト・レイテンシーを削減する。

これらの補助機能は Microsoft Copilot Studio などのローコードエージェント基盤と組み合わせても利用でき、モデルそのものの強化以上に運用コスト・安定性を底上げできます。

Foundry 経由で併載される他社モデルとの使い分け

Microsoft Foundry には、OpenAI 系以外の他社モデルも併載されています。代表的なのは以下です。

• Anthropic Claude(Opus 4.6・Fable 5 など)
• Mistral・Cohere・Meta Llama
• xAI Grok
• Microsoft MAI(thinking／Code／Image／Transcribe／Voice)
• gpt-oss(オープンウェイト)

Anthropic Claude は2026年に Microsoft Foundry へ展開され、Azure は GPT と Claude の両方のフロンティアモデルを1つのプラットフォームで提供する唯一のクラウドとして位置づけられています。

「Azure OpenAI Service という名称で契約するルート」は引き続き OpenAI 系が中心ですが、Foundry portal 上では他社モデルも同じデプロイ UI で扱えるため、ユースケースに応じてモデルを切り替える運用が現実的になっています。

用途別モデル選定の早見表

ここまでのモデル群を、用途別に「まずどこから検討するか」の早見表に落とすと以下のようになります。

用途	第一候補	代替・補助
汎用テキスト・対話	gpt-5	gpt-5-mini / gpt-5-nano(軽量・低コスト)
大量バッチでの分類・抽出	gpt-5-nano	Batch API 50%割引と併用
複雑な推論・コード設計	o3	o4-mini(軽量)／ o3-pro(より深い思考)
コードレビュー・生成	gpt-5-codex 系	Codex CLI／VS Code 拡張と組み合わせ
画像生成・編集	gpt-image-2(GA)	gpt-image-1.5／gpt-image-1-mini(Limited Access)
画像分類・異常検知・OCR連携	GPT-5 系／GPT-4.1 系の視覚理解	Azure AI Vision との組み合わせ
動画生成	sora-2(プレビュー)	sora(従来モデル)
音声リアルタイム対話	gpt-realtime-2	gpt-audio-1.5
音声文字起こし	gpt-4o-mini-transcribe	gpt-realtime-whisper(ストリーミング)
多言語翻訳・通訳	gpt-realtime-translate	gpt-5 系＋自前プロンプト

新モデルは継続的に追加されるため、実プロジェクトでは「用途要件→候補モデル数本→ベンチマーク→本採用」というプロセスをまず1サイクル回し、その後に PTU・Reservation などのコスト最適化に踏み込む順序が安全です。

---

Azure OpenAI Serviceで実装するエージェントとRAGの活用パターン

2026年の Azure OpenAI Service 活用は、単発の API 呼び出しから「エージェント」「RAG」を前提とした構成へシフトしています。本セクションでは、代表的な活用パターンを整理します。

社内ナレッジ検索エージェント

社内文書・マニュアル・チャットログを横断検索して回答する「社内QA エージェント」は、最も導入が進んでいるパターンです。

2026年現在の公式推奨構成は、**Foundry Agent Service(エージェント実行基盤)＋ Foundry IQ(マネージド知識レイヤー)**です。Foundry IQ は、Azure AI Search などで構築した企業データの knowledge base を Foundry Agent Service から MCP(Model Context Protocol)ツールとして呼び出し、引用付きの回答を生成できる仕組みを提供します。

ACL(アクセス制御)・Entra ID 認証・引用付き回答・Azure AI Search ベースの知識基盤を、自前で組み立てなくても利用できます。

旧 On Your Data 機能は2026年時点で classic 扱いとなり、新規モデル追加が停止しています。新規プロジェクトでは Foundry IQ から始め、既存の On Your Data 実装は Foundry IQ への移行計画を立てるのが現実的です。詳細は後段の「導入前に確認すべき制約」で扱います。

Codex系の開発エージェント

Codex シリーズと組み合わせて、開発者の手元で動くエージェントを構築できます。Codex CLI は、ローカルリポジトリのコード読み取り・編集・テスト実行を任せるための CLI ツールです。

Claude Code や GitHub Copilot 系のエージェントと並ぶ「コーディングエージェント」のひとつとして、Azure OpenAI 経由でも同じレベルの開発支援を組めるようになっています。

社内ポリシーで「機密コードを外部 SaaS に送れない」場合、Azure OpenAI Service の閉域接続を経由する Codex 系は有力な選択肢です。

顧客接点の自動化(Realtime API ＋ SIP テレフォニー)

電話越しの定型業務を AI に任せる構成は、Realtime API の SIP 対応(2025年10月)で実装ハードルが大きく下がりました。

コールセンターの一次対応、予約変更、注文受付などを、低レイテンシーの音声対話として実装しやすくなりました。gpt-realtime-2 では推論と指示追従が強化されており、複雑な分岐を含む会話フローも維持できる水準です。

「24時間対応を人手で回せない」「離職率が高い問い合わせ部門の負担を下げたい」というニーズに対しては、最も具体的な効果が出やすい活用パターンになっています。

マルチモーダル業務の実装パターン

画像・動画・音声を組み合わせる業務として、以下が代表的です。

• 製造現場の画像検査支援
  GPT-5 系の視覚理解機能や Azure AI Vision で異常検知の前処理・分類を行い、人間検査員の判断を補助
  
  

• マーケティング素材の量産
  gpt-image-2 で広告バナーや製品ビジュアルを生成、sora-2 で 4／8／12 秒の短尺 SNS 動画を量産
  
  

• コールセンター×音声分析
  Realtime Whisper でリアルタイム書き起こし、GPT-5 でサマリ生成、後続業務へ連携

「テキストだけ」だった AI 活用が、画像・動画・音声をまたぐワークフローに広がっています。

企業事例(メルカリ・海外金融／小売)

国内の代表的な活用事例として、メルカリは Azure OpenAI Service を出品体験の改善に組み込んでいます。出品時に商品画像を解析し、推奨される商品名を自動生成する機能を実装し、出品から販売までの導線を短縮しています。

海外では、CarMax が在庫車両のレビュー要約に Azure OpenAI Service を使い、数万件規模のレビュー処理を自動化した事例が知られています。Mass General Brigham(医療)、AT&T(通信)など、規制業界・大企業での導入も進んでいます。

国内の事例傾向としては、製造業の技術文書検索、金融業のコンプライアンス文書要約、流通業のカスタマーサポート自動化といった、「文書量が多く、人手では追いつかない領域」から導入が広がるパターンが目立ちます。

---

Azure OpenAI Serviceの料金設計

Azure OpenAI Service の料金は、単純な「モデル単価表」だけでは設計できません。PAYG・PTU・Reservations の3軸と、Global／Data Zone／Regional のデプロイ区分の組み合わせで決まります。

価格の最新値は変動するため、本文では2026年6月時点の基準値と設計の考え方を示します。最新価格は Azure OpenAI Service の公式 pricing ページ で、料金体系を整理した解説は Azure OpenAI Serviceの料金体系を解説 で確認してください。

課金体系の3軸(PAYG ／ PTU ／ Reservations)

Azure OpenAI Service の課金は、大きく以下の3軸に分かれます。

課金軸	仕組み	主な向き先
PAYG(Pay-As-You-Go)	入力／出力トークンあたりの従量課金	検証・PoC・トラフィックが少ない／読みづらいワークロード
PTU(Provisioned Throughput Units)	予約した処理能力に対する時間単価課金	常時稼働の本番ワークロード／予測可能な高トラフィック
Reservations	PTU の月次／年次予約による割引	1か月以上連続稼働するワークロードのコスト最適化

新規プロジェクトはまず PAYG で計測→負荷が安定したら PTU を検討→さらに長期固定であれば Reservation という順序が、AI総研の支援現場でも標準的な進め方です。

Global ／ Data Zone ／ Regional のデプロイ区分

PAYG／PTU のいずれも、デプロイ区分によって価格と挙動が変わります。

• Global
  世界中の Azure リージョンを横断してトラフィックを処理。最も低単価だが、処理が行われるリージョンを指定できない。
  
  

• Data Zone
  Microsoft が定める地理ゾーン(例：EU、米国)内で処理。データレジデンシー要件を一定範囲で満たせる。
  
  

• Regional
  特定のリージョン(例：Japan East、East US 2)内で処理。最も厳密なデータ所在制御が可能だが、その分単価は高い。

規制業界では Regional、社内データ標準では Data Zone、それ以外は Global、という使い分けが基本になります。

PTU の時間課金とReservationsの割引機構

PTU は「予約した処理能力に対する時間単価課金」です。月額ではなく時間単価ベースで、利用しなくても予約分の課金が発生します。

PTU 単独のままだと PAYG より割高になることが多く、Reservations(1か月／1年の予約)と組み合わせて初めてコストメリットが出る設計です。年次予約では月次予約より追加の割引が適用されるため、実額は Azure Pricing Calculator で月次・年次の両方を試算して比較するのが安全です。

PTU は最初の起動に最低ユニット数が必要なので、デプロイ前に必要 PTU 数の試算を Azure 公式の計算ツールで行うのが定石です。試算をスキップして「とりあえず PTU」を選ぶと、想定の数倍のランニングコストになる事故が起きやすい部分です。

Batch API・Prompt Cache などの割引機構

リアルタイム性が要らない処理は、Batch API と Prompt Cache でコストを大きく下げられます。

• Batch API
  非同期処理で24時間以内に結果を返す。標準価格から約50%割引。夜間バッチでの分類・抽出・要約に最適。
  
  

• Prompt Cache
  プロンプトの繰り返し部分(システムプロンプト等)をキャッシュ。キャッシュヒット部分は割引価格で課金される。
  
  

• Stored Completions
  評価・ファインチューニング用にチャット履歴を保存できる。データセット構築のコストを下げる。

「同じシステムプロンプトを大量のユーザーリクエストに付ける」設計では、Prompt Cache の有無で月額が数倍変わるケースもあります。

料金設計の流れ(PAYG 実測 → PTU 検討 → Reservation 判断)

設計の順序を間違えると、PTU 予約が過剰／過小になりやすくなります。AI総研の支援現場で標準的に使う流れは以下です。

1. PAYG で30〜60日運用し、月間トークン消費量・モデル別の比率・ピーク負荷を実測する
2. 実測値から PTU 必要数を試算(公式の Azure OpenAI Calculator を利用)
3. ピークだけ PTU では賄えない場合、Provisioned Spillover で PAYG への逃がし設計を追加
4. 月間使用が読めて1か月以上連続するなら、月次／年次 Reservation を比較して割引を確定
5. バッチ処理可能な部分は Batch API へ分離、共通プロンプトは Prompt Cache 対応の設計に直す

「いきなり PTU 予約」「いきなり Reservation」は避けたほうがよいというのが、最も伝えたい設計指針です。実測なしのコミットは、想定外のコスト固定化や処理能力の取り違えに直結します。

周辺コスト(Azure AI Search ／ Storage ／ Egress ／ Support)

トークン課金以外の周辺コストも見落としやすいポイントです。RAG なら Azure AI Search、ファイル系なら Azure Storage、APIの大量アクセスでは Egress(送信データ転送)、エンタープライズ運用なら Support Plan が乗ります。

周辺コストは案件の構成によって大きく変動するため、固定の比率では見積もれません。AI Search のインデックス容量、Storage のアクセスパターン、Egress の発生条件、Support Plan の階層など、項目ごとに Azure Pricing Calculator で個別試算するのが基本です。トークン単価だけ見て「安い」と判断すると、本番化のタイミングで予算が崩れやすい部分です。

---

Azure OpenAI Serviceの始め方

Azure OpenAI Service の利用開始は、Microsoft Foundry portal を起点とした流れに統一されつつあります。本セクションでは、検証〜本番デプロイまでの基本的な流れを整理します。

申請ステータスの最新(多くは申請不要、一部は要登録)

以前は Azure OpenAI Service の利用そのものに申請が必要でしたが、現在は多くのモデル・機能で個別申請は不要になりました。Azure サブスクリプションを持っていれば、リソース作成から数分で利用開始できます。

一方で、以下のような Limited Access モデルや高リスク機能 は引き続き登録・承認が必要です。GPT-5 系や o3 / o4-mini などの推論モデル、Codex シリーズは2026年6月時点では制限解除済みのため、Azure サブスクリプションがあれば追加申請なしでデプロイできます。

• computer-use-preview などの限定アクセス機能
• gpt-image-1 ／ gpt-image-1.5 など画像生成系の一部
• abuse monitoring のオプトアウト(ログ非保存)などのガードレール変更

「申請不要」と一律に聞かされても、自社が使いたいモデル・機能が Limited Access に該当している場合は数営業日〜数週間のリードタイムが入ります。プロジェクト計画ではここを織り込んでおく必要があります。

Microsoft Foundry portal でのリソース作成

利用開始の手順は以下が基本フローです。

1. Azure ポータルから新規リソースとして Azure OpenAI(Foundry Models)を作成
2. リソースを置くリージョンを選択(後述のリージョン制限あり)
3. Microsoft Foundry portal(旧 Azure AI Studio)にサインインし、作成済みリソースに接続
4. Playground でモデルを試した上で、本格デプロイ用のモデルバージョンを選定
5. デプロイ名を決め、デプロイタイプ(Global ／ Data Zone ／ Regional ／ PTU)を指定して作成

Foundry portal は2026年に大幅にリニューアルされており、旧 Azure AI Studio や Foundry classic portal の UI とは異なります。社内手順書がある場合は、リブランド前のスクリーンショットや手順が残っていることがあるため、最新の Foundry portal をベースに棚卸ししたほうが安全です。

モデルデプロイと API キー／エンドポイント取得

デプロイが完了すると、リソース単位で API キーとエンドポイント URL が払い出されます。具体的な取得手順は Azure OpenAI APIキーの取得方法と利用手順 を参照してください。

API キーは認証情報なので、Azure Key Vault に格納し、アプリ側からは Managed Identity 経由で取得する設計が推奨です。生のキーをコードリポジトリにコミットしてしまう事故は依然として多いため、Microsoft Entra ID 統合をデフォルトに据えるのが安全です。

アプリ連携(Azure SDK ／ LangChain ／ Semantic Kernel ／ MCP)

クライアント側の連携手段は複数あります。

• Azure SDK(Python ／ .NET ／ Node.js 等)
  Azure OpenAI 専用クライアントを使う。認証・リトライ・テレメトリが標準装備。
  
  

• LangChain ／ LlamaIndex
  OSS のフレームワーク。OpenAI 用の実装を Azure OpenAI 用に切り替えるだけで動く。
  
  

• Semantic Kernel
  Microsoft 純正の AI オーケストレーション SDK。プラグイン・プランナー・メモリ機能が組み込み済み。
  
  

• MCP(Model Context Protocol)
  外部ツールやデータソースとモデルをつなぐオープン標準。Foundry Agent Service や Foundry IQ もこのプロトコルで動く。

新規プロジェクトでは Semantic Kernel または LangChain ＋ MCP の組み合わせから入ると、エージェント化への拡張がしやすくなります。

---

Azure OpenAI Serviceのセキュリティとコンプライアンス

Azure OpenAI Service の最大の選定理由のひとつが、セキュリティとコンプライアンスの統制レベルです。本セクションでは、企業要件として確認すべき項目を整理します。

入力・出力データの非学習とデータレジデンシー

最も重要なのは、入力・出力データがモデル学習にも他顧客のサービス提供にも使われないという点です。Microsoft 公式は「顧客の入力・出力・埋め込み・学習データは、他顧客・OpenAI・OpenAI の基盤モデル学習のいずれにも提供されない」と明示しています。

データレジデンシーは、デプロイ区分(Global ／ Data Zone ／ Regional)によって処理場所が変わります。日本のデータを国内に留めたい場合は、Japan East リージョンの Regional デプロイを選択するのが基本です。

閉域接続と認証認可の設計

ネットワーク面では、Azure OpenAI リソースを Virtual Network(VNet)に閉じ込め、Private Endpoint 経由でのみアクセス可能にする構成が標準的です。インターネット経由のアクセスを完全に遮断できるため、社外への情報漏えい経路を物理的に塞げます。

認証認可では、Microsoft Entra ID(旧 Azure AD)でユーザー認証、RBAC(Role-Based Access Control)でリソースごとの権限制御を行います。エージェントを動かす場合は、エージェント単位の認証情報を発行する Entra Agent ID によって、人間ユーザーとエージェントの権限を分離する運用が可能になりました。

Foundry RBAC(Foundry portal 上の細粒度ロール)も2026年に整理され、開発者・運用者・監査担当者ごとに役割を分けやすくなっています。

Guardrailsの3つの介入点と主な機能

旧称「Content Filters」は、2026年時点で Guardrails として整理され、入力・ツール呼び出し・出力の3つの介入点で防御層が組まれています。

機能	介入点	役割
Prompt Shields	入力	直接的なジェイルブレイク／間接プロンプトインジェクション攻撃を検出・ブロック
PII Detection	入力／出力	個人識別情報の検出と、出力に含めないよう制御
Spotlighting	入力	外部文書からの間接攻撃を、信頼レベルの低い入力として明示
Groundedness Detection	出力	出力が参照元データに基づいているかを検証し、ハルシネーションを抑制
Jailbreak Risk Detection	入力	ジェイルブレイク試行を統計的に検出

Guardrails は Microsoft Foundry のレイヤーで提供されるため、Azure OpenAI 単体に依存せず、他社モデル併載でも同じ統制基盤の上で動かせる点も強みです。コンプライアンス担当者の視点では、モデルが変わっても統制設計を流用できる構造になっています。

主要認定・コンプライアンスと日本リージョン

Azure OpenAI Service は、Microsoft Azure 全体の SOC 1／2／3、ISO 27001／27017／27018、HIPAA、GDPR、PCI DSS など主要認証の範囲に組み込まれています。

医療・金融など特定業界の要件については、別途 BAA(Business Associate Agreement) や業界別契約が必要なケースがあります。HIPAA であれば、Enterprise Agreement・Microsoft 365・CSP のいずれかのライセンス形態で BAA が結ばれている前提で利用可能です。

日本リージョン(Japan East ／ Japan West)でも主要モデルがデプロイ可能になっていますが、最新世代の限定アクセスモデルは East US 2 や Sweden Central から先に提供されるケースが多いため、リージョン別の可用性は別途確認が必要です(次のセクションで扱います)。

---

Azure OpenAI Service導入前に確認すべき制約

セキュリティと並んで、導入前に確認しておかないと後で詰まる論点があります。本セクションでは、AI総研の支援現場で繰り返し相談を受ける「見落としやすい論点」を5点に絞って整理します。

リージョン別モデル可用性のズレ

Azure OpenAI Service のモデルは、リージョンによって利用可否と提供時期が異なります。最新世代の限定アクセスモデルは、East US 2 や Sweden Central から先に提供され、Japan East などへの展開はしばらく遅れる傾向があります。

「日本に置きたいモデル」と「最新で使いたいモデル」が両立しないケースは珍しくありません。データレジデンシーを優先するなら旧世代を Japan East で運用し、最新検証は East US 2 の別リソースで行うといった多リージョン分割が現実的な解になることがあります。Azureのリージョン ごとの可用性と特徴は別記事で整理しています。

リージョン別可用性は変化が早いため、調達計画前に Microsoft Foundry の Region availability ページ で必ず最新を確認してください。

Limited Access モデルの登録要件と承認フロー

「申請不要」と一般化されがちですが、computer-use-preview や gpt-image-1 系などの一部モデル・機能は Limited Access として個別登録が必要です。承認には数営業日〜数週間かかることがあります。GPT-5 系や推論モデル・Codex 系は2026年6月時点で制限解除済みですが、扱いは随時変更されるため、利用前に最新の Limited Access ページを確認するのが安全です。

abuse monitoring のオプトアウト(ログを Microsoft 側に保存しない設定)など、ガードレール変更を伴う構成も同じく個別承認が必要です。これらは PoC 開始のタイミングで余裕を持って申請しておかないと、開発スケジュールが詰まる典型パターンです。

社内ポリシーで「ログを Microsoft 側に保存させない」要件がある場合、要件定義の段階で abuse monitoring オプトアウトの申請を進めるのが安全です。

PTU コミット前の PAYG 実測の必須化

料金設計セクションでも触れた通り、PTU は実測なしにコミットすると事故が起きやすい仕組みです。少なくとも30〜60日の PAYG 実測値がない状態での PTU 予約・Reservation 契約は避けたほうが安全です。

具体的に詰まるのは、「想定よりトークン消費が3倍だった」「ピークだけ PTU が足りない」「PTU の遊休時間が長くて PAYG より高い」というパターンです。Provisioned Spillover で PAYG への逃がしを組み込めばリスクは抑えられますが、設計の前提が変わるため、最初から組み込んでおく価値があります。

Foundry移行期のドキュメント断絶

2025年〜2026年のリブランド期は、ドキュメントが「Foundry classic」と「新 Foundry」に分かれている状態です。learn.microsoft.com 上でも、旧 classic 配下のパス(/azure/foundry-classic/openai/) と新 Foundry 配下のパス(/azure/foundry/openai/) の両方が並走しています。

社内手順書が classic portal 前提で書かれている場合、新 Foundry portal では UI が変わっていてそのまま再現できないことがあります。「Foundry の何を見るべきか」を最新ドキュメントで確認する習慣が、移行期は特に重要です。

「On Your Data」廃止予告と Foundry IQ への移行タイムライン

社内データを使った RAG 機能として広く使われてきた「Azure OpenAI On Your Data」は、classic 扱いとなり新規モデル追加が停止しています。Microsoft は Foundry Agent Service ＋ Foundry IQ への移行を公式に推奨しています。

公式の Azure OpenAI On Your Data (classic) ドキュメント では、退役予定日が 2026年10月14日 とアナウンスされています。退役スケジュールは公開後も変わる可能性があるため、移行計画を立てる前に同ページで最新を確認してください。なお、利用モデル単位の退役予定は別途 Microsoft Foundry の Model retirement schedule で確認します。

新規 RAG プロジェクトは Foundry IQ から始め、既存 On Your Data 実装は段階的に Foundry IQ へ載せ替えるのが現実的な進め方です。Foundry IQ は Azure AI Search を中心としたマネージド知識レイヤーとして、Entra ID 認証・引用付き回答・Foundry Agent Service との MCP 連携を提供するため、自前で組み立てていた RAG パイプラインを大きく簡素化できます。

---

Azure OpenAI Serviceを業務に定着させるなら

Azure OpenAI Service のモデル・料金・セキュリティを押さえれば、「使うための準備」は整います。

ただし、PoC を本番運用に定着させ、複数業務に横展開する段階では、モデル選定・コスト設計・ガバナンス・業務プロセス再設計を並行で回す必要があります。ここで詰まると、「PoC は動いたが本番化できない」状態が長引きます。

このレイヤーを担うのが、Microsoft Foundry や Azure OpenAI Service と組み合わせて使うエンタープライズ AI エージェント基盤です。AI 総合研究所の AI Agent Hub は、社内ナレッジ検索・業務文書処理・コーディング支援・コールセンター自動化といった用途別エージェントを、自社の Azure テナント内で安全に運用するための構成と運用体制をパッケージで提供します。

AI 総合研究所の専任チームが、要件整理・PoC 設計・本番展開まで一貫して伴走支援します。詳細は AI Agent Hub の LP で具体例とあわせてご確認ください。

---

まとめ

本記事では、Azure OpenAI Service について、Microsoft Foundry 時代の現在地・主要モデルと選び方・活用パターン・料金設計・始め方・セキュリティ・導入前に確認すべき制約までを、2026年6月時点の最新情報で解説しました。要点を改めて整理します。

• Azure OpenAI Service は 2025年11月の Microsoft Ignite で「Microsoft Foundry」へ改名された統合 AI プラットフォーム配下のサービスとして再整理されており、OpenAI 最新モデルを Azure 経由で安全に利用する標準ルートに位置づけられている
  
  

• 利用できるモデルは GPT-5 系・Codex 系・推論系・gpt-image 系・Sora 系・Realtime 系へと大きく広がっており、「全カタログを覚える」より「用途別に第一候補を決めて検証→本採用」する選定プロセスが現実的
  
  

• 料金は PAYG・PTU・Reservations の3軸で設計する。PoC は PAYG で実測→負荷が安定したら PTU を検討→長期固定なら Reservation の順序が安全で、Batch API・Prompt Cache の割引機構も併せて活用する
  
  

• RAG の新規実装は Foundry Agent Service ＋ Foundry IQ が公式推奨。旧 On Your Data は classic 扱いで新規モデル追加が停止しているため、既存実装も移行計画を立てる
  
  

• セキュリティは Guardrails(Prompt Shields／PII Detection／Spotlighting／Groundedness)＋閉域接続＋データ非学習 が標準。SOC・ISO・HIPAA・GDPR・BAA の認定範囲に組み込まれており、規制業界の要件にも対応できる

Azure OpenAI Service は、単発の API として使う段階を超え、エージェント・RAG・マルチモーダル業務までを Foundry の統制下で組み立てる基盤に成長しました。

導入を成功させる鍵は、最新モデルを追いかけることそのものよりも、「自社のどの業務に・どのモデルで・どの料金体系で・どの統制範囲で運用するか」という設計判断にあります。まずは1業務に絞って PoC を回し、運用データを取った上で本格展開へ広げる順序が、最も着実な進め方になります。