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 推論 |
|---|---|---|
| ベースURL | https://{resource}.openai.azure.com/ | https://{resource}.services.ai.azure.com/ |
| パス | openai/deployments/{デプロイ名}/chat/completions | api/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-Type | application/json | JSON ボディを送るため必須 |
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 found | URL の {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-Type | application/json | JSON ボディ |
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": "{デプロイ名}"
- 方法A:
- デプロイ名とモデル名を取り違えないことが最重要
- キーの種類(Azure OpenAI のキー vs Inference Credential)を使い分ける
- API バージョンは常にポータルのサンプルに合わせる
temperatureを 0 に固定している既存コードは、GPT‑5 ではエラーになる可能性があるため要修正
一度、方法A/B のどちらかで GPT‑5(ベース)の Chat Completions 呼び出しが成功すれば、あとは既存の GPT‑4 / GPT‑3.5 コードからの置き換えも比較的スムーズです。
「ポータルに Chat Completions が見当たらない」という見た目に惑わされず、エンドポイントとデプロイ名・キーの3点セットを丁寧に確認しながら接続してみてください。

コメント