Microsoft 365 Business Premium でメール暗号化や IRM を試そうとして、「RMS テンプレートが空」「Connect-AipService がどうしても通らない」という壁にぶつかるケースが 2024 年頃から急増しました。本記事では、実際に発生したサービス側の不具合や MFA・PowerShell の相性問題を踏まえつつ、Azure Information Protection(AIP)の保護サービスを確実に有効化し、Exchange の RMS テンプレートが表示されるところまでを、実務目線で丁寧に解説します。
AIP 保護サービスの有効化に失敗する典型的なケース
よくあるシナリオ
まずは、実際に多く報告されているパターンを整理します。
- サブスクリプション:Microsoft 365 Business Premium(試用テナントを含む)
- やりたいこと:Exchange のトランスポート ルールで「メッセージの暗号化」を設定したい
- 現象:ルール作成画面で RMS テンプレートのドロップダウンが空
- 対処として:
- AIP の「保護サービスを有効化(Activate)」が必要と判断
- PowerShell で
Connect-AipServiceを実行するが、サインイン画面が出ない/認証エラーで失敗
- 試したこと:
- AipService モジュール v3.0.0.1(2024 年 1 月公開)に更新、もしくは v2 系/v1 系へダウングレード
- Windows PowerShell 5.1 と PowerShell 7 の両方で試行
- しかし、どの組み合わせでも
Connect-AipServiceが失敗 - 別テナントでは成功しているため、テナント依存の問題に見える
この現象は、2024 年 1 月頃に新規テナントで特に多く報告され、Microsoft Q&A でも「30 日試用の M365 Business Premium で RMS テンプレートが空」「Connect-AipService がどの環境からも失敗する」といった投稿が相次ぎました。
Azure Information Protection / Azure Rights Management の現在地
用語整理:AIP と Azure Rights Management
Exchange の RMS テンプレートやメール暗号化を支えているのが、Azure Rights Management(Azure RMS)と呼ばれる暗号化サービスです。現在は Microsoft Purview Information Protection の一部として提供されており、旧称が Azure Information Protection(AIP)という位置づけになっています。
この Azure Rights Management サービスの有効化・状態確認に使うのが AipService PowerShell モジュール です。AipService は、さらに古い AADRM モジュールの後継として提供されており、AADRM はすでにサポート終了となっています。
関連 PowerShell モジュールの整理
| モジュール名 | 主な用途 | 状態 | 補足 |
|---|---|---|---|
| AADRM | 旧 Azure Rights Management 管理 | 廃止(サポート終了) | AipService に置き換え済み |
| AipService | Azure Rights Management(AIP 保護サービス)管理 | 現役 | Connect-AipService / Enable-AipService などを提供 |
| AzureInformationProtection | クライアント側ラベリング/保護(旧クライアント) | 非推奨 | PurviewInformationProtection に置き換え |
| PurviewInformationProtection | 新しい情報保護クライアント管理 | 新世代 | ラベル/ポリシー管理に使用 |
つまり、RMS テンプレートやメール暗号化のために「保護サービスを有効化する」場合、いまも AipService モジュール + Connect-AipService / Enable-AipService という流れ自体は有効です。
自動有効化と手動有効化
現在の Microsoft 365 では、Exchange Online を含む多くのサブスクリプション(特に 2018 年 2 月末以降に取得したもの)では、Azure Rights Management サービスは 自動的に有効化 されるのが基本です。
しかし、以下のようなケースでは、依然として Enable-AipService による手動有効化が必要になることがあります。
- 過去に一度 RMS を無効化しているテナント
- Exchange 以外のワークロードから先に構成したため、自動有効化が走らなかったテナント
- サービス側の不具合で自動有効化が正常に完了しなかった新規テナント(今回のテーマ)
なぜ Connect-AipService が失敗したのか:原因の整理
サービス側の不具合(2024 年 1 月〜2 月初旬)
2024 年 1 月後半、新規に作成したテナントで Connect-AipService がことごとく失敗する事象が Microsoft Q&A や GitHub issue で多数報告されました。
- エラー内容は概ね共通:
The attempt to connect to the Azure Information Protection service failed. Verify that the credentials you are using are correct ...- Verbose 出力では
The attempt to discover the location of the administration service and organization failed.などのメッセージ
- 別のテナントでは同じアカウント/PC でも正常に接続できる
- 複数のユーザーが「新規テナントでのみ再現する」と報告
この件について Microsoft 側の担当エンジニアから「RMS チームが原因を特定し、Connect-AipService が失敗する不具合に対して修正を展開した」とのコメントが 2024-02-01 付けで投稿されており、その後は同じテナントで正常に接続できるようになったと報告されています。
したがって、2024 年 1 月当時に発生した一連の接続失敗は、テナント設定ではなくサービス側(RMS バックエンド)の不具合が主要因 だったと言えます。
MFA(多要素認証)とレガシー認証フローの相性問題
前述の不具合と前後して、次のような報告も相次ぎました。
- グローバル管理者アカウントで MFA(条件付きアクセス含む)が有効になっていると
Connect-AipServiceが失敗する - 同じアカウントで、MFA を一時的に無効化したところ、
Connect-AipService→Enable-AipServiceまで通るようになった - MSOnline モジュールを使い、次のように
Set-MsolUser -StrongAuthenticationRequirements @()を実行した事例が複数報告
Import-Module MSOnline
Connect-MsolService
Set-MsolUser -UserPrincipalName [email protected] `
-StrongAuthenticationRequirements @()
このことから、多くの環境では Connect-AipService がレガシーな認証フロー に依存しており、条件付きアクセスや MFA 設定との組み合わせによっては認証に失敗することがわかります。
もちろん、MFA を恒久的に無効化するのは NG ですが、以下のような前提を守れば「短時間のワークアラウンド」として現実的な選択肢になりえます。
- 作業専用の全体管理者アカウントを用意する
- 作業時間を最小限にする(数分〜十数分程度)
- 完了後、すぐに MFA / 条件付きアクセスを元に戻す
実行環境(PowerShell)の相性
AipService モジュールは公式に Windows PowerShell(フル .NET Framework)でのみサポート されており、PowerShell 7+ はサポート対象外です。
また、Microsoft Q&A では「PowerShell ISE からの Connect-AipService が失敗し、同じマシンの PowerShell コンソールからは成功する」という報告もあり、ISE での利用は避けるのが無難です。
| 実行環境 | サポート可否 | コメント |
|---|---|---|
| Windows PowerShell 5.1(x64) | ◯(推奨) | 管理者として実行 |
| Windows PowerShell ISE | ✕(非推奨) | 接続失敗の事例あり |
| PowerShell 7.x(pwsh) | ✕(サポート外) | .NET 6/7 ベースで動作仕様が異なる |
権限・ロール不足
Connect-AipService で接続し、Enable-AipService を実行するには、少なくとも以下のいずれかのロールが必要です。
- 全体管理者(グローバル管理者)
- コンプライアンス管理者
- コンプライアンス データ管理者 など
ただし、実務的には「全部入り」である全体管理者を使った方が、ロール不足によるエラー切り分けが不要なためスムーズです。(本番では作業専用の全体管理者アカウントを用意するのがおすすめです)
いまどうすべきか:結論と方針
ここまでを踏まえると、以下のように整理できます。
- 2024 年 1 月〜初旬にかけての大規模な接続失敗は、RMS 側の不具合が主因 であり、Microsoft が 2024-02-01 までに修正を展開した。
- それでもなお一部環境で接続が不安定なのは、主に
- MFA/条件付きアクセスとの相性
- PowerShell 実行環境(ISE や PowerShell 7)
- テナント固有の問題
したがって、実務的な対応としては次の 2 段構えが有効です。
- 推奨ワークフローでまず自力で有効化を試みる
→ 本記事で紹介する「PowerShell 5.1 + MFA 一時無効化 +Connect-AipService+Enable-AipService+Set-IRMConfiguration」を実施 - それでもダメなら Microsoft サポートにエスカレーション
→Connect-AipService -Verbose実行時の相関 ID(Correlation ID)・時刻・テナント情報を添付して問い合わせ
すぐ効くワークアラウンド:MFA を一時的に外して有効化する手順
ここからは、実際の作業手順を具体的に示します。ポイントは次の 3 つです。
- 全体管理者アカウントを 一時的に MFA 無効 にする(MSOnline モジュール利用)
- Windows PowerShell 5.1(管理者)から
Connect-AipService→Enable-AipService - Exchange Online 側で
Set-IRMConfiguration -AzureRMSLicensingEnabled $trueを確認・設定する
前提:作業端末・アカウント
- OS:Windows 10 / 11
- PowerShell:Windows PowerShell 5.1(x64)
- 実行方法:「管理者として実行」した PowerShell コンソール
- アカウント:全体管理者(グローバル管理者)
- 可能であれば「作業専用」の全体管理者アカウントを新規作成
- 作業完了後は必ず MFA / 条件付きアクセスを元に戻す
Step 1:AipService モジュールのインストール/確認
# PowerShell を管理者として実行している前提
Install-Module -Name AipService -Scope AllUsers
# 読み込み
Import-Module AipService
# バージョン確認(3.0.0.1 など)
Get-Module AipService -ListAvailable
PowerShell Gallery 上の最新版として、2024 年には v3.0.0.1 が提供されています。
Step 2:MSOnline モジュールで MFA を一時的に無効化
MSOnline モジュールはレガシー扱いですが、MFA 設定を一括変更する用途では依然として利用例が多く、今回のワークアラウンドでも使われています。
# MSOnline モジュールをインポート
Install-Module MSOnline
Import-Module MSOnline
# テナントに接続(全体管理者)
Connect-MsolService
# 対象アカウントの MFA を一時的に無効化
Set-MsolUser -UserPrincipalName [email protected] `
-StrongAuthenticationRequirements @()
※ 条件付きアクセス ポリシーで MFA を強制している場合は、ポリシー側の一時的な無効化も併せて検討してください。
Step 3:AIP サービスへ接続 → 保護サービスを有効化
# AipService モジュールをインポート
Import-Module AipService
# AIP サービスに接続
Connect-AipService -Verbose
# 接続に成功したら保護サービスを有効化
Enable-AipService
Connect-AipServiceでサインインウィンドウが表示され、認証に成功することを確認Enable-AipServiceは、接続済みでないとNo connection to the Azure Information Protection service is present ...というエラーになります
有効化後は、Get-AipService コマンドで状態が Enabled になっているかを確認できます。
Get-AipService
# Status : Enabled であれば有効
Step 4:Exchange Online で IRM 設定を確認・有効化
次に、Exchange Online から Azure Rights Management サービスを利用できるように設定します。
# Exchange Online PowerShell v3 モジュールの利用を想定
Import-Module ExchangeOnlineManagement
# Exchange Online に接続
Connect-ExchangeOnline -UserPrincipalName [email protected]
# 現状確認
Get-IRMConfiguration
# 必要に応じて AzureRMSLicensingEnabled を有効化
Set-IRMConfiguration -AzureRMSLicensingEnabled $true
# 推奨:動作テスト
Test-IRMConfiguration -RMSOnline
Get-IRMConfiguration 出力の AzureRMSLicensingEnabled が True であれば、Exchange Online 側から Azure Rights Management に接続できる状態です。
Step 5:RMS テンプレートの表示を確認
ここまで完了したら、管理センターから RMS テンプレートが見えるかどうかを確認します。
- Exchange 管理センター(EAC)でトランスポート ルール(メール フロー ルール)を作成
- 「メッセージのセキュリティ」や「メッセージに暗号化を適用」などのアクションを選択
- RMS テンプレートの一覧 に代表的なテンプレート(「転送禁止」「暗号化のみ」など)が表示されることを確認
テンプレートの反映には、環境によっては数分〜数十分かかる場合があります。しばらく待ってからブラウザを再読み込みして再確認してみてください。
Step 6:MFA / 条件付きアクセスを必ず元に戻す
ワークアラウンドの中で MFA を一時的に無効化した場合は、忘れずに元の設定へ戻します。
- Entra ID(旧 Azure AD)管理センター:
- 対象ユーザーの MFA を再有効化
- 条件付きアクセス ポリシーを元の状態に戻す
- 必要に応じて、MSOnline や Graph PowerShell からも確認
ここを放置すると、管理者アカウントが長期間 MFA 無効のままになってしまい、セキュリティリスクが一気に高まります。
まとめて実行したい場合のサンプル スクリプト
細かいエラーハンドリングやログ出力は割愛しますが、「検証テナントで一気に試したい」という方向けに、主要ステップをまとめたサンプルを載せておきます。
# 前提:管理者として実行 / Windows PowerShell 5.1
$AdminUpn = "[email protected]"
# --- MFA 一時無効化(必要な場合のみ) ---
Import-Module MSOnline
Connect-MsolService
Set-MsolUser -UserPrincipalName $AdminUpn -StrongAuthenticationRequirements @()
# --- AipService 有効化 ---
Install-Module -Name AipService -Scope AllUsers -Force
Import-Module AipService
Connect-AipService -Verbose
Enable-AipService
# --- Exchange Online IRM 設定 ---
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -UserPrincipalName $AdminUpn
Get-IRMConfiguration
Set-IRMConfiguration -AzureRMSLicensingEnabled $true
Test-IRMConfiguration -RMSOnline
本番テナントで実行する場合は、必ず事前に検証テナントで動作確認を行い、MFA 再有効化手順も含めてドキュメント化 しておくことをおすすめします。
チェックリスト:再発防止とトラブルシュートの観点
| チェック項目 | OK 条件 | 確認方法 |
|---|---|---|
| アカウント ロール | 全体管理者 or コンプライアンス管理者 | Entra ID 管理センターのロール設定を確認 |
| PowerShell バージョン | Windows PowerShell 5.1(x64) | $PSVersionTable.PSVersion |
| 実行ホスト | PowerShell コンソール(ISE ではない) | ISE ではなく powershell.exe で実行 |
| AipService モジュール | インストール済みで最新 | Get-Module AipService -ListAvailable |
| AIP サービス状態 | Status : Enabled | Get-AipService の出力 |
| Exchange IRM 設定 | AzureRMSLicensingEnabled : True | Get-IRMConfiguration の出力 |
| テスト結果 | Test-IRMConfiguration -RMSOnline が成功 | エラーが出ないことを確認 |
| MFA 状態 | 作業後に元のポリシーへ復元済み | Entra ID 管理センターで確認 |
| サービス側の問題の可能性 | 他テナントでは成功・本テナントのみ失敗 | Connect-AipService -Verbose の相関 ID を控えてサポートへ |
よくある勘違い・ハマりどころ
| よくある誤解 | 実際のところ |
|---|---|
Enable-AipService を先に実行すればよい | Connect-AipService での接続が前提。接続がないと No connection ... エラーになる |
| PowerShell 7 の方が新しいから安全 | AipService は PowerShell 7 をサポートしておらず、Windows PowerShell 5.1 一択 |
| モジュールのバージョンを下げれば直る | 一時的にサインイン画面が出ることはあるが、根本原因が RMS 側やテナント設定なら解決しない |
| 「Access management for Azure resources」の設定が原因 | Entra ID のこの設定は主に Azure リソース管理用であり、AIP 接続問題の主因ではないと考えられる |
| 2024 年以降は Azure Rights Management が自動有効化されるから何も不要 | 原則は自動だが、無効化済みテナントや一部新規テナントでは手動有効化が必要なケースが残っている |
Microsoft 365 Business Premium でのメール暗号化全体像
現在の Microsoft 365 では、メール暗号化は Microsoft Purview Message Encryption として提供されており、実態としては Azure Rights Management の暗号化機能を Sensitivity ラベルやトランスポート ルールから呼び出す形になっています。
- Purview 情報保護の Sensitivity ラベルで「暗号化」を有効化
- ラベルをメールに自動/手動適用することで暗号化
- 裏側では Azure Rights Management サービスが動作し、RMS テンプレートやポリシーに基づいてアクセス制御
しかし、テナント側で Azure Rights Management が Disabled のままになっていると、次のようなエラーを引き起こします。
- 「Rights Management is not active for the tenant」
- ラベル編集画面で暗号化オプションがグレーアウト
- Exchange の RMS テンプレート一覧が空のまま
そのため、Purview 側でどれだけラベルやポリシーを作り込んでも、AipService で保護サービスを Enabled にする・Exchange 側で IRM を有効化する という基盤部分を済ませておかないと、メール暗号化の全体設計が動きません。
いつ Microsoft サポートにエスカレーションすべきか
ここまでの手順を実施してもなお Connect-AipService が成功しない場合は、テナント固有の問題である可能性が高くなります。その場合は、早めに Microsoft サポートへエスカレーションするのがおすすめです。
問い合わせ時に用意しておきたい情報:
Connect-AipService -Verboseの出力から:- Correlation ID(相関 ID)
- エラー発生日時(UTC or タイムゾーン込み)
- テナント ID / サブスクリプション種別(例:Microsoft 365 Business Premium 試用版)
- 実行環境:
- Windows バージョン
- PowerShell バージョン(5.1)
- AipService モジュール バージョン
- 別テナントでは接続成功しているかどうか
- ネットワーク ファイアウォールでのブロックがないことの証跡(可能であれば)
2024 年 1〜2 月の例では、複数のユーザーが「新規テナントだけで一斉に再現している」ことを根拠に、ネットワークや設定ではなくサービス側の問題であると主張し、RMS チームによる修正に結びつけています。
まとめ:実務目線での「最短ルート」
最後に、本記事で紹介した内容を実務的な観点から 5 行でまとめます。
- RMS テンプレートが空/
Connect-AipServiceに失敗する場合、まずは Windows PowerShell 5.1 + AipService モジュール で試す。 - 接続できないときは、作業用の全体管理者アカウントの MFA を一時的に無効化 し、
Connect-AipService→Enable-AipServiceを実行。 - 続いて Exchange Online で
Set-IRMConfiguration -AzureRMSLicensingEnabled $trueを設定し、Test-IRMConfiguration -RMSOnlineで確認。 - RMS テンプレートが EAC から見えるようになったら、必ず MFA / 条件付きアクセスを元に戻す。
- ここまで行っても解消しない場合は、
Connect-AipService -Verboseの相関 ID とともに Microsoft サポートへエスカレーションし、テナント固有の問題として調査を依頼する。
これらを押さえておけば、「なぜか RMS テンプレートが出ない」「AIP の保護サービスが有効化できない」といったトラブルにも落ち着いて対処できるようになるはずです。

コメント