Outlookのメッセージ取り消しは、これまで「同じ組織内で送ったメールを取り消す機能」と考えるのが基本でした。今回の Exchange Online Cross-tenant Message Recall では、相手組織が自社テナントを許可リストに追加している場合、他組織宛てのメールも取り消し対象にできる予定です。つまり、社外メールを無条件に取り消せる機能ではなく、相手テナント側の許可がある外部組織との間で使えるリコール機能と理解するのが重要です。Microsoft 365 Roadmapではこの機能が開発中として案内され、ロールアウト開始は2026年8月予定とされていますが、Roadmap上の時期や内容は変更される可能性があります。(Microsoft)
OutlookのCross-tenant Message Recallで変わること
Exchange OnlineのMessage Recallは、送信済みメールを受信者のメールボックスから削除、または差し替えようとする機能です。現行のクラウドベースのメッセージ取り消しでは、Outlookクライアントからの操作をきっかけに、Exchange Online側のエージェントがリコールメッセージを処理し、受信者メールボックス内の元メッセージを削除します。差し替えを選んだ場合は、元メッセージを削除したうえでOutlookが新しいメッセージを通常配送します。(Microsoft Learn)
今回の変更点は、取り消し対象の境界が「同一組織内」から「許可された他テナント」へ広がることです。特に、グループ会社、業務委託先、重要顧客など、Microsoft 365同士で日常的にやり取りする組織では、誤送信対応の選択肢が増えます。
| 観点 | これまで | Cross-tenant Message Recall導入後の考え方 |
|---|---|---|
| 取り消し対象 | 基本的に同一組織内の受信者 | 相手組織が自社テナントをrecall allow listに追加している場合、他組織宛ても対象になり得る |
| ユーザー操作 | Outlookから送信済みメールを開き、リコールを実行 | 基本操作は従来のMessage Recallの流れを踏襲する見込み |
| 管理者の関与 | テナント内のMessage Recall有効化、既読メッセージの取り消し設定など | 既存設定に加え、外部テナントを許可する運用ルールの整備が重要 |
| 誤解しやすい点 | 「社内なら取り消せることがある」 | 「社外でも必ず取り消せる」わけではない。相手側の許可と条件が前提 |
影響を受ける対象者
この変更は、単にOutlookのボタンが増えるという話ではありません。外部組織とのメール運用、監査、サポート対応に影響します。
エンドユーザー
営業、採用、法務、経理、カスタマーサポートなど、社外宛てメールを頻繁に送るユーザーは恩恵を受けやすいです。たとえば、添付ファイル漏れ、宛先間違い、古い見積書の送付などで、相手組織が許可していればリコールを試せる可能性があります。
ただし、リコールは「送信前に戻す」機能ではありません。受信者が転送したメール、外部へ自動転送されたメール、別システムに保存されたコピーまで必ず消せるわけではありません。現行のMessage Recallでも、手動転送されたメッセージや受信トレイ規則による転送メッセージなどは取り消し対象外とされています。(Microsoft Learn)
Exchange Online管理者
管理者は、既存のMessage Recall設定と、今後追加されるクロステナント向けの許可リスト運用を分けて考える必要があります。
現行のクラウドベースMessage Recallでは、管理者が制御できる主な設定として、機能の有効・無効と、既読メッセージを取り消すかどうかがあります。Exchange Online PowerShellでは、次のような設定が案内されています。(Microsoft Learn)
Set-OrganizationConfig -MessageRecallEnabled <$true | $false> -RecallReadMessagesEnabled <$true | $false>既定値が空欄の場合は有効相当として扱われ、設定変更の反映には約1時間かかるとされています。展開前には、現在の自社設定がどうなっているかを確認しておきましょう。(Microsoft Learn)
セキュリティ・コンプライアンス担当者
Cross-tenant Message Recallは、誤送信時の被害を減らす助けになりますが、監査や情報保護の代替にはなりません。現行仕様では、訴訟ホールドやインプレースホールドの対象メールボックスでは、取り消されたメッセージもeDiscoveryに表示されるとされています。一方で、メールボックス監査ログには現時点でリコールが記録されないとされています。(Microsoft Learn)
そのため、情報漏えい対策としては、リコールだけに頼らず、DLP、秘密度ラベル、暗号化、送信前警告、外部宛先確認などと組み合わせるべきです。
開発者・システム連携担当者
メールアーカイブ、チケット管理、DLP、SIEM、メールゲートウェイ、カスタム監視ツールを運用している場合は、リコールメッセージの扱いに注意が必要です。現行のMessage Recallでは、リコール要求メッセージのメッセージクラスは IPM.Outlook.Recall、件名は Recall: <Original Subject> となり、Exchange Online側のエージェントが処理します。(Microsoft Learn)
開発・運用側では、こうしたリコール要求を通常の迷惑メールや不要メールとして誤って削除・隔離しないよう、メールフローやログ処理を確認しておくと安全です。
管理者がまず確認すべき設定
Cross-tenant Message Recallの詳細な管理UIやPowerShell設定は、一般提供に向けて追加情報が出る可能性があります。ただし、今から確認できることはあります。
既存のMessage Recallが有効か確認する
まず、テナント内でクラウドベースMessage Recallを無効化していないかを確認します。特に過去に「既読メールまで取り消されるのは困る」として設定を変更した組織では、現状のポリシーを棚卸ししておく必要があります。
確認観点は次の3つです。
| 確認項目 | 見るべきポイント |
|---|---|
| Message Recallの有効・無効 | テナント全体で機能が無効化されていないか |
| 既読メッセージの取り消し | 既読メールのリコールを許可するか、未読相当に限定するか |
| 反映時間 | 設定変更後、すぐに結果を判断せず約1時間程度の反映時間を見込む |
リコールレポートが届くか確認する
リコールを実行すると、送信者にはMessage Recall Reportへのリンクを含むメールが届きます。現行仕様では、リコールレポートは [email protected] から送信されるため、この送信元がブロックまたは隔離されていないか確認が必要です。レポートが届かない場合、管理者はメッセージトレースでブロックや隔離の有無を確認できます。(Microsoft Learn)
また、リコール状況は通常数分で確認できますが、受信者数が多い場合は時間がかかることがあります。現行仕様では、システムは最大24時間リコールを継続して試行します。(Microsoft Learn)
共有メールボックスの運用を確認する
共有メールボックスや代理送信を使っている部門では、リコール後のレポート確認でつまずきやすくなります。現行仕様では、共有または代理メールボックスから送信したメッセージもリコールできる場合がありますが、レポートの閲覧に制約があるケースが案内されています。(Microsoft Learn)
代表アドレスを使う営業窓口、採用窓口、問い合わせ窓口では、誰が送信済みアイテムを確認し、誰がリコールレポートを見るのかを事前に決めておきましょう。
recall allow listの運用で決めるべきこと
Cross-tenant Message Recallの最大のポイントは、相手組織が自社テナントをrecall allow listに追加する必要がある点です。これはセキュリティ上自然な設計です。外部の送信者が一方的に受信者メールボックス内のメッセージ削除を試みられると、業務証跡や法務上の問題が起きるためです。
管理者は、次のような基準で許可リストの方針を作ると実務に落とし込みやすくなります。
| 判断基準 | 許可しやすい例 | 慎重に扱う例 |
|---|---|---|
| 継続的な取引関係 | グループ会社、常駐委託先、長期契約の重要顧客 | 一度だけやり取りする取引先 |
| 情報の機密性 | 共同プロジェクトで誤送信リスクが高い相手 | 契約関係が曖昧な外部組織 |
| 運用責任者 | 双方にIT管理者・セキュリティ窓口がある | 緊急時の連絡先が不明 |
| 監査・法務 | リコール運用の合意を文書化できる | 証跡保持の考え方が不明確 |
| 棚卸し | 四半期や半年ごとに見直せる | 追加後に放置される可能性が高い |
ポイントは、「便利だから広く許可する」ではなく、業務上必要な相手だけを許可し、定期的に見直すことです。
ユーザーに伝えるべき注意点
Cross-tenant Message Recallを展開する際は、ユーザー教育が欠かせません。特に「社外メールも取り消せるようになった」とだけ伝えると、誤解が広がります。
必ず成功する機能ではない
Message Recallは、送信済みメールを取り消せる可能性を高める機能です。受信者の環境、メールの状態、転送、保持設定、保護設定などによって結果は変わります。
Microsoft Supportでも、Outlookのリコールでは成功・保留・失敗をMessage Recall Reportで確認する流れが案内されています。(Microsoft サポート)
ユーザー向けには、次のように説明すると誤解を防げます。
社外宛てでも、相手組織が許可している場合はリコールを試せます。ただし、相手のメール環境や転送状況によって失敗することがあります。機密情報を送った場合は、リコールだけで済ませず、必ず管理者またはセキュリティ窓口へ連絡してください。
個人向けOutlook.comとは別物
Outlook.com、Hotmail、Gmailなどの個人向けメールでは、Exchange OnlineのMessage Recallとは異なる考え方になります。Microsoft Supportでは、Outlook.comでは送信後のメッセージリコールは利用できず、代わりに送信を数秒遅らせる「Undo Send」を使う説明がされています。(Microsoft サポート)
社内マニュアルでは、「Outlookの取り消し」と「送信取り消しの猶予時間」を混同しないようにしましょう。
展開前に作成しておきたい運用ルール
管理者は、一般提供の直前に慌てて設定するのではなく、今のうちに運用ルールを作っておくとスムーズです。
許可リスト申請フロー
外部テナントを許可する場合、誰が申請し、誰が承認し、どの期間有効にするかを決めます。
実務では、次のような申請項目を用意すると判断しやすくなります。
| 申請項目 | 記入例 |
|---|---|
| 相手組織名 | 株式会社〇〇 |
| 目的 | 共同プロジェクトにおける誤送信対応 |
| 期間 | 契約終了月の翌月末まで |
| 自社責任者 | 情報システム部 〇〇 |
| 相手側窓口 | 相手組織のMicrosoft 365管理者 |
| 承認者 | 情報セキュリティ責任者、法務担当など |
誤送信時の一次対応
ユーザーがリコールを実行しただけで対応完了にしないルールが必要です。特に、個人情報、契約情報、未公開情報、認証情報を含むメールでは、リコール結果を待つだけでは不十分です。
おすすめの一次対応は次の流れです。
| 手順 | 対応内容 |
|---|---|
| 送信者 | 送信済みメールからリコールを実行し、レポートを確認する |
| 送信者 | 上長または情報システム部へ報告する |
| 管理者 | Message Recall Reportとメッセージトレースを確認する |
| セキュリティ担当 | 情報の種類、相手先、再拡散リスクを評価する |
| 必要に応じて | 相手組織へ削除依頼、事故報告、再発防止策を実施する |
ログと証跡の扱い
リコール結果を確認する場合、Message Recall Reportだけでなく、メッセージトレースの見方も理解しておく必要があります。現行仕様では、リコールが成功した場合でも、トランスポートでリコールメッセージがドロップされるため、メッセージトレース上のStatus値だけでは判断を誤る可能性があります。詳細イベントのResult値を確認する必要があります。(Microsoft Learn)
ヘルプデスク向け手順書には、「StatusがFailedだからリコール失敗」と即断しないことを明記しておきましょう。
開発者・連携システム担当者のチェックポイント
メール関連の自動処理を組んでいる組織では、Cross-tenant Message Recallの導入で思わぬ影響が出る可能性があります。
| 領域 | 確認ポイント |
|---|---|
| メールゲートウェイ | IPM.Outlook.Recall のメッセージを不審メールとして隔離していないか |
| アーカイブ製品 | リコール後も保存コピーが残る前提で監査設計されているか |
| DLP・秘密度ラベル | リコールに頼らず、送信前ブロックや警告を継続できるか |
| SIEM・ログ基盤 | リコール成功・失敗の判断に必要なイベントを取り込めるか |
| Outlookアドイン | 送信前チェック、外部宛先警告、添付漏れ確認などを強化できるか |
| ヘルプデスクツール | リコールレポート、メッセージトレース、ユーザー申告を同じチケットで追跡できるか |
特に重要なのは、リコールを「削除完了イベント」として扱わないことです。取り消しが成功しても、受信者が転送したコピー、別システムのアーカイブ、保持ポリシー上のコピーが残る可能性があります。現行仕様でも、ホールド対象のメールはeDiscoveryに表示されるとされています。(Microsoft Learn)
導入時に失敗しやすいポイント
社外メールを何でも取り消せると案内してしまう
最も危険なのは、ユーザーに「社外メールも取り消せます」とだけ伝えることです。正しくは、「相手組織が許可しており、かつ条件を満たす場合にリコールを試せる」です。
許可リストを広げすぎる
相手組織を広く許可しすぎると、後から棚卸しできなくなります。最初は重要な取引先やグループ会社など、管理責任を共有しやすい相手に絞るのが現実的です。
レポートメールをブロックしている
リコール結果を確認できなければ、ユーザーも管理者も次の判断ができません。[email protected] からのレポートが届くか、展開前にテストしておきましょう。(Microsoft Learn)
送信前対策を弱めてしまう
リコール機能が強化されても、誤送信を未然に防ぐ対策は引き続き必要です。外部宛先警告、添付ファイル確認、秘密度ラベル、DLP、送信遅延、承認フローは、Cross-tenant Message Recallと競合するものではなく補完関係にあります。
今すぐ進めるべき準備
Cross-tenant Message Recallは、誤送信対応の選択肢を広げる重要な変更です。ただし、効果を出すには設定だけでなく、相手組織との合意、社内ルール、ユーザー教育、ログ確認手順が必要です。
まずは次の順番で準備しましょう。
- 現在のMessage Recall設定を確認する
- 既読メッセージの取り消しを許可するか社内方針を決める
- リコールレポートが届くか確認する
- 外部テナントを許可する判断基準を作る
- グループ会社や主要取引先との運用合意を検討する
- ユーザー向けに「成功を保証する機能ではない」と明記した案内を用意する
- ヘルプデスク向けにメッセージトレース確認手順を整備する
OutlookのCross-tenant Message Recallは、誤送信後の被害を減らす助けになります。しかし、リコールは最後の安全網であり、送信前の確認や情報保護を置き換えるものではありません。一般提供までに、許可リストの方針とサポート手順を整えておくことが、管理者にとって最も実務的な準備です。
コメント