
フォームに10項目入力した直後、間違えて戻るボタンを押してしまい、全部消えた。そんな経験がある現場スタッフは少なくありません。Power Apps では、未保存の変更がある状態で画面を離れようとしたとき、確認ダイアログを出して離脱を防ぐ設計が作れます。
この記事で解説する未保存警告は、Power Appsの入力ミス防止設計の全体像の中でもうっかりミスを防ぐフロー制御の一つです。Unsaved プロパティと OnChange フラグを使った警告ダイアログの実装方法を解説します。
入力途中で画面を離れるとデータが消える問題
Power Apps の画面遷移は Navigate 関数で実装します。戻るボタンの OnSelect に Back() や Navigate(Screen_List) を書くだけで、即座に画面が切り替わります。このシンプルさが便利な一方、確認なしに離脱できてしまうという問題も生みます。
私が現場展開したアプリで、最初は何も警告を入れていませんでした。社内の勉強会で実演中にスタッフが入力フォームのテスト中に誤って戻るボタンを押し、全入力が消えるという場面がありました。その場はデモだったので笑い話で済みましたが、実務で起きたらシャレになりません。
スマホ操作では特にこの問題が顕在化します。画面端のスワイプ操作がアプリの戻るボタンと競合したり、誤タップが起きやすかったりします。入力量が多い申請フォームほど、未保存警告の設計は重要です。
Unsaved プロパティを使う方法
EditForm コントロールを使っているなら、Unsaved プロパティが利用できます。フォームに紐づいたいずれかのデータカードで値が変更された場合、Unsaved は自動的に true になります。保存(SubmitForm)か Reset(ResetForm)が実行されると false に戻ります。
この仕組みを戻るボタンの制御に使います。戻るボタンの OnSelect に直接 Back() を書く代わりに、Unsaved の値によって処理を分岐させます。
// 戻るボタンの OnSelect
If(
Form1.Unsaved,
Set(varShowUnsavedDialog, true),
Navigate(Screen_List, ScreenTransition.Fade)
)
Unsaved が true のとき、確認ダイアログを表示する変数を立てます。false なら未変更なのでそのまま画面遷移します。変数の基本的な使い方を理解していれば、このフラグ制御はすぐに実装できます。
確認ダイアログをコンテナで作る
警告ダイアログは、コンテナコントロールを使ったオーバーレイUIで実装します。ダイアログ用のコンテナを画面の最前面に配置し、varShowUnsavedDialog が true のときだけ表示する設計です。
ダイアログの構成
- 垂直コンテナを1つ作成し、Visible プロパティに varShowUnsavedDialog を設定します
- コンテナの背景色を半透明の黒(RGBA(0,0,0,0.5))にして、画面全体を覆う大きさにします
- その中に白背景の内側コンテナを配置し、メッセージとボタン2つ(破棄して戻る・キャンセル)を配置します

破棄して戻るボタンの OnSelect には、ダイアログを閉じてから画面遷移する処理を書きます。キャンセルボタンはダイアログを閉じるだけです。
// 破棄して戻るボタンの OnSelect
Set(varShowUnsavedDialog, false);
ResetForm(Form1);
Navigate(Screen_List, ScreenTransition.Fade)
// キャンセルボタンの OnSelect
Set(varShowUnsavedDialog, false)
コンテナを使ったオーバーレイダイアログの配置については、コンテナを使ったレイアウト設計の全体ガイドが参考になります。Z軸方向の重なり順(コンテナの配置順)を正しく設定しないと、ダイアログが他のコントロールの下に隠れてしまうことがあります。
OnChange フラグを使う方法(EditForm 非使用の場合)
EditForm を使わず、個別のテキスト入力やドロップダウンを直接配置している画面では、Unsaved プロパティが使えません。この場合は各コントロールの OnChange プロパティでフラグを立てる方法を使います。
// 各テキスト入力コントロールの OnChange プロパティ
Set(varHasChanges, true)
// 画面の OnVisible プロパティ(画面を開くたびにリセット)
Set(varHasChanges, false)
戻るボタンの処理は Unsaved パターンと同様です。varHasChanges が true なら確認ダイアログを出し、false ならそのまま遷移します。保存処理(Patch 関数など)が成功したタイミングでも varHasChanges を false に戻すことを忘れないようにしましょう。Patch 関数の使い方と組み合わせると、保存後の状態リセットがスムーズに実装できます。
画面遷移の基本と組み合わせる
Power Apps の画面遷移は Navigate 関数が基本です。Navigate 関数の使い方で解説しているように、画面遷移に引数としてコンテキスト変数を渡すこともできます。未保存警告の実装では、遷移先画面に情報を渡す必要はほとんどありませんが、複雑な遷移フローを組む場合は知っておくと便利な機能です。

注意点:スワイプ操作やハードウェアバックには対応できない
このアプローチには1つ大きな制限があります。Power Apps 内の戻るボタンを制御するのは有効ですが、Android 端末のハードウェアバックボタンやスワイプ操作による戻るアクションには対応できません。Power Apps はこれらのシステム操作を上書きする機能を持っていないためです。
割り切りが必要な部分です。スマホ利用が多い現場では、この制限をユーザーに周知するか、画面の上部に保存状態を常時表示するUI(保存済み / 未保存の表示ラベル)を追加して意識させる設計も有効です。完璧な防止は難しくても、ほとんどのユーザーのうっかりミスを防ぐことに意味があります。
まとめ:入力の労力を守るのも、アプリ設計の仕事
未保存警告は、ユーザーが積み上げた入力作業を守るための設計です。EditForm を使うなら Unsaved プロパティ、個別コントロールなら OnChange フラグと、状況に応じて使い分けられます。確認ダイアログはコンテナで作るのが最もシンプルで、他の画面にも流用しやすいコンポーネントになります。
現場のスタッフが安心してアプリを使い続けられる環境を作ることが、市民開発の本質だと思っています。地道な UX 改善の積み重ねが、長く使われるアプリを作ります。