Microsoft 365 Backupの「Department Billing」は、バックアップ費用を部門・地域・子会社などの単位で分け、複数のAzureサブスクリプションへ従量課金を割り当てられるようにする機能です。結論から言うと、全社一括でMicrosoft 365 Backupを管理している企業よりも、部門ごとに予算・管理権限・責任範囲を分けたい大規模組織で影響が大きくなります。
特に確認すべきポイントは、バックアップポリシーと課金先のBilling Policyの対応関係、Azure RBACのOwner/Contributor権限、既存ポリシーをどの部門に紐づけ直すかの3点です。Microsoft 365 Roadmap ID 506744では、この機能はMicrosoft 365 BackupのDepartment Billingとして掲載され、管理者が部門・地理的拠点・加盟会社などの細かなスコープでバックアップを構成し、複数のAzureサブスクリプションにまたがる従量課金を管理できる内容として説明されています。(Microsoft)
Microsoft 365 BackupのDepartment Billingとは
Department Billing for Microsoft 365 Backupは、Microsoft 365 Backupのバックアップ運用と費用負担を、組織内の単位に合わせて分離しやすくする機能です。
従来のように「Microsoft 365 Backupの費用を1つのAzureサブスクリプションにまとめる」運用では、部門別の利用量や費用負担が見えにくくなります。Department Billingを使うと、たとえば営業部、研究開発部、海外拠点、グループ会社などの単位でBilling Policyを分け、それぞれのAzureサブスクリプションにバックアップ消費を割り当てやすくなります。
Microsoft Learnでは、Departmental Billingにより、バックアップ費用を異なるAzureサブスクリプションごとに分解でき、部門内の特定管理者にRBACでバックアップ管理を制限でき、他部門の管理者が自部門のAzureサブスクリプションを使って未承認のバックアップ課金を発生させることを防ぎやすくなると説明されています。(Microsoft Learn)
つまり、この変更の本質は「バックアップ機能そのものの復元性能が変わる」ことではなく、Microsoft 365 Backupの課金・権限・運用責任を部門単位に寄せられるようになることです。
何が変わるのか
今回の変更で重要なのは、Microsoft 365 Backupの管理単位がより細かくなる点です。Roadmapでは、部門、地理的ロケーション、member firmsなどの粒度でバックアップを構成し、複数のAzureサブスクリプションにまたがる従量課金を管理できるとされています。(Microsoft)
実務上は、次のような変化として捉えると分かりやすいです。
| 項目 | これまで起きやすかった課題 | Department Billing後の考え方 |
|---|---|---|
| 課金管理 | 全社分のMicrosoft 365 Backup費用が1つのAzureサブスクリプションに集まり、部門別の費用把握が難しい | 部門・地域・法人単位でBilling Policyを分け、Azureサブスクリプション別に費用を追いやすくする |
| 権限管理 | バックアップ管理者が広い範囲を操作でき、責任境界が曖昧になりやすい | Azure RBACのOwner/Contributor権限をもとに、部門ごとの管理者に操作範囲を絞る |
| 内部統制 | 他部門の管理者が意図せず別部門の課金先を使うリスクがある | 権限のないBilling Policyは利用できず、アクセス権のない管理者にはConfidentialとして表示される |
| コスト配賦 | 利用実態に応じた社内請求や予算管理に手作業が必要 | Azure Cost Managementのタグやメーターで費用分析しやすくする |
特に大きいのは、バックアップポリシー作成時にBilling Policyを関連付ける点です。Departmental Billingを有効にすると、バックアップ管理者は、自分がOwnerまたはContributorとしてアクセスできるBilling Policyのみを使ってバックアップポリシーを作成・編集する形になります。(Microsoft Learn)
対象となる組織と影響範囲
Department Billingの恩恵が大きいのは、Microsoft 365 Backupを「全社IT部門だけで一括管理する」組織よりも、複数部門・複数拠点・複数法人で運用責任を分けている組織です。
影響が大きいケース
次のいずれかに当てはまる場合は、設定確認を優先すべきです。
- Microsoft 365 BackupをOneDrive、SharePoint、Exchange Onlineで利用している
- Azureサブスクリプションを部門別、国・地域別、法人別に分けている
- Microsoft 365 Backupの費用を部門別に配賦したい
- バックアップポリシーの作成・変更を各部門の管理者に委任している
- グローバル管理者やSharePoint管理者に権限が集中している状態を見直したい
- 既存のバックアップポリシーが全社共通の課金先に紐づいている
Microsoft 365 Backupのセットアップには、有効なAzureサブスクリプション、リソースグループ、リージョン、AzureサブスクリプションのOwnerまたはContributorロールが必要です。新規顧客はMicrosoft 365管理センターのBillingノード配下の従量課金セットアップを利用し、既存顧客は従来のSetup配下の課金管理画面を引き続き利用する流れが案内されています。(Microsoft Learn)
影響が比較的小さいケース
一方で、次のような環境では急いで設計変更する必要性は低いかもしれません。
| 環境 | 対応方針 |
|---|---|
| Microsoft 365 Backupをまだ使っていない | 導入設計時にDepartment Billingを前提に課金単位を決める |
| 単一部門・単一Azureサブスクリプションで運用している | 既存のPay-as-you-go設定を確認し、将来の分割要否だけ検討する |
| バックアップ管理を中央IT部門だけで行っている | 権限委任の予定がなければ、無理に部門別化しない |
| GCC環境で利用している | Microsoft Learnでは、GCC向けのMultiple BillingおよびDepartmental Billingは今後提供予定で、現時点では単一Billing Policyのみ接続可能とされています。対象クラウドの提供状況を管理センターとMessage Centerで確認してください。(Microsoft Learn) |
管理者が最初に確認すべき設定
Department Billingで失敗しやすいのは、機能を有効化する前に「誰が、どの課金先で、どのデータを保護するのか」を整理しないまま展開してしまうことです。
まずは、次の順番で棚卸ししてください。
| 確認項目 | 見る場所・観点 | 判断基準 |
|---|---|---|
| Azureサブスクリプション | Azure portal、Cost Management + Billing | 部門別に分ける必要があるか。既存の予算管理単位と一致しているか |
| Billing Policy | Microsoft 365管理センターのPay-as-you-go関連画面 | Microsoft 365 Backupに複数のBilling Policyを接続する必要があるか |
| 管理者権限 | Azure RBAC、Microsoft 365管理センターの管理者ロール | バックアップ管理者にOwnerを与えすぎていないか。Contributorで足りるか |
| 既存バックアップポリシー | Microsoft 365 BackupのBackup policies | OneDrive、SharePoint、Exchange Onlineのポリシーがどの部門に属するか |
| 費用分析 | Azure Cost Management | tenant、servicetype、protectionunitidなどのタグで費用を追えるか |
| 通知設定 | Microsoft 365 BackupのEmail notifications | 危険な変更を複数管理者で検知できるか |
Microsoft Learnでは、Departmental Billingを有効化するには、Billing Policyを作成してMicrosoft 365 Backupに接続し、Pay-as-you-goページのServicesタブでMicrosoft 365 Backupを選択したうえで、Settingsタブから部門内のBackup管理制限を有効にする流れが示されています。(Microsoft Learn)
展開前に決めておくべき設計方針
Department Billingは、単なるチェックボックスのオン・オフではなく、社内の運用設計に関わります。特に次の3つは先に決めておくべきです。
課金単位は「組織図」ではなく「費用責任」で決める
部門別課金という名前から、組織図どおりに分けたくなりますが、実務では費用責任の単位で分けるほうが運用しやすくなります。
たとえば、営業1部・営業2部・営業企画部が同じ予算管理下にあるなら、無理に3つのBilling Policyに分ける必要はありません。逆に、同じIT部門配下でも、日本法人と海外法人で請求先や予算承認者が異なるなら、Billing Policyを分ける価値があります。
判断基準はシンプルです。
- 月次で誰が費用を確認するのか
- 予算超過時に誰が承認・停止判断をするのか
- バックアップ対象の追加依頼を誰が承認するのか
- 監査時にどの単位で説明責任を持つのか
この4点が異なるなら、課金単位を分ける候補になります。
管理者権限はOwnerではなくContributorを基本にする
Microsoft Learnでは、部門サブスクリプションのOwnerである場合、バックアップ管理者が他の管理者追加権限を必要としないなら、より低い権限であるContributorロールを付与することが推奨されています。(Microsoft Learn)
実務では、次のように分けると安全です。
| 役割 | 推奨権限の考え方 | 理由 |
|---|---|---|
| 全社クラウド管理者 | 必要に応じてOwner | サブスクリプション設計、権限設計、監査対応を担うため |
| 部門バックアップ管理者 | 原則Contributor | バックアップポリシーの作成・編集はできるが、不要な権限委任を避けやすい |
| 費用確認だけの担当者 | Cost Management Readerなど読み取り系ロールを検討 | ポリシー変更権限を与えず、費用確認に限定するため |
| 一時対応者 | 期限付き・申請ベース | 退職、異動、兼務終了後の権限残存を防ぐため |
Azure RBACは、誰がどのAzureリソースにアクセスでき、何を実行できるかを管理する仕組みです。ロール割り当ては、セキュリティプリンシパル、ロール定義、スコープの3要素で構成されるため、Department Billingでも「誰に」「どのロールを」「どのサブスクリプションまたはリソース範囲で」付与するかを明確にする必要があります。(Microsoft Learn)
バックアップポリシー名に部門と課金先を入れる
Microsoft 365 Backupでは、SharePoint、Exchange、OneDriveごとにバックアップポリシーを作成します。公式ドキュメントでは、各製品ごとに複数のバックアップポリシーを作成でき、製品ごとに最大100ポリシーまで、部門や地域などの論理区分でデータを分けられると説明されています。(Microsoft Learn)
Department Billingを使う場合は、ポリシー名だけで部門と対象サービスが分かるようにしておくと、後からの運用ミスを減らせます。
例としては、次のような命名が実用的です。
| 対象 | ポリシー名の例 | 意図 |
|---|---|---|
| 営業部のOneDrive | SALES-OD-Backup | 部門とサービスを即判別できる |
| 日本拠点のSharePoint | JP-SP-Sites-Backup | 地域単位の費用配賦に向く |
| 子会社AのExchange | FIRMA-EXO-Mailbox | 法人単位で課金管理しやすい |
| 研究開発部の重要サイト | RND-SP-Critical | 優先度や対象範囲を明示できる |
ただし、Microsoft Learnではポリシー名は最大20文字で一意である必要があると説明されています。長い部門名をそのまま入れるのではなく、社内で略称ルールを決めてから作成しましょう。(Microsoft Learn)
Department Billingの設定手順
実際の画面名や配置はテナントやロール、展開状況により変わる可能性がありますが、公式ドキュメントの流れを実務向けに整理すると次の手順になります。
| 手順 | 作業内容 | 実務上の注意点 |
|---|---|---|
| 1 | 部門別のAzureサブスクリプションまたは既存サブスクリプションを確認する | 費用責任者と予算アラートの宛先を先に決める |
| 2 | Microsoft 365 Backup用のBilling Policyを作成・接続する | 部門名、地域名、法人名など識別しやすい名前にする |
| 3 | Pay-as-you-goページでMicrosoft 365 Backupを選択する | 新規顧客と既存顧客で画面導線が異なる可能性がある |
| 4 | Microsoft 365 BackupのSettingsタブでDepartmental Billingを有効化する | 有効化後、RBACに基づく管理制限が効くため事前検証が必要 |
| 5 | 部門管理者にAzure RBACのOwnerまたはContributorを付与する | 原則はContributor。Owner付与は最小限にする |
| 6 | バックアップポリシー作成・編集時にBilling Policyを紐づける | 権限のない管理者には対象Billing Policyが見えない、または使えない |
| 7 | Azure Cost Managementで費用を確認する | tenant、servicetype、protectionunitidなどのタグで分析する |
| 8 | 予算アラートと通知設定を有効化する | 課金増加や危険な設定変更に気づける体制にする |
Departmental Billingを無効化したい場合は、Microsoft 365 BackupページのSettingsタブで、サブスクリプションのOwnerまたはContributorにバックアップ管理を制限するチェックを外す流れが案内されています。(Microsoft Learn)
既存環境での移行・見直しポイント
すでにMicrosoft 365 Backupを利用している場合、いきなりDepartment Billingを有効化するより、既存のバックアップポリシーを棚卸ししてから段階的に移行するほうが安全です。
既存バックアップポリシーを部門単位で分類する
まず、既存のOneDrive、SharePoint、Exchange Onlineのバックアップポリシーを一覧化します。確認すべき項目は次のとおりです。
| 確認項目 | 例 | 見直しポイント |
|---|---|---|
| 対象サービス | OneDrive、SharePoint、Exchange | サービス別に責任者が異なるか |
| 対象範囲 | 全社員、特定部門、特定サイト | 部門別Billing Policyに分ける必要があるか |
| 現在の課金先 | 全社共通Azureサブスクリプション | 部門別サブスクリプションへ変更するか |
| 管理者 | 中央IT、部門IT、外部委託先 | Azure RBACとMicrosoft 365管理者ロールが過剰でないか |
| 変更頻度 | 毎月変更、年数回、固定 | 動的ルールを使うか、CSV運用にするか |
バックアップポリシーのスコープからアカウント、サイト、メールボックスを削除しても、既存バックアップが直ちに削除されるわけではなく、将来のバックアップが停止する扱いになります。公式ドキュメントでは、削除済み対象の既存バックアップは保持され、課金対象になる旨が説明されています。移行時に「ポリシーから外したから費用もすぐゼロになる」と誤解しないよう注意が必要です。(Microsoft Learn)
Billing Policyの変更はバックアップDashboardから行う
Departmental Billingでは、バックアップポリシーに紐づくBilling Policyを後から変更できます。Microsoft Learnでは、Backup Dashboardで対象のバックアップポリシーを選び、ポリシー名横の3点メニューから「Update Billing policy」を選択する流れが示されています。(Microsoft Learn)
変更時は、次の確認をセットで行いましょう。
- 変更先Billing Policyに部門管理者がOwnerまたはContributorでアクセスできるか
- 変更後の費用がどのAzureサブスクリプションに計上されるか
- 月途中の変更を社内配賦でどう扱うか
- 変更前後の証跡をチケットや変更管理台帳に残したか
- 予算アラートのしきい値が新しい課金先に設定されているか
特に月次決算や部門別請求を行う企業では、月末直前にBilling Policyを変更すると、費用配賦の説明が複雑になります。可能であれば、月初や会計処理の切れ目に合わせて変更するのが安全です。
開発者・自動化担当者が確認すべき点
Department Billingは管理センター上の設定だけでなく、PowerShellやGraph APIを使った運用自動化にも影響します。
Microsoft 365 Backupのバックアップポリシー操作は、Microsoft Graph Backup Restore関連のAPIやPowerShell例から実行できることが案内されています。公式ドキュメントでは、Graph APIドキュメントのExample requestからPowerShellタブを選び、Microsoft.Graph.BackupRestoreモジュールを使う流れが紹介されています。(Microsoft Learn)
自動化している環境では、次の点を確認してください。
| 確認項目 | なぜ重要か |
|---|---|
| 実行アカウントのAzure RBAC | スクリプト実行者が対象Billing Policyにアクセスできなければ、ポリシー作成・変更に失敗する可能性がある |
| Billing Policy指定の有無 | 既存スクリプトが課金先を前提にしていない場合、Department Billing環境で改修が必要になる可能性がある |
| エラーハンドリング | 権限不足、Confidential表示、ポリシー未選択などを検知できるようにする |
| 部門別ログ出力 | どの部門のポリシーを誰が変更したかを後から追えるようにする |
| テストテナントでの検証 | 本番の課金先を誤って使わないよう、検証用のBilling Policyで動作確認する |
開発者目線では、「APIが動くか」だけでなく「意図したAzureサブスクリプションに課金されるか」まで確認する必要があります。バックアップ対象の追加は、機能面では成功しても、費用面では別部門に計上される可能性があるためです。
費用確認はAzure Cost Managementで行う
Department Billingを導入した後は、Microsoft 365管理センターだけでなく、Azure Cost Managementでの確認が重要になります。
Microsoft Learnでは、Microsoft 365 BackupのOneDrive、SharePoint、Exchangeについて、Azure portalのMicrosoft Cost ManagementまたはCost Management public APIsから、テナントやサービス種別ごとの実コスト、累積コストを確認できると説明されています。(Microsoft Learn)
実務では、最低限次のビューを作っておくと運用しやすくなります。
| ビュー | 目的 | フィルター例 |
|---|---|---|
| 部門別月次コスト | 社内配賦・予算管理 | Azureサブスクリプション、タグ |
| サービス別コスト | どのサービスのバックアップ費用が大きいか把握 | servicetype:OneDrive、SharePoint、Exchange |
| 急増検知 | バックアップ対象の追加ミスを発見 | 前月比、予算アラート |
| 保護単位別確認 | 特定サイトやOneDriveに費用が偏っていないか確認 | protectionunitid |
Microsoft Learnでは、Microsoft 365 Backup向けのタグとして、tenants、servicetype、protectionunitidなどが示されています。また、OneDriveのタグはsite IDであり、ユーザーIDに戻すにはMicrosoft Graph APIでサイトのdrive ownerを取得する方法が紹介されています。(Microsoft Learn)
注意点として、Azure消費レポートのMailboxDbGuidタグはMicrosoft内部利用を目的としたもので、値が変わる可能性があるため依存しないことが推奨されています。(Microsoft Learn)
バックアップ対象ごとの注意点
Department Billingは課金・権限の機能ですが、実際の運用ではバックアップ対象の追加方法にも注意が必要です。
SharePointの注意点
SharePointでは、CSVアップロード、特定条件に一致するサイトの追加、個別選択などでバックアップ対象を追加できます。公式ドキュメントでは、CSVによる一括追加は1ファイルあたり最大50,000件、サイト名やURLを使ったルールベース追加では一度に最大10件のキーワードを指定できると説明されています。(Microsoft Learn)
ただし、古いSharePointサイトテンプレートの一部はMicrosoft 365 Backupでサポートされない場合があります。移行前に、重要サイトが対象外になっていないか確認しましょう。
Exchange Onlineの注意点
Exchangeでは、ユーザーメールボックスと共有メールボックスを対象にできますが、会議室メールボックスやグループメールボックスなど、すべての受信者タイプが対象になるわけではありません。また、ハイブリッド構成はサポートされず、Exchange Onlineに完全にホストされているメールボックスのみ保護対象とされています。(Microsoft Learn)
オンプレミスから移行したばかりのメールボックスや、ライセンス付与直後のメールボックスは、一時的に追加に失敗する可能性があります。移行プロジェクト中は、Microsoft 365 Backupの対象追加をメールボックス移行完了後のチェックリストに入れておくと安全です。
OneDriveの注意点
OneDriveでは、CSV、動的ルール、フィルター、個別選択などで対象ユーザーを追加できます。動的ルールでは配布リストやセキュリティグループのメンバー変更が毎日再評価され、ユーザー追加・削除がバックアップポリシーに反映される仕組みです。ただし、公式ドキュメントでは動的ルールはPreviewとされています。(Microsoft Learn)
人事異動や入退社が多い組織では動的ルールが便利ですが、プレビュー機能を本番運用の中核に置く場合は、仕様変更に備えて定期的な対象者確認を行いましょう。
よくある失敗と回避策
Department Billingは便利ですが、設計を誤ると「権限はあるのにポリシーが作れない」「費用が想定外の部門に付いた」といったトラブルにつながります。
| 失敗しやすいポイント | 起きること | 回避策 |
|---|---|---|
| Azure RBACを付け忘れる | 部門管理者がBilling Policyを使えない | Microsoft 365管理者ロールとAzure RBACを別物として確認する |
| Ownerを広く付与する | 管理者追加や課金先変更の権限が過剰になる | 原則Contributor。Ownerは全社クラウド管理者などに限定する |
| 既存ポリシーを分類せず有効化する | どの部門の費用か分からなくなる | 有効化前に既存バックアップポリシーと課金先を棚卸しする |
| ポリシー名が曖昧 | 後から運用者が対象範囲を判断できない | 部門略称、サービス名、用途を20文字以内で表す |
| ポリシーから外せば課金も即止まると誤解する | 既存バックアップ分の費用が残る | 「将来のバックアップ停止」と「既存バックアップ保持」を分けて説明する |
| Cost Managementを見ていない | バックアップ対象の増加に気づけない | 予算アラートとサービス別ビューを事前に作る |
| 月末に課金先を変更する | 社内配賦の説明が難しくなる | 会計期間の切れ目で変更する |
特に見落としやすいのは、Microsoft 365の管理者ロールとAzure RBACの両方が関係する点です。Microsoft 365 Backupを操作できる管理者であっても、対象Billing Policyに対するOwnerまたはContributor権限がなければ、部門の課金先を使ったバックアップ管理はできません。
導入判断の目安
Department Billingを有効化すべきか迷う場合は、次の基準で判断してください。
| 判断軸 | 有効化を検討すべき状態 | まだ急がなくてもよい状態 |
|---|---|---|
| 組織規模 | 複数部門・複数法人・複数地域で費用責任が分かれる | 単一組織で中央ITが一括管理している |
| 課金管理 | Microsoft 365 Backup費用を部門別に配賦したい | 全社共通費として処理している |
| 管理委任 | 部門ITにバックアップポリシー管理を任せたい | 操作は中央ITだけが行う |
| 統制要件 | 他部門の課金先利用を防ぎたい | 管理者数が少なく、運用統制が単純 |
| 自動化 | 部門別にポリシー作成を自動化したい | 手動運用で十分対応できている |
大規模組織では、Department Billingを単なる新機能として扱うのではなく、Microsoft 365 Backupの費用統制と権限委任を見直すタイミングとして使うのが現実的です。
管理者向けチェックリスト
展開前後で確認すべき内容を、実務用チェックリストとしてまとめます。
| タイミング | チェック項目 |
|---|---|
| 展開前 | Microsoft 365 Roadmap ID 506744とMessage Centerの対象テナント通知を確認する |
| 展開前 | Microsoft 365 Backupの既存ポリシーをOneDrive、SharePoint、Exchange別に棚卸しする |
| 展開前 | 部門・地域・法人ごとの費用責任者を決める |
| 展開前 | AzureサブスクリプションとBilling Policyの対応表を作る |
| 展開前 | 部門バックアップ管理者に必要なAzure RBACを付与する |
| 展開前 | Owner権限をContributorに下げられる管理者がいないか確認する |
| 展開時 | Departmental Billingを有効化し、部門管理者でポリシー作成・編集をテストする |
| 展開時 | 権限のないBilling Policyが利用できないことを確認する |
| 展開後 | Azure Cost Managementで部門別・サービス別の費用を確認する |
| 展開後 | 予算アラート、通知リスト、変更管理の運用を確認する |
| 展開後 | 月次でバックアップ対象の増減と費用増減をレビューする |
最初にやるべきこと
Microsoft 365 BackupのDepartment Billingは、バックアップ機能の追加というより、バックアップ費用と管理権限を部門単位で統制するための変更です。対象はMicrosoft 365 Backupを利用し、Azureサブスクリプションや費用責任を分けて管理している組織です。
まずは、既存のMicrosoft 365 Backupポリシー、Azureサブスクリプション、Billing Policy、部門管理者のAzure RBACを一覧化してください。そのうえで、部門別に分けるべき課金単位を決め、Contributorを基本にした最小権限で展開するのが安全です。
すでにMicrosoft 365 Backupを使っている場合は、すぐに設定を変更するより、最初の一歩として「どのバックアップポリシーが、どの部門の費用として扱われるべきか」を整理することから始めましょう。ここが曖昧なままDepartment Billingを有効化すると、後から権限・課金・監査の説明が難しくなります。

コメント