Microsoft Purview Message Encryptionを設定する際に最初に確認すべきことは、Azure Rights Managementが有効か、AD RMSを使っていないか、既存のメールフロールールが新しい暗号化方式に更新されているかの3点です。ここを確認しないまま展開すると、暗号化メールが期待どおりに送れない、外部受信者が開けない、旧形式のHTML添付ファイルで配信され続ける、といった問題が起きやすくなります。
Microsoft Purview Message Encryptionは、Microsoft 365組織内だけでなく、Outlook.com、Gmail、その他のメールサービス利用者にも暗号化メールを送れる仕組みです。Microsoft公式情報では、利用前提としてAzure Rights Managementサービスがテナントで有効になっていること、Exchange Online PowerShellでIRM構成を確認すること、既存の暗号化ルールをMicrosoft Purview Message Encryption向けに更新することが示されています。(Microsoft Learn)
この記事では、2026年5月時点の公式情報を基に、Microsoft Purview Message Encryptionの設定手順、管理者が確認すべき変更点、影響範囲、移行・展開時の注意点を実務目線で整理します。
Microsoft Purview Message Encryptionとは
Microsoft Purview Message Encryptionは、メールの暗号化と権限管理を組み合わせて、組織内外の相手と保護されたメールをやり取りするためのMicrosoft 365の機能です。権限管理部分はMicrosoft Purview Information Protectionの機能を利用しており、暗号化だけでなく「転送禁止」「閲覧のみ」といった利用制御も組み合わせられます。(Microsoft Learn)
従来のOffice 365 Message EncryptionやIRMと比べると、社内外の受信者に対応し、Outlook、Outlook on the web、モバイルOutlook、暗号化メッセージポータルなどを通じて利用できる点が特徴です。公式FAQでは、Office 365 Message Encryptionは2023年7月1日に非推奨となり、Microsoft Purview Message Encryptionに自動的に置き換えられると説明されています。(Microsoft Learn)
業務での主な利用シーンは、次のようなケースです。
- 取引先に個人情報や契約情報を含むメールを送る
- 給与、採用、法務、監査関連のメールを外部に送る
- 社外秘資料を添付したメールの転送を制限する
- 特定の宛先、ドメイン、キーワードに該当するメールを自動で暗号化する
- DLPやメールフロールールと組み合わせて情報漏えい対策を強化する
ポイントは、Microsoft Purview Message Encryptionが「ユーザーが手動で暗号化ボタンを押す機能」だけではないことです。Exchange Onlineのメールフロールールを使えば、条件に一致したメールを自動で暗号化できます。
管理者が押さえるべき変更点と確認ポイント
今回の公式手順で重要なのは、単に「暗号化機能を有効にする」ことではありません。既存環境に旧OME、IRM、AD RMS、ハイブリッドExchange、独自のトランスポートルールがある場合、設定の見直しが必要です。
| 確認項目 | 管理者が見るべきポイント | 放置した場合の影響 |
|---|---|---|
| Azure Rights Management | テナントで有効化されているか | Message Encryptionが正しく動作しない |
| AD RMS利用有無 | Exchange OnlineとAD RMSを併用していないか | Microsoft Purview Message Encryptionを利用できない |
| 既存の暗号化ルール | 旧OME用のアクションが残っていないか | 旧HTML添付ファイル形式で配信される可能性がある |
| Exchange Online PowerShell | Get-IRMConfigurationとTest-IRMConfigurationで検証したか | 本番展開後に暗号化・復号エラーが判明する |
| テナントキー管理 | Microsoft管理キーかBYOKか | コンプライアンス要件と合わない可能性がある |
| 外部受信者の認証方式 | ソーシャルID、ワンタイムパスコードを許可するか | 取引先が暗号化メールを開けない可能性がある |
| ハイブリッド構成 | メールがExchange Onlineを経由しているか | オンプレミスユーザーの暗号化メール運用に影響する |
特に注意したいのは、既存のメールフロールールを更新しないと、ユーザーが新しいシームレスな暗号化メール体験ではなく、以前のHTML添付ファイル形式で受信し続ける可能性がある点です。公式手順でも、既存ルールをMicrosoft Purview Message Encryption向けに更新する必要があると説明されています。(Microsoft Learn)
影響範囲はメール管理者だけに限られない
Microsoft Purview Message Encryptionの設定は、Exchange Online管理者だけで完結する作業に見えます。しかし実際には、セキュリティ、法務、ヘルプデスク、業務アプリ担当者にも影響します。
Exchange Online管理者への影響
Exchange Online管理者は、メールフロールール、IRM構成、ハイブリッドメール経路を確認する必要があります。特に既存のトランスポートルールが多い環境では、「どのルールが暗号化を適用しているか」「旧OME用のアクションが残っていないか」を棚卸しする作業が重要です。
暗号化ルールは、条件に一致したメールに自動的に適用されます。たとえば、外部宛て、特定ドメイン宛て、件名や本文に特定キーワードを含むメール、特定部門から送信されるメールなどが対象になります。(Microsoft Learn)
セキュリティ・コンプライアンス担当者への影響
セキュリティ担当者は、暗号化の対象範囲だけでなく、復号、監査、eDiscovery、添付ファイルの扱いも確認する必要があります。
たとえば、Microsoft Purview Message Encryptionで保護された多くのメールはeDiscoveryで検出可能ですが、カスタムブランドが適用され、メール本文が受信者のメールボックスではなく暗号化メッセージポータル上のリンクとして表示されるケースでは、検索できない場合があると公式FAQで説明されています。(Microsoft Learn)
ヘルプデスクへの影響
展開後に増えやすい問い合わせは、外部受信者からの「暗号化メールを開けない」「ワンタイムパスコードが届かない」「Gmailでサインインできない」といったものです。
公式FAQでは、ワンタイムパスコードが届かない場合、迷惑メールフォルダー、DKIM・DMARCによるフィルタリング、Microsoft Purviewポータルの検疫を確認するよう案内されています。(Microsoft Learn)
開発者・業務アプリ担当者への影響
業務アプリからメールを送信している場合、そのメールがExchange Onlineのメールフローを通るかどうかを確認してください。メールフロールールで暗号化する設計では、対象メールがExchange Online組織内から送信され、ルール条件に一致する必要があります。
また、請求書、契約書、通知メールなどを自動送信するシステムでは、次の点をテストしておくと本番トラブルを避けやすくなります。
- 添付ファイル込みで25MBを超えないか
- BCCを使う運用がないか
- 外部受信者が暗号化メールを開けるか
- 暗号化が不要な自動通知まで対象になっていないか
- 返信メールや転送制御が業務フローを妨げないか
Microsoft公式FAQでは、Microsoft Purview Message Encryptionで送信できるメッセージサイズは添付ファイルを含めて最大25MBと説明されています。また、一部のコネクタ構成やExchangeハイブリッド環境では、BCC受信者が暗号化前に削除される場合があるため、宛先はToまたはCCに入れる運用が推奨されています。(Microsoft Learn)
設定前に確認する前提条件
Microsoft Purview Message Encryptionを設定する前に、次の項目を確認します。
| 確認項目 | 確認内容 | 判断基準 |
|---|---|---|
| ライセンス | 対象ユーザーが利用可能なライセンスを持つか | 暗号化機能を利用するユーザーごとに必要 |
| 管理者権限 | Compliance Administratorなど十分な権限があるか | グローバル管理者の常用は避ける |
| Azure Rights Management | テナントで有効か | 有効ならMicrosoft 365側でMessage Encryptionが利用可能 |
| AD RMS | Exchange OnlineとAD RMSを使っていないか | 利用中ならAzure RMSへの移行が必要 |
| 既存ルール | 旧OMEやIRMルールが残っていないか | Microsoft Purview Message Encryption用に更新 |
| テナントキー | Microsoft管理キーかBYOKか | コンプライアンス要件に応じて判断 |
| 外部受信者 | Gmail、Outlook.com、取引先ドメインで開封できるか | パイロット送信で確認 |
| 添付ファイル | Office、PDF、クラウド添付の扱いを確認したか | 対応範囲を誤解しない |
Microsoft Purview Message Encryptionの唯一の前提条件は、組織テナントでAzure Rights Managementサービスが有効であることです。多くの対象プランでは自動的に有効化されますが、無効化していた場合や自動有効化されていない場合は手動確認が必要です。(Microsoft Learn)
Azure Rights Managementの状態を確認する
Microsoft Purview Message Encryptionは、Azure Rights Managementサービスの保護機能を利用します。まずはAzure Rights Managementが有効かどうかを確認します。
公式手順では、Azure Rights Managementの有効化や状態確認にはPowerShellを使用します。管理ポータルからの有効化・無効化はできないため、AIPServiceモジュールを使って確認します。(Microsoft Learn)
Connect-AipService
Get-AipServiceGet-AipServiceの結果がEnabledであれば、Azure Rights Managementは有効です。Disabledの場合は、ライセンスやAD RMS利用状況を確認したうえで、有効化を検討します。
Enable-AipServiceただし、AD RMSを組織で展開している場合は注意が必要です。公式情報では、AD RMSを利用している場合はAzure Rights Managementを安易に有効化せず、移行計画を立てる必要があるとされています。(Microsoft Learn)
Exchange Online PowerShellでIRM構成を確認する
Azure Rights Managementを確認したら、Exchange Online側でMicrosoft Purview Message Encryptionが使える状態かを確認します。
まず、Exchange Online PowerShellに接続します。
Connect-ExchangeOnline次に、IRM構成を確認します。
Get-IRMConfiguration確認すべき代表的な値は、AzureRMSLicensingEnabledです。公式手順では、この値が$Trueであれば、テナントでMicrosoft Purview Message Encryptionが構成されていることを示すとされています。$Falseの場合は、次のように有効化します。(Microsoft Learn)
Set-IRMConfiguration -AzureRMSLicensingEnabled $true続いて、暗号化と復号が正常に動作するかをテストします。
Test-IRMConfiguration -Sender [email protected] -Recipient [email protected]期待される結果は、RMSテンプレートの取得、暗号化、復号、IRMの確認がすべてPASSになる状態です。公式手順では、OVERALL RESULT: PASSが確認例として示されています。(Microsoft Learn)
RMSテンプレート取得に失敗した場合
Failed to acquire RMS templatesのようなエラーが出る場合は、AIPServiceモジュールに接続したうえで、ライセンス配布ポイントを設定し直します。
$RMSConfig = Get-AipServiceConfiguration
$LicenseUri = $RMSConfig.LicensingIntranetDistributionPointUrl
Set-IRMConfiguration -LicensingLocation $LicenseUri
Set-IRMConfiguration -InternalLicensingEnabled $trueその後、再度Test-IRMConfigurationを実行し、PASSになるか確認します。(Microsoft Learn)
テナントキー管理は「既定のまま」でよいかを判断する
Azure Rights Managementのルートキーは、既定ではMicrosoftが管理します。公式手順では、ほとんどの組織にとってMicrosoft管理キーが既定かつ推奨されるベストプラクティスとされています。(Microsoft Learn)
一方で、金融、公共、規制産業などでは、監査要件や内部統制上の理由からBYOK、つまりBring Your Own Keyを検討する場合があります。
| 選択肢 | 向いている組織 | 注意点 |
|---|---|---|
| Microsoft管理キー | 多くの一般企業、運用負荷を抑えたい組織 | キー管理をMicrosoftに委ねる |
| BYOK | 厳格なキー管理要件がある組織 | Azure Key VaultやHSM、運用手順の整備が必要 |
| AD RMSから移行 | オンプレミスRMSを利用中の組織 | 移行計画、クライアント再構成、Exchange連携確認が必要 |
BYOKが必要な場合は、Microsoft Purview Message Encryptionの本格展開前にキー管理方針を決めておくべきです。後から変更すると、検証や運用手順の見直しが増えます。
既存のメールフロールールを更新する
Microsoft Purview Message Encryptionを利用するうえで、実務上もっとも重要なのがメールフロールールの見直しです。
既存の暗号化ルールがある場合は、Exchange管理センターで各ルールを確認し、アクションをMicrosoft Purview Message Encryption向けに更新します。公式手順では、Exchange管理センターの「メールフロー」>「ルール」から、該当ルールのアクションで「Office 365 Message Encryptionおよび権限保護を適用」を選び、RMSテンプレートからEncryptを選択する流れが示されています。(Microsoft Learn)
新規展開の場合は、対象条件を明確にしてからルールを作成します。
| 利用シーン | 条件例 | アクション例 | 注意点 |
|---|---|---|---|
| 外部宛ての機密メール | 受信者が組織外、件名に「Confidential」 | Encryptを適用 | 件名ルールだけでは漏れが出る |
| 特定取引先への契約書送付 | 受信者ドメインが取引先 | Do Not Forwardを適用 | 取引先の共有メールボックス運用を確認 |
| 個人情報を含むメール | DLP条件または本文キーワード | Encryptを適用 | 誤検知時の解除手順を用意 |
| 役員・人事部門の送信メール | 送信者が特定グループ | EncryptまたはDo Not Forward | すべて暗号化すると業務負荷が増える |
| 暗号化解除が必要な社内処理 | 組織が適用した暗号化メール | 暗号化解除ルール | 解除対象を広げすぎない |
メールフロールールでは、外部送信者から届いた受信メールを暗号化することはできません。公式情報では、Exchange Online組織外からの受信メールを暗号化するルールを作成しても、その受信メールは暗号化されずに配信されると説明されています。(Microsoft Learn)
AD RMS利用環境では移行が必須
Exchange OnlineでActive Directory Rights Management Service、つまりAD RMSを利用している場合、Microsoft Purview Message Encryptionをそのまま利用することはできません。公式手順では、Microsoft Purview Message EncryptionはAD RMSと互換性がなく、利用前にAzure Rights Managementサービスへ移行する必要があると明記されています。(Microsoft Learn)
AD RMSからAzure Information Protectionへの移行では、AD RMSで保護された既存の文書やメールへのアクセスを維持しながら、新たに保護されるコンテンツはAzure Rights Managementを使う構成に変えていきます。移行手順には、キーやテンプレートのエクスポート・インポート、Azure Rights Managementの有効化、クライアント再構成、Exchange OnlineのIRM統合、AD RMSの廃止などが含まれます。(Microsoft Learn)
移行時に特に注意すべき点は次のとおりです。
- 既存のAD RMS保護コンテンツを誰が開く必要があるかを洗い出す
- 外部パートナーとAD RMS連携している場合、相手側の移行計画も確認する
- WindowsクライアントがAD RMSではなくAzure Rights Managementを参照するように再構成する
- Exchange ServerやSharePoint ServerのIRM連携がある場合、短時間の停止や再構成を計画する
- 移行後、既存テンプレートの公開状態とユーザー表示を確認する
「AD RMSは古いからすぐ止める」という進め方は危険です。保護済みコンテンツの開封、外部パートナーとの共同利用、監査要件に影響するため、段階的な移行計画を作るべきです。
ハイブリッドExchange環境での注意点
Exchangeハイブリッド環境では、オンプレミスユーザーもMicrosoft Purview Message Encryptionを利用できます。ただし、メールがExchange Onlineを経由する必要があります。
公式情報では、ハイブリッドExchange環境でメッセージ暗号化を構成するには、Hybrid Configuration Wizardでハイブリッド構成を行い、Microsoft 365とオンプレミスメールサーバー間のメールフローを構成したうえで、メールフロールールを設定する必要があると説明されています。(Microsoft Learn)
確認すべき実務ポイントは次の3つです。
- オンプレミス送信メールがExchange Onlineを経由しているか
- コネクタ構成によりBCCや宛先情報の扱いに影響が出ないか
- オンプレミス側の既存IRM設定とExchange Online側の暗号化ルールが競合しないか
特に、業務システムや複合機がオンプレミスSMTPから直接外部送信している場合、Exchange Onlineのメールフロールールが適用されない可能性があります。暗号化対象にしたいメールは、送信経路を必ず確認してください。
外部受信者の開封体験を設計する
Microsoft Purview Message Encryptionでは、外部受信者が暗号化メッセージポータルを使ってメールを読むケースがあります。管理者は、Google、Yahoo、MicrosoftアカウントなどのソーシャルIDによるサインインを許可するか、ワンタイムパスコードを許可するかを制御できます。(Microsoft Learn)
代表的な設定は次のとおりです。
Set-OMEConfiguration -Identity "OME Configuration" -SocialIdSignIn $true
Set-OMEConfiguration -Identity "OME Configuration" -OTPEnabled $trueソーシャルIDやワンタイムパスコードを厳しく制限すると、セキュリティ上は統制しやすくなります。一方で、取引先が暗号化メールを開けず、ヘルプデスク問い合わせが増える可能性があります。
| 設定 | メリット | 注意点 |
|---|---|---|
| ソーシャルIDを許可 | Gmailなどの利用者が開きやすい | 認証方式の許容範囲を社内で決める |
| ソーシャルIDを禁止 | 外部認証の統制を強められる | 受信者の利便性が下がる |
| OTPを許可 | アカウント連携なしで開ける | パスコードメールが迷惑メールや検疫に入ることがある |
| OTPを禁止 | 認証経路を限定できる | 取引先によっては開封困難になる |
おすすめは、最初から厳格に閉じるのではなく、主要取引先、Gmail、Outlook.com、社外共有メールアドレスで開封テストを行い、問い合わせ傾向を見てから制御を強める方法です。
Outlook on the webの暗号化ボタンを制御する
ユーザーがOutlook on the webで暗号化ボタンを使えるかどうかは、管理者が制御できます。公式手順では、Set-IRMConfigurationのSimplifiedClientAccessEnabledパラメーターで表示を管理します。(Microsoft Learn)
Set-IRMConfiguration -SimplifiedClientAccessEnabled $true無効化する場合は次のようにします。
Set-IRMConfiguration -SimplifiedClientAccessEnabled $false展開初期は、全ユーザーに暗号化ボタンを表示するよりも、パイロット部門や情報管理が必要な部門から始めた方が安全です。ユーザーが意味を理解しないまま「何となく暗号化」を多用すると、受信者が開けない、転送できない、業務委託先の共有アドレスで処理できない、といった運用トラブルが増えます。
添付ファイルとクライアント制限を誤解しない
Microsoft Purview Message Encryptionはメール本文だけでなく、添付ファイルにも関係します。ただし、すべての添付ファイルが同じように保護されるわけではありません。
公式FAQでは、保護ポリシーが適用されるファイル形式は一部に限られ、既定ではWord、Excel、PowerPoint、XPSなどのOfficeファイル拡張子が対象として示されています。また、Word、Excel、PowerPointの97-2003形式はサポートされないと説明されています。(Microsoft Learn)
PDFについては、Exchange OnlineでPDF暗号化を有効にすることで、対応するOutlookクライアントでPDF添付を保護できます。(Microsoft Learn)
Set-IRMConfiguration -EnablePdfEncryption $true一方、SharePointやOneDriveのクラウド添付は、Microsoft Purview Message Encryptionではメール本文を暗号化できても、クラウド添付そのものは対象外とされています。(Microsoft Learn)
iOS標準メールアプリの注意点
iOS標準メールアプリは、Microsoft Purview Message Encryptionで保護されたメッセージをクライアント側で復号できません。管理者はサービス側復号を有効化できますが、その場合、復号済みコピーがデバイスに送られるため、コピーや印刷などの制御に影響します。既定ではサービス側復号は有効ではありません。(Microsoft Learn)
Set-ActiveSyncOrganizationSettings -AllowRMSSupportForUnenlightenedApps $trueセキュリティ重視の組織では、iOS標準メールアプリでの利便性を優先するより、Outlookモバイルアプリ利用を標準にした方が運用しやすい場合があります。
メールフロールールの設計で失敗しやすいポイント
Microsoft Purview Message Encryptionの展開でよくある失敗は、技術設定そのものよりも、ルール設計とユーザー影響の見積もり不足です。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| すべての外部メールを暗号化して問い合わせが急増 | 業務影響を検証していない | 重要部門や特定条件から段階展開する |
| 旧形式のHTML添付ファイルで届く | 既存ルールが更新されていない | 旧OMEアクションを削除し、新しい権限保護アクションに更新する |
| 取引先が暗号化メールを開けない | OTPやソーシャルID設定を制限しすぎた | 代表的な外部ドメインで事前テストする |
| 自動送信メールが暗号化されない | Exchange Onlineを経由していない | 送信経路とコネクタを見直す |
| 添付ファイルが期待どおり保護されない | ファイル形式やクラウド添付の仕様を誤解 | Office、PDF、OneDriveリンクの扱いを個別に確認する |
| 会議出席依頼をメールフロールールで暗号化しようとする | 対象メッセージの種類を誤解 | 会議招待は秘密度ラベルの利用を検討する |
| 管理者権限を広く付与しすぎる | 作業効率を優先した | Compliance Administratorなど最小権限を使う |
公式FAQでは、会議出席依頼やその応答に対して、メールフロールールで暗号化または暗号化解除を行うことはできず、秘密度ラベルを使う必要があると説明されています。(Microsoft Learn)
段階展開のおすすめ手順
Microsoft Purview Message Encryptionは、全社一括展開よりも段階展開の方が安全です。特に外部取引先が多い企業、ハイブリッドExchange環境、業務アプリからのメール送信が多い環境では、パイロット期間を設けるべきです。
| フェーズ | 実施内容 | 完了条件 |
|---|---|---|
| 事前調査 | ライセンス、AD RMS、既存ルール、送信経路を棚卸し | 影響部門と対象メールが明確になっている |
| 技術検証 | Azure RMS、IRM構成、テンプレート取得を確認 | Test-IRMConfigurationがPASS |
| パイロット | 情報システム部、人事、法務など少人数で試行 | 社内外で開封・返信・添付確認が完了 |
| ルール拡張 | 特定ドメイン、外部宛て、DLP条件に拡大 | 誤検知と問い合わせが許容範囲 |
| 本番運用 | ヘルプデスク手順、監査、定期レビューを整備 | ルール変更履歴と例外申請が管理されている |
Azure Rights Managementにはオンボーディング制御があり、暗号化を適用できるユーザーを段階的に制限することもできます。公式情報では、全ユーザーにすぐ暗号化を許可したくない場合、PowerShellでオンボーディング制御を構成できると説明されています。(Microsoft Learn)
開発者・アプリ担当者が確認すべきこと
業務アプリからメールを送る場合、Microsoft Purview Message Encryptionの設定後に「人がOutlookで送るメール」と同じように暗号化されるとは限りません。ルール条件、送信経路、宛先、添付ファイル、サイズ制限を個別に確認してください。
特に確認すべき項目は次のとおりです。
送信経路
Exchange Onlineを経由して送信されるメールかを確認します。オンプレミスSMTP、外部メール配信サービス、業務システム独自のSMTPサーバーから直接外部へ送っている場合、Exchange Onlineのメールフロールールは適用されません。
宛先設計
暗号化メールでは、BCCや配布リスト、共有メールボックスの挙動を事前に確認します。共有メールボックスで暗号化メールを開く場合、Outlook on the webでは対応しやすい一方、Outlook for Windowsでは直接割り当てやバージョン条件などの制約があるため、代表ユーザーでテストしてください。(Microsoft Learn)
添付ファイル
自動生成されるPDF、Excel、Word、CSV、ZIPファイルの扱いを確認します。PDF暗号化を使う場合は、Set-IRMConfiguration -EnablePdfEncryption $trueの設定だけでなく、受信者側クライアントで開けるかまで検証します。
エラーハンドリング
受信者が暗号化メールを開けない場合、業務アプリ側では送信成功に見えても、実際の業務処理は止まります。請求書、契約締結、本人確認、採用通知など期限があるメールでは、代替連絡手段や再送手順を用意しておくべきです。
運用開始後に確認する監査・レポート
Microsoft Purview Message Encryptionは、設定して終わりではありません。運用後は、暗号化メールの利用状況、外部受信者の開封トラブル、ルールの誤適用、例外申請を定期的に確認します。
公式FAQでは、暗号化メールに関するレポートとしてMicrosoft PurviewポータルのEncryption reportが案内されています。また、暗号化メッセージポータルのアクティビティログは、外部受信者がポータルへアクセスしたイベントを対象とし、外部受信者のメールクライアント上の操作は記録されないと説明されています。(Microsoft Learn)
運用レビューでは、次の観点を月次または四半期で確認すると実務に役立ちます。
- 暗号化ルールに一致したメール件数
- 誤って暗号化されたメールの件数
- 暗号化されるべきだったが漏れたメールの事例
- 外部受信者からの問い合わせ内容
- OTP未着や検疫入りの発生状況
- 例外ルールが増えすぎていないか
- 退職者、共有メールボックス、配布リストの扱い
管理者向けチェックリスト
本番展開前に、次のチェックリストを使って確認してください。
| チェック | 項目 |
|---|---|
| □ | 対象ユーザーのライセンスを確認した |
| □ | Azure Rights Managementが有効であることを確認した |
| □ | AD RMSを使っていない、または移行計画を作成した |
| □ | Exchange Online PowerShellでGet-IRMConfigurationを確認した |
| □ | Test-IRMConfigurationで暗号化・復号テストに成功した |
| □ | 既存の旧OMEルールを棚卸しした |
| □ | メールフロールールをMicrosoft Purview Message Encryption向けに更新した |
| □ | 外部受信者のソーシャルID・OTP利用方針を決めた |
| □ | 主要取引先、Gmail、Outlook.comで開封テストした |
| □ | 添付ファイル、PDF、クラウド添付の扱いを確認した |
| □ | ハイブリッド環境のメール経路を確認した |
| □ | ヘルプデスク向けFAQを用意した |
| □ | 監査・レポートの確認担当を決めた |
次に取るべき行動
Microsoft Purview Message Encryptionを安全に展開するには、まず現在のメール暗号化環境を棚卸ししてください。確認順序は、Azure Rights Managementの有効化状況、AD RMS利用有無、IRM構成、既存メールフロールール、外部受信者の開封テストの順が実務的です。
特に既存のOffice 365 Message EncryptionやIRMルールがある環境では、ルール更新を後回しにしないでください。旧形式の配信が残ると、ユーザー体験がばらつき、問い合わせ対応も複雑になります。
まずは情報システム部門や一部の管理部門でパイロットを行い、Test-IRMConfigurationの結果、外部受信者の開封可否、添付ファイルの扱い、ヘルプデスク問い合わせの傾向を確認します。そのうえで、DLPやメールフロールールと組み合わせ、必要なメールだけを確実に暗号化する設計へ広げていくのが、失敗しにくい展開方法です。
コメント