Microsoft Purview メール保護で添付ファイルへの保護継承を完全に止められるのか?Encrypt‑Only 設定と現実的な回避策

Microsoft Purview メール保護を導入すると、「メールを暗号化したら添付ファイルまで自動で保護されてしまい、相手が二次利用しづらい」「Encrypt‑Only なら継承を外せたが、Do Not Forward や暗号化付き感度ラベルでも止めたい」といった声がよく上がります。本記事では、現行仕様で“できること/できないこと”を整理しつつ、実務で取りうる現実的な回避策を詳しく解説します。

目次

Microsoft Purview メール保護と「添付ファイルの保護継承」概要

まずは、Microsoft Purview メール保護(Microsoft Purview Message Encryption / 情報保護)の基本動作を整理します。

Encrypt‑Only / Do Not Forward / 暗号化付き感度ラベルの違い

Purview メール保護では、代表的に次の 3 パターンでメールが保護されます。

  • Encrypt‑Only(暗号化のみ):内容を暗号化するが、利用権限の制御は最小限
  • Do Not Forward(転送不可):転送・コピー・印刷など再配布を強く制限
  • 暗号化付き感度ラベル:管理者が定義した権限(閲覧のみ/社内限定など)を付与

公式ドキュメント上でも、Encrypt‑Only と Do Not Forward は「メール暗号化の 2 大オプション」として説明されています。

それぞれの既定動作と、添付ファイル保護の扱いを表にまとめると以下の通りです。

保護方式主な目的既定の添付ファイル動作継承オフ可否(テナント設定)
Encrypt‑Onlyメール内容を暗号化(使用権限の制限は弱め)メール本文と同じ Encrypt‑Only 保護が添付に継承される
(Office 添付は暗号化され、受信者にも制限がかかる)
可
Set‑IRMConfiguration -DecryptAttachmentForEncryptOnly で制御可能
Do Not Forward転送・コピー・印刷など再配布の抑止メールだけでなく、Office 添付も Do Not Forward 相当の保護が自動継承される(ダウンロード後も保護が維持)不可
添付への継承を無効化する管理者設定は存在しない
暗号化付き感度ラベルラベル単位で権限(社外ドメイン限定・閲覧のみ等)を定義暗号化ラベルが適用されたメールに Office ファイルを添付すると、
同じ暗号化&権限が添付にも自動的に適用される
不可
「メールだけ暗号化し添付は無保護にする」汎用設定はない

つまり、管理者が制御できる「添付継承の ON/OFF」は Encrypt‑Only に限られます。Do Not Forward や暗号化付き感度ラベルには同等のスイッチがありません。

結論:Encrypt‑Only 以外は継承停止できない

本記事のテーマである「メール → 添付の保護継承を全部止めたい?」という問いに対する結論は以下の通りです。

  • Encrypt‑Only の場合のみ、テナント設定で添付の継承を無効化できる
  • Do Not Forward や 暗号化付き感度ラベル については、
    • 添付ファイルへの保護継承を無効化する PowerShell パラメータや管理画面の設定は存在しない
    • Microsoft Q&A でも「現時点では不可能」と公式サイドで整理されている

この前提を押さえたうえで、実際に何ができるかを見ていきます。

Encrypt‑Only の添付保護継承を止める方法

Set‑IRMConfiguration -DecryptAttachmentForEncryptOnly の意味

Exchange Online の IRM 設定には、DecryptAttachmentForEncryptOnly というパラメータがあります。公式ドキュメントでは次のように説明されています。

  • $true:Encrypt‑Only で送信されたメールの添付ファイルについて、受信者に「制限なし」で利用させる(≒添付側は保護しない)
  • $false:Encrypt‑Only メールの添付も暗号化され、利用に制限がかかる(既定値)

この設定を有効にすることで、Encrypt‑Only のメールに限り、添付ファイルへの保護継承を外すことができます。

具体的な設定手順(PowerShell)

Exchange Online PowerShell へ接続したうえで、次のように設定します。

# Exchange Online PowerShell へ接続(モジュールは事前インストール済みを想定)
Connect-ExchangeOnline

# Encrypt-Only のメールに限り、添付は保護しないで送付する
Set-IRMConfiguration -DecryptAttachmentForEncryptOnly $true

# 現在値の確認
Get-IRMConfiguration | fl DecryptAttachmentForEncryptOnly

ポイントは以下の通りです。

  • テナント全体に一律で適用される(ユーザー単位/ラベル単位で変えることは不可)
  • Encrypt‑Only 以外(Do Not Forward や暗号化付き感度ラベル)には影響しない
  • 設定反映まで、環境によっては数十分〜数時間程度のタイムラグが出ることもある

この設定を入れると、「Encrypt‑Only で守りたいのはメール本文だけ。添付は相手先で自由に加工してほしい」というユースケースにはフィットしますが、当然ながら 添付が無保護で外部に渡るリスクも増えます。そのため、後述のような共有リンク運用やラベル設計と組み合わせて使うことが重要です。

なぜ Do Not Forward/暗号化付きラベルの継承は止められないのか

Do Not Forward の目的は「再配布の抑止」

Do Not Forward は、単にメールを暗号化するだけでなく、受信者の「できること」を強く制限することが主目的です。

  • メールの転送禁止
  • 内容のコピー/印刷禁止
  • 受信者の追加や変更の禁止 など

このオプションが有効な場合、Office 形式の添付ファイルも同様に保護されるのが仕様です。ダウンロードしても保護が残るため、「メールは転送できないのに、添付を別メールで送り直せる」という抜け道を塞ぐことができます。

もしここで「メールは Do Not Forward だけど、添付は無保護で OK」という設定ができてしまうと、Do Not Forward の根本目的と矛盾してしまいます。そのため、設計思想としても添付への保護継承を前提にしており、管理者が一括で止める仕組みは提供されていないと考えるのが自然です。

暗号化付き感度ラベルも同様に継承が前提

暗号化付き感度ラベルでは、管理者が「誰に」「どの権限で」アクセスさせるかを細かく定義できます。たとえば「社内全員閲覧可」「特定パートナー企業のドメインだけ閲覧可」といった設定です。

  • メールに暗号化ラベルを付ける
  • 未保護の Office 文書を添付する
  • 送信すると、添付文書にも同じ暗号化&権限が自動的に適用される
  • 受信者が添付文書を開くと、文書自体にも対応するラベルが表示される

この挙動は「メールを経由して届いた文書も一貫したポリシーで守る」という思想に基づいており、やはり継承を無効化するオプションは用意されていません。Microsoft Q&A でも、「Do Not Forward テンプレート」「暗号化付き感度ラベル」のいずれについても、メール→添付の継承を停止する手段はないと整理されています。

よくある「クライアント側で Do Not Forward を消せないか?」という発想

前述の Q&A では、参考として Outlook クライアントのレジストリで Do Not Forward を無効化する DisableDNF という設定も紹介されていますが、これはあくまで「そのクライアントで Do Not Forward ボタンを出さない」レベルの話です。

  • 他のクライアント(Outlook on the web やモバイル)には効かない
  • トランスポートルールや DLP から Do Not Forward を付与されれば意味がない
  • 既に Do Not Forward/暗号化ラベルで保護されたメールの添付をサーバー側で「だけ」解除することはできない

そのため、組織全体で継承を止めたいという要件の解決策にはなりません。

実務で取りうる回避策(現実解)

仕様としては「完全な一括無効化は不可」なので、要件を満たすための設計と運用ルールで回避していくことになります。ここでは、現実的に採用しやすいパターンを紹介します。

1. 添付をやめて共有リンクに切り替える(推奨)

最も汎用的で再現性の高い方法は、ファイルは OneDrive / SharePoint に置き、メールには共有リンクだけを載せる方式に切り替えることです。

標準パターン(社外共有を想定)

  1. ファイルを OneDrive または SharePoint の共有用ライブラリに保存
  2. 「共有」から リンクの種類を「特定のユーザー」に設定(または組織ポリシーに応じて「組織内のユーザー」など)
  3. 必要に応じて以下のオプションを設定
    • 編集可/閲覧のみ
    • リンクの有効期限(◯日で自動失効)
    • ダウンロードの禁止(Block download)
  4. 生成された共有リンクをコピーし、保護されたメールの本文内に貼り付けて送信

この方式をとると、次のメリットがあります。

  • ファイル側のアクセス権限・有効期限・共有解除を、送信後も管理者/所有者が後から変更できる
  • 誤送信時もリンクの無効化で被害を小さくできる
  • 「メールは Do Not Forward/暗号化ラベル」「ファイルは別ポリシー」という分離がしやすい

一方で、以下のような運用上の注意点もあります。

  • 社外ユーザーが Microsoft アカウント/職場アカウントでのサインインを求められるケースがあるため、事前にアクセス方式を案内する必要がある
  • 「URL を転送すれば誰でもアクセスできてしまう」ような共有設定(Anyone リンク)は極力避ける

共有リンク運用 vs 添付ファイル運用の比較

項目従来の添付ファイル運用共有リンク運用
送信後のアクセス取り消し事実上不可能(コピー済みファイルは追えない)リンク削除/アクセス権変更で取り消し可能
有効期限の設定手作業で「削除」するしかないリンク期限をポリシーで強制可能
誤送信時のダメージ暗号化に依存。復旧はほぼ不可能リンクを即時無効化すれば被害を抑えやすい
ユーザーの手間添付するだけなので楽慣れるまではリンク生成が一手間

2. ラベル設計の見直し(メール用と文書用を分離)

次のように、「メール専用ラベル」と「文書専用ラベル」を分離すると設計が整理されます。

  • メール専用ラベル:スコープを「メールのみ」にして、Encrypt‑Only/Do Not Forward などメール向けの権限だけを定義
  • 文書専用ラベル:スコープを「ファイル(+必要ならメール)」にし、ドキュメント保護の権限を定義
  • 「分類だけ付ける(暗号化なし)」ラベル:システム間連携や検索のためにラベルは欲しいが、暗号化は不要なケース向け

イメージとして、次のようなラベル構成が考えられます。

ラベル名例スコープ暗号化主な用途
[メール] 機微情報通知(Encrypt‑Only)メールのみEncrypt‑Only(添付は共有リンク前提)相手に編集してほしい添付付きメールの通知
[メール] 機密連絡(Do Not Forward)メールのみDo Not Forward添付も含めて再配布させたくない連絡
[文書] 社外共有可(ドメイン指定暗号化)ファイル+メール特定ドメインのみ閲覧可パートナー企業と共有する文書全般
[文書] 社外共有不可(暗号化+社内限定)ファイル+メール社内ユーザーのみ閲覧可社外に出してはいけない設計書・レポートなど
[文書] 社内限定(ラベルのみ・暗号化なし)ファイル+メールなし分類だけ付けたいが暗号化は不要な資料

こうした分離により、次のような運用ポリシーが組み立てやすくなります。

  • 重要通知メール+添付編集が必要 ⇒ [メール] Encrypt‑Only ラベル + 共有リンク
  • 添付も含めて共有範囲を厳格にコントロールしたい ⇒ [文書] ラベルで文書側を保護し、メールは必要に応じて Do Not Forward
  • 暗号化でトラブルを起こしたくない領域 ⇒ 暗号化なしラベルのみを利用

3. 送信時のガードレール(トランスポートルール等)を整備

ユーザー任せにすると、「何となく Do Not Forward を付けたら相手が開けない」「添付が保護されていて印刷できない」といった混乱が起きがちです。そのため、Exchange Online のトランスポートルールや DLP ポリシーでガードレールを敷くのが有効です。

例えば、次のようなルールが考えられます。

  • ルール例 A:Do Not Forward + 添付あり + 対象が外部 ⇒ 警告バナーを自動追加
    • 「このメールは転送不可で送信され、添付ファイルも保護されます。相手に編集してもらう必要がある場合は、共有リンクで再送してください。」といったメッセージを付加
  • ルール例 B:特定ラベル+添付がローカルファイル ⇒ 送信をブロック
    • 「このラベルでは添付ファイルの共有は OneDrive/SharePoint のリンクのみ許可されています。」と表示して送信をキャンセル
  • ルール例 C:Encrypt‑Only + 添付あり ⇒ 自動的に共有リンクへ変換(将来構想)
    • 現時点では完全自動化は難しいですが、Outlook の「クラウド添付」機能と組み合わせたテンプレート・クイック操作により、ユーザー操作を簡略化できます。

ルールで「完全に制御」するのではなく、ユーザーにとって誤操作しづらいレールを敷くイメージで設計するのがおすすめです。

4. 効果が限定的/非推奨なアプローチ

一方で、次のようなアプローチは組織全体の解決にはつながりません。

  • Outlook クライアント側レジストリで Do Not Forward を非表示にする
    • 前述のとおり、他クライアントやサーバー側処理には影響しません
    • 既に保護されたメール/添付の継承を後から止めることはできません
  • サーバー側で「添付だけ保護解除」するようなカスタムスクリプト
    • Purview 情報保護/RMS の仕組み上、一般的な運用としてサポートされていません
    • 監査・コンプライアンス上もリスクが高く、推奨されません
  • 暗号化そのものをオフにしてしまう
    • 一時的なトラブル回避にはなりますが、本来守りたい情報も丸裸になってしまいます

シナリオ別:どう設計すべきか

ここまでの内容を踏まえて、代表的なシナリオごとにおすすめ構成をまとめます。

シナリオ要件おすすめ構成
取引先に見積書(Excel)を送り、相手側で編集して返送してほしいメール本文は保護したい(誤転送は避けたい) 添付 Excel は編集前提で相手に自由に扱ってほしいテナントで DecryptAttachmentForEncryptOnly = $true を設定 メールは Encrypt‑Only または Encrypt‑Only 相当のメール用ラベルを利用 可能なら添付ではなく OneDrive/SharePoint の共有リンクに切り替え
機密性の高い契約書を社外の特定担当者だけとやり取りしたいメール・添付ともに厳密に共有範囲を制限したい 転送やコピーも抑止したいパートナー企業のドメインを対象にした暗号化付き感度ラベルを作成(ファイル+メールスコープ) メール・添付ともにこのラベルで保護 必要に応じて Do Not Forward も併用
社外とのやり取りは最低限守りたいが、暗号化トラブルは避けたい相手環境によっては暗号化メールが開けないことがある とはいえ全く無保護なのも不安基本は共有リンク運用+暗号化なしラベルで分類のみ 暗号化メールは本当に必要なケースに限定し、Encrypt‑Only を中心に運用

導入時に押さえておきたい運用ポイント

  • ユーザー向けガイドの整備
    • 「このラベル+添付ありの場合は、必ず共有リンクに変えてください」といった、具体的な IF-THEN ルールを明文化
    • Outlook のクイック操作/テンプレートを用意し、ユーザー操作を簡略化
  • 段階的ロールアウト
    • 最初は Encrypt‑Only のみ有効にし、挙動に慣れてもらう
    • Do Not Forward/暗号化付きラベルは pilot グループで検証してから全社展開
  • ヘルプデスク用ナレッジ
    • 「添付が開けない」「相手が印刷できない」といった典型的な問い合わせへの対応フローを用意
    • どのラベル/オプションを使っているかで切り分けできるようにしておく

まとめ

  • Do Not Forward と暗号化付き感度ラベルでは、メール→添付ファイルへの保護継承を管理者設定で無効化することはできません。これは設計思想として、添付の無保護化が Do Not Forward 等の目的と矛盾するためです。
  • Encrypt‑Only の場合のみ、Set-IRMConfiguration -DecryptAttachmentForEncryptOnly $true により、添付の保護継承を外すことができます。
  • 要件が「添付は保護したくない/相手に自由に編集させたい」のであれば、
    • OneDrive / SharePoint の共有リンク運用
    • メール用ラベルと文書用ラベルの分離
    • トランスポートルールや DLP による送信時ガードレール
    を組み合わせるのが、現行仕様下での現実的な解決策です。

「全部止める」設定は存在しませんが、設計と運用でカバーすれば、ユーザーの利便性と情報保護レベルのバランスを高い水準で両立させることができます。Purview メール保護をこれから本格導入する場合は、Encrypt‑Only の継承設定と、共有リンクを前提にしたメール・ラベル設計を、初期段階でしっかり詰めておくことをおすすめします。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次