ChatGPT で使われている GPT を、業務システムに組み込みたい——そう考えたとき、選択肢は2つあります。本家 OpenAI の API を直接叩くか、Azure OpenAI Service を経由するか。同じ GPT でも、この2つは「使い勝手」も「安心感」も大きく違います。企業でAIを使うなら、まずAzure OpenAI とは何者で、本家と何が違うのかを押さえておくのが第一歩です。
GPTを使うなら本家OpenAIでよくない？ わざわざAzure経由にする意味って何なの？ モデルの種類も多くてどれを選べばいいか分からない…
この記事は Azure OpenAI シリーズの第1回として、Azure OpenAI の「概要」だけに絞って次の4つを整理します。読み終えたときに、この4つを自分の言葉で説明できることをゴールにします。
- Azure OpenAI が何か（Azure 上でホストされる OpenAI モデル）を説明できる
- 本家 OpenAI API との違い（Azure 統合・SLA・データ保護）を理解している
- 利用可能なモデル（GPT-4o / o系 / embedding / 画像系）を把握している
- リージョン / クォータ / モデル可用性の考え方を理解している
なお、Azure OpenAI は現在 Azure AI Foundry という大きな作業場の中に位置づけられています（Foundry ＝ OpenAI を含む上位のプラットフォーム）。その関係は別シリーズで扱うので、ここでは「GPT を Azure で使うためのサービス」という土台に集中します。各セクション末に「ここが説明できればOK」の自己チェックを置いています。
Azure OpenAI とは？｜GPT を Azure 上で使うサービス
Azure OpenAI Service とは、OpenAI の GPT などのモデルを、Microsoft Azure 上でホストして企業向けに提供するサービスです。中身のモデルは本家と同じですが、Azure のセキュリティ・ガバナンス・SLA と一緒に使えます。
ポイントは「モデルは同じ、まわりが Azure」という点です。GPT-4o などのモデルそのものは本家 OpenAI と共通ですが、それを動かす基盤が Azure になることで、企業が求めるRBAC（権限管理）・ネットワーク分離・監査ログ・データの取り扱い保証が付いてきます。
たとえるなら、同じ食材（モデル）を、個人経営の店（本家 OpenAI）で食べるか、衛生管理と契約がしっかりした法人向けレストラン（Azure）で食べるかの違いです。味は同じでも、企業として使うなら「契約・保証・管理」が揃っている方が安心して導入できます。
【ここが説明できればOK①】
「Azure OpenAI は、GPT 等の OpenAI モデルを Azure 上でホストし、企業向けのセキュリティ・ガバナンス・SLA と一緒に提供するサービス。モデルは本家と同じ」——これを言えればOKです。
本家 OpenAI API との違い｜Azure統合・SLA・データ保護
「じゃあ本家で良くない？」という疑問に答えます。個人の趣味なら本家で十分ですが、企業システムに組み込むとなると、Azure OpenAI の3つの違いが効いてきます。
| 観点 | 本家 OpenAI API | Azure OpenAI |
|---|---|---|
| 認証・権限 | APIキー中心 | Entra ID / RBAC / マネージド ID で統合 |
| ネットワーク | インターネット公開 | VNet / Private Endpoint で閉域化できる |
| SLA | 明示的な企業向けSLAは限定的 | Azure の SLA が適用される |
| データの扱い | ポリシーに依存 | 入力データはモデルの学習に使われない（保証） |
特に企業導入で決め手になりやすいのがデータ保護です。Azure OpenAI では、ユーザーが送ったプロンプトや応答が、モデルの再学習に使われることはありません。「社内の機密情報を AI に投げても、それが学習データに吸われて他社に出る心配がない」——この保証があるかどうかは、企業にとって非常に大きな差になります。
加えて、既に Azure を使っている組織なら、認証・ネットワーク・監視を Azure に一本化できるのも大きな利点です。AI だけ別の管理体系にせず、既存のガバナンスに乗せられます。
【ここが説明できればOK②】
「本家との違いは Azure 統合（Entra/RBAC/VNet）・SLA・データ保護（入力がモデル学習に使われない）。企業導入では特にデータ保護とガバナンス統合が効く」——これを言えればOKです。
利用可能なモデル｜GPT-4o / o系 / embedding / 画像系
Azure OpenAI で使えるモデルは、役割ごとに種類が分かれています。全部を覚える必要はありませんが、「どれが何のためのものか」の地図を持っておくと、用途に応じて選べるようになります。
| モデル種別 | 役割（ざっくり） | 使いどころ |
|---|---|---|
| GPT-4o 系 | 会話・生成のマルチモーダル主力 | チャット・要約・生成・画像入力 |
| o 系（推論モデル） | じっくり考える高度な推論 | 難しい論理・数学・コード設計 |
| text-embedding 系 | テキストを数値ベクトルに変換 | 検索・RAG・類似度判定 |
| 画像系（DALL·E 等） | テキストから画像を生成 | 画像生成・素材作成 |
実務で最もよく使うのは GPT-4o 系（会話・生成）と embedding 系（検索・RAG）の2つです。「賢く答えさせる」なら GPT-4o、「自社データを検索させる」なら embedding、という組み合わせが RAG の基本形になります（詳しくは第4回で扱います）。難しい推論が必要な場面だけ o 系を使う、と覚えておけば十分です。
【ここが説明できればOK③】
「GPT-4o 系＝会話・生成、o 系＝高度な推論、embedding 系＝ベクトル化（検索/RAG）、画像系＝画像生成。用途で使い分ける」——これを言えればOKです。
リージョン / クォータ / モデル可用性｜「使いたいモデルがその地域にあるか」
最後に、Azure OpenAI で最初につまずきやすい落とし穴を押さえます。それが「モデルの可用性はリージョンごとに違う」という事実です。
本家 OpenAI は「API を叩けばどのモデルも使える」感覚ですが、Azure OpenAI ではリージョン（データセンターの地域）ごとに、使えるモデルとバージョンが異なります。「Japan East では使えるが、別のリージョンでは最新モデルがまだ来ていない」といったことが普通に起こります。
あわせて重要なのがクォータ（TPM）です。
- クォータ＝そのリージョンで自分に割り当てられた処理量の上限。TPM（Tokens Per Minute）という単位で管理される。
- クォータはリージョン単位で割り当てられる。つまり「どのリージョンにデプロイするか」で、使えるモデルも処理できる量も決まる。
「使いたいモデルが、そのリージョンにあるか？」を最初に確認するのが鉄則。ここを飛ばすと『デプロイしようとしたらモデルが選べない』でつまずくよ！
【ここが説明できればOK④】
「モデルの可用性はリージョンごとに異なり、クォータ（TPM）もリージョン単位で割り当てられる。どのリージョンにデプロイするかで使えるモデルと処理量が決まる」——これを言えればOKです。
まとめ
- Azure OpenAI＝GPT 等のモデルを Azure 上でホストし、企業向けの管理・保証と共に提供
- 本家との違いはAzure統合・SLA・データ保護（入力がモデル学習に使われない）
- モデルはGPT-4o 系 / o 系 / embedding 系 / 画像系を用途で使い分け
- モデル可用性・クォータ（TPM）はリージョン単位。最初に「そのリージョンにあるか」を確認
概要がつかめたら、次は実際に リソースを作り、モデルをデプロイして、API/SDK で呼び出す手順に進みましょう。第2回で「作成からデプロイ、最初のリクエストまで」を通しで整理します。
