OneDrive（SharePoint Online）で誰がいつファイルを削除したかを把握できないと、誤削除や内部不正、ランサム被害の初動が遅れます。Microsoft 365 Business Basicでも、Microsoft Purviewの監査（標準）＋アラート ポリシーで「削除」を検知し、管理者へメール通知できます。
この要件でつまずく理由：OneDriveの「削除」は標準機能だけだと追いにくい
OneDrive for Business は仕組み上、実体は SharePoint Online 上の「個人用サイト（OneDrive サイト）」として動きます。そのため、ファイルが削除された事実を正確に拾うには、SharePoint/OneDrive の操作履歴を記録する仕組み（監査ログ）が必要になります。
よく混同されがちですが、SharePoint の従来型「アラート（変更通知）」は、基本的に特定のライブラリやリスト単位での変更通知であり、管理者が全ユーザーの OneDrive を横断して「削除」を監視する用途には向きません。さらに、通知が必要な対象が増えるほど設定と保守が破綻しやすく、誤通知・未通知も起きがちです。
| やりたいこと | 従来のSharePointアラート | Purview監査＋アラートポリシー |
|---|---|---|
| 全ユーザーのOneDrive削除を一括で検知 | 難しい（対象ごとに設定が必要） | 可能（ユーザー条件なしで設計できる） |
| 特定ユーザーだけ削除を監視 | ユーザー側の設定に依存しやすい | 可能（対象ユーザーを条件に指定） |
| 削除した人・時刻・対象ファイルを追跡 | 通知文だけでは情報が不足しがち | 監査ログに証跡が残る（調査にも使える） |
| 監視と調査を管理者が一本化 | 運用が分散しやすい | コンプライアンス/セキュリティ側で集中管理 |
結論：Microsoft Purview の監査（Audit Standard）＋アラート ポリシーが王道
Microsoft 365 Business Basic で「OneDrive/SharePoint のファイル削除を検知してメール通知したい」という要件は、Microsoft Purview の監査（Audit Standard）で削除イベントを記録し、アラート ポリシー（Alert policy）で通知するのが最短ルートです。
監査ログは「いつ・誰が・何をしたか」を証跡として残す仕組みなので、通知だけでなく、後からの調査・説明（いつ誰が削除したか、誤削除か、不正か）にも直結します。運用を考えるほど、通知より先に監査ログを正しく残すことが重要になります。
事前に押さえるポイント（権限・対象・通知のタイミング）
| ポイント | 押さえる内容 | 実務上のコツ |
|---|---|---|
| 必要な権限 | 監査ログ検索・アラート作成ができる管理者ロールが必要 | 「自分だけが見られる」状態にすると引き継ぎが大変。運用者用の管理者アカウント/グループを用意 |
| 対象範囲 | OneDrive の削除も SharePoint の削除も同じ監査基盤で拾える | ポリシー名に「全社」「特定ユーザー」「高リスク」など範囲が分かる命名を |
| 通知の遅延 | 監査ログ反映やアラート発報にはタイムラグが出ることがある | 本番前に「いつ届くか」をテストして期待値を揃える。運用は“即時”前提にしない |
| 通知の量 | 全ユーザーの削除を「1件ごと」に通知するとメールが埋まる | しきい値（一定件数以上で通知）や、重要フォルダ/重要ユーザーに絞る |
監査（Audit Standard）が有効か確認する
まずは、監査ログが利用できる状態かを確認します。画面名称は更新されることがありますが、基本は「Microsoft Purview コンプライアンス ポータル」で操作します。
- Microsoft Purview コンプライアンス ポータルを開く
- 「監査」→「検索」（Audit > Search）を開く
- 検索画面が開けるか確認する
もし「記録を開始」などの案内が出る場合は、案内に従って監査を有効化します。テナントの状態や権限によって表示が異なることがあるため、検索画面が開けない場合は、まず自分のアカウントの管理者ロールを見直してください。
監査ログで削除イベントを先に確認する（通知設定の前に必ず）
アラートは、裏側で「監査ログに記録されたイベント」を条件に動きます。つまり、監査ログで削除が拾えていない限り、通知も飛びません。先に監査ログ検索で「Deleted file（ファイルの削除）」が見える状態を作るのが、遠回りに見えて最短です。
監査ログ検索のおすすめ手順
- 監査ログの検索で期間を「直近（例：過去24時間）」に絞る
- アクティビティ（活動）でDeleted file（ファイルの削除）を選ぶ（必要に応じて Deleted folder も）
- まずはテスト用に、自分の OneDrive でファイルを1つ削除する
- 数分〜しばらく待ってから検索し、削除イベントが出るか確認する
この時点で結果が出れば、あとはそのイベントをトリガーにアラートを作るだけです。検索結果の詳細では、少なくとも次の観点が追えるかを確認しましょう。
- 実行者（誰が削除したか：ユーザー）
- 対象（どのファイル/フォルダか：名前やパス）
- 実行時刻（いつ削除したか）
- 場所（OneDrive/SharePoint のどこか）
検索条件のメモとして、運用で使いやすい形を残しておくと楽です。
活動（Activity）：Deleted file
期間：過去24時間
ユーザー：user@yourdomain（特定ユーザー監視時のみ）
アラート ポリシーで削除をメール通知する
監査ログで削除イベントが確認できたら、次はアラート ポリシーです。UI は「Purview 側のアラート」から「Defender 側のアラート ポリシー」画面へ誘導される構成になっていることがあります。経路が多少違っても、やることは共通で、削除イベント（Deleted file）を条件にして通知先メールを設定します。
作成の流れ（画面遷移は多少前後してもOK）
- Purview のメニューで「アラート」関連の画面を開く
- 「Defender でアラート ポリシーを表示」などの導線から Alert policy 画面へ移動する
- New alert policy で新規作成する
- 条件（アクティビティ）に Deleted file を指定する
- 通知先（メール）に管理者のアドレスを指定する
- 必要なら対象ユーザーやしきい値で絞り、保存して有効化する
おすすめ設定（まず迷ったらこの形）
| 項目 | おすすめ | 理由 |
|---|---|---|
| ポリシー名 | OneDrive/SharePoint ファイル削除検知（全社） | 後から見た時に目的が一目で分かる |
| アクティビティ | Deleted file（＋必要なら Deleted folder） | まずは削除を確実に拾う |
| 通知先 | 管理者メール（＋運用チーム共有アドレス） | 個人宛てだけにしない。引き継ぎと見落としを減らす |
| しきい値 | 運用に合わせて調整（最初は低め→ノイズを見て上げる） | 全件通知は運用が破綻しやすい。現実的な量にする |
| 対象ユーザー | 全社監視：指定しない / 特定監視：対象ユーザーを指定 | 目的に応じて設計を分ける |
ケース別の設計例
全ユーザーの削除を通知したい（ただしメール爆発を防ぎたい）
「全ユーザーの削除をすべて通知」は、理想に見えて通知の洪水になりやすいです。特に OneDrive は日常的に整理が行われるため、1件ごとの通知は現場で読まれなくなります。おすすめは、次のいずれかです。
- しきい値方式：一定時間内の削除件数が多い場合のみ通知（大量削除の兆候を拾う）
- 重要フォルダー方式：特定フォルダー配下だけを通知対象にする（例：経理、契約書、社外共有フォルダー）
- 重要ユーザー方式：役員・情シス・経理など、影響の大きいユーザーだけ先に監視する
| 設計パターン | 狙い | 向いている組織 |
|---|---|---|
| しきい値方式 | ランサムや誤操作による大量削除を早期検知 | ユーザー数が多い/削除が日常的に多い |
| 重要フォルダー方式 | 守りたいデータの削除だけを確実に拾う | 重要データの置き場が決まっている |
| 重要ユーザー方式 | 事故時の影響が大きいアカウントを優先監視 | スモールスタートしたい |
特定ユーザーだけ監視したい（退職予定者・委託先・高権限ユーザーなど）
対象ユーザーを絞れるなら、通知運用は一気に現実的になります。アラート ポリシーの条件に、対象ユーザー（実行者）を指定して作成します。
- 退職予定者・異動者など、データ持ち出しや整理が増えるタイミング
- 委託先アカウント（利用期間が決まっていて監視したい）
- 高権限ユーザー（共有領域に影響を与えられる）
ポリシーを分けておくと、通知メールを見た瞬間に「誰の監視なのか」が分かり、初動が速くなります。
「重要な削除だけ」通知したい（ノイズを減らす実務テクニック）
削除は日常業務でも起きるため、運用では“重要”の定義が鍵です。次のような条件で段階的に絞ると、ノイズを抑えつつ検知力を落としにくくなります。
- 共有された場所（社外共有や特定チームサイト）に限定する
- ファイル種類（例：.xlsx / .docx / .pdf など）を対象にする
- 命名規則（例：「契約」「見積」「個人情報」などのキーワード）で検知対象を設計する
- まずは「大量削除」だけ拾い、次に「重要フォルダー」へ広げる
保存・有効化後のテスト手順（“動く”を確認する）
アラート ポリシーは、保存してすぐに完璧に飛ぶとは限りません。環境によって反映に時間がかかることがあります。テストは次の流れが確実です。
- テスト用ファイルを用意（分かりやすい名前にする）
- 対象の OneDrive で削除する（可能なら複数パターン：Web、同期クライアントなど）
- まず監査ログで削除イベントが出るか確認する
- 次にアラートの画面（Purview/Defender）でアラートが生成されているか確認する
- 最後に通知メールを確認する（迷惑メールもチェック）
通知が来ない／遅いときのチェックリスト
| 症状 | よくある原因 | 対処 |
|---|---|---|
| 監査ログに削除が出ない | 監査が有効化されていない／権限不足／検索条件のミス | 監査の有効化状態と管理者ロールを確認。期間とアクティビティを絞って再検索 |
| 監査ログは出るがアラートが出ない | ポリシー条件が絞りすぎ／対象ユーザー指定が違う | 一度条件を最小（Deleted file のみ）にして動作確認してから絞り込む |
| アラートは出るがメールが来ない | 通知先設定ミス／メールが迷惑メール扱い | 通知先アドレスを再確認。共有アドレスにも送る。迷惑メール/隔離を確認 |
| 通知が数時間遅れる | 監査ログ反映・アラート処理のタイムラグ | 即時性が必要なら設計を見直す（しきい値や監視対象の限定、バックアップ併用） |
通知を受け取った後の初動フロー（運用の型）
削除アラートは「削除が起きた」ことを知らせるだけなので、受信後にどう動くかを決めておくと、誤削除にも不正にも強くなります。おすすめの初動フローは次の通りです。
- 事実確認：アラートの詳細（実行者・対象・時刻・場所）を確認し、監査ログ検索でも同じイベントが出るかを見ます。
- 影響範囲の把握：単発か、連続/大量かを確認します。大量削除や複数フォルダーにまたがる場合は、ランサムや誤操作の可能性が上がります。
- 本人確認：実行者に「意図した削除か」「操作ミスか」「同期クライアントで一括削除になっていないか」を確認します（急ぎの場合は復元を優先）。
- 復元：基本は OneDrive/SharePoint のごみ箱から復元します。時間が経つほど復元が難しくなる場合があるため、迷ったら早めに戻してから精査するのが安全です。
- 再発防止：大量削除が頻発する場合は、同期設定・フォルダー構成・アクセス権・教育（「移動」と「削除」の違い）を見直します。
復元の考え方（ごみ箱を前提に“戻せる設計”にする）
削除検知は大事ですが、実際の現場では「通知が来たのに、もう戻せない」が一番困ります。監視と合わせて、復元手段もセットで整備しましょう。
- ユーザーが削除したファイルは、まずごみ箱に入るケースが多い
- ごみ箱から消えた後も、段階的に保持される構成になっている場合がある（環境や設定による）
- 復元できる期間や動作は、組織の設定や保持ポリシーで変わることがある
「通知＝事故対応のスタート」になるので、監視ポリシーと一緒に復元手順（誰が・どこで・どう戻すか）を社内手順として残しておくと安心です。
削除の挙動でハマりやすいポイント（ごみ箱・同期・完全削除）
OneDrive/SharePoint の「削除」は、現場の感覚とシステムの挙動がズレることがあります。運用前に理解しておくと、誤検知や見逃しを減らせます。
- ごみ箱へ移動＝削除として扱われることが多い（ユーザーは“まだ戻せる”つもりでも、監査上は削除として記録される）
- ごみ箱を空にする操作は別イベントになることがある（必要なら追加で監視）
- 同期クライアントからの削除も監査に残るが、反映タイミングがずれることがある
- 大規模なフォルダー削除は「1操作＝多数の削除イベント」として記録され、通知が増えやすい
運用をラクにする実践テンプレ（おすすめのポリシー分割）
最初から完璧な1本を作るより、目的別に分けた方が運用が安定します。例として、次の3本立てが使いやすいです。
| ポリシー | 目的 | 条件例 | 通知先 |
|---|---|---|---|
| 大量削除検知 | ランサム/誤操作の早期検知 | Deleted file、一定時間内の件数が多い | 情シス/管理者（即対応） |
| 重要ユーザー監視 | 影響が大きいアカウントの監視 | Deleted file、対象ユーザー指定 | 管理者＋上長（必要に応じて） |
| 重要データ領域監視 | 守るべき置き場の監視 | Deleted file、特定サイト/フォルダーに限定 | 管理者＋該当部門 |
補足：代替案と、選ぶときの判断基準
「削除通知」だけを目的にすると、別ルートも候補に上がります。ただし、証跡（監査）と通知（アラート）を一体で扱えるのが Purview の強みです。要件に合わせて使い分けましょう。
| 手段 | メリット | デメリット | おすすめ度 |
|---|---|---|---|
| Purview監査＋アラートポリシー | 証跡が残る／管理者が一元管理／OneDriveとSharePointを横断 | 即時ではないことがある／通知量の設計が必要 | ◎ |
| SharePoint従来アラート | 設定が直感的／特定ライブラリでは手軽 | 横断監視に弱い／運用が分散しやすい | △ |
| Power Automateで監視 | 柔軟な通知先（Teams等）／条件分岐ができる | 削除検知は設計が難しいことがある／大規模運用に不向き | △ |
| バックアップ製品/サービス | 復旧が強い／監視と復元がセットになりやすい | コスト増／運用が別系統になる | ○（復旧重視なら） |
よくある質問
OneDriveだけでなく、チームのSharePointサイトの削除も同じ仕組みで通知できますか？
はい。OneDrive も SharePoint Online も、操作履歴は同じ監査の仕組みに記録されるため、削除イベントを条件にしたアラート設計は共通化できます。運用上は「個人領域（OneDrive）」と「共有領域（チームサイト）」で通知の重要度が変わりやすいので、ポリシーを分けるのがおすすめです。
すべての削除をリアルタイムにメールで受け取れますか？
監査ログとアラートは便利ですが、反映や通知にタイムラグが出ることがあります。また、全件をリアルタイムで通知するとメールが埋まりやすく、結果として見落としにつながります。実務では「大量削除」「重要データ」「特定ユーザー」など、事故につながりやすい条件に寄せて設計する方がうまく回ります。
削除した本人にも通知したいのですが可能ですか？
技術的には通知先に本人を含めることもできますが、運用設計としては慎重に判断してください。誤削除なら良い一方、不正や調査が必要なケースでは「本人に通知されること」自体がリスクになる場合があります。まずは管理者/運用チームへの通知で始め、必要に応じて部門管理者へ展開するのが安全です。
通知が多すぎて運用できません。どう減らすのが現実的ですか？
いきなり全件通知を目指すのではなく、次の順番で“意味のある通知”に寄せていくのが現実的です。
- 大量削除（しきい値）だけ拾う
- 重要ユーザーだけ拾う
- 重要フォルダー/重要サイトだけ拾う
- 必要があれば部門ごとにポリシーを分割する
通知は「気付ける量」に収めて初めて価値が出ます。最初の1〜2週間は試行期間として、受信状況を見ながら微調整する前提で進めると失敗しにくいです。
まとめ：Business Basicでも「削除の検知と通知」は実現できる
OneDrive（SharePoint Online 含む）の削除を管理者が把握したいなら、まずは監査ログで削除が取れる状態を作り、その上でアラート ポリシーでメール通知するのが最も現実的です。
ポイントは「全件通知を目指しすぎない」こと。運用で読まれない通知は無いのと同じです。最初は重要ユーザーや大量削除など、事故につながりやすい部分から始め、ログとアラートを見ながら段階的に最適化していくと、Business Basic でも十分に“使える監視”になります。
コメント