Azure AI FoundryのAzure OpenAI画像・音声・動画REST API v1 preview更新ポイント

2026年6月24日に更新された Microsoft Learn の「Azure OpenAI image, audio, and video REST API reference (v1 preview)」は、Azure AI Foundry で画像生成、音声合成・文字起こし、動画生成を REST API から扱う開発者・管理者が必ず確認すべきリファレンスです。結論から言うと、今回のポイントは「画像・音声・動画系のデータプレーン API が v1 preview の形式で整理され、エンドポイント、api-version、model 指定、動画生成ジョブの扱いを見直す必要がある」という点です。公式ページ自体は移行期限を告知する文書ではありませんが、既存の 2025-04-01-preview 系 API やプレビュー モデルを使っている環境では、コード、API Management、認証、監視、データ保存の確認が必要です。(Microsoft Learn)

目次

Azure AI Foundry の「Azure OpenAI image, audio, and video REST API reference」とは

このリファレンスは、Azure AI Foundry 上の Azure OpenAI で、画像、音声、動画生成に関するデータプレーン推論 API を v1 preview としてまとめた公式ドキュメントです。対象は、画像生成・画像編集、音声合成、音声文字起こし、音声翻訳、動画生成ジョブなどです。一方で、チャット補完、埋め込み、評価、ファイル、ファインチューニング、Responses API、Vector Stores などは別の Azure OpenAI REST API リファレンスを見る必要があります。(Microsoft Learn)

重要なのは、このページが「Azure AI Foundry のすべての API を解説するページ」ではなく、画像・音声・動画のメディア系 API に特化した v1 preview リファレンスである点です。テキスト生成 API の移行や Responses API の設計変更を調べたい場合は、同じ v1 系でも別のリファレンスを参照する必要があります。(Microsoft Learn)

2026年6月24日更新で押さえるべきポイント

今回の更新で管理者が見るべき点は、単に「新しい API が増えた」ことではありません。既存の実装が、古い日付付き preview API の URL 設計に依存していないかを確認することが実務上のポイントです。

確認項目変更・確認すべき内容実務での影響
API パス/openai/v1/... 形式の v1 preview API として整理旧 API パスをハードコードしているアプリは修正が必要
api-versionメディア系 v1 preview では api-version=preview が使われる日付付き 2025-04-01-preview からの単純置換ではなく、動作検証が必要
モデル指定API パスの deployment-id ではなく、リクエスト本文の model で指定する形式が中心ルーティング、ログ、監査で「どのデプロイを呼んだか」の追跡方法を見直す
認証API キーまたは Bearer トークンを利用でき、トークンベース認証が推奨される本番環境では Managed Identity や Microsoft Entra ID 連携を優先したい
動画生成ジョブ作成、一覧、取得、削除、動画取得、サムネイル取得が分かれる同期処理ではなく、非同期ジョブとして設計する必要がある
レスポンス画像では base64、URL、有効期限、使用量情報、動画では expires_at などを考慮生成物を後から使う場合はアプリ側で保存処理が必要

v1 API 全体の考え方として、Microsoft は月次のような日付付き API バージョン更新の負担を減らし、OpenAI クライアントとの互換性を高める方向を示しています。ただし、今回の画像・音声・動画 REST API は preview であり、安定版 API と同じ前提で本番固定するのは避けるべきです。(Microsoft Learn)

影響範囲:どのシステムが確認対象になるか

今回の Azure AI Foundry の REST API 更新で影響を受けやすいのは、次のようなシステムです。

  • Azure OpenAI の画像生成 API をアプリや業務システムに組み込んでいる
  • 音声合成、文字起こし、翻訳を REST API で直接呼び出している
  • 2025-04-01-preview などの日付付き API バージョンを使っている
  • API Management、WAF、プロキシで /openai/deployments/{deployment-id}/... 形式のパスを許可している
  • 生成動画を後続システムで保存・配信・レビューしている
  • API キーをアプリ設定や環境変数で長期間使っている

特に注意したいのは、旧来の deployment-id を URL パスに含める実装です。2025-04-01-preview の画像・音声 API では /openai/deployments/{deployment-id}/... 形式が使われていますが、v1 preview のリファレンスでは /openai/v1/... 形式になり、model をリクエスト本文で指定する構成が示されています。(Microsoft Learn)

影響が小さいケース

チャット補完や埋め込みだけを使っており、画像・音声・動画 API を呼び出していない環境では、このリファレンス更新による直接影響は限定的です。ただし、Azure OpenAI 全体で v1 API への移行が進んでいるため、今後の新規開発では /openai/v1/ ベースの設計を前提にした方が保守しやすくなります。(Microsoft Learn)

影響が大きいケース

影響が大きいのは、メディア生成をすでに本番業務に組み込んでいるケースです。たとえば、EC 商品画像の自動生成、社内研修動画の自動生成、コールセンター音声の文字起こし、ナレーション生成などでは、API パス変更だけでなく、レスポンス形式、バイナリデータ保存、コンテンツフィルター、監査ログまで確認が必要です。

v1 preview の主な API 操作

公式リファレンスでは、音声、画像、動画の API 操作が整理されています。運用担当者は「どの操作を使っているか」を棚卸ししたうえで、対応するエンドポイントを確認してください。(Microsoft Learn)

分野操作v1 preview のエンドポイント例主な用途
音声Create speechPOST {endpoint}/openai/v1/audio/speech?api-version=previewテキストから音声を生成
音声Create transcriptionPOST {endpoint}/openai/v1/audio/transcriptions?api-version=preview音声を入力言語で文字起こし
音声Create translationPOST {endpoint}/openai/v1/audio/translations?api-version=preview音声を英語テキストに翻訳
画像Create imagePOST {endpoint}/openai/v1/images/generations?api-version=previewプロンプトから画像を生成
画像Create image editPOST {endpoint}/openai/v1/images/edits?api-version=preview画像とプロンプトから編集画像を生成
動画Video generation jobs – CreatePOST {endpoint}/openai/v1/video/generations/jobs?api-version=preview動画生成ジョブを作成
動画Video generation jobs – List/Get/DeleteGET / DELETEジョブ一覧、状態確認、削除
動画Retrieve video contentGET {endpoint}/openai/v1/video/generations/{generation-id}/content/video?api-version=preview生成済み動画を取得
動画Retrieve thumbnailGET {endpoint}/openai/v1/video/generations/{generation-id}/content/thumbnail?api-version=previewサムネイルを取得

動画生成は、画像生成のように単一リクエストで結果を受け取る設計ではなく、ジョブを作成し、状態を確認し、生成物を取得する流れです。生成動画のレスポンスは video/mp4、サムネイルは image/jpg として扱われるため、JSON レスポンスだけを想定した API クライアントや API Management ポリシーでは失敗する可能性があります。(Microsoft Learn)

設定変更で確認すべきポイント

API パスを /openai/v1/ 形式に合わせる

旧 API では、次のようにデプロイ ID をパスに含める形が一般的でした。

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

v1 preview では、画像生成は次のような形式になります。

POST https://{endpoint}/openai/v1/images/generations?api-version=preview
Content-Type: application/json

そして、利用するモデルまたはデプロイ名は本文の model で指定します。

{
  "model": "your-image-deployment",
  "prompt": "A clean product photo on a white background",
  "size": "1024x1024",
  "quality": "auto"
}

この変更により、URL パスだけを見てデプロイ先を判定していたログ設計やルーティング設計は見直しが必要です。API Management でパスベースのポリシーを組んでいる場合は、/openai/v1/images/*、/openai/v1/audio/*、/openai/v1/video/* の許可ルールを追加してください。(Microsoft Learn)

api-version=preview を安易に削らない

v1 API では、日付付き api-version への依存を減らす方向が示されています。一方で、今回の画像・音声・動画 v1 preview リファレンスでは、各エンドポイント例に api-version=preview が明記されています。そのため、既存コードから api-version を単純に削除するのではなく、対象 API ごとに公式リファレンスの指定に合わせる必要があります。(Microsoft Learn)

実務では、共通 API クライアントの設定で「v1 GA 用」と「v1 preview メディア用」を分けておくと安全です。たとえば、テキスト生成系は /openai/v1/responses、画像・音声・動画 preview は ?api-version=preview を付ける、といった形で明確に分岐させます。

API キーより Microsoft Entra ID 認証を優先する

公式リファレンスでは API キーと Bearer トークンのどちらも利用できますが、トークンベース認証の方が推奨されています。Azure CLI でトークンを取得する例や、OAuth のスコープも示されています。(Microsoft Learn)

本番環境では、次の順で見直すのが現実的です。

認証方式向いている用途注意点
Microsoft Entra ID / Managed Identity本番アプリ、社内システム、CI/CDRBAC、トークン更新、実行環境の ID 設計が必要
API キーPoC、短期検証、ローカル開発漏えい時の影響が大きいため、保管・ローテーションが必須
個人ユーザーの手動トークン一時的な検証長期運用に向かない

Microsoft Entra ID を使う場合は、対象 ID に Azure OpenAI を利用できるロールが割り当てられているかも確認してください。v1 API の前提条件として、Microsoft Entra ID 認証では Cognitive Services OpenAI User ロールが示されています。(Microsoft Learn)

音声 API で確認すべき変更点

音声 API では、音声合成、文字起こし、翻訳の 3 種類を分けて確認します。音声合成では input、voice、model などを指定し、入力テキストには最大 4096 文字の上限があります。また、音声速度は 0.25 から 4.0 の範囲で指定でき、既定値は 1 です。(Microsoft Learn)

文字起こしでは、chunking_strategy、language、response_format、timestamp_granularities、stream などのパラメータが重要です。たとえば、単語単位のタイムスタンプを使う場合は verbose_json が必要で、単語タイムスタンプ生成には追加レイテンシが発生する可能性があります。(Microsoft Learn)

実務では、次の観点でテストしてください。

テスト項目確認内容
日本語音声の文字起こし精度language に ja を指定した場合と未指定の場合を比較
長時間音声ファイルサイズ、処理時間、タイムアウトを確認
ストリーミング利用モデルが streaming に対応しているか確認
タイムスタンプセグメント単位で十分か、単語単位が必要か判断
ログ保存音声ファイル名、生成テキスト、モデル名を監査できるか確認

コールセンターや会議録のように個人情報を含む音声を扱う場合は、API の呼び出し成功だけでなく、保存先、アクセス権、削除ルールまで含めて確認する必要があります。

画像 API で確認すべき変更点

画像生成では、gpt-image-1 系、dall-e-2、dall-e-3 で対応パラメータが異なります。たとえば、gpt-image-1 系では png、jpeg、webp の出力形式、背景の透明化、圧縮率、high・medium・low などの品質指定が扱えます。一方で、DALL-E 系では URL または base64 形式、サイズ、スタイル指定などにモデルごとの制約があります。(Microsoft Learn)

特に見落としやすいのが、生成画像 URL の有効期限です。リファレンスでは、DALL-E 2 / DALL-E 3 の url 形式で返される画像 URL は生成後 60 分のみ有効とされています。また、gpt-image-1 系では常に base64 エンコード画像が返されるため、アプリ側で保存処理を実装する必要があります。(Microsoft Learn)

画像生成を業務利用する場合は、次のように設計すると事故を防ぎやすくなります。

利用シーン推奨設計
Web アプリで即時表示base64 または一時 URL を受け取り、必要に応じて自社ストレージへ保存
商品画像・広告画像生成プロンプト、生成結果、レビュー状態をセットで記録
背景透過画像background=transparent と output_format=png または webp の組み合わせを確認
複数案生成n の上限、コスト、レビュー負荷を考えて制限を設ける
監査が必要な環境user パラメータやログでエンドユーザー識別子を管理

画像 API は見た目の結果だけに注目しがちですが、本番では「画像をどこに保存するか」「誰が承認するか」「プロンプトと出力を後から追えるか」が重要です。

動画生成 API で確認すべき変更点

v1 preview で特に注目すべきなのが動画生成 API です。動画生成はジョブベースで、ジョブ作成、一覧取得、個別取得、削除、生成動画取得、サムネイル取得、ヘッダーのみ取得といった操作に分かれています。(Microsoft Learn)

動画生成ジョブの作成では、prompt、model、width、height が必要です。動画の長さは n_seconds で指定し、1〜20 秒の範囲、既定値は 5 秒です。バリエーション数は n_variants で指定し、1〜5 の範囲です。対応寸法として、480×480、854×480、720×720、1280×720、1080×1080、1920×1080 などが示されています。(Microsoft Learn)

運用上、最も重要なのは expires_at です。VideoGenerationJob には、ジョブがサービスから自動削除される時刻を示す expires_at が含まれ、データ損失を避けるために期限前に動画コンテンツとメタデータを保存する必要があると説明されています。(Microsoft Learn)

動画生成の実装フロー

動画生成をアプリに組み込む場合は、次の順序で設計します。

手順処理実装上の注意
1動画生成ジョブを作成job-id を必ず保存する
2ジョブ状態をポーリング完了、失敗、期限切れを分けて処理する
3generation-id を取得複数バリエーションがある場合は選択 UI が必要
4サムネイルを取得レビュー画面や一覧表示に使う
5動画本体を取得video/mp4 として保存する
6保存完了後に不要ジョブを削除保持ポリシーに合わせて削除する

「API が 200 を返したから完了」ではありません。動画生成では、ジョブ管理、生成物の取得、期限前保存、失敗時の再実行まで含めてアプリ設計に組み込む必要があります。

移行期限はあるのか

今回の「Azure OpenAI image, audio, and video REST API reference (v1 preview)」の更新ページ自体には、特定の旧 API をいつ停止する、という移行期限は明示されていません。したがって、「2026年6月24日の更新により、すぐに既存 API が停止する」と断定するのは不正確です。(Microsoft Learn)

ただし、移行期限を考えるうえでは、API 仕様とモデル ライフサイクルを分けて管理する必要があります。Microsoft Foundry Models のライフサイクル ポリシーでは、プレビュー モデルは本番利用が推奨されず、退役時には少なくとも 30 日前に通知され、置換モデルへの強制アップグレードまたは置換なしの退役が行われる場合があります。退役後は推論が 410 Gone を返すことがあります。(Microsoft Learn)

また、モデル退役スケジュールは別ページで管理されており、Azure OpenAI の各モデルについてライフサイクル、退役日、置換モデルが一覧化されています。音声系モデルや GPT 系モデルの退役日も更新されるため、管理者はリファレンス更新だけでなく、モデル退役スケジュールと Models API の確認を運用に組み込むべきです。(Microsoft Learn)

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

API 棚卸し

まず、ソースコード、IaC、API Management、環境変数、CI/CD から旧 API の利用箇所を探します。

grep -R "api-version=2025-04-01-preview" .
grep -R "/openai/deployments/" .
grep -R "/images/generations" .
grep -R "/audio/transcriptions" .

見つかった API 呼び出しについて、次の情報を一覧化してください。

棚卸し項目確認内容
利用 API画像生成、画像編集、音声合成、文字起こし、翻訳、動画生成
利用モデルデプロイ名、モデル名、バージョン
API バージョン日付付き preview か、v1 preview か
認証方式API キー、Microsoft Entra ID、Managed Identity
呼び出し元Web アプリ、バッチ、社内ツール、外部連携
保存先生成画像、音声、動画、ログの保存先
監視失敗率、レイテンシ、コンテンツフィルター、429、410

API Management とネットワーク設定

API Management やプロキシを使っている場合は、POST だけでなく、動画生成で使う GET、DELETE、HEAD も許可する必要があります。レスポンスも JSON だけでなく、application/octet-stream、image/jpg、video/mp4 を扱えるか確認してください。(Microsoft Learn)

よくある失敗は、API Management のポリシーで Content-Type: application/json だけを許可しており、multipart/form-data の音声・画像編集リクエストが拒否されるケースです。音声の文字起こしや画像編集では multipart を使うため、メディア系 API を通す場合は Content-Type の制限を見直してください。(Microsoft Learn)

レスポンスのパースを厳格にしすぎない

v1 API のライフサイクル ガイドでは、新しい API レスポンス オブジェクトが追加される可能性があるため、必要なレスポンス オブジェクトだけをパースすることが推奨されています。これは preview API を扱ううえで重要です。スキーマに未知のフィールドが追加されたときにアプリが落ちる設計は避けてください。(Microsoft Learn)

実装では、次のような方針が安全です。

response = call_api()

required_fields = ["id", "status"]
validate(required_fields)

ignore_unknown_fields(response)
log_known_metadata(response)

特に動画生成ジョブでは、ステータス、生成物 ID、期限、失敗理由など、運用に必要なフィールドを明確に決めておきます。

Service Health と通知を設定する

モデル退役やサービス影響を見落とさないため、Azure Service Health のアラートを設定します。Microsoft の日本語ドキュメントでは、Service Health で個別の “Microsoft Foundry” サービスを探すのではなく、サービス名として Azure OpenAI Service を選択するよう説明されています。(Microsoft Learn)

通知先は、開発者だけでなく、Azure サブスクリプション所有者、運用チーム、セキュリティ担当、業務アプリのオーナーまで含めるのが安全です。退役通知を受け取っても、担当者が不明だと移行作業が止まります。

本番導入するかどうかの判断基準

v1 preview のメディア API は魅力的ですが、すべての環境で即採用すべきとは限りません。次の基準で判断してください。

判断向いているケース注意点
積極的に検証する新規開発、PoC、社内ツール、メディア生成の試験導入仕様変更に備えて疎結合にする
段階的に移行する既存の画像・音声 API を利用中旧 API と v1 preview を並行稼働して比較する
慎重に扱う厳格な SLA、監査、法務確認が必要な本番業務preview の変更、モデル退役、出力差分を考慮する
すぐには移行しないテキスト API のみ利用、メディア API 未使用ただし v1 API 全体の動向は追跡する

本番に近い環境で試す場合は、機能フラグを使い、一部ユーザーや一部ジョブだけを v1 preview に切り替える方法が現実的です。画像・音声・動画は生成結果の差分が業務品質に直結するため、API の疎通確認だけでなく、出力品質、レイテンシ、コスト、保存フローまで比較してください。

移行時に起きやすい失敗と対策

失敗例原因対策
404 または認証エラーになる旧パスと v1 preview パスを混在させているAPI クライアントを v1 用に分離する
モデルが見つからないdeployment-id をパスから消したが、本文の model 指定を忘れているmodel にデプロイ名を明示する
音声ファイル送信に失敗するmultipart/form-data を許可していないAPI Management とクライアントの Content-Type を確認
生成画像が後で見られない一時 URL を永続 URL と誤解している生成後すぐに自社ストレージへ保存
動画が消えるexpires_at 前に保存していないジョブ完了後に自動ダウンロードする
preview 変更でパースエラーレスポンスの全フィールドを厳格検証している必須フィールドのみ検証し、未知フィールドは無視
退役通知に気づかないService Health や所有者メールを見ていないAzure OpenAI Service のアラートを設定

まず実施すべきアクション

Azure AI Foundry で画像・音声・動画 API を使っている場合、最初にやるべきことは「使っている API とモデルの棚卸し」です。そのうえで、旧パス、日付付き preview API、API キー利用、生成物の保存漏れ、動画ジョブの期限管理を確認してください。

次に、検証環境で v1 preview のエンドポイントに切り替え、既存 API と同じ入力で結果を比較します。確認すべき項目は、レスポンス形式、レイテンシ、エラー処理、コンテンツフィルター、保存処理、監査ログです。特に動画生成では、ジョブ作成から動画保存までを一連のワークフローとしてテストする必要があります。

最後に、モデル退役スケジュールと Service Health 通知を運用に組み込みます。今回の公式リファレンス更新だけで即時移行期限が発生するわけではありませんが、プレビュー API とプレビュー モデルは変更の影響を受けやすい領域です。Azure AI Foundry のメディア生成機能を安全に使うには、API 仕様、モデル ライフサイクル、認証、保存設計をセットで管理することが重要です。(Microsoft Learn)

この記事を書いた人

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

コメント

コメントする

目次