Azure OpenAI Service は、OpenAI のモデルそのものを Microsoft のガバナンス基盤に載せ替えた製品だ。モデルの中身は OpenAI 直接版とほぼ同じで、差は「周辺」にある。
OpenAI 直接版と何が違うのか
実質的な違いはモデル性能ではなく、契約・統制・ネットワークの 3 点に集約される。
- Azure AD / RBAC: 既存の組織アカウントでアクセス権を管理でき、API キーの配り回しを避けられる
- プライベートエンドポイント / VNet 統合: 通信を社内ネットワーク内に閉じられる
- データ所在地: デプロイするリージョンを選べるため、データの物理的な所在を契約要件に合わせられる
裏返すと、これらの要件がない個人開発では Azure のリソースグループや権限設定が純粋な手間になる。手早く LLM を試したいだけなら OpenAI 直接の方が立ち上がりが速い。
料金の構造
従量課金（トークン単価）に加え、プロビジョンドスループット（時間課金で性能を予約する）という体系がある。トラフィックが読めて遅延を保証したいエンタープライズ用途では後者が効くが、予約した分は使わなくても課金される。トークン単価自体は OpenAI 直接とほぼ同水準で、Azure の契約割引が乗る余地がある程度と考えておくとよい。
導入時のつまずきと運用上の注意
導入時の最初のつまずきは、利用したいモデルが申請制・リージョン限定であること。使いたいモデルが対象リージョンで提供されているかを最初に確認する。さらに見落としやすいのが、OpenAI が新モデルや新機能を出してから Azure 側に反映されるまでに時差がある点だ。最新モデルをリリース直後に使いたいプロジェクトでは、この追従ラグが意思決定の足かせになる。
運用面では、コンテンツフィルタリングの強度設定がアプリ仕様に影響することにも注意したい。フィルタが想定より強くかかると正当なリクエストまでブロックされるため、業務ドメインに合わせた調整を初期段階で検証しておくと、本番投入後の混乱を避けられる。
OpenAI 直接と最も違うのは「デプロイ」という単位
運用で最初に戸惑うのがここだ。OpenAI 直接ならアカウントに対して利用枠が決まるが、 Azure ではモデルをデプロイとして作成し、そのデプロイごとに処理能力を割り当てる。 リクエストで指定するのもモデル名ではなくデプロイ名になる。
この違いは設計に影響する。用途ごとにデプロイを分ければ、検証用の処理が本番の枠を 食い潰す事故を構造的に防げる。一方で、割り当てはサブスクリプションとリージョンの 上限を分け合う形になるため、デプロイを増やすほど 1 つあたりの枠は細くなる。 「とりあえず全部同じデプロイ」で始めると、後から用途を分離するときにアプリ側の 設定をすべて触ることになる。最初から用途単位で分けておく方が安い。
リクエストにはバージョンを指定します。新しいバージョンでレスポンスの構造や利用できるパラメータが変わることがあるため、検証したバージョンをコードに固定し、上げるときは差分を確認してから移行してください。あわせて、モデルには提供終了の予定日が設定されます。使っているモデルの終了予定を定期的に確認する運用が要ります。
日本から使うときの請求
Azure の日本での契約・請求は日本マイクロソフト株式会社が主体になる。海外法人との 直接契約になる API と違い、円建てで、適格請求書の要件を満たした請求書が国内から出る。 経理処理の手間や仕入税額控除の扱いを判断材料に含めるなら、この点は OpenAI 直接との実質的な差になる。詳細はページ下部の「日本で使うときの条件」を参照。