Azure REST API更新まとめ：2026-05-15-preview追加でBatch revocationとprogramTypeは何が変わる？

2026年5月5日に更新されたAzure REST APIのドキュメント更新では、Microsoft.CodeSigning、つまりArtifact SigningのARMコントロールプレーンAPIに、2026-05-15-previewが追加される点が重要です。特に確認すべき変更は、証明書失効を複数件まとめて扱うrevokeCertificatesアクションと、Certificate Profileに追加されるprogramTypeプロパティです。Azure REST APIを直接呼び出しているチーム、SDKを自動生成しているチーム、Terraform AzAPIやARM/BicepでArtifact Signingを管理しているチームは、既存のapi-version固定、失効処理のリクエスト形式、プレビューAPIを本番で使う判断基準を確認してください。

今回の変更は、署名処理そのもののデータプレーンではなく、Azure Resource Manager経由でリソースを作成・更新・削除するControl Plane API側の仕様変更です。PR上でもARM関連仕様の変更であることが示されており、GitHub上ではMicrosoft.CodeSigning向けの新しいプレビューAPIバージョン、Swagger、TypeSpec、サンプルJSONが追加されています。(GitHub)

今回のAzure REST API更新で押さえるべき結論

今回の「Azure REST API documentation update: Added 2026-05-15 public preview version with Batch revocation and WESP program type changes in CP」は、既存のすべての利用者が即時移行すべき更新ではありません。まず行うべきことは、現在の自社環境がMicrosoft.CodeSigningのARM APIを直接使っているか、SDK・IaC・自動化スクリプト経由で使っているかを棚卸しすることです。

特に影響が出やすいのは、以下のようなケースです。

確認対象	影響の可能性	最初に見るべきポイント
REST APIを直接呼び出している	高い	`api-version`、URLパス、POST本文
AutoRestやTypeSpecからSDKを生成している	高い	メソッド名、モデル名、破壊的変更レビュー
Terraform AzAPI、ARMテンプレート、Bicepで管理している	中〜高	`apiVersion`と`programType`の扱い
Azure portal中心で操作している	低〜中	今後の画面反映、プレビュー利用可否
証明書失効をインシデント対応手順に組み込んでいる	高い	一括失効時の監査ログ、リトライ設計

注意したいのは、PRが確認された時点でGitHub上ではOpen状態で、DoNotMerge、NotReadyForARMReview、BreakingChangeReviewRequiredなどのラベルも確認できます。つまり、実運用で採用する前に、PRのマージ状況、Microsoft LearnのREST APIリファレンスへの反映、SDKリリース状況を必ず確認する必要があります。(GitHub)

変更点の全体像

今回の更新は、Artifact Signingの管理APIに対するプレビュー仕様の追加です。Artifact Signingは、証明書の取得・保護・ビルドパイプラインへの統合といったコード署名の運用を簡素化する、Microsoftのフルマネージド署名ソリューションです。Microsoft Learnでは、証明書ライフサイクル管理、開発者ツール連携、Public Trust・Private Trust・VBS enclave・CI policy・test signingなどの署名シナリオへの対応が説明されています。(Microsoft Learn)

今回のPRで重要なのは、次の3点です。

変更点	内容	実務上の意味
`2026-05-15-preview`の追加	`Microsoft.CodeSigning`向けの新しいプレビューAPIバージョン	新機能検証時に明示的な`api-version`指定が必要
Batch revocation	Certificate Profile配下の複数証明書を`revokeCertificates`で指定	インシデント時の複数証明書失効を自動化しやすくなる
`programType`の追加	Certificate Profileの用途を示す任意の文字列プロパティ	WESPなど特定用途向けプロファイル管理に使われる可能性がある

PRのレビューコメントでは、新しいpackage-2026-05-15-previewタグ、生成されたSwagger、revokeCertificatesアクション、RevokeCertificateListモデル、Certificate ProfileのprogramTypeプロパティ、各種サンプルの追加が整理されています。(GitHub)

Batch revocationとは何が変わるのか

最も実務影響が大きいのは、証明書失効アクションの変更です。従来の単一証明書向けアクションrevokeCertificateは、2026-05-15-previewでは削除扱いとなり、新たに複数証明書を扱うrevokeCertificatesが追加されています。TypeSpec上では、旧アクションに@removed(Versions.v2026_05_15_preview)、新アクションに@added(Versions.v2026_05_15_preview)が付いています。(GitHub)

新しいREST APIのパスは、次の形式です。

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.CodeSigning/codeSigningAccounts/{accountName}/certificateProfiles/{profileName}/revokeCertificates?api-version=2026-05-15-preview

リクエスト本文では、revokeCertificates配列に複数の証明書を指定します。サンプルでは、serialNumber、thumbprint、effectiveAt、reason、remarksを持つオブジェクトを配列で渡し、成功時は204が返る形になっています。(GitHub)

{
  "revokeCertificates": [
    {
      "serialNumber": "xxxxxxxxxxxxxxxxxx",
      "thumbprint": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
      "effectiveAt": "2026-05-15T00:00:00Z",
      "reason": "KeyCompromised",
      "remarks": "Incident INC-12345"
    },
    {
      "serialNumber": "yyyyyyyyyyyyyyyyyy",
      "thumbprint": "yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy",
      "effectiveAt": "2026-05-15T00:00:00Z",
      "reason": "KeyCompromised",
      "remarks": "Incident INC-12345"
    }
  ]
}

この変更により、複数の証明書を同じCertificate Profile配下で失効する運用は書きやすくなります。ただし、PR内の仕様だけでは「配列内の一部だけ失敗した場合の扱い」「一度に指定できる最大件数」「同一証明書を再指定した場合の冪等性」までは判断できません。実装時は、1リクエストを過度に大きくせず、証明書ごとのserialNumberとthumbprintを事前に記録し、レスポンスと監査ログを照合できる形にしておくのが安全です。

`programType`は何に使われるのか

もう一つの注目点は、Certificate ProfileのpropertiesにprogramTypeが追加されることです。TypeSpecでは、programTypeは2026-05-15-previewで追加された任意の文字列プロパティで、「リソースが特定の利用シナリオを意図しているかを示す」と説明されています。(GitHub)

PRタイトルには「WESP program type changes」とあります。WESPはWindows Endpoint Security Platformの略で、MicrosoftのWindows Resiliency Initiativeの説明では、Windowsの保護・セキュリティソリューションをカーネル外で実行できるようにする取り組みとして紹介されています。(Microsoft)

ただし、今回の差分上ではprogramTypeは文字列であり、列挙型として具体的な許可値が定義されているわけではありません。サンプルには"programType": "test"のような値が見られますが、これを本番値として流用すべきではありません。WESP向けにどの値を設定すべきかは、公開ドキュメント、Microsoftからの案内、または対象プログラムのオンボーディング資料で確認する必要があります。

実務では、次のように扱うのが無難です。

判断ポイント	推奨対応
WESPなど特定プログラム向けの明確な案内がある	指定値・対象プロファイル・利用条件を確認して設定
既存の通常署名プロファイルを運用している	すぐに`programType`を追加しない
IaCでCertificate Profileを作っている	`programType`を任意項目として扱い、環境変数化や条件分岐を検討
SDKモデルに新プロパティが出た	未設定時の差分検出や再デプロイ挙動をテスト

`api-version`を固定しているかを確認する

Azure Resource ManagerのREST APIでは、https://management.azure.com/に対してリクエストを送り、必要なクエリ文字列パラメーターとしてapi-versionを指定します。Microsoft LearnのAzure REST APIリファレンスでも、Resource ManagerプロバイダーAPIではapi-versionが必要であることが説明されています。(Microsoft Learn)

今回のようなプレビューAPI追加では、api-versionの扱いが非常に重要です。既存システムが安定版や旧プレビューに固定されていれば、通常は即座に動作が変わることはありません。一方で、SDK自動生成や社内ラッパーで「最新プレビューを使う」ような運用をしている場合、単一失効アクションから一括失効アクションへの変更でビルドエラーや実行時エラーが発生する可能性があります。

確認すべき箇所は、次の4つです。

場所	探す文字列の例
RESTクライアント	`api-version=2024-09-30-preview`、`api-version=2025-10-13`
IaC	`Microsoft.CodeSigning/codeSigningAccounts`、`certificateProfiles`
ソースコード	`revokeCertificate`、`revokeCertificates`
SDK生成設定	`package-2026-05-15-preview`、`CodeSigning.Management`

既存の本番環境では、安定して動いているapi-versionを不用意に変更しないことが重要です。プレビューAPIは、新機能検証用のサブスクリプションや検証用リソースグループで先に試し、失効処理や再作成処理の影響を確認してから段階的に適用してください。

PowerShellで検証する場合の考え方

Az PowerShellにまだ専用コマンドレットがない機能を試す場合は、Invoke-AzRestMethodが便利です。Microsoft Learnでも、Azコンテキストを使ってARMエンドポイントへカスタムHTTP要求を送れるコマンドレットとして説明されています。(Microsoft Learn)

検証用のイメージは次の通りです。

$subId = "<subscription-id>"
$rg = "<resource-group-name>"
$account = "<code-signing-account-name>"
$profile = "<certificate-profile-name>"

$path = "/subscriptions/$subId/resourceGroups/$rg/providers/Microsoft.CodeSigning/codeSigningAccounts/$account/certificateProfiles/$profile/revokeCertificates?api-version=2026-05-15-preview"

$body = @{
  revokeCertificates = @(
    @{
      serialNumber = "<serial-number>"
      thumbprint = "<thumbprint>"
      effectiveAt = "2026-05-15T00:00:00Z"
      reason = "KeyCompromised"
      remarks = "Revoked during preview API validation"
    }
  )
} | ConvertTo-Json -Depth 5

Invoke-AzRestMethod -Path $path -Method POST -Payload $body

このような検証を行う前に、Microsoft.CodeSigningリソースプロバイダーが登録されているかを確認してください。Artifact Signingのクイックスタートでは、利用前にMicrosoft.CodeSigningリソースプロバイダーを登録する手順が示されています。(Microsoft Learn)

az provider show --namespace Microsoft.CodeSigning \
  --query "registrationState"

未登録であれば、検証環境で登録します。

az provider register --namespace Microsoft.CodeSigning

移行前チェックリスト

2026-05-15-previewを使うかどうかを判断する前に、次の順序で確認すると失敗しにくくなります。

手順	確認内容	完了条件
現状把握	`Microsoft.CodeSigning`を使うコード・IaC・スクリプトを洗い出す	対象リポジトリと運用手順が一覧化されている
APIバージョン確認	既存の`api-version`を確認する	本番と検証で利用バージョンが分かる
失効処理確認	`revokeCertificate`を使っていないか確認する	新旧アクションの差分が把握できている
検証環境準備	検証用アカウントとCertificate Profileを用意する	本番証明書に影響しない構成になっている
Batch revocation検証	複数証明書、1件のみ、重複指定、失敗ケースを試す	監査ログとリトライ方針が決まっている
`programType`確認	値の出所と設定条件を確認する	推測値を使わない運用になっている
SDK影響確認	生成SDKや言語別パッケージの変更を確認する	CIでビルド・単体テストが通る
本番判断	プレビュー利用のリスクを承認する	ロールバック手順が用意されている

SDK利用者が注意すべき点

PRでは、Swagger、TypeSpecに加えて、Go、JavaScript、Python、Java向けのAPIViewが作成されていることも確認できます。これは言語別SDKへの影響確認が必要であることを示す材料です。ただし、APIViewに表示されたからといって、各SDKの正式リリースが完了したことを意味するわけではありません。(GitHub)

SDK利用者は、次の点を確認してください。

言語・利用形態	注意点
Python	`azure-mgmt-artifactsigning`などの生成SDKでメソッド名が変わる可能性
JavaScript/TypeScript	`@azure/arm-artifactsigning`のプレビュー対応状況を確認
Java	モデル名`RevokeCertificateList`やメソッド名変更の影響
Go	operation groupやメソッドシグネチャの差分
AutoRest自動生成	readmeのタグ指定を誤ると意図せずプレビュー仕様で生成される可能性

特に、既存コードにrevokeCertificateという単数形のメソッドやパスがある場合は要注意です。2026-05-15-previewでは複数形のrevokeCertificatesへ切り替わるため、メソッド名だけでなく、本文モデルも単一オブジェクトから配列を含むモデルへ変わります。

本番環境で避けたい失敗

今回の更新でありがちな失敗は、「プレビューAPIが追加されたので、とりあえず最新にする」という判断です。Azure REST APIでは、プレビューAPIに新機能が先行して入る一方、仕様変更やSDK生成の差分が発生することがあります。PR上でも破壊的変更レビュー関連のラベルが確認できるため、既存の安定運用をしている環境では慎重に扱うべきです。(GitHub)

避けたい失敗は次の通りです。

失敗パターン	何が起きるか	対策
本番の`api-version`を急にプレビューへ変更	既存メソッドやモデルが合わず失敗する	検証環境で差分テストを行う
`programType`に推測値を入れる	想定外のプロファイル扱いになる可能性	公式案内がある値だけを使う
失効対象を大きな配列で一括送信	失敗時の切り分けが難しい	小さな単位で送信し、証明書単位で記録する
204応答だけを見て監査しない	どの証明書をいつ失効したか追跡しにくい	送信前後に`serialNumber`と`thumbprint`を保存する
SDKリリース前に生成コードを混在させる	CIや型定義が不安定になる	SDK・Swagger・TypeSpecのバージョンを揃える

誰が対応すべきか

対応優先度が高いのは、Artifact Signingを単なるポータル操作ではなく、CI/CDや社内システムから管理しているチームです。特に、コード署名証明書の失効をセキュリティインシデント対応に組み込んでいる場合、Batch revocationは有用な変更になり得ます。

一方で、Azure portalだけでArtifact SigningアカウントやCertificate Profileを作成しており、REST APIやSDKを直接使っていない場合、現時点で大きな作業は不要です。ただし、将来の画面更新やSDK更新でprogramTypeのような新しい項目が見える可能性があるため、何の用途を示す項目なのかは把握しておくとよいでしょう。

まず取るべき行動

今回のAzure REST API更新に対して、最初にやるべきことは移行ではなく確認です。既存環境のapi-versionを棚卸しし、revokeCertificateを使っている箇所を探し、2026-05-15-previewを使う必要があるかを判断してください。

Batch revocationを使う価値がある場合は、検証環境でrevokeCertificatesのリクエスト本文、204応答、監査ログ、リトライ方法を確認します。programTypeについては、WESPなど明確な利用要件がある場合だけ設定し、推測値で本番プロファイルを作成しないことが重要です。

現時点で本番運用の基本方針は、既存の安定したapi-versionを維持しつつ、プレビューAPIの差分を検証環境で先に吸収することです。API仕様、SDK、Microsoft Learnの公開ドキュメントがそろった段階で、移行可否を判断しましょう。

この記事を書いた人

佐藤健司

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

Azure REST API更新まとめ：2026-05-15-preview追加でBatch revocationとprogramTypeは何が変わる？

今回のAzure REST API更新で押さえるべき結論

変更点の全体像

Batch revocationとは何が変わるのか

programTypeは何に使われるのか

api-versionを固定しているかを確認する

PowerShellで検証する場合の考え方

移行前チェックリスト

SDK利用者が注意すべき点

本番環境で避けたい失敗

誰が対応すべきか

まず取るべき行動

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

`programType`は何に使われるのか

`api-version`を固定しているかを確認する

コメントするコメントをキャンセル