2026.08.16 AI

Azure OpenAIでGPT-5を使う方法｜デプロイ・クォータ・推論パラメータの実装手順

Azure上でGPT-5系のモデルを動かそうとして、デプロイ画面にモデルが出てこない、あるいはコードは通ったのに応答が空で返ってくる、という詰まり方をした人は多いはずです。原因はコードの書き方ではなく、デプロイ種類とリージョンの組み合わせ、割り当てられたクォータ、推論モデル特有のパラメータ仕様という三つの前提にあります。

この記事では、Azure OpenAI（Microsoft Foundry Models）でGPT-5系を呼び出すまでの手順を、実装者が実際に踏む順番で整理します。記載する数値とモデル名は2026年8月16日時点でMicrosoft Learnの公開ドキュメントを実測したものです。提供状況は更新頻度が高いため、実装前に自分のサブスクリプションで再確認してください。

まとめ：GPT-5系をAzureで動かす前に決める三点

結論から書きます。Azure上でGPT-5系を動かすときに最初に決めるのは、デプロイ種類・クォータ階層・API形式の三点で、この三つが決まればコードはほぼ機械的に書けます。

  • デプロイ種類：GPT-5系は原則としてグローバル標準（GlobalStandard）が第一候補です。リージョン内で処理を完結させる標準／リージョン別デプロイには、2026年8月16日時点でGPT-5系の提供がありません。データ所在の要件がある案件では、この一点で構成が決まります。
  • クォータ階層：クォータは2026年5月7日以降サブスクリプション単位で管理され、Free TierとTier 1〜Tier 6の7段階が割り当てられます。Tier 1のgpt-5（GlobalStandard）は10,000 RPM／1,000,000 TPMです。
  • API形式：新規実装ではv1 API（エンドポイント末尾に openai/v1 を付ける形式）を選び、日付付きの api-version 指定を持ち込まないのが素直でしょう。OpenAI公式クライアントをそのまま使えます。

以降ではこの三点を数値付きで掘り下げ、最後にAzure側を選ぶ条件とOpenAI直APIに寄せるべき場面を整理します。サービス全体の概要や料金の考え方はAzure OpenAI Serviceとは？できること・料金・導入事例まで実務目線で解説を、どのモデルを選ぶかという手前の判断はAzure OpenAI Serviceのモデル一覧と選び方を先に読むと接続がよくなります。

Azure OpenAIでGPT-5系を呼び出すまでの三工程と前提条件

Azure上でGPT-5系を動かす作業は、リソース作成・モデルデプロイ・API呼び出しの三工程に分解できます。OpenAI直APIがアカウント作成とキー発行だけで済むのに対し、Azure側はリソースという器を先に用意する必要があり、ここが最初の段差です。

リソース作成で決めるのは名前ではなくリージョンと認証方式の二点

最初に作るのはFoundryリソースまたはAzure OpenAIリソースです。この時点で決めるのはリソース名ではなく、配置するリージョンと、後段で使う認証方式の二つになります。認証はAPIキーとMicrosoft Entra IDの二択で、Entra IDを使う場合は対象のIDに Cognitive Services OpenAI User ロールを割り当てておきましょう。キーを環境変数に置く運用は検証段階では手早いものの、本番ではキーの配布と失効の管理が重くなるため、初期からEntra IDに寄せておくと後戻りが減ります。

なお、グローバル標準を使う限り、リソースを置いたリージョンと推論が処理されるリージョンは一致しません。国内リージョンにリソースを作れば国内で処理される、という理解のまま設計すると、データ所在の説明が後で崩れます。

デプロイ名とモデル名を分けて管理すると版の差し替えが楽になる

次に、モデルをデプロイします。ここでAzure特有の概念として出てくるのが「デプロイ名」です。OpenAI直APIではリクエストの model にモデル名（gpt-5 など）を渡しますが、Azureでは自分が付けたデプロイ名を渡します。デプロイ名を用途ベースにし、背後のモデル版はデプロイ設定で差し替えられる状態にしておくと、モデルの提供終了に合わせてアプリ側のコードを触らずに切り替えられます。提供終了と自動アップグレードの扱いはAzure OpenAIのモデル廃止に備える方法で手順化しているので、デプロイ名の設計と併せて決めておくと安全です。

呼び出しはv1 APIを既定にしてapi-version指定を持ち込まない

三工程目の呼び出しでは、2025年8月から提供されているv1 APIを既定に据えます。従来は月次で新しいAPIバージョンが出るたびにコードと環境変数を更新する必要がありましたが、v1 APIでは日付付きの api-version パラメータが必須ではなくなりました。

デプロイの種類と対応リージョンで決まるGPT-5系の使える範囲

GPT-5系が「デプロイ画面に出てこない」原因の大半は、選んだデプロイ種類とリージョンの組み合わせにモデルの提供がないことです。Microsoft Learnのリージョン可用性ページはデプロイカテゴリごとにタブが分かれており、同じモデル名でもタブを切り替えると可否が変わります。

デプロイ種類ごとに処理される場所と提供されるモデルの幅が違う

標準系のデプロイは、処理される場所の広さで分けた三段階です。グローバルはモデルがデプロイされている任意のAzureリージョン、データゾーンは米国・EU・アジア太平洋（APAC）といったMicrosoftが定義したデータゾーン内、標準／リージョン別はデプロイに紐づいたリージョンで処理されます。推論として実行できる操作はどれも同じで、違いは課金・スケール・遅延特性、そして提供モデルの幅にあります。2026年8月16日時点のアジア太平洋タブを実測すると、次のような差が出ました。

デプロイ種類 japaneastでのGPT-5系 処理される範囲
グローバル標準 gpt-5／mini／nano／pro／5.1 任意のAzureリージョン
データゾーン標準 gpt-5.2／5.4／5.4-mini など APACデータゾーン内
標準／リージョン別 提供なし（gpt-4o系などのみ） デプロイのリージョン

つまり、東日本リージョンの中だけで推論処理を完結させたいという要件を立てた瞬間、GPT-5系は候補から外れます。データ所在の要件がAPAC内で足りるならデータゾーン標準が使え、そこではgpt-5の無印ではなくgpt-5.2以降の版が並ぶ組み合わせになります。

プレビュー版かどうかと提供終了日はデプロイ時点で記録しておく

GPT-5系の中には、gpt-5-chatやgpt-5.2-chatのようにプレビュー扱いの版があります。Microsoftはプレビュー版を本番で使わないよう案内しており、プレビュー指定のモデルは通常のライフサイクル規定に従いません。検証で速く動いた版がそのまま本番に残る事故を避けるため、デプロイ時点でプレビューかどうかを記録しておきましょう。

コンテキストウィンドウと出力上限も版ごとに異なる仕様です。gpt-5（2025-08-07）は入力272,000・出力128,000で合計400,000トークン、gpt-5.4やgpt-5.5の世代では合計1,050,000トークン（入力922,000・出力128,000）と桁が変わります。長文処理を前提にした設計では、この差が分割処理の要否を決める条件です。小型版の性格の違いはGPT-5.4 mini・nanoとは｜料金・ベンチマーク・mini/nanoの使い分けを解説で比較しています。

GPT-5系のクォータ階層とレート制限の読み方および増枠申請の判断

デプロイ画面までたどり着いても、クォータが0であればデプロイは作れません。クォータ管理は2026年5月7日以降に変わり、リソース単位・リージョン単位ではなくサブスクリプション単位で追跡する方式になりました。

共有プールとクォータ階層という二つの軸で使える枠が決まる仕組み

変更後のクォータは共有プールに統合されます。グローバル標準では同じモデルとバージョンのデプロイがサブスクリプション内の全リージョンで一つのプールを共有し、データゾーン標準ではデータゾーンごとに一つのプールを共有する形です。検証用と本番用でリージョンを分けても、同じモデル版を使う限りクォータは奪い合いになります。

もう一つの軸がクォータ階層です。Free TierとTier 1からTier 6までの7段階があり、Tier 6が最も大きいクォータを持ちます。初期の割り当ては、そのモデルの使用状況とMicrosoftとの契約関係（EAやMCA-Eなど）で決まり、使用量が増えると自動的に上位階層へ移る仕組みです。自動昇格を止めたい場合は、コントロールプレーンAPIで tierUpgradePolicy を NoAutoUpgrade に設定してオプトアウトできます。

クォータ階層ごとの実数を並べて必要なスループット規模を見積もる

階層が上がるとどれだけ変わるのかを、gpt-5のグローバル標準で並べると次のようになります。

クォータ階層 RPM（gpt-5・グローバル標準） TPM（同）
階層1 10,000 1,000,000
階層3 90,000 9,000,000
階層5 300,000 30,000,000
階層6 450,000 45,000,000

同じ階層1でも、データゾーン標準のgpt-5は3,000 RPM／300,000 TPMと桁が下がります。データ所在を優先した構成はスループット面で不利になるため、要件のどちらを優先するかを設計段階で決めておきましょう。増枠が必要な場合はクォータ要求フォームから申請でき、承認されても階層自体は変わらず割り当て量だけが増えます。申請は受け取った順に処理され、既存の割り当てを実際に使っている利用者が優先されるため、枠だけ先に押さえる進め方は通りにくいと考えたほうが現実的です。

なお、使用量メトリックがクォータを下回っていても429（要求が多すぎます）が返る場合があります。バースト的な送信パターンでは瞬間的な超過が起きるため、再試行ロジックの実装と、負荷を段階的に上げるテストを前提に組んでおきます。遅延の安定を強く求めるワークロードなら、従量のクォータを追いかけるよりプロビジョニング済みスループット（PTU）への切り替えを検討する段階です。

v1 APIでの呼び出しとOpenAI直APIとの実装差分の要点

v1 APIの登場で、AzureとOpenAI直APIのコード差はかなり縮みました。以前は AzureOpenAI() 専用クライアントとapi-versionの指定が必須でしたが、現在はOpenAI公式クライアントに base_url を渡すだけで動作します。

from openai import OpenAI

client = OpenAI(
    api_key=os.getenv("AZURE_OPENAI_API_KEY"),
    base_url="https://YOUR-RESOURCE-NAME.openai.azure.com/openai/v1/",
)

response = client.chat.completions.create(
    model="YOUR-DEPLOYMENT-NAME",
    messages=[
        {"role": "user", "content": "実装手順を三つに分けて説明して"},
    ],
    max_completion_tokens=5000,
    reasoning_effort="medium",
)

差分として残るのは、実質的に次の三点です。第一に、base_url にリソース名と openai/v1 を含めること。第二に、model にモデル名ではなくデプロイ名を渡すこと。第三に、Entra IDを使う場合は api_key にトークンプロバイダーを渡すことです。base_url は openai.azure.com 形式と services.ai.azure.com 形式のどちらも受け付けます。

SDKそのものの使い方や、Responses APIと従来のChat Completions APIの書き分けはOpenAI Python SDKの使い方｜インストールから最新クライアント・Responses APIまでにまとめています。Foundryという上位のプラットフォーム概念との関係が曖昧だと、ポータルのどこを操作しているのか分からなくなるため、前提の整理にはAzure AI Foundryとは何か？概要と基本的なコンセプトを解説が入口になります。

reasoning_effortとverbosityの指定で挙動が変わる場面

GPT-5系は推論モデルであり、従来のチャットモデルとはパラメータの体系が違います。ここを踏まずに移行すると、リクエストが通らないか、通っても応答が期待と食い違います。

推論モデルではサポートされなくなるパラメータを先に洗い出しておく

推論モデルでは、temperature・top_p・presence_penalty・frequency_penalty・logprobs・top_logprobs・logit_bias・max_tokens といったパラメータがサポートされません。特に max_tokens は max_completion_tokens に置き換わるため、既存コードをそのまま移すと出力が意図した長さで止まらなくなります。温度を下げて出力を安定させる、というチューニングの型もここでは使えません。

reasoning_effortは品質のつまみとして段階的に上げる

代わりに使うのが reasoning_effort です。モデルが回答前にどれだけ考えるかを制御するパラメータで、サポートされる値には none・minimal・low・medium・high・xhigh・max があります。ただし受け付ける値と既定値はモデルごとに異なり、たとえばgpt-5.1では既定が none のため、以前の推論モデルから移した場合は明示的に値を渡す必要があります。逆にgpt-5.1-codex-maxのように none を受け付けないモデルもあるので注意しましょう。

Microsoftの案内でも、品質が落ちたときに真っ先に手を出す先ではなく、チューニングのつまみとして扱うよう書かれています。実装では既定値のまま計測を取り、許容範囲を見てから段階的に上げるのが安全です。消費した推論トークンは、Chat Completions APIなら completion_tokens_details の reasoning_tokens で確認できます。

verbosityとreasoning.modeで出力量を調整する

GPT-5世代で加わった verbosity は、low・medium・high の三段階で出力の簡潔さを制御するパラメータです。reasoning_effort が思考量、verbosity が出力量という役割分担になっており、両方を混同すると「短く答えさせたいのに思考を削ってしまう」という調整ミスが起きます。さらにgpt-5.6世代では reasoning.context の既定が all_turns になっており、コードを変えなくても複数ターンの会話でトークン消費が増える点は見積もりに影響します。以前の挙動を保ちたい場合は current_turn を明示しましょう。

ツール呼び出しで失敗しないためのAPIの選び方と移行時の注意点

移行時に最も踏みやすい地雷が、関数呼び出し（ツール）と推論の組み合わせです。新しい世代では、Chat Completions APIでツールと推論を同時に使うとリクエストが失敗します。

gpt-5.6以降のモデルはChat Completions APIもツールもそれぞれサポートしていますが、その二つを同時には受け付けません。tools を含むチャット完了要求は、関数ツールとreasoning_effortの併用がサポートされない旨のエラーで落ちます。これらのモデルは reasoning_effort の既定が medium のため、パラメータを送っていなくても tools を送るだけでエラーになる仕様です。以前の推論モデルからデプロイをアップグレードした直後にツール呼び出しが失敗し始めるのは、この変更が原因になっています。

回避策は二つあります。推論とツールを併用するならResponses APIへ移すこと、Chat Completions APIを維持する必要があるなら tools を送る全リクエストで reasoning_effort に none を設定することです。後者では推論が提供していた計画の質が失われるため、新規実装であればはじめからResponses API側に寄せておくほうが後の分岐は減ります。

gpt-5.4とgpt-5.5をResponses APIで長時間動かす場合、各アシスタントメッセージに phase 値を付けることが案内されています。省略可能なパラメータではあるものの、省くとモデルが前置きを最終回答と解釈して早期に停止する可能性があります。

Azure側でGPT-5系を採用する条件と直APIに寄せるべき場面

ここまでの制約を踏まえて、案件でどちらを選ぶかを言い切ります。判断材料は、データ所在の要件・必要なスループット・使いたい機能の三つです。

Azure側を採用すべきなのは、次の条件に当てはまる場合です。既にAzureにデータ基盤や業務システムがあり、Entra IDによる認証とロール管理をそのまま延長したい案件。ネットワーク境界を含めた社内規程に沿う必要があり、リソース単位で監査ログを揃えたい案件。そしてデータの処理範囲をAPAC内に限定できればよい案件です。三つ目に該当するなら、データゾーン標準でgpt-5.2以降の版を選ぶ構成が現実解になります。

逆に見送ったほうがよいのは、次の場面です。第一に、日本国内リージョンで処理を完結させることが動かせない要件になっている案件。標準／リージョン別デプロイにGPT-5系の提供がない以上、この要件とモデル世代は両立しません。要件を「国内処理」から「APAC内処理」に読み替えられるかを先に確認し、読み替えられないなら別モデルか別構成を検討します。

第二に、リリース直後の最新版をいち早く試したい検証フェーズです。Azure側は提供開始のタイミングやプレビュー扱いの期間があり、直APIより一手遅れることがあります。検証は直APIで進め、本番移行の段階でAzureに寄せる二段構えが現実的でしょう。

第三に、瞬間的な大量並列が必要で、かつ階層1のクォータしか持っていない段階です。増枠申請は実使用の実績が優先されるため、いきなり大きな枠は通りにくく、PTUを含めた費用の検討が先に来ます。ここは技術選定というより調達の話になります。

どの構成を選ぶにせよ、実装の前段にある体制や進め方の設計は避けて通れません。社内リソースだけで進めるか外部に委託するかの判断軸はAzure OpenAI Service導入支援の進め方｜五工程と外部委託の判断基準で整理しています。要件定義からデプロイ設計、クォータ設計、運用監視までを含めて任せたい場合は、当社の生成AI開発・AI受託開発でご相談を受け付けています。

よくある質問

Azure OpenAIでGPT-5を使うのに申請は必要ですか？

2026年8月16日時点のMicrosoft Learnの記載では、gpt-5・gpt-5-mini・gpt-5-nanoを含む多くのGPT-5系モデルでアクセス要求は不要になっています。ただしクォータは別で、gpt-5.5やgpt-5.6-solのように階層によってはクォータ要求が必要なモデルもあります。階層5と階層6には既定でクォータが割り当てられているため、自分の階層を先に確認するのが近道です。

東日本リージョンでGPT-5は使えますか？

グローバル標準デプロイであれば、japaneastを含むアジア太平洋の主要リージョンでgpt-5系をデプロイできます。ただし処理そのものは任意のAzureリージョンで行われる仕様のため、国内で処理される意味にはなりません。標準／リージョン別デプロイには同時点でGPT-5系の提供がない点にも注意してください。

api-versionはどの値を指定すればよいですか？

v1 APIを使う場合、日付付きの api-version は必須パラメータではありません。base_url の末尾に openai/v1 を付けたうえで、OpenAI公式クライアントをそのまま使います。プレビュー段階の機能は、APIバージョンを差し替えるのではなく機能ごとのプレビューヘッダーを渡すか、パスに alpha を含む専用パスを使う方式です。

max_tokensを指定したのに応答が途中で切れるのはなぜですか？

推論モデルでは max_tokens がサポートされないため、max_completion_tokens に置き換えてください。推論モデルは回答前に推論トークンを消費するので、上限が小さいと推論だけで枠を使い切り、可視の出力が空になることがあります。まずは上限を大きめに取り、実測値を見てから絞り込みましょう。

Chat Completions APIでツールを呼ぶとエラーになるのはなぜですか？

gpt-5.6以降のモデルでは、Chat Completions APIで関数ツールとreasoning_effortを併用できません。既定がmediumのため、パラメータを明示していなくてもtoolsを送るだけで失敗します。Responses APIへ移すか、全リクエストでreasoning_effortにnoneを設定してください。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る