Azure AutomationでRunbookを書いてスケジュール実行できるようになった——そこまで来ると、次に必ずぶつかる壁があります。「このRunbookでAzure上のVMは止められた。でも、社内のオンプレサーバーは？」「そもそもサーバーの設定が誰かに勝手に変えられていないか、どうやって見張るの？」「毎月のWindows Updateを手作業で当てるの、いい加減つらい」。基本のRunbook実行だけでは届かない、運用の”次の一歩”です。
私自身、Automationを最初は「クラウド上のVMを夜に止めるスクリプト置き場」くらいに思っていました。ところが実務では、オンプレを含めた社内サーバー全体の運用を、この一箇所から回したい場面がどんどん出てきます。Automationは、そこまで面倒を見られるように作られているんですね。
「Runbookは動かせた。けど、オンプレのサーバーとか、パッチ当てとか、設定の統制ってAutomationでできるの？それぞれ別サービスがいるの？」
この記事では、Automationの応用としてハイブリッドRunbookワーカー（クラウドから社内サーバーやオンプレVMを操作する）、構成管理（サーバーの”あるべき状態”を定義してドリフトを検知・是正する）、更新管理（OSパッチの評価とスケジュール適用を一元化する）、そしてLogic Apps／Functionsとの使い分けまでを、公式ドキュメントの正確さは押さえつつ、初心者がつまずく所を噛み砕いて解説します。読み終わるころには、Automationを「クラウドの中だけ」ではなくオンプレを含めた運用自動化の司令塔として捉えられるようになります。
なお、Runbookそのものやスケジュール実行といった基本がまだあやふやな方は、先に Azure Automationとは？Runbookによる運用自動化・スケジュール実行を実務目線で解説 に目を通しておくと、この記事の位置づけがはっきりします。本記事はその親記事の”応用編”にあたる子記事です。
ハイブリッドRunbookワーカー：クラウドから社内サーバーを操作する
まず、応用編でいちばん出番が多いのがこれです。基本のRunbookは、Azureのクラウド上（Automationが用意したサンドボックスと呼ばれる実行環境）で動きます。つまり実行される場所はMicrosoftのデータセンターの中。ここで多くの人が最初に困るのが、「じゃあ、うちの社内ネットワークにあるオンプレのファイルサーバーや、別クラウドのVMには手が届かないのでは？」という点です。
その”届かない”を解決するのがハイブリッドRunbookワーカーです。名前が仰々しいですが、やっていることはシンプルで、Runbookをクラウドではなく「あなたが指定したマシンの上」で実行させる仕組みです。
たとえるなら「現地スタッフ」
イメージしやすいたとえで言うと、こうです。Automationのクラウド実行は、遠くの本社から電話で指示を出す本部のようなもの。でも本部の電話は、外部からは入れない社内ネットワークの中までは届きません。そこで、社内に一人スタッフを常駐させておく。本部（Automation）が指示を出すと、その現地スタッフ（＝ハイブリッドワーカーを入れたマシン）が、社内ネットワークの中で実際に手を動かしてくれる。これがハイブリッドRunbookワーカーです。
この「現地スタッフ」は、社内ネットワークの内側にいるので、外部から直接触れないオンプレのサーバーやデータベース、ファイル共有にアクセスできます。しかもこの仕組みは、社内オンプレだけでなく、AWSやGCPといった別のクラウド上のVMに対しても同じように使えます。要は「Azureの外にあるマシンで、Azure Automationのスクリプトを走らせたい」というときの答えが、ハイブリッドRunbookワーカーだと覚えておけば大丈夫です。
導入の全体像（拡張機能ベース）
現在の推奨方式は拡張機能ベース（Extension-based）のハイブリッドワーカーです。以前はエージェント（Log Analyticsエージェント）を入れる古い方式がありましたが、そちらは順次終息に向かっているので、これから学ぶなら拡張機能ベースの一択で問題ありません。導入の流れをざっくり押さえておきましょう。
手順の骨格はこうなります。まずAutomationアカウントの中にハイブリッドワーカーグループという”班”を作ります。次に、その班に実際のマシンをワーカーとして登録し、そのマシンへ拡張機能をインストールします。あとはRunbookを実行するときに「クラウドで実行」か「このハイブリッドワーカーグループで実行」かを選ぶだけ。グループにしておくのは、同じ班に複数台を入れておけば、1台が落ちても別の台が仕事を引き継げるからです。
ここでひとつ大事な前提があります。Azureの外にあるマシン（オンプレや別クラウド）をワーカーにするには、そのマシンをまず「Azure Arc対応サーバー」としてAzureに繋いでおく必要があります。Azure Arcは、ざっくり言うと「Azureの外にあるマシンを、Azureの管理対象として登録する仕組み」です。Arcで繋ぐと、そのオンプレサーバーがAzureポータル上に”リソース”として現れ、拡張機能をインストールできるようになる。逆に言えば、Azure上のVMは最初からAzureの管理下にいるのでArcは不要で、拡張機能をそのまま入れられます。
「オンプレを操作したい＝まずArcで繋ぐ、が入口」。この一言を覚えておくと、この先の構成管理も更新管理も一気に地続きになります。
つまずきポイント
実際に組んでみると引っかかりやすいのが、「どのアカウントで動くのか」という点です。クラウド実行のRunbookはAutomationのマネージドIDで動きますが、ハイブリッドワーカー上で動くRunbookは、既定ではそのマシンのローカルのシステムアカウントで実行されます。「クラウドでは動いたのにハイブリッドワーカーだと権限エラーで落ちる」というのは、この実行アカウントの違いが原因のことがほとんどです。オンプレのサーバーに対して何か操作するなら、そのローカルアカウントに必要な権限があるか、あるいは資格情報アセット（Automationに保存した認証情報）をRunbook内で明示的に使うか、を最初に確認しておきましょう。
もうひとつはネットワークの向きです。ハイブリッドワーカーは、ワーカー側からAzure（Automation）へアウトバウンド（外向き）で接続を張る設計になっています。つまりAzure側から社内へ穴を開けにいくのではなく、社内のワーカーがAzureに”会いにいく”形。だから社内ファイアウォールでは、特定のAzureエンドポイントへの外向き通信（HTTPS/443）を許可してあげる必要があります。「インバウンドを開けなきゃいけないのでは」と身構えがちですが、基本は外向きだけ、というのは安心材料としても覚えておくと良いです。
構成管理（Machine Configuration）：あるべき状態を定義してドリフトを検知する
次は、サーバーの”設定そのもの”を統制する話です。運用をしていると、こんな悩みが必ず出てきます。「気づいたら誰かがサーバーの設定を変えていた」「10台のWebサーバー、全部が本当に同じ設定になっているか自信がない」。この手作業でバラバラになっていく問題に効くのが構成管理です。
DSCという考え方と、その後継
構成管理の根っこにあるのがDSC（Desired State Configuration＝望ましい状態の構成）という考え方です。ポイントは「手順を書く」のではなく「あるべき状態を書く」という発想の転換にあります。たとえば「IISをインストールして、サービスを起動して……」という手順を並べるのではなく、「このサーバーはIISが入っていて、稼働している状態であるべき」という結果（状態）だけを宣言する。あとは仕組みのほうが、現状と見比べて足りなければ揃えてくれます。
料理でたとえるなら、レシピ（手順書）を渡すのがスクリプト、「完成した皿の写真」を渡すのがDSCです。写真どおりになっていなければ、足りない具材を足して写真に近づける。これが状態ベースの発想です。
ここで用語の整理を少し。かつてAzure AutomationにはState Configuration（Automation DSC）という機能があり、DSCの設定をクラウドから配っていました。ただ現在、この役割はAzure Machine Configuration（マシン構成／旧Guest Configuration）という後継サービスへ引き継がれています。これから学ぶなら、Automation DSCではなくMachine Configurationを前提にするのが正解です。この記事でも以降はMachine Configurationの話として進めます。
「監査だけ」と「是正まで」を選べる
Machine ConfigurationはAzure Policyと組み合わせて動きます。Azure Policyは「ルールを決めて、それに沿っているかを評価する」仕組みで、Machine Configurationはその評価対象を”サーバーのOS内部の設定”にまで広げてくれるもの、とイメージすると分かりやすいです。
実務で大事なのが「どこまで踏み込むか」を選べるという点です。公式では大きく次の3つのモードが用意されています。
- 監査（Audit）：状態をチェックして報告するだけ。設定は一切変えない。まずは現状把握から入りたいときの安全な入口。
- 適用して監視（Apply and Monitor）：あるべき状態を一度適用したうえで、その後の変化を見張る。
- 適用して自動修正（Apply and Autocorrect）：あるべき状態からズレたら自動で元に戻す。いわゆる構成ドリフトの自動是正。
この「構成ドリフト」というのは、あるべき状態から現実の設定が少しずつズレていく現象のことです。誰かが緊急対応でこっそり設定を変えた、別の担当がうっかり上書きした——そういう積み重ねで、いつの間にか”あるべき姿”と違うサーバーが増えていく。Machine Configurationの自動修正モードは、そのズレを見つけて黙って元に戻してくれるわけです。ここでも入口はまず監査から。いきなり自動修正をかけると想定外の設定まで巻き戻して事故になりやすいので、監査で現状を可視化 → 問題なければ適用、という順番を強くおすすめします。
そして、これもハイブリッドワーカーと同じで、Azure VMだけでなくAzure Arcで繋いだオンプレ／別クラウドのマシンにも同じように適用できます。「クラウドも社内も、同じルールで設定を統制する」という一元管理が、Arcを軸にして成立しているのが見えてくると思います。
更新管理（Azure Update Manager）：パッチ当てを一元化する
応用編のもうひとつの主役が、OSのパッチ管理です。サーバー運用で地味に重く、それでいて絶対に手を抜けないのがWindows UpdateやLinuxのパッケージ更新。「今月のパッチ、どのサーバーに当たっていて、どれが未適用か、正確に言える？」と聞かれて即答できる現場は、実はそう多くありません。このパッチの当たり具合を見える化し、当てる作業まで自動化するのが更新管理です。
ここも用語を先に整理しておきます。昔はAutomationのUpdate Management（更新管理）という機能がこの役割を担っていましたが、現在はAzure Update Managerという独立したサービスに置き換わっています。Update ManagerはLog AnalyticsワークスペースやAutomationアカウントに依存しない作りになっていて、Azure VMとArc対応サーバーにネイティブに備わった機能として使えます。これから学ぶなら、迷わずUpdate Managerを前提にしてください。
「評価」と「適用」は分けて考える
Update Managerを理解するコツは、「評価（アセスメント）」と「適用（デプロイ）」を別物として捉えることです。
評価は「このサーバーに、今いくつ未適用の更新があるか」を調べる健康診断のような工程です。実際にパッチを当てるわけではないので安全で、まずはここから始められます。定期評価をオンにしておけば、おおむね24時間ごとに自動でチェックしてくれるので、「未適用が何件あるか」を常に把握できる状態になります。
一方の適用は、実際にパッチを当てる工程です。ここで効いてくるのがメンテナンス期間（メンテナンスウィンドウ）という考え方。「毎月第2火曜の翌週末、深夜2時から4時のあいだにだけパッチを当てる」といった時間帯を決めて、その枠の中だけで更新を流す設定ができます。業務時間中に勝手に再起動されて事故る、という最悪パターンを避けるための命綱です。
実務でありがたい使い方
Update Managerが実務でありがたいのは、台数が増えても運用が破綻しないところです。押さえておくと役立つポイントを挙げておきます。
- Azureも社内も一枚のダッシュボードで：Azure VMも、Arcで繋いだオンプレ／他クラウドのサーバーも、同じ画面でパッチのコンプライアンス状況を並べて見られる。
- その場適用とスケジュール適用：緊急のゼロデイ対応は「今すぐ適用」、通常運用は「メンテナンス期間でスケジュール適用」と使い分けられる。
- 動的スコープ：「この条件に合うマシン」というグルーピングでまとめて対象にできるので、対象を1台ずつ手で指定しなくてよい。
ここでも共通しているのは「まず評価で現状を見える化 → メンテナンス期間を決めて安全に適用」という流れです。ハイブリッドワーカー・構成管理・更新管理と見てきましたが、Azure Arcで社内マシンを繋ぎ、Azure側から一元的に運用するという同じ骨格が、機能を変えて何度も出てきているのが分かると思います。ここが応用編を貫く芯です。
Logic Apps／Functionsとの使い分け
最後に、初心者がかなりの確率で混乱するテーマを整理します。「自動化っぽいサービスが多すぎる。Automationと、Logic Appsと、Functions、結局どれを使えばいいの？」という疑問です。役割がはっきり分かれているので、早見表で押さえてしまいましょう。
| サービス | 得意なこと | 典型的な用途 |
|---|---|---|
| Azure Automation | IT運用のスクリプト実行 | VMの起動/停止、パッチ、構成管理、オンプレ操作（ハイブリッドワーカー） |
| Logic Apps | サービス間をつなぐ連携ワークフロー | 「メールが来たら承認 → 記録 → 通知」などSaaS/API連携の自動化 |
| Functions | イベント駆動のコード実行 | 「ファイルがアップされた瞬間に処理」など、きっかけに反応する短いコード |
ざっくりした選び分けのコツはこうです。インフラやサーバーを”運用”する管理者目線のスクリプトならAutomation。複数のサービス（Teams、SharePoint、外部API…）をノーコードでつなぐ業務フローならLogic Apps。「何かが起きた瞬間」に反応して動く軽いコードならFunctions。今回の主役であるオンプレ操作・パッチ・構成統制は、いずれも「サーバーを運用する」話なので、まっすぐAutomationの領分だと判断できます。
実際にはこれらは対立するものではなく、組み合わせて使うことも多い機能です。たとえば「Logic Appsで承認フローを回し、承認が下りたらAutomationのRunbookを呼び出してサーバーを操作する」といった連携はよくあるパターン。ただ、Logic Apps自体を掘り下げると話が大きくなるので、この記事では”使い分けの地図”を持ってもらうところまでに留めます。Logic Appsは別途あらためて取り上げます。
まとめ
この記事では、Azure Automationの応用として、基本のRunbook実行の”次の一歩”を見てきました。要点を振り返っておきます。
- ハイブリッドRunbookワーカー：Runbookを「指定したマシンの上」で実行し、オンプレや別クラウドのサーバーを操作できる。Azure外のマシンはAzure Arcで繋ぐのが入口。実行アカウントとアウトバウンド通信に注意。
- 構成管理（Machine Configuration）：手順ではなくあるべき状態を宣言し、構成ドリフトを検知・是正する。まず監査から入り、問題なければ適用。Automation DSCではなくMachine Configurationが後継。
- 更新管理（Update Manager）：パッチを評価と適用に分けて考える。定期評価で見える化し、メンテナンス期間で安全にスケジュール適用。Azureも社内も一枚のダッシュボードで。
- 使い分け：運用スクリプトはAutomation、連携ワークフローはLogic Apps、イベント駆動コードはFunctions。
通して見えてくるのは、Azure Arcで社内マシンを繋ぎ、Automation／Machine Configuration／Update Managerで一元的に運用するという一本の背骨です。ここまで捉えられれば、Automationを「クラウドの中だけで完結する自動化」ではなく、オンプレを含めた運用自動化の司令塔として使える段階に立っています。基本のRunbookから始めた人にとって、これは大きな景色の広がりです。
あわせて読みたい：
