Hybrid Runbook Worker（HRW）は、Azure Automationのランブックを、Azureのサンドボックスではなくオンプレミスや他クラウドの自分のマシン上で実行するための仕組みです。2024年8月にエージェント版が廃止され、現在は拡張機能版が唯一の選択肢です。この記事では、仕組みとSystem版・User版の違い、要件、PowerShellとAzure CLIでの登録コマンド、ランブックの実行方法、つまずきの対処までを、2026年10月14日時点のMicrosoft Learnの記載に沿って整理します。
まとめ：Hybrid Runbook Workerの現状と拡張機能版で押さえる要点
- 使える方式：エージェント版は2024年8月31日に廃止、2025年4月1日以降はジョブも停止。現在は拡張機能版（HybridWorkerExtension）だけです。
- 前提：システム割り当てマネージドIDで認証し、オンプレ機はAzure Arcへのオンボードが必要です。
- 要件：2コア・4GB RAM以上。外向き443で
*.azure-automation.netへ届けば、受信ポートの開放は要りません。 - 登録の要点：拡張機能の設定値は
AutomationHybridServiceUrlで、RegistrationUrlではありません。 - 判断：Azureリソースの操作だけで終わる短い処理はサンドボックスで足ります。オンプレ依存・3時間超・ファイアウォール内の処理だけをHRWへ寄せます。
Hybrid Runbook Workerの仕組みとAzureサンドボックスとの違い
ランブックの実行場所を自社のマシンへ移すHybrid Runbook Workerの役割
ランブック（runbook）は、Azure Automationに保存する自動化スクリプト（PowerShellやPythonなど）で、「何をするか」の定義です。「どこで動かすか」は実行環境が担い、既定ではAzure側のサンドボックス（Azureサンドボックス）で動きます。
これに対しHybrid Runbook Workerは、実行場所を自分の管理するマシンに移す仕組みです。オンプレのファイルサーバーや社内APIなど、サンドボックスから届かない対象に手が届きます。ランブックの保存と管理はAzure Automation側に残ります。
Azureサンドボックスの3時間制限とHRWで外れる実行環境の制約
Azureサンドボックスは共有環境で、実行時間やモジュール、ネットワーク到達範囲に制約があります。Microsoft LearnのHybrid Runbook Worker概要は、HRWの典型例としてクラウドジョブの3時間制限を超える処理、リソースを多く使う処理、オンプレのサービス連携、昇格権限が必要なスクリプトを挙げています。HRWではサンドボックスの「フェアシェア」による時間制限を受けず、制約はワーカー自身のリソースだけです。
ファイアウォールを有効にしたAzure Storage・Key Vault・Azure SQLも、HRWが受け皿です。Automationは「信頼されたMicrosoftサービス」に含まれないため、サンドボックスからは届きません。
System版とUser版の2種類と、本記事でセットアップ対象とするUser版
Hybrid Runbook Workerには2種類あります。System Hybrid Runbook Workerは、旧Update ManagementなどAzure Automationの機能が内部的に使うもので、ユーザーが直接ランブックを流す用途では使いません。旧Update Managementの解説ページは2026年10月時点でAzure Update Managerへ転送されています。
自分で書いたランブックを実行させるのはUser Hybrid Runbook Workerです。本記事のセットアップと廃止・移行の話は、すべてこのUser版を指します。
ジョブは30秒ごとのポーリングで取得される：1台4件と4,000台の上限
HRWは、ワーカーがジョブを取りに行く方式です。各ワーカーは30秒ごとにAutomationサービスへ問い合わせ、先に問い合わせたワーカーがジョブを受け取ります。1回で受け取れるのはおおむね4件で、それを超えるペースで投入すると中断されることがあります。
開始時に指定できるのはグループだけで、個々のワーカーは選べません。1台が登録できるAutomationアカウントは1つで、上限は1アカウントあたりSystem・User各4,000台です。
エージェント版の廃止と拡張機能版への移行：2024年8月以降の変更点
2024年8月31日の廃止と2025年4月1日からのジョブ停止の影響範囲
ここが古い解説記事と最も食い違う点です。Log Analyticsエージェント（旧MMA）に依存していたエージェント版User Hybrid Runbook Worker（Windows・Linux）は2024年8月31日に廃止され、2025年4月1日以降はジョブもすべて停止しています。エージェント版が残っていれば、移行済みかを最優先で確認してください。Log Analyticsエージェントで集めていたログの置き場所は、Azure Log Analyticsのワークスペース設計とテーブルプラン別の保存コストを参考に見直します。
拡張機能版が標準になった理由：マネージドIDとARMへの統合
拡張機能版は、認証の土台をLog AnalyticsエージェントからマネージドID（Microsoft Entra ID）へ置き換えたものです。VM拡張機能として展開し、Azure Resource Manager（ARM）のIDモデルに直接乗るので、エージェントの保守が要りません。
展開はポータル、PowerShell、Bicep、ARMテンプレート、REST API、Azure CLIから選べ、マイナーバージョンの自動アップグレードが既定で有効です（メジャー更新は手動）。移行は認証と展開の方式そのものが変わる作業なので、延命ではなく設計として捉えます。Microsoft Entra ID（旧Azure AD）とは？Active Directoryとの違い・機能・料金もあわせて確認しておくと、マネージドID周りの理解が早まります。
エージェント版から拡張機能版へ移す手順：同居させて切り替える流れ
同じマシンにエージェント版（V1）と拡張機能版（V2）を同居させられるので、移行は「並べてから外す」順で進めます。既存のグループの「ハイブリッドワーカー」から既存のV1マシンを追加すると、同じマシンが「プラットフォーム」列でV1とV2の2行に並びます。
V2でジョブが動くのを確かめたら、V1の行を削除します。ポータルでの削除は登録を消すだけで、Log Analyticsエージェントのアンインストールは別作業です。台数が多いときはテンプレートでまとめて入れるのが早道で、Azure Bicepのインストールからbicep build・デプロイまでの手順が下敷きになります。
拡張機能版Hybrid Runbook Workerの要件：対応OS・ネットワーク・Arc
Azure VMとAzure Arc対応サーバー：オンプレ機はArcオンボードが前提
拡張機能版のマシンは、Azure Resource Managerから見えている必要があります。Azure VMはそのまま対象にできますが、オンプレミスや他クラウドのサーバーは、先にAzure Connected Machine agentを入れてArc対応サーバーにしておくのが前提です（Arc対応のVMware vSphere VM・SCVMM管理下のVMも対象）。Arc化していないオンプレ機には入れられません。
Arc不要だった旧エージェント版との大きな違いなので、移行時は対象機のArcオンボードから確認します。Arcの無料範囲とオンボード手順はAzure Arcとは？料金の無料範囲と有料機能の単価・導入手順にまとめています。仮想マシンスケールセット（VMSS）はHRWの対象外です。
2コア・4GB RAMと対応OS：PowerShell 5.1と.NETの要件
最小要件は2コア以上・4GB RAM以上と、システム割り当てマネージドIDの有効化です。旧解説にある「10GBの空きストレージ」は公式要件ではありません。拡張機能版のデプロイ手順ページ（2026年7月更新版）の対応OSと追加要件は次のとおりです。
| 項目 | Windows（x64） | Linux（x64） |
|---|---|---|
| 主な対応OS | Windows Server 2016〜2022 | Ubuntu 22.04まで、RHEL 9まで |
| そのほかのOS | Windows 10・11、2012系はEOS | Debian・SLES・Rocky・Oracle |
| 実行に必要なもの | Windows PowerShell 5.1 | glibc、OpenSSL、curl、PAM |
| そのほかの条件 | .NET Framework 4.6.2以上 | Linuxハードニング無効 |
| Pythonの制約 | 個別の制約なし | Python 3.11以降は非対応 |
Windowsのワーカー本体はWindows PowerShell 5.1で動きます。7系のランブックを流すなら、7系を別に追加します（後述）。また、ドメインコントローラーを兼ねるVMには拡張機能を入れないよう公式が強く推奨しています。Active Directoryの操作は、メンバーサーバーに置いたワーカーから行います。
外向き443で*.azure-automation.netへ届けばよいネットワーク要件
ネットワークは、対象マシンから外向きにHTTPS（ポート443）で *.azure-automation.net へ到達できることが必須です（Azure Automationのネットワーク構成）。インバウンドのポート開放は不要です。リージョン別のDNSレコードに絞って許可することもできます。
NSGやAzure Firewallでは、IPアドレスの代わりにサービスタグ GuestAndHybridManagement を指定できます。プロキシ経由の要求は30秒でタイムアウトし、3回で失敗扱いになります。443の外向きが絞られた環境では、ここが最初のつまずきどころです。
拡張機能版をPowerShellとAzure CLIでセットアップする手順とコマンド
ポータルでハイブリッドワーカーグループを作りマシンを追加する5ステップ
User Hybrid Runbook Workerの追加は、Azure Automationアカウントを起点にした次の流れで進めます。
- 対象マシンを用意する。オンプレ・他クラウドの場合は先にAzure ArcへオンボードしてArc対応サーバーにする。
- Azure Automationアカウントの「プロセスオートメーション」から「ハイブリッドワーカーグループ」を作成する（実行対象をまとめる論理グループ）。
- 作成したグループに対象マシンを追加する。この操作でHybridWorkerExtension（VM拡張機能）が対象機へ展開される。
- 対象マシンのシステム割り当てマネージドIDが有効化される（無効なら追加処理の中で有効化される）。
- ランブックの実行時に「実行先」としてハイブリッドワーカーグループを指定し、対象機で動くことをテスト実行で確認する。
拡張機能のインストールには数分かかります。追加候補に出るのは、どのグループにも属していないマシンだけです。
PowerShellでワーカーを登録し拡張機能を入れる手順とURLの取得
複数台に同じ構成を入れる場合はPowerShell（Az.Automation・Az.Compute）で組みます。グループ作成、ワーカー登録、URL取得、拡張機能の展開の4段で、引数はNew-AzAutomationHybridRunbookWorkerGroupのリファレンスで確認できます。以下はAzure上のWindows VMを登録する例です。
# 自社の環境名に置き換える
$rg = "rg-automation"
$account = "aa-ops-prod"
$group = "hwg-onprem-file"
$vm = Get-AzVM -ResourceGroupName "rg-vm" -Name "vm-batch01"
# 0. VMのシステム割り当てマネージドIDを有効化
Update-AzVM -ResourceGroupName $vm.ResourceGroupName -VM $vm -IdentityType SystemAssigned
# 1. ハイブリッドワーカーグループを作成
New-AzAutomationHybridRunbookWorkerGroup -ResourceGroupName $rg -AutomationAccountName $account -Name $group
# 2. VMをワーカーとして登録（ワーカー名は新しいGUID）
New-AzAutomationHybridRunbookWorker -ResourceGroupName $rg -AutomationAccountName $account `
-HybridRunbookWorkerGroupName $group -Name (New-Guid).Guid -VmResourceId $vm.Id
# 3. AutomationHybridServiceUrl を取得（RegistrationUrl ではない）
$sub = (Get-AzContext).Subscription.Id
$path = "/subscriptions/$sub/resourceGroups/$rg/providers/Microsoft.Automation/automationAccounts/${account}?api-version=2023-11-01"
$hybridUrl = ((Invoke-AzRestMethod -Path $path -Method GET).Content | ConvertFrom-Json).properties.automationHybridServiceUrl
# 4. 拡張機能を展開（Linux VMなら HybridWorkerForLinux）
$settings = @{ "AutomationAccountURL" = $hybridUrl }
Set-AzVMExtension -ResourceGroupName $vm.ResourceGroupName -Location $vm.Location -VMName $vm.Name `
-Name "HybridWorkerExtension" -Publisher "Microsoft.Azure.Automation.HybridWorker" `
-ExtensionType "HybridWorkerForWindows" -TypeHandlerVersion 1.1 -Settings $settings -EnableAutomaticUpgrade $trueArc対応サーバーの場合は、手順2の -VmResourceId にArcマシンのリソースIDを渡し、手順4を New-AzConnectedMachineExtension に置き換えます。引数名は -MachineName と -Setting（単数形）です。Windowsでプロキシを通す場合は、$settings に ProxySettings を足します。
Azure CLIのaz automation hrwgでグループとワーカーを登録
Azure CLIでは az automation 拡張機能（Azure CLI 2.75.0以上）の az automation hrwg を使います（初回実行時に自動で入ります）。以下はLinux VMをbashから登録する例です。
RG=rg-automation; AA=aa-ops-prod; HWG=hwg-linux-batch
az vm identity assign -g rg-vm -n vm-batch02
az automation hrwg create -g $RG --automation-account-name $AA --name $HWG
VM_ID=$(az vm show -g rg-vm -n vm-batch02 --query id -o tsv)
az automation hrwg hrw create -g $RG --automation-account-name $AA \
--hybrid-runbook-worker-group-name $HWG \
--hybrid-runbook-worker-id $(uuidgen) --vm-resource-id "$VM_ID"
SUB=$(az account show --query id -o tsv)
HYBRID_URL=$(az rest --method get \
--url "https://management.azure.com/subscriptions/$SUB/resourceGroups/$RG/providers/Microsoft.Automation/automationAccounts/$AA?api-version=2023-11-01" \
--query properties.automationHybridServiceUrl -o tsv)
az vm extension set -g rg-vm --vm-name vm-batch02 \
--name HybridWorkerForLinux --extension-instance-name HybridWorkerExtension \
--publisher Microsoft.Azure.Automation.HybridWorker --version 1.1 \
--settings "{\"AutomationAccountURL\": \"$HYBRID_URL\"}" --enable-auto-upgrade true
az automation hrwg hrw list -g $RG --automation-account-name $AA --hybrid-runbook-worker-group-name $HWG -o table最後の hrw list でワーカーが表示され、VMの拡張機能が「プロビジョニング成功」なら完了です。
ランブックをハイブリッドワーカーで動かす：RunOn指定とランタイム設定
マネージドIDでAzureに接続しローカル処理も行うランブックの例
HRWで動くランブックの構造はサンドボックス用と同じです。違いは、モジュールをワーカー側に入れておくことと、開始時に実行先グループを指定することの2点です。次の例は、AutomationアカウントのマネージドIDでAzureに接続しつつ、ワーカー自身のWindowsサービスの状態を返します（ワーカーにAz.Accountsが入っている前提）。
param([string]$ServiceName = "Spooler")
# 以前のジョブのAzコンテキストを引き継がない
Disable-AzContextAutosave -Scope Process | Out-Null
# Automationアカウントのシステム割り当てマネージドIDで接続
$ctx = (Connect-AzAccount -Identity).Context
Set-AzContext -SubscriptionName $ctx.Subscription -DefaultProfile $ctx | Out-Null
# サンドボックスからは届かない、ワーカー自身のローカル処理
$svc = Get-Service -Name $ServiceName
Write-Output ("{0}: {1} = {2}" -f $env:COMPUTERNAME, $svc.Name, $svc.Status)このランブックを発行したら、Hybrid Runbook Workerでのランブック実行の手順どおり、-RunOn にグループ名を渡して開始します。-RunOn を省くと、ジョブは通常どおりAzureサンドボックスで動きます。
Start-AzAutomationRunbook -ResourceGroupName "rg-automation" -AutomationAccountName "aa-ops-prod" `
-Name "Check-LocalService" -RunOn "hwg-onprem-file" -Parameters @{ ServiceName = "W32Time" }ジョブの実行ユーザーは、WindowsではローカルのSystemアカウントです。ワーカーが再起動すると実行中のジョブは最初からやり直しになり、3回を超えると中断されます。長時間のランブックは再実行に耐える作りにしておきます。
PowerShell 7.4とPython 3.10を使うときの環境変数と拡張機能の版
2026年10月時点の公式ページでは、PowerShell 7.4とPython 3.10のランブックは拡張機能版でのみ動き、Windowsは拡張機能1.3.63以上、Linuxは1.1.23以上が条件です（7.2は1.1.11以上）。PowerShell 5.1・Python 3.8も引き続き使えます。
ランタイム本体はワーカーに自分で入れ、パスを環境変数 powershell_7_4_path・python_3_10_path で知らせます。Linuxは /etc/environment に追記し、再起動か再ログインで反映させます。
# /etc/environment に追記（Linuxワーカー）
powershell_7_4_path="/usr/bin/pwsh"
python_3_10_path="/usr/bin/python3.10"Windowsでは「システムのプロパティ」の環境変数に同じ名前で登録し、ワーカーを再起動します。PowerShell 7系の入れ方はPowerShellのインストール手順（7.6 LTSをwinget・MSI・Linux・macOSで入れる）を参照してください。HRWの対応表に載っているのは7.4までなので、ワーカーには表にある版を入れておくのが確実です。
認証と権限管理：マネージドIDとHybrid Worker資格情報の使い分け
拡張機能版の認証は、マネージドID（Microsoft Entra ID）が主役です。Azureリソースを操作するなら、このIDに必要なロール（Azure RBAC）だけを割り当てます。特定リソースグループのVMを起動・停止するだけなら、そのスコープに「仮想マシン共同作成者」相当を与え、それ以上は付与しません。
使えるIDは、AutomationアカウントのシステムID、Azure VMのシステムIDまたはユーザー割り当てID、Arc対応サーバー組み込みのシステムIDです。注意点は排他関係です。AutomationアカウントのマネージドIDを有効にすると、VM側・Arc側のIDはランブックから使えなくなります。Automationアカウントのユーザー割り当てIDはHRWでは使えません。
オンプレのリソースだけに触るなら、グループ設定の「Hybrid Worker資格情報」をカスタムにし、資格情報アセットのユーザーでジョブを動かせます（Linuxは非対応）。Arc対応サーバーでは C:\ProgramData\AzureConnectedMachineAgent\Tokens の読み取り権限をそのユーザーへ直接付与する必要があり、Connected Machine agentの更新でこの権限が外れる既知の問題もあります。パスワードはランブックに直書きせず、資格情報アセットや変数アセットで管理します。
つまずきやすい原因と対処：ジョブ停止・登録失敗のログ確認手順
拡張機能版でジョブが動かない・登録できないときは、原因が特定のパターンに集中します。
- 外向き443がブロックされ
*.azure-automation.netへ届かない（プロキシ・FWを確認）。 - オンプレ機がArc未オンボードで「Unable to retrieve IMDS identity endpoint」になる。
- システム割り当てIDが無効で「Invalid Authorization Token」になる（有効化して拡張機能を入れ直す）。
- ランブックが使うモジュールやランタイムが対象機に入っていない。
- 30秒に4件を超える投入で「exceeded the job limit」になる（ワーカーを増やす）。
- Linuxでジョブが実行中のまま進まない（既定でCPU 1コアあたり25%のクォータ）。
切り分けの起点は、拡張機能版のトラブルシューティングにあるワーカー側のログです。Windowsはイベントログ Microsoft-SMA/Operational と、拡張機能フォルダーの bin\troubleshooter\TroubleShootWindowsExtension.ps1 の診断結果を見ます。Linuxは hwd サービスと /var/log/azure/ 配下のログです。
30日以上問い合わせのないワーカーはグループから外されます。問い合わせ回数はメトリック HybridWorkerPing で追えるので、Azure Monitorの監視の仕組みに沿ってアラートを掛けておくと停止に早く気づけます。
Hybrid Runbook Workerを採用する条件と見送る場面の判断基準
HRWを入れると、ワーカーのOS更新、ランタイムの入れ替え、Arcエージェントの保守が新たな運用として乗ります。判断は次の条件で決めます。
- 採用する：オンプレのファイルサーバー・業務DB・社内APIを定期操作する／3時間を超えるバッチがある／ファイアウォールを開けずにStorage・Key Vault・SQLを処理したい。
- 見送る：Azureリソースの起動停止だけで終わる処理（サンドボックスで足ります）／イベント起点の短い処理（Azure Functionsのほうが軽い）／ワーカーをドメインコントローラーにしか置けない環境。
- 台数の目安：1グループ1台は冗長性がゼロです。夜間バッチなど止められない処理を載せるなら、最低2台で1グループを組みます。
移行ではArcのオンボード、マネージドIDの権限設計、443の許可をまとめて見直すことになり、オンプレとAzureをまたぐ設計に慣れたチームで進めると手戻りが減ります。一創ではAWS・Google Cloud・Azureのインフラ構築として、Azure Automationとオンプレ環境をつなぐ運用基盤の設計・構築も承っています。
よくある質問
Hybrid Runbook Workerについて、検索の多い質問に答えます。
Hybrid Runbook Workerとは何ですか？
Azure Automationのランブックを、Azureのサンドボックスではなく自分の管理するマシン（オンプレサーバー、Azure VM、他クラウドVM）で実行させる機能です。オンプレのリソース操作や、サンドボックスでは動かない3時間超の処理に使います。現在使えるのは拡張機能版だけです。
runbook（ランブック）とはどういう意味ですか？
Azure Automationに保存する自動化スクリプト（PowerShellやPythonなど）を指します。定型作業の手順をコード化して繰り返し実行するためのもので、そのランブックの実行場所を自分のマシンへ移すのがHybrid Runbook Workerです。HRWで動かす場合も、ランブックの書き方はサンドボックス用と変わりません。
エージェント版はまだ使えますか？
使えません。エージェント版User Hybrid Runbook Worker（Windows・Linux）は2024年8月31日に廃止され、2025年4月1日以降はジョブも停止しています。同じマシンにV1とV2を同居させられるので、拡張機能版を追加して動作を確かめてから、エージェント版の登録を削除します。
オンプレミスのサーバーでも動かせますか？
動かせますが、対象サーバーを先にAzure ArcへオンボードしてArc対応サーバーにする必要があります。そのうえでハイブリッドワーカーグループへ追加します。通信は外向き443だけで足り、受信ポートの開放は不要です。ドメインコントローラーへの導入は避けてください。
System版とUser版の違いは何ですか？
System Hybrid Runbook Workerは旧Update ManagementなどAzure Automationの機能が内部的に使うもので、ユーザーがランブックを直接実行する用途では使いません。自分の書いたランブックを実行させるのはUser Hybrid Runbook Workerで、セットアップや移行の対象はこちらです。上限はどちらも1つのAutomationアカウントあたり4,000台です。
関連記事
- Azure Arcとは？料金の無料範囲と有料機能の単価・導入手順【2026年10月】
- Microsoft Entra ID（旧Azure AD）とは？読み方・Active Directoryとの違い・機能・料金をコード付きで解説【2026年版】
- Azure Bicepとは？インストールからbicep build・デプロイまでの実務手順
- Azure Monitorとは？監視の仕組み・Log AnalyticsとApplication Insightsの関係・料金モデルとDatadogとの違いを実装者目線で解説
- Azure Pipelinesの使い方｜YAMLでCI/CDを組む手順と無料枠・権限設定
- Azure DevOpsは日本語化できる？UIを日本語にする方法とServices/Serverの違い
