【2026年版】Outlookでメールを自動転送する方法｜できない時の原因と対処法も解説

Outlookの自動転送は、担当者不在時の引き継ぎや、特定条件のメール共有に役立つ機能です。一方で、会社のメールを個人アドレスへ転送したり、侵害されたアカウントに不正な転送ルールを作成されたりすると、顧客情報や契約情報が漏洩するおそれがあります。

特にMicrosoft 365では、組織外への自動転送はセキュリティ上のリスクとして扱われます。便利だからという理由で個人のGmailなどへ業務メールを集約する運用は避け、必要な場合は管理者の承認を受けましょう。

本記事では、従来のデスクトップ版Outlook（Classic Outlook）、新しいOutlook for Windows、職場・学校アカウント向けのOutlook on the webで自動転送を設定する方法を解説します。個人向けのOutlook.comとは設定画面や対象アカウントが異なるため、混同しないよう注意してください。あわせて、転送できないときの確認項目、外部転送のブロック、DLP、共有メールボックスについて整理します。新旧Outlookの移行や、2026年10月から段階的に始まるEWSアクセス変更で確認したい事項も取り上げます。

メールを自動転送するときの注意点

Outlookの自動転送は短時間で設定できますが、業務メールには顧客情報、見積書、契約書、社内資料、認証情報などが含まれることがあります。設定前に、転送の目的、転送先、必要な期間、承認者を明確にしましょう。

組織外のアドレスへの自動転送は原則避ける

会社の業務メールを、Gmail、Outlook.comなどの個人アドレスや承認されていない外部サービスへ自動転送する運用は、多くの企業で禁止または制限されています。転送先でメールが再配布されたり、端末管理や監査の対象から外れたりするためです。

Microsoft 365では、アウトバウンドスパムポリシー、Remote Domains、メールフロールールのいずれかで外部自動転送がブロックされていると、通常はブロック側の設定が優先されます。アウトバウンドスパムポリシーの既定値である「Automatic - System-controlled」は、組織によって挙動が異なる可能性があります。外部自動転送を禁止する方針であれば、「Off - Forwarding is disabled」を明示的に設定してください。設定後は、Remote Domainsやメールフロールールも含めて実効設定をテストします。

外部転送を例外的に認める場合も、対象ユーザー、転送先ドメイン、利用目的、責任者、有効期限を限定し、申請番号と監査ログを残す運用が必要です。機密情報を含むメールは、個人のOutlookルールで除外するのではなく、Microsoft Purview DLPまたはExchangeのメールフロールールで組織として制御しましょう。

DLPのポリシーヒントは利用者に注意を促すための表示であり、情報漏洩を防ぐ最終手段ではありません。メールの作成途中で秘密度ラベルを付与した場合、Outlookクライアントでは、新しいラベルを条件とするポリシーヒントが再評価されないことがあります。ただし、サーバー側のDLPアクションは適用されます。「ヒントが出ない＝転送できる」とは判断しないでください。Classic Outlook、新しいOutlook、Outlook on the webのそれぞれで、ラベル付与前後の表示と、実際に送信されたかブロックされたかをテストしましょう。

不正な転送ルールを定期的に監査する

自動転送ルールは、利用者本人だけでなく、アカウントを侵害した攻撃者が作成することもあります。攻撃者はメールボックスへ侵入したあと、外部アドレスへの受信トレイルールやSMTP転送を設定し、請求書、見積書、取引先との連絡を継続的に取得します。

管理者は、Exchange管理センターの自動転送メッセージレポートを活用しましょう。このレポートでは受信トレイルール、メールフロールール、SMTP forwardingを区別したうえで、転送先ドメイン、転送ユーザー、転送回数、最初の転送日を確認できます。調査は、これまで存在しなかった転送先ドメイン、新たに転送を始めたユーザー、個人向けメールドメインへの転送から優先して進めます。

各メールボックスを月に一度確認するだけでは不十分です。レポートを定期的にCSVで保管して前回との差分を確認し、可能であれば日次の確認やアラートにしてください。新規作成ルール、未知の外部ドメイン、通常使わないフォルダーへ移動するルールを検知対象とし、ルール作成者、作成元IPアドレス、同時期のサインイン履歴を突き合わせます。

不正が疑われる場合は、ルールを削除して終わりにせず、先に証拠を保全します。Unified Audit Log、メールボックス監査ログ、メッセージトレース、サインインログを確保してから、不審なルール、メールボックス転送、OAuth同意を確認してください。続いて、強制サインアウトやリフレッシュトークンの失効で既存セッションを無効化し、パスワード変更とMFA再登録が必要か判断します。

Microsoft 365 Copilotでは、対応環境であれば自然言語で受信トレイルールを作成、表示、変更、無効化、削除できます。変更前には確認画面が表示され、作成したルールはこれから受信するメールに適用されます。ただし、公式に例示されているのはメールの移動、カテゴリ付与、削除などで、外部アドレスへの自動転送ルールを作成する例は確認できません。Copilotの一覧だけで監査を済ませず、管理者はExchangeやDefender側のログも確認してください。

他システム連携は転送以外の方法も検討する

問い合わせメールをチケット管理システムへ送る、CRMに活動履歴を残すといった目的で自動転送を使っている場合は、転送ルールに依存しない方法も検討しましょう。Power Automate、Microsoft Graph API、各サービスの公式コネクタ、共有メールボックスを使えば、必要なデータだけを連携でき、権限・ログ・エラーも管理しやすくなります。ただし、転送をやめて別の方式に切り替えても、その連携方式の保守は続きます。EWSを使う連携の扱いは後述の「EWS依存の連携は別途点検する」で確認してください。

代表アドレスを複数人で扱う場合、個人メールボックスへの転送先を増やすだけでは、誰が対応中か、誰が返信したか、未対応のメールがあるかを把握しにくく、二重返信も起こりがちです。

公開事例としては、香川銀行のケースがあります。共有メールの担当者、対応状況、メモ、上長承認、履歴などを管理する仕組みと、添付ファイルをURL共有に切り替える仕組みを組み合わせています。ベンダーの発表なので効果は一般化できませんが、単純な転送に頼らず、メール対応とファイル受け渡しを分けて管理する設計例として参考になります。

添付ファイル側の設計例には、2026年9月に公開されたエイチワンの事例もあります。社外や海外拠点とのファイル授受を専用の共有基盤に移し、権限と証跡の管理、PPAP作業の削減を図ったものです。これはOutlookの自動転送を置き換えた事例ではなく、提供元が掲載する工数削減の試算も一般的な導入効果とはいえません。

メール対応側の参考設計としては、個人のメールに分散した営業案件を、受信・送信メールの定期取得によって「自社対応待ち／相手の返信待ち／完了」に整理する国内の開発事例もあります。ただし、その構成がExchange Online環境にそのまま合うとは限りません。取得方式と認証方式は自社環境に合わせて確認してください。

info@、support@、sales@などの方式は、転送先の人数で決めるのではなく、担当者、ステータス、承認、監査ログが必要かどうかで選びます。添付ファイルをURLで共有する場合は、認証、有効期限、アクセスログを管理しましょう。HTMLを無効化したり本文をテキスト表示にしたりすると安全性は高まりますが、表、署名、画像などが失われます。重要なメールについては、原本を保持する方法も決めておいてください。

問い合わせ窓口では、次の流れを一つのワークフローとして設計することが重要です。送信元や件名による自動分類、受付完了の自動返信、担当者への割り当て、SLA・回答期限の管理、返信前の承認、不達時の再送、対応完了後の履歴保存です。保険業界にも、自動ルール、自動返信、対応履歴を組み合わせたメール共有ツールの導入事例があります。保険・金融・医療では、転送できたかだけでなく、顧客に届いたか、誰が承認したか、どの文面を送ったかまで記録できるようにしましょう。

AIを使う場合も、いきなり完全に自動化する必要はありません。まずは転送から始め、問い合わせのケース化、返信案の作成、人の承認を経た送信へと段階的に進めます。そのうえで、定型かつ低リスクな問い合わせだけを限定して自律処理する方法が現実的です。契約、請求、個人情報、苦情、解約に関するメールはカテゴリごとに自動化レベルを定め、最終的な送信は人が確認する設計が安全です。

外部サービスを転送の代わりに採用する場合は、OAuth権限を確認してください。確認したいのは次の点です。

• Mail.ReadではなくMail.ReadWriteが本当に必要か
• 全ユーザーではなく特定のメールボックスに限定できるか
• Application permissionとDelegated permissionのどちらを使うか
• 管理者同意が必要な権限は何か

あわせて、メール本文、添付、連絡先、予定表のどこまでを取得するか、同意の取り消し方法、サービスを退役させるときにトークンやサービスプリンシパルを削除する手順も明確にしましょう。

新しいOutlookでは従来型COM／VSTOアドインを利用できない

Classic OutlookでCRM、SFA、チケット管理システムなどと連携するためにCOMアドインやVSTOアドインを使っている場合は、新しいOutlook for Windowsへの移行時に注意が必要です。新しいOutlookはWeb版に近い設計で、従来型のローカルアドイン、VBA、Outlook Object Modelは利用できません。移行前に、利用中のアドインにWebアドイン版があるか、ベンダーに確認しましょう。

EWS依存の連携は別途点検する

EWS（Exchange Web Services）に依存するサーバー側のメール連携は、COM／VSTOアドインとは別の問題です。利用者がClassic Outlookと新しいOutlookのどちらを使っていても影響を受けます。次のような連携がEWSに依存していないか、棚卸ししてください。

• CRM・SFAへのメール保存
• メールアーカイブやバックアップ
• 問い合わせ管理
• Exchange Online移行ツール
• 共有メールボックスやグループメールボックスとの連携
• 予定表・連絡先・添付ファイルの取得

MicrosoftのExchange Team Blogでは、2026年10月1日から段階的にEWSへのアクセス動作を変更し、EWSの全面的な無効化は2027年4月とする予定が案内されています（2026年9月時点）。10月1日に全テナント・全アプリが一斉に停止するという意味ではなく、変更はテナントごとに順次適用されます。移行期間中もEWSを使い続けるテナントに対しては、2026年9月末までにアプリIDの許可リスト（EWSAllowedAppIDs）を整え、EWSEnabled=Trueを設定するよう案内されていました。関連する別製品向けの文書には異なる期限を記載したものもあります。全製品に共通する期限があると考えず、対象製品の案内と最新のExchange Team Blogの更新を照合してください。

2026年9月7日には、日本マイクロソフトのExchange & Outlookサポートチームも、この変更の注意点を日本語で公開しました。米国での発表の日本語抄訳で、国内独自の仕様変更ではありません。主なポイントは次の3つです。

• EWSEnabled=Trueのテナントでは、許可するアプリIDのリストが必要になる
• 管理者がリストを作成していない場合、Microsoftが過去60日間の利用状況をもとに作成することがある。この場合、利用頻度の低い業務アプリが漏れる一方で、許可したくないアプリが含まれる可能性がある
• 管理者が設定済みのリストは上書きされない

Microsoftの自動作成に任せず、管理者が必要なアプリIDだけを登録しましょう。

EWSを一時的に使い続ける場合は、ベンダー名ではなくアプリケーションID単位で確認します。EWSAllowedAppIDsは、Entra ID上のアプリケーションのクライアントIDを使うテナント単位の制御です。これに対して、従来のEWSAllowListとEWSBlockListはUser-Agentベースで、別のレイヤーとして評価されます。許可したアプリが接続できるかだけでなく、登録していないアプリが拒否されるかもテストしてください。既存のEwsApplicationAccessPolicy、許可リスト、ブロックリストも別途確認が必要です。EWSを使い続けるのはあくまで暫定策です。2027年4月の全面無効化を見据え、Microsoft Graphなどへの移行計画を別に立てることが重要です。

製品別の移行作業の例として、MicrosoftはSystem Center Service Manager向けに、Exchange Onlineに接続するEmail NotificationsとExchange Connectorへの影響を公開しています。Exchange Connectorはバージョン5.0への更新、通知機能は暫定対処と後続の更新が案内されています。暫定対処の内容は製品固有のものなので、他製品の推奨設定として流用せず、各ベンダーの案内に従ってください。

PSTをOneDriveの同期フォルダーで運用しない

Microsoftは、PSTファイルのエクスポート先にOneDriveの同期フォルダーを使わないよう案内しています。OneDriveによるOutlook PSTファイルの自動同期はブロックされるため、PSTをリアルタイム共有や継続的なバックアップの手段にしないでください。

バックアップが必要な場合は、Outlookを終了してから、組織が管理するバックアップ先へコピーします。保持ポリシー、オンラインアーカイブ、メールボックスの容量管理も含め、PSTへの依存を減らす設計を検討しましょう。

新しいOutlookでは、PST内のメールを閲覧・検索・管理でき、メールボックスとの間でメールを移動することもできます。PSTからメールボックスへのインポートについては、Microsoftサポートの手順ページに［設定］＞［データファイル］＞［インポート］（英語表示では［Settings］＞［Data files］＞［Import］）を使う方法が掲載されています。一方で、別のMicrosoftサポートページには新しいOutlookでは未対応とする記述も残っており、公式資料の間で説明が一致していません（2026年9月時点）。対応状況はアカウントの種類、環境、展開状況によって異なる可能性があります。移行前に、実際の対象PSTでインポートを試してください。インポートできない環境では、Classic Outlookの利用を検討しましょう。PST内の予定表・連絡先を表示できるかも、インポートの可否とは分けて検証します。

比較基準日：2026年9月29日（PSTからメールボックスへのインポートの行を確認して更新。その他の行は元記事の更新時点の情報であり、実環境での確認を推奨します）

リダイレクト転送は自動応答の宛先に注意する

Outlookのルールには、通常の転送とリダイレクトがあります。リダイレクトは、元の差出人から届いたメールをそのまま別の宛先へ配送する動きに近いものです。そのため、転送先で自動応答が設定されていると、元の差出人に自動応答が届く場合があります。

差出人が転送やリダイレクトの存在を知らなければ、想定外の相手から自動応答が返ってきたように見えます。社外とのやり取りでは、事前に関係者へ周知するか、通常の転送を選ぶほうが安全です。

転送ループを作らない

AさんのメールをBさんへ、BさんのメールをAさんへ転送するような相互転送は避けましょう。Exchange Onlineの受信トレイルールによる自動転送・リダイレクトは、X-MS-Exchange-Inbox-Rules-Loopヘッダーで追跡され、1回に制限されています。そのため、AからB、BからCといった多段の転送は途中で止まる可能性があります。

無限ループは防げても、メールの未達や監査上の混乱は起こり得ます。複数のルール、共有メールボックス、配布グループを組み合わせる場合は、テストメールで配送経路と宛先を確認してください。

従来のデスクトップ版Outlook（Classic）：メールを自動転送する方法

ここでは、上部のリボンに［ファイル］タブがある従来のデスクトップ版、いわゆるClassic Outlookでの設定方法を紹介します。組織のリボン構成や画面幅によって入口は異なります。［ホーム］の［移動］＞［ルール］、または［ファイル］から［仕分けルールと通知の管理］を開いてください。

1. ［仕分けルールと通知の管理］を開きます。
2. ［新しい仕分けルール］を選択します。
3. ［受信メッセージにルールを適用する］を選びます。
4. 差出人、件名、宛先、受信期間など、転送対象の条件を設定して［次へ］をクリックします。
5. アクションで［名前／パブリック グループへ転送する］またはリダイレクトを選び、転送先を指定します。
6. 必要に応じて例外条件を設定し、ルール名を入力して保存します。
7. テストメールを送信し、必要なメールだけが正しい宛先へ転送されることを確認します。

Exchange Onlineの受信トレイルールで指定できる個別受信者は、合計10件までです。11件以上に共有したい場合は、個別のアドレスを並べるのではなく、配布グループ、Microsoft 365グループ、共有メールボックスを利用してください。

添付ファイルや特定の差出人を例外にすることはできます。ただし、機密情報を含むメールを外部転送から除外する制御は、管理者がPurview DLPまたはメールフロールールで行いましょう。

従来のデスクトップ版Outlook（Classic）：自動転送の設定を削除する

自動転送を止めるには、［仕分けルールと通知の管理］を開きます。対象ルールのチェックを外すと一時停止、ルールを選択して［削除］をクリックすると削除できます。操作前に、ルール名、条件、転送先を確認してください。

新しいOutlook for Windows：メールを自動転送する方法

新しいOutlook for Windowsは、Outlook on the webに近い画面設計で、設定画面もほぼ共通です。メールボックス全体の転送を設定する基本手順は次のとおりです。

1. 画面右上の歯車アイコンから［メール］を開き、［転送］を選択します。
2. ［転送を有効にする］をオンにします。
3. 転送先のメールアドレスを入力します。
4. 元のメールボックスにも記録を残す必要がある場合は、［転送されたメッセージのコピーを保持する］をオンにします。
5. ［保存］をクリックします。

新しいOutlookのリリースノートを見ると、2026年9月11日の更新は会議出席依頼、メール設定内のフォルダーペイン、Peopleのカテゴリ操作、9月18日の更新は一般的な修正が中心です。自動転送の設定手順や外部転送の可否が変わったという発表ではありません。画面の表示が本記事と異なる場合は、自社テナントの表示とリリースノートを照らし合わせて確認してください。

一部のMicrosoft 365 Businessプランでは、メールボックス容量を最大100GBに拡大する変更が展開されています（元記事の更新時点の情報）。ただし、実際のクォータはライセンスとテナントの展開状況によって異なります。コピー保持を容量対策の代わりにはせず、管理センターで実際のクォータ、保持ポリシー、アーカイブ設計を確認してください。

条件付きで転送する場合は、［メール］＞［ルール］で条件と転送アクションを組み合わせます。新しいOutlookでは、テナントへの展開状況に応じて、Externalタグが付いたメールを受信トレイルールの条件に使えます。使える条件は段階的に展開されるため、実際の［メール］＞［ルール］画面とMicrosoft 365 Message Centerで確認してください。

ただし、「組織外からのメール」という条件は、外部への転送を許可する機能ではありません。外部からのメールだけを個人アドレスへ一括転送したり、ルールの条件をDLPや外部転送制御の代わりにしたりする運用は避けてください。ルールを追加したら、既存の［以降のルールの処理を停止する］と競合しないかも確認します。

Outlook on the web：メールを自動転送する方法

職場・学校アカウントでは、Outlook on the webから自動転送と条件付きルールを設定できます。個人のHotmail、Live、MSN、Outlook.comアカウント向けのOutlook.comとは別のサービスです。スマホアプリでは詳細なルールを作成できない場合があるため、PCのブラウザーから組織のMicrosoft 365ポータルまたはOutlook on the webにサインインして設定してください。

1. ［設定］を開きます。
2. ［メール］＞［ルール］を選択します。
3. ［新しいルールを追加］を選択します。
4. ルール名、条件、アクション、例外を設定します。
5. 必要に応じて［以降のルールの処理を停止する］を設定します。
6. 保存し、テストメールで条件、宛先、本文・添付ファイルの扱いを確認します。

［メール］＞［転送］からメールボックス全体の転送を設定する場合は、転送を有効にして宛先を入力し、必要に応じて元メールのコピー保持を選んで保存します。外部への転送ができるかどうかは、利用者の設定ではなく組織のポリシーで決まります。

Outlook on the web：自動転送の設定を削除する

［設定］＞［メール］＞［ルール］を開きます。一時停止する場合は対象ルールをオフにし、不要になった場合は削除します。メールボックス全体の転送は、［メール］＞［転送］で無効にします。期限付きの代理対応ルールは、終了日を運用台帳などにも記録し、設定が残ったままにならないようにしましょう。

具体例：特定のアドレスからのメールを代理担当者へ転送する

特定の取引先から届くメールを一定期間だけ代理担当者へ転送する場合は、対象者、期間、転送先、終了後の停止方法を事前に決めておきます。

1. ［仕分けルールと通知の管理］＞［新しい仕分けルール］を開きます。
2. ［受信メッセージにルールを適用する］を選び、［差出人が〇〇の場合］、［特定の期間に受信した場合］などの条件を設定します。
3. ［名前／パブリック グループへ転送する］を選び、代理担当者または共有メールボックスを指定します。
4. 必要に応じて、サーバーでの自動返信を設定します。自動返信は元の差出人に送られるため、代理対応中であること、緊急時の連絡先、返信内容に含めない情報を事前に確認します。
5. ルール名を入力して保存し、テストメールで転送と自動返信を確認します。

代理対応が複数人にわたる、承認が必要、対応状況を可視化したいといった場合は、個人への転送を増やすより、共有メールボックスやメール共有システムで担当・ステータス・承認・履歴を管理する方法が適しています。

メールが自動転送できないときの原因と対処法

まずは、Outlookの画面で転送ルールを保存・実行できているかを確認します。連携システムにメールが取り込まれない問題は別に切り分けてください。前者はケース①〜⑤、後者はケース⑥を参照します。

ケース①：組織外のメールに自動転送されない

会社のメールを個人アドレスなど組織外へ転送した際に、5.7.520 Access deniedやAS(7555)を含むNDRが返ってくる場合は、組織の外部自動転送ブロックが原因です。

管理者は、アウトバウンドスパムポリシーのAutoForwardingMode、Remote Domainsの自動転送設定、メールフロールール、転送先が内部か外部かを確認します。外部転送を禁止する方針であれば、AutoForwardingModeを明示的にOffに設定し、例外は最小限に管理しましょう。

ケース②：転送先を複数設定したら自動転送されない

Exchange Onlineの受信トレイルールで指定できる個別受信者は、合計10件までです。11件以上に同じメールを共有したい場合は、配布グループ、メールが有効なセキュリティグループ、Microsoft 365グループ、共有メールボックスを使います。

ケース③：ルールの条件や処理順が競合している

一部のメールだけ転送されない場合は、ルールの条件、例外、処理順を確認します。別のルールが先にメールを移動し、［以降のルールの処理を停止する］が設定されていると、後続の転送ルールは実行されません。

• ルールが有効になっているか
• 条件が厳しすぎないか
• 例外条件に該当していないか
• 転送ルールより前に処理を停止するルールがないか
• 転送先アドレスに入力ミスがないか
• サーバー側で実行できるルールか

POPやIMAPなどでメールをOutlookに取り込んでいる場合や、ローカルフォルダーを対象にしている場合は、ルールがクライアント側ルールになることがあります。その場合、Outlookを起動していない間はルールが動作しません。

ケース④：DLPや社内ポリシーで止められている

個人情報、クレジットカード番号、マイナンバーに類する情報、契約書などを含むメールは、DLPポリシーやメールフロールールで転送がブロックされる場合があります。確認時は、次の点を分けて確認してください。

• ポリシーヒントが表示されたか
• ラベル付与の前と後のどちらで評価されたか
• 使用したクライアントがClassic Outlook、新しいOutlook、Webのどれか
• サーバー側でブロックされたか
• 上書きできる警告か、強制ブロックか

ケース⑤：Gmail・Yahoo!メールなどでOutlookのルールを設定している

新しいOutlookにGmail、Yahoo!メール、iCloudなどのサードパーティーアカウントを追加していても、これらのアカウントに対する受信トレイルールはOutlook側でサポートされていません。Outlookで受信メールを表示できていても、転送や振り分けは各メールサービスの設定画面で構成してください。

ケース⑥：連携システムにメールが取り込まれなくなった

問い合わせ管理、CRM、アーカイブ、バックアップなどの連携システムにメールが取り込まれなくなった場合は、Outlookの受信トレイルールや外部自動転送ポリシーの不具合とは限りません。2026年10月1日から段階的に進むEWSアクセス変更の影響も疑い、次の順で確認します。

1. Outlook側でテストメールが正しく受信・転送されているかを確認し、問題が連携側にあるのかを切り分けます。
2. 連携製品の管理画面やログで、APIエラーの内容と発生日時を確認します。
3. 連携製品がEWSを使っているか、実際に呼び出しているアプリIDは何かを確認します。
4. テナントのEWSEnabledの値と、EWSAllowedAppIDsに該当するアプリIDが登録されているかを確認します。
5. 既存のEwsApplicationAccessPolicy、EWSAllowList、EWSBlockListで拒否されていないかを確認します。
6. 復旧したら、停止中の未処理メール、再試行による重複登録、処理漏れがないかを確認します。

許可リストへの追加は必要なアプリに絞りましょう。対象製品のGraph対応版や移行手順もベンダーに確認し、暫定的な復旧で終わらせないようにしてください。

Copilotを活用できる場面と現時点の制限

Microsoft 365 Copilotは、Outlookでのメールの要約、返信文の下書き、長いスレッドの要点整理に使えます。対応環境では、受信トレイルールの作成、表示、変更、無効化、削除にも活用できます。ルールを作成・変更する前には内容が表示され、利用者が確認してから実行されます。

ただし、公式文書には外部アドレスへの自動転送ルールを作成する例はありません。Copilotで扱える操作と組織の外部転送ポリシーは、別々に管理する必要があります。削除、転送、自動送信のそれぞれについてリスクを評価し、AI利用ガイドライン、データ分類、利用ログ、アクティブ率の確認と連動させましょう。

（補足）転送とリダイレクトの違い

転送の場合

［名前／パブリック グループへ転送する］を選ぶと、転送先には転送者から送られたメールとして届きます。たとえば、AさんからBさんに届いたメールをBさんがCさんへ転送した場合、Cさんの自動応答は通常Bさんに返ります。

リダイレクトの場合

［名前／パブリック グループへリダイレクトする］を選ぶと、リダイレクト先には元の差出人から直接届いたように見えます。AさんからBさんに届いたメールをCさんへリダイレクトした場合、Cさんの自動応答がAさんに届くことがあります。社外とのメールでは特に注意が必要です。

Outlookメールの自動転送はルールと監査をセットで使う

Outlookの自動転送は、担当者不在時の引き継ぎや限られた情報共有に役立ちます。しかし、外部アドレスへの転送は、情報漏洩やアカウント侵害時の持ち出し経路になり得ます。原則禁止または承認制にすることが重要です。

安全に運用するための基本は次のとおりです。

• 転送先を連絡先やグループで管理する
• 個別宛先は10件までという上限を守る
• ルールを作成したらテストする
• 不要になったルールを削除する
• 外部転送の例外には責任者と有効期限を設ける

管理者は、受信トレイルールだけでなく、SMTP forwarding、メールフロールール、外部転送ポリシーも継続的に確認してください。

代表アドレスや問い合わせ窓口では、個人への転送を増やすより、共有メールボックスや対応管理システムで担当者、対応期限、承認、返信済みの状態、履歴を共有するほうが適しています。転送の代わりにPower Automate、Microsoft Graph API、公式コネクタなどで連携する場合も、その方式の保守は続きます。

次のアクションとして、自社のメール連携で実際にEWSを呼び出しているアプリIDと最終利用日を洗い出してください。そのうえで、EWSAllowedAppIDsの設定内容と、Graphなどへの移行計画を確認しましょう。