Windows 管理者が今回の「Exchange PowerShell」更新で最初に確認すべきことは、利用している接続方式と実行環境です。特に、Exchange Online PowerShell モジュール 3.10.0 以降では PowerShell 7 の要件が上がり、2026年7月以降に公開されるモジュールでは -Credential パラメーターの扱いが変わるため、古い自動化スクリプトは早めに棚卸しが必要です。Exchange PowerShell は単なるコマンド実行ツールではなく、Exchange Online、Security & Compliance PowerShell、オンプレミス Exchange Server の運用を自動化する管理基盤です。この記事では、2026年6月25日に公開または更新された公式情報をもとに、影響範囲、設定変更、移行期限、管理者が確認すべきポイントを実務目線で整理します。
Windows の新機能・変更点：「Exchange PowerShell」で確認すべきポイント
Exchange PowerShell は、PowerShell 技術をベースにした Exchange 管理用のコマンドライン インターフェイスです。メールボックス、メールフロー、セキュリティ設定、コンプライアンス関連の操作を GUI ではなくコマンドで実行できるため、大量変更、定期レポート、自動化、監査対応に向いています。公式リファレンスでは、Exchange Server PowerShell、Exchange Online PowerShell、Security & Compliance PowerShell、オンプレミス メールボックス向けの組み込みセキュリティ アドオン用 PowerShell が利用可能な環境として示されています。クラウド環境では PowerShell Gallery の ExchangeOnlineManagement モジュールを使い、Exchange Server では Exchange Management Shell、管理ツールのみをインストールした端末、または Windows PowerShell からのリモート PowerShell 接続を使う構成です。(Microsoft Learn)
今回のポイントは、「Exchange PowerShell そのものが急に別物になる」というより、Exchange Online PowerShell モジュールの実行条件と認証方式の見直しが進んでいる点です。Exchange Online PowerShell モジュールは、Exchange Online PowerShell、Security & Compliance PowerShell、オンプレミス メールボックス用の組み込みセキュリティ アドオン向け PowerShell に接続するためのモジュールで、最新の認証と MFA を前提にしています。(Microsoft Learn)
2026年6月時点で重要な更新内容
Exchange Online PowerShell モジュールの最新リリースとして、2026年6月にバージョン 3.10.0 が案内されています。PowerShell Gallery では 3.10.0 が current version として掲載され、Last Published は 2026年6月8日です。リリースノートでは、PowerShell 7 の最低要件が 7.6 に引き上げられたこと、Connect-IPPSSession で -EnableSearchOnlySession を使用した際の証明書ベース認証の問題修正が示されています。(Microsoft Learn)
| 確認項目 | 変更・注意点 | 管理者が取るべき対応 |
|---|---|---|
| ExchangeOnlineManagement 3.10.0 | PowerShell 7 の最低要件が 7.6 に変更。Windows PowerShell 5.1 は影響なし | PowerShell 7.4 などで運用している端末・Runbook・管理サーバーを確認 |
Connect-IPPSSession | -EnableSearchOnlySession 使用時の証明書ベース認証の問題を修正 | eDiscovery や Purview 関連の自動化で IPPS 接続を使う場合はテスト |
| REST API 接続 | Exchange Online PowerShell と Security & Compliance PowerShell では REST API 接続が標準化 | WinRM の基本認証や RPS 前提の古い手順を見直す |
-Credential パラメーター | 2026年7月以降に公開されるモジュールで削除予定 | 資格情報を渡す自動化を、MFA、証明書ベース認証、マネージド ID に移行 |
| コマンドライン ヘルプ | 3.7.0 以降、Exchange Online PowerShell コマンドレットのヘルプは既定で読み込まれない | 必要時は Connect-ExchangeOnline -LoadCmdletHelp を使う |
REST API 接続は、従来のリモート PowerShell セッションに依存しないため、セキュリティ、信頼性、パフォーマンスの面で利点があります。公式ドキュメントでは、REST API 接続では WinRM の基本認証が不要で、一時的なエラーには組み込みの再試行が使われると説明されています。(Microsoft Learn)
影響範囲：どの Windows 環境を確認すべきか
影響を受けやすいのは、管理者の作業端末、ジャンプサーバー、Azure Automation、運用監視サーバー、タスクスケジューラで Exchange Online PowerShell を実行している Windows 環境です。特に、PowerShell 7 を使っている場合は、モジュール更新だけでなく PowerShell 本体のバージョンも確認する必要があります。
Windows 11、Windows Server 2022、Windows Server 2025 では、ExchangeOnlineManagement 3.10.0 以降を PowerShell 7 で使う場合、PowerShell 7.6.0 以降が必要です。一方、Windows PowerShell 5.1 については、ExchangeOnlineManagement 3.10.0 のリリースノート上では影響なしとされています。(Microsoft Learn)
| 環境 | 確認すべき点 | 実務上の注意 |
|---|---|---|
| Windows 11 管理端末 | PowerShell 7.6 以上か、Windows PowerShell 5.1 で運用しているか | 端末ごとにモジュールのインストール場所が異なることがある |
| Windows Server 2022 / 2025 | 自動実行ジョブの PowerShell バージョン | サーバー上のスケジュールタスクは古い pwsh.exe を参照している場合がある |
| Windows Server 2016 / 2019 | PowerShell 7.6 以上への更新可否 | 古いサーバーでは .NET や実行ポリシーも合わせて確認 |
| Windows 10 | エディションとサポート状況 | PowerShell 7 と新しい .NET のサポート範囲に注意 |
| Azure Automation / Azure VM | 実行ランタイム、モジュールバージョン、認証方式 | マネージド ID 化する場合はロール付与までセットで確認 |
Windows 10 では、PowerShell 7 と新しい .NET のサポート範囲がエディションによって制限されます。公式情報では、Windows 10 コンシューマー エディションは 2025年10月にサポート終了に達し、.NET 8.0 または .NET 10.0 はサポートされていないとされています。運用端末が Windows 10 の場合は、単にモジュールを更新するだけでなく、OS のサポート状態も確認してください。(Microsoft Learn)
移行期限：-Credential を使うスクリプトは2026年7月前に見直す
自動化スクリプトで最も注意したいのが、Connect-ExchangeOnline -Credential や Connect-IPPSSession -Credential を使っているケースです。Microsoft は、2026年7月以降にリリースされる Exchange Online PowerShell モジュールで -Credential パラメーターのサポートを外す方針を示しています。該当するスクリプトは、モジュールを更新したタイミングで失敗する可能性があります。(TECHCOMMUNITY.MICROSOFT.COM)
古い書き方の例は次のようなものです。
$cred = Get-Credential
Connect-ExchangeOnline -Credential $credこの方式は、ユーザー名とパスワードに依存するため、MFA や条件付きアクセスと相性が悪く、グローバル企業のセキュリティ要件にも合いにくくなっています。今後は、用途に応じて次の認証方式へ移行するのが現実的です。
| 利用シーン | 推奨される接続方式 | 使いどころ |
|---|---|---|
| 管理者が手動で作業する | 対話型サインイン、MFA | 一時的な調査、設定変更、障害対応 |
| オンプレミスや管理サーバーで自動実行する | アプリ専用認証、証明書ベース認証 | 定期レポート、棚卸し、夜間バッチ |
| Azure Automation や Azure VM で自動実行する | マネージド ID | 証明書やシークレットを持たせたくない自動化 |
| CSP / GDAP で顧客テナントを管理する | -DelegatedOrganization などを組み合わせる | 複数テナント管理、運用代行 |
対話型接続では、次のように Connect-ExchangeOnline を使います。公式ドキュメントでは、MFA の有無にかかわらず Windows PowerShell 5.1 と PowerShell 7 で動作する例として案内されています。(Microsoft Learn)
Connect-ExchangeOnline -UserPrincipalName [email protected]接続後は、低リスクなコマンドで接続確認を行います。
Get-AcceptedDomain | Format-Table Name,DomainNameエラーが出なければ接続は成功です。公式ドキュメントでも、Get-AcceptedDomain などの Exchange Online PowerShell コマンドレットを実行して結果を確認する方法が示されています。(Microsoft Learn)
自動化スクリプトは「証明書ベース認証」か「マネージド ID」へ移行する
無人スクリプトでは、ユーザー資格情報をローカルファイルやシークレットに保存する方式を避けるべきです。Microsoft のドキュメントでは、証明書ベース認証、つまりアプリ専用認証を使うことで、Microsoft Entra アプリと証明書を利用した無人スクリプトや自動化をサポートできると説明されています。(Microsoft Learn)
証明書ベース認証の接続例は次の通りです。
Connect-ExchangeOnline `
-CertificateThumbPrint "012THISISADEMOTHUMBPRINT" `
-AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" `
-Organization "contoso.onmicrosoft.com"この方式では、Microsoft Entra ID にアプリを登録し、Office 365 Exchange Online の Exchange.ManageAsApp アプリケーション権限を付与し、証明書を構成します。さらに、実際に実行できるコマンドはロールベースアクセス制御、つまり RBAC によって制御されます。(Microsoft Learn)
Azure Automation や Azure VM で実行するなら、マネージド ID の方が管理しやすい場合があります。マネージド ID は、ローカル端末の Windows PowerShell セッションから使うものではなく、Azure Automation アカウントや Azure VM など、マネージド ID に関連付けられた Azure リソースのコンテキストで使います。(Microsoft Learn)
システム割り当てマネージド ID の例は次の通りです。
Connect-ExchangeOnline -ManagedIdentity -Organization contoso.onmicrosoft.comユーザー割り当てマネージド ID の例は次の通りです。
Connect-ExchangeOnline `
-ManagedIdentity `
-Organization contoso.onmicrosoft.com `
-ManagedIdentityAccountId <UserAssignedManagedIdentityClientIdValue>Azure 上で完結する自動化なら、マネージド ID を優先候補にしてください。証明書の期限切れ、秘密キーの保管、ローテーション手順を減らせるため、運用ミスを抑えやすくなります。ただし、マネージド ID にも Microsoft Entra ロールの割り当てが必要です。接続できても権限が不足していれば、コマンドレットやパラメーターは利用できません。(Microsoft Learn)
管理者が今すぐ実行すべき確認コマンド
まず、管理端末や自動実行環境で PowerShell と ExchangeOnlineManagement のバージョンを確認します。
$PSVersionTable.PSVersion
Get-InstalledModule ExchangeOnlineManagement | Format-List Name,Version,InstalledLocationインストール場所も重要です。%ProgramFiles%\WindowsPowerShell\Modules\ に入っていれば全ユーザー向け、Documents 配下であれば現在のユーザーのみのインストールです。複数の管理者が同じサーバーを使っている場合、ユーザーごとに異なるバージョンを読み込んでいることがあります。(Microsoft Learn)
未インストールまたは更新が必要な場合は、次のようにインストールまたは更新します。
Install-Module -Name ExchangeOnlineManagement -Scope CurrentUser
Update-Module -Name ExchangeOnlineManagementPowerShell の実行ポリシーでエラーが出る場合は、管理者権限の PowerShell で RemoteSigned を設定します。公式ドキュメントでは、スクリプト実行が無効な場合の対処として Set-ExecutionPolicy RemoteSigned が示されています。(Microsoft Learn)
Set-ExecutionPolicy RemoteSigned次に、古い接続方式を使っているスクリプトを検索します。
Get-ChildItem -Path . -Filter *.ps1 -Recurse |
Select-String -Pattern 'Connect-ExchangeOnline|Connect-IPPSSession|-Credential|UseRPSSession'特に -Credential、UseRPSSession、古い RPS 前提の処理、パスワードをファイルから読み込む処理が見つかった場合は、移行対象として管理台帳に登録してください。ExchangeOnlineManagement 3.9.2 のリリースノートでは、Connect-ExchangeOnline と Connect-IPPSSession の UseRpsSession パラメーターが非推奨になったことも示されています。(Microsoft Learn)
グローバル環境で注意したい接続先の違い
グローバル企業では、商用 Microsoft 365 だけでなく、GCC、GCC High、DoD、21Vianet 運営の Microsoft 365 などを扱う場合があります。商用 Microsoft 365 や Microsoft 365 GCC では通常 ExchangeEnvironmentName を指定する必要はありませんが、GCC High や DoD では環境名の指定が必要です。(Microsoft Learn)
| 環境 | 接続例 | 注意点 |
|---|---|---|
| Microsoft 365 / Microsoft 365 GCC | Connect-ExchangeOnline -UserPrincipalName [email protected] | 既定値で接続できることが多い |
| Microsoft GCC High | Connect-ExchangeOnline -UserPrincipalName [email protected] -ExchangeEnvironmentName O365USGovGCCHigh | 政府クラウド向けの接続先を明示 |
| Microsoft 365 DoD | Connect-ExchangeOnline -UserPrincipalName [email protected] -ExchangeEnvironmentName O365USGovDoD | DoD 用の接続先を明示 |
| 21Vianet 中国 | Connect-ExchangeOnline -ExchangeEnvironmentName O365China | 追加パラメーターや接続先 URI の確認が必要 |
運用標準書を作る場合は、「どのテナントに、どの認証方式で、どの環境名を指定して接続するか」を明記しておくと、障害対応時のミスを減らせます。
設定変更で失敗しやすいポイント
PowerShell 7 だけ更新してモジュール要件を見落とす
ExchangeOnlineManagement 3.10.0 以降を PowerShell 7 で使うなら、PowerShell 7.6 以上が必要です。PowerShell 7.4 のままモジュールだけ更新すると、検証環境では動いていたスクリプトが本番の自動実行環境で失敗することがあります。モジュール更新の前に、実行環境単位で PowerShell バージョンを確認してください。(Microsoft Learn)
PowerShellGet と PackageManagement の状態を見ない
Windows の REST API 接続には PowerShellGet が必要で、依存関係として PackageManagement も必要です。公式ドキュメントでは、プレビュー版の PackageManagement または PowerShellGet があると接続問題が発生する可能性があるため、Get-InstalledModule PackageManagement -AllVersions; Get-InstalledModule PowerShellGet -AllVersions で確認するよう案内されています。(Microsoft Learn)
Get-InstalledModule PackageManagement -AllVersions
Get-InstalledModule PowerShellGet -AllVersionsRBAC を「接続の問題」と誤解する
Exchange Online PowerShell は接続できても、RBAC によって実行できるコマンドレットやパラメーターが制御されます。接続は成功しているのに特定の操作だけ失敗する場合、モジュールやネットワークではなく、管理ロールの不足が原因のことがあります。(Microsoft Learn)
PropertySets All で大量取得する
Get-EXOMailbox などの Get-EXO 系コマンドレットは、必要なプロパティだけを取得できるように設計されています。公式ドキュメントでは、PropertySets All で全プロパティを取得する方法は処理速度が遅くなり信頼性も下がるため推奨されていません。必要なプロパティを PropertySets または Properties で明示するのが安全です。(Microsoft Learn)
悪い例です。
Get-EXOMailbox -ResultSize Unlimited -PropertySets All必要な項目だけ取得する例です。
Get-EXOMailbox -ResultSize Unlimited -Properties DisplayName,PrimarySmtpAddress,RecipientTypeDetailsローカル証明書の扱いを軽視する
証明書ベース認証へ移行する場合、証明書の秘密キーを誰が管理するか、期限切れをどう検知するか、更新時にどのジョブを止めるかまで決めておく必要があります。公式ドキュメントでも、証明書ファイルのパスワードをローカルに保存することは、自動化シナリオの安全な接続方法の目的を損なうと注意されています。(Microsoft Learn)
実務で使える移行チェックリスト
Exchange PowerShell の更新対応は、単にモジュールを最新版にする作業ではありません。次の順番で進めると、影響範囲を把握しながら安全に移行できます。
| 順番 | 作業 | 完了条件 |
|---|---|---|
| 1 | 管理端末・サーバー・Runbook を棚卸し | 実行場所、PowerShell バージョン、モジュールバージョンが一覧化されている |
| 2 | スクリプト内の接続方式を検索 | -Credential、UseRPSSession、パスワード読み込み処理を抽出済み |
| 3 | 認証方式を決定 | 対話型、証明書ベース認証、マネージド ID のどれを使うか決定済み |
| 4 | 検証環境でモジュール更新 | PowerShell 7.6 以上または Windows PowerShell 5.1 で接続確認済み |
| 5 | RBAC を確認 | 必要なコマンドレットとパラメーターが実行できる |
| 6 | 本番スクリプトを修正 | -Credential 依存を解消済み |
| 7 | 障害時の切り戻しを準備 | 旧モジュール、旧スクリプト、実行ログの保管方針が明確 |
| 8 | 運用標準書を更新 | 接続方法、証明書更新、マネージド ID のロール管理が文書化済み |
特にグローバル企業では、テナントごと、地域ごと、運用委託先ごとに接続方式が混在しがちです。「管理者個人の端末では動くが、自動化環境では失敗する」という状態を避けるため、接続方式を標準化し、例外は理由付きで管理してください。
まとめ：まずは接続方式と実行環境の棚卸しから始める
Windows 環境で Exchange PowerShell を使っている管理者は、2026年6月時点の更新を「モジュール更新」「PowerShell 7 要件」「認証方式の移行」の3点で確認する必要があります。ExchangeOnlineManagement 3.10.0 以降では PowerShell 7.6 以上が必要になり、Windows PowerShell 5.1 は影響を受けません。さらに、2026年7月以降のモジュールでは -Credential パラメーターの削除が予定されているため、資格情報ベースの自動化は早めに見直すべきです。(Microsoft Learn)
次に取るべき行動は明確です。まず、すべての管理端末、サーバー、Runbook で ExchangeOnlineManagement のバージョンと PowerShell バージョンを確認してください。次に、スクリプトから -Credential と UseRPSSession を検索し、対話型サインイン、証明書ベース認証、マネージド ID のいずれかへ移行計画を作ります。最後に、RBAC、PowerShellGet、PackageManagement、実行ポリシー、接続先クラウド環境まで含めて検証すれば、Exchange PowerShell の更新に伴う停止リスクを大きく減らせます。
コメント