Azure REST APIでKey Vaultを作成している環境では、今回の更新を「サンプル修正だから影響なし」と見ない方が安全です。結論から言うと、Key Vault作成時のリクエスト本文に enableSoftDelete: true を明示することが重要です。サービス側ではソフトデリートが既定で有効でも、Azure Policyがリクエスト本文を評価する環境では、プロパティが省略されているだけで RequestDisallowedByPolicy によって作成に失敗する可能性があります。(GitHub)
今回のAzure REST APIドキュメント更新は、既存のKey Vaultを自動変更するものではありません。主な影響は、Azure REST API、Azure管理SDK、ARM/Bicep/Terraform、CI/CDパイプラインなどで「新しいKey Vaultを作成する処理」を持っているチームです。なお、PRタイトルには enablePurgeProtection も含まれていますが、2026年5月5日時点の差分では enableSoftDelete の明示追加が中心で、enablePurgeProtection は後続検討として扱われています。(GitHub)
Azure REST APIのKey Vault作成例で何が変わったのか
Azure/azure-rest-api-specsのPR #42880では、Key Vaultの作成サンプルに enableSoftDelete: true を追加する変更が行われています。対象は createVault.json と createVaultWithNetworkAcls.json で、APIバージョン 2025-05-01、2026-02-01、2026-03-01-preview の例に同じ趣旨の変更が入っています。(GitHub)
変更の要点はシンプルです。
"enableSoftDelete": trueこの1行が、Key Vault作成時の properties に明示されるようになります。
| 確認項目 | 変更前 | 変更後 | 実務上の意味 |
|---|---|---|---|
enableSoftDelete | 作成例に含まれない場合がある | true を明示 | Azure Policyで必須チェックされても通りやすくなる |
enablePurgeProtection | PRタイトルには含まれる | 最新差分では追加されていない | 消去保護は別途、要件に応じて明示設定する |
| SDK生成サンプル | 例JSONを元に生成される | 再生成後に enableSoftDelete が反映される想定 | サンプルをコピーした利用者のポリシー違反を減らせる |
| 既存Key Vault | 変更なし | 変更なし | 既存リソースの設定が勝手に変わるわけではない |
ここで大切なのは、今回の更新が「Key Vaultサービスの既定値を変える更新」ではなく、「作成例のリクエスト本文に値を明示する更新」である点です。
なぜ enableSoftDelete を省略すると問題になるのか
Azure Key VaultのREST APIリファレンスでは、enableSoftDelete は新規作成時に未指定なら既定で true になり、一度 true になると false に戻せないプロパティとして説明されています。つまり、サービスだけを見れば「省略しても最終的には有効になる」と考えがちです。(Microsoft Learn)
しかし、PR #42880で問題として挙げられているのは、Azure Policyがサービス側の既定値適用前にリクエスト本文を評価するケースです。enableSoftDelete がJSONペイロードに存在しない場合、サービス側では後から true になる予定でも、ポリシー評価の段階では「必須プロパティがない」と判断される可能性があります。(GitHub)
流れとしては次のようになります。
| 段階 | 起きること |
|---|---|
| 1 | SDKサンプルやRESTリクエストで enableSoftDelete を省略する |
| 2 | クライアントから送信されるJSONにも enableSoftDelete が含まれない |
| 3 | Azure Policyがリクエスト本文を評価する |
| 4 | enableSoftDelete が存在しないため、ポリシー違反と判定される |
| 5 | Key Vault作成前に RequestDisallowedByPolicy で失敗する |
つまり、実務上の判断基準は「最終的に有効になるか」ではなく、「作成リクエストの本文に明示されているか」です。
影響を受けやすい環境
今回のAzure REST APIドキュメント更新で特に確認すべきなのは、Key Vaultを手動作成している人よりも、コードやテンプレートで繰り返し作成しているチームです。
| 対象 | 影響を受ける理由 | 対応の方向性 |
|---|---|---|
| Azure REST APIを直接呼び出す処理 | リクエスト本文を自前で組み立てている | properties.enableSoftDelete を明示する |
| Python / Java / JavaScript / TypeScript / Go / .NETのAzure管理SDK | 作成サンプルがspec例から生成される | SDKのサンプル更新を待たず、作成処理で明示設定する |
| ARMテンプレート / Bicep / Terraform | 「既定値で有効」と判断して省略しやすい | テンプレート側に enableSoftDelete: true を追加する |
| CI/CDパイプライン | ポリシー適用済みサブスクリプションで突然失敗する | デプロイ前にポリシーとリクエスト本文を確認する |
| Azure Policy管理者 | フィールドの存在を厳格に見るポリシーで失敗が出る | Deny条件と作成リクエストの整合性を確認する |
PRでは、5つのAzure管理SDKで作成サンプルがspecのexample JSONから生成されることが背景として説明されています。サンプルが更新されれば将来的な誤用は減りますが、現在運用中のコードが自動的に修正されるわけではありません。(GitHub)
まず確認すべき設定項目
Key Vault作成処理を見直すときは、enableSoftDelete だけでなく、関連する保護設定とAPIバージョンもまとめて確認すると手戻りを減らせます。
| 項目 | 確認すること | 注意点 |
|---|---|---|
enableSoftDelete | 作成リクエストに true が明示されているか | サービス既定値に頼らない |
softDeleteRetentionInDays | 保持期間を要件どおりにしているか | 7〜90日の範囲で、作成後に変更できない前提で設計する |
enablePurgeProtection | 本番・暗号化キー用途で有効化が必要か | 有効化は不可逆で、既定では有効ではない |
enableRbacAuthorization | Azure RBACを使うか、アクセスポリシーを使うか | APIバージョン 2026-02-01 以降では新規Vaultの既定アクセス制御に注意 |
| APIバージョン | 2026-02-01 以降へ移行済みか | 古いKey VaultコントロールプレーンAPIは2027年2月27日に廃止予定 |
Key Vaultのソフトデリートは、新しいキーコンテナー作成時に既定でオンになり、有効化後は無効化できません。保持期間は既定で90日、設定可能範囲は7〜90日です。消去保護は既定では有効ではなく、ソフトデリートが有効な場合にのみ有効化できます。(Microsoft Learn)
REST APIやIaCでの修正例
Azure REST APIやテンプレートでKey Vaultを作成している場合は、作成時の properties に enableSoftDelete を明示します。
以下は、注目すべきプロパティを抜き出した例です。実際のリクエストでは、利用するAPIバージョン、アクセス制御方式、ネットワーク設定、タグ、リージョンなどに合わせて必要項目を調整してください。
{
"location": "japaneast",
"properties": {
"tenantId": "<tenant-id>",
"sku": {
"family": "A",
"name": "standard"
},
"enableSoftDelete": true,
"softDeleteRetentionInDays": 90,
"enablePurgeProtection": true,
"enableRbacAuthorization": true
}
}enablePurgeProtection は、すべての環境で機械的に追加すればよい設定ではありません。消去保護を有効にすると、保持期間中は完全削除できなくなるため、検証環境や短命な環境では運用ルールと衝突することがあります。一方で、本番環境、カスタマーマネージドキー、ストレージ暗号化、監査要件がある環境では、消去保護を有効にする判断が強く求められます。Microsoft Learnでも、暗号化にキーを使う場合の消去保護が推奨され、Key Vaultと統合する多くのAzureサービスで必要になることが説明されています。(Microsoft Learn)
既存のKey Vaultで確認するコマンド例
既存のKey Vaultについては、まず現在の設定を確認します。Azure CLIを使う場合は、次のように az resource show でKey Vaultのプロパティを確認できます。
az resource show \
--resource-group <resource-group-name> \
--resource-type Microsoft.KeyVault/vaults \
--name <vault-name> \
--query "properties.{softDelete:enableSoftDelete,purgeProtection:enablePurgeProtection,retention:softDeleteRetentionInDays,rbac:enableRbacAuthorization}"PowerShellでは、環境やモジュールのバージョンによって表示プロパティが異なる場合がありますが、基本的には Get-AzKeyVault で確認します。
Get-AzKeyVault -VaultName <vault-name> |
Select-Object VaultName, EnableSoftDelete, EnablePurgeProtection, SoftDeleteRetentionInDays, EnableRbacAuthorization新規作成処理でエラーが出ている場合は、作成後の確認ではなく、実際に送信されるリクエスト本文を確認してください。今回の問題は「作成されたKey Vaultの最終状態」ではなく、「作成リクエストの時点でプロパティが存在するか」にあります。
enablePurgeProtection は今回の更新だけで有効になるのか
今回のトピック名には enablePurgeProtection が含まれていますが、2026年5月5日時点で確認できるPR差分では、最終的に enablePurgeProtection の追加は外され、enableSoftDelete の追加に絞られています。実際に「remove enablePurgeProtection, only add enableSoftDelete」というコミットがあり、ファイル差分でも追加されている行は enableSoftDelete: true です。(GitHub)
そのため、実務では次のように分けて判断するのが安全です。
| 設定 | 今回の更新で見るべきこと | 自社で判断すべきこと |
|---|---|---|
enableSoftDelete | 作成例に明示追加される | すべてのKey Vault作成処理で明示する |
enablePurgeProtection | 最新差分では追加対象外 | 本番・CMK・監査要件に応じて明示する |
softDeleteRetentionInDays | 直接の主題ではない | 保持期間を作成時に決める |
特に本番環境では、enableSoftDelete だけで満足せず、消去保護と保持期間をセットでレビューしてください。ソフトデリートは削除後の回復を可能にしますが、消去保護を有効にしない場合、権限を持つユーザーや処理による完全削除リスクは残ります。
APIバージョン 2026-02-01 以降への移行とあわせて見るべき点
今回の作成例更新は、Key Vault APIバージョン 2026-02-01 以降への移行とも関連して見ておくべきです。Microsoft Learnでは、2026-02-01 以降で新しいKey Vaultを作成する場合、既定のアクセス制御モデルがAzure RBACになること、既存Vaultは明示的に変更しない限り現在のアクセス制御モデルを維持することが説明されています。(Microsoft Learn)
また、2026-02-01 より前のKey VaultコントロールプレーンAPIバージョンは、2027年2月27日に廃止予定です。データプレーンAPIは対象外ですが、管理SDK、REST API呼び出し、ARM/Bicep/Terraformテンプレートを使ってKey Vaultを作成・更新している場合は移行計画が必要です。(Microsoft Learn)
このタイミングで見直すべきポイントは、次の3つです。
1つ目は、enableSoftDelete を明示しているかです。これは今回のPRの中心です。
2つ目は、enableRbacAuthorization の扱いです。アクセスポリシーを使い続ける環境では、APIバージョン変更によって意図せずAzure RBAC前提の作成になることを避ける必要があります。
3つ目は、SDKのバージョンです。Microsoft Learnでは、APIバージョン 2026-02-01 をサポートする5つのKey Vaultコントロールプレーン管理SDKがリリースされていることが案内されています。(Microsoft Learn)
Azure CLIとAzure PowerShell利用者の確認ポイント
今回のPRには、Azure CLIとAzure PowerShellの関連修正も言及されています。Azure CLIでは az keyvault create、Azure PowerShellでは New-AzKeyVault が、Azure Policyのチェックを満たすために enableSoftDelete / EnableSoftDelete をリクエスト本文へ明示する修正として扱われています。(GitHub)
ただし、CLIやPowerShellの修正PRがあるからといって、すべての環境がすぐに安全になるわけではありません。組織内で使っているAzure CLI、Az PowerShellモジュール、コンテナイメージ、DevOpsエージェントのバージョンが古いままだと、修正済みの挙動が反映されない可能性があります。
確認すべき場所は次のとおりです。
| 場所 | 確認内容 |
|---|---|
| 開発者PC | Azure CLI / Az PowerShellのバージョン |
| CI/CDエージェント | ビルドイメージ内のCLI・PowerShellモジュール |
| IaC実行基盤 | Terraform provider、Bicep CLI、Azure CLIの組み合わせ |
| 社内サンプルコード | 古い作成例をコピーしていないか |
| テスト環境 | Azure Policyが本番と同じ条件で適用されているか |
特に、CI/CDだけが失敗する場合は、ローカル環境とパイプライン環境でツールバージョンやポリシー適用スコープが違うことがあります。
よくある失敗パターン
今回の変更で避けたい失敗は、単に enableSoftDelete を書き忘れることだけではありません。Key Vaultはセキュリティ、アクセス制御、削除保護が絡むため、周辺設定の見落としが障害につながります。
| 失敗パターン | 起きる問題 | 回避策 |
|---|---|---|
| 「既定でtrueだから省略」で済ませる | Azure Policyで作成前に拒否される | 作成リクエストに enableSoftDelete: true を明示する |
PRタイトルだけを見て enablePurgeProtection も反映済みと思い込む | 消去保護が有効にならない | 実際の差分と作成後設定を確認する |
| 検証環境で消去保護を無計画に有効化する | リソース名再利用や削除運用で困る | 保持期間と削除運用を先に決める |
| APIバージョンだけ更新する | アクセス制御モデルが想定とずれる | enableRbacAuthorization を明示的に設計する |
| SDKサンプルの更新を待つ | 既存の自動デプロイが失敗し続ける | 現行コードに明示設定を入れる |
| 作成後の状態だけ確認する | ポリシー拒否の原因を見逃す | 実際の送信JSONをログやデバッグで確認する |
対応手順：まず何を直すべきか
実務では、次の順番で確認すると効率的です。
Key Vault作成箇所を洗い出す
まず、コードリポジトリやIaCテンプレートからKey Vault作成処理を探します。検索キーワードは次のようなものが有効です。
Microsoft.KeyVault/vaults
createVault
keyvault create
New-AzKeyVault
enableSoftDelete
enablePurgeProtection
softDeleteRetentionInDaysenableSoftDelete が見つからない作成処理は、今回の確認対象です。
作成リクエストに enableSoftDelete: true を追加する
REST API、ARMテンプレート、Bicep、Terraform、SDKのいずれであっても、最終的な作成リクエストに enableSoftDelete が含まれるようにします。
ポイントは、SDKの内部既定値やサービス側の既定値に頼らないことです。Azure Policyがリクエスト本文を評価する環境では、「結果としてtrueになる」では不十分な場合があります。
消去保護を有効にするか決める
本番環境では、enablePurgeProtection も合わせて検討します。特に、Key Vault内のキーをストレージ、SQL、ディスク暗号化、アプリケーションの重要シークレット保護に使っている場合は、消去保護を有効にする価値が高くなります。
一方、短命な検証環境では、保持期間中に完全削除できないことが運用上の負担になる場合があります。環境ごとにポリシーを分けるか、本番相当環境では必須、サンドボックスでは別管理にするなどの設計が必要です。
Azure PolicyのDeny条件を確認する
RequestDisallowedByPolicy が出ている場合は、エラーメッセージに含まれるポリシー割り当て名やポリシー定義を確認します。Microsoft Learnでも、RequestDisallowedByPolicy ではエラーコード、ポリシー割り当て、ポリシー定義が主要な確認要素になると説明されています。(Microsoft Learn)
ポリシー側で見るべき点は、enableSoftDelete の値だけを見ているのか、プロパティの存在まで要求しているのかです。後者の場合、サービス側の既定値では回避できません。
APIバージョンとアクセス制御を同時に見直す
2026-02-01 以降へ移行する場合は、enableSoftDelete だけでなく enableRbacAuthorization も確認します。新しいKey Vaultをアクセスポリシー方式で作成したい場合は、enableRbacAuthorization を明示的に false にする必要があります。(Microsoft Learn)
変更対応のチェックリスト
公開前、またはCI/CDへ反映する前に、次のチェックを済ませてください。
- Key Vault作成リクエストに
enableSoftDelete: trueが含まれている - 本番環境で
enablePurgeProtectionを有効にするか判断済み softDeleteRetentionInDaysの保持期間が要件に合っている- Azure PolicyのDeny条件と作成リクエストが整合している
- APIバージョン
2026-02-01以降への移行方針が決まっている - アクセス制御方式としてAzure RBACを使うか、アクセスポリシーを使うか決まっている
- SDK、Azure CLI、Az PowerShell、CI/CDエージェントのバージョンを確認した
- 作成後のプロパティだけでなく、送信されるJSON本文も確認した
まとめ：次に取るべき行動
今回のAzure REST APIドキュメント更新で最も重要なのは、Key Vault作成時に enableSoftDelete: true を明示することです。サービス側の既定値では有効になる設定でも、Azure Policyがリクエスト本文を評価する環境では、省略がそのままデプロイ失敗につながる可能性があります。
まずは、REST API、SDK、IaC、CI/CDのKey Vault作成処理を検索し、enableSoftDelete がリクエスト本文に含まれているか確認してください。そのうえで、本番環境では enablePurgeProtection と保持期間、APIバージョン 2026-02-01 以降のアクセス制御モデルも合わせて見直すのが安全です。
PRや生成サンプルの反映状況は変わる可能性があるため、実装前にはazure-rest-api-specsの該当PRと最新のMicrosoft Learnを確認し、自社のポリシー条件に合わせて明示設定することが実務上の最短ルートです。
コメント