自動是正は「何を自動にするか」で9割決まる

山崎行政書士事務所
6 時間前
読了時間: 6分

〜情シス向け：Azure運用の“自動是正対象”をA〜Dで分類して、事故らないルールに落とす〜

※本記事は一般的な情報提供であり、個別案件の法的助言ではありません。※当事務所（行政書士）は、規程・台帳・運用設計・証跡整備など「ガバナンスの型づくり」を中心に支援します（個別紛争・訴訟等は弁護士領域です）。

1. 情シスの現実：自動化は“正しく怖がらないと”事故装置になる

Azureの自動是正（Azure Policyの修復、Runbook、Functions等）は、運用の属人化と棚卸し地獄を終わらせる強い武器です。一方で、やり方を誤ると「全社スケールの設定変更」を一瞬で走らせる、最大級の事故リスクにもなります。

だからこそ、Microsoftが推奨する 安全なデプロイプラクティス（SDP） の考え方（段階ロールアウト、影響の早期検出、影響範囲の制限）を、Policy含む運用に取り込むのが前提です。

結論から言うと、情シス運用で一番効くのはこれです。

自動是正の対象は、最初にA〜Dに分類して“許可範囲”を固定する。そして、クラスごとに「安全装置（Dry-run／影響上限／承認／ロールバック）」を義務化する。

2. 前提：自動是正に必須の「安全装置」4点セット

分類の前に、最低限この4点を仕組みに入れます（入ってない自動化は“禁止”扱いにするのが安定します）。

(1) Dry-run（事前差分を出す）

ARMテンプレートの What-If は「デプロイしたら何が変わるか」をプレビューでき、既存リソースは変更しない、と明記されています。
Bicepでも同様にWhat-Ifで変更予測ができ、既存リソースに変更を加えないと説明されています。

(2) 影響上限（爆風半径の制限）

Azure Policyの修復タスクには resourceCount（対象件数）、parallelDeployments（並列数）、failureThreshold（失敗率で止める）などがあり、範囲・速度を制御できます。

(3) 承認フロー（Human-in-the-loop）

Azure DevOpsの承認チェックは、ステージを実行するタイミングを手動で制御するための仕組みとして整理されています（運用環境へのデプロイ制御に一般的）。

(4) ロールバック（止血→復元）

Azure Automation Runbookは「中断された場合、先頭から再開される」と明記されています。つまり、冪等設計（何回走っても同じ結果）や復元手順が必須です。
さらにPolicyの修復は、CLIで cancel が用意されています（止血の道具）。

3. 本題：自動是正対象のA〜D分類（情シス運用ルールの型）

ここからが運用ルールの核です。“迷ったら厳しめ（C/D寄り）”が正解です。あとで緩めるのは簡単ですが、事故の後に締めるのは地獄です。

Class A：自動OK（低リスク・可逆・追加/整形中心）

定義

“誤っても致命傷になりにくい”
変更の爆風半径が小さい（スコープ・対象を絞れる）
戻しやすい（逆操作が明確）

代表例（情シスで一番効果が出る）

タグ補完／タグ標準化（costCenter、owner、env 等）
- Azure Policyの modify 効果は、プロパティ/タグを「追加・更新・削除」でき、既存非準拠も修復タスクで直せる、と明記されています。
- タグガバナンスをPolicyで回すチュートリアルも公開されています。

必須の安全装置（Aでも省略不可）

Dry-runログ（対象一覧・予定変更・件数）
自動化ID（マネージドID等）の最小権限
- Azure Automationのセキュリティベストプラクティスでも、最小特権や広範スコープ付与の回避が前提として整理されています。

Class B：自動OK（ただし影響上限つき）

定義

自動化して良いが、“速度”と“範囲”を必ず縛る
一度に全量修復しない（小さく刻んで回す）

代表例

低〜中リスクの構成是正（例：タグの欠落修復を定期で回す、軽微な標準化）
「ルール違反を直す」より、「ルールに寄せる」方向の作業

実装のポイント

Policy修復タスクの resourceCount / parallelDeployments / failureThreshold を小さく設計する（最初は遅く、少なく）。
段階展開（スコープを小さく→広く）
- 新しいポリシーは既存リソースの“限られたサブセット”で評価し、Dev環境で doNotEnforce を使って効果をトリガーしない形でテストできる、と説明されています。
- さらに、Azure Policy割り当てにSDPを適用して段階ロールアウトする方法もチュートリアル化されています。

Class C：承認必須（Change扱い＝証跡必須）

定義

正しいことをしていても「業務影響」「コスト影響」「情報管理（監査）」の説明責任が重い
自動化はするが、実行前に承認ゲートを通す

代表例（情シスが“揉めやすい”領域）

診断設定（ログ転送）の大規模適用
- 診断設定用の組み込みポリシー／イニシアチブで、大規模に診断設定を適用する考え方が整理されています。
- 便利＝一気に全体へ届くので、承認と証跡がないと「なぜログ量が増えた？コストは？誰が決めた？」で確実に詰まります。
ポリシーの“強制開始”（DoNotEnforce→Defaultへの切り替え）
- enforcementMode の考え方（Default / DoNotEnforce）が整理されています。

Cの王道フロー（情シス向け）

Dry-run：What-If（IaC）／DoNotEnforce（Policy）
影響上限：スコープと段階ロールアウト、修復タスクは少数・低並列
承認：DevOpsの承認チェック（承認者・期限・指示を明記）
実行：RunbookやPipelineで実行
証跡：差分（What-If）＋承認ログ＋実行ログ＋結果確認

Class D：原則禁止（自動是正しない＝検知と通知まで）

定義

誤ったときの被害が大きすぎる
戻すのに時間がかかる／二次被害が出る
“止める”より“事故が起きない”が重要

代表例

ネットワーク境界・経路（公開設定、NSG/UDR/Firewall等）
RBACの特権付与/剥奪（オーナー/共同作成者相当）
削除・破壊的変更（クリーンアップ系）

Dで自動化するなら

自動は「検知→通知（→可能なら隔離）」まで
“是正実行”は二人承認＋手動Changeで実施

4. 例外の扱い：例外を放置すると、統制は必ず崩壊する

分類を決めても、現場は必ず例外を求めます。問題は「例外そのもの」ではなく、期限・理由・代替統制がない例外です。

Azure Policyの適用除外（Exemption）は、expiresOn で期限を持てること、期限を迎えてもオブジェクトは削除されず“記録保持のため維持され、適用除外は無効となる”ことが明記されています。

情シス運用ルールとして、例外は必ず次をセットで台帳化してください。

期限（expiresOn）
理由（技術制約、移行期間、業務要件）
代替統制（軽減策）
次回レビュー日

（これがあるだけで監査・引継ぎが激変します）

5. “仕組み”として回す実装パターン（事故らない自動化ライン）

分類を作ったら、次はライン化です。

監視→起動→承認→実行の王道

Azure Monitorのアクショングループは、メールだけでなく Webhook、Azure 関数 などの通知/アクションを有効化できると説明されています。
Azure Automationは Webhook 1本でRunbookを起動できます（外部サービスからHTTP要求で開始）。
Runbookは入力パラメーターで、対象や条件を柔軟に制御できます。

これを組み合わせると、情シスが欲しい「自動化＋統制」が作れます。