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

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

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

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

本記事では、次の内容を解説します。

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

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

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

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

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

法人向けMicrosoft 365は永続無料のプランではありません。Microsoft 365 Business Basicの公式案内ではWeb版・モバイル版のOutlookが提供されています。料金や試用条件は契約時に確認してください。クラシックOutlookの遅延ルール、新Outlook・Web版のUndo Send／Schedule Send、Exchange OnlineのMessage Recallは別々の仕組みである点に注意してください。

Exchange Onlineを利用していても、組織の管理者がリコール関連の機能を制限している場合があります。次の2点は、Microsoft 365管理センターまたは情報システム部門に確認してください。

• 自社アカウントがリコールの対象か
• 利用中のOutlookクライアントで操作と結果確認ができるか

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

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

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

例外として、Microsoftの管理者向け文書には、異なるExchange Onlineテナント間で処理するCross-Tenant Message Recallが案内されています（2026年10月15日確認）。

ただし、自社と相手先のテナントで利用できるかは、管理者が設定と検証用メールで確認する必要があります。テナント間リコールを使うには、次の3点がそろっている必要があります。

• 受信側テナントが機能を有効化していること
• 受信側テナントが送信側のテナントIDを許可していること
• 自社環境で実際に動作することを確認していること

管理者は、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>"}

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

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

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

従来のOutlookのリコールでは、対象メールが未読であることが重要な条件とされてきました。しかし、Exchange Onlineのクラウド型リコールでは、管理者設定によって既読メールも削除対象にできます。既読メールを対象にするかは、管理者がRecallReadMessagesEnabledの実際の設定を確認してください。

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

リコールできるのは、管理者が設定するリコール可能期間内のメールに限られます。Microsoft Learnの管理者向け文書（2026年10月15日確認）によると、この期間（Maximum Recallable Message Age）の既定値は365日です。管理者は5分～10年の範囲で設定できます。古いメールのリコールに失敗した場合は、この設定も確認しましょう。

管理者向けの注意点もあります。同一テナント内のメールが外部のメールゲートウェイなどを経由してExchange Onlineに戻る構成（external round-trip routing）では、ヘッダーを変更しないようにコネクタを適切に設定する必要があります。メールゲートウェイの導入や変更の際は、通常メールだけでなくリコール要求も含めて往復配送のテストを行ってください。

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

また、クラシックOutlookでは、次の環境でリコールが正常に動作しないことがあります。

• OutlookがOnline modeで動作している場合
• 1つのOutlookプロファイルに複数のExchangeアカウントを設定している場合

共有・委任メールボックスでは、リコール自体は成功しても、所有メールボックスの認証上の制約からMessage Recall Reportを開けない場合があります。重要な共通メールボックスや複雑なメール環境では、事前にテストを実施してください。

Outlook送信取り消しの方法

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

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

リボンの種類によって、操作は次のように異なります。

• クラシックリボン：［メッセージ］タブの［移動］グループから［その他の移動操作］を開き、［このメッセージを取り消す］を選択する
• 簡易リボン：［その他のコマンド］→［アクション］→［このメッセージを取り消す］の順に選択する

表示名や配置は、Microsoft 365 Appsのビルドによって異なる場合があります。

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

新しいOutlook for Windows、Outlook on the web、Mac版、Outlookモバイルでは、メニュー表示が異なります。Microsoftのモバイル向けサポートでは、iOS／Androidからもリコールを開始する手順を案内しています。基本の対象は、送信者と受信者が同じ組織のMicrosoft 365アカウントを使うメールです（2026年10月15日確認）。

1. 送信済みフォルダーで対象メールを開く
2. 右上の三点メニュー（その他のオプション）を開く
3. ［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で導入

対策済みかは、Microsoftの既知の問題と修正案内で、利用中の更新チャネルとバージョンを照合します。過去に掲載された特定日のビルド番号だけで判断しないでください。

修正の適用時期は、Current Channel、Monthly Enterprise Channelなどの更新チャネルによって異なります。特定のビルド番号を全端末の対策済み条件にするのではなく、管理者は実際の更新チャネル、バージョン、ビルドを確認してください。そのうえで、次の条件でDLPテストを実施します。

• 本文のみ
• 添付のみ
• 添付の差し替え
• 内部・外部宛先の混在

利用者画面の警告だけを統制の根拠にしないことも重要です。Policy Tipが表示されない場合でも、サーバー側でブロック・監査できるかを確認してください。

誤送信後の監視体制も見直しておきましょう。Microsoftは、2026年10月上旬からの組み込みのアラートチューニングルール（built-in alert tuning rule）による変更を次のように説明しています。

• DLPシグナルはMicrosoft Defender XDRで「アラート」ではなく「動作（behavior）」として扱われ、インシデントキューには表示されなくなる
• シグナル自体はAdvanced Hunting（BehaviorInfo、BehaviorEntitiesなど）で確認できる
• 従来どおりアラートとして表示したい場合は、Settings > Microsoft Defender XDR > Alert tuningで当該ルールを無効化する

誤送信後の監視手順が「インシデントキューだけを見る」運用になっていないか、設定と検知テストで確認してください。なお、Message Recall ReportとDLPアラートは別物です。リコール結果の確認とDLPによる検知の確認は、分けて行う必要があります。

誤送信の事故対応では、削除できなかった受信者への連絡に続いて、取引先への説明や確認の打ち合わせが必要になることもあります。そうした場面では、メールで候補日時を何往復もやり取りせず、予約ページで日程を調整する方法があります。日程調整ツールのJicooは、Outlookの予定を参照した予約ページを作成できます。個人向けの基本的な日程調整は、Individualプラン（0円、2026年10月時点）で無料で始められます。予約ページは打ち合わせ日程を決めるために使い、メールの回収や情報漏えいへの対応は別途進めてください。

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

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

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

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

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

添付ファイルの送付方法も見直しましょう。自社でリンク共有を使っていても、相手がパスワード付きZIPなど別の方式を利用していることがあります。受信側が許可する形式と、ファイルにアクセスできる担当者を送付前に確認します。送信方式を変えるときは取引先にも案内し、必要なファイルが隔離されて業務が止まらないかテストしましょう。

誤送信防止製品を比較するときは、宛先確認、送信保留、共有先の制限を同じ軸で確認します。機能名が似ていても、端末上のアドインとサーバー側の処理では、対象となるOutlookや管理方法が異なります。採用前に対応クライアント、管理者の設定範囲、通信失敗時の動作を確認しましょう。ZIP暗号化に対応しているかと、自社でその方式を採用するかは別の判断です。

ファイル共有リンクには、次の設定を行います。

• 指定ユーザーまたはドメインへの制限
• 有効期限
• ダウンロード制御
• アクセスログ
• 誤送信時の共有停止・リンク失効

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

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

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

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

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

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

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

クラシックOutlookでは、仕分けルールで送信メールを遅延させられます。

1. ［ファイル］から［仕分けルールと通知］を開く
2. ［新しい仕分けルール］を選択する
3. ［送信メッセージにルールを適用する］を選ぶ。条件を指定しなければ、すべての送信メールに適用される
4. アクションとして［指定した時間分後に配信する］を選び、遅延時間を設定する

短い確認時間として、1～3分程度に設定する運用が考えられます。クラシックOutlookの遅延ルールは、最大120分まで設定できます。

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

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

新OutlookやWeb版のUndo Send機能

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

Microsoftの新Outlookリリースノートには、Undo Sendの遅延選択肢を10秒から30秒へ増やしたとの記載があります。一方、Web版を含むすべての環境に共通する最大値は、この記載だけでは判断できません。利用中の環境で選べる時間を確認してください。1分以上の確認時間を確保したい場合は、メールごとに日時を指定するSchedule Sendや、クラシックOutlookの遅延ルールを使い分けましょう。Microsoftの送信遅延・日時指定送信の案内では、新Outlookの日時指定送信はIMAP・POPアカウントで利用できません。

各機能の違いは次のとおりです。

比較基準日：2026年10月15日

機能	主な対象	猶予・処理	特徴
Message Recall	同一Exchange Onlineテナント内。展開・設定済みの環境では、受信側が許可したExchange Onlineテナント間も対象になり得る	配信後（管理者が設定するリコール可能期間内。既定は365日）	受信者のメールボックスからの削除を試行する
Undo Send	新Outlook・Web版など	新Outlookには30秒の遅延選択肢が案内されている。Web版の設定可能な時間は利用環境で確認	実際の送信前にキャンセルする
遅延ルール	クラシックOutlook	1～120分	クライアント側ルールのため、Outlookの起動・接続に依存する
Schedule Send	新Outlook・Web版（新OutlookのIMAP・POPは対象外）	指定日時まで	メール単位の日時指定であり、常時適用する誤送信防止の統制ではない

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

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

一斉送信でBCCの代わりにToやCCを使うと、受信者同士にアドレスが見えてしまいます。配信前に確認する項目を、次のように決めておきましょう。

• 受信者同士にメールアドレスを表示してよい配信か
• To・CC・BCCに意図したアドレスだけが入っているか
• 個別配信や承認済みの一斉配信システムを使う必要がないか

こうしたミスは、気付いた時点ではアドレスがすでに受信者全員に表示されています。送信前の確認と配信手段の選び方で防ぐしかありません。

確認ポップアップは、すべての項目に機械的にチェックを入れさせるだけでは形骸化しがちです。社外ドメイン、新規宛先、大量宛先、要配慮情報を含む添付など、リスクの高い条件を色や警告レベルで目立たせる設計が有効です。

利用者任せにせず、組織全体で同じルールを適用・維持することも大切です。外部送信前の確認画面や一時保留を導入する場合は、管理者が対象者と例外条件を定め、共有メールボックスや代理送信でも動作するか確かめましょう。

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

個人メールへの送信は、宛先の入力ミスだけでなく、業務で閲覧を許可された情報を、許可されていない保存先へ持ち出す場面でも問題になります。たとえば人事や健康に関する情報は、担当者に閲覧権限があっても、個人メールでの保管まで許可されているとは限りません。閲覧権限と社外への送信許可を分け、利用できる送信経路を定めてください。

このような事故を防ぐ対策は次のとおりです。

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

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

定型的なデータ送信や自動配信では、次のような仕組みを取り入れましょう。

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

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

製品の名称だけで対応可否を判断せず、次のように処理方式を分けて調べます。価格比較では、ユーザー数の区分、年払い・月払い、初期費用、税の扱い、移行時の追加ライセンスをそろえましょう。対応環境は提供元の動作条件で確認します。

• COM／VSTOアドイン：クラシックOutlookでの動作と、新Outlookへの移行方法を確認する
• Webアドイン：新Outlook、Web版、Macなど、実際に利用する端末で送信確認を試す
• サーバー側の処理：端末の設定に依存せず適用される範囲と、管理者の例外設定を確認する

新Outlookで同等の対策を続けるには、既存製品の対応状況と契約条件を確認します。現在の契約で利用できるWebアドインやサーバー側のDLPを確かめ、必要な場合に追加ライセンスを検討してください。また、サーバー側で処理するエンタープライズ版と、端末上でポップアップを表示するAdd-inとでは仕組みが異なるため、混同しないようにしましょう。

移行時に確認すべき項目は次のとおりです。

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

新OutlookとOutlook on the webで使われるイベントベースのアドイン、いわゆるSmart Alertsにも制約があります。作成画面やクライアントによって対応条件が異なるため、MicrosoftのSmart Alerts資料で要件を確認します。新規メールだけでなく、返信や転送、会議関連の画面でも実際の動作を試してください。また、Microsoft Marketplaceで公開するアドインの送信モードはprompt userまたはsoft blockに限られます。完全なblockを利用するアドインは、組織の管理者による展開が必要です。

Microsoftは、Office Add-insのサンプル「Verify the sensitivity label of a message」を提供しています。新旧Windows版Outlook、Mac、Web版を対象に、添付ファイルや宛先に応じて感度ラベルを確認・適用する実装例です。sensitivity label APIや、宛先変更時のイベントOnMessageRecipientsChangedなどを使っています。

ただし、これは開発者向けの実装例です。Outlook標準で全メールが自動検査されるようになったという発表ではありません。自社でアドインを開発・調達する場合は、対応端末、イベントが発火する条件、送信を止める設定を検証項目に加えてください。

アドインの導入・更新時には、次の条件をテストしましょう。

• 作成画面：新規メール、返信、全員に返信、転送、会議招待、会議転送、メモ付き応答
• メールボックスの種類：共有メールボックス、代理送信
• クライアント：新Outlook、Web版、Mac、モバイル
• 異常時：ネットワーク障害・タイムアウト時の挙動
• 配布方法：Marketplace版と管理者配布版でのブロック動作の違い

機密情報に対する強制ブロックは、クライアントアドイン単独に依存しないでください。Exchange Online／Microsoft Purview側のDLPと二重化することが重要です。

自動通知や一斉配信の運用では、次の仕組みを整えましょう。

• 本番配信前に社内アドレスだけへ送るカナリア配信
• 宛先IDと本文・添付データの一致検証
• 一定件数以上の配信を一時停止する承認フロー
• 配信開始後のサンプル監視
• 異常検知時に即時停止できる機能

テンプレート変更、データ結合処理、バッチ更新の際の回帰テストも欠かせません。

インシデント手順には、Outlookのリコールだけでなく、次の対応を含めておくことが重要です。

• 配信停止
• 共有リンクの無効化
• 暗号化コンテンツへのアクセス停止
• 影響範囲の確認
• 受信者への連絡
• 社内報告

緊急時に利用者の端末と対象クライアントが正常に起動し、手順を実行できるかも定期的に確認してください。

Outlook送信取り消し まとめ

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

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

誤送信対策では、送信後のリコールに頼らず、配信前に止める仕組みを作ることが重要です。クラシックOutlookなら遅延ルール、新Outlook・Web版ならUndo SendやSchedule Sendを活用します。そのうえで、次の対策を組み合わせましょう。

• DLP、感度ラベル、暗号化
• 社外宛て警告、To・CC・BCCの使い分けの確認
• 個人メールドメインへの送信制御
• 権限・期限付きのリンク共有
• 送信対象別のファイル自動生成とデータ最小化
• 複数人でのチェック、配信システムのテスト

新Outlookへの移行時には、既存の誤送信防止アドインが動作するかの確認も欠かせません。

メール誤送信は、個人の注意力だけで完全に防げるものではありません。配信前に止める、必要最小限のデータだけを配信する、配信後にアクセスを止める、事故発生時に結果を追跡するという多層の対策で、ミスを起こしにくく被害を広げにくい仕組みを整えてください。まずは自社テナントのリコール設定（リコール可能期間、既読メールの扱い、テナント間リコールの許可状況）と、利用中のOutlookで遅延ルールまたはUndo Sendが設定されているかを確認するところから始めましょう。