Microsoft 365 BackupのDepartment Billingとは?変更点と管理者の確認ポイント

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 PolicyMicrosoft 365管理センターのPay-as-you-go関連画面Microsoft 365 Backupに複数のBilling Policyを接続する必要があるか
管理者権限Azure RBAC、Microsoft 365管理センターの管理者ロールバックアップ管理者にOwnerを与えすぎていないか。Contributorで足りるか
既存バックアップポリシーMicrosoft 365 BackupのBackup policiesOneDrive、SharePoint、Exchange Onlineのポリシーがどの部門に属するか
費用分析Azure Cost Managementtenant、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を使う場合は、ポリシー名だけで部門と対象サービスが分かるようにしておくと、後からの運用ミスを減らせます。

例としては、次のような命名が実用的です。

対象ポリシー名の例意図
営業部のOneDriveSALES-OD-Backup部門とサービスを即判別できる
日本拠点のSharePointJP-SP-Sites-Backup地域単位の費用配賦に向く
子会社AのExchangeFIRMA-EXO-Mailbox法人単位で課金管理しやすい
研究開発部の重要サイトRND-SP-Critical優先度や対象範囲を明示できる

ただし、Microsoft Learnではポリシー名は最大20文字で一意である必要があると説明されています。長い部門名をそのまま入れるのではなく、社内で略称ルールを決めてから作成しましょう。(Microsoft Learn)

Department Billingの設定手順

実際の画面名や配置はテナントやロール、展開状況により変わる可能性がありますが、公式ドキュメントの流れを実務向けに整理すると次の手順になります。

手順作業内容実務上の注意点
1部門別のAzureサブスクリプションまたは既存サブスクリプションを確認する費用責任者と予算アラートの宛先を先に決める
2Microsoft 365 Backup用のBilling Policyを作成・接続する部門名、地域名、法人名など識別しやすい名前にする
3Pay-as-you-goページでMicrosoft 365 Backupを選択する新規顧客と既存顧客で画面導線が異なる可能性がある
4Microsoft 365 BackupのSettingsタブでDepartmental Billingを有効化する有効化後、RBACに基づく管理制限が効くため事前検証が必要
5部門管理者にAzure RBACのOwnerまたはContributorを付与する原則はContributor。Owner付与は最小限にする
6バックアップポリシー作成・編集時にBilling Policyを紐づける権限のない管理者には対象Billing Policyが見えない、または使えない
7Azure 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を有効化すると、後から権限・課金・監査の説明が難しくなります。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次