誤送信対策の上長承認、Microsoft 365 は上長欄が空だと素通りする

情シスの支援に入っている、ある設計・解析系の会社（社員20数名）では、社外にメールを送るとき、決まった上長（経営者）を CC に入れていないと送れない。メール誤送信対策の製品（m-FILTER）が、CC のないメールを止めている。その製品の契約が満了まで約1か月になり、会社が使っている Microsoft 365（メールや Teams などをまとめた Microsoft のサービス）の機能で置き換えられないかを調べた。先に決めるべきだったのは、上長に送信を「止めてほしい」のか、「見ていてほしい」のかだった。

Microsoft 365 にも「送信者の上長に承認させてから送る」機能がある。ところが Microsoft の説明では、この機能は、社員ごとに登録しておく「上長は誰か」の欄が空だと、承認を待たずにそのまま相手に届く。エラーも出ない。素通りだ。設定は変えずに全員分の一覧を出して見たら、この欄は1件も埋まっていなかった。承認の機能でルールを作っていたら、1通も止まらないのに、止まっていると思い込むところだった。

もともとの要望に戻ると、求められていたのは「上長が CC に必ず入っていること」だった。上長欄が全員空だと分かったその日に、方針を「承認は要らない。CC に入っていればいい」と決めた。これなら Microsoft 365 のルール1本で作れ、追加の費用はかからない。この記事は、この上長チェックの部分の話だ。取引先へのファイルの渡し方は、別に製品を選んでいる。ルールはまだ入れていない。ここに書くのは設計と判断までで、担当者向けのルール案は後半に載せた。

この記事でわかること

▶ 誤送信対策の製品の「上長承認」と「上長を CC 必須」は、別の仕組みだということ
▶ 上長に「止めてほしい」のか「見ていてほしい」のかで、作り方と費用が変わること
▶ Microsoft 365 の上長承認が、設定しても止まらないことがある理由
▶ 自分の会社で確かめること（と、担当者向けのルール案）

▼見直した理由：満了まで約1か月。製品で使っていたのは2つの機能だけ

まず、今の製品で実際に使っている機能を書き出した。誤送信対策の製品は機能が多いが、この会社が使っていたのは次の2つだけだった。

▶ 上長を CC に入れないと、社外に送れない：CC に決まった上長が入っていない社外宛てのメールは止まる
▶ 添付ファイルの自動 ZIP 化：添付を自動で ZIP にして、パスワードを別のメールで送る

この会社は Microsoft 365 の Business Premium（中小企業向けのプラン）を契約済みだ。1つ目を Microsoft 365 のルールで作れれば、その部分は製品に払わなくてよくなる。

2つ目は置き換えない。ZIP にしてパスワードを別メールで送るやり方（いわゆる PPAP）は、やめる方針だからだ。実際、ZIP の添付を受け取れない取引先が2社あった。取引先へのファイルの渡し方（URL とパスワードを別々のメールで送る仕組みや、数 GB のファイルの送り方）は、別に製品を選んでいる。だからこの記事で扱うのは、1つ目の上長チェックだけだ。

▼置き換えで引っかかりやすい3つ：製品の「上長承認」は、今の「CC 必須」とは別物

置き換え先を探すと、「上長承認」という言葉がよく出てくる。ただ、これは今の「CC に入っていないと送れない」とは別の仕組みだ。調べていて引っかかりやすかったのは次の3つ。

承認は送る前に止める。CC 必須は上長に写しを届けるだけ

比べた製品の「上長承認」は、送ったメールを上長が許可するまで、相手に届かない仕組みだった。一方、今の「CC 必須」は、上長にメールの写しが届くようにするだけで、上長は送信を止めない。「CC がないと送れない」を機能として載せている製品は、調べた範囲では見当たらなかった（設定の例として近いものが1つあった程度）。名前が似ているので、資料だけ見ると同じものに見える。

承認には期限があり、上長が休みだと社外へのメールが止まる

Microsoft 365 の承認も、上長が許可するまで相手に届かない。上長が出張や休みで見られないと、その間、社外へのメールは出ていかない。許可されないまま2日を過ぎると失効し、相手には届かない（失効の処理の都合で、実際に失効するのは2〜9日の間のどこか）。送信者には期限切れの知らせが届く。

CC 必須のルールは、上長本人のメールや自動で出るメールも止めうる

何も例外を入れないと、上長本人が社外に送るメールも「CC に上長がいない」として止まる。上長を宛先（To）に入れた場合も、CC ではないので止まる。不在時の自動応答や、複合機・業務システムから社外に出るメールが止まるかどうかは、公式の説明には書かれていない。後で書く「記録だけのモード」（メールは止めずに、ルールに当たったことだけを記録するモード）で確かめる対象だ。当たった場合に、自動応答や会議の返信を例外として外す設定はある。

▼判断の分かれ目：上長が「見ていれば」いいなら、Microsoft 365 のルール1本・追加費用なしで足りる

方針は「承認は要らない。社外宛てのメールの CC に、決まった上長が入っていればいい」にした。止めるか見ているかを決めるときに、材料になるのは次の3つだ。

▶ 何が求められているか：この会社の要望は、最初から「メールの CC に必ず経営者が入る」運用だった。今の製品で止めているのも、CC に上長が入っていないメールだ
▶ 承認がどういう仕組みか：承認は、上長が1通ずつ許可するまで社外にメールが出ない仕組みだ。上長は毎回操作が要り、送る側は許可を待つ。CC 必須なら、上長は写しを受け取るだけで、メールは待たずに出る
▶ 承認に必要なデータがそろっているか：承認には「上長は誰か」の欄が要る。この会社は全員空だった。承認を選ぶなら、まず全員分のその欄を埋めるところから始めることになる（次の節）

こう決めたことで、上長チェックは Microsoft 365 のルール1本で足りる見込みになった。製品に求めることも、「URL とパスワードを別々のメールで自動で送る」「数 GB のファイルを送れる」「宛先や URL の取り違えを防ぐ」の3つに絞れた。各製品の「上長承認」は、選ぶ基準にならなくなった。

CC 必須で手放すもの

CC 必須は、送ってしまったメールを止めない。宛先を間違えても、上長が気づくのは送ったあとだ。上長には社外宛てのメールの写しが全部届くので、量が多い会社では読まれなくなる。「上長が見ている」という抑止と、あとから追える記録が残ることに価値を置けるかどうかが分かれ目になる。

規模が大きい会社なら、判断は変わりうる（ここは設計上の見立てで、自分がやった話ではない）。部署ごとに上長が違うと、CC 必須はルールを部署の数だけ作る設計が要る（上長をまとめたグループで1本にすると、どの部署の上長が CC に入っていても通ってしまう）。誤送信の事故が実際に起きていて、送る前に止めることに意味があるなら、承認を選ぶ。その場合は、次の注意が先に来る。

▼一番の注意：止めたいなら、先に上長欄を埋める。空だとエラーなしで素通りする

Microsoft 365 の上長承認は、送信者のアカウントに登録された「上長」に承認を求める仕組みだ。その欄が空なら、Microsoft の公式ドキュメントには「承認なしで受信者に届く」と書いてある。止まらないだけで、エラーも警告も出ない。

この会社は、有効なアカウントの上長欄が全員空だった。承認を選んでルールを入れていたら、ルールは「入っている」のに1通も止まらないところだった。

承認を使うなら、手は2つある。

▶ 全員の上長欄を埋める：入社・異動・退職のたびに更新する運用まで決める。1人でも空のままだと、その人のメールは素通りする
▶ 承認する人を決まった人にする：送信者ごとの上長ではなく、決まった人（最大10人）に承認を求める方式もある。この場合、上長欄は使わない

📄 設定は配られていたのに、前提のアカウントが PC に無くて何もしていなかった話はこちらの記事で書いています。

▼始める前に決めておくこと：CC に入れる人・例外・差し戻しの文面

誰を CC 必須にするか

決まった1人か、部署ごとの上長か。決まった1人にすると、その人が交代・退職したときにルールを書き換える必要がある。一方、その人が休みでも、CC に入れるだけなのでメールは止まらない（承認と違う点）。

2人とも必ず CC に入れたいなら、ルールを1人ずつに分ける。1本のルールに2人を並べると「どちらか1人が入っていれば通す」になる。

上長本人と、To・BCC に入れた場合

上長本人が送るメールは例外にする。上長を宛先（To）に入れた場合も通すかは決めておく。To と CC のどちらに入っていても通す条件も作れる。なお、ルールは CC の欄しか見ないので、上長を BCC（相手に見えない写し）に入れても例外にならず、止まる。

社内と社外が混ざった宛先

公式の説明からは、CC に上長がいないとき、止まるのは社外の宛先の分だけで、社内の宛先には届くと読める。送信者には社外の分の差し戻しが返ることになる。ただ、このルールの組み合わせでの動きを名指しした記述はない。記録だけのモードはメールを止めないので、ここはテスト用のアカウントから送るメールだけを対象にした、止めるモードのルールで確かめる。

止まったときに送信者に届く文面

止まったメールは、理由を書いた知らせ付きで送信者に返る。文面は自分で決められる。たとえば「外部宛てのメールは上長を CC に入れてください」。社員への周知と同じ言葉にしておくと、返ってきたときに迷わない。

▼ルールを入れる流れ：記録だけ → 当たったメールを確かめる → 止める

記録だけのモードで入れる：メールは止めずに、「このルールに当たった」という記録だけを残す
当たったメールを確かめる：止めてはいけないもの（上長本人のメール、不在時の自動応答、複合機や業務システムからのメールなど）が当たっていないかを見て、例外に足す。集計のレポートは、出るまで最大5日かかることがある
止めるモードに切り替える：社員に周知してから切り替える。今の製品が、社外へのメールをいったん自分のところに通してから送る仕組みになっているなら、解約の前に Microsoft 365 側のその設定を元に戻す。戻さないと、社外へのメールが出ていかなくなるおそれがある（この会社は、どうつながっているかをまだ確かめていない）

満了まで約1か月だと、記録だけの期間を取れば、止めるモードへの切り替えは満了の少し前になる。今の製品と二重に止まる期間や、どちらも止めない期間が出ないよう、切り替える日と解約の日を合わせて決める。

▼まだやっていないこと：ルールはまだ1本も入れていない

▶ ルールは未作成で、動かして確かめていない：ここに書いたのは、Microsoft の公式ドキュメントから組んだ設計だ
▶ メールのルールが他にあるか、見ていない：ある場合は、順番や重なりを確かめる
▶ 今の製品のつなぎ方と、解約の手続き：社外へのメールが製品を通っているか、解約の申し出の期限、自動更新の有無
▶ 取引先へのファイルの渡し方：製品選びは続いている

▼まとめ：自分の会社で確かめること

誤送信対策の製品の更新が近いなら、担当者（または委託先）に次を確かめてもらえばいい。

▶ 製品で実際に使っている機能はどれか：書き出すと少ないことがある。この会社は2つだった
▶ 上長に「止めてほしい」のか「見ていてほしい」のか：見ていればいいなら、Microsoft 365 のルールで作れる
▶ Microsoft 365 の承認を使うなら、全員の上長欄が埋まっているか：空の人のメールは、承認なしで届く
▶ CC 必須にする人が交代・休みのときどうするか
▶ 製品の満了日と解約の申し出の期限：社外へのメールが今の製品を通っているなら、解約の前の戻し方も

▼担当者向け：設定と手順の詳細

ここからは、実際に設定する人向け。前半の言い方と、実際の名前の対応から。

前半の言い方と、実際の名前

前半の言い方	実際の名前
Microsoft 365 のルール	Exchange Online のメールフロールール（トランスポートルール）。EAC の「メールフロー」＞「ルール」／`New-TransportRule`
上長は誰か、の欄	Entra ID のユーザーの Manager 属性
送信者の上長に承認させる	アクション `ModerateMessageByManager`（EAC：承認のためにメッセージを転送する＞送信者のマネージャーへ）
決まった人に承認させる	アクション `ModerateMessageByUser`
CC に上長が入っていれば通す	例外 `ExceptIfAnyOfCcHeader`（To か CC なら `ExceptIfAnyOfToCcHeader`、グループなら `ExceptIfAnyOfCcHeaderMemberOf`）
社内から社外へのメール	`-FromScope InOrganization` と `-SentToScope NotInOrganization`
止めて送信者に返す・その文面	`-RejectMessageReasonText`（送信者に NDR＝配信不能の通知が返る）
記録だけのモード／止めるモード	`-Mode Audit`／`-Mode Enforce`（EAC の「ルールモード」では「ポリシーヒントなしでテストする」が `Audit` に近い。対応は公式に明記がなく、説明からの読み）
ZIP にしてパスワードを別メールで送るやり方	PPAP（添付の自動 ZIP 化は Exchange Online の標準機能にない）

EAC（Exchange 管理センター）の表記は、Microsoft の日本語ドキュメントのもの。実際の画面とは違うことがある。

上長欄（Manager 属性）が空かを確かめる

Microsoft Graph PowerShell で、有効なメンバー（ゲスト以外）の Manager を1人ずつ見る。読み取りだけで、権限は委任の User.Read.All で足りる。Manager がないユーザーは API が 404 を返すので、エラーを受けて「なし」とする。下は公式の部品から組んだ例で、この形のまま実行して確かめたものではない。

Connect-MgGraph -Scopes ‘User.Read.All’

$users = Get-MgUser -All -Filter “accountEnabled eq true and userType eq ‘Member'” `
  -Property Id,DisplayName,UserPrincipalName

$users | ForEach-Object {
  $m = $null
  try { $m = Get-MgUserManager -UserId $_.Id -ErrorAction Stop } catch { }
  [pscustomobject]@{
    DisplayName       = $_.DisplayName
    UserPrincipalName = $_.UserPrincipalName
    HasManager        = [bool]$m
  }
} | Where-Object { -not $_.HasManager }

この会社でも、10月に Graph の読み取りで有効なメンバー全員の Manager を見て、入っている人は0人だった。

ルール案（未実行）

Exchange Online PowerShell で作る。<上長のアドレス> は CC 必須にする人のプライマリ SMTP アドレス（条件はプライマリアドレスだけを見る。別名のアドレスで CC に入れると例外に当たらず、止まる可能性がある）。

# 0. 既存のルールを確認（順番・重なりを見る）
Get-TransportRule | Format-Table Name, State, Mode, Priority

# 1. 記録だけのモードで作る
New-TransportRule -Name “外部宛て:上長CC必須” `
  -FromScope InOrganization `
  -SentToScope NotInOrganization `
  -ExceptIfAnyOfCcHeader “<上長のアドレス>” `
  -ExceptIfFrom “<上長のアドレス>” `
  -RejectMessageReasonText “外部宛てのメールは上長を CC に入れてください” `
  -Mode Audit `
  -SetAuditSeverity Low

▶ 例外は OR：「CC に上長がいる」か「送信者が上長本人」のどちらかに当たれば、ルールは何もしない
▶ To も認めるなら：-ExceptIfAnyOfCcHeader を -ExceptIfAnyOfToCcHeader に替える
▶ 2人とも必須にするなら：1人ずつルールを分ける。-ExceptIfAnyOfCcHeader に2人並べると「どちらか1人」で通る（公式の説明は「Cc に、指定した受信者のいずれかが含まれるメッセージ」）
▶ 理由文だけ指定する：理由文だけなら拡張ステータスコードは既定の 5.7.1。-RejectMessageEnhancedStatusCode と両方指定したときの扱いは公式の書き方があいまいなので、最初の案から外した
▶ 重大度を指定する：Audit の記録がメッセージ追跡やレポートに出るかは重大度しだいで、公式ページ同士の記述が食い違う。-SetAuditSeverity Low を明示しておく
▶ 反映まで待つ：新しいルールや変更が効くまで30分以上かかることがある

記録の見方と、止めるモードへの切り替え

▶ メッセージ追跡：EAC の「メールフロー」＞「メッセージ追跡」で該当メッセージの詳細を開き、イベントの「トランスポートルール」と、ルールが取るはずだったアクションを見る
▶ トランスポートルールレポート：EAC の「レポート」＞「メールフロー」。ルールが当たった回数が見られる。大半は24時間以内に出るが、最大5日かかるものもある

当たったメールに止めてはいけないものがないのを確かめたら、止めるモードに切り替える。

Set-TransportRule -Identity “外部宛て:上長CC必須” -Mode Enforce

記録だけのモードで確かめること

次の5つは、公式の説明だけでは断定できなかった。テスト用のメールで1回ずつ見る。1つ目は記録だけのモードでは確かめられない（メールを止めないため）ので、-From <テスト用アカウント> を足して対象をテスト用のアカウントに絞った別のルールを、止めるモードで入れて送る（この確かめ方も未検証）。

▶ 社内と社外が混ざった宛先：SentToScope は「受信者」区分の条件で、公式の一般的な説明では、拒否は条件に当たった受信者（社外）だけにかかり、ほかの受信者には届く。このルールでもそうなるか
▶ Audit の記録がメッセージ追跡に出るか：-SetAuditSeverity Low を付けた状態で
▶ 2人とも必須にする場合：1人ずつルールを分けたときに、両方そろわないと止まるか
▶ 上長を To だけに入れたメール：公式の説明が CC の欄だけを対象にしていることからの読みで、止まるはず。To も認めるなら -ExceptIfAnyOfToCcHeader にする
▶ 自動で外に出るメール：不在時の自動応答、会議の出欠の返信、複合機や業務システムから社外に出るメールが当たるか。自動応答なら -ExceptIfMessageTypeMatches OOF、会議の返信などなら Calendaring で外せる。複合機などは送信者のアドレスで外す

承認を選ぶ場合の仕様（この会社は使わない）

項目	公式の記述
`ModerateMessageByManager` と Manager 属性	送信者の Manager 属性が定義されているときだけ働く。無ければ承認なしで受信者に配信される
承認の期限	2日（管理者は延ばせない）。失効の処理は7日周期なので、実際は2〜9日の間に失効。送信者には期限切れの知らせが届く（負荷が高いと届かないこともある）
承認者の数	最大10人
グループを承認者にする	配布グループは承認者にできない

参考（Microsoft の公式ドキュメント、2026-10-28 確認）

メールフロールールのアクション（承認・拒否。日本語版は一部の訳が崩れているので、英語版と見比べる）
メールフロールールの条件と例外
New-TransportRule（-Mode・-SentToScope・-ExceptIfAnyOfCcHeader）
メールフロールールのテスト
Exchange Online の制限（承認の期限・承認者の数）
List manager（Microsoft Graph）

📅 30分無料相談、受け付けています

「誤送信対策の製品の更新が近いが、どの機能を本当に使っているのか、Microsoft 365 で足りるのかが分からない」——そういった段階からお気軽にどうぞ。今の製品で使っている機能の書き出しから一緒に進めます。

📅 30分無料相談を予約する →