Azure AI FoundryでGPT‑5(ベース)をChat Completions APIとして使う完全ガイド

Azure AI Foundry で GPT‑5(ベース)をデプロイしたのに、ポータルには Response API のサンプルしか表示されず、「Chat Completions の REST API はどこ?」と迷っていませんか。本記事では、GPT‑5(ベース)を Chat Completions API として正しく呼び出す具体的な方法と、ハマりがちな落とし穴・トラブルシューティングをまとめて解説します。


目次

GPT‑5(ベース)でも Chat Completions は使える

結論から言うと、GPT‑5(ベース)も Chat Completions API をサポートしています。
Microsoft Q&A でも、Azure AI Foundry でデプロイした GPT‑5(ベース)に対して /chat/completions を使った呼び出しが公式に案内されています。

ただし、Azure AI Foundry のポータル上では GPT‑5(ベース)の REST サンプルとして Responses API(/responses) が優先的に表示されるため、 「Chat Completions が無い=非対応」と誤解しやすい構造になっています。

実際には、次のどちらかのエンドポイント形式を使えば、GPT‑5(ベース)でも Chat Completions と同じインターフェースで呼び出し可能です。

  • 方法A:Azure OpenAI 互換エンドポイント(*.openai.azure.com)
  • 方法B:Foundry Models の推論エンドポイント(*.services.ai.azure.com)

どちらの方式でも共通点はただ一つ。「デプロイ名を正しく使う」ことです。ポータルに表示される「モデル名 (gpt‑5‑preview 等)」と「デプロイ名」は別物なので、ここを取り違えると 404 や 400 エラーの原因になります。


エンドポイント2種類の違いを整理する

まずは、Azure 側に存在する 2 種類のエンドポイントの役割を整理しておきます。

項目方法A:Azure OpenAI 互換方法B:Foundry Models 推論
ベースURLhttps://{resource}.openai.azure.com/https://{resource}.services.ai.azure.com/
パスopenai/deployments/{デプロイ名}/chat/completionsapi/models/chat/completions または
models/chat/completions
デプロイ名の指定場所URL パスの {デプロイ名}JSON ボディの "model": "{デプロイ名}"
主な利用ケース既存の Azure OpenAI 連携コードから GPT‑5 を使いたい場合Foundry のプロジェクトから統一的に各種モデルを呼びたい場合
認証情報Azure OpenAI リソースの API キーFoundry Models の Inference Credential(推論資格情報)

Foundry Models 側の Chat Completions エンドポイントは、公式ドキュメントでは次のように定義されています。

POST https://{resource}.services.ai.azure.com/models/chat/completions?api-version=2024-05-01-preview

一方、Azure OpenAI サービス側の Chat Completions は古くから次の形式で提供されています。

POST https://{resource}.openai.azure.com/openai/deployments/{deployment}/chat/completions?api-version={version}

Azure AI Foundry では、この両方を「接続」として利用できます。GPT‑5(ベース)も例外ではなく、どちらの形でも Chat Completions を呼び出すことが可能です。


方法A:Azure OpenAI 互換エンドポイントで GPT‑5(ベース)を呼び出す

エンドポイント形式

Azure OpenAI 互換エンドポイントを使う場合、URL は次の形式になります。

https://{リソース名}.openai.azure.com/openai/deployments/{デプロイ名}/chat/completions?api-version=2024-08-01-preview
  • {リソース名}:Azure OpenAI リソース名
  • {デプロイ名}:Azure OpenAI Studio / Foundry で設定したデプロイ名(例:gpt-5)
  • api-version:ポータルに表示されている有効なバージョンを利用(例は一例)

リクエストヘッダー

ヘッダー名値補足
Content-Typeapplication/jsonJSON ボディを送るため必須
api-key{Azure OpenAI リソースのキー}Foundry の Inference Credential ではない点に注意

最小サンプル(Python / requests)

import os
import requests
import json

endpoint   = "https://{リソース名}.openai.azure.com/"
deployment = "{デプロイ名}"  # 例: gpt-5
api_key    = "{APIキー}"
api_version = "2024-08-01-preview"

url = f"{endpoint}openai/deployments/{deployment}/chat/completions"
params = {"api-version": api_version}
headers = {
    "Content-Type": "application/json",
    "api-key": api_key,
}

payload = {
    "messages": [
        {"role": "system", "content": "あなたは有能なアシスタントです。"},
        {"role": "user", "content": "こんにちは"}
    ]
}

resp = requests.post(url, headers=headers, params=params, json=payload, timeout=60)
resp.raise_for_status()
print(json.dumps(resp.json(), ensure_ascii=False, indent=2))

ポイントは、URL の {deployment} には必ず「デプロイ名」を指定することです。
ここに「モデル名(例:gpt-5-preview)」を入れてしまうと 404 エラーの原因になります。

よくある実装ミス(方法A)

症状よくある原因確認ポイント
404 Resource not found/chat/completions の chat を付け忘れているなど、パス違いURL に /chat/completions が含まれているかを確認
404 Deployment not foundURL の {deployment} にモデル名を入れてしまっているStudio の「デプロイ名」列と一致しているか確認
401 Unauthorized誤った API キーや別リソースのキーを使用Azure OpenAI リソースの「キーとエンドポイント」画面でキーを再コピー

方法B:Foundry Models の推論エンドポイントで GPT‑5(ベース)を呼び出す

エンドポイント形式

Foundry Models 経由の Chat Completions は、基本的に次の形式で呼び出します。

POST https://{リソース名}.services.ai.azure.com/models/chat/completions?api-version=2024-05-01-preview

ただし、Microsoft Q&A や一部のサンプルでは、次のように /api を含む形式が案内されることもあります。

POST https://{リソース名}.services.ai.azure.com/api/models/chat/completions

最終的には、ポータルの「コードサンプル」ペインに表示される URL が正なので、自身の環境に表示された形式を優先してください。

リクエストヘッダー

ヘッダー名値補足
Content-Typeapplication/jsonJSON ボディ
api-key{Inference Credential}Foundry の「推論資格情報」のキー。Azure OpenAI のキーとは別物。

最小サンプル(cURL)

curl -X POST "https://{リソース名}.services.ai.azure.com/api/models/chat/completions" \
  -H "Content-Type: application/json" \
  -H "api-key: {推論資格情報}" \
  -d '{
    "model": "{デプロイ名}",
    "messages": [
      {"role": "system", "content": "あなたは有能なアシスタントです。"},
      {"role": "user", "content": "一言で挨拶してください。"}
    ]
  }'

この形式では、URL にはデプロイ名を含めず、リクエストボディの "model" プロパティに「デプロイ名」を指定します。

JavaScript(Node.js)での例

import fetch from "node-fetch";

const endpoint = "https://{リソース名}.services.ai.azure.com";
const apiKey = "{推論資格情報}";
const deployment = "{デプロイ名}";

async function main() {
  const url = `${endpoint}/api/models/chat/completions`;
  const res = await fetch(url, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "api-key": apiKey,
    },
    body: JSON.stringify({
      model: deployment,
      messages: [
        { role: "system", content: "あなたは有能なアシスタントです。" },
        { role: "user", content: "今日の天気の例を教えてください。(実際の天気でなくてOK)" }
      ]
    }),
  });

  if (!res.ok) {
    console.error("status:", res.status, await res.text());
    return;
  }

  const data = await res.json();
  console.log(JSON.stringify(data, null, 2));
}

main().catch(console.error);

方法A/B の違い早見表

比較項目方法A:Azure OpenAI方法B:Foundry Models
URL にデプロイ名を含めるかはい(/deployments/{デプロイ名})いいえ(ボディの "model" に指定)
model フィールド通常不要(指定しても無視されるか、v1 API のみ利用)必須(デプロイ名を指定)
キーの種類Azure OpenAI リソースの API キーInference Credential(推論資格情報)
ポータルとの馴染み既存の Azure OpenAI コードと似ているFoundry Projects からの利用に最適化

Chat Completions リクエストの基本構造

GPT‑5(ベース)であっても、Chat Completions の基本的な JSON 構造は、従来の GPT‑4 / GPT‑3.5 と共通です。

{
  "messages": [
    {"role": "system", "content": "あなたは有能なアシスタントです。"},
    {"role": "user", "content": "Azure AI Foundry で GPT-5 を使う方法を教えて。"}
  ],
  "max_tokens": 512,
  "top_p": 1,
  "frequency_penalty": 0,
  "presence_penalty": 0
}

特に GPT‑5(ベース)を使う場合に注意したいのは以下の点です。

  • messages は必須(prompt 単体ではなく、チャット形式)
  • role には system / user / assistant などを利用
  • 画像や音声などのマルチモーダル入力に対応しているモデルでは、追加のフィールドが使える(対応モデルのみ)

よくあるつまずきチェックリスト

デプロイ名 vs モデル名の取り違え

もっとも多いのが、デプロイ名とモデル名を混同してしまうパターンです。

項目例どこに使うか
モデル名gpt-5-preview などデプロイ作成時の選択肢として使用
デプロイ名gpt-5 や gpt-5-prod などURL の {deployment} や "model" に使用

方法A(Azure OpenAI)では URL の {deployment} に、方法B(Foundry Models)では ボディの "model" に、必ずデプロイ名を書きます。

キーの種類を間違える

  • 方法A:Azure OpenAI リソースの API キー
  • 方法B:Foundry の Inference Credential(推論資格情報)

これを取り違えると、リクエストは 401(Unauthorized)を返します。Azure OpenAI 側の 401 エラーは、しばしば「キーの種類違い」「エンドポイントのリソース名違い」が原因になっています。

API バージョンの指定漏れ・不整合

Azure OpenAI の Chat Completions では、api-version クエリパラメータがほぼ必須です。
Foundry Models の Chat Completions でも、公式ドキュメントの例では api-version が指定されています。

バージョンは頻繁に更新されるため、ポータルのサンプルコードに表示されるものをそのまま使うのが安全です。


HTTP エラー別トラブルシューティング

エラーコードと対処の早見表

HTTP ステータス典型的な原因チェックポイント
401 Unauthorizedキーが違う / 期限切れ / 権限不足・Azure OpenAI のキーと Foundry の Inference Credential を混在させていないか
・キー文字列の前後に余計な空白や改行が入っていないか
404 Not Foundパス違い / デプロイ名の間違い・URL に /chat/completions が付いているか
・{deployment} や "model" にデプロイ名を指定しているか
400 Bad Requestサポートされないパラメータ、JSON 構造の不正・サポート外のフィールド(例:特定モデルで禁止の temperature など)を送っていないか
・messages の JSON 構造が正しいか
429 Too Many Requestsレート制限(RPM / TPM)の超過、クォータ不足・リトライ時に指数バックオフを入れているか
・デプロイのレート制限設定とサブスクリプションのクォータを確認

GPT‑5(ベース)特有の注意点:temperature エラー

GPT‑5(ベース)をテストしていると、以下のようなエラーに遭遇することがあります。

Unsupported value: 'temperature' does not support 0 with this model. Only the default (1) value is supported.

これは、一部の GPT‑5 系モデルや推論モデルでは temperature が固定値(既定値 = 1)で、任意に変更できないために発生するエラーです。同様のメッセージは、OpenAI / Azure OpenAI の新しい推論系モデルでも多数報告されています。

対処方法

  • temperature を送らない(指定しなければ既定値 1 が使われる)
  • 出力のばらつきを抑えたい場合は、モデルがサポートしていれば top_p / frequency_penalty / presence_penalty などで調整する
  • それでもエラーが出る場合は、そのモデルがサポートしているパラメータ一覧をドキュメントで確認する

特に、既存の GPT‑3.5 / GPT‑4 系向けコードをそのまま GPT‑5 に差し替えた場合、 「デフォルトで temperature=0 を指定している」コードが原因で一気に 400 エラーが量産される、というケースが多いので注意が必要です。


実務での設計・運用のヒント

GPT‑5(ベース)と GPT‑5‑chat / mini / nano の役割分担

ポータル上では、GPT‑5‑chat / GPT‑5‑mini / GPT‑5‑nano には最初から Chat Completions のサンプルが表示される一方、GPT‑5(ベース)は Response API のサンプルが前面に出てくる傾向があります。

これは「機能差」というより、ポータル上の導線の違いと考えると理解しやすくなります。

  • GPT‑5‑chat / mini / nano:チャット用途向けに分かりやすい UI が整備されている
  • GPT‑5(ベース):Responses API や高度な機能を前提にした利用を想定しているため、Chat Completions のサンプルが埋もれがち

アプリ設計上は、次のように使い分けるのが現実的です。

  • Chat UI ベースのアプリや、既存の Chat Completions コードを流用したい場合:
    → GPT‑5(ベース)を Chat Completions API で呼び出す(本記事の方法)
  • より高度な機能(例:長いコンテキスト管理やツール呼び出し)を最大限活かしたい場合:
    → Responses API を検討(ただし実装は別途検証が必要)

セキュリティと認証パターン

本記事ではわかりやすさのために API キーを使った例を紹介しましたが、実運用では Microsoft Entra ID(旧 Azure AD)によるキー無し認証も有力な選択肢です。Azure AI Foundry / Foundry Models は Entra ID によるキーレス認証をサポートしており、クライアント側でキーを持たない設計も可能です。

ただし、Entra ID 認証はセットアップ手順が増えるため、 まずは「開発・検証はキー認証、本番は Entra ID」という二段構えで設計するのがおすすめです。


まとめ:GPT‑5(ベース)でも落ち着いて Chat Completions を使おう

最後に、本記事のポイントを整理します。

  • GPT‑5(ベース)は Chat Completions API に対応している(ポータルに出てこないだけ)
  • 呼び出し方法は大きく 2 パターン
    • 方法A:https://{resource}.openai.azure.com/openai/deployments/{deployment}/chat/completions?api-version=...
    • 方法B:https://{resource}.services.ai.azure.com/api/models/chat/completions + ボディの "model": "{デプロイ名}"
  • デプロイ名とモデル名を取り違えないことが最重要
  • キーの種類(Azure OpenAI のキー vs Inference Credential)を使い分ける
  • API バージョンは常にポータルのサンプルに合わせる
  • temperature を 0 に固定している既存コードは、GPT‑5 ではエラーになる可能性があるため要修正

一度、方法A/B のどちらかで GPT‑5(ベース)の Chat Completions 呼び出しが成功すれば、あとは既存の GPT‑4 / GPT‑3.5 コードからの置き換えも比較的スムーズです。
「ポータルに Chat Completions が見当たらない」という見た目に惑わされず、エンドポイントとデプロイ名・キーの3点セットを丁寧に確認しながら接続してみてください。


この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次