Azure AI FoundryのAzure OpenAI image and audio REST API更新点|2025-04-01-previewの確認項目

Azure AI Foundryで画像生成や音声処理をREST APIから利用している場合、今回まず確認すべきなのは、2025-04-01-preview が「画像生成・画像編集・音声文字起こし・英訳・音声合成」を扱うデータプレーン推論APIのプレビュー仕様だという点です。既存の 2024-10-21 GA版を単純に置き換えるものではなく、gpt-image-1 系の画像生成、画像編集、ストリーミング応答、文字起こしのタイムスタンプ粒度などを検証したい開発チーム向けの参照情報として読むのが適切です。Microsoft Learnの当該ページは2026年6月24日に更新されており、チャット、埋め込み、Responses API、Assistantsなどは別のAzure OpenAI REST APIリファレンスを参照する構成になっています。(Microsoft Learn)

実務上の結論は明確です。新規開発では、まずGA版またはv1 APIで要件を満たせるか確認し、2025-04-01-preview は画像・音声の新しいパラメーターを検証する用途に限定するのが安全です。すでに本番で画像生成や音声APIを使っている管理者は、APIバージョン、モデルの退役日、認証方式、Content-Type、レスポンス形式、クォータ、Azure API Management連携の可否を棚卸ししてください。

目次

Azure AI Foundryの「2025-04-01-preview」REST API referenceとは

Azure AI FoundryにおけるAzure OpenAIのAPIは、大きく分けると「リソースやデプロイを管理するコントロールプレーン」と、「推論やオーサリングを行うデータプレーン」に分かれます。今回の「Azure OpenAI image and audio REST API reference (2025-04-01-preview)」は、データプレーン推論のうち、画像生成と音声関連の操作に絞ったプレビュー版リファレンスです。(Microsoft Learn)

対象になる主な操作は次のとおりです。

操作エンドポイントの用途主な利用シーン
Transcriptions – Create音声を入力言語のテキストに変換会議録、コールセンター音声の文字起こし、字幕生成
Translations – Create音声を英語テキストへ変換多言語音声の英訳、海外拠点の音声ログ分析
Speech – Createテキストから音声を生成読み上げ、音声ガイダンス、アクセシビリティ対応
Image generations – Createテキストプロンプトから画像を生成マーケティング素材、UI案、商品イメージの生成
Image generations – Edit既存画像をプロンプトで編集背景変更、マスク編集、画像のバリエーション作成

重要なのは、同じAzure OpenAIでも、チャット補完やResponses APIの仕様確認にはこのページだけでは不十分な点です。画像と音声のREST API仕様を確認するページであり、テキスト生成やRAG構成、ベクトルストア、Assistants関連の変更確認には別リファレンスを参照する必要があります。

今回の更新で確認すべき主要ポイント

2025-04-01-preview の更新ポイントは、単にAPIバージョンが増えたことではありません。画像生成では gpt-image-1 系を前提にしたパラメーターが増え、音声では文字起こしモデルやタイムスタンプ指定など、実装時にレスポンス設計へ影響する項目が明確になっています。

項目確認すべき内容実務上の影響
APIバージョンapi-version=2025-04-01-preview を明示して呼び出す環境変数やSDK設定の固定値を確認する
認証APIキーまたはMicrosoft Entra IDを利用可能本番ではキー管理よりEntra ID認証を優先検討する
画像生成background、output_format、output_compression、partial_images、stream などを確認透明背景、JPEG圧縮、ストリーミングUIに影響する
画像編集images/edits が追加され、画像・マスクを multipart/form-data で扱う既存のJSON前提の実装では対応できない
音声文字起こしgpt-4o-transcribe、gpt-4o-mini-transcribe、whisper-1 などのモデル指定を確認精度、コスト、レイテンシ、話者分離要件に影響する
レスポンス形式json、text、srt、verbose_json、vtt などを選択字幕、検索インデックス、監査ログの後続処理に影響する
APIM連携2025-04-01-preview のOpenAPI 3.1仕様はAzure API Managementで完全対応していない既知の課題ありAPI Management経由で公開する場合は事前検証が必須

MicrosoftのAPIライフサイクル情報では、2025-04-01-preview と前月版の差分として GPT-image-1 support が挙げられています。また、2025-04-01-preview の仕様がOpenAPI 3.1を使っており、Azure API Managementでは完全にサポートされていない既知の問題があることも示されています。API ManagementでOpenAPI定義をインポートして社内APIとして公開している組織では、ここが見落としやすいポイントです。(Microsoft Learn)

画像生成APIで変わる実装上の考え方

画像生成は次の形式で呼び出します。

POST https://{endpoint}/openai/deployments/{deployment-id}/images/generations?api-version=2025-04-01-preview

このAPIは、指定した画像生成モデルのデプロイに対して、テキストプロンプトから画像を生成する操作です。prompt は必須で、gpt-image-1 系では最大32,000文字、dall-e-3 では最大4,000文字という違いがあります。加えて、gpt-image-1 系でのみ使える項目として、背景の透過指定、出力形式、JPEG圧縮、画像生成時の使用量情報などが定義されています。(Microsoft Learn)

特に確認すべきパラメーターは次のとおりです。

パラメーター内容注意点
prompt生成したい画像の説明モデルによって最大文字数が異なる
n生成枚数dall-e-3 は n=1 のみ対応
background透明・不透明・自動を指定gpt-image-1 系のみ対応
output_formatpng または jpeggpt-image-1 系のみ対応
output_compressionJPEG圧縮率を指定JPEG出力時のみ有効
partial_imagesストリーミング時の部分画像数0〜3の範囲で指定
streamストリーミング応答の利用UIに途中生成結果を出す場合に検証
qualityauto、high、medium、low、hd、standardモデルごとの対応差に注意
response_formaturl または b64_jsongpt-image-1 系では常にBase64返却とされる

ここで失敗しやすいのは、旧来のDALL-E前提で response_format=url を固定しているケースです。gpt-image-1 系ではBase64エンコード画像を前提に保存処理やCDN連携を設計する必要があります。画像の保存先、ファイル名、メタデータ、コンテンツフィルター結果をどう保管するかまで含めて見直してください。

また、2026年時点では dall-e-3 の扱いにも注意が必要です。Microsoftの画像生成モデルのガイドでは、dall-e-3 は2026年3月4日に退役し、新規デプロイ不可かつ既存デプロイも機能しないため、画像生成には gpt-image- 系モデルを使うよう案内されています。リファレンス内に dall-e-3 の制約が残っていても、新規設計では gpt-image-1、gpt-image-1-mini、gpt-image-1.5、gpt-image-2 など現行モデルの提供状況を確認するべきです。(Microsoft Learn)

画像編集APIはContent-Typeとファイル制約に注意

画像編集は次のエンドポイントで提供されます。

POST https://{endpoint}/openai/deployments/{deployment-id}/images/edits?api-version=2025-04-01-preview

画像編集APIは、テキストプロンプトだけではなく、編集対象の画像ファイルやマスク画像を送信します。そのため、リクエストは multipart/form-data で扱います。image はPNGまたはJPGで50MB未満、mask はPNGで4MB未満かつ編集対象画像と同じ寸法である必要があります。(Microsoft Learn)

実務では、次のようなチェックを入れておくと事故を減らせます。

チェック項目実装で見るポイント
ファイル形式PNG/JPG以外をアップロード前に弾く
ファイルサイズ画像は50MB未満、マスクは4MB未満に制限する
マスク寸法元画像と同じ幅・高さか検証する
input_fidelity顔や特徴を保持したい場合は high の検証を行う
n1〜10の範囲で、コストとUXを考えて制御する
ストリーミング部分画像表示を行う場合はUI側の再描画設計を行う

画像編集でありがちな失敗は、生成APIと同じJSON送信のつもりで実装してしまうことです。画像編集はファイルアップロードを伴うため、API Gateway、WAF、プロキシ、アプリケーションサーバーのアップロード上限にも影響します。Azure API Managementを挟む構成では、OpenAPI 3.1の既知課題に加えて、マルチパートデータの取り扱いも検証してください。

音声APIは「文字起こし」「英訳」「読み上げ」で役割が異なる

2025-04-01-preview の音声APIは、用途別に3つの操作に分かれています。似た名前でも入力、出力、モデル選定、後続処理が異なるため、同じ「音声API」としてまとめて設計しないことが重要です。

音声文字起こしは言語指定とタイムスタンプ粒度を確認する

文字起こしは次のエンドポイントを使います。

POST https://{endpoint}/openai/deployments/{deployment-id}/audio/transcriptions?api-version=2025-04-01-preview

リクエストは multipart/form-data で、音声ファイルとモデルを指定します。リファレンスでは、gpt-4o-transcribe、gpt-4o-mini-transcribe、gpt-4o-mini-transcribe-2025-12-15、whisper-1、gpt-4o-transcribe-diarize がモデル候補として示されています。language をISO-639-1形式で指定すると、精度とレイテンシの改善につながると説明されています。(Microsoft Learn)

字幕生成や音声検索で重要なのが timestamp_granularities[] です。verbose_json を指定した場合に、segment または word のタイムスタンプを取得できます。ただし、単語単位のタイムスタンプは追加レイテンシが発生するとされているため、リアルタイム性が重要な処理では使いどころを絞るべきです。(Microsoft Learn)

音声翻訳は「英語テキストへの変換」と理解する

翻訳APIは次のエンドポイントです。

POST https://{endpoint}/openai/deployments/{deployment-id}/audio/translations?api-version=2025-04-01-preview

この操作は、入力音声を英語テキストに変換するものです。日本語音声を日本語テキストにする用途ならTranscriptions、会議音声を英語テキストとして社内共有するならTranslations、というように使い分けます。prompt を使う場合は英語で指定する点にも注意が必要です。(Microsoft Learn)

音声合成は入力長、音声形式、話速を先に決める

読み上げAPIは次のエンドポイントです。

POST https://{endpoint}/openai/deployments/{deployment-id}/audio/speech?api-version=2025-04-01-preview

input は最大4,096文字で、voice は alloy、echo、fable、onyx、nova、shimmer から選択します。出力形式は mp3、opus、aac、flac、wav、pcm を指定でき、speed は0.25〜4.0の範囲で調整できます。(Microsoft Learn)

音声合成では、仕様どおりに呼び出せるかだけでなく、利用先の再生環境に合わせた形式選定が重要です。Web配信なら mp3 や opus、編集ワークフローに渡すなら wav や flac、低レイヤーの音声処理とつなぐなら pcm を検討します。話速を上げれば短時間で再生できますが、研修コンテンツやアクセシビリティ用途では聞き取りやすさを優先してください。

GA版、v1 API、2025-04-01-previewの使い分け

Azure OpenAIの画像・音声APIには、GA版の 2024-10-21 リファレンスもあります。GA版は本番利用の安定性を重視する場合の基本候補であり、プレビュー版は新機能を早く検証したい場合に使います。(Microsoft Learn)

一方で、Microsoftはv1 APIも提供しており、v1では日付形式の api-version 指定を減らし、OpenAIクライアントとの互換性を高める方向性が示されています。v1 APIでは、base_url に /openai/v1/ を付ける構成や、OpenAIクライアントの利用が説明されています。(Microsoft Learn)

判断基準は次のように整理できます。

選択肢向いているケース注意点
2024-10-21 GA本番で安定運用したい、既存の画像・音声処理を維持したい新しい画像編集や一部パラメーターは使えない可能性がある
2025-04-01-previewgpt-image-1 系、画像編集、ストリーミング、詳細な音声処理を検証したいプレビュー仕様のため変更リスクがある
v1 API / v1 preview新規開発でAPIバージョン管理の負担を減らしたい、今後のAPI体系に合わせたい対象機能がGAかPreviewかを個別に確認する必要がある

新規プロジェクトでは、最初から 2025-04-01-preview に固定するのではなく、「GA版で足りるか」「v1 APIで実装できるか」「どうしてもプレビュー機能が必要か」の順に判断するのが現実的です。

影響範囲:誰が何を確認すべきか

今回の更新は、開発者だけでなく、クラウド管理者、セキュリティ担当、API基盤担当、プロダクトオーナーにも影響します。

役割確認すべきポイント
開発者エンドポイント、Content-Type、必須パラメーター、レスポンス形式、SDK対応
Azure管理者対象リージョン、モデルデプロイ、クォータ、APIバージョンの利用状況
セキュリティ担当APIキー利用の有無、Microsoft Entra ID認証、コンテンツフィルター結果の保管
API基盤担当Azure API Management、WAF、プロキシ、ファイルアップロード制限
プロダクト担当画像生成・音声合成のコスト、レイテンシ、UI上の待ち時間
法務・ガバナンス担当生成画像・音声の利用範囲、ログ保存、ユーザー識別子の取り扱い

Azure OpenAIのクォータはテナント単位ではなく、サブスクリプション、リージョン、モデルまたはデプロイ種別ごとに管理されます。画像生成ではRPM、音声やテキスト系ではRPM/TPMの制限が実装に影響するため、グローバル展開ではリージョンごとのクォータ設計が重要です。(Microsoft Learn)

移行期限とモデル退役で確認すべきこと

この 2025-04-01-preview リファレンス自体には、特定の日付までに必ず移行しなければならない期限は明記されていません。ただし、実際の運用ではAPIバージョンよりも、利用モデルのライフサイクルが先に問題になることがあります。

Microsoftのモデル退役スケジュールでは、たとえば gpt-image-1 はPreviewで退役日が2026年10月23日、gpt-4o-transcribe はGAで退役日が2026年10月15日、whisper 001はGAで退役日が2026年12月15日と示されています。モデルの提供状況は変わり得るため、管理者はAPIバージョンだけでなく、デプロイ済みモデル名、モデルバージョン、退役日をセットで棚卸ししてください。(Microsoft Learn)

移行計画では、次の順番で確認すると抜け漏れを減らせます。

手順確認内容判断基準
1現在のAPIバージョンを洗い出すコード、環境変数、API Gateway設定を確認
2使用モデルを一覧化するデプロイ名ではなく実モデル名とバージョンを見る
3GA版またはv1 APIの対応可否を確認する本番はGA優先、Previewは限定利用
4レスポンス差分をテストするurl と b64_json、字幕形式、JSON構造を比較
5クォータとレイテンシを測定する画像生成枚数、単語タイムスタンプ、音声合成形式で変動
6ロールバック手順を用意するPreview仕様変更に備え、旧APIとの切り戻し条件を決める

管理者がすぐ確認すべきチェックリスト

本番環境または本番候補でAzure AI Foundryの画像・音声APIを使っている場合は、次の項目を確認してください。

  • api-version=2025-04-01-preview を本番コードに固定していないか
  • 2024-10-21 GA版で満たせる要件までPreviewに寄せていないか
  • v1 APIまたはv1 previewへ移行する方針があるか
  • dall-e-3 前提の実装や運用手順が残っていないか
  • gpt-image- 系モデルの退役日と代替候補を確認しているか
  • 画像生成結果をBase64で受ける場合の保存処理を実装しているか
  • 画像編集APIで multipart/form-data、画像サイズ、マスク寸法を検証しているか
  • 音声文字起こしで language を指定しているか
  • verbose_json と単語タイムスタンプ利用時のレイテンシを測定しているか
  • APIキーではなくMicrosoft Entra ID認証を使える構成になっているか
  • Azure API ManagementでOpenAPI 3.1仕様を扱えるか検証しているか
  • サブスクリプション、リージョン、モデル別のクォータを確認しているか
  • コンテンツフィルター結果、user 識別子、生成物の保存ポリシーを決めているか

特にグローバル展開では、リージョンごとに利用できるモデル、クォータ、レイテンシ、データ保存方針が変わります。単一リージョンで動作確認できたからといって、全リージョンで同じ品質・同じ制限で動くとは考えない方が安全です。

実装時に避けたい失敗パターン

Preview APIを本番の標準APIとして固定してしまう

2025-04-01-preview は便利ですが、Previewである以上、仕様変更の可能性があります。検証環境で新機能を試し、必要な機能だけを本番に限定投入するのが基本です。本番ではGA版またはv1 GAで要件を満たせない理由を明文化してから採用してください。

画像生成の戻り値をURL前提で設計する

旧実装では生成画像のURLを受け取って保存する設計が多く見られます。しかし、gpt-image-1 系ではBase64返却が前提になるため、保存処理、ファイルサイズ、ログ出力、レスポンス圧縮、フロントエンドへの返却方式を見直す必要があります。

画像編集APIをJSONで呼び出そうとする

画像編集はファイルを送るため、multipart/form-data が必要です。プロンプトだけの画像生成と同じ感覚でJSON送信すると、実装段階でエラーになります。アップロード上限、タイムアウト、ウイルススキャン、マスク画像の検証も含めて設計してください。

音声文字起こしでレスポンス形式を後から変える

text、srt、vtt、json、verbose_json は後続システムへの影響が大きい項目です。字幕が必要なら srt や vtt、検索インデックスや分析に使うなら json、タイムスタンプや詳細メタデータが必要なら verbose_json を選ぶなど、最初に用途を決めておくべきです。

モデル退役日をAPIバージョンの問題として見落とす

APIが動いていても、デプロイしているモデルが退役すれば処理は継続できません。APIバージョンの移行計画とモデル移行計画を別々に管理すると抜け漏れが起きやすいため、同じ台帳で管理することをおすすめします。

まず取るべきアクション

Azure AI Foundryの「Azure OpenAI image and audio REST API reference (2025-04-01-preview)」は、画像生成・画像編集・音声処理をREST APIで扱うチームにとって重要な更新です。ただし、すべての環境で直ちに採用すべき仕様ではありません。

まずは、現在の本番コードで使っているAPIバージョンとモデルを一覧化してください。次に、GA版で足りない機能が何かを明確にし、gpt-image- 系の画像生成、画像編集、音声文字起こしの詳細メタデータなど、Previewを使う理由がある部分だけを検証します。最後に、モデル退役日、クォータ、認証方式、API Management対応、レスポンス保存方式を確認すれば、Preview機能を安全に評価しながら本番影響を抑えられます。

この記事を書いた人

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

コメント

コメントする

目次