Azure自動化で“運用の提出物”を作る
- 山崎行政書士事務所
- 7 時間前
- 読了時間: 6分
〜棚卸し・逸脱検知・是正を、手作業から「仕組み」に変える〜
静岡鉄道の全駅パネルを“小沼みのりさん起用”のデザインに刷新しました。駅で見かけた情シスの方にこそ伝えたいのが、「クラウド運用は、人力だと必ず破綻する。でも Azureなら“自動化の型”で勝てる」という話です。
今回は、Azure自動化（Automation/Policy/Monitor/Logic Apps等）にスポットを当てて、情シスの運用が“監査でも説明できる状態”になるための実務パターンをまとめます。
1. 情シスがAzure運用で詰まるポイントは「設定」ではなく「継続運用」
Azureは、設計・構築の段階では綺麗に揃います。崩れるのは運用開始後です。
よくある“崩れ方”
いつの間にか 診断ログが取れていないリソースが混ざる
タグが揃わず、原価配賦／予算管理が崩壊する
“例外”が積み上がり、誰が何を許可したか説明できない
手作業の棚卸しが属人化し、担当交代で停止する
これを人力でやると、どこかで必ず漏れます。なので発想を変えます。
運用の基本サイクルを「仕組み化」する
棚卸し（Inventory）
逸脱検知（Detect）
自動是正（Remediate）
証跡化（Evidence）
2. Azure自動化の“王道アーキテクチャ”はこれ
情シスで一番再現性が高い構成は、次の組み合わせです。
[Azure Resource Graph] …棚卸し（全体の現状把握） ↓[Azure Policy] …ガードレール（守らせる） ↓（非準拠が出たら）[Remediation Task] …自動修復（deployIfNotExists / modify） ↓（それでも失敗/例外なら）[Azure Monitor Alerts] …逸脱検知（ログ/メトリック） ↓[Action Group] …通知＋自動アクション ↓[Azure Automation / Logic Apps / Functions] …是正＆チケット化 ↓[Log Analytics / Storage] …証跡（監査提出できる形）それぞれ根拠（Microsoft公式）
Azure Automation：PowerShell / Python / グラフィカルのRunbookでプロセス自動化。Webhookで起動でき、Logic AppsやFunctions、ITSM、監視システムからトリガー可能。さらにHybrid Runbook Workerでオンプレ/他クラウド側でも実行可能。
Azure Monitor：アラートにアクション グループを付け、WebhookやAzure Functionsトリガー等の自動アクションが可能。
Azure Policy：deployIfNotExists や modify と修復タスクで、非準拠リソースを準拠へ寄せられる。
Resource Graph：大規模なリソース棚卸しを高速にクエリできる。
3. 「Azure Automation / Logic Apps / Functions / Event Grid」使い分け（情シスの現実解）
自動化は“道具の使い分け”で詰みます。ざっくり、この方針が外しにくいです。
Azure Automation（Runbook）に寄せるべきとき
Azure運用の定型作業（棚卸し、権限・タグ・ロック・設定の是正、レポート生成）
PowerShell/Pythonで 運用手順をコード化 したい
監視→復旧など、運用ワークフローが長い
RunbookはPowerShell/Python/グラフィカル等があり、Pythonは3.10が推奨という整理も明記されています。
Logic Appsに寄せるべきとき
SaaS連携（ServiceNow、Teams、メール、各種コネクタ）を 最小コードで繋ぐ
“承認”や“通知”を含む業務ワークフロー
Logic Appsはワークフローを視覚的に作成でき、ワークフロー形態（従量/Standard等）も選択できる説明があります。
Azure Functionsに寄せるべきとき
軽量なコードでイベント駆動の処理を作りたい（Webhook受け口、変換、判定ロジックなど）
アプリ寄りの実装（CI/CDやテストも含めて）
Functionsはサーバーレスで、少ないコードで堅牢なアプリを構築できる概要が整理されています。
Event Gridに寄せるべきとき
「何かが起きた」を起点に、複数の処理へイベント配布したい（pub/sub）
Event Gridはフルマネージドの発行/サブスクライブで、イベント駆動アーキテクチャに向く説明です。
結論：“是正そのもの”はAutomation（Runbook）、“チケット化や承認フロー”はLogic Apps、“入口の軽い処理”はFunctions、“イベント配布”はEvent Gridが、情シス運用として再現性が高いです。
4. 実務で効くAzure自動化パターン4選（そのまま設計に落とせます）
パターンA：診断設定（ログ転送）を「ポリシーで標準化」して、証跡を自動生成する
ISMS/監査でまず聞かれるのが「ログは取ってる？いつから？例外は？」です。ここを人力運用すると、必ず漏れます。
Microsoft公式でも、Azure Policyを使って 診断設定（リソースログ）を大規模に有効化し、Log Analytics/イベントハブ/ストレージへ転送する方法が整理されています。
これをやると、次が一気に揃います。
ログ取得の“標準”が定まる
例外は「例外として見える」
監査時に「証跡の保存先」が固定できる
パターンB：Azure Policyの修復タスクで「放置しても戻る」基盤にする
ポリシーは“縛る”だけだと、非準拠が溜まります。情シスが疲弊します。そこで 修復タスク（Remediation task） を前提にします。
deployIfNotExists / modify の割り当てに準拠していない既存リソースを、修復タスクで準拠させる構造が説明されています。
修復タスクは割り当てで指定したID（マネージドID）で実行され、必要最小限のRBACが必要です。
さらに、修復タスク リソースは「最後の変更から60日経過で削除される」注意も書かれています（運用設計に影響します）。
情シスの運用ポイント修復タスクを「回しっぱなし」にするのではなく、 非準拠の検知 → 修復 → 失敗時はチケット化までをセットにして、“例外”を台帳に落とすと綺麗に回ります。
パターンC：Azure Monitor × アクショングループで「逸脱検知→自動是正」のラインを作る
Azure Monitorのアクション グループは、通知だけでなく Webhook や Azure 関数のトリガー等の自動アクションを持てます。 ログ検索アラート ルール（Log alert rule）も、ルール作成と動きが整理されています。
ここから先は、情シス運用として次の定石が強いです。
Sev0/1（重大）：自動是正は慎重に（まず隔離・停止・通知→承認）
Sev2/3（中軽度）：自動是正を前提に（タグ補完、診断設定適用、不要公開の削除など）
すべて Log Analytics/Storageに証跡を残す（後で説明できる）
パターンD：予算（Cost Management）イベントをトリガーに“自動抑止”
「月末に請求が爆発してから気づく」——これ、情シスあるあるです。Microsoft公式でも、予算しきい値到達時に Azure Monitor のアクション グループを使えることが整理されています。
例：開発サブスクリプション
80%到達：Teams通知（Logic Apps）
100%到達：夜間の非本番VMを停止（Automation/Functions）
110%到達：緊急チケット＋一部制限（承認フロー）
5. 2026年のAzure Automationで“絶対に外さない”要点（情シス必修）
5-1. Run Asアカウントは前提にしない（マネージドIDへ）
Azure Automation 実行アカウント（Run As）は 2023年9月30日に廃止され、マネージドIDに置き換えと明記されています。 これから設計するなら、最初から Managed Identity前提が安全です。
AutomationアカウントのマネージドID設定手順も公式に整理されています。
RunbookからマネージドIDでAzureリソース操作するチュートリアルもあります。
5-2. “最小権限”で動く設計にする（自動化ほど事故が大きい）
Azure Automationは、環境ごとに必要最小限の権限で安全にアクセスする必要がある、というセキュリティ観点の整理があります。 情シスでは、RunbookのID（MI）に与えるRBACを「役割の棚卸し対象」にしてください。
5-3. Hybrid Runbook Workerは“オンプレ運用の橋”として有効
オンプレADやファイルサーバ等をまだ抱えている事業会社では、Hybrid Runbook Workerが現実解になるケースがあります。Hybrid Runbook Workerの概要は公式に整理されています。
5-4. Runbook起動はWebhook化すると運用連携が爆速になる
WebhookでHTTP POSTからRunbookを開始する手順と、Webhookプロパティ（URL等）が公式に整理されています。 “監視→是正”だけでなく、“申請→承認→実行”の入口にも使えます。
6. 自動化を「監査で説明できる形」にする提出物（情シスの勝ちパターン）
自動化は、入れた瞬間から“統制対象”です。情シスが困るのは、自動化が増えたのに台帳がない状態。
最低限、次の提出物を持つと運用が安定します。
自動化台帳（Runbook/Logic Apps/Functions）：目的、トリガー、権限、影響範囲、Owner
変更記録（Change Record）：いつ、誰が、何を変えたか。承認は？
監視マップ（Alert → Action）：どのアラートが何を起動するか
証跡インデックス（Evidence Index）：ログの保存先、保持期間、提出時の説明ポイント
月次棚卸し（Monthly Review）：逸脱と是正のSLA
参考リンク（Microsoft公式）
# Azure Automation
# Azure Monitor / Alerts / Action Group
# Azure Policy / Remediation
# Diagnostic Settings at scale (Policy)
# Azure Resource Graph
# Cost Management
# Logic Apps / Functions / Event Grid
# Update Manager（パッチ運用を自動化したい場合）
コメント