Azure REST API documentation updateとして公開された「Remove data gen Task type option」は、Azure AI Foundryのdata generation jobs関連仕様から task タイプを外す変更です。結論から言うと、REST APIやSDK、OpenAPI定義、テストデータで type: "task" や TaskDataGenerationJobOptions を使っている場合は確認が必要です。単なる説明文の修正ではなく、OpenAPI/TypeSpec上の列挙値とモデル定義が削除されているため、コード生成・バリデーション・CIで影響が出る可能性があります。(GitHub)
2026年5月5日にAzure REST API仕様リポジトリのPR #42867がマージされ、対象は specification/ai-foundry/data-plane/Foundry 配下のOpenAPI 3定義とTypeSpec定義です。特に、Azure AI Foundryで合成データ生成やfine-tuning向けデータ生成をREST APIまたはSDK経由で扱っているチームは、リクエストボディ、SDKモデル、テストケース、ドキュメントを早めに見直すべきです。(GitHub)
Azure REST API documentation updateで変更された内容
今回のAzure REST API documentation updateでは、data generation jobsのタスク種別から task が削除されています。PRの差分では、OpenAPIのdiscriminator mappingから task: '#/components/schemas/TaskDataGenerationJobOptions' が削除され、DataGenerationJobType のenumからも task が外されています。あわせて、TaskDataGenerationJobOptions というスキーマ自体も削除されています。(GitHub)
変更はJSON/YAMLのOpenAPI定義だけでなく、TypeSpecの元定義にも入っています。TypeSpec側では DataGenerationJobType の task: "task" と、TaskDataGenerationJobOptions モデルが削除されています。これは、ドキュメント表示だけでなく、仕様から生成されるSDKや型定義にも波及し得る変更と見るべきです。(GitHub)
| 確認項目 | 変更前 | 変更後 |
|---|---|---|
DataGenerationJobType | simple_qna、traces、tool_use、task | simple_qna、traces、tool_use |
| discriminator mapping | task が TaskDataGenerationJobOptions に紐付く | task の紐付けが削除 |
TaskDataGenerationJobOptions | スキーマとして存在 | 削除 |
| TypeSpec定義 | task: "task" と専用モデルが存在 | どちらも削除 |
| 対象ファイル | OpenAPI/TypeSpec | v1、virtual-public-preview、TypeSpecソースに反映 |
影響を受ける可能性が高い人
この変更で最も影響を受けるのは、Azure AI Foundryのdata generation jobsをREST API仕様に基づいて利用している開発者です。特に、プレビュー機能を試しながらREST APIリクエストを自作しているチーム、OpenAPIからSDKやクライアントコードを生成しているチーム、API仕様差分をCIで検証しているチームは注意が必要です。
| 対象 | 確認すべきこと |
|---|---|
| REST APIを直接呼び出している開発者 | リクエストボディに type: "task" が残っていないか |
| SDK利用者 | 生成SDKや型定義に TaskDataGenerationJobOptions、DataGenerationJobType.task 相当が残っていないか |
| OpenAPI/TypeSpecからコード生成しているチーム | 最新仕様で再生成したときにビルドエラーや型エラーが出ないか |
| APIテスト担当者 | 正常系・異常系テストに task 前提のケースが残っていないか |
| 技術記事・社内手順書の管理者 | 「taskを選択する」「Task typeを指定する」といった説明が残っていないか |
| CIでSwagger/OpenAPI差分を見ているチーム | enum削除を破壊的変更として扱うルールに引っかからないか |
PR上では data-plane と TypeSpec のラベルが付いており、APIレベルの変更としてAPIViewによるTypeSpec、Python、JavaScript向けレビューも作成されています。さらに Swagger BreakingChange チェックが失敗しているため、少なくとも仕様上は「既存利用者に影響し得る変更」として扱うのが安全です。(GitHub)
すぐ確認すべきコードと設定
まずは、自社のコードベースで task がどこに使われているかを洗い出します。ポイントは、単純な文字列検索だけで終わらせないことです。task は一般的な単語なので、data generation jobsの type として使っている箇所を絞り込む必要があります。
Linux/macOSなら、次のように検索します。
grep -R '"task"\|TaskDataGenerationJobOptions\|DataGenerationJobType' .PowerShellなら、次のように検索できます。
Get-ChildItem -Recurse -File | Select-String -Pattern '"task"', 'TaskDataGenerationJobOptions', 'DataGenerationJobType'見つかった箇所では、次の観点で仕分けします。
| 見つかった内容 | 判断 |
|---|---|
"type": "task" | data generation jobのリクエストなら修正候補 |
TaskDataGenerationJobOptions | 新しい仕様では削除対象のため、SDK更新時にエラー化する可能性あり |
DataGenerationJobType.task / Task | enum値として使っているなら置き換えが必要 |
テストフィクスチャ内の "task" | 古い仕様に基づくテストデータの可能性あり |
| UI表示文言の「Task」 | 実際のAPI仕様と一致しているか確認が必要 |
ここで大事なのは、task を機械的に tool_use や simple_qna に置き換えないことです。task が何を意図していたかを確認せずに置き換えると、入力ファイル形式や生成されるデータの目的がずれてしまいます。
task は何に置き換えるべきか
置き換え先は、利用目的で判断します。Microsoft Learnの合成データ生成プレビューでは、ポータルで選べるgenerator typeとして「Simple Q&A」と「Tool use」が説明されています。Simple Q&Aはドメイン文書から質問回答ペアを作る用途、Tool useはAPIサーフェスに対するツール呼び出しを含む会話を生成する用途です。(Microsoft Learn)
| これまでの意図 | 検討する置き換え先 | 注意点 |
|---|---|---|
| 文書からQ&A形式のfine-tuningデータを作りたい | simple_qna | PDF、Markdown、テキストなど文書ベースの入力に寄せる |
| API呼び出しを含む会話データを作りたい | tool_use | OpenAPI 3.0.xまたは3.1.xのJSON仕様ファイルが必要 |
| 既存ログや会話履歴に基づくデータを扱っている | traces の利用可否を確認 | REST API仕様上は残っていても、UIや利用条件と一致するとは限らない |
| 「タスク説明からマルチターン会話を作る」目的だった | 公式ドキュメントと現在のAPI仕様を再確認 | task の単純な後継が明示されていない場合は、要件を分解して再設計する |
特に tool_use へ移行する場合は、入力が「自然文のタスク説明」ではなく、APIを表現したOpenAPI仕様になる点に注意してください。Microsoft Learnでは、Tool useの参照ファイルとしてOpenAPI 3.0.xまたは3.1.xのJSONファイルが示されています。(Microsoft Learn)
移行時の実務手順
まずAPIリクエストの実態を確認する
ログ、テスト、サンプルコードから、実際に送っているリクエストボディを確認します。古いサンプルでは、次のような形で task を指定している可能性があります。
{
"type": "task"
}このようなリクエストがある場合、最新仕様に合わせたリクエストへ変更する必要があります。ただし、APIのエンドポイント、必須プロパティ、対応リージョン、プレビュー条件は時期によって変わる可能性があります。修正時は、利用しているAPIバージョンと現在のMicrosoft Learn上のREST APIリファレンスを必ず照合してください。
SDKの型エラーを先に出す
SDKを使っている場合は、仕様変更後のSDKまたは生成クライアントでビルドを通してみるのが早道です。TaskDataGenerationJobOptions や DataGenerationJobType.task のような型が削除されていれば、コンパイル時点で検出できます。
動的型付けのJavaScriptやPythonでは、ビルド時に気づけないことがあります。その場合は、API呼び出し直前のpayloadをログに出し、type に何が入っているかをテストで検証します。
assert payload["type"] != "task"expect(payload.type).not.toBe("task");OpenAPI由来のバリデーションを更新する
OpenAPIスキーマを使ってリクエストを検証している場合、enumから task が消えることで、古いテストデータが不正扱いになる可能性があります。これは悪いことではなく、むしろ本番前に古い仕様への依存を検出できる良いサインです。
確認すべき対象は次の通りです。
| 対象 | 具体例 |
|---|---|
| JSON Schemaバリデーション | type enumに task が残っていないか |
| モックサーバー | task リクエストを正常応答として返していないか |
| Contract Test | 古いOpenAPI定義を参照していないか |
| SDK生成設定 | キャッシュされた古いspecを使っていないか |
| APIドキュメント | サンプルpayloadに task が残っていないか |
失敗しやすいポイント
「documentation updateだから実装には関係ない」と判断する
今回の変更は、READMEや説明文だけの修正ではありません。OpenAPIのenum、discriminator mapping、スキーマ、TypeSpecモデルに変更が入っています。REST API仕様を基準にSDKやクライアントを生成している環境では、ドキュメント更新がそのまま実装差分として現れることがあります。(GitHub)
task を一般的な業務タスク名として残してしまう
task という単語はログ、ジョブ名、UI文言、バックログ管理などにも使われます。検索結果をすべて修正するのではなく、data generation jobの type として使っている箇所だけを見極めてください。
判断に迷う場合は、周辺に次の単語があるかを見ます。
DataGenerationJobTypeDataGenerationJobOptionsTaskDataGenerationJobOptionssimple_qnatool_usetracesfine-tuningsynthetic data generation
これらが近くに出てくる場合は、今回の変更と関係している可能性が高くなります。
v1 だけ、またはpreviewだけを確認して終わる
PRの変更対象には、OpenAPI 3の v1 と virtual-public-preview の両方が含まれています。片方の仕様だけを見て「まだ task が使える」と判断すると、実際に利用しているAPIバージョンやSDK生成元とずれる可能性があります。(GitHub)
ポータルの選択肢とREST API仕様を混同する
Microsoft Learnの合成データ生成プレビューでは、ポータル上のtask typeとしてSimple Q&AまたはTool useを選ぶ手順が示されています。一方、REST API仕様上は traces が残っているため、「ポータルに見える選択肢」と「REST API仕様に存在するenum」は必ずしも同じ粒度ではありません。(Microsoft Learn)
実務では、次のように整理すると混乱を避けられます。
| 見る場所 | 目的 |
|---|---|
| Microsoft Learnの操作手順 | ポータルで何を選べるか、どの入力ファイルが必要かを確認する |
| Azure REST API仕様 | REST API/SDK/型定義として何が許可されるかを確認する |
| 自社の実行ログ | 実際にどのpayloadを送っているかを確認する |
| SDKのリリースノート | 利用中のSDKに仕様変更が反映済みかを確認する |
対応の優先順位
すべてのAzure REST API利用者がすぐに修正を迫られるわけではありません。優先順位は、task への依存度で決めます。
| 優先度 | 状況 | 対応 |
|---|---|---|
| 高 | 本番または検証環境で type: "task" を送っている | 代替タイプを検討し、APIバージョンごとに動作確認する |
| 高 | OpenAPI/TypeSpecからSDKを自動生成している | 最新仕様で再生成し、ビルド・テストを実行する |
| 中 | サンプルコードや社内手順書に task がある | 利用実態を確認し、誤った手順を更新する |
| 中 | CIでSwagger BreakingChangeやOpenAPI diffを見ている | enum削除を検出したときの対応フローを確認する |
| 低 | simple_qna や tool_use のみ使っている | 直接修正は不要な可能性が高いが、テストで再確認する |
移行後に確認したいテストケース
移行後は、単にリクエストが通るかだけでなく、生成されるデータが目的に合っているかを確認してください。data generation jobsはfine-tuning用データに直結するため、API呼び出しが成功しても、出力形式や品質がずれていれば後工程で問題になります。
| テスト | 確認内容 |
|---|---|
| リクエスト検証 | type に task が入っていない |
| 正常系APIテスト | 新しいタイプでジョブを作成できる |
| 異常系APIテスト | 古い task 指定時のエラーを想定できている |
| SDKテスト | 削除された型やenumに依存していない |
| データ品質確認 | 生成されたJSONLや会話データがfine-tuning目的に合っている |
| ドキュメント確認 | 社内手順、チュートリアル、サンプルが最新仕様に合っている |
Microsoft Learnでも、合成データ生成はプレビューであり、機能・形式・制限が変わる可能性があるため、本番利用前に出力を検証するよう注意されています。(Microsoft Learn)
今回の変更をどう受け止めるべきか
今回の「Remove data gen Task type option」は、Azure REST APIの全サービスにまたがる大規模変更ではありません。ただし、Azure AI Foundryのdata generation jobsをREST API、SDK、OpenAPI生成コードで扱っている場合は、無視しないほうがよい変更です。
対応の出発点はシンプルです。まずコードベースから type: "task"、TaskDataGenerationJobOptions、DataGenerationJobType.task を探し、該当箇所が実際のdata generation jobsに関係するか確認します。関係がある場合は、simple_qna、tool_use、必要に応じて traces のどれが目的に合うかを見直し、入力ファイル形式と生成結果まで含めてテストしてください。
最後に、OpenAPIやTypeSpecを使ってSDKを生成しているチームは、今回のようなenum削除を「仕様の整理」ではなく「クライアント実装に影響する可能性のある変更」として扱うべきです。API仕様の更新を定期的に取り込み、生成コード・テスト・社内ドキュメントを同じタイミングで更新する運用にしておくと、プレビュー機能の変更にも振り回されにくくなります。
コメント