Bicep What-ifとDeployment Stacksで“消える変更”を防ぐ
- 山崎行政書士事務所
- 7月8日
- 読了時間: 9分
IaCの変更前レビューと承認証跡を標準化する
確認日：2026年7月8日前提：個別テナントの実設定、既存パイプライン、RBAC設計、運用規程は確認できません。以下はMicrosoft公式情報に基づく標準設計案です。
結論
BicepによるAzure IaC運用では、「What-ifで変更前に差分を見る」だけでは不十分です。本番運用では、Bicep What-if、Deployment Stacks、Azure DevOps承認、Activity Log、デプロイ履歴を組み合わせて、変更前レビューと承認証跡を標準化すべきです。
理由は、IaCは便利である一方、テンプレート変更、パラメーター誤り、Complete mode、Deployment Stacksのaction-on-unmanage設定、手動変更との差分によって、意図しない変更・削除・説明不能な状態が起きるためです。
数字で見ると、最低限押さえるべき管理点は7つです。1. What-if結果、2. Delete/Modify判定、3. action-on-unmanage、4. deny-settings-mode、5. 承認者、6. デプロイ履歴、7. Activity Log保全です。
公式情報で確認できた事実
Microsoft LearnのBicep What-ifは、Bicepファイルをデプロイする前に、リソースにどのような変更が発生するかを予測する機能です。What-if自体は既存リソースを変更せず、Resource Group、Subscription、Management Group、Tenantスコープで利用できます。公式ページの最終更新日は2026年3月3日です。
Deployment Stacksは、Azureリソースのグループを一体として管理するAzureリソースです。BicepまたはARMテンプレートで管理対象リソースを定義し、テンプレートから外れたリソースをactionOnUnmanageの動作によりデタッチまたは削除できます。公式ページの最終更新日は2026年6月18日です。
Azure Resource Managerのデプロイモードでは、Incremental modeが推奨されています。BicepまたはARM JSONテンプレートの一部としてリソース削除が必要な場合は、Deployment Stacksを使うことがMicrosoft公式で示されています。
Azure CLIのaz stack group createでは、--action-on-unmanageにdeleteAll、deleteResources、detachAllを指定でき、--deny-settings-modeにdenyDelete、denyWriteAndDelete、noneを指定できます。az stack groupのコマンドはCore GAとして記載されています。
Azure DevOpsのApprovals and checksは、YAMLファイル内ではなくAzure PipelinesのWeb UI側で管理されます。そのため、パイプラインYAMLを編集できる人が、承認チェックそのものをYAML変更だけで消すことはできません。公式ページの最終更新日は2025年11月13日です。
Azure Activity Logは、Azureリソースの作成、更新、削除などの管理操作を記録します。Activity Logは既定で90日間保持され、長期保全するには診断設定でLog Analytics Workspace等へ送る必要があります。公式ページの最終更新日は2026年5月20日です。
なぜIaCで「消える変更」が怖いのか
IaCの怖さは、コマンドそのものではありません。怖いのは、人間が変更の意味を見落としたまま、自動化だけが正確に実行されることです。
たとえば、Bicepファイルからサブネット定義を1つ消した場合、レビュー画面では単なる数行の削除に見えます。しかし実環境では、そのサブネットにPrivate Endpoint、NSG、Route Table、App Service VNet Integration、Application GatewayのBackend、監視設定が関係していることがあります。レビューで見るべきなのは「Bicepの差分」だけではなく、「Azure上で何が変わるか」です。
What-ifは、この差を埋めるための入口です。ただし、What-ifには限界もあります。Microsoft公式では、What-ifは一部のプロパティを誤って削除と表示することがあり、これは“noise”として説明されています。また、reference()関数、listKeys()、utcNow()など、デプロイ実行時でないと評価できない式もあります。
つまり、What-ifは「自動承認ツール」ではありません。正しくは、人間が見るべき変更点を機械的に抽出するレビュー材料です。
What-ifで見るべき変更タイプ
Bicep What-ifでは、変更タイプとしてCreate、Delete、Ignore、NoChange、NoEffect、Modify、Deployなどが示されます。公式説明では、DeleteはComplete modeで、既存リソースがテンプレートに存在しない場合などに関係します。一方、Ignoreは既存リソースがテンプレートに存在しないが、デプロイや変更の対象ではない状態として説明されています。
実務では、次のように判定します。
What-if表示 | 実務上の扱い |
Create | 新規作成。名前、SKU、リージョン、タグ、診断設定、Private Endpoint有無を確認 |
Modify | 最重要。ネットワーク、ID、認証、暗号化、診断ログ、削除保護の変更を重点確認 |
Delete | 原則停止。削除理由、復旧手段、影響範囲、承認者を確認 |
Ignore | IaC管理外の既存リソース。ドリフト、手動作成、移行途中の可能性を確認 |
NoChange | 証跡上は安全材料。ただしレビュー対象外にしすぎない |
Deploy | 詳細差分が不明な可能性。自動承認せず手動確認 |
NoEffect | サービス側で無視される変更。なぜ無視されるかを記録 |
本番環境では、特にDelete、Modify、Deployを自動承認しない設計が重要です。
Deployment Stacksで「削除の扱い」を明示する
Deployment Stacksを使う最大の意味は、リソースのライフサイクルを明示できることです。テンプレートから外れたリソースをどう扱うかをaction-on-unmanageで指定します。
実務上の基本方針は次の通りです。
環境 | 推奨方針 | 理由 |
開発環境 | deleteResourcesも選択肢 | 検証環境の作り直し・クリーンアップを優先できる |
検証環境 | 原則detachAll、必要時のみdeleteResources | 誤削除を防ぎながら、削除テストは個別承認 |
本番環境 | 原則detachAll | テンプレートから外れただけで削除しない |
一時環境 | deleteAllも選択肢 | リソースグループごと消す前提の短期環境に限定 |
deleteAllは、管理対象リソースだけでなくリソースグループにも削除動作が及ぶ可能性があるため、恒久的な本番環境では通常運用に入れるべきではありません。Azure CLIの公式説明でも、deleteAll、deleteResources、detachAllは明示的に選択する値として示されています。
deny-settings-modeで「勝手な削除」を止める
Deployment Stacksでは、管理対象リソースに対して拒否設定を使えます。公式説明では、deny-settings-modeは、未承認のセキュリティプリンシパルによる削除または更新の試行から管理対象リソースを保護するための設定で、none、denyDelete、denyWriteAndDeleteがあります。
実務では、次の設計が現実的です。
設定 | 使いどころ |
none | 開発環境、検証初期、頻繁に作り直す環境 |
denyDelete | 本番の標準候補。誤削除を止めつつ、通常の更新余地を残す |
denyWriteAndDelete | 重要基盤向け。ただし通常運用・パッチ・子リソース追加を妨げる可能性があるため慎重に使う |
本番の第一候補は、私はdenyDeleteだと考えます。理由は、IaC運用では変更を完全に止めるよりも、削除を強く止め、変更はレビューと承認で制御する方が現場運用に合いやすいからです。
ただし、denyWriteAndDeleteを使うべき場面もあります。たとえば、監査ログ保管用のStorage Account、基幹ネットワークのHub VNet、共有Key Vault、重要なPrivate DNS Zoneなど、変更頻度が低く、破壊影響が大きいリソースです。
標準フロー：変更前レビューから承認証跡まで
実務で使うなら、次の流れにします。
Bicep変更
↓
Pull Request作成
↓
bicep build / validate
↓
What-if実行
↓
What-if結果をJSONとMarkdownで保存
↓
Delete / Modify / Deployをレビュー
↓
Azure DevOps Environment Approval
↓
Deployment Stackでデプロイ
↓
Deployment History / Activity Log / PR / 承認記録を保全ポイントは、What-ifを見た人、承認した人、実行したパイプライン、実際にAzureで起きた操作をつなげることです。
Azure DevOps Environmentsは、デプロイ対象環境としてDev、Test、QA、Staging、Productionなどの論理ターゲットを表現でき、デプロイ履歴、コミットや作業項目のトレーサビリティ、セキュリティ管理に利用できます。公式ページの最終更新日は2026年6月17日です。
コマンド例：What-ifを証跡として保存する
以下は、リソースグループスコープの例です。
mkdir -p artifacts
az deployment group what-if \
--name "whatif-prod-app-20260708-001" \
--resource-group "rg-prod-app" \
--template-file "infra/main.bicep" \
--parameters "@infra/parameters/prod.parameters.json" \
--result-format FullResourcePayloads \
--validation-level Provider \
--no-pretty-print \
--output json \
> "artifacts/what-if.prod.20260708-001.json"--result-format FullResourcePayloadsは、変更されるリソースとプロパティ詳細を確認するために使います。ResourceIdOnlyは軽量ですが、本番変更レビューでは情報が足りません。What-ifの結果形式としてFullResourcePayloadsとResourceIdOnlyが公式に示されています。
コマンド例：本番ではdetachAllを基本にする
本番環境で、テンプレートから外れたリソースを即削除しない設計にする例です。
az stack group validate \
--name "stack-prod-app" \
--resource-group "rg-prod-app" \
--template-file "infra/main.bicep" \
--parameters "@infra/parameters/prod.parameters.json" \
--action-on-unmanage detachAll \
--deny-settings-mode denyDelete \
--validation-level Provider承認後に実行します。
az stack group create \
--name "stack-prod-app" \
--resource-group "rg-prod-app" \
--template-file "infra/main.bicep" \
--parameters "@infra/parameters/prod.parameters.json" \
--action-on-unmanage detachAll \
--deny-settings-mode denyDelete \
--description "CHG-20260708-001 commit:abc123 approved-by:infra-manager"この設計では、Bicepからリソース定義が消えても、即削除ではなくスタック管理から外す方向になります。削除が必要な場合は、別の変更申請としてdeleteResourcesを使う、または個別削除手順を用意します。
削除を許可する場合のレビュー条件
削除を許可する場合は、最低限、次の情報を残します。
項目 | 確認内容 |
削除対象 | リソースID、リソース名、種類、リソースグループ |
削除理由 | 廃止、移行完了、重複、誤作成、コスト削減など |
影響範囲 | 接続先、Private Endpoint、DNS、監視、バックアップ、依存アプリ |
復旧方法 | 再デプロイ、バックアップ、スナップショット、再作成手順 |
承認者 | 情シス責任者、アプリ責任者、セキュリティ責任者など |
証跡 | PR、What-if結果、承認コメント、デプロイ履歴、Activity Log |
ここを曖昧にすると、あとで「なぜ消えたのか」「誰が承認したのか」「戻せるのか」が説明できません。IaCの事故は、技術事故であると同時に、変更管理事故でもあります。
証跡として残すべきもの
本番IaCでは、最低限この7点を残します。
証跡 | 目的 |
PR URL | 変更内容とレビューコメントを残す |
Commit SHA | どのコードを実行したか固定する |
What-if JSON | Azure上で予測された変更を残す |
What-if要約Markdown | 承認者が読める形にする |
承認ログ | 誰が、いつ、何を承認したか残す |
Deployment History | ARMデプロイの結果と相関IDを確認する |
Activity Log | 実際の管理操作、実行主体、失敗・成功を監査する |
Azure Resource Managerのデプロイ履歴では、過去のデプロイ操作や、どのリソースがデプロイされたかを確認できます。ただし、リソースグループのデプロイ履歴は800件に制限されます。公式ページの最終更新日は2026年6月26日です。
Activity Logは管理操作の監査に有効ですが、既定保持は90日です。監査・契約・内部統制の説明に使うなら、Log Analytics WorkspaceやStorageへのエクスポートを前提にすべきです。
見落としやすい制限
Deployment Stacksにも限界があります。公式の既知の問題では、暗黙的に作成されたリソースはDeployment Stacksが管理しないこと、Key Vault secretsを削除できないこと、リソースグループ削除はdeny assignmentsを回避し得ることが示されています。
したがって、Deployment Stacksを入れればすべて安全、とは言えません。特に、次のリソースは別途確認が必要です。
Key Vault secrets
サービスが暗黙的に作成する子リソース
Private Endpointに紐づくNIC
Managed Identity
Diagnostic Settings
Role Assignment
Private DNS Zone link
Policy Assignment
Lock
手動作成された運用補助リソース
本番運用では、What-if結果だけでなく、Azure Resource Graph、Activity Log、既存設計書、監視設定も合わせて確認する必要があります。
山崎行政書士事務所としての支援観点
山崎行政書士事務所が支援できる価値は、単にBicepを書くことではありません。Azureの設計・構築・運用に加えて、変更管理、承認証跡、規程、契約関連資料、監査説明資料まで一体で整理できる点にあります。
情シス担当者にとって重要なのは、「この設定は正しいです」だけではなく、「この変更は、誰が、何を見て、どのリスクを承認して、本番に反映しました」と説明できることです。
行政書士業務の範囲では、社内規程、運用ルール、説明資料、契約関連資料、監査対応資料の整備を支援できます。個別紛争対応や訴訟代理など弁護士領域に属する事項は切り分けたうえで、Azure技術支援とクラウド法務・ガバナンス整備をつなぎます。
まとめ
Bicep What-ifは、変更前にAzure上の差分を確認するための強力な入口です。Deployment Stacksは、リソース群のライフサイクルを管理し、テンプレートから外れたリソースの扱いを明示できます。Azure DevOpsのApprovals and checksは、YAML外で承認を管理できるため、本番反映の統制に向いています。Activity LogとDeployment Historyは、後から説明するための証跡になります。
IaCは、速く作るためだけの仕組みではありません。安全に変え、不要な削除を防ぎ、監査と経営層に説明できる状態を作るための仕組みです。
Azure環境のBicep化、Deployment Stacks設計、What-ifレビュー標準化、承認証跡・監査説明資料の整備は、山崎行政書士事務所へご相談ください。
コメント