【Microsoft365参考書】「メッセージ追跡」と「エクスプローラー」の違いとは？

Microsoft 365 を運用していると、

「メールが届かない」「怪しいメールが来た」「誰がどこに送ったか確認したい」

といった場面が必ず出てきます。

そのときに使う代表的な機能が次の2つです。

• メッセージ追跡（Message Trace）
• Microsoft Defender のエクスプローラー（Threat Explorer）

この2つは似ているようで、目的も視点もまったく違う機能です。

メッセージ追跡とは？

メッセージ追跡は、
メールの配送状況を確認するための機能です。

画面上から確認できる要約レポート、CSVファイルに出力する増補要約レポート、包括的レポートの取得が可能です。

主な確認内容

• 送信者・受信者
• 配信成功／失敗
• スパム判定
• 転送・リダイレクト状況
• 配信日時
• トランスポートルールの適用有無

利用シナリオ

• 「メールが届いていない」と問い合わせがあった
• 社外へ送ったメールが相手に届いているか確認したい
• 共有メールボックスに転送されているか確認したい
• 配信遅延の原因を知りたい

つまり、

“配送の事実確認” が目的

特徴

• Exchange Online のログベース
• 管理センターまたは PowerShell から利用可能
• 過去90日分まで検索可能（標準）

it-bibouroku.hateblo.jp

it-bibouroku.hateblo.jp

エクスプローラー（Threat Explorer）とは？

エクスプローラーは、
セキュリティ分析・インシデント調査のための機能です。

利用できるのは、E5 や Defender for Office 365 Plan 2 のライセンスを持っている環境です。

メール、URL、ファイルなどの脅威をリアルタイムまたはほぼリアルタイムで可視化・調査・対処 できるのが最大の特徴です。

また、メッセージ追跡との大きな違いは、送信者や受信者、件名だけではなく、DKIMの結果やマルウェア判定されたメールなど詳細な条件指定ができます。

主な確認内容

• フィッシング判定
• マルウェア検出
• URLクリック履歴
• 添付ファイルの動的解析結果
• メールが隔離された理由
• 同様の攻撃メールの横展開確認

利用シナリオ

• フィッシングメールが届いた
• 1人が誤ってURLをクリックした
• 同じ攻撃メールが他ユーザーにも届いていないか確認したい
• 隔離解除してよいか判断したい
• 攻撃キャンペーンの全体像を把握したい
• 特定のメールを削除したい

つまり、

“脅威の分析と横断調査” が目的

it-bibouroku.hateblo.jp

it-bibouroku.hateblo.jp

機能の違いを整理

項目	メッセージ追跡	エクスプローラー
主目的	配送確認	セキュリティ分析
視点	メールの流れ	攻撃の痕跡
対象	すべてのメール	脅威関連メール
URLクリック追跡	×	○
添付ファイル解析	×	○
横展開確認	×	○
ライセンス	Exchange Online	Defender for O365 P2

実務での使い分け例

ケース①「メールが届いていない」

→ まず メッセージ追跡

配送ログを確認し、

• ブロックされたのか
• 正常に届いているのか
• スパムフォルダ行きか

を特定します。

ケース②「怪しいメールが来た」

→ まず エクスプローラー

• 判定理由
• 他ユーザーへの配信有無
• URLクリック状況
• 自動調査の結果

を確認します。

ケース③「両方使うケース」

例：

• 配信ログは正常
• しかしユーザーが被害に遭った可能性がある

この場合、

1. メッセージ追跡 → 配送事実確認
2. エクスプローラー → 攻撃分析

本質的な違いとは？

実は一番大きな違いは「思想」です。

メッセージ追跡

インフラ管理者の視点
＝ メール配送の健全性を確認

エクスプローラー

SOC / セキュリティ担当の視点
＝ 攻撃の痕跡を追う

つまり、

• Exchange 管理者向け → メッセージ追跡
• セキュリティ運用担当向け → エクスプローラー

it-bibouroku.hateblo.jp

it-bibouroku.hateblo.jp

it-bibouroku.hateblo.jp

駐車場に停めている車にぶつけられたら？やるべき手順を徹底解説

「駐車していたのにぶつけられた…」
このケースは、実は想像以上に多いトラブルです。

実際に私も大雪で駐車場がせまくなっていたこともあり、車にぶつけられました。

動いていない車にぶつけられた場合でも、対応を間違えると

• 修理費で損をする
• 保険で不利になる
• 示談トラブルになる

といった問題につながることがあります。

ここでは、事故後にやるべき具体的な手順をわかりやすく解説します。

① まずは警察への届け出（物損事故）

相手が連絡してくれている場合でも、必ず警察の事故処理が入っているか確認します。

• 事故証明が出るか
• 物損事故として受理されているか

保険請求には「交通事故証明書」が必要になります。

② 現場・傷の写真を必ず撮影

保険会社とのやり取りでは、証拠が命です。

撮影しておくべきポイント：

• 車全体（位置関係がわかる写真）
• 傷のアップ
• ナンバー
• 周囲の状況（白線・障害物など）

時間が経つと状況は変わります。
気づいた時点ですぐ撮影しましょう。

③ 相手の情報を確認

最低限確認する情報：

• 氏名
• 住所
• 電話番号
• 車両ナンバー
• 加入している保険会社名

④ 自分の保険会社にも連絡する

「100％相手が悪いから連絡しなくていい」は危険です。

理由：

• 過失割合の交渉サポートを受けられる
• 弁護士特約が使える可能性
• 今後のトラブル予防になる

特に弁護士特約がある場合は、積極的に相談しましょう。

⑤ 修理か現金受取かを検討

ここが大きな分かれ道です。

修理する場合

• きれいに直る
• 将来的な査定への影響を抑えられる

現金で受け取る場合

• 修理しなければ手元にお金が残る
• 軽微な傷なら合理的な選択

注意点

• 修理しない場合でも「事故歴」は残る可能性あり
• 見えない内部損傷があることも

ディーラーや板金業者で一度見積もりを取るのがおすすめです。

⑥ 過失割合はどうなる？

駐車中（完全停止）であれば、原則「10：0」で相手過失となるケースが多いです。

ただし例外もあります：

• 駐車違反状態
• 危険な停め方
• 私有地での特殊ケース

必ず保険会社に確認しましょう。

⑦ 示談書は必ず確認

示談成立後は原則やり直しができません。

確認ポイント：

• 修理費以外の補償は含まれているか
• 代車費用は出るか
• 評価損（格落ち）は請求できるか

不安な場合は弁護士特約の活用がおすすめです。

相手とのやり取りは保険会社がおこなってくれるのか？

ケースにもよりますが、駐車場に停めている車にぶつけられた場合、こちらは完全無過失なので、自分でやり取りをしないといけません。

あなたにも「過失がある」場合（例：8:2 など）

→ あなたの保険会社が前面に出て、相手側の保険会社と交渉します。

これは保険会社が「示談交渉サービス」を行えるためです。

あなたが完全に無過失（10:0）の場合

→ あなたの保険会社は原則、交渉できません。

理由はシンプルで、

保険会社は「あなたに支払う義務が発生する事故」でないと示談交渉を代行できないからです。

駐車中でぶつけられた場合はこのケースが多いです。

この場合は：

• 相手側の保険会社から直接あなたに連絡が来る

• 修理や示談のやり取りをあなた自身が行う

という流れになります。

自分の保険会社は何もしてくれないのか？

いいえ、そんなことはありません。

✔ アドバイスはしてくれます
✔ 事故受付はしてくれます
✔ 今後の流れの説明はしてくれます

弁護士特約がある場合

→ 弁護士に交渉を依頼できます（自己負担なしが多い）

無過失事故では特に強力です。

【応用編】損をしないための考え方

実は重要なのは「修理費」だけではありません。

• 将来の売却価格
• 保険料への影響
• 精神的ストレス

トータルで考えることが大切です。

場合によっては「評価損（格落ち）」を請求できるケースもあります。

まとめ

駐車場でぶつけられた場合の流れ：

1. 警察確認
2. 写真撮影
3. 相手情報の確認
4. 自分の保険会社へ連絡
5. 修理か現金か検討
6. 示談内容を慎重に確認

慌てず、記録を残し、プロを使う。

これが最も損をしない対応です。

it-bibouroku.hateblo.jp

it-bibouroku.hateblo.jp

【Microsoft365参考書】MC1143991 onmicrosoftドメインによるメール送信の制限。MOERAドメインとは？

MOERAドメインとは？

MOERA（Microsoft Online Email Routing Address）ドメインとは、Microsoft 365テナントを新規作成した際に自動的に割り当てられる、初期のメールルーティング用ドメインです。
MOERAドメインは、[<テナント名>.onmicrosoft.com] のような形式になります。

Microsoft 365の初期セットアップ時に、独自ドメインが未設定でもメール送受信ができるようにするための内部ルーティングアドレスです。

一部のサービス（例：Exchange Online、SharePoint Online）では、MOERAドメインが内部的に使用されることがあります。

セキュリティの問題

MOERAドメインは、SPFと DKIM が既定で有効になっているため、基本的な送信元認証は機能します。

ただし、MOERAドメインは、試用版テナントを取得することで無料で利用できることから、スパマーに悪用されやすいという問題があります。

そのため、メールを利用するなら MOERA ドメインは利用せずにカスタムドメインを登録して利用することが推奨されています。

onmicrosoft ドメインの送信制限とは？

onmicrosoft.com ドメインからのメール送信制限は、テナント単位で 24 時間以内に onmicrosoft.com ドメインから外部に送信できるメッセージが 100 アドレスまでになるという制限です。
ユーザー単位ではなく、テナント全体での制限となることをご留意ください。
 
また、配布リストなどのグループのメンバーに外部ユーザーが含まれている場合も対象となり、グループにメールを送信し展開後に配信されたユーザー数でカウントされます。

固定の時間帯ではなくローリングウィンドウ方式にてカウントされる動作となります。
※ 現在の時刻から過去 24 時間に送信した数が制限の対象となります。

制限に抵触した場合は以下のエラーが返されることを確認しており、24 時間経過し制限が解除されるまで待つしかありません。

エラー内容

550 5.7.236 Your message can't be sent because your tenant has exceeded its daily limit for sending email to external recipients from your tenant's onmicrosoft.com domains. For more information see https://aka.ms/EXONdrs.

MC1143991の概要

MC1143991は、Microsoft 365のメッセージセンターで発信された公式通知であり、以下の内容が含まれています。

通知タイトル

Limiting onmicrosoft domain usage for sending emails（onmicrosoftドメインによるメール送信の制限）

主な内容

Microsoftは、MOERAドメイン（例：contoso.onmicrosoft.com）から送信される外部メールに対して、送信制限（スロットリング）を導入します。

1組織あたり 24時間で MOERA ドメインから送信される外部メールが最大100通までに制限され、制限に達した場合は、エラーコード 550 5.7.236 を含む配信不能通知 (NDR）が返されます。

なお、内部ユーザーへ送信するメールや受信メールには影響はありません。

実施時期

2025年10月中旬から順次開始

2026年6月初旬までに全組織へ展開完了予定

必要な対応

現在、MOERAドメインを利用しているアカウントをカスタムドメインに変更。

既定のドメインをカスタムドメインに変更。

MOERAドメインを削除することはできるか？

MOERAドメインはMicrosoft 365の内部ルーティングに使用されるため、完全削除はできません。ただし、ユーザーやグループに紐づけられていない状態にすることで、事実上の無効化は可能です。

なお、注意する点は以下のとおりです。

• MOERAドメインを使用していたアプリ（例：Bookings、通知メール）が動作しなくなる可能性があります。
• 削除後に再利用するには、テナントの削除と再作成が必要になる場合があります。
• Microsoft 365の一部機能（内部ルーティング、認証など）に影響が出る可能性があるため、慎重な検討が必要です。

it-bibouroku.hateblo.jp

it-bibouroku.hateblo.jp

【Microsoft365参考書】ExchangeOnlineでのPowerShell ISE と通常の PowerShell の違いとは？

Exchange Online の管理で、PowerShell を利用するシナリオがあると思います。

その中でよく迷うのが、

• PowerShell ISE
• 通常の PowerShell（Windows PowerShell / PowerShell 7）

本記事では、Exchange Online の視点で両者の違いを整理します。

PowerShell ISE とは？

PowerShell ISE（Integrated Scripting Environment）は、
PowerShell スクリプトを作成・実行するための統合開発環境です。

主な特徴

• エディタと実行画面が一体
• 複数行スクリプトが書きやすい
• 補完や色分け表示が見やすい
• Windows に標準搭載（旧世代ツール）

学習用途では便利ですが、現在は Microsoft により非推奨となっています。

通常の PowerShell とは？

通常の PowerShell とは、主に以下を指します。

• Windows PowerShell 5.1
• PowerShell 7（pwsh）

Exchange Online 管理では、
PowerShell 7 + ExchangeOnlineManagement モジュール が公式推奨構成です。

Exchange Online の観点での決定的な違い

① PowerShell ISE は Exchange Online 非推奨

Exchange Online 管理で使用する ExchangeOnlineManagement モジュールは、
PowerShell ISE での利用が推奨されていません。

• 接続エラーが発生する
• 認証画面が表示されない
• 将来的な動作保証がない

② モダン認証・MFA と ISE の相性問題

Exchange Online は OAuth（モダン認証）と MFA が必須です。

Connect-ExchangeOnline

この接続時、ISE では以下の問題が起きやすくなります。

• ブラウザ認証画面が出ない
• ログインで固まる
• 意図しない認証エラー

③ PowerShell 7 は Exchange Online 向けに最適化されている

• 高速で安定している
• Microsoft の公式ドキュメントが前提としている
• 今後も継続的にアップデートされる

PowerShell ISE と通常の PowerShell の違い(まとめ)

 

項目	PowerShell ISE	通常の PowerShell（コンソール）
UI（画面）	GUI エディタ付き	文字だけのコンソール
スクリプト編集	タブ・色分け・補完が使いやすい	メモ帳的で編集は弱い
実行	画面上で F5 実行・分割画面	コマンド入力のみ
目的	スクリプト作成・学習向け	実運用・最新環境向け
開発状況	すでに非推奨（メンテ終了）	PowerShell 5/7 で現役
OS	Windows のみ	Windows / macOS / Linux

 

 

現在の推奨スタイル：ISE → VSCode + PowerShell 拡張機能

Microsoft の公式推奨は、スクリプト開発は VSCode、実行は PowerShell コンソールです。

VSCode が推奨される理由

• ISE 互換キーバインドがある

• 自動補完が超強力

• デバッグ機能が充実（ブレークポイント、変数ウォッチ）

• PowerShell 7 を完全にサポート

Powershell ISE を利用することはできるか？

ExchangeOnline Management Module のバージョン 3.7.0 以降では、Powershell ISEとの互換性に関する問題が報告されており、認証ウィンドウが表示されずに接続ができないという事象が確認されています。

ExchangeOnline Management Module のバージョン 3.7.0 以降では、Web アカウントマネージャー(WAM) の認証が実装されており、ISE では WAM での認証がエラーとなります。

エラー内容

A window handle must be configured. See https://aka.ms/msal-net-wam#parent-window-handles

なお、Connect-ExchangeOnline のパラメーターとして "DisableWAM" を追加することで WAM を無効化し、Exchange Online に接続することが可能です。

 
一度、PowerShell ISE を起動し、Connect-ExchangeOnline 実行してエラーになると、その Powershell ISE のセッションに WAM 利用することが紐づけられるため、PowerShell ISE を再起動してから以下のコマンドレットを実行してください。

WAM を無効化し、Exchange Online に接続するコマンドレット

[実行例]
Connect-ExchangeOnline -UserPrincipalName admin@contoso.com -DisableWAM
 
※ admin@contoso.com をグローバル管理者のユーザID(UPN)に置き換えて実行してください。

it-bibouroku.hateblo.jp

it-bibouroku.hateblo.jp

it-bibouroku.hateblo.jp

【Microsoft365参考書】MC786329 SMTP 接続の基本認証が廃止される？

2027年まで廃止される期間が延長されました。

MC786329 で 2025 年 9 月に  SMTP Auth (基本認証による接続) が廃止となることが公開されました。

現時点の予定として、2024 年 9 月に、Exchange 管理センターのレポート機能 (SMTP AUTH クライアント送信レポート) に関して、基本認証で SMTP を利用しているユーザーが特定できるように更新されるようです。

また、クライアント送信で基本認証 (SMTP AUTH) を使用しているテナントには、2025 年 1 月の段階と、2025 年 8 月の段階で、メッセージセンターの投稿にて警告される予定もあるようです。

techcommunity.microsoft.com

SMTP AUTH を対象とした基本認証が廃止されると、SMTP AUTHクライアント送信を基本認証で使用しているクライアントからのメール送信がおこなうことができなくなります。

SMTP AUTH クライアント送信はプリンターや複合機やシステムからテナント内外にメールを送信する場合などに用いられる送信方法です

そのため、プリンターや複合機が先進認証のSMTPクライアント送信に対応していない場合は、メールの送信ができなくなりますので、メーカーなどに確認しておいたほうがいいと思います。

Outlookクライアントでは、POPとIMAPの基本認証に対応していないので、あえてSMTP AUTHだけ利用している人はほとんどいないと思います。通常はMAPI接続で利用していると思いますので、その場合はOutlookクライアントでの送信には影響はありません。

SMTP AUTH 送信の構成要件

・ Exchange Online に実在するライセンスが付与されたメールボックスのユーザーアカウント (サインイン ID) とパスワードを指定する。

・ 接続先 SMTP サーバー名 smtp.office365.com を指定する

・ TCP ポート  587 (または 25 番ポート) を利用可能

・ デバイスで TLS バージョン 1.2 以上を使用できる

・ 多要素認証 (MFA) を使用していない

なお、構成要件を満たしているにもかかわらず、送信に失敗する場合の要因としては、以下が考えられます。

考えられる要因

1. ユーザーの SMTP 認証許可設定 (SmtpClientAuthenticationDisabled) が無効

2. テナントの SMTP 認証許可設定 (SmtpClientAuthenticationDisabled) が無効

3. テナントの [セキュリティの既定値群] が有効

4. ユーザーの多要素認証が有効

1.ユーザーの SMTP 認証許可設定の確認手順

1. Microsoft 365 管理センター (https://admin.microsoft.com) に全体管理者アカウントでサインインします。

2. 画面左側メニューより [ユーザー] > [アクティブなユーサー] をクリックします。

3. 一覧より対象ユーザーをクリックします。

4. 右側に展開された画面で [メール] をクリックします。

5. [メールアプリ] 項目で [メール アプリを管理する] をクリックします。

6. [認証済み SMTP] にチェックが入っていない場合はチェックを入れ、[変更の保存] をクリックします。

2.テナントの SMTP 認証許可設定の確認手順

1. Microsoft 365 管理センター (https://admin.microsoft.com) に全体管理者アカウントでサインインします。

2. 画面左側メニューより [Exchange] をクリックします。

3. [設定] > [メール フロー] とクリックします。

4. [組織で SMTP AUTH プロトコルを無効にする] にチェックが入っている場合はチェックを外し、 [保存] をクリックします。

3.[セキュリティの既定値群] 設定の確認手順

[セキュリティの既定値群] の設定が有効になっている場合、基本認証がブロックされます。

1. Microsoft Entra 管理センター (https://entra.microsoft.com/) にグローバル管理者アカウントでサインイン

2. 左メニューの [概要] をクリック

3. [プロパティ] をクリック

4. [セキュリティの既定値の管理] をクリック

5. [セキュリティの既定値群] を [無効 (推奨しません)] に設定

6. [無効にする理由] の該当のチェック項目にチェック

  ※ その他を選んだ場合は、詳しい文章を入力する必要がございます。

7. [保存] をクリック

4.ユーザーごとの多要素認証設定の確認手順

対象ユーザーで多要素認証が設定されている場合、SMTP 認証での送信ができません。

1. Microsoft Entra 管理センター (https://entra.microsoft.com) へ、全体管理者アカウントでサインインします。  

2. 画面左側メニューの [ユーザー] > [すべてのユーザー] をクリックします。  

4. 画面上部の [ユーザーごとの MFA] をクリックします。  

5. 一覧で対象ユーザーの [MULTI-FACTOR AUTHENTICATION の状態] で [有効] または [強制] の場合は多要素認証が有効となっていますので、対象ユーザーをクリックし、[無効にする] > [はい] をクリックします。

6. [閉じる] をクリックします。

なお、現在、テナントで OAuth が利用可能な状態であるかどうかについては、以下のコマンドレットにて確認可能です。

下記のサイトを参考に Exchange Online に接続します。

it-bibouroku.hateblo.jp

 テナント設定

 <実行例>

Get-OrganizationConfig | fl OAuth2ClientProfileEnabled

基本認証 (SMTP AUTH) を利用しているシステムやユーザを確認するには？

Exchange 管理センターの SMTP AUTH クライアントのレポートにて OAuth (先進認証)であるか、基本認証であるか確認が可能となることが予定されていますが、基本認証 (SMTP AUTH) を利用していることを確認する場合は、Microsoft Entra ID のサインインログでも可能です。

Exchange 管理センターの SMTP AUTH クライアントのレポートにて OAuth であるか、基本認証であるか確認できるようですが、サインインログでは基本認証であるかということしか確認ができません。

SMTP Auth (基本認証による接続) 利用の有無を確認する手順

1. 全体管理者にて Microsoft 365 管理センター (https://admin.microsoft.com/) にアクセスします。

2. サイドリンクバーの [… すべてを表示] - [ID] をクリックします。

3. Microsoft Entra 管理センターに遷移したのち、[ユーザー] > [すべてのユーザー] > [サインイン ログ] の順にクリックします。

4. [許可された時刻] にて検索したい期間を設定し [適用] をクリックします。

5. [フィルターの追加] - [クライアントアプリ] にチェックを入れて [適用] をクリックします。

6. [クライアントアプリ : 選択されていません] をクリックします。

8. [レガシ認証クライアント] の下にある [SMTP] をオンにして [適用] をクリックします。

9. SMTP 基本認証で接続されていたサインイン ログが表示されます。

サインインログで結果が表示されない場合、テナントではSMTP AUTHクライアント送信を基本認証で利用されていない状況と判断できます。

SMTPクライアント送信については、以下の記事でご紹介しておりますので参考としてくださいね。

it-bibouroku.hateblo.jp

it-bibouroku.hateblo.jp