Azure AutomationでPython 2.7／3.8、PowerShell 7.1／7.2のRunbookを運用している場合、2026年9月30日までに、PowerShellは7.4、Pythonは3.10へ移行するのが基本方針です。MicrosoftのAzure Update 567556では、これらの旧runtimeが2026年9月30日にretirementとなり、2026年10月1日からunsupportedになる予定が示されています。(Microsoft Azure)
ただし、Runbookのruntime設定だけを変更しても、安全な移行にはなりません。Runtime Environmentに登録するPowerShellモジュールやPythonパッケージ、マネージドIDなどの認証方法、スケジュール・Webhook・親子Runbookの呼び出し関係まで確認する必要があります。
2026年10月1日以降も、旧runtimeのRunbookが直ちにすべて停止するとは限りません。しかし、Microsoftのサポートポリシー上はreduced-supportとなり、新機能、セキュリティ更新、パフォーマンス最適化の対象外です。状況によってはスケーリングも制限されるため、「動く間は使う」という判断は避け、期限前に本番切り替えまで完了させる必要があります。(Microsoft Learn)
旧runtimeの期限と移行先
対象となるruntimeと、基本的な移行先は次のとおりです。
| 現在のruntime | 基本的な移行先 | 主な確認ポイント | 移行難易度の目安 |
|---|---|---|---|
| PowerShell 7.1 | PowerShell 7.4 | Azモジュール、外部モジュール、出力オブジェクト、認証 | 中 |
| PowerShell 7.2 | PowerShell 7.4 | モジュール依存関係、PowerShell 7.4固有の制約 | 中 |
| Python 2.7 | Python 3.10 | 構文、文字列とbytes、ライブラリ、SDKの全面的な見直し | 高 |
| Python 3.8 | Python 3.10 | パッケージ版、wheel互換性、非推奨API | 中 |
Azure AutomationのRuntime Environmentで現在選択できるサポート対象は、PowerShellが5.1または7.4、Pythonが3.10です。既存のPowerShell 7.1／7.2は原則として7.4へ、Python 2.7／3.8は3.10へ更新します。(Microsoft Learn)
PowerShell 5.1もサポート対象ですが、PowerShell 7.xのRunbookを安易に5.1へ戻すことは推奨できません。クロスプラットフォーム対応や.NET依存、モジュールの対応状況が変わり、かえって修正範囲が広がる可能性があるためです。Windows PowerShell専用モジュールが必要など、明確な理由がある場合だけ例外として検討します。
なお、PowerShell Workflow、Graphical PowerShell、Graphical PowerShell Workflowは、通常のPowerShell 7.4 Runbookと同じ方法では移行できません。これらはSystem-generated PowerShell 5.1 Runtime Environmentで動作するため、今回の棚卸しで見つかった場合は別案件として扱います。(Microsoft Learn)
2026年10月1日以降も動く可能性はあるが、運用継続は避ける
MicrosoftのAzure Automationランタイムサポートポリシーでは、retired runtimeを使用するRunbookについて、引き続き作成、デプロイ、実行できる場合があると説明されています。ただし、その状態は正式サポートではなく、次の制約を伴います。(Microsoft Learn)
- セキュリティ更新を受けられない
- 新機能が追加されない
- パフォーマンス最適化の対象にならない
- 問題や性能低下が発生する可能性がある
- 割り当て可能なインスタンス数が制限される場合がある
したがって、2026年9月30日は「移行作業を開始する日」ではなく、すべての本番Runbookが新runtimeで安定稼働しているべき最終期限です。社内期限は少なくとも2週間前に設定し、残りを監視とロールバック確認に充てるのが安全です。
最初にRunbookを棚卸しする
移行で最も危険なのは、Azure portalに表示されたRunbookだけを見て、順番にruntimeを変更する進め方です。
実際の影響範囲を把握するには、Runbook本体だけでなく、起動元、実行先、認証、モジュール、処理内容を一つの台帳にまとめます。
| 棚卸し項目 | 記録する内容 |
|---|---|
| Azure上の識別情報 | サブスクリプション、リソースグループ、Automationアカウント、Runbook名 |
| 現行実行環境 | Runbook type、Runtime Environment名、runtime version |
| モジュール・パッケージ | 名前、現在の版、移行先で使う版、依存パッケージ |
| 起動方法 | 手動、スケジュール、Webhook、Azure Monitor、Logic Apps、親Runbook |
| 実行先 | Azure sandbox、Hybrid Runbook Worker、Worker group |
| 認証方法 | システム割り当てマネージドID、ユーザー割り当てマネージドID、資格情報、証明書 |
| 操作対象 | サブスクリプション、VM、Storage、Key Vault、Microsoft Graphなど |
| 処理の危険度 | 読み取りのみ、作成・更新、停止、削除 |
| 運用情報 | 実行頻度、最終成功日時、担当者、障害時の代替手段 |
| 移行管理 | 移行先runtime、テスト結果、本番切り替え日、ロールバック方法 |
lastModifiedTimeはRunbookの最終更新日時であり、最終実行日時ではありません。「長期間更新されていないから未使用」と判断せず、ジョブ履歴、スケジュール、Webhook、親Runbookからの呼び出しも確認してください。
REST APIでRunbook一覧を取得する
Automationアカウント内のRunbook一覧は、Azure Automation REST APIの2024-10-23版から取得できます。応答にはRunbook type、Runtime Environment、公開状態、最終更新日時などが含まれます。(Microsoft Learn)
Azure Cloud Shellなどで、次のように実行します。
SUBSCRIPTION_ID="<subscription-id>"
RESOURCE_GROUP="<resource-group-name>"
AUTOMATION_ACCOUNT="<automation-account-name>"
az rest \
--method get \
--url "https://management.azure.com/subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Automation/automationAccounts/${AUTOMATION_ACCOUNT}/runbooks?api-version=2024-10-23" \
--query "value[].{Runbook:name,Type:properties.runbookType,Runtime:properties.runtimeEnvironment,State:properties.state,LastModified:properties.lastModifiedTime}" \
--output table結果を保存する場合は、最後を次のように変更します。
--output json > runbooks.json応答にnextLinkが含まれる場合は、次ページも取得しなければ一覧が欠落します。また、このAPIだけではスケジュール、Webhook、ジョブ履歴、親子関係までは分かりません。Azure portalとソースコード検索を併用してください。
Runtime Environmentのパッケージを一覧化する
特定のRuntime Environmentに登録されたモジュールやパッケージは、次のAPIで確認できます。
RUNTIME_ENVIRONMENT="<runtime-environment-name>"
az rest \
--method get \
--url "https://management.azure.com/subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${RESOURCE_GROUP}/providers/Microsoft.Automation/automationAccounts/${AUTOMATION_ACCOUNT}/runtimeEnvironments/${RUNTIME_ENVIRONMENT}/packages?api-version=2024-10-23" \
--query "value[].{Package:name,Version:properties.version,State:properties.provisioningState,Default:properties.default}" \
--output tableパッケージ一覧APIでは、パッケージ名、バージョン、プロビジョニング状態などを取得できます。(Microsoft Learn)
ただし、登録済みパッケージの一覧だけでは、どのRunbookがどのコマンドを利用しているかまでは分かりません。PowerShellではImport-Module、using module、使用しているコマンド名を、Pythonではimportとfrom ... import ...を検索し、実際の依存関係を台帳に追記します。
移行優先度を決める判断基準
すべてのRunbookを同時に移行すると、障害発生時に原因を切り分けにくくなります。次の基準で優先度を決めます。
| 優先度 | 該当するRunbook |
|---|---|
| 最優先 | 毎日実行、Webhook起動、VM停止やリソース削除を行う、業務停止につながる、代替手段がない |
| 通常 | 週次・月次処理、読み取り中心、手動で代替可能、影響範囲が限定的 |
| 廃止候補 | スケジュールなし、Webhookなし、親Runbookからの呼び出しなし、長期間ジョブ実績なし |
| 要個別対応 | PowerShell Workflow、Graphical Runbook、Hybrid Worker固有処理、ソース管理連携あり |
未使用Runbookは、無理に新runtimeへ移すより、コードと設定を保全したうえで廃止する方が安全です。移行対象を減らせるため、期限対応だけでなくAutomationアカウントの保守性も改善できます。
Runtime Environmentは依存関係ごとに分ける
Runtime Environmentは、runtimeの言語、バージョン、実行時に使用するパッケージをまとめて管理する仕組みです。1つのRunbookが関連付けられるRuntime Environmentは1つですが、1つのRuntime Environmentを複数のRunbookで共有できます。(Microsoft Learn)
ここで注意したいのが、Runtime Environment内のモジュールやパッケージを更新すると、関連付けられているすべてのRunbookへ新しい設定が反映される点です。(Microsoft Learn)
そのため、すべてのRunbookを1つの環境へまとめる設計は避けます。依存関係と更新サイクルが同じRunbookだけをグループ化します。
| Runtime Environment名の例 | 対象 |
|---|---|
ps74-az-core-v1 | Az.AccountsやAz.Resourcesを中心に使うRunbook |
ps74-graph-v1 | Microsoft Graph関連モジュールを使うRunbook |
ps74-exchange-v1 | Exchange Online関連Runbook |
py310-rest-v1 | HTTP API呼び出し中心のPython Runbook |
py310-azure-sdk-v1 | Azure SDK for Pythonを使うRunbook |
PowerShell 7.4にはSystem-generated Runtime Environmentが用意されないため、カスタムRuntime Environmentを作成する必要があります。Python 3.10についても、パッケージ版を固定して管理したい場合はカスタム環境を作る方が安全です。(Microsoft Learn)
モジュールを更新するときは既存環境を直接書き換えるのではなく、v2などの新環境を作成し、テスト後にRunbookを付け替える方法が適しています。これにより、問題が起きた場合は旧環境へ戻せます。
Runbookを安全に更新する手順
現行状態を保全する
最初に、現在公開されているコードと設定を保全します。
- Runbookの公開済みコード
- 入力パラメーターと既定値
- 現在のRuntime Environment
- モジュールとパッケージのバージョン
- スケジュールとWebhook
- 親子Runbookの呼び出し関係
- マネージドIDとRBACロール
- 正常実行時の出力と処理時間
特に、正常実行時の出力件数、対象リソースID、終了コードを保存しておくと、新旧runtimeの結果を比較しやすくなります。
サポート中のRuntime Environmentを作成する
Azure portalでAutomationアカウントを開き、次の順に操作します。
- 「Process Automation」から「Runtime Environments」を開く
- 「Create」を選択する
- PowerShellの場合は7.4、Pythonの場合は3.10を選ぶ
- Runbookが必要とするモジュールやパッケージを追加する
- パッケージのプロビジョニング完了を確認する
Runtimeの言語とバージョンは作成後に変更できません。一方、モジュールやパッケージは更新できます。(Microsoft Learn)
本番Runbookを直接変更せずにテストする
通常のRunbookでは、ポータルエディターで新しいRuntime Environmentを選択し、「Test pane」で実行してから公開できます。Microsoftも、Runtime Environmentを変更したRunbookを公開前にテストすることを推奨しています。(Microsoft Learn)
業務影響が大きいRunbookは、本番Runbookのコピーを作り、次のような名前で検証します。
Stop-NightlyVMs-ps74-test
Create-MonthlyReport-py310-testMicrosoftのマネージドID移行手順でも、本番Runbookを上書きしないよう、コピーを作って認証を検証する方法が推奨されています。(Microsoft Learn)
テスト用Runbookには、いきなり本番スケジュールや本番Webhookを接続しないでください。停止や削除を伴う処理は、テスト用サブスクリプション、テスト用リソースグループ、対象を限定するパラメーターなどを使って副作用を抑えます。
本番RunbookのRuntime Environmentを切り替える
テストに合格したら、本番RunbookのRuntime Environmentを変更して公開します。
既存のRunbook自体を更新すれば、Runbook名や紐付け先を変えずに移行できるため、スケジュールや親Runbookへの影響を抑えられます。Runtime Environmentは複数Runbookを選択して一括更新することもでき、変更時点ですでに実行中のジョブには影響しません。(Microsoft Learn)
ただし、一括更新は同じテスト結果を適用できるRunbook群に限定します。依存モジュールや認証方法が異なるRunbookまでまとめて切り替えないでください。
PowerShell 7.4でモジュール互換性を検証する
PowerShell Runbookでは、runtimeに対応したモジュールをRuntime Environmentへ登録する必要があります。PowerShell 7.4用として登録したモジュールはジョブ実行時に検証されるため、ポータル上でインポートが完了しただけでは互換性を確認したことになりません。依存モジュールが不足していれば、実行時に失敗します。(Microsoft Learn)
実際にロードされるモジュールを確認する
新しいRuntime Environmentへ関連付けたテストRunbookで、次のコードを実行します。
$ErrorActionPreference = "Stop"
Write-Output "PowerShell version:"
$PSVersionTable.PSVersion
Write-Output "Available modules:"
Get-Module -ListAvailable |
Sort-Object Name, Version |
Select-Object Name, Version, Path必要なモジュールだけを明示的に検証する場合は、次のようにします。配列内の名前はRunbookに合わせて変更してください。
$ErrorActionPreference = "Stop"
$requiredModules = @(
"Az.Accounts",
"Az.Resources",
"Az.Storage"
)
foreach ($name in $requiredModules) {
$module = Get-Module -ListAvailable -Name $name |
Sort-Object Version -Descending |
Select-Object -First 1
if (-not $module) {
throw "Required module not found: $name"
}
Import-Module $module.Path -Force -ErrorAction Stop
Write-Output "$($module.Name) $($module.Version)"
}PowerShellで確認すべき互換性
| 確認項目 | 失敗例 | 対応 |
|---|---|---|
| 依存モジュール | Import-Moduleで依存関係エラー | 依存モジュールもRuntime Environmentへ追加 |
| コマンドの存在 | コマンドが見つからない | 対象モジュールとバージョンを確認 |
| パラメーター | パラメーター名や型のエラー | 現行モジュールのコマンド仕様に合わせて修正 |
| 戻り値 | プロパティが存在しない | 新旧の出力オブジェクトを比較 |
| 内部パス | C:\modulesなどが見つからない | Azure内部パスへの依存を除去 |
| 子スクリプト | .\child-runbook.ps1が動かない | Start-AzAutomationRunbookなどでRunbookとして呼び出す |
| バックグラウンドジョブ | Start-Job -Credentialが失敗 | 対応する別の実行方法へ変更 |
| モジュール更新 | 複数Runbookが同時に失敗 | 新しいRuntime Environmentを作って段階移行 |
PowerShell 7.xではWorkflowと署名付きRunbookに制約があります。また、PowerShell 7.4はAzure AutomationのSource control integrationに対応しておらず、ソース管理から同期した7.4 Runbookが5.1として作成される制約も公式ドキュメントに記載されています。既存の同期運用を使っている場合は、ポータルまたはREST APIを含めたデプロイ経路を先に検証してください。(Microsoft Learn)
モジュールは単に「最新版」にするのではなく、テストに合格した版を記録して固定します。Runbookのコード変更とモジュールのメジャーアップデートを同時に行うと、障害原因の切り分けが難しくなります。
Python 3.10でパッケージ互換性を検証する
Python 2.7から3.10への移行では、単なるruntime変更ではなく、実質的なコード移植が必要です。
特に次の記述を検索します。
| Python 2.7で使われやすい記述 | Python 3.10での確認内容 |
|---|---|
print "text" | print("text")へ変更 |
unicode | strとbytesの使い分けを確認 |
dict.iteritems() | dict.items()へ変更 |
xrange() | range()へ変更 |
| 古い例外構文 | except Exception as e形式へ変更 |
/による整数除算 | 必要に応じて//へ変更 |
urllib2 | urllib.requestなどへ変更 |
| Python 2向けAzure SDK | Python 3.10対応SDKへ更新 |
Python 3.8から3.10の場合は、構文変更よりもパッケージ互換性が問題になりやすくなります。requirements相当の一覧を作り、利用している全パッケージの対応版を確認してください。
新しいRuntime Environmentでパッケージ版を確認する簡易コードは次のとおりです。
import sys
from importlib import metadata
print(f"Python: {sys.version}")
required_packages = (
"requests",
"azure-identity",
"azure-mgmt-resource",
)
for package in required_packages:
try:
version = metadata.version(package)
print(f"{package}=={version}")
except metadata.PackageNotFoundError as exc:
raise RuntimeError(f"Required package is missing: {package}") from excrequired_packagesは、実際のRunbookで使用するパッケージ名へ置き換えます。
Azure AutomationのPython 3.10カスタムパッケージは、公式ドキュメント上、cp310のLinux OSを対象としたwheelがサポート対象です。また、カスタムパッケージの互換性はジョブ実行時に検証されるため、依存パッケージの不足や非互換なwheelは実行時エラーになります。(Microsoft Learn)
Windows専用のバイナリを含むパッケージや、OSネイティブライブラリを必要とする処理は、Azure sandboxでは動作しない可能性があります。その場合は、Python 3.10を構成したHybrid Runbook Workerでの実行も検討します。
認証とRBACをruntime移行と同時に確認する
runtimeとモジュールの読み込みに成功しても、認証先やRBACが正しくなければRunbookは完了しません。
特に、コード内に次の記述が残っていないか確認します。
AzureRunAsConnection
Get-AutomationConnection
CertificateThumbprint
Add-AzureRmAccount
Connect-AzureRmAccountAzure AutomationのRun Asアカウントは2023年9月30日にretirementとなり、マネージドIDへ置き換えられています。旧Run As接続を参照するRunbookが残っている場合は、今回のruntime移行と合わせて修正対象にします。(Microsoft Learn)
システム割り当てマネージドIDの接続例
$ErrorActionPreference = "Stop"
# 別ジョブのAzContextを引き継がないようにする
Disable-AzContextAutosave -Scope Process
# Automationアカウントのシステム割り当てマネージドIDで接続
$AzureContext = (Connect-AzAccount -Identity).Context
# 対象サブスクリプションを明示
$AzureContext = Set-AzContext `
-SubscriptionName $AzureContext.Subscription `
-DefaultProfile $AzureContext
Write-Output $AzureContextこれはMicrosoft公式ドキュメントで案内されている接続方法です。ユーザー割り当てマネージドIDを使用する場合は、Connect-AzAccount -Identity -AccountId "<client-id>"のように対象IDを指定します。(Microsoft Learn)
認証テストでは、Connect-AzAccountが成功したことだけを合格条件にしてはいけません。実際にRunbookが行う操作を、最小権限の範囲で確認します。
- 対象サブスクリプションを取得できるか
- 対象リソースを読み取れるか
- VMの開始・停止など必要な更新操作ができるか
- Key VaultやStorageなど、対象サービスへのアクセスができるか
- 別サブスクリプションを誤って操作していないか
- ユーザー割り当てIDとシステム割り当てIDを取り違えていないか
読み取りテストだけで、停止、更新、削除を行う本番Runbookの権限を検証したことにはなりません。実際の操作に近いテスト用リソースを用意してください。
Hybrid Runbook Workerは別途runtimeを準備する
Hybrid Runbook Workerで実行するRunbookは、Azure側のRuntime Environmentを変更するだけでは移行できません。
現行の公式要件では、PowerShell 7.4とPython 3.10は、Windows・LinuxともにExtension-based Hybrid Runbook Workerでサポートされます。(Microsoft Learn)
| Worker OS | 必要なExtensionの最低版 | 追加作業 |
|---|---|---|
| Windows | 1.3.63以上 | PowerShell 7.4またはPython 3.10をインストールし、実行ファイルのパスを設定 |
| Linux | 1.1.23以上 | PowerShell 7.4またはPython 3.10をインストールし、実行ファイルのパスを設定 |
PowerShell 7.4ではpowershell_7_4_path、Python 3.10ではpython_3_10_pathという環境変数をWorker側に設定します。設定後はHybrid Runbook Workerの再起動が必要です。(Microsoft Learn)
Hybrid Workerでは、次の項目も確認します。
- Worker extensionのバージョン
- PowerShellまたはPythonの実体が存在するか
- 環境変数のパスが正しいか
- ローカルモジュールやOS依存ライブラリ
- プロキシ、DNS、ファイアウォール
- ファイル共有やオンプレミスサーバーへの接続
- 実行アカウントのローカル権限
- Worker groupを指定した実行
クラウドのTest paneだけで成功しても、Hybrid Worker上で成功するとは限りません。最終テストは本番と同じWorker group、ネットワーク経路、認証方式で実施します。
本番切り替え前のテスト項目
テストは「ジョブがCompletedになったか」だけでは不十分です。新旧runtimeの出力と副作用を比較します。
| テスト | 合格基準 |
|---|---|
| runtime確認 | PowerShell 7.4またはPython 3.10で実行されている |
| パッケージ確認 | 必要なモジュールが指定版で読み込まれる |
| 認証確認 | 意図したマネージドIDとサブスクリプションを使用している |
| 読み取り処理 | 旧runtimeと件数、ID、値が一致する |
| 更新処理 | テスト用リソースに対して期待した変更だけが行われる |
| 冪等性 | 同じ処理を2回実行しても二重作成や重複通知が発生しない |
| エラー処理 | 権限不足、対象なし、429、5xxなどを適切に処理できる |
| パラメーター | 手動、スケジュール、Webhook、親Runbookの各経路で正しく渡る |
| 出力互換性 | 後続処理が参照するプロパティ名や形式が変わっていない |
| 性能 | 実行時間やメモリ使用量が許容範囲に収まる |
| ログ・監視 | エラー、警告、Job output、アラートが確認できる |
| Hybrid Worker | 本番相当のWorker groupで正常終了する |
破壊的な処理では、対象を1件に限定するパラメーターやテストモードを用意します。対応するコマンドであれば-WhatIfも有効ですが、すべてのコマンドが実際の処理を完全に再現するわけではありません。
よくある失敗と回避策
| 失敗しやすい進め方 | 問題 | 回避策 |
|---|---|---|
| runtimeだけ変更する | モジュールや認証で実行時エラーになる | Runtime Environment、依存関係、認証を一体で検証 |
| 共有環境のモジュールを直接更新する | 複数Runbookが同時に影響を受ける | v2環境を作り、Runbookを段階的に付け替える |
| 全モジュールを最新版にする | コマンドや戻り値が同時に変わる | テスト済みバージョンを固定する |
| ログイン成功だけで認証テストを終える | 実操作時にRBACエラーになる | 読み取りと更新の両方をテストする |
| Test paneだけで完了とする | WebhookやHybrid Worker固有の問題を見逃す | 実際のトリガーと実行先でも確認する |
| 最終日に一括切り替えする | ロールバックと原因切り分けができない | 優先度別に段階移行し、2週間以上の余裕を残す |
| 更新日時だけで未使用と判断する | 現役Runbookを誤って廃止する | ジョブ履歴、スケジュール、Webhook、呼び出し元を確認する |
| 10月1日以降も動く前提で延期する | セキュリティ更新と正式サポートを失う | 9月中旬を社内切り替え期限にする |
2026年9月30日までの推奨スケジュール
2026年7月から着手する場合は、次のように公式期限より前へ社内期限を設定します。
| 推奨期限 | 完了させる作業 |
|---|---|
| 2026年7月31日 | AutomationアカウントとRunbookの全件棚卸し、優先度決定 |
| 2026年8月14日 | PowerShell 7.4／Python 3.10環境作成、パッケージ登録 |
| 2026年8月31日 | 最優先Runbookの本番切り替え |
| 2026年9月15日 | 使用中の全Runbookを新runtimeへ切り替え |
| 2026年9月25日 | 旧runtime残存ゼロの確認、監視、ロールバック手順確認 |
| 2026年9月30日 | Microsoftのretirement期限 |
工程が遅れている場合も、モジュール検証、認証テスト、実トリガー確認を省略して一括切り替えするのは危険です。処理件数が多い場合は、まず業務影響の大きいRunbookを新runtimeへ移し、未使用Runbookを廃止して対象数を減らします。
期限前に完了させるべき最終確認
Azure Automation旧runtimeの移行先は、PowerShell 7.1／7.2からPowerShell 7.4、Python 2.7／3.8からPython 3.10です。
実務では、次の状態になって初めて移行完了と判断します。
- 使用中Runbookがすべてサポート中runtimeに関連付けられている
- 必要なモジュールとパッケージのバージョンが記録されている
- マネージドIDとRBACを実操作で検証している
- スケジュール、Webhook、親子Runbookから正常に起動できる
- Hybrid Workerを使う場合はWorker側のruntimeも更新済み
- 新旧の出力と処理結果を比較している
- 問題発生時に以前のRuntime Environmentへ戻せる
- 旧runtime上で実行される本番Runbookがゼロになっている
最初に行うべき作業は、REST APIまたはAzure portalでRunbook一覧を出し、Python 2.7、Python 3.8、PowerShell 7.1、PowerShell 7.2を使用しているRunbookへ担当者と優先度を付けることです。その後、依存関係の少ないRunbookを1本選び、PowerShell 7.4またはPython 3.10のRuntime Environmentでパイロット移行を実施してください。
コメント