外部ユーザーが「暗号化メールの本文は読めるのに、添付ファイルだけ開けない」場合、原因はメール配送や添付ファイルの破損ではなく、Microsoft Purview Message Encryption と Microsoft Entra Conditional Access の設計境界にある可能性があります。
2026年4月14日時点で特に注意したいのは、Purview の暗号化添付ファイルが、厳格な MFA ポリシー下で一部の外部ユーザーに対して失敗するケースです。Microsoft は、Purview のメール／添付ファイル暗号化、MFA 必須、すべてのクラウドアプリ対象、ゲストまたは外部ユーザー対象という条件が重なると、外部ユーザーが暗号化添付ファイルを開けない場合があると説明しています。結論として、対処すべきは暗号化の解除ではありません。Microsoft Rights Management Services（RMS）を含む Conditional Access の適用範囲、クロステナント MFA 信頼、ゲストアカウント運用を再設計することです。(TECHCOMMUNITY.MICROSOFT.COM)
何が起きているのか：メールは開けるが添付ファイルだけ失敗する
この問題の分かりにくい点は、ユーザー体験が一貫していないことです。
外部ユーザーから見ると、次のような状態になります。
| 状況 | ユーザーの見え方 | 管理者が疑うべきポイント |
|---|---|---|
| 暗号化メール本文は読める | OTP、Microsoft アカウント、相手組織の ID などで認証できる | メール暗号化そのものは機能している可能性が高い |
| 添付された Office ファイルだけ開けない | 「アカウントが送信者テナントに存在しない」などのエラーが出る | RMS と Conditional Access の評価でブロックされている可能性 |
| 一部の外部ユーザーだけ失敗する | 取引先 A は開けるが、取引先 B や個人メールでは失敗する | 相手テナントの MFA 信頼、ゲスト登録、ID 種別の差を確認する |
Microsoft Purview の暗号化メールでは、感度ラベルや IRM によってメールが保護されると、添付された Office ドキュメントが権限管理付きの暗号化を継承するケースがあります。Microsoft Learn でも、メール送信時に添付ファイルが暗号化を継承するが、ラベルそのものを継承するわけではないことが説明されています。(Microsoft Learn)
つまり、メール本文の閲覧と添付ファイルの閲覧は、同じ「暗号化メールを開く」操作に見えても、裏側では異なる認証・認可フローになります。ここを同一視すると、トラブルシューティングが遠回りになります。
発生条件：この組み合わせがある環境は優先的に確認する
このエッジケースは、すべての Purview 利用環境で必ず起きるわけではありません。特に注意すべきなのは、次の条件が重なっている環境です。
| 確認項目 | 該当するとリスクが高い状態 |
|---|---|
| メール保護 | Microsoft Purview Message Encryption、感度ラベル、IRM を使ってメールや Office 添付ファイルを暗号化している |
| Conditional Access | MFA 必須ポリシーを構成している |
| 対象リソース | 「すべてのクラウドアプリ」または現在の表記で「すべてのリソース」を対象にしている |
| 対象ユーザー | ゲストユーザー、外部ユーザー、B2B ユーザーを含めている |
| 外部 ID 設計 | 相手テナントの MFA を信頼していない、または外部ユーザーを自テナントのゲストとして登録していない |
| 受信者の種類 | Microsoft Entra ID ではない ID、個人 Microsoft アカウント、OTP、SAML/WS-Fed、Google フェデレーションなどが混在している |
Microsoft の説明では、暗号化メールの閲覧は OTP、Microsoft 個人アカウント、相手組織の ID で成功する場合がある一方、暗号化添付ファイルでは RMS が関与し、送信者側テナントで評価可能な ID が求められるため、厳格な Conditional Access ポリシーでブロックされることがあります。代表的なエラーとして AADSTS90072 が挙げられています。(TECHCOMMUNITY.MICROSOFT.COM)
根本原因：RMS は「メール本文」とは別に Conditional Access で評価される
暗号化添付ファイルを開くとき、Office アプリや対応クライアントは Microsoft Rights Management Services に対して、ファイルを復号・利用するための権利を確認します。
このとき、送信者側テナントの Conditional Access ポリシーが RMS を含んでいると、外部ユーザーに対しても MFA やその他の条件が評価されます。
整理すると、次の流れです。
| フロー | 主な処理 | 失敗しやすい理由 |
|---|---|---|
| 暗号化メール本文を読む | メールポータルや対応クライアントで外部ユーザーを認証 | OTP や個人アカウントでも読める場合がある |
| 暗号化添付ファイルを開く | RMS が利用権限を確認し、Entra ID と Conditional Access が関与 | 外部 ID が送信者テナントで評価できず、MFA 条件を満たせない場合がある |
Microsoft Learn では、Microsoft Rights Management Services を含む Conditional Access ポリシーが外部ユーザーにも適用される場合、相手が自組織の Microsoft Entra アカウントを持っていればクロステナントアクセス設定で MFA 要求を信頼すること、そうでなければ送信者側テナントにゲストアカウントが必要になることが説明されています。これらを満たせない場合は、RMS を Conditional Access ポリシーから外すか、外部ユーザーをポリシー対象から除外する必要があります。(Microsoft Learn)
ここで重要なのは、RMS を外部ユーザー向け Conditional Access ポリシーから除外しても、メールや添付ファイルの暗号化そのものを解除するわけではないという点です。暗号化の強度を落とす話ではなく、RMS への認証フローを外部コラボレーションに合わせて調整する話です。
なぜ外部コラボレーション設計で重要なのか
この問題は、単なる「添付ファイルが開けない」という問い合わせでは終わりません。Messaging admins、compliance admins、IAM teams の間で責任範囲が分かれやすく、対応が遅れると取引先との業務に直接影響します。
特に次のような組織では、設計課題として扱うべきです。
| 組織の状況 | 放置した場合の影響 |
|---|---|
| 海外取引先や委託先に暗号化メールを送る | 相手によって開ける／開けないが発生し、サポート負荷が増える |
| M&A、共同研究、監査対応などで外部共有が多い | 重要ファイルの受け渡しが止まり、代替手段として非承認ツールに流れる |
| 「すべてのユーザー、すべてのクラウドアプリ、MFA 必須」を基本方針にしている | 内部ユーザー向けの強いポリシーが外部ユーザーの RMS 認証を妨げる |
| ゲストアカウントを最小化している | 個別ゲスト登録で回避しにくく、運用が破綻しやすい |
| デバイス準拠や認証強度を外部ユーザーにも厳しく要求している | 相手組織のデバイスや認証方式を評価できず、想定外にブロックされる |
Conditional Access は「誰が、どのリソースに、どの条件でアクセスするか」を制御する仕組みです。Microsoft Learn でも、ポリシーの割り当てではユーザーやグループ、外部ゲストユーザー、対象リソース、条件、アクセス制御を組み合わせて評価すると説明されています。(Microsoft Learn)
そのため、内部ユーザー向けに正しいポリシーでも、外部ユーザー向けには過剰に厳しい、または実行不能な条件になることがあります。
まず確認すべきトラブルシューティング項目
問い合わせを受けたら、最初に「添付ファイルの問題」だけを見ないことが重要です。メール管理、Purview、Entra ID、Conditional Access を横断して確認します。
| 確認項目 | 見るべき内容 | 判断のポイント |
|---|---|---|
| エラーメッセージ | AADSTS90072、アカウントが送信者テナントに存在しないという表示 | RMS 認証時に外部 ID を評価できていない可能性 |
| 対象ユーザー | 受信者が Entra ID、Microsoft 個人アカウント、OTP、Google、SAML/WS-Fed のどれか | 認証強度や MFA 信頼が使える範囲が変わる |
| Entra サインインログ | アプリケーションが Microsoft Rights Management Services になっているか | メール本文ではなく RMS 側で失敗しているかを確認 |
| 適用された CA ポリシー | 外部ユーザーを含む MFA 必須ポリシー、すべてのリソース対象の有無 | RMS が意図せず対象に入っていないかを確認 |
| クロステナントアクセス設定 | 相手組織の MFA claim を信頼しているか | 既知の取引先なら MFA 信頼で解決できる可能性 |
| ゲストアカウント | 受信者が送信者テナントにゲストとして存在するか | 個別ユーザー単位の制御で解決できる可能性 |
| デバイス条件 | 準拠済みデバイス、Hybrid Join、アプリ保護ポリシーを要求していないか | 外部ユーザーでは満たせない条件になりやすい |
Microsoft Learn では、RMS のアプリケーション ID として 00000012-0000-0000-c000-000000000000 が示されています。クロステナントアクセス設定でアプリ単位の制限を行っている場合、この Microsoft Rights Management Services へのアクセスを許可しないと、暗号化コンテンツを開くための認証・認可ができません。(Microsoft Learn)
対応方針は外部ユーザーの種類で分ける
すべての外部ユーザーに同じ設計を当てはめると、どこかで破綻します。実務では、受信者の種類と共有パターンで対応を分けるのが現実的です。
| 外部コラボレーションの種類 | 推奨アプローチ | 向いているケース | 注意点 |
|---|---|---|---|
| 既知の大口取引先、グループ会社 | クロステナントアクセス設定で MFA 信頼を構成 | 相手が Microsoft Entra テナントを持ち、継続的に共有する | 信頼対象を広げすぎない。相手組織の MFA 運用水準を確認する |
| 少数の特定ユーザー | 送信者テナントにゲストアカウントを作成 | 監査法人、顧問、特定委託先など | 招待、失効、アクセスレビューの運用が必要 |
| 不特定多数の外部受信者 | 外部ユーザー向け CA ポリシーを分け、RMS を除外する | 顧客、候補者、個人メール、取引先が頻繁に変わる業務 | 除外理由を文書化し、内部ユーザー向けポリシーとは分離する |
| 高機密・規制対象データ | メール添付以外の共有方式も検討 | 契約書、個人情報、研究データ、金融・医療関連情報 | SharePoint/OneDrive の B2B 共有、アクセスレビュー、期限付き共有などを組み合わせる |
Microsoft は、外部ユーザーが暗号化コンテンツを開く要件を満たせない場合、Microsoft Rights Management Services を Conditional Access ポリシーから外すか、外部ユーザーをポリシーから除外する必要があると説明しています。ここでのポイントは、内部ユーザー向けの MFA 強制を維持しながら、外部ユーザー向けの評価だけを分離することです。(Microsoft Learn)
推奨される Conditional Access 設計パターン
安全に運用するには、「内部ユーザー向けポリシー」と「外部ユーザー向けポリシー」を分けて考えます。
内部ユーザー向けポリシーは強く保つ
内部ユーザーには、従来どおり強い MFA 要求を維持します。
| 設定項目 | 推奨例 |
|---|---|
| 対象ユーザー | 社内ユーザー、管理者、必要な内部グループ |
| 対象リソース | すべてのリソース。RMS を含める |
| アクセス制御 | MFA、認証強度、リスクベース制御など |
| 除外 | 緊急アクセス用アカウントなど、最小限 |
| 運用 | Report-only で影響確認後に有効化 |
Microsoft のゲスト MFA ポリシー手順でも、緊急アクセス用アカウントを除外し、まず Report-only で確認してから有効化する流れが示されています。(Microsoft Learn)
外部ユーザー向けポリシーは RMS の扱いを明示する
外部ユーザー向けには、次のように分けて設計します。
| 設定項目 | 推奨例 |
|---|---|
| 対象ユーザー | Guest and external users の必要なサブタイプ |
| 対象リソース | 原則は必要なクラウドアプリを対象にする |
| RMS の扱い | 要件を満たせない外部ユーザーがいる場合、Microsoft Rights Management Services を除外候補にする |
| MFA | 対応可能な外部 ID には MFA を要求する |
| 既知の取引先 | クロステナント MFA 信頼を優先的に検討する |
| デバイス条件 | 相手テナントのデバイス claim を信頼できない限り、外部ユーザー全体には安易に要求しない |
RMS のアプリケーション ID は次の値です。
00000012-0000-0000-c000-000000000000Microsoft Security Community Blog では、内部ユーザーには RMS を含めて MFA を維持し、外部ユーザー向けの別ポリシーでは RMS を評価対象から除外する考え方が紹介されています。(TECHCOMMUNITY.MICROSOFT.COM)
クロステナント MFA 信頼を使うべきケース
既知の取引先やグループ会社との継続的なコラボレーションでは、RMS を除外する前に、クロステナントアクセス設定で MFA claim を信頼できるかを検討します。
Microsoft Entra の外部 ID では、リソーステナント側が相手テナントの MFA claim やデバイス claim を信頼する設定を構成できます。MFA 信頼が有効な場合、外部ユーザーが自分のホームテナントで MFA を満たしていれば、リソーステナント側のアクセスでその claim を評価できます。(Microsoft Learn)
ただし、これは「すべての外部組織を信頼する」という意味ではありません。次の観点で判断します。
| 判断基準 | 確認内容 |
|---|---|
| 相手組織の ID 管理 | Microsoft Entra ID を利用しているか |
| MFA の水準 | 自社が求める MFA 強度を満たせるか |
| 契約関係 | 継続的な取引先、委託先、グループ会社か |
| 監査要件 | 信頼設定の理由を説明できるか |
| 例外管理 | 信頼を解除する条件やタイミングが決まっているか |
相手が Microsoft Entra テナントを持たない、または個人メール、OTP、Google、SAML/WS-Fed などが混在する場合は、認証強度ポリシーだけで一律に解決しようとすると失敗しやすくなります。Microsoft Learn では、認証強度ポリシーを外部ユーザーに適用できるのは Microsoft Entra ID で認証する外部ユーザーであり、メール OTP、SAML/WS-Fed、Google フェデレーションでは MFA grant control を使うよう説明されています。(Microsoft Learn)
ゲストアカウントで解決すべきケース
少数の外部ユーザーであれば、送信者テナントにゲストアカウントを作成する方法も有効です。
例えば、次のようなケースです。
| ケース | ゲストアカウントが向いている理由 |
|---|---|
| 監査法人に毎月暗号化レポートを送る | 対象者が少なく、変更頻度も低い |
| 顧問弁護士に契約書を共有する | 個別ユーザー単位で権限管理しやすい |
| 共同研究先の固定メンバーと共有する | アクセスレビューや期限管理を適用しやすい |
一方で、顧客全般、採用候補者、多数の委託先、スポット取引先などに対して毎回ゲストを作る運用は、すぐに破綻します。ゲストアカウントには、招待、本人確認、権限付与、定期レビュー、退職・契約終了時の削除が必要です。
「とりあえずゲストにすれば開ける」という運用は、短期的な回避策にはなっても、長期的にはアカウント棚卸しの負債になります。
外部ユーザーにデバイス条件を要求するときの注意点
外部ユーザーに対して、準拠済みデバイスや Microsoft Entra hybrid joined device を要求する設計は慎重に扱う必要があります。
Microsoft Learn では、外部ユーザーのデバイスは通常、リソース組織ではなくホーム組織によって管理されるため、相手テナントのデバイス claim を信頼する意思がない限り、外部ユーザーに管理済みデバイスを要求する Conditional Access ポリシーは推奨されないと説明されています。(Microsoft Learn)
暗号化添付ファイルのトラブルで、次のような条件が入っている場合は要注意です。
| 条件 | 外部ユーザーで起きやすい問題 |
|---|---|
| 準拠済みデバイス必須 | 相手の端末を自社 Intune で管理していないため評価できない |
| Hybrid Join 必須 | 相手組織の端末参加状態を自社が確認できない |
| アプリ保護ポリシー必須 | 外部ゲストに適用できない、または運用負荷が高い |
| 認証強度を一律に要求 | OTP や Google フェデレーション利用者では満たせない場合がある |
外部ユーザーに強い条件を課すこと自体は間違いではありません。ただし、相手がその条件を技術的に満たせるかを確認せずに適用すると、セキュリティ強化ではなく業務停止になります。
安全に変更するための実務手順
既存の Conditional Access を変更する場合、いきなり本番ポリシーを編集しないでください。特に RMS は暗号化コンテンツの閲覧に関わるため、影響範囲を誤ると内部ユーザーや他の外部共有にも影響します。
現状把握
最初に、次の情報を洗い出します。
| 項目 | 確認内容 |
|---|---|
| 送信元 | どの部署、どのメールフロー、どの感度ラベルで送っているか |
| 受信者 | ドメイン、相手テナント、個人アカウント、OTP 利用の有無 |
| ファイル | Office 添付ファイルか、他形式か、どのアプリで開いているか |
| エラー | 画面表示、エラーコード、発生日時 |
| サインインログ | 失敗しているアプリ、適用 CA ポリシー、失敗理由 |
| CA ポリシー | 外部ユーザー、すべてのリソース、MFA、デバイス条件の有無 |
影響の大きいポリシーを特定する
特に確認すべきなのは、次のようなポリシーです。
| ポリシー例 | リスク |
|---|---|
| All users + All resources + Require MFA | 外部ユーザーや RMS まで広く巻き込む |
| Guest and external users + All resources + Require MFA | 暗号化添付ファイルの RMS 認証で失敗しやすい |
| Guest and external users + Require compliant device | 相手デバイスを評価できずブロックしやすい |
| External users + Authentication strength | Microsoft Entra ID 以外の外部 ID で満たせない場合がある |
| Cross-tenant access で全アプリを既定ブロック | RMS アプリを許可していないと暗号化コンテンツを開けない |
Microsoft Learn のトラブルシューティングでも、クロステナントアクセス設定で既定ですべてのアプリをブロックしている場合、Microsoft Rights Management Service のアプリ ID を許可しないと、OME とも呼ばれる暗号化メールを読めなくなると説明されています。(Microsoft Learn)
Report-only または限定グループで検証する
変更案は、次のような小さな範囲で検証します。
| テストケース | 期待結果 |
|---|---|
| 社内ユーザーが暗号化添付ファイルを開く | 引き続き MFA が要求され、正常に開ける |
| 既存ゲストユーザーが開く | ゲストアカウントと MFA 条件を満たせば開ける |
| MFA 信頼済みの取引先が開く | 相手テナントの MFA claim を利用して開ける |
| OTP または個人アカウント利用者が開く | 外部ユーザー向け RMS 除外設計で開けるか確認する |
| 未承認の外部ユーザーが開く | 暗号化権限がない場合は開けない |
ここで見るべきなのは、「全員が開けるようになったか」ではありません。権限を持つ外部ユーザーだけが、意図した認証フローで開けるかです。
やってはいけない対応
暗号化添付ファイルの問い合わせは緊急度が高くなりがちですが、場当たり的な対応は避けるべきです。
| NG対応 | 問題点 |
|---|---|
| Purview の暗号化を一時的に外して再送する | 情報保護ポリシーを迂回し、監査上の説明が難しくなる |
| 全外部ユーザーを一括で CA から除外する | MFA やリスク制御が広く効かなくなる |
| 全外部テナントの MFA claim を無条件に信頼する | 相手組織の認証水準を検証できない |
| ゲストアカウントを大量作成して放置する | 退職者、契約終了者、不要アカウントが残る |
| デバイス準拠を外部ユーザー全体に強制する | 相手端末を評価できず、正当な利用者もブロックする |
| サインインログを見ずにメール暗号化設定だけ変更する | 本当の失敗箇所が RMS／CA であることを見落とす |
特に「暗号化を外して送れば業務は進む」という判断は危険です。短期的には解決したように見えても、同じ問題が別の取引先で再発します。さらに、機密情報をどの条件で外部共有してよいかという統制も曖昧になります。
セキュリティを弱めずに外部共有を成立させる考え方
この問題の本質は、「暗号化」と「アクセス条件」を同じ強度で全員に当てれば安全になる、という単純な話ではありません。
実務では、次のように分けて考える必要があります。
| 設計要素 | 内部ユーザー | 外部ユーザー |
|---|---|---|
| MFA | 強制する | 可能な方式で強制する。相手テナント MFA 信頼も検討 |
| RMS | CA の対象に含める | 要件を満たせない受信者がいる場合は外部ポリシーで除外候補 |
| デバイス条件 | 自社管理デバイスを前提に設計可能 | 相手テナントの claim を信頼できる場合のみ慎重に適用 |
| ゲスト管理 | 原則不要 | 少数・高信頼の外部ユーザーには有効 |
| 不特定外部共有 | 通常は対象外 | メール添付だけでなく、共有基盤や期限付きアクセスも検討 |
Microsoft Security Community Blog の要点も、暗号化を弱めることではなく、暗号化コンテンツがどのように評価されるかに合わせて Conditional Access を設計することにあります。(TECHCOMMUNITY.MICROSOFT.COM)
よくある質問
添付ファイルの暗号化だけを無効化すればよいですか？
基本方針としてはおすすめしません。感度ラベルや IRM によって保護されたメールでは、Office 添付ファイルが権限管理付き暗号化を継承する設計があります。問題は「添付ファイルが暗号化されること」ではなく、外部ユーザーが RMS 認証時に Conditional Access 条件を満たせないことです。まずは CA、クロステナント MFA 信頼、ゲスト運用を確認すべきです。(Microsoft Learn)
RMS を外部ユーザー向け CA ポリシーから除外すると危険ですか？
除外の仕方によります。内部ユーザー向けポリシーから RMS を外すのではなく、外部ユーザー向けに分けたポリシーで、必要な範囲だけ RMS の評価を調整するのが現実的です。暗号化されたコンテンツの権限管理は維持されます。ただし、除外理由、対象範囲、代替統制は文書化してください。
クロステナント MFA 信頼とゲストアカウントはどちらを選ぶべきですか？
継続的にやり取りする既知の Microsoft Entra テナントなら、クロステナント MFA 信頼を優先的に検討します。少数の特定ユーザーであれば、ゲストアカウントでも管理できます。不特定多数や個人アカウントが多い場合は、ゲスト登録だけで解決しようとせず、外部ユーザー向け Conditional Access 設計を分ける方が現実的です。
AADSTS90072 はパスワードや MFA の入力ミスですか？
入力ミスとは限りません。この文脈では、外部ユーザーのアカウントが送信者側テナントで評価できない、または必要なゲスト登録・MFA 信頼がないために、暗号化添付ファイルの RMS 認証で失敗している可能性があります。メール本文が読めている場合でも、添付ファイルを開くフローは別に確認してください。(TECHCOMMUNITY.MICROSOFT.COM)
すべてのクラウドアプリに MFA をかける方針は間違いですか？
方針自体が間違いとは限りません。Microsoft の手順でも、ゲストや外部ユーザーを対象に、すべてのリソースへ MFA を要求する構成例はあります。ただし、対象外にすべきアプリケーションや外部ユーザーの認証方式を考慮せずに一律適用すると、RMS のような依存サービスで想定外のブロックが起きます。(Microsoft Learn)
まず取るべきアクション
暗号化添付ファイルの外部ユーザー問題に対応するなら、最初に次の順番で確認してください。
| 優先度 | アクション |
|---|---|
| 高 | Entra サインインログで、失敗しているアプリが Microsoft Rights Management Services か確認する |
| 高 | 外部ユーザーを含む MFA 必須 CA ポリシーが、すべてのリソースを対象にしていないか確認する |
| 高 | 相手が Microsoft Entra テナントか、個人アカウントや OTP かを分類する |
| 中 | 既知の取引先にはクロステナント MFA 信頼を検討する |
| 中 | 少数の固定ユーザーにはゲストアカウント運用を検討する |
| 中 | 不特定多数の外部共有には、外部ユーザー向け CA ポリシーを分け、RMS の扱いを明示する |
| 低 | 暗号化設定そのものを変更する前に、代替共有手段と監査要件を確認する |
このエッジケースは、Messaging admins だけでも、compliance admins だけでも、IAM teams だけでも解決しにくい問題です。メール暗号化、感度ラベル、RMS、Conditional Access、外部 ID の接点で起きるため、チーム横断で「外部ユーザーが暗号化添付ファイルを開くための標準設計」を決めておくことが重要です。
社外コラボレーションを安全に成立させるには、暗号化を強くするだけでは不十分です。誰が、どの ID で、どの認証条件を満たし、どのサービスを経由して暗号化コンテンツを開くのかを設計に落とし込む必要があります。まずは、外部ユーザーを含む Conditional Access ポリシーと RMS の適用状況を確認し、既知パートナー、少数ゲスト、不特定外部受信者の3パターンに分けて改善してください。
コメント