Power Platform の「Back up and restore environments」は、Dataverse を含む環境のバックアップ保持期間、手動バックアップ、復元先の制限、監査ログの扱いを確認するための管理者向け公式情報です。2026年6月24日更新版で特に押さえるべき結論は、標準の保持期間は多くの環境で7日、Production の Managed Environment では最大28日まで延長可能、復元は原則として Production に直接戻せない、という点です。環境の復元は業務停止やデータ上書きにつながるため、Power Platform 管理者は「どの環境が対象か」「どこに復元できるか」「復元後にフローや接続参照をどう戻すか」まで事前に確認しておく必要があります。 (Microsoft Learn)
Power Platform のバックアップと復元で何が変わるのか
Power Platform のバックアップと復元は、Power Apps、Power Automate、Dataverse を利用する組織にとって、障害対応や誤操作からの復旧に直結する重要な管理機能です。
今回確認すべきポイントは、単に「バックアップがあるから安心」という話ではありません。管理者が実務で判断すべき点は、次の4つです。
- どの環境タイプがバックアップ対象になるか
- バックアップを何日保持できるか
- Production 環境へどのように復元するか
- 復元後にアプリ、フロー、接続、監査ログへどのような影響が出るか
公式情報では、Dataverse データベースを持つ環境はシステムバックアップの対象になり、Trial 系の環境はシステムバックアップと復元の対象外とされています。管理者はまず、自社の重要アプリが Production、Sandbox、Developer、Teams、Default、Trial のどれに該当するかを棚卸しする必要があります。 (Microsoft Learn)
2026年6月24日更新版で押さえるべき要点
Microsoft Learn の「Back up and restore environments」は、Power Platform と Dataverse のデータを保護するため、システムバックアップと手動バックアップの考え方を整理しています。公式ページの最終更新日は 2026年6月24日です。 (Microsoft Learn)
実務上の確認ポイントをまとめると、次のようになります。
| 確認項目 | 管理者が見るべきポイント |
|---|---|
| バックアップ対象 | Dataverse データベースを持つ環境かどうか |
| 標準保持期間 | 多くの環境ではシステムバックアップ、手動バックアップともに7日 |
| 延長できる環境 | Production の Managed Environment |
| 最大保持期間 | 7日、14日、21日、28日のいずれか |
| 設定方法 | Power Platform admin center または PowerShell |
| 復元先 | 原則として Sandbox、Developer、Teams など。Production へ直接復元は不可 |
| 容量要件 | 復元には少なくとも1GBの空き容量が必要 |
| 注意点 | 復元後、フロー、接続参照、カスタムコネクタ、共有設定の確認が必要 |
特に重要なのは、バックアップ保持期間の延長がすべての環境で使えるわけではないことです。Production の Managed Environment では最大28日まで延長できますが、その他の非本番環境では既定の7日が基本になります。 (Microsoft Learn)
バックアップ保持期間の考え方
Power Platform では、環境タイプによってバックアップの扱いが異なります。管理者は「本番環境かどうか」だけでなく、「Managed Environment かどうか」「Default 環境かどうか」「Trial 環境ではないか」を確認する必要があります。
| 環境タイプ | システムバックアップ | 手動バックアップ | 実務上の注意点 |
|---|---|---|---|
| Production | 7日 | 7日 | Managed Environment なら最大28日まで延長可能 |
| Sandbox | 7日 | 7日 | 検証・復元先として使うことが多い |
| Developer | 7日 | 7日 | Default 環境の復元先になる場合がある |
| Teams | 7日 | 7日 | Teams 環境は自己復元の制限を確認 |
| Default | 7日 | 非対応 | Default 環境へ直接復元できない点に注意 |
| Trial | 非対応 | 非対応 | 重要用途では Production への変換を検討 |
| Trial サブスクリプションベース | 非対応 | 非対応 | システムバックアップと復元の対象外 |
Default 環境は、多くのユーザーが最初にアプリやフローを作りやすい環境です。しかし、手動バックアップはサポートされず、システムバックアップも Default 環境の上へ直接復元するのではなく、Developer 環境へ復元する形になります。業務アプリを Default 環境に置き続けている場合は、Production または専用環境への移行を検討した方が安全です。 (Microsoft Learn)
Production の Managed Environment は最大28日保持できる
2026年6月24日更新版で、管理者が特に確認すべきなのがバックアップ保持期間の延長です。Production 環境の既定保持期間は7日ですが、Production の Managed Environment では、7日、14日、21日、28日のいずれかに変更できます。変更は Power Platform admin center または PowerShell から実施できます。 (Microsoft Learn)
この設定を行えるのは、Microsoft Entra ID 上で Power Platform 管理者、グローバル管理者、Dynamics 365 管理者などのテナントレベル管理者ロールを持つユーザーです。なお、環境グループレベルでバックアップ保持ルールが設定されている場合、個別環境側では上書きできない点に注意が必要です。 (Microsoft Learn)
保持期間を延長すべきケース
すべての環境で28日にすればよい、というわけではありません。保持期間の延長は、復旧要件と運用負荷を見て判断します。
| ケース | 推奨判断 |
|---|---|
| 基幹業務で Dataverse を利用している | 14日以上を検討 |
| 月次処理や承認ワークフローがある | 誤更新に気づくまで時間がかかるため21日または28日を検討 |
| 大規模カスタマイズを頻繁に行う | 変更前後の復元ポイント確保のため延長を検討 |
| 検証用の Sandbox 環境 | 基本は7日運用でよい |
| Trial 環境で重要データを扱っている | 保持期間延長ではなく、環境タイプの見直しが必要 |
重要なのは、バックアップ保持期間を「IT部門の都合」だけで決めないことです。現場が誤削除や設定ミスに気づくまでの日数、月次締め処理、監査対応、カスタマイズ頻度を基準に決めると、実態に合った運用になります。
バックアップ保持期間の設定手順
Power Platform admin center で保持期間を変更する場合は、対象が Production の Managed Environment であることを確認したうえで操作します。公式手順では、Power Platform admin center にサインインし、Manage から Environments を開き、対象の Production Managed Environment を選択して Edit を実行します。その後、Backup retention で 7日、14日、21日、28日から選択して保存します。 (Microsoft Learn)
PowerShell で設定する場合は、Power Platform Administrators 向けの PowerShell モジュールを利用し、Set-AdminPowerAppEnvironmentBackupRetentionPeriod を使用します。環境 ID を EnvironmentName に指定し、NewBackupRetentionPeriodInDays に 7、14、21、28 のいずれかを指定します。確認には Get-AdminPowerAppEnvironment を使用します。 (Microsoft Learn)
Set-AdminPowerAppEnvironmentBackupRetentionPeriod `
-EnvironmentName "環境ID" `
-NewBackupRetentionPeriodInDays 28
Get-AdminPowerAppEnvironment -EnvironmentName "環境ID"設定変更時の注意点として、保持期間の変更は将来のバックアップだけでなく、保持期間内にある既存バックアップにも適用されます。ただし、変更が反映されるまで最大24時間かかる場合があり、古いバックアップが想定より早く削除される可能性もあります。変更前には、復元可能なバックアップの日時を確認してから実施するのが安全です。 (Microsoft Learn)
システムバックアップと手動バックアップの違い
Power Platform には、大きく分けてシステムバックアップと手動バックアップがあります。
| 種類 | 作成方法 | 主な用途 | 注意点 |
|---|---|---|---|
| システムバックアップ | システムが自動作成 | 障害復旧、誤更新からの復元 | Trial 環境は対象外 |
| 手動バックアップ | 管理者が任意に作成 | 大規模変更前、バージョン更新前、カスタマイズ前 | Default 環境では作成不可 |
システムバックアップは、Dataverse データベースを持つ環境に対して継続的に作成されます。Microsoft Learn では、基盤技術として Azure SQL Database の自動バックアップ機能が使われていると説明されています。 (Microsoft Learn)
一方、手動バックアップは「この時点を復元ポイントとして分かりやすく残す」ために使うものです。公式 FAQ では、現在の手動バックアップは従来のようにフルバックアップを別途取得する動作ではなく、復元に使うタイムスタンプとラベルを保持する仕組みと説明されています。大規模なカスタマイズやバージョン更新の前には、作業名が分かるラベルで手動バックアップを作成しておくと、復旧時の判断が速くなります。 (Microsoft Learn)
手動バックアップを作成すべきタイミング
手動バックアップは、日常的に何となく作るものではなく、「戻す可能性がある変更」の直前に作ると効果的です。
代表的なタイミングは次のとおりです。
| タイミング | バックアップ名の例 | 理由 |
|---|---|---|
| ソリューションの本番反映前 | before-solution-import-202607 | インポート失敗や依存関係エラーに備える |
| 大規模なテーブル変更前 | before-dataverse-schema-change | 列削除やリレーション変更の影響を戻せるようにする |
| Power Automate フローの大幅改修前 | before-flow-redesign | トリガーや接続変更による停止に備える |
| Dynamics 365 アプリ更新前 | before-d365-update | 業務アプリの更新影響を切り分ける |
| 権限ロールの再設計前 | before-security-role-change | アクセス不可や過剰権限の発生に備える |
手動バックアップは、Production、Sandbox、Teams、Developer 環境で作成できますが、Default 環境では作成できません。また、手動バックアップの作成後、復元可能になるまで最大10分程度かかる場合があり、復元を試す前に10〜15分待つことが推奨されています。 (Microsoft Learn)
復元先の制限を理解する
Power Platform の復元で最も誤解されやすいのが、「Production 環境へ直接戻せるのか」という点です。公式情報では、Production 環境へ直接復元することはできません。Production に戻したい場合は、いったん環境タイプを Sandbox に変更し、復元を実施した後、Production に戻す必要があります。 (Microsoft Learn)
復元先の主な組み合わせは次のとおりです。
| 復元元 | 復元先 |
|---|---|
| Production | Sandbox |
| Sandbox | Sandbox |
| Developer | Sandbox または Developer |
| Teams | Teams。ただし自己復元 |
| Default | Developer |
復元元と復元先は同じリージョンである必要があります。また、Managed Environment は Managed Environment へ、非 Managed Environment は非 Managed Environment へ、という整合性も重要です。顧客管理キー、エンタープライズポリシー、Virtual Network 関連のポリシーが関係する環境では、復元先にも同じ条件が求められます。 (Microsoft Learn)
Production 復元で失敗しやすいポイント
Production へ戻す作業は、単なるボタン操作ではありません。特に次の点で失敗が起きやすくなります。
| 失敗しやすいポイント | 起きる問題 | 事前対策 |
|---|---|---|
| Production に直接復元しようとする | 復元先に表示されない | Sandbox への復元手順を事前に確認 |
| リージョン違いの環境を選ぶ | 復元先に指定できない | 環境一覧でリージョンを確認 |
| Managed Environment の条件不一致 | 復元先に表示されない | 復元元・復元先の管理状態を合わせる |
| 容量不足 | 復元操作がブロックされる | Dataverse 容量を事前確認 |
| 顧客管理キーやポリシー不一致 | 復元できない | 暗号化キー、エンタープライズポリシーを確認 |
| 復元後のフロー確認漏れ | 業務処理が止まる | フロー、接続参照、カスタムコネクタを点検 |
復元には少なくとも1GBの空き容量が必要です。バックアップ自体はストレージ容量にカウントされませんが、復元操作では容量要件に引っかかることがあります。環境の容量が上限を超えている場合、復元、新規環境作成、環境コピーなどの管理操作がブロックされる可能性があります。 (Microsoft Learn)
監査ログを復元するかどうかの判断
手動バックアップから復元する際、監査ログを含めるかどうかを選択できます。公式情報では、監査ログを含めると復元にかかる時間が大きく増える可能性があるため、既定では除外されると説明されています。 (Microsoft Learn)
監査ログを含めるべきかは、次の基準で判断すると実務的です。
| 判断基準 | 監査ログを含めるべきか |
|---|---|
| 内部監査や法務確認が必要 | 含めることを検討 |
| 操作履歴の証跡が重要 | 含めることを検討 |
| 復旧速度を最優先したい | 除外を検討 |
| 検証環境への一時復元 | 除外で十分な場合が多い |
| データ量が大きい | 復元時間への影響を事前に見積もる |
ただし、監査ログの扱いは業種や社内規程に左右されます。金融、医療、公共、上場企業の内部統制対象システムなどでは、IT部門だけで判断せず、監査・法務・情報セキュリティ部門と復元方針を合わせておくべきです。
復元後に必ず確認すべき Power Apps と Power Automate
バックアップと復元は、Dataverse データを戻すだけで終わりではありません。復元後には Power Apps、Power Automate、接続参照、カスタムコネクタの動作確認が必要です。
公式 FAQ では、復元後のフローについて、ターゲット環境の既存のソリューションフローは削除され、既存の非ソリューションフローは残ると説明されています。また、ソリューションフローはオフになるため、必要に応じて有効化する必要があります。接続参照では新しい接続の作成と設定が必要で、カスタムコネクタも確認し、必要に応じて削除・再インストールします。 (Microsoft Learn)
復元後のチェックリストは、次のように用意しておくと実務で使いやすくなります。
| 確認対象 | 確認内容 |
|---|---|
| モデル駆動型アプリ | サイトマップ、フォーム、ビュー、権限ロール |
| キャンバスアプリ | アプリ ID、共有設定、データ接続 |
| Power Automate | フローがオンになっているか、トリガーが正しいか |
| 接続参照 | 新しい接続が設定されているか |
| カスタムコネクタ | 認証設定、エンドポイント、再インストール要否 |
| セキュリティロール | ユーザーやチームに正しく割り当てられているか |
| 共有設定 | Everyone 共有が復元後に維持されると思い込んでいないか |
| 外部連携 | Webhook、API、Azure Functions、外部SaaS連携 |
特にキャンバスアプリでは、復元後にアプリ ID が元のバックアップ時点と同じにならない点に注意が必要です。また、Everyone に共有されていたアプリは、復元後に Everyone 共有が維持されません。共有先をセキュリティグループにしておくと、復元後の再共有作業を整理しやすくなります。 (Microsoft Learn)
Default 環境を業務利用している場合の注意点
Power Platform では、Default 環境にユーザーがアプリやフローを作成しているケースが少なくありません。しかし、Default 環境はバックアップと復元の運用面で制限があるため、重要な業務システムを置く場所としては慎重に扱う必要があります。
Default 環境では手動バックアップを作成できません。さらに、Default 環境のシステムバックアップを Default 環境に直接復元するのではなく、Developer 環境へ復元する扱いになります。 (Microsoft Learn)
Default 環境を使っている組織では、次の対応を検討してください。
| 現状 | 推奨対応 |
|---|---|
| 個人作成の小規模アプリのみ | ガバナンスルールを整備し、重要度を分類 |
| 部門業務で使うアプリがある | 専用の Production 環境へ移行を検討 |
| Dataverse テーブルを業務利用している | バックアップ・復元要件を確認 |
| 多数のフローが稼働している | 所有者、接続、依存関係を棚卸し |
| 管理者が把握していないアプリが多い | CoE Starter Kit などによる可視化を検討 |
Default 環境を完全に禁止するよりも、「試作用途は許可するが、部門業務・本番業務は専用環境へ移す」というルールにすると、現場の利便性と統制を両立しやすくなります。
移行期限はあるのか
今回の公式情報は、バックアップと復元の仕様・管理手順を説明する内容であり、特定日までに移行しなければならないという移行期限は示されていません。したがって、管理者が取るべき行動は「期限対応」ではなく、「復旧要件に合う環境設計へ見直すこと」です。 (Microsoft Learn)
ただし、次のような場合は早めに対応した方がよいでしょう。
| 状況 | 早めに対応すべき理由 |
|---|---|
| Trial 環境で業務データを扱っている | システムバックアップと復元が対象外 |
| Default 環境で本番業務を運用している | 手動バックアップ不可、復元先にも制限がある |
| Production が Managed Environment ではない | 28日保持を利用できない |
| 復元手順を一度も検証していない | 障害時に復旧時間が読めない |
| フローや接続参照の棚卸しがない | 復元後に業務処理が止まる可能性がある |
移行期限がないから後回しにするのではなく、次の四半期メンテナンスや大型リリースの前に、復元テストを実施するのが現実的です。
管理者が今すぐ確認すべきチェックリスト
Power Platform 管理者は、次の順番で確認すると抜け漏れを減らせます。
| 項目 | 確認内容 | 優先度 |
|---|---|---|
| 環境一覧 | Production、Sandbox、Default、Trial の分類を確認 | 高 |
| Dataverse 有無 | バックアップ対象になる環境か確認 | 高 |
| Managed Environment | Production が Managed Environment か確認 | 高 |
| 保持期間 | 7日で十分か、28日まで延長すべきか判断 | 高 |
| 管理者ロール | 設定変更できる管理者がいるか確認 | 中 |
| 容量 | 復元に必要な1GB以上の空きがあるか確認 | 高 |
| 復元先 | 同一リージョンの Sandbox や Developer を用意できるか確認 | 高 |
| 接続参照 | 復元後に再設定が必要な接続を把握 | 中 |
| フロー | 復元後にオンにする対象を洗い出し | 高 |
| 監査ログ | 復元時に含めるかの基準を決める | 中 |
| 手順書 | Production 復元時の Sandbox 切り替え手順を文書化 | 高 |
特に、Production 環境のバックアップ保持期間を延長したい場合は、対象環境が Managed Environment であることを確認し、環境グループのバックアップ保持ルールが個別設定を妨げていないかを確認してください。
実務で使えるバックアップ運用ルール例
Power Platform のバックアップ運用は、環境ごとにルールを分けると管理しやすくなります。
| 環境 | 運用ルール例 |
|---|---|
| Production | Managed Environment 化し、重要度に応じて14〜28日保持を設定 |
| Sandbox | リリース検証・復元テスト用として維持 |
| Developer | Default 環境の復元先や開発者検証用に利用 |
| Teams | Teams 内利用に限定し、重要データの有無を定期確認 |
| Default | 試作用途に限定し、業務利用は専用環境へ移行 |
| Trial | 本番データを置かず、必要なら Production へ変換 |
リリース前の運用としては、「手動バックアップ作成」「バックアップ名の記録」「復元先 Sandbox の確認」「容量確認」「復元後チェックリストの準備」をセットで行うと安全です。バックアップだけ作っても、復元先や復元後の作業が決まっていなければ、障害時の復旧時間は短くなりません。
よくある誤解と正しい理解
バックアップがあるので、いつでも元に戻せる？
戻せる範囲は保持期間内に限られます。多くの環境では既定で7日です。Production の Managed Environment であれば最大28日まで延長できますが、すべての環境に適用できるわけではありません。 (Microsoft Learn)
手動バックアップを作れば、バックアップファイルをダウンロードできる？
Power Platform では、データベースバックアップのコピーをダウンロードしてオフライン利用することはサポートされていません。オンライン環境からオンプレミスへデータを移す場合は、バックアップ取得ではなくデータ移行として考える必要があります。 (Microsoft Learn)
Production 環境へそのまま復元できる？
Production 環境へ直接復元することはできません。Production に戻すには、まず環境タイプを Sandbox に変更し、復元後に Production に戻します。これは誤った上書きを防ぐための制限です。 (Microsoft Learn)
手動バックアップは作成後すぐに復元できる？
手動バックアップは、作成後に復元可能になるまで最大10分程度かかる場合があります。公式情報では、復元を試みる前に10〜15分待つことが推奨されています。 (Microsoft Learn)
復元すればフローもそのまま動く？
そのまま動くとは限りません。復元後、ソリューションフローはオフになり、接続参照には新しい接続の作成と設定が必要です。カスタムコネクタも確認が必要です。 (Microsoft Learn)
まとめ：バックアップ設定よりも復元設計が重要
Power Platform の「Back up and restore environments」で管理者が最も重視すべきなのは、バックアップの有無ではなく、実際に復元できる設計になっているかです。
Production の Managed Environment ではバックアップ保持期間を最大28日まで延長できますが、Default 環境や Trial 環境には制限があります。また、Production へ直接復元できないため、Sandbox を使った復元手順、同一リージョンの復元先、容量、Managed Environment の一致、接続参照やフローの復旧手順まで準備しておく必要があります。
まずは Power Platform admin center で環境一覧を確認し、Production、Default、Trial の利用状況を棚卸ししてください。そのうえで、重要な Production 環境は Managed Environment 化と保持期間延長を検討し、次回のリリース前に手動バックアップと復元テストを実施することが、最も現実的な対策です。
コメント