Azure REST APIを使ってAzure Load Testingを自動化している場合、今回まず確認すべき結論はシンプルです。Azure Load Testingのdata plane APIにGA版の2026-04-01が追加され、通常のテスト作成・実行・メトリック取得・通知ルール・トリガー関連のREST呼び出しは、この新しいAPIバージョンへの移行候補になります。 一方で、previewで使えていたTest Profile／Test Profile Run系のAPI面は、2026-04-01のGA面から外されているため、単純にapi-versionだけを置き換えると失敗する可能性があります。(GitHub)
2026年5月5日にMicrosoft Learn側のAzure Load Testing data planeドキュメントが更新され、GitHubのAzure REST API仕様PRも同日にマージされています。この記事では、Azure REST APIの今回の更新について、何が変わったのか、どの利用者が対応すべきか、移行時にどこを確認すべきかを実務目線で整理します。(Microsoft Learn)
Azure Load Testingのdata plane API 2026-04-01 GAで何が変わったのか
今回の更新は、Azure Load Testing向けのdata plane API version 2026-04-01をGAとして追加するものです。GitHub PRでは、新しいGA data-plane API versionの追加、TypeSpec設定の更新、stable swaggerとサンプルペイロードの追加が説明されています。(GitHub)
ここで重要なのは、これはAzure Load Testingのリソース作成そのものを扱う管理プレーンではなく、作成済みのAzure Load Testingリソースに対してテスト、テスト実行、ファイル、メトリック、通知、トリガーなどを操作するdata planeの更新だという点です。
たとえば、次のようなREST API呼び出しが対象になります。
PATCH https://{endpoint}/tests/{testId}?api-version=2026-04-01
PATCH https://{endpoint}/test-runs/{testRunId}?api-version=2026-04-01
POST https://{endpoint}/test-runs/{testRunId}/insights:generate?api-version=2026-04-01Microsoft Learnの2026-04-01ドキュメントでは、Data Planeの操作グループとして、Load Test Administration、Load Test Run、Notification Rule Administration、Operations、Trigger Administrationが掲載されています。(Microsoft Learn)
今回の変更点まとめ
| 確認項目 | 内容 | 実務上の見方 |
|---|---|---|
| APIバージョン | 2026-04-01がAzure Load Testingのdata plane GA版として追加 | preview依存を減らしたい環境では移行候補 |
| 仕様ファイル | stable/2026-04-01/loadtestservice.jsonが追加 | OpenAPI/Swaggerからクライアント生成している場合は再生成対象 |
| サンプル | テスト作成、テスト実行、通知、トリガー、メトリック、LROなどの例が追加 | 既存のREST呼び出しやCI/CDジョブの確認に使える |
| Test Profile系 | 2026-04-01のGA面からTest Profile／Test Profile Runが外されている | previewでこの機能を使っている場合は要注意 |
| 公開・更新日 | Microsoft LearnのData Planeページは2026年5月5日更新 | 既存記事や社内手順書の更新タイミングとして扱える |
PRのレビュー情報では、package-2026-04-01がデフォルトタグになり、新しいGA swaggerと多数のexampleファイルが追加されたことも示されています。(GitHub)
対応すべき人、すぐに対応しなくてもよい人
今回のAzure REST API更新は、Azure Load Testingを使っているすべての人に同じ影響があるわけではありません。影響が大きいのは、Azureポータルだけで操作しているユーザーではなく、REST APIや生成クライアントで自動化しているチームです。
| 利用状況 | 対応優先度 | 確認すべきこと |
|---|---|---|
| Azure Load TestingのREST APIを直接呼び出している | 高 | URL内のapi-version、エンドポイント、レスポンス処理 |
| OpenAPI/Swaggerからクライアントを生成している | 高 | stable/2026-04-01ベースで再生成できるか |
| CI/CDで負荷テストを自動実行している | 高 | テスト作成、ファイルアップロード、実行開始、停止、結果取得 |
| Test Profile／Test Profile Runをpreviewで使っている | 高 | GA版に同じAPI面がないため、移行方針を個別確認 |
| Azure SDKやCLIだけを使っている | 中 | SDK/CLI側がどのAPIバージョンを使うか、更新情報を確認 |
| Azureポータルで手動実行しているだけ | 低 | すぐにAPI修正は不要。ただし社内手順書は更新余地あり |
| Azure Load Testingリソースの作成だけをARM/Bicep/Terraformで行っている | 低〜中 | 今回はdata plane中心。管理プレーンのAPI変更とは分けて確認 |
MicrosoftのAPIライフサイクルページでは、Azure Load Testingのpreview API versionは廃止対象になり得ること、廃止後は該当API versionを使ったリクエストが失敗することが説明されています。preview版に依存しているチームは、今回のGA追加を「後で見る」ではなく、棚卸しのきっかけにした方が安全です。(Microsoft Learn)
2026-04-01で使える主な操作グループ
2026-04-01のdata plane APIでは、Azure Load Testingの運用でよく使う操作が複数のグループに整理されています。自社のコードがどのグループに該当するかを先に分けると、移行確認が楽になります。
Load Test Administration
Load Test Administrationは、負荷テストそのものを管理するAPI群です。Microsoft Learnでは、テストの作成・更新、クローン、削除、テストファイルの取得・アップロード、アプリコンポーネント、サーバーメトリック設定、テスト計画の推奨生成などが掲載されています。(Microsoft Learn)
代表的な作成・更新APIは次の形式です。
PATCH https://{endpoint}/tests/{testId}?api-version=2026-04-01このAPIでは、displayName、kind、loadTestConfiguration、passFailCriteria、autoStopCriteria、secrets、environmentVariables、subnetIdなどを扱えます。JMXだけでなくLocustのサンプルも掲載されているため、既存のテスト種別ごとにリクエストボディを比較するとよいでしょう。(Microsoft Learn)
Load Test Run
Load Test Runは、テスト実行を作成・開始し、停止、取得、メトリック参照、ファイル参照、Insights生成などを行うAPI群です。Create Or Update Test Runでは、指定したtestRunIdで新しいテスト実行を作成して開始できます。(Microsoft Learn)
代表的な呼び出しは次の形式です。
PATCH https://{endpoint}/test-runs/{testRunId}?api-version=2026-04-01再実行に使うoldTestRunIdを任意パラメータとして指定できるため、既存のCI/CDで「前回条件を再利用して実行する」処理を組んでいる場合は、このパラメータの扱いも確認してください。(Microsoft Learn)
Notification Rule AdministrationとTrigger Administration
Notification Rule Administrationでは通知ルールの作成・更新・削除・取得・一覧取得ができます。Trigger Administrationではトリガーの作成・更新・削除・取得・一覧取得ができます。(Microsoft Learn)
負荷テストを定期実行したり、結果に応じて通知する仕組みを組んでいる場合は、テスト実行APIだけでなく、この2つの操作グループも移行対象に含めてください。特に、通知やトリガーは「テスト自体は成功したのに周辺自動化だけ失敗する」ケースが起きやすい部分です。
Operations
Operationsには、長時間実行操作の状態取得が含まれます。Generate InsightsやGenerate Test Plan RecommendationsのようなAPIは202 Acceptedを返し、Operation-Locationヘッダーを使って進捗確認する形になります。(Microsoft Learn)
そのため、移行時は「HTTP 200なら成功」という単純な実装だけでなく、202 Accepted、Operation-Location、ポーリング、失敗時のerror処理までテストする必要があります。
Test Profile／Test Profile Runを使っている場合は特に注意
今回もっとも見落としやすいのは、Test Profile／Test Profile Runの扱いです。
GitHub PRでは、2026-04-01のGA面からTest Profile／Test Profile Run surfacesを削除したことが明記されています。レビューIssue側では「latest preview API versionをGAにする」「新機能は追加していない」「Test ProfileとTest Run Profileの一部機能をdeprecatedにした」「breaking changeは導入していない」と説明されています。(GitHub)
一方、2025-11-01-previewのMicrosoft Learnドキュメントには、Test Profile作成APIとして次のようなエンドポイントが掲載されています。
PATCH https://{endpoint}/test-profiles/{testProfileId}?api-version=2025-11-01-previewまた、Test Profile Run作成APIとして次のようなエンドポイントも掲載されています。
PATCH https://{endpoint}/test-profile-runs/{testProfileRunId}?api-version=2025-11-01-previewこれらはpreview版のAPIとして確認でき、Test ProfileにはtargetResourceIdやtargetResourceConfigurations、Test Profile RunにはtestProfileIdや推奨情報などのモデルが含まれています。(Microsoft Learn)
つまり、/testsや/test-runsを使う通常の負荷テスト自動化と、/test-profilesや/test-profile-runsを使うpreview機能は、移行時に分けて扱う必要があります。
Test Profile利用時の判断基準
| 現在の実装 | 判断 | 対応 |
|---|---|---|
/testsと/test-runsだけを使っている | 移行しやすい | 2026-04-01で同等の操作を検証 |
/test-profilesを使っている | 要注意 | GA版に同じAPI面がないため、設計を確認 |
/test-profile-runsを使っている | 要注意 | 単純なapi-version置換は避ける |
| Test Profileの推奨結果を業務判断に使っている | 高リスク | 代替運用、保持データ、レポート仕様を確認 |
| preview機能をPoCだけで使っていた | 中 | GA運用へ載せる前に機能の扱いを見直す |
実務では、まずリポジトリ全体を検索して、test-profiles、test-profile-runs、2025-11-01-preview、2024-05-01-previewなどの文字列が残っていないか確認してください。該当があれば、通常のAPI移行チケットとは別に、Test Profile系の仕様確認チケットを切るのがおすすめです。
移行前に確認するチェックリスト
Azure REST APIのAPIバージョン移行は、URLのクエリパラメータを変えるだけに見えます。しかし、実際には認証、レスポンス、生成クライアント、CI/CD、監視まで影響することがあります。
まずコード内のAPIバージョンを棚卸しする
最初に、アプリケーション、CI/CD定義、社内スクリプト、Postmanコレクション、IaC補助スクリプトを検索します。
検索する文字列の例は次の通りです。
api-version=
rest-loadtesting-dataplane
loadtesting.azure.com
cnt-prod.loadtesting.azure.com
/test-runs
/tests
/test-profiles
/test-profile-runsapi-versionが環境変数や設定ファイルに集約されている場合は比較的安全です。逆に、複数のシェルスクリプトやYAML内に直書きされている場合は、移行漏れが起きやすくなります。
エンドポイントと認証スコープを確認する
2026-04-01の各APIは、https://{endpoint}/...形式のdata planeエンドポイントを使います。認証はMicrosoft Entra IDのOAuth 2.0で、スコープとしてhttps://cnt-prod.loadtesting.azure.com/.defaultが示されています。 (Microsoft Learn)
よくあるミスは、管理プレーンのhttps://management.azure.com/...向けに取得した考え方のまま、data planeのエンドポイントを呼び出してしまうことです。認証エラーや権限エラーが出た場合は、APIバージョンより先に「どのエンドポイントに、どのトークンで、どの権限でアクセスしているか」を確認してください。
ID制約を満たしているか確認する
testIdやtestRunIdには、長さや文字種の制約があります。Microsoft Learnでは、testIdやtestRunIdについて、2〜50文字、小文字英字・数字・アンダースコア・ハイフンのパターンが示されています。(Microsoft Learn)
既存システムで、ビルド番号やブランチ名をそのままIDに使っている場合は注意が必要です。たとえば、Feature/Add-Login-Test#123のような文字列は大文字、スラッシュ、シャープを含むため、そのままでは制約に合いません。CI/CDで使う場合は、事前に小文字化し、許可されない文字を-に置換する処理を入れておくと安全です。
LROの完了確認をテストする
Insights生成やテスト計画推奨の生成では、レスポンスが即時完了ではなく202 Acceptedになり、Operation-Locationが返ります。(Microsoft Learn)
移行テストでは、次の3点を確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| 開始レスポンス | 202 AcceptedとOperation-Locationを正しく受け取れるか |
| ポーリング | 完了まで待つ処理がタイムアウトやリトライを考慮しているか |
| 失敗時 | Failedやエラーオブジェクトをログに残せるか |
単体テストでは成功していても、CI/CDではポーリング間隔が短すぎてAPI制限やタイムアウトに近い動きになることがあります。負荷テスト実行の自動化では、API呼び出しそのものよりも「完了をどう待つか」が品質を左右します。
具体的な移行手順
現在のAPI利用箇所を分類する
まず、API呼び出しを次の4種類に分けます。
| 分類 | 例 | 方針 |
|---|---|---|
| テスト管理 | /tests/{testId}、ファイルアップロード、サーバーメトリック設定 | 2026-04-01で動作確認 |
| テスト実行 | /test-runs/{testRunId}、停止、メトリック取得 | 2026-04-01で動作確認 |
| 通知・トリガー | notification rules、triggers | テスト本体とあわせて確認 |
| Test Profile系 | /test-profiles、/test-profile-runs | 個別に移行可否を判断 |
この分類をせずに一括置換すると、Test Profile系やLRO周りで不具合を見落としやすくなります。
開発環境でapi-version=2026-04-01に切り替える
通常のテスト作成・実行APIであれば、まず開発環境や検証用のAzure Load Testingリソースでapi-versionを変更します。
変更前の例です。
PATCH https://{endpoint}/tests/{testId}?api-version=2025-11-01-preview変更後の例です。
PATCH https://{endpoint}/tests/{testId}?api-version=2026-04-01このとき、リクエストボディを変えずに動くかだけを見るのではなく、レスポンスのプロパティ、ステータスコード、エラー形式、後続処理で使っている値まで確認してください。
生成クライアントを使っている場合は再生成する
OpenAPI/Swaggerからクライアントを生成している場合は、stable/2026-04-01/loadtestservice.jsonを前提に再生成する流れになります。PRでは、このstable swaggerと関連exampleが追加されています。(GitHub)
特に注意すべきなのは、古い生成コードにpreviewのモデルやoperationが残ることです。コード生成後は、次の観点で差分を確認してください。
| 確認箇所 | チェック内容 |
|---|---|
| operation名 | 削除・追加されたメソッドがないか |
| モデル | Test Profile系の型が残っていないか |
| enum | 状態値やkindの扱いが変わっていないか |
| サンプル | 既存のリクエストボディが新仕様の例と矛盾しないか |
| エラー処理 | x-ms-error-codeやerror objectをログ化できるか |
CI/CDでスモークテストを流す
本番反映前に、最低限次のシナリオをCI/CDで通します。
| テスト | 成功条件 |
|---|---|
| テスト作成・更新 | PATCH /tests/{testId}が200または201で完了 |
| テストファイルアップロード | JMX、Locust、設定ファイルなどが想定どおり登録される |
| テスト実行開始 | PATCH /test-runs/{testRunId}で実行が作成される |
| 実行停止 | 停止APIが期待どおり動作する |
| 実行結果取得 | ステータス、メトリック、ファイル情報を取得できる |
| 通知・トリガー | ルール作成、一覧取得、削除ができる |
| LRO | Insights生成や推奨生成のポーリングが完了する |
ここで重要なのは、「APIが呼べた」だけで合格にしないことです。負荷テストの自動化では、テスト結果の取得、しきい値判定、通知、レポート生成まで含めて初めて業務上の成功になります。
移行時に失敗しやすいポイント
api-versionだけを一括置換してしまう
もっとも危険なのは、検索置換で2025-11-01-previewを2026-04-01に変えるだけの移行です。通常の/testsや/test-runsでは動いても、Test Profile系のpreviewエンドポイントでは同じように扱えない可能性があります。
一括置換をする場合でも、事前に/test-profilesと/test-profile-runsを除外しておくと安全です。
管理プレーンとdata planeを混同する
Azure REST APIでは、リソースを作成・削除する管理プレーンと、サービス内のデータや実行を扱うdata planeが分かれます。今回の更新はAzure Load Testingのdata plane APIに関するものです。
そのため、BicepやARMテンプレートでAzure Load Testingリソースを作成しているだけのコードに対して、無理に今回の2026-04-01を当てはめる必要はありません。逆に、CI/CDで負荷テストを起動しているスクリプトはdata planeの可能性が高いため、優先して確認してください。
preview廃止リスクを軽く見る
MicrosoftのAPIライフサイクル説明では、廃止されたAPI versionを使うリクエストは最終的に失敗するとされています。(Microsoft Learn)
preview APIを使い続けること自体が即座に問題になるとは限りませんが、運用負荷は高くなります。特に、毎週・毎日走る負荷テストやリリース判定に組み込まれているAPIは、失敗すると開発フロー全体を止める可能性があります。
サンプルの成功レスポンスだけで判断する
Microsoft Learnのサンプルは確認に役立ちますが、実際の環境では権限、リージョン、サブネット、Key Vault、Managed Identity、メトリック対象リソースなどの条件が絡みます。
たとえば、Create Or Update Testでは、Key Vault参照、Managed Identity、サブネット、サーバーメトリック、CSV分割など複数の設定項目があります。(Microsoft Learn)
本番相当の設定を使わずに最小リクエストだけで確認すると、移行後に「APIバージョンは合っているが、実運用設定で失敗する」という状態になりやすいです。
実務でおすすめの対応方針
今回のAzure REST API更新に対しては、次の順番で進めるとリスクを抑えられます。
| 順番 | 作業 | 目的 |
| -: | —————————- | —————– |
| 1 | REST API利用箇所を棚卸し | 影響範囲を明確にする |
| 2 | Test Profile系の有無を確認 | 単純移行できない箇所を先に分ける |
| 3 | 通常の/tests、/test-runsから検証 | 主要な自動化をGA APIへ寄せる |
| 4 | 通知、トリガー、メトリック取得を確認 | 周辺機能の移行漏れを防ぐ |
| 5 | LROとエラー処理を確認 | CI/CDでの失敗検知を安定させる |
| 6 | 生成クライアントや社内手順書を更新 | 属人化と古いAPIの再利用を防ぐ |
| 7 | 本番反映後にログ監視 | 移行直後の予期しない失敗を拾う |
特に、社内で複数チームがAzure Load Testingを使っている場合は、共通ライブラリや共通テンプレートにapi-versionを集約するのが効果的です。各チームのYAMLやスクリプトにAPIバージョンが散らばっていると、次回以降のREST API更新でも同じ調査を繰り返すことになります。
まとめ：まずはpreview依存とTest Profile利用を確認する
今回のAzure REST APIドキュメント更新では、Azure Load Testingのdata plane APIにGA版2026-04-01が追加されました。通常の負荷テスト作成、実行、停止、メトリック取得、通知、トリガーをREST APIで自動化している場合は、移行候補として確認する価値があります。
一方で、Test Profile／Test Profile Run系は2026-04-01のGA面から外されているため、preview版の該当APIを使っている場合は注意が必要です。まずはコードとCI/CD定義を検索し、api-version、/tests、/test-runs、/test-profiles、/test-profile-runsを棚卸ししてください。
次に取るべき行動は、通常のテスト実行APIは2026-04-01で検証し、Test Profile系は別枠で仕様確認することです。これにより、GA APIへの移行を進めつつ、preview機能の扱いで本番自動化を壊すリスクを減らせます。
コメント