Power Platformのバックアップと復旧：環境・アプリ・フロー・本番リリースの戻し方
Power Platformで「バックアップを取っている」と説明するとき、環境全体を戻せることと、アプリやフローを個別に戻せることは分けて考える必要があります。さらに、本番へ誤ったソリューションを展開した場合は、以前のZIPを保存してあるだけでは復旧手順が決まりません。
基本となるのは、環境の復元、アプリ・フローの定義の復元、業務データの修復を、それぞれ準備することです。この記事では、Microsoft Power Platform（以下、Power Platform）の管理者と開発・運用担当者に向けて、環境バックアップの範囲と制約、個別復旧の備え、本番リリース失敗時の判断を整理します。
対象はMicrosoft Dataverse（以下、Dataverse）を使う環境、Microsoft Power Apps（以下、Power Apps）のキャンバスアプリ、Microsoft Power Automate（以下、Power Automate）のクラウドフローです。アプリ・フローをソリューションに含めた場合と含めていない場合の違いも扱います。Microsoft公式資料を2026年10月20日に確認した調査・設計ガイドであり、実環境でのバックアップ・復元や復旧時間の測定は行っていません。
1. 何を戻したいかで保護する単位を決める
バックアップ方式を選ぶ前に、運用担当者が復旧したい対象を決めます。例えば、フローの条件式を一つ直す作業と、誤削除した業務データを含めて環境を戻す作業では、影響する範囲が異なります。
| 戻したい対象 | 備えるもの | 復旧時に判断すること |
|---|---|---|
| キャンバスアプリの直近の変更 | アプリのバージョン履歴 | 復元したバージョンを利用者へ公開するか |
| ソリューション対応クラウドフローの定義 | フローのバージョン履歴 | 復元した下書きの内容と公開・実行の条件 |
| 本番へ展開したアプリ・フローと関連定義 | ソース管理とリリース成果物 | 依存関係、レイヤー、更新・削除の範囲 |
| Dataverseを含む環境 | 環境バックアップ | 復元先、復元時点、巻き戻る正常な変更 |
| 特定のDataverseレコード・列 | 削除済みレコードの保持、監査、過去データ | 戻す範囲と残す正常な変更を選べるか |
| 外部サービスのデータや誤処理の結果 | 保存先ごとの保護と修復手順 | 再送、重複、取り消し、復元後との差分 |
上の表は、公式機能を組み合わせた運用設計の整理です。ソリューションはコンポーネントやメタデータなどを運ぶ仕組みであり、業務データは含みません。したがって、ソリューションを再展開する備えと、業務データを戻す備えを組み合わせます。[1]
2. 環境バックアップの範囲と保持期間
アプリ・フローがソリューションに含まれているかを確認する
環境のシステムバックアップは、Dataverseデータベースを持つ環境に対して継続的に作成されます。アプリ・フローの定義について、環境バックアップの対象になるのは、Dataverseのソリューションに含まれるものです。そのため、実際にソリューションに含まれていないアプリ・フローの定義は、環境バックアップに含まれません。環境バックアップとは別に、個別の履歴や保管した成果物から復旧する手段を準備します。[2]
ただし、Power Platformには、新しいアプリ・フローをソリューションへ自動追加する設定があります。キャンバスアプリの自動追加設定は、確認した公式資料ではプレビュー機能です。この機能で既定のソリューション（Common Data Services Default Solution）に保存されるため、作成者が手動でソリューション化していなくても、アプリがソリューションに含まれている場合があります。クラウドフローにも自動追加の設定がありますが、こちらは一般提供されており、キャンバスアプリのプレビュー設定とは区別します。[16]
モデル駆動型アプリ（Model-driven app）は、Dataverseを前提に、アプリやテーブルなどの定義をソリューションで管理します。この節でキャンバスアプリについて確認したいのは、一部のアプリがソリューションに含まれず、環境バックアップの対象から外れる場合があるという点です。[17]
コードアプリ（Code app）にも、Dataverseを持つ環境へ初めて公開するときに、Power Apps CLIがソリューションを選んで追加する仕組みがあります。ただし、Dataverseがない場合や追加先のソリューションを特定できない場合には、ソリューションなしで公開されます。そのため、コードアプリも必ずソリューションに含まれるとは判断せず、実際の状態を確認します。[18]
したがって、アプリ・フローの定義が環境バックアップの対象になるかは、ソリューションに含まれているかを指標に確認します。作成者が手動で追加した覚えがあるかどうかや、独自のソリューションを作ったかどうかだけでは判断しません。自動追加されたものも含め、バックアップ時点での実際の状態を確認しておく必要があります。
管理者は、対象環境の独自のソリューションと既定のソリューションなどで、アプリ・フローの定義を確認します。管理センターの自動追加設定も確認しますが、現在の設定がオンであることだけで、既存アプリもすべて追加済みとは判断しません。対象の定義を確認した上で、必要な復元点や復元先の条件、接続・共有などの再設定を含めて復旧訓練を行います。
このソリューションの条件は、アプリ・フローの定義に関するものです。Dataverseの業務データが環境バックアップで保護されることとは分けて考えます。ソリューションのエクスポートは定義を運ぶ操作であり、通常のソリューションのZIPに業務データは含まれません。また、アプリがMicrosoft SharePointのリストや外部のSQLデータベースを使う場合、そのデータは保存先で別途保護します。[1]
ソリューションに含まれること、本番へマネージドソリューションとして配布すること、環境を「マネージド環境」に設定することも、それぞれ別の確認です。非ソリューションの既存アプリ・フローを追加する場合には、追加後に元の非ソリューションの状態へ戻せないという公式の注記も踏まえ、平常時に依存関係や動作を確認してから変更します。[16]
システムバックアップと手動バックアップ
| 方式 | 作成の考え方 | 運用上の使いどころ |
|---|---|---|
| システムバックアップ | サービスが継続的に作成 | 障害発生前の利用可能な時点を選ぶ |
| 手動バックアップ | 管理者が時刻とラベルを記録 | 大きな変更やリリースの前を識別する |
現行方式の手動バックアップは、その都度独立したフルバックアップファイルを作る操作ではありません。継続的なバックアップに対して、復元に使う時刻とラベルを記録します。また、データベースバックアップをダウンロードしてオフライン保管する機能はありません。[2]
保持期間は本番であることだけでは決まらない
公式資料の既定の保持期間は7日です。本番のマネージド環境では、管理者が7・14・21・28日に変更でき、その設定はシステムバックアップと手動バックアップの両方に適用されます。保持期間の変更に必要なテナント管理者ロールと、環境グループのルールも確認します。[2]
| 環境の種類 | 公式資料に示された基本条件 |
|---|---|
| 本番 | 既定7日。本番のマネージド環境は最大28日へ変更可能。実際の復元には下記の条件あり |
| サンドボックス・開発者・Teams | 保持期間表では7日 |
| 既定 | システムバックアップ7日。手動バックアップは非対応 |
| 試用版・サブスクリプションベースの試用版 | システム・手動バックアップとも非対応 |
開発者環境とTeams環境については、同じ公式ページに非マネージド開発者環境とDataverse for Teams環境の廃止に関する注記があります。保持期間表に載っていることを理由に、その環境を長期運用・移行先として選べるとは判断しません。[2]
28日保持と、28日前の状態へ一括で戻せることは同じではない
例えば、本番のマネージド環境Aを2か月間運用し、その間、バックアップの保持期間を28日に設定していたとします。復元画面で28日前の必要な復元点がまだ利用できることを確認できれば、その時点の状態を別環境へ復元する方法があります。
管理者は環境Aを本番のまま維持し、同じリージョンにDataverseを持つサンドボックス環境Bを新規作成して、マネージド環境として用意します。容量や暗号化・企業ポリシーなどの復元条件も満たした上で、環境Aの28日前の復元点を選び、環境Bへ復元します。これは、7日より古いバックアップは本番環境を維持して別のサンドボックスへ復元するという、公式資料の案内に沿った構成例です。[2]
この場合、環境Aは現在の状態を維持し、環境Bにはバックアップの対象範囲について28日前の状態が復元されます。つまり、必要な復元点が保持され、復元条件がそろっていれば、最大28日の保持範囲を利用できます。環境Bで業務を再開するための接続・共有・フローなどの確認は、復元後に別途行います。
「本番のマネージド環境は最大28日へ変更可能」というのは、バックアップを保持する期間の設定です。必要な復元点が実際に残っていて、復元先などの条件を満たせば、その保持範囲内の過去の時点へ、対象のDataverseデータなどを環境単位で復元できます。ただし、28日に設定してあるだけで、いつでも正確に28日前へ本番を一括で戻せる保証にはなりません。[2]
保持期間は、復元候補がどこまで残るかに関係します。実際に戻せる時点と範囲は、次の三つを合わせて確認します。
| 確認するもの | 意味 | 28日の設定だけでは決まらないこと |
|---|---|---|
| バックアップの保持期間 | バックアップを残す期間の設定 | 設定前に期限切れになった過去のバックアップがあるか |
| 利用可能な復元点と復元先 | 実際に選べる日時と、上書きできる環境 | 必要な時刻が残っているか、環境種別などの条件を満たすか |
| 復元対象と業務再開の条件 | 戻るデータ・定義と、再設定する項目 | 外部システムや監査履歴も同じ時点になるか、すぐ業務を再開できるか |
保持期間を延長しても、消えたバックアップは復活しない
例えば、7日保持で運用していた環境を今日28日保持へ変更しても、今日から20日前のバックアップが既に失われていれば、その時点へ戻せるようにはなりません。保持期間の変更は、今後のバックアップと、まだ保持されているバックアップに適用されます。公式資料には、設定の反映に最大24時間かかる場合や、一部の古いバックアップが想定より早く削除される場合もあると記載されています。[2]
また、環境を作成してからの経過日数や、復元点の有効期限にも左右されます。28日前は保持期間の境界に近いため、「28日」という日数だけで判断せず、復元画面にある最も古い利用可能日時と、必要な復元点の日時・有効期限を確認します。
古い復元点があっても、本番自身への戻し方には制限がある
本番環境への直接復元はできず、本番自身へ戻すにはサンドボックスへの種類変更が必要です。公式資料は、7日より前のバックアップを使う可能性がある場合、本番の種類を維持して別のサンドボックスへ復元することを検討するよう案内しています。また、手動復元のために本番をサンドボックスへ変更した場合、選択できるバックアップは過去7日分になると明記しています。[2]
したがって、「28日保持しているので、本番をサンドボックスへ変更し、その場で28日前へ戻す」と決め打ちしません。7日より前の状態が必要なら、まず元の本番を維持して、別の復元先で利用可能な時点を確認します。別環境に復元した状態を新しい稼働先にするのか、必要なデータだけを元の本番へ反映するのかは、その後に設計する作業です。別環境へ戻せたことだけで、本番の切り替えまで完了するわけではありません。
環境を戻しても、業務全体がその日時と同じ状態にはならない
環境単位の復元では、復元対象となる業務データやソリューション内の定義を過去へ戻す一方、その後の正常な更新も影響を受けます。外部サービスのデータや送信済みの通知は別に扱い、接続、アプリの共有、フローの有効化などを確認してから業務を再開します。また、同じ環境へのシステムバックアップ復元では、復元時点より後の監査ログも残ります。すべての情報が同じ日時へ巻き戻る操作ではありません。[2]
運用要件は「28日保持する」だけでなく、「何日前のどの時点へ、どのデータを、どの環境へ戻し、何時間以内に業務を再開するか」まで決めます。この記事では、必要な復元点の存在、復元先の条件、正常な後続更新の扱い、復元後の再設定を含めて訓練し、戻せる範囲を確認することを推奨します。
3. 環境を復元するときの条件と確認
本番の復元と別環境での調査を分ける
本番環境へ直接復元することはできません。本番自身を復元先にする場合は、環境の種類をサンドボックスへ変更し、復元後に本番へ戻します。種類の変更は保持期間にも影響するため、7日より前のバックアップが必要な場合は、本番の種類を維持して別のサンドボックスへ復元する方法を検討します。既定環境のバックアップは、既定環境自身への上書きではなく、開発者環境への復元が案内されています。[2]
環境全体を戻すと、問題のある変更だけでなく、復元時点より後の正常な業務更新も影響を受けます。この記事では、まず別の復元先で影響と回収対象を調べ、本番を巻き戻す必要があるかを判断する運用を推奨します。別環境へ戻した後に必要なデータだけを本番へ移す場合も、キー、関連レコード、重複、現在の更新との競合を調べる作業が必要です。
復元前に管理者が確認する項目
復元元と復元先にはDataverseが必要で、同じリージョンであること、環境の管理状態や暗号化キー・企業ポリシーの条件が合うことを確認します。復元には1GB以上の空き容量も必要です。環境の種類ごとの復元先制限は、公式資料の条件表と実際の管理画面を照合します。[2]
管理者はPower Platform管理センターの対象環境で「Backup & Restore」から、システムの復元時点または手動バックアップを選びます。最終操作の前に、上書きされる復元先の環境IDと、復元時刻・タイムゾーンを作業記録へ残します。監査ログの扱いは、次の節のとおり、復元方式と復元先を分けて判断します。[2]
監査ログは、誰が何を変えたかを調べるために使う
ここでいう監査ログは、Dataverseのレコードの作成・更新・削除などを記録する履歴です。「誰が、いつ、どのレコードを更新したか」「どの列が変わり、変更前の値は何だったか」を調べる手掛かりになります。個別レコードの監査履歴や、環境全体の監査概要から確認できます。Power Automateの実行履歴とは別の情報です。[12]
データ変更を記録するには、あらかじめ環境・テーブル・列で監査を有効にしておく必要があります。監査対象外だった操作や、有効化前の操作の履歴を、復元によって後から作ることはできません。記録済みのログも保持設定によって削除されるため、必要な期間のログが残っているかを確認します。例えば、誤更新した列が監査対象でなければ、その列の変更前の値を監査ログから確認することはできません。[12]
監査ログを調べることと、業務データを修復することは別の作業です。変更前の値が確認できても、その後の正常な更新を残すかを判断し、修正するレコードと値を選ぶ必要があります。監査ログの復元だけで、誤更新の取り消し処理が実行されるわけではありません。
監査ログを戻す場合・戻さない場合の違い
公式資料の手動バックアップの復元手順では、監査ログは既定で除外されます。含める場合は、復元先の選択後に「Audit logs」の「Click here」を開き、監査ログをコピーする設定をオンにします。監査ログを含めると、環境の復元時間が大幅に長くなる可能性があります。[2]
| 手動バックアップの復元時の選択 | 過去の監査履歴の扱い | 判断すること |
|---|---|---|
| 監査ログを含める | 復元に監査ログのコピーを含める | 復元先でも過去の変更履歴を調べる必要があるか、追加の復元時間を許容できるか |
| 監査ログを含めない | 復元元の監査ログのコピーを省く | 過去の履歴を別の保全先で確認できるか、まず業務データの復元を優先するか |
この選択で変わるのは監査履歴をコピーする範囲であり、業務データをどの時点へ戻すかとは分けて考えます。「監査ログを含めない」ことを、すべての復元方式で既存の監査ログが消えるという意味にはしません。
特に、同じ環境へシステムバックアップを復元する場合は、監査ログが削除されず、復元時点より後のログも残ると公式資料に記載されています。例えば、10:30に誤更新があり、同じ環境の業務データを10:00へ戻した場合でも、10:30の監査ログが残るという関係です。現在のレコードの値と、履歴が示す最後の更新が一致しない場合があります。これは説明用の想定例です。[2]
この記事では、別環境で過去の変更も調べたい場合は監査ログを含める必要性を確認し、業務再開を優先してコピーを省く場合は、必要な履歴をどこで保全・参照するかを先に決める運用を推奨します。ログを戻さない選択をしても、復元後の監査設定が不要になるわけではありません。再開前には、監査対象のテーブル・列と保持設定も確認します。
復元先にあるフローは、ソリューション内外で扱いが違う
バックアップの対象を確認したら、次は「復元先に既にあるもの」を確認します。復元元の環境Aと、上書き先の環境Bを分けて考えると、公式資料の説明を読み取りやすくなります。
この節でも、手動で独自のソリューションに入れたかどうかではなく、既定のソリューションへの自動追加も含めた実際のソリューション対応の状態で、フローを区別します。以下の「ソリューション外」は、独自のソリューションで整理していないだけの状態ではなく、実際にソリューション非対応のものを指します。
公式FAQでは、復元先に既にあるソリューション内のフローは削除され、ソリューション外のフローは残ると説明されています。また、復元後のソリューション内のフローはオフになり、接続参照には新しい接続の設定が必要です。[2]
| どこにあるフローか | 環境Aのバックアップを環境Bへ復元するときの扱い |
|---|---|
| Aのバックアップ対象に含まれるソリューション内のフロー | バックアップ時点の定義を復元する。復元後はオフのため、接続と動作を確認して有効化する |
| Aのソリューション外のフロー | Aの環境バックアップからBへ復元される対象には含まれない |
| Bに復元前からあるソリューション内のフロー | 公式FAQでは、復元先の既存ソリューションフローは削除されると説明されている |
| Bに復元前からあるソリューション外のフロー | Bに残る。Aのバックアップから復元されたものではない |
例えば、昨日の環境Aには、ソリューション内の「申請承認フロー」と、ソリューション外の「個人用通知フロー」があったとします。環境Bには別のソリューション外フローである「検証通知フロー」があります。Aの昨日のバックアップをBへ復元すると、申請承認フローは復元対象になりますが、個人用通知フローはそのバックアップからBへは戻せません。一方、Bにもともとある検証通知フローは残ります。これは公式仕様の関係を説明する想定例であり、実行結果ではありません。
つまり、「ソリューション外のフローが残る」と「バックアップから戻せる」は違います。同じ環境へ過去のバックアップを復元する場合も、そこにあるソリューション外のフローまで、その過去の定義へ巻き戻ると考えないようにします。残ったフローについても、復元後のデータや接続先に対して意図した処理になるか、トリガーとアクションを確認します。
ここでの「復元先の既存フローが残る」という説明は、公式FAQがフローについて示したものです。ソリューション外のキャンバスアプリも必ず残る、という保証へは広げません。アプリは前章のバックアップ対象、個別の保全方法と、次の復元後の確認を組み合わせて扱います。
復元完了と業務再開は別の確認になる
公式資料では、復元後のソリューション対応フローはオフになり、接続参照には新しい接続の設定が必要とされています。キャンバスアプリのIDや「Everyone」への共有にも復元前との違いがあります。管理モードを含め、業務再開前に確認します。[2]
この記事で推奨する再開確認は、次の順序です。
- 復元先で、接続先URL、環境変数、認証に使う主体を確かめる。
- アプリIDを使うリンクや埋め込み、アプリの共有先を確かめる。
- フローを有効にする前に、外部への通知・更新が発生する条件を調べる。
- 限定したデータでアプリとフローの業務動作を確認する。
- 管理モードや利用制限を解除し、再開後の実行を監視する。
復元時間はデータ量などによって変わります。環境復元を「数分で戻せる緊急ボタン」として扱わず、許容できる停止時間とデータ損失の範囲を、事前の復旧訓練で確かめる設計にします。
4. アプリ・フローを個別に戻すための備え
キャンバスアプリはバージョン履歴から復元する
Power Appsで対象環境を選び、「アプリ」から対象の詳細を開き、「バージョン」で以前のバージョンを選んで復元します。復元すると新しいバージョンが作成されます。利用者へ反映する場合は、復元された最新の未公開バージョンを確認し、公開します。[3]
公式資料には、6か月以上前のアプリを復元するときの再パッケージ化と、元のパッケージから機能が変わる可能性について注記があります。また、参照した日本語資料はプレリリース文書と明記されています。長期保管や削除への備えを、バージョン履歴だけに任せる設計は避けます。[3]
クラウドフローはソリューション対応かを確認する
Power Automateの下書き・バージョン履歴は、ソリューション対応クラウドフローと新しいデザイナーが対象です。以前のバージョンを選んで復元すると、新しい下書きになります。実行へ反映するには公開が必要です。下書きの履歴は6か月、公開済みの履歴は12か月で期限を迎えます。[4]
ソリューションのエクスポートに含まれるのは、そのフローの最後に公開されたバージョンです。下書きやバージョン履歴はエクスポートされません。リリース担当者は「保存した内容」と「公開して成果物に入った内容」を区別します。[4]
本番へマネージドソリューションとして配布している場合は、個別の履歴復元を本番の標準手順にする前に、編集可能性とレイヤーへの影響を確認します。この記事では、本番の定義を直す際も、開発側のソースと配布成果物の対応を残す運用を基本にします。
ソリューションのソースと配布成果物をそろえる
開発環境のアンマネージドソリューションから、ソースとして保管するものと、本番配布用のマネージドソリューションを作ります。Microsoftはカスタマイズの定期的なエクスポートとソース管理を案内しています。マネージドソリューションそのものや既定のソリューションはエクスポートできません。[5]
したがって、本番にあるマネージドソリューションを後から取り出せば十分、という計画にはできません。開発側のソース、Gitのコミットやタグ、実際に配布したZIP、対象環境の設定を対応づけます。ソース管理から特定時点の構成を取り出して、再び配布成果物を作れる状態にするためです。[1]
接続参照は接続を参照するコンポーネントで、接続には認証情報が保存されます。ソリューションのインポート先では接続参照に使う接続を指定します。環境変数では、現在の値が既定値より優先されます。復旧担当者は、接続の定義と認証、変数の定義と値を分けて記録し、対象環境に合う設定を確かめます。[10][11]
5. 誤った本番リリースから復旧する
正常な構成を新しいバージョンとして配布する
開発環境からソリューションをエクスポートし、本番へインポートしている運用を考えます。公式の更新手順は、開発側のアンマネージドソリューションを修正し、バージョン番号を上げてマネージド形式で配布する流れです。[6]
この仕組みに基づき、この記事では、過去の正常な処理を新しいバージョンとして再リリースする方法を復旧案の中心にします。次は説明用の例で、実施済みの結果ではありません。
| バージョン | 状態 | 用途 |
|---|---|---|
| 1.0.0.0 | 正常 | 戻したい処理内容の根拠 |
| 1.1.0.0 | 不具合あり | 現在の本番に入っている成果物 |
| 1.2.0.0 | 復旧用 | 正常な処理と現在必要な構成を含めて再作成 |
1.0.0.0のソースを取り出しても、単に番号だけ変えれば復旧できるとは限りません。1.1.0.0で追加したテーブルや列、フロー、依存コンポーネントをどう扱うかを決めます。元の処理へ戻しつつ、新たな業務データを保持するために残す構成もあり得ます。
UpdateとUpgradeは削除の要否で選ぶ
| インポートの操作 | 新しいパッケージに含まれない既存コンポーネント | 復旧時の判断 |
|---|---|---|
| Update | 残る | 主に既存定義を直し、追加済みの構成を残す場合 |
| Upgrade | 削除対象になる | 不要な構成を除く必要があり、依存関係とデータ影響を確認できた場合 |
| Stage for Upgrade | 適用を完了するまで旧構成の削除を延期 | 削除前のデータ移行などが必要な場合 |
この違いは、公式の更新・アップグレード手順に基づきます。Upgradeを選べば安全に元へ戻る、という意味ではありません。テーブルや列の削除を伴う場合は、関連データへの影響も調べます。Stage for Upgradeも、旧バージョンを残したまま動作に影響しない待機状態ではありません。保留中のアップグレードが上位レイヤーとなって動作へ影響する場合があります。[6][7]
パッチとアンインストールを緊急時の定番にしない
パッチは小規模な追加・修正に使える仕組みですが、コンポーネントは削除できません。現行の公式資料は、パッチの複製・ソリューションの複製による更新について、チーム開発を制限し、ソース管理を複雑にするため推奨しないとしています。新しい運用を設計するときは、通常の更新・アップグレードを先に検討します。[8]
また、マネージドソリューションのアンインストールは、そのソリューションが持つコンポーネントや関連データの削除につながります。依存関係によって削除できない場合もあります。「いったん削除して旧ZIPを入れる」ことを、一般的な巻き戻し手順にはしません。[9]
本番がアンマネージドだった場合
アンマネージドソリューションを削除しても、取り込んだコンポーネントは削除されません。アンマネージドの変更は共通のアンマネージドレイヤーにあるため、ソリューションの入れ物を消す操作を取り消しとして扱えません。[9][7]
この場合は、正常な定義を再適用した結果と、追加・削除・上書きされた差分を個別に調べます。今後の運用では、開発にアンマネージド、検証と本番への配布にマネージドを使い、配布物とソースを管理する構成を基本にできます。[1]
緊急復旧の作業例
次は、マネージドソリューションを配布しているチーム向けの運用提案です。各環境で実行時間や手順を検証してから、実際の復旧手順書にします。
- 影響を止める。 運用担当者が問題のフローや連携を特定し、必要に応じて停止します。実行中の処理と外部への書き込みも記録します。
- 現状を残す。 本番のバージョン、インポート履歴、レイヤー、障害発生時刻、影響したデータを保存します。追加の変更前に、利用できるバックアップを確認します。
- 復旧範囲を決める。 定義の修正、データ修復、環境復元のどれが必要かを、開発・運用・業務担当者が判断します。
- 復旧用の成果物を作る。 開発担当者が正常なソースを基に修正し、現在より高いバージョンを付けます。UpdateかUpgradeか、削除対象と依存関係も決めます。
- 本番に近い状態で検証する。 不具合版と同じレイヤー・設定を持つ検証環境へ適用し、修正箇所と既存業務の両方を確かめます。空の環境への新規インストールだけでは、更新時の問題を確認できません。
- 本番へ適用する。 対象環境と成果物を照合してインポートします。接続、環境変数、公開状態、有効化の条件を確認します。
- 限定して業務を再開する。 少量のデータで結果を確認し、停止中のイベントや再実行の扱いを決めてから、通常運用へ戻します。
正常な定義をインポートしても結果が変わらない場合は、上位のアンマネージド変更や別ソリューションを調べます。ただし、すべてのコンポーネントが単純な「最後の変更優先」ではありません。モデル駆動型アプリ、フォーム、サイトマップにはマージの動作があります。[7]
6. Dataverseの業務データを必要な範囲で復旧する
例えば、不具合のあるフローが1,000件の顧客レコードを誤更新したとします。フローの条件式を正常に戻しても、既に更新された1,000件はそのまま残ります。環境全体を巻き戻すと、それ以外の正常な業務更新も失う可能性があります。これは説明用の想定例です。
個別のデータ復旧では、「削除したレコードを戻す」「特定の列を変更前の値へ戻す」「関連データを含めてある時点の状態へ戻す」を分けます。公式資料にある機能・方法と、それらを組み合わせる運用案は次のとおりです。
| 要求 | 最初に検討する方法 | 公式資料と運用案の境界 |
|---|---|---|
| 誤削除したレコードだけを戻す | 削除済みレコードの復元機能 | 標準機能。事前設定・保持期間・対象テーブルに条件あり |
| 誤更新した列だけを戻す | 監査履歴で変更前の値を調べ、対象列を補正 | 履歴取得は公式機能。値の選定と再更新は運用案 |
| 特定の顧客と関連レコードを過去の状態へ戻す | バックアップを別環境へ復元し、必要な差分を本番へ反映 | 別環境への復元は公式に案内。抽出・比較・再反映は個別設計 |
| 環境バックアップの保持期間を超えて戻す | 対象データの履歴・スナップショットを別に保管 | この記事の設計案。保存範囲と復旧処理を別途用意 |
削除したレコードは標準の個別復元を確認する
公式の管理者向け手順では、環境で「Keep deleted Dataverse records」を事前に有効にし、削除済みレコードの保持日数を1〜90日に設定します。設定が正常に有効になった後の削除が対象で、保持中のレコードもストレージ容量を消費します。環境バックアップの保持期間とは別の設定です。[13]
システム管理者のセキュリティロールを持つ担当者は、Power Platform管理センターの対象環境で「Settings > Data management > Deleted Records」を開き、対象レコードを選んで「Restore」を実行します。この機能は削除の復元用で、既存レコードの誤更新を以前の値へ戻すものではありません。[13]
仮想テーブル、エラスティックテーブル、ソリューションコンポーネントを保存するテーブルなどには対応していません。対象環境・テーブルで利用できるかを確認します。関連レコードも対象になる場合は、連鎖削除の順序や独自の削除処理を調べます。親レコードの復元だけで、独自処理が削除したすべての関連データまで戻ることを前提にはしません。[13]
バックアップを別環境へ戻し、必要なデータを取り出す
Microsoftは、一括削除したレコードを本番環境へ上書き復元せずに回収する方法として、空の環境を用意し、元の環境のバックアップをそこへ復元する方法を案内しています。本番の新しいレコードを残しつつ、別環境で削除前のデータを参照できる状態を作る考え方です。復元先には第3章のリージョン・環境種別・容量などの条件が適用されます。[2]
ただし、公式資料のこの説明は、回収したレコードを本番へ安全に戻す処理まで自動で提供するものではありません。特定の顧客や案件だけを任意の時点へ一操作で戻す手順は、今回確認した資料では確認できませんでした。以下は、公式の別環境への復元方法を利用した一つの運用案です。実環境で検証した手順ではありません。
- 戻す範囲を決める。 業務担当者が、対象レコードのID、対象列、戻したい時刻とタイムゾーン、含める関連レコードを指定します。「顧客Aの住所だけを10:00の値へ戻し、11:00に登録した受注は残す」のように、残す更新も定義します。
- 過去データを別環境へ復元する。 管理者が必要な時点のバックアップを、条件を満たすサンドボックスへ復元します。通知や外部更新が動かないよう、フロー・プラグイン・接続の状態を確認します。
- 現在との差分を作る。 開発担当者が、復元先と本番から対象データを取得し、ID・列ごとに比較します。変更前の値、現在値、反映予定値と、その根拠を一覧にします。
- 反映する操作を決める。 誤更新なら必要な列だけを更新し、誤削除なら不足するレコードを回収する方法を選びます。参照先のID、親子関係、重複、必須列、所有者、添付ファイルなどを確認し、削除済みレコードの標準復元と、データを再作成する処理を区別します。
- 検証してから限定的に反映する。 本番に近い検証環境で、業務ルール、関連データ、通知・外部更新への影響を確認します。業務担当者が差分を確認してから、少数ずつ本番へ反映します。
- 結果と再実行条件を残す。 成功・失敗したID、反映前後の値、件数を記録します。失敗分の再実行で重複を作らないことと、復旧後の業務結果を確かめます。
別環境のレコードをそのまま全件上書きする方法は、復元時点より後の正常な変更も消してしまいます。また、複数テーブルを抽出するだけで、関連、ファイル、権限、更新日時などを含む元の状態をそのまま再現できるとは限りません。戻す項目と戻せない項目を復旧計画に残します。
誤更新した列は監査履歴を根拠に補正する案もある
監査対象の列で必要な履歴が残っていれば、環境を復元せずに変更前の値を調べられます。公式APIには、監査レコードの詳細を取得するRetrieveAuditDetails、特定レコードの列の変更履歴を取得するRetrieveAttributeChangeHistoryなどがあります。ただし、大きな列の値は5KB程度で切り詰められる場合があり、公式資料も、切り詰められた値はその列の変更を復元するためには使えないとしています。[14]
履歴から値を選んで書き戻す部分は、この記事の運用案です。例えば、顧客の電話番号だけを誤更新した場合は、その変更直前の電話番号を確認し、現在の住所や受注を残したまま電話番号だけを補正します。同じ電話番号が後から正しく更新されていた場合は、機械的に古い値へ戻さず、業務担当者が採用する値を判断します。
比較中にも本番データが更新される場合は、反映直前の再照合や条件付き更新を設計します。Dataverse Web APIでは、取得したETagとIf-Matchを使い、対象テーブルが楽観的同時実行制御に対応している場合に、取得後に変更されたレコードへの上書きを拒否できます。この仕組みは競合を検出する手段であり、業務上どの値が正しいかを決めるものではありません。[15]
監査が無効だった列、必要なログが削除済みの期間、切り詰められた値では、この案だけで戻せるとは限りません。監査ログを業務データ全体のバックアップの代わりにはせず、別環境の復元や、事前に残したデータも照合します。
特定の業務時点へ戻す要件には、事前の履歴保管を設計する
「月次確定前の案件一式へ戻したい」「環境バックアップの保持期間より前の顧客情報を取り戻したい」という要件には、その状態を残す仕組みを別に用意する案があります。これは、Power Platformの環境バックアップがそのまま提供する機能としての説明ではなく、この記事の設計提案です。
対象レコードのID、必要な列、参照先のID、関連レコード、取得時刻、業務上の確定番号などを、版を識別できる形で保管します。添付ファイルや画像も戻す要件なら、それらの実体も対象にします。保管先には、アクセス権と保持期間を設定したファイル・オブジェクトストレージや、業務アプリ専用の履歴テーブルなどが候補になります。
現在値へ同期し続けるだけのコピーでは、誤更新や削除も反映されてしまいます。過去版を上書きせずに保持すること、複数テーブルの取得中に更新が進んだ場合の整合性、削除されたレコードの識別を設計します。例えば、毎晩の保存だけなら、保存していない昼間の任意の時点まで戻せるとは限りません。
CSVの出力だけで関連・ファイル・システム管理列まで完全に戻せるとは考えず、対象データを読み戻して業務処理が成立するかを訓練します。履歴の保管と、そこから必要な値を選んで反映する復旧処理は、両方を用意します。
データを戻しても、外部への処理は別に確認する
Dataverseのレコードを戻しても、送信済みの通知や外部システムへの更新が取り消されるわけではありません。承認や請求などの業務処理を元に戻す要件なら、状態列の値だけでなく、その業務で定めた取り消し・訂正の手順を確認します。
この記事では、データの補正によってフローやプラグインが再び動く条件、停止中のイベント、再実行による重複も、業務再開前の確認に含めることを推奨します。必要な範囲だけを戻す案と、環境全体を戻す案は、失う正常な更新、関連データの整合性、作業時間を比較して選びます。
7. リリースごとに残す記録と復旧訓練
復旧の準備は、バックアップを作成したかという確認だけでは終わりません。この記事で提案するリリース記録は、次のとおりです。
| 残すもの | 復旧で使う目的 |
|---|---|
| リリース番号、配布ZIP、ソースのコミット・タグ | 本番に入れたものと再構築するソースを対応づける |
| ソリューションの一意名、発行元、依存関係 | 同じソリューションとして更新できる条件を確かめる |
| 対象環境ID、インポート方式、実施時刻 | 誤った環境や方式への適用を避ける |
| 接続参照と環境変数、設定の担当者 | 環境に合う接続・値を再設定する |
| 変更前の環境バックアップの時刻と保持期限 | 環境復元が必要になったときに選べる時点を確かめる |
| データ移行・外部連携の変更内容 | 定義を戻すだけでは修復できない処理を特定する |
| 復旧手順、業務確認項目、再開の判断者 | 緊急時に担当者が同じ順序で判断する |
認証情報そのものを通常のソースや記事用の記録へ保存する運用は避け、接続を再作成する担当と手順を記録します。保持期間の延長、復元先の容量、検証用の環境、ソース管理と成果物保管にも運用費用がかかるため、環境構成と契約に応じて見積もります。この記事ではライセンス価格や費用を試算していません。
復旧訓練では、「旧ソースから復旧用パッケージを作れたか」「不具合版がある環境へ適用できたか」「データ修復と業務確認を含めて何時間かかったか」を測ります。バックアップの保持期間より遅く障害を発見する可能性があるなら、長期に残す成果物とデータの保護方法も別に決めます。
最初に確かめるのは、担当する本番アプリとフローがどのソリューションに入り、対応するソースと配布物を取り出せるかです。その上で、定義の修正で済む障害と、データ修復や環境復元が必要な障害を分けて訓練すれば、実際に戻せる範囲と必要な時間を説明できます。
参考資料
資料の確認日：2026年10月20日（モデル駆動型アプリ・コードアプリのソリューション管理は2026年10月21日に追加確認）。保持期間や提供条件は変更されるため、実行前に対象環境と公式資料を再確認してください。英語資料は確認した内容への対応を優先して掲載しています。
- ALM basics with Microsoft Power Platform（Microsoft Learn）：業務データとソリューションの区別、ソース管理、開発以外の環境へのマネージド配布。
- Back up and restore environments（Microsoft Learn）：対象範囲、保持期間、復元条件、復元後のアプリ・フローへの影響。確認時の最終更新は2026年10月6日。
- キャンバスアプリを以前のバージョンに復元する（Microsoft Learn）：復元・公開と古いアプリの注記。参照した文書にはプレリリースの表記があります。
- Drafts and versioning for solution-aware cloud flows（Microsoft Learn）：下書き・履歴の対象、保持期間、復元、エクスポート対象。
- Export solutions（Microsoft Learn）：エクスポートできるソリューションと保管の考え方。
- Upgrade or update a solution（Microsoft Learn）：バージョンを上げた更新、Update・Upgrade・Stage for Upgrade。
- Solution layers（Microsoft Learn）：アンマネージド・マネージドレイヤー、保留中のアップグレード、マージ動作。
- Create and update solutions（Microsoft Learn）：パッチの制限と複製による更新を推奨しない旨の注記。
- Solution concepts（Microsoft Learn）：マネージド・アンマネージドの違い、削除時の影響、依存関係。
- Use a connection reference in a solution with Microsoft Dataverse（Microsoft Learn）：接続と接続参照、インポート先の接続設定。
- Environment variables for Power Platform overview（Microsoft Learn）：環境変数の定義、現在の値と既定値。
- Manage Dataverse auditing（Microsoft Learn）：監査ログの役割、記録する操作、環境・テーブル・列の設定と保持。2026年10月20日確認。
- Restore deleted Microsoft Dataverse table records（Microsoft Learn）：削除済みレコードの保持と個別復元、更新には使えない制限、対応テーブル・関連レコード。管理者向け資料の最終更新は2026年9月25日。1〜90日の設定はこの資料に基づき、対象環境で確認します。
- Retrieve the history of audited data changes（Microsoft Learn）：監査履歴の取得API、変更前後の値と大きな列の値の切り詰め。
- Perform conditional operations using the Web API（Microsoft Learn）：ETag・If-Matchと楽観的同時実行制御。
- Add canvas apps and cloud flows to a solution by default（Microsoft Learn）：ソリューション内の定義をDataverseで管理すること、自動追加の設定、キャンバスアプリの既定の保存先とプレビュー扱い、非ソリューションの既存アプリ・フローを追加するときの注記。2026年10月20日確認。
- What are model-driven apps in Power Apps?（Microsoft Learn）：Dataverseを前提とすること、ソリューションによるアプリと構成要素の管理。
- How to: Application Lifecycle Management (ALM) for code apps（Microsoft Learn）：初回公開時のソリューションの自動選択、Dataverseがない場合・追加先を特定できない場合の例外。