【2026年版】Outlook送信取り消しの方法｜成功する条件と、社外への誤送信を防ぐ設定

メールは日常業務に不可欠ですが、宛先の選択ミス、CC／BCCの設定ミス、添付ファイルの付け忘れ・取り違え、本文の誤記、送信先グループの選択ミスは誰にでも起こり得ます。誤送信は単なるケアレスミスでは済まず、個人情報や機密情報の漏えい、取引先からの信用低下、調査・報告などの対応コストにつながるおそれがあります。

Outlookには、一定の条件下で送信済みメールの削除を試行できるメッセージリコール（Message Recall）があります。ただし、すべてのメールを確実に取り消せる機能ではありません。特に社外宛てのメールは原則として送信側から回収できません。

送信取り消しは最後のセーフティネットと考え、配信前に止める、送信するデータを必要最小限にする、配信後にファイル・コンテンツへのアクセスを止める、事故発生時に結果を追跡するという多層的な対策を設計することが重要です。

本記事では、Outlookで送信取り消しができる条件と操作方法、社外への誤送信を防ぐ送信遅延・Undo Sendの設定、組織として整えたい技術・運用の対策を解説します。

Outlook送信取り消しをできる条件

Outlookで送信取り消しができるといっても、すべてのメールを取り消せるわけではありません。条件に当てはまらない場合や、取り消し結果が失敗した場合は、社内ルールに沿って速やかに報告し、必要に応じて相手への連絡、再送、共有アクセスの停止、情報漏えい時の対応を進めましょう。

1. 法人向けのMicrosoft 365を利用している場合

メッセージリコールを利用するには、原則としてExchange Onlineを利用する法人向けMicrosoft 365環境であることが前提です。個人向けMicrosoft 365、一般的なプロバイダーメール、Gmailなどの外部メールサービスに送ったメールを、Outlook側から削除することはできません。

Exchange Onlineを利用していても、組織の管理者がリコール関連の機能を制限している場合があります。自社アカウントが対象か、利用中のOutlookクライアントで操作・結果確認ができるかは、Microsoft 365管理センターまたは情報システム部門に確認してください。

2. 原則として同じ組織内の宛先である場合

Exchange Onlineのメッセージリコールは、同一のMicrosoft 365テナント内、つまり同じ組織に所属する受信者へ送ったメールが基本的な対象です。社内の同僚や同一テナント内の部門宛てであれば、クラウド型リコールを利用できる可能性があります。

社外宛てのメールは通常、送信側が別組織・別サービスのメールボックスから配信済みメールを削除する仕組みがないため、原則として取り消せません。

ただしMicrosoftは、異なるMicrosoft 365テナント間でリコールを処理するCross-Tenant Message Recallを2026年8月中旬から9月中旬にかけて段階的に展開すると案内しています。2026年9月13日時点では展開完了予定時期に近づいていますが、利用可否はテナントごとに確認が必要です。管理者はMicrosoft 365 Message Center、Exchange Online PowerShell、検証用メールで実際の動作を確認してください。

この機能は、Microsoft 365同士なら社外メールを自由に回収できるものではありません。送信側・受信側の双方がExchange Onlineを利用していることに加え、受信側テナントの管理者が機能を有効化し、送信側テナントIDを許可リストに登録していることが必要です。既定では無効であり、制御主体は送信側ではなく受信側テナントです。Gmail、Outlook.com、Yahooメール、Proton Mailなど、Exchange Online外のメールボックスは対象になりません。

Set-CrossTenantRecallConfiguration -CrossTenantRecallEnabled $true

Set-CrossTenantRecallConfiguration `
  -AllowedSenderTenantIds @{Add="<送信側テナントID>"}

Get-CrossTenantRecallConfiguration

この設定は、自社から相手へ送ったメールを一方的に取り消せるようにするものではありません。他社が自社ユーザーのメールボックスに対してリコールを実行することを許可する設定です。グループ会社、親子会社、継続的な委託先などとの間で双方向に運用する場合は、双方の受信側テナントで相手を許可する相互設定が必要です。

許可リストには、契約関係やデータ共有関係が明確な組織だけを登録しましょう。許可申請者、承認者、設定実施者を分離し、契約終了、M&A、テナント移行、組織再編時には許可設定を削除する手順を定めます。機密情報を「後からリコールできる」前提で平文送信する運用は禁止すべきです。

3. 受信者のメールボックスと管理者設定がリコールに対応している場合

従来のOutlookのリコールでは、対象メールが未読であることが重要な条件として案内されてきました。しかし、Exchange Onlineのクラウド型リコールでは、管理者設定によって既読メールも削除対象にできます。既読メールを対象にする設定であるRecallReadMessagesEnabledは、未設定の場合も有効相当として扱われます。

そのため、「未読でなければ取り消せない」と一律に考えるのは、現在のクラウド型リコールの仕様とは一致しません。Microsoftの一般利用者向けサポートとExchange Online管理者向け文書では、未読メールや組織間リコールに関する説明が一致しない部分もあります。一般向けWebページだけで判断せず、管理者は自社テナントの設定と実機テストで確認してください。

なお、既読メールをメールボックスから削除できたとしても、受信者がすでに内容を閲覧、保存、転送、複写、画面撮影している可能性までは消せません。リコールの成功は、情報漏えいがなかったことを意味しない点に注意が必要です。

また、クラシックOutlookでは、OutlookがOnline modeで動作している場合や、1つのOutlookプロファイルに複数のExchangeアカウントを設定している場合、リコールが正常に動作しないことがあります。共有・委任メールボックスでは、リコール自体が成功しても、所有メールボックスによる認証上の制約からMessage Recall Reportを開けない場合があります。重要な共通メールボックスや複雑なメール環境では、事前テストを実施してください。

Outlook送信取り消しの方法

条件に当てはまる場合は、誤送信に気付いた時点でできるだけ早く取り消し操作を行いましょう。時間が経つほど、受信者が閲覧・保存・転送する可能性は高まります。

クラシックOutlookでは、まず送信済みアイテムから対象メールを開きます。閲覧ウィンドウではなく、メールをダブルクリックして別ウィンドウで開いてください。

クラシックリボンでは、［メッセージ］タブの［移動］グループから［その他の移動アクション］を開き、［このメッセージを呼び戻す］を選択します。簡易リボンでは、［その他のコマンド］から［アクション］、［このメッセージを呼び戻す］の順に選択します。表示名や配置はMicrosoft 365 Appsのビルドによって異なる場合があります。

表示される画面で削除を実行すると、リコール要求が送信されます。画面に「未読ならば、受信トレイから削除する」と表示される場合がありますが、クラウド型リコールでは既読メールの扱いを管理者設定で制御できます。画面の文言だけで成功条件を判断しないようにしましょう。

新しいOutlook for Windows、Outlook on the web、Mac版、Outlookモバイルでは、対応状況やメニュー表示が異なります。Exchange Onlineの管理者向け文書ではOutlook for iOS／AndroidからMessage Recallを開始できると案内される一方、モバイルアプリ向けのサポートにはundo／recallを利用できないとする説明も残っています。モバイル利用を社内手順書に記載する際は、アプリのバージョン、アカウント種別、対象テナントでリコールメニューとレポート動作を確認してから判断してください。

なお、Undo SendとMessage Recallは別機能です。Undo Sendは実際の配信前に送信を中止する機能であり、Message Recallは配信後に受信者メールボックスからの削除を試行する機能です。

Outlook送信取り消しの注意事項

Outlookの送信取り消し機能は便利ですが、万能ではありません。仕様を誤解したまま使うと、取り消せたと思っていたメールが相手に残っていた、という事態になりかねません。

取り消し結果は必ず確認する

リコールを実行しても、必ず成功するとは限りません。受信者のメールボックスや管理者設定が対象外だった場合、転送やルールの影響を受けた場合、許可設定のない外部組織へのメールだった場合などは、削除に失敗することがあります。

Exchange Onlineのクラウド型リコールでは、Message Recall Reportで受信者ごとの成功、失敗、処理中の状態を確認できます。通知は通常短時間で届きますが、受信者が多い場合などは反映に時間がかかることがあります。システムは最大24時間、処理を継続します。

レポートはOffice365Reports@microsoft.comから送信されるため、迷惑メール対策、隔離、メールフロー設定によってブロックされていないかを管理者が確認しましょう。重要な誤送信では、レポートをインシデント記録として保存し、削除できなかった受信者への連絡や追加対応につなげます。

管理者がMessage Traceで確認する場合は、上位ステータスのFailedだけでリコール失敗と判定しないことも重要です。リコール要求は処理完了後にTransportでドロップされるため、Message Trace上ではFailedと表示されても、リコール自体は成功している場合があります。Get-MessageTraceDetailV2でDropイベントの詳細を開き、Result:SuccessまたはResult:Failedを確認してください。

Get-MessageTraceV2 -MessageId "<Recall message ID>" |
  Get-MessageTraceDetailV2 -Event Drop |
  Format-List

重大事故では、リコールの成否だけで完了とせず、受信者による閲覧、転送、保存、画面撮影の可能性、共有リンクへのアクセス履歴も別途評価します。

また、クラシックOutlookでDLPのポリシーヒントを利用している組織は注意が必要です。本文・添付ファイルに対するDLP Policy Tipsが表示されず、添付の追加・削除時のコンプライアンス評価が正しく処理されない問題では、Version 2604～2607が影響対象とされ、修正はVersion 2608に導入されました。Current Channelでは2026年9月8日時点でVersion 2608、Build 20326.20144まで更新されています。

ただし、適用時期はCurrent Channel、Monthly Enterprise Channelなどの更新チャネルによって異なります。特定のビルド番号だけを全端末の対策済み条件とせず、管理者は更新チャネル、バージョン、ビルドを確認し、本文のみ、添付のみ、添付の差し替え、内部・外部宛先の混在といった条件でDLPテストを実施してください。利用者画面の警告だけを統制根拠にせず、Policy Tipが表示されない場合にもサーバー側でブロック・監査できるかを確認することが重要です。

社外宛てのメールは原則として取り消しできない

顧客や取引先への誤送信こそ取り消したい場面ですが、通常のメールでは送信側が別組織・別サービスのメールボックスから配信済みメッセージを削除することはできません。GmailなどExchange Online外のメールや、許可設定のない外部テナント宛てのメールは取り消せません。

例外として、Cross-Tenant Message Recallの対象となるよう受信側テナントが設定し、自社テナントを許可しているExchange Onlineテナント間では、リコールが処理される場合があります。ただし、これは例外的な連携機能です。社外宛てメールは原則回収できないものとして、送信前統制と事故対応を設計してください。

社外メールでは、通常のリコールと、暗号化メールの外部アクセス削除を区別して考える必要があります。Microsoft Purview Advanced Message Encryptionでは、一定の条件下で、受信者のメールボックスからメールを削除するのではなく、暗号化ポータル上の本文への外部アクセスを停止できる場合があります。

ただし、「暗号化したメールなら後から必ず止められる」という意味ではありません。対象となる暗号化方式、テンプレート、ライセンス、送信クライアントを導入前に検証する必要があります。受信者がすでに内容を保存・転記している場合もあるため、暗号化やアクセス停止を誤送信の免責手段として扱わないことが重要です。

添付ファイルの送付方法も見直しましょう。PPAPを廃止する企業では、自社から送るファイルをURL方式へ変えるだけでなく、取引先から届くパスワード付きZIPを受信拒否する運用へ移行する例もあります。YCC情報システムは2026年7月30日、8月3日からクラウド型ファイル送受信サービスへ移行し、取引先から届くPPAP方式のメールを受信拒否すると公表しました。

国内の誤送信防止製品では、新Outlook対応とともに、送信確認だけでなくAIチェック、クラウドストレージ連携、共有先制御へ機能を広げる動きがあります。株式会社エアーは2026年9月、365 AlertにBox連携、ZIP暗号化、Azure OpenAI Serviceを利用するAI送信前チェックを追加し、WISE Alertにはキーワードによる送信規制や、リンク共有時の共有先選択機能を追加しました。ZIP暗号化に対応する製品があることと、自社の標準としてPPAPを採用することは分けて判断し、リンク共有を基本とする方針を維持するとよいでしょう。

ファイル共有リンクには、指定ユーザーまたはドメインの制限、有効期限、ダウンロード制御、アクセスログ、誤送信時の共有停止・リンク失効を設定します。「リンクを知っている全員」ではなく指定ユーザー限定を原則とし、メールの宛先とファイルの共有先が一致しているかも確認してください。メール誤送信とクラウド共有設定ミスは別々に扱わず、送信先、共有対象、アクセスログ、失効状況を同じインシデント管理台帳で追跡することが有効です。

AIによる送信前チェックを導入する場合も、本文を読むだけでは不十分です。宛先、添付、共有権限、禁止キーワードをそれぞれ制御し、AI判定は送信者への助言として活用します。個人情報・機密情報の送信には、DLP、承認フロー、送信ブロックなどの強制統制を残してください。Azure OpenAI Serviceなど外部AI基盤を使う場合は、入力対象、ログ、保持期間、リージョン、学習利用の有無を事前に確認します。

送信取り消しだけに頼らない

メール誤送信の多くは、送信ボタンを押した直後に気付きます。宛先候補の見間違い、添付漏れ、添付ファイルの取り違え、社外秘情報の記載などは、送信前の数十秒から数分の確認で防げることが少なくありません。

そのため、送信取り消しを過信せず、送信前のダブルチェック、社外宛て警告、DLP、感度ラベル、暗号化、承認フローを組み合わせることが重要です。特に機密情報や個人情報を含むメールは、送信後に回収できる前提で運用してはいけません。

Outlookで誤送信を防ぐための設定

取り消し機能には限界があるため、最も有効な対策は、送信直後にメールを一定時間保留し、見直す余地をつくることです。

クラシックOutlookでは、仕分けルールで送信メールを遅延させられます。［ファイル］から［仕分けルールと通知］を開き、［新しい仕分けルール］を選択します。次に、［送信メッセージにルールを適用する］を選び、条件を指定しない場合はすべての送信メールに適用します。

アクションとして［指定した時間分後に配信する］を選び、遅延時間を設定します。短い確認時間として1～3分程度を設定する運用が考えられます。クラシックOutlookの遅延ルールは最大120分まで設定できます。

ただし、この遅延ルールはクライアント側ルールです。予定時刻に送信するには、Outlookが起動・接続している必要があります。ノートPCを閉じる、Outlookを終了する、ネットワークから切断するなどの状態では、設定した時刻に送信されない場合があります。

遅延中のメールは送信トレイに残ります。誤りに気付いた場合は、送信トレイからメールを開いて削除または修正すれば、配信前に止められます。リコールとは異なり、相手のメールボックスへ届く前に中止できる点が大きな利点です。

新OutlookやWeb版のUndo Send機能

新しいOutlook for WindowsやOutlook on the webでは、Undo Sendを利用できる場合があります。Undo Sendは送信ボタンを押した直後に「元に戻す」を表示し、実際の送信前にキャンセルする機能です。受信者のメールボックスから削除を試行するMessage Recallとは異なります。

Undo Sendの猶予時間は最大10秒です。1分以上の確認時間を確保する機能ではないため、長めの保留が必要な場合は、メールごとに日時を指定するSchedule Sendや、クラシックOutlookの遅延ルールを使い分けましょう。

システムと人の確認を組み合わせる

送信遅延やUndo Sendに加え、送信前に宛先、CC、BCC、添付ファイル、件名、本文内の個人情報・機密情報を確認する仕組みを整えると、誤送信リスクをさらに下げられます。

確認ポップアップは、すべての項目に機械的にチェックを入れさせるだけでは形骸化しがちです。社外ドメイン、新規宛先、大量宛先、要配慮情報を含む添付など、リスクの高い条件を色や警告レベルで目立たせる設計が有効です。福岡市が公表したWISE Alertの導入事例でも、外部送信前の確認画面、一時保留、宛先状況を示すカラーアイコン、管理者による統一設定が運用されています。これはベンダー公表事例ですが、利用者任せにせず組織全体で同じルールを適用・維持する考え方の参考になります。

• 社外宛てメールの送信時に確認ポップアップを表示する
• 通常の社外メールには外部宛て警告と送信遅延を設定する
• 個人情報・機密情報を含むメールにはDLP、暗号化、別担当者確認、承認フローを組み合わせる
• 個人メールドメインへの送信をDLPやメールフロールールでブロックまたは承認制にする
• 重要な一斉配信には配信システム、承認フロー、カナリア配信を利用する
• 添付ファイルを直接送らず、権限・期限付きのクラウドリンクで共有する
• 外部共有先をメールアドレスまたはドメインで制限し、メール宛先と共有権限を照合する
• ファイル所有者と共有設定の承認者を分け、共有後は別アカウントでも権限をテストする
• 誤送信時の手順に、共有リンクの無効化、アクセスログ確認、受信者への連絡を含める

個人メールへの送信は、単純な宛先入力ミスだけでなく、正規の担当者による許可されていない持ち出しとしても発生します。2026年8月に報じられた米国労働省の事例では、合理的配慮を申請した約3,150人のPII・医療関連情報を含む表計算ファイルが、同省ドメイン外の個人メールアドレスへ複数回送信されたとされます。送信先の人物は業務上データにアクセスする権限を持っていたものの、個人メールへ送る権限はありませんでした。

このような事故を防ぐには、Gmail、Outlook.com、iCloudなど個人メールドメインへの送信を制御し、人事・医療・障害・給与情報は添付ファイル単位だけでなく列・項目単位でも検知できるようにします。送信者が正規の担当者でも、送信経路と受信先が許可済みかを判定し、同一個人メールへの繰り返し送信を異常行動として監視しましょう。大量の要配慮情報はメール添付を禁止し、認証、期限、監査ログを備えた共有領域に限定することが適切です。

誤送信対策では、宛先だけでなくその宛先に必要なデータだけが入っているかも確認する必要があります。送付先の自治体自体は正しかったものの、自治体ごとに分割すべき個人情報ファイルをまとめて送信してしまうような事故は、単純な社外宛て警告だけでは防げません。

定型的なデータ送信や自動配信では、送信先ごとにファイルを自動分割・生成し、宛先IDと出力ファイルの対象IDを機械的に照合しましょう。元データ一式を送信担当者が直接選択できないようにし、非表示シート、非表示列、コメント、変更履歴、メタデータを検査することも有効です。個人情報ファイルは送信前画面に対象件数を表示し、受信者ごとに必要最小限のデータだけを出力する設計にします。

新Outlookへの移行時には、従来の誤送信防止機能が消えていないかを必ず棚卸ししてください。新Outlook for WindowsではCOM／VSTOアドインがサポートされず、Webアドインへの移行が必要です。クラシックOutlookを前提にしたツールを利用している場合、新Outlookへ切り替えた結果、送信前確認だけが動かなくなるおそれがあります。

確認すべき項目は、現在のツールがCOM／VSTOアドインかWebアドインか、新Outlook・クラシックOutlook・Web版・Mac・モバイルのどこで動作するか、共有メールボックス・代理送信・複数アカウント・オフライン時にどう動くか、アドインの失敗やタイムアウト時に送信を許可するか停止するか、Exchange Online側にもDLPやメールフロールールがあるかです。

新OutlookとOutlook on the webで使われるイベントベースのアドイン、いわゆるSmart Alertsにも制約があります。標準的な新規メール、返信、全員に返信、転送の画面では動作しても、会議招待へのメモ付き応答やカレンダーからの会議転送など、非標準の作成画面では自動起動しない場合があります。また、Microsoft Marketplaceで公開するアドインの送信モードはprompt userまたはsoft blockに限られ、完全なblockを利用するアドインは組織管理者による展開が必要です。

導入・更新時には、新規メール、返信、全員に返信、転送、会議招待、会議転送、メモ付き応答、共有メールボックス、代理送信をテストしましょう。さらに、新Outlook、Web版、Mac、モバイル、ネットワーク障害・タイムアウト時の挙動、Marketplace版と管理者配布版のブロック動作の違いも確認します。機密情報に対する強制ブロックは、クライアントアドイン単独に依存せず、Exchange Online／Microsoft Purview側のDLPと二重化することが重要です。

自動通知や一斉配信の運用では、本番配信前に社内アドレスだけへ送るカナリア配信、宛先IDと本文・添付データの一致検証、一定件数以上の配信を一時停止する承認フロー、配信開始後のサンプル監視、異常検知時の即時停止機能を整えましょう。テンプレート変更、データ結合処理、バッチ更新時の回帰テストも欠かせません。

インシデント手順には、Outlookのリコールだけでなく、配信停止、共有リンクの無効化、暗号化コンテンツへのアクセス停止、影響範囲の確認、受信者への連絡、社内報告を含めておくことが重要です。緊急時に利用者の端末と対象クライアントが正常に起動し、手順を実行できるかも定期的に確認してください。

Outlook送信取り消し まとめ

Outlookのメッセージリコールは、Exchange Onlineを利用する法人向けMicrosoft 365環境で使える機能です。同一テナント内のメールが基本的な対象であり、クラウド型リコールでは管理者設定によって既読メールも削除対象にできます。ただし、削除できたとしても、すでに閲覧・保存・転送された情報まで取り消せるわけではありません。

社外宛てメールは原則として回収できません。例外として、Cross-Tenant Message Recallを受信側が有効化し、自社テナントを許可しているExchange Onlineテナント間ではリコールが処理される場合があります。しかし、Gmailなど外部サービス宛てのメールは対象外であり、社外メールを後から回収できる前提で運用してはいけません。

誤送信対策では、送信後のリコールに頼るのではなく、クラシックOutlookの遅延ルール、新Outlook・Web版のUndo SendやSchedule Sendで配信前に止める仕組みを作ることが重要です。加えて、DLP、感度ラベル、暗号化、社外宛て警告、個人メールドメインへの送信制御、権限・期限付きのリンク共有、送信対象別のファイル自動生成、データ最小化、複数人チェック、配信システムのテストを組み合わせましょう。

メール誤送信は個人の注意力だけで完全に防げるものではありません。配信前に止める、必要最小限のデータだけを配信する、配信後にアクセスを止める、事故発生時に結果を追跡するという多層の対策で、技術と運用の両面からミスを起こしにくく、被害を広げにくい仕組みを整えてください。