Azure Automationで、同じAutomationアカウント内に「旧版モジュールを使うRunbook」と「新版モジュールを使うRunbook」を共存させたい場合は、Runtime Environmentを分けて各Runbookへ割り当てるのが基本です。
Runtime Environmentには、PowerShellやPythonの種類、ランタイムバージョン、実行時に読み込むモジュールやパッケージを定義できます。モジュール競合を避けるためだけにAutomationアカウントを複数作る必要が減り、既存Runbookを新しいサポート対象ランタイムへ段階的に移行しやすくなります。
2026年7月30日に公開されたAzure Update 568102では、PowerShell 7.6 Runbook、Runtime Environment、PowerShell 7.6 RunbookでのAzure CLIコマンド対応について、一般提供が案内されました。特にRuntime Environmentの利点として、競合するモジュール版の分離、Runbookの迅速なアップグレード、Automationアカウント数の削減が挙げられています。
Azure Automation Runtime Environmentで何を分離できるのか
Runtime Environmentは、Azure Automationのジョブを実行するための環境定義です。
Microsoftの説明では、Runbookは次の2つの要素で構成されます。
| 要素 | 管理する内容 |
|---|---|
| Script code | PowerShellやPythonで記述したRunbook本体 |
| Runtime Environment | 言語、ランタイムバージョン、必要なパッケージやモジュール |
コードと実行環境は独立して管理できます。1つのRunbookに関連付けられるRuntime Environmentは1つですが、同じRuntime Environmentを複数のRunbookで共有することは可能です。(Microsoft Learn)
たとえば、同じAutomationアカウント内で次のような構成を作れます。
| Runbook | Runtime Environment | 用途 |
|---|---|---|
| 新しいVM管理Runbook | PowerShell 7.6＋現在のAzモジュール | 新規開発用 |
| 既存の管理Runbook | PowerShell＋互換性確認済みの旧モジュール | 既存処理の維持 |
| 集計用Runbook | Python 3.10＋分析用パッケージ | データ処理用 |
新しいRunbookのためにモジュールを更新しても、既存Runbookを別のRuntime Environmentへ分けておけば、同じモジュールの旧版と新版を同一Automationアカウント内で使い分けられます。
分離されるのは言語と依存パッケージ
Runtime Environmentが定義する主な対象は、次の3つです。
- PowerShellまたはPythonなどの言語
- PowerShell 7.6やPython 3.10などのランタイムバージョン
- Azモジュール、PowerShell Galleryのモジュール、PyPI由来のPythonパッケージ、独自パッケージ
一方、Runtime Environment自体にはRBACのアクセス許可を割り当てられません。そのため、これはモジュールやランタイムの依存関係を分ける仕組みであり、セキュリティ境界を作る仕組みではありません。(Microsoft Learn)
従来のモジュール管理との違い
従来のAzure Automationでは、モジュールやPythonパッケージをAutomationアカウントの共有リソースとして管理していました。そのため、同じモジュールの異なるバージョンを必要とするRunbookがあると、影響を避けるためにAutomationアカウント自体を分ける運用が必要になることがありました。
Runtime Environmentでは、実行環境ごとにパッケージ構成を持たせ、Runbook単位で使う環境を選択できます。(Microsoft Learn)
| 比較項目 | 従来の管理 | Runtime Environment |
|---|---|---|
| モジュールの管理単位 | Automationアカウント中心 | Runtime Environment単位 |
| 競合するモジュール版 | アカウント分割が必要になる場合がある | 同一アカウント内で環境を分けられる |
| ランタイムの移行 | Runbookとモジュールの影響確認が複雑 | 移行先環境を作ってテストできる |
| ロールバック | モジュールの戻し作業が必要 | 以前のRuntime Environmentへ再関連付けできる |
| 既存Runbookへの影響 | 共有モジュール更新の影響を受けやすい | 環境を分ければ影響範囲を限定できる |
Runtime Environmentは依存関係のまとまりごとに作る
Runtime EnvironmentはRunbookごとに割り当てられますが、必ずしもRunbookごとに1つ作る必要はありません。
おすすめは、同じランタイム、同じモジュール構成、同じ更新タイミングで運用できるRunbookを1つのRuntime Environmentへまとめることです。
たとえば、次のような命名ルールにすると、用途を判断しやすくなります。
<言語とバージョン>-<依存関係または用途>-<環境>| Runtime Environment名の例 | 想定用途 |
|---|---|
ps76-az-standard-prod | 標準的なPowerShell 7.6 Runbook |
ps76-legacy-prod | 互換性維持が必要な旧モジュール構成 |
ps76-az-standard-test | モジュール更新前の検証 |
py310-report-prod | Python 3.10によるレポート処理 |
細かく分けすぎると管理対象が増えます。一方、すべてのPowerShell Runbookを1つの環境へまとめると、モジュール更新時の影響範囲が広がります。
次の基準で判断するとよいでしょう。
| 状況 | 推奨する構成 |
|---|---|
| ランタイムとモジュール構成が同じ | Runtime Environmentを共有 |
| 同じモジュールの異なる版が必要 | Runtime Environmentを分離 |
| モジュール更新のタイミングが異なる | Runtime Environmentを分離 |
| 本番前に新版を検証したい | 検証用Runtime Environmentを追加 |
| 権限やセキュリティ境界も分けたい | Automationアカウントの分離を検討 |
競合するモジュールをRuntime Environmentに分離する方法
現在のランタイムとモジュールを確認する
最初に、各Runbookが依存しているランタイムとモジュールを整理します。
最低限、次の情報を一覧にします。
| 確認項目 | 確認する内容 |
|---|---|
| Runbook名 | 対象となるRunbook |
| 種類 | PowerShellまたはPython |
| ランタイム | 現在使用しているバージョン |
| モジュール | 明示的に利用しているモジュール |
| モジュール版 | 動作確認済みのバージョン |
| 実行場所 | AzureサンドボックスまたはHybrid Runbook Worker |
| 起動方法 | スケジュール、Webhook、手動、親Runbook |
| 重要度 | 停止時の業務影響 |
PowerShellでは、テスト用Runbookで次のコードを実行すると、ランタイムと利用可能なモジュールを確認できます。MicrosoftもAz PowerShellパッケージの構成確認にGet-Module -ListAvailableを案内しています。(Microsoft Learn)
Write-Output "PowerShell version:"
$PSVersionTable.PSVersion
Write-Output "Available modules:"
Get-Module -ListAvailable |
Select-Object Name, Version, Path |
Sort-Object Name, VersionPythonでは、次のコードでPython本体とインストール済みパッケージを確認できます。
import sys
from importlib.metadata import distributions
print("Python version:")
print(sys.version)
print("Installed packages:")
packages = []
for dist in distributions():
name = dist.metadata.get("Name") or "unknown"
packages.append((name, dist.version))
for name, version in sorted(packages, key=lambda item: item[0].lower()):
print(f"{name}: {version}")一覧を取得するだけでなく、Runbook内のImport-Module、#Requires、import文なども確認してください。コード上で明示されていなくても、あるモジュールが別のモジュールへ依存していることがあります。
AzureポータルでRuntime Environmentを作成する
Azureポータルでは、次の流れで作成します。
- 対象のAzure Automationアカウントを開きます。
- ［概要］を開きます。
- 必要に応じて［Try Runtime Environment experience］を選択します。
- ［プロセス オートメーション］の［Runtime Environments］を開きます。
- ［作成］を選択します。
- 名前、言語、ランタイムバージョン、説明を入力します。
- ［Packages］で必要なモジュールやパッケージを追加します。
- 設定内容を確認して作成します。
Runtime Environment名は英字で始め、英数字、アンダースコア、ハイフンを使用します。PowerShell用Runtime Environmentには、Azureリソース管理に使うAz PowerShellパッケージが既定で用意されます。追加パッケージは、ギャラリーまたはローカルファイルから登録できます。(Microsoft Learn)
2026年7月のAzure UpdateではPowerShell 7.6の一般提供が案内されています。ただし、一部のMicrosoft Learn手順や画面例にはPowerShell 7.4の表記が残っています。作成時に選べるランタイムについては、対象リージョンのAzureポータルに表示される選択肢と最新の公式更新情報を確認してください。
必要なモジュールを追加する
［Packages］では、Runbookが必要とするモジュールだけを追加します。
たとえば、旧版のモジュールを必要とするRunbookと、新版を必要とするRunbookがある場合は、次のように2つのRuntime Environmentを作ります。
| Runtime Environment | 登録するモジュール |
|---|---|
| 既存Runbook用 | 現在正常に動いている旧版 |
| 新規Runbook用 | 検証済みの新版 |
同じRuntime Environment内に競合する版を無理に共存させるのではなく、環境そのものを分けることがポイントです。
現在のMicrosoft Learnでは、パッケージのインポートについて、合計100MBまで、1回に追加できるパッケージは最大10個と案内されています。Python 3.10のカスタムパッケージについては、cp310のLinux向けWheelファイルが必要です。制限は変更される可能性があるため、大容量パッケージを登録する場合は最新情報も確認してください。(Microsoft Learn)
RunbookをRuntime Environmentへ関連付ける
新しいRunbookを作成する場合は、作成画面でRuntime Environmentを選択できます。既存Runbookを変更する場合は、次の手順で関連付けを更新します。
- Automationアカウントの［Runbooks］を開きます。
- 対象Runbookのチェックボックスを選択します。
- ［Update Runtime Environment］を選択します。
- 移行先のRuntime Environmentを選びます。
- ［Update］を実行します。
PowerShell RunbookにはPowerShell用Runtime Environmentだけが表示され、Python RunbookにはPython用Runtime Environmentだけが表示されます。選択した環境内のパッケージが、Runbook実行時に利用可能になります。(Microsoft Learn)
Runtime Environmentの変更時点ですでに実行中のジョブは影響を受けません。変更後に開始するジョブは、Runbookへ関連付けられた新しいRuntime Environmentを継承します。(Microsoft Learn)
Test Paneで実行してから公開する
本番Runbookをいきなり切り替えるのではなく、先にTest Paneで確認します。
- 対象Runbookを開きます。
- ［Edit in Portal］を選択します。
- Runtime Environment欄で移行先の環境を選びます。
- ［Test pane］を開きます。
- ［Start］を選択してテストジョブを実行します。
- エラー、警告、出力、処理結果を確認します。
- 必要に応じてコードやパッケージ構成を修正します。
- 問題がなければ［Publish］を実行します。
テスト時には、単にジョブが正常終了したかだけでなく、実際の処理結果も確認してください。モジュール更新によって、コマンドが成功しても戻り値の型やプロパティ名が変わることがあります。(Microsoft Learn)
Runtime Environmentを安全に更新する運用方法
本番環境のモジュールを直接更新しない
Runtime Environmentでは、言語とランタイムバージョンは作成後に変更できません。一方、モジュール版の変更やパッケージの追加・削除は可能です。
注意が必要なのは、Runtime Environmentのパッケージを変更すると、その環境へ関連付けられたすべてのRunbookに新しい設定が反映されることです。(Microsoft Learn)
そのため、本番環境のモジュールをその場で更新するより、次の運用が安全です。
- 現在の本番Runtime Environmentを残します。
- 新しいモジュール版を登録した検証用Runtime Environmentを作ります。
- Test Paneで対象Runbookを実行します。
- 問題がなければ本番Runbookを新環境へ切り替えます。
- 一定期間、旧環境をロールバック用として残します。
たとえば、次のように世代を分けます。
ps76-az-standard-v1-prod
ps76-az-standard-v2-test
ps76-az-standard-v2-prodこれにより、問題発生時はRunbookを以前のRuntime Environmentへ再関連付けするだけで戻せます。
ランタイム変更時は新しい環境を作る
PowerShell 7.4からPowerShell 7.6へ移行するような場合、既存Runtime Environmentのバージョンを直接書き換えることはできません。
次のように新しい環境を作成します。
移行前：ps74-standard-prod
移行先：ps76-standard-test
本番用：ps76-standard-prod言語やランタイムバージョンを不変にする仕組みは、既存Runbookの実行環境が意図せず変わることを防ぐ一方、アップグレード時には新しいRuntime Environmentの作成が必要になることを意味します。(Microsoft Learn)
既存Runbookをサポート対象ランタイムへ移行する
新しいRuntime Environmentエクスペリエンスへ切り替えると、既存Runbookは、旧画面のランタイム、モジュール、パッケージ情報を基に作られたシステム生成Runtime Environmentへ自動的に関連付けられます。既存Runbookをすぐに手作業で作り直す必要はありません。(Microsoft Learn)
システム生成Runtime Environmentには、PowerShell 5.1、PowerShell 7.1、PowerShell 7.2、Python 2.7、Python 3.8、Python 3.10などがあります。これらは直接編集できず、旧画面のModulesやPackagesに加えた変更が反映されます。新しいランタイムへ移行する場合は、編集可能なRuntime Environmentを新規作成し、Runbookを関連付け直します。(Microsoft Learn)
2026年9月30日までに旧ランタイムを確認する
Microsoftは、PowerShell 7.1、PowerShell 7.2、Python 2.7、Python 3.8について、Azure Automationでのサポートを2026年9月30日に終了すると案内しています。
サポート終了後もRunbookが実行できる場合はありますが、新機能、セキュリティ更新、バグ修正、正式サポートの対象外となります。Azure Automationのランタイムサポートは、PowerShellやPython本体、および基盤OSのサポート期間に合わせて縮小されます。(Microsoft Learn)
移行対象が多い場合は、次の順番で進めると効率的です。
- PowerShell 7.1、7.2、Python 2.7、3.8を使うRunbookを抽出する
- 毎日実行される重要Runbookを優先する
- 権限の大きいRunbookを優先する
- 新しいRuntime Environmentを作成する
- 依存モジュールを登録する
- Test Paneで実行する
- 本番Runbookを切り替える
- ジョブ履歴を監視する
- 問題がなければ旧環境を整理する
Runtime Environmentで失敗しやすいポイント
共有環境のモジュールをそのまま更新する
1つのRuntime Environmentを多数のRunbookで共有している場合、モジュール更新はすべての関連Runbookへ反映されます。
更新前に、そのRuntime Environmentへ関連付けられているRunbookを確認してください。影響を受けるRunbookが多い場合は、新しいRuntime Environmentを作って段階的に切り替えます。
依存モジュールを登録していない
PowerShellモジュールやPythonパッケージは、実行時に依存関係が検証される場合があります。対象モジュールだけを登録し、依存モジュールを登録していないと、インポートが完了しているように見えてもジョブ実行時に失敗する可能性があります。(Microsoft Learn)
エラーメッセージに次のような内容がある場合は、依存関係を確認します。
The specified module was not loaded
Could not load file or assembly
ModuleNotFoundError
ImportErrorPowerShell GalleryやPyPIの依存関係だけでなく、モジュール配布元のリリースノートも確認することが重要です。
Runtime Environmentをセキュリティ境界として使う
Runtime Environmentごとにモジュールは分けられますが、Runtime Environment自体にはRBACを設定できません。
次のような要件がある場合は、Runtime EnvironmentだけでなくAutomationアカウントの分離も検討します。
- 管理担当者ごとにアクセス権を完全に分けたい
- 認証主体や権限を独立させたい
- 障害や誤操作の影響範囲を分けたい
- 組織やシステムごとに厳格な運用境界が必要
- ネットワークやリージョンの構成を分けたい
判断基準は、違いがランタイムとモジュールだけならRuntime Environment、権限や運用境界まで異なるならAutomationアカウントです。
旧Runtime Environmentをすぐ削除する
削除したRuntime Environmentは復元できません。移行直後に旧環境を削除すると、問題発生時にすぐロールバックできなくなります。(Microsoft Learn)
少なくとも次の確認が終わるまでは残しておくのが安全です。
- スケジュール実行が正常に完了した
- Webhookや親Runbookから正常に起動できた
- Hybrid Runbook Workerでも動作した
- 出力データや更新結果が正しい
- 警告やエラーが増えていない
グラフィカルRunbookにも同じ方法を適用する
PowerShell Workflow、Graphical PowerShell、Graphical PowerShell Workflowは、システム生成のPowerShell 5.1 Runtime Environmentでのみ動作します。通常のテキスト形式のPowerShell Runbookと同じように、新しいPowerShell 7系Runtime Environmentへ切り替えられるとは限りません。(Microsoft Learn)
既存のグラフィカルRunbookを新しいランタイムへ移したい場合は、テキスト形式のPowerShell Runbookとして処理を再実装する必要がないか確認してください。
公式ドキュメントのGA表記とバージョン差に注意する
Azure Update 568102は2026年7月30日に公開され、Runtime Environment GAを含む更新として登録されています。一方、Microsoft Learnの「What’s new in Azure Automation」には、Runtime EnvironmentのGAが2025年6月の項目にも掲載されています。
そのため、「Runtime Environmentが初めてGAになった日」を示す場合は、2026年7月30日と断定するより、次のように表現するのが正確です。
2026年7月30日公開のAzure Update 568102で、PowerShell 7.6対応とともにRuntime EnvironmentのGAが改めて案内された。
また、PowerShell 7.6の一般提供後も、一部のMicrosoft LearnページにはPowerShell 7.4を前提とした手順や既定パッケージの記述が残っています。実際に利用できるランタイムやパッケージ版については、Azureポータルに表示される内容と最新のAzure Updateを併せて確認してください。
まず行うべき作業
Azure Automation Runtime Environmentを導入する際は、最初からすべてのRunbookを切り替える必要はありません。
まず、Automationアカウント内のRunbookを、次の3種類に分けます。
| 分類 | 対応 |
|---|---|
| 現在もサポートされるランタイムで問題なく動作 | 現状維持し、依存関係だけ記録 |
| 競合するモジュール版を使用 | Runtime Environmentを分離 |
| PowerShell 7.1／7.2、Python 2.7／3.8を使用 | サポート対象ランタイムへの移行を優先 |
そのうえで、検証用Runtime Environmentを作成し、Test Paneで確認してから本番Runbookを切り替えます。
特に2026年9月30日にサポート終了予定のランタイムを使っている場合は、Runbook名、ランタイム、モジュール、実行スケジュールを一覧化することが最初の作業です。Runtime Environmentを依存関係の境界として活用すれば、Automationアカウントを増やしすぎず、旧Runbookと新しいRunbookを段階的に共存させられます。
コメント