SharePoint の Microsoft 365 Backup を運用するうえで、最初に確認すべきポイントは「どのサイトをバックアップ対象にするか」「対象から外した後も既存バックアップと課金がどう扱われるか」です。公式ドキュメント「Create, view, and edit backup policies in Microsoft 365 Backup」は、SharePoint、OneDrive、Exchange のバックアップポリシーを作成・確認・編集するための管理者向け手順を整理したものです。特に SharePoint 管理者は、CSV 一括登録、サイトフィルター、個別選択、ポリシー編集時の削除扱い、複数ポリシーの上限、Multi-Geo 環境での制約を押さえておく必要があります。(Microsoft Learn)
2026年7月時点で重要なのは、単に「バックアップを有効化する」ことではありません。既存の SharePoint サイトを漏れなく保護できているか、今後追加されるサイトをどう拾うか、不要サイトを外したときに費用がどう残るかまで含めて、バックアップ設計を見直すことです。
SharePoint の Microsoft 365 Backup ポリシーとは
Microsoft 365 Backup のバックアップポリシーは、組織内の Microsoft 365 データを保護するために、管理者が定義するバックアップ計画です。SharePoint であれば保護対象は SharePoint サイト、OneDrive であればユーザーの OneDrive アカウント、Exchange であればメールボックスです。Microsoft 365 Backup を SharePoint、OneDrive、Exchange で利用するには、各サービスごとにバックアップポリシーを作成する必要があります。(Microsoft Learn)
注意したいのは、ポリシー画面で保持期間やバックアップ頻度を確認できても、現時点ではそれらを自由に変更できる設定項目ではない点です。管理者が主に制御するのは「どのサイト、アカウント、メールボックスを保護対象に含めるか」です。SharePoint のバックアップポリシーでは、部門別、地域別、重要度別などに複数のポリシーを作成できますが、1サービスあたりの上限は100ポリシーで、同じ SharePoint サイトを複数のバックアップポリシーに重複登録することはできません。(Microsoft Learn)
つまり、SharePoint のバックアップ設計では「重要サイトを片っ端から追加する」だけでは不十分です。後から管理しやすい単位でポリシーを分け、どのサイトがどのポリシーに属しているかを説明できる状態にしておくことが重要です。
2026年7月時点で確認すべき更新ポイント
公式 Learn の該当ページでは、バックアップポリシーの作成、表示、編集、名前変更、動的ルール、バックアップ状態、Multi-Geo 環境の扱いが整理されています。一方で、Microsoft Graph の更新情報では、2026年6月のプレビューとして、SharePoint Online、OneDrive、Exchange Online のワークロード全体を保護する Full workload backup API が追加されています。これにより、将来的には「対象を個別に追加する」設計だけでなく、「原則すべて保護し、除外対象だけを指定する」設計も重要になります。(Microsoft Learn)
なお、Microsoft Learn の該当ページ自体には ms.date 06/16/2025 が表示され、GitHub の履歴では2026年4月22日などのコミットも確認できます。2026年7月2日付の更新情報として社内展開する場合でも、実際のロールアウト状況やテナント固有の通知は Microsoft 365 管理センターの Message Center と併せて確認するのが安全です。(GitHub)
| 確認項目 | 管理者が見るべきポイント | 実務上の判断 |
|---|---|---|
| ポリシー対象 | SharePoint サイト、OneDrive アカウント、Exchange メールボックスをサービス別に管理 | SharePoint だけでなく、OneDrive・Exchange との保護範囲の差分も確認する |
| ポリシー数 | 1サービスあたり最大100ポリシー | 部門別・地域別・重要度別など、後で監査しやすい単位に分ける |
| 重複登録 | 1つの SharePoint サイトは1つのバックアップポリシーにのみ所属 | 同じサイトを別ポリシーへ二重登録する運用は避ける |
| 削除時の扱い | 対象から外しても既存バックアップは削除されない | 「保護停止」と「バックアップ削除」を混同しない |
| 今後の方向性 | Full workload backup API では除外対象を指定する考え方が登場 | 全社保護へ寄せる場合は、除外リストと費用見積もりを先に整備する |
SharePoint バックアップポリシーの作成方法
SharePoint のバックアップポリシーは、Microsoft 365 管理センターから作成します。大まかな流れは次のとおりです。
| 手順 | 操作内容 | 確認ポイント |
|---|---|---|
| 1 | Microsoft 365 管理センターを開く | 権限が不足していると Microsoft 365 Backup の設定に進めない |
| 2 | Settings を開く | 管理センターの表示はテナントやロールにより異なる場合がある |
| 3 | Microsoft 365 Backup を選択 | OneDrive、SharePoint、Exchange の各セクションを確認する |
| 4 | SharePoint セクションで Set up policy を選択 | 既存ポリシーがある場合は重複対象に注意する |
| 5 | Overview を確認して Next | 保護対象や復元の考え方を確認する |
| 6 | サイト選択方法を選ぶ | CSV、フィルター、個別選択から選択する |
| 7 | ポリシー名を入力 | 名前は短く、部門や用途が分かる形式にする |
| 8 | Review 画面で確認し Create policy を実行 | 対象サイト数、命名、範囲に誤りがないか確認する |
SharePoint サイトをポリシーに追加すると、復元ポイントが利用可能になるまで最大で1,000サイトあたり15分程度かかる場合があります。大規模テナントでは、ポリシー作成直後に復元テストを始めるのではなく、処理完了を待ってから確認する運用にしておくと混乱を避けられます。(Microsoft Learn)
SharePoint サイトの選択方法は3種類
SharePoint のバックアップポリシー作成では、主に3つの方法でサイトを追加できます。どの方法が最適かは、対象サイト数、命名ルールの有無、管理台帳の整備状況によって変わります。
| 選択方法 | 向いているケース | 注意点 |
|---|---|---|
| CSV ファイルでアップロード | 対象サイトが多く、事前にサイト一覧を管理している場合 | CSV は最大50,000件まで。URL の誤記や古いサイトの混入に注意 |
| サイト名・URL・最終更新日などの条件で抽出 | 命名規則が整っている部門サイトやプロジェクトサイト | SharePoint のサイトフィルターはプレビュー扱いの機能が含まれる |
| 個別に検索して選択 | 重要サイトだけを少数保護したい場合 | 新規サイトの追加漏れが起きやすい |
CSV アップロードは大量登録に向いていますが、サイト一覧の鮮度が低いと不要サイトまで保護対象に入る可能性があります。サイトフィルターは便利ですが、プレビュー機能を含むため、本番運用では想定どおり抽出されているかを必ず確認してください。個別選択は分かりやすい一方で、サイト数が増えるほど管理者の手作業に依存しやすくなります。(Microsoft Learn)
実務では、最初に重要サイトを個別選択で保護し、その後に部門別・拠点別の CSV 管理へ移行する流れが現実的です。すでに SharePoint サイト台帳を持っている組織なら、CSV を正とし、バックアップポリシーとの差分を定期的に確認する運用が向いています。
既存ポリシーの表示・編集でできること
既存の SharePoint バックアップポリシーは、Microsoft 365 Backup 画面の Backup policies タブから確認できます。SharePoint Service でフィルターすれば、組織内に作成済みの SharePoint バックアップポリシーを一覧表示できます。編集したいポリシーを選び、View details から Policy details の Scope を編集する流れです。(Microsoft Learn)
編集でできる主な操作は、既存ポリシーへのサイト追加と、保護対象からのサイト削除です。追加する場合は Included sites から Add sites を選び、作成時と同じようにサイトを選択します。削除する場合は Included sites で対象サイトを選び Remove を実行します。削除されたサイトは Backup policies タブ配下の Removed Items に移動します。(Microsoft Learn)
ここで最も誤解されやすいのは、ポリシーから削除しても既存バックアップがすぐ消えるわけではない点です。SharePoint サイトをバックアップポリシーから外すと、そのサイトの将来のバックアップは取得されません。しかし、既存バックアップは削除されず、課金対象として残ります。(Microsoft Learn)
削除、停止、オフボーディングの違い
SharePoint のバックアップ運用では、「ポリシーから外す」「バックアップを削除する」「Microsoft 365 Backup の利用をやめる」を分けて考える必要があります。
| 操作 | 何が起きるか | 注意点 |
|---|---|---|
| ポリシーからサイトを削除 | そのサイトの新しいバックアップ取得が止まる | 既存バックアップは残り、課金も継続する |
| 保護単位をオフボーディング | 特定サイト、ユーザー、メールボックスのバックアップ削除へ進む | 事前にポリシーから外し、未保護状態にする必要がある |
| Microsoft 365 Backup 自体をオフボーディング | アクティブなポリシーの停止・削除とバックアップデータ削除を伴う | 課金状態の異常でもオフボーディングが開始される場合がある |
特定の SharePoint サイトのバックアップを削除したい場合は、まず対象の保護単位をポリシーから外し、その後 PowerShell コマンドレットでオフボーディングを進める流れになります。Microsoft のオフボーディング情報では、オフボーディング開始後でも90日間の猶予期間内であればキャンセルできる操作が示されています。(Microsoft Learn)
料金への影響は事前に見積もる
Microsoft 365 Backup は従量課金型のサービスです。公式の価格モデルでは、Microsoft 365 管理センターから提供される Microsoft 365 Backup のリスト価格は、保護対象コンテンツ1GBあたり月額0.15米ドルとされています。ただし、実際の請求額は契約、リージョン、為替、課金条件などによって変わる可能性があるため、最終的には自社テナントの課金情報で確認してください。(Microsoft Learn)
課金対象には、現在見えている SharePoint サイトや OneDrive アカウントのサイズだけでなく、第2段階のごみ箱にある削除済みコンテンツ、Exchange の削除・バージョン管理されたアイテムなども含まれます。つまり、SharePoint 上でファイルを削除して見た目の容量が減っても、バックアップが保持している削除済みデータが残っていれば、すぐに費用が下がるとは限りません。(Microsoft Learn)
特に Full workload backup のように「ワークロード全体を保護する」方向へ運用を広げる場合は、バックアップ対象が一気に増えます。全社保護は漏れを減らす有効な設計ですが、対象サイト数、容量、第2段階のごみ箱、削除済みデータの量を確認せずに有効化すると、想定以上の費用になる可能性があります。
復元ポイントと RPO の考え方
Microsoft 365 Backup の価値は、バックアップ対象を登録することではなく、必要な時点へ復元できることにあります。SharePoint のフルサイト復元では、直近0〜14日については10分の RPO、15〜365日前については1週間の RPO が示されています。SharePoint と OneDrive のファイル・フォルダー単位の復元では、直近期間はおおむね日次、それ以降は週次の復元ポイントになります。(Microsoft Learn)
ただし、「10分 RPO」は10分ごとに単純なスナップショットが作られるという意味ではありません。管理者は、ランサムウェア被害や誤削除の発生時に、どの時点へ戻すべきかを判断できるよう、復元手順と意思決定フローを事前に決めておく必要があります。
SharePoint の実務では、以下のような復元シナリオを事前に整理しておくと対応が速くなります。
- ランサムウェアで多数のファイルが暗号化された場合は、被害発生直前のサイト全体復元を検討する
- 特定フォルダーの誤削除であれば、ファイル・フォルダー単位の復元を優先する
- 権限変更を含めて戻したい場合は、復元先や上書きの影響を事前に確認する
- 重要サイトは、バックアップ設定後に復元テストを実施しておく
Multi-Geo 環境では追加方法に注意
グローバル企業や多拠点テナントでは、Multi-Geo 環境での制約も重要です。Microsoft 365 Backup は、Multi-Geo が有効なテナントにおいて、中央ロケーションとサテライトロケーションのサイトやユーザーアカウントをバックアップ対象にできます。ただし、CSV ファイルでの追加は各 Geo のサイトやアカウントを扱える一方、サイトピッカー、検索、フィルタールールによる追加は、現時点ではテナントの中央ロケーションのみをサポートする扱いです。バックアップ内のデータは、定義された Geo のデータ所在地要件に従います。(Microsoft Learn)
このため、海外拠点や複数リージョンに SharePoint サイトがある組織では、個別選択だけに頼るとサテライト側のサイトを拾い漏らす可能性があります。Multi-Geo 環境では、CSV ベースで対象一覧を作り、各 Geo の SharePoint サイトがバックアップ対象に含まれているかを定期的に確認する運用が現実的です。
管理者ロールと通知設定も見直す
Microsoft 365 Backup をセットアップするには、Microsoft 365 管理センターへアクセスできる適切な管理者権限が必要です。公式情報では、SharePoint 管理者またはグローバル管理者がセットアップに必要とされ、管理には Global Administrator、SharePoint Administrator、Exchange Administrator、Microsoft 365 Backup Administrator などのロールが関係します。Microsoft は最小権限のロール利用を推奨しており、グローバル管理者は緊急時などに限定すべき高権限ロールとされています。(Microsoft Learn)
また、Microsoft 365 Backup ではメール通知を有効化できます。通知対象には、Microsoft 365 Backup の無効化、課金停止、保護単位の削除、ポリシー停止、通知リスト変更など、見逃すと影響が大きいイベントが含まれます。通知先には最大20件の個別受信者を追加でき、配布リストやメール有効なセキュリティグループも利用できます。(Microsoft Learn)
バックアップは「設定した人だけが知っている」状態にすると危険です。SharePoint 管理者、セキュリティ担当、IT 運用担当、監査・コンプライアンス担当が最低限の通知を受け取れるようにしておくと、誤操作や不正な変更に気付きやすくなります。
請求設定の移行で確認すべきこと
Microsoft 365 Backup の利用には、Pay-as-you-go の請求設定が関係します。新規顧客は Microsoft 管理センターの Billing ノード配下にある新しい Pay-as-you-go セットアップ体験を使う形になっています。一方、既存の Microsoft 365 Backup 顧客については、従来の Setup 配下の請求管理から、新しい Billing 配下の体験へ移行する変更がロールアウト中です。Migrate オプションが表示されるテナントでは、既存の Azure サブスクリプション、リソースグループ、リージョンを使って新しい請求ポリシーへ移行できます。移行中に既存バックアップの停止はないと説明されています。(Microsoft Learn)
ここで重要なのは、移行期限を自社で勝手に決め打ちしないことです。公式 Learn のセットアップ情報では、Migrate が表示されない場合はそのテナントではまだロールアウト中と説明されています。したがって、管理者は「いつ移行するか」よりも先に、現在どの Azure サブスクリプションで課金しているか、部門別課金や複数請求ポリシーを使う必要があるかを確認するべきです。(Microsoft Learn)
Full workload backup への備え
2026年6月の Microsoft Graph 更新では、Microsoft 365 Backup and Storage のプレビューとして、SharePoint Online、OneDrive for work or school、Exchange Online のワークロード全体を保護する API サポートが追加されています。これは、保護ポリシーでワークロード内のすべてのデータをバックアップし、除外する対象だけを指定する考え方です。(Microsoft Learn)
Graph beta の exclusionUnitBase では、Full workload backup の除外単位を表すリソースが定義されており、fullServiceBackup の保護モードで作成したポリシーに対して、サイト、ドライブ、メールボックスの除外リストを管理する説明があります。ただし、Microsoft Graph の beta API は変更される可能性があり、本番アプリケーションでの利用はサポートされないと明記されています。(Microsoft Learn)
SharePoint 管理者が今から準備すべきことは、いきなり全社バックアップへ切り替えることではありません。まず、保護すべきサイトと除外すべきサイトの基準を明文化することです。たとえば、次のような分類を作っておくと、Full workload backup の導入判断がしやすくなります。
| 分類 | 例 | 推奨判断 |
|---|---|---|
| 必ず保護するサイト | 経営、法務、財務、人事、主要プロジェクト、Teams 連携の重要サイト | 既存ポリシーまたは全体保護の対象に含める |
| 条件付きで保護するサイト | 一時プロジェクト、部門検証用、短期キャンペーン | 保持期間、容量、業務影響を確認して判断する |
| 除外候補 | テストサイト、研修用サイト、重複データ置き場 | 除外理由と責任者を記録する |
| 要確認 | 所有者不明、最終更新日が古い、容量が大きいサイト | 所有者確認と整理を先に行う |
失敗しやすいポイント
SharePoint の Microsoft 365 Backup ポリシーでよくある失敗は、設定手順そのものよりも、運用設計の不足から起こります。
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
| 重要サイトだけ個別追加して終わる | 新規サイトがバックアップ対象から漏れる | 月次でサイト一覧とポリシー対象を突合する |
| ポリシーから削除すれば費用も消えると思い込む | 既存バックアップが残り、想定外の費用が続く | 削除、保護停止、オフボーディングの違いを手順書に書く |
| SharePoint のバージョン履歴だけで十分と考える | 大規模なランサムウェア復旧や一括復元に弱い | Microsoft 365 Backup の復元手順を別途整備する |
| Multi-Geo を意識せず画面検索だけで追加する | サテライト Geo のサイトを拾い漏らす | CSV ベースで全 Geo の対象を管理する |
| 通知先が管理者1人だけ | 異常や誤操作の発見が遅れる | 複数管理者・運用チーム・セキュリティ担当へ通知する |
| beta API 前提で自動化する | 仕様変更でスクリプトが動かなくなる | 本番利用は GA や v1.0 の対応状況を確認する |
Microsoft 365 Backup は、SharePoint のバージョン履歴、保持ラベル、訴訟ホールドの代替ではなく、復元を目的としたバックアップ機能として設計されています。公式 FAQ でも、バージョン履歴は大規模なランサムウェア復旧にはスケールしにくく、法的保持はエクスポート向けで大規模復元に最適化されたものではないと説明されています。(Microsoft Learn)
管理者が今すぐ確認すべきチェックリスト
SharePoint 管理者は、次の順番で確認すると実務に落とし込みやすくなります。
| 優先度 | 確認内容 | 具体的なアクション |
|---|---|---|
| 高 | SharePoint バックアップポリシーの有無 | Microsoft 365 Backup の Backup policies で SharePoint Service に絞り込む |
| 高 | 重要サイトの保護漏れ | 経営・人事・法務・財務・主要 Teams サイトを照合する |
| 高 | 課金対象容量 | SharePoint 使用量、第2段階のごみ箱、削除済みデータを見積もる |
| 高 | 通知設定 | 危険な変更イベントを複数管理者へ通知する |
| 中 | Multi-Geo 対象 | CSV で中央・サテライト Geo のサイトを含める |
| 中 | 除外基準 | テストサイトや一時サイトを除外候補として整理する |
| 中 | 復元手順 | フルサイト復元とファイル・フォルダー単位復元の判断基準を作る |
| 低 | API 自動化 | beta ではなく GA・v1.0 対応状況を確認してから本番化する |
SharePoint バックアップポリシーは「作る」より「保ち続ける」ことが重要
「Create, view, and edit backup policies in Microsoft 365 Backup」で確認すべき本質は、SharePoint のバックアップポリシーを一度作ることではありません。新しいサイトが増え、古いサイトが使われなくなり、部門やプロジェクトが変わっても、保護範囲を説明できる状態に保ち続けることです。
まずは Microsoft 365 Backup の SharePoint ポリシー一覧を開き、現在の対象サイト、削除済みサイト、通知設定、課金設定を確認してください。そのうえで、重要サイトの漏れ、不要サイトの混入、Multi-Geo の対象漏れ、復元テストの未実施を洗い出すことが、2026年7月時点で管理者が取るべき最初の行動です。
コメント