PowerAppsのConfirm関数で迷わない?確認ダイアログの便利な使い方

Power Appsで削除ボタンや保存ボタンを作ると、「押した瞬間に実行されるのが怖い」と感じる場面がありますよね。

特に業務アプリでは、レコード削除、ステータス更新、入力中の画面離脱など、あとから戻しにくい操作がよく出てきます。そこで役に立つのが、Power FxのConfirmです。

Confirmを使うと、処理の前に確認ダイアログを出し、ユーザーが選んだ結果で処理を分けられます。自作ポップアップより軽く始められるので、まずは標準関数として押さえておきたいところです。

PowerApps Confirmでできること

Confirmは、ユーザーの操作をいったん止めて、実行してよいか確認するための関数です。まずは、Confirmが何をしてくれるのか、Notifyや自作ダイアログとどこが違うのかを整理しておくと、使いどころを間違えにくくなります。

Confirmは確認ダイアログを出す関数

Power AppsのConfirmは、キャンバスアプリで確認用のダイアログを表示するPower Fx関数です。

Microsoft LearnのConfirm関数ページでは、メッセージとオプションを指定して確認ダイアログを出す関数として説明されています。

大事なのは、Confirmが単に画面へメッセージを出すだけではないことです。ユーザーが確認ボタンを押せばtrue、キャンセルを押せばfalseが返ります。この戻り値をIfで受けて、処理を実行するか止めるかを分けます。

たとえば削除ボタンのOnSelectにConfirmを入れると、ユーザーは削除前に一度確認できます。ここでキャンセルを選べば、削除処理は走りません。「押したら即削除」にならないので、業務アプリの誤操作防止に向いています。

ただし、Confirmは万能な安全装置ではありません。ユーザーへ確認する関数なので、権限チェックや入力チェックの代わりにはなりません。権限制御や必須入力は、別の仕組みできちんと守る必要があります。

Notifyとの違いを先に押さえる

Confirmと混同しやすい関数に、Notifyがあります。Notifyは、処理の結果や注意を画面上部の通知として表示する関数です。たとえば「保存しました」「入力内容を確認してください」のようなメッセージに使います。

一方で、Confirmはユーザーの選択を待ちます。つまり、Confirmは実行前、Notifyは実行後に置くと考えると分かりやすいです。

削除前に「削除しますか？」と聞きたいならConfirmです。削除後に「削除しました」と知らせたいならNotifyです。両方を使うなら、Confirmで確認して、処理が終わったらNotifyで結果を知らせる流れになります。

この切り分けを曖昧にすると、画面上に通知は出ているのに処理が止まらない、という状態になりがちです。ユーザーに判断してもらう必要があるなら、Confirm優先で考えましょう。

自作ダイアログより先に検討したい理由

Power Appsでは、変数とコンテナーを使って自作の確認ダイアログを作ることもできます。ただ、削除前確認のようなシンプルな用途なら、最初から自作するより標準Confirmを使うほうが早いです。

Confirmなら、メッセージ、タイトル、補足文、確認ボタン、キャンセルボタンの文言を指定できます。複雑な画面制御を増やさずに、短い数式で確認処理を入れられるのが利点です。

もちろん、次のような場合は自作ダイアログも候補になります。

• 入力欄やチェックボックスをダイアログ内に置きたい
• 選択肢を3つ以上にしたい
• アプリ独自の見た目やレイアウトを細かく作りたい
• 複数ステップの確認フローにしたい

逆に言えば、確認するだけならConfirmで足ります。まずは標準関数で実装し、足りない理由が出てから自作UIを検討する順番が扱いやすいです。

Confirmの基本構文と戻り値

Confirmは、見た目よりも戻り値の扱いが重要です。構文、OptionsRecord、Ifとのつなぎ方を押さえると、削除ボタンや保存ボタンのOnSelectにすぐ組み込めます。

基本構文はMessageとOptionsRecord

Confirmの基本構文は次の形です。

Confirm(Message [, OptionsRecord])

Messageは、ダイアログ本文に出す文字列です。これは必須なので、まずは「このレコードを削除しますか？」のように、ユーザーが判断できる文を書きます。

OptionsRecordは省略できます。ただ、業務アプリではボタン文言まで指定したほうが分かりやすいので、僕はなるべく使う前提で考えます。

OptionsRecordでよく使う項目は、次の4つです。

ボタンがOKとCancelのままだと、何が起きるか一瞬迷うことがあります。削除なら「削除」、保存なら「保存」、戻るなら「戻る」と、操作に合わせた短い言葉へ変えるのがおすすめです。

Ifでtrue側だけ処理を実行する

Confirmが返す値は、確認ボタンならtrue、キャンセルならfalseです。そのため、実務ではIfと組み合わせるのが基本になります。

削除前確認なら、次のような形です。

If(
    Confirm("このレコードを削除しますか？"),
    Remove(Tasks, ThisItem)
)

この数式では、ユーザーが確認ボタンを押したときだけRemoveが実行されます。キャンセルした場合はfalseなので、第二引数の削除処理は走りません。

ここで大事なのは、Confirmの外側に危険な処理を置かないことです。削除や更新の関数をConfirmの前後に何となく置くと、キャンセルしても処理される書き方になってしまう場合があります。実行位置には注意しましょう。

特に、Confirmの外へRemoveやPatchを出してしまう書き方は事故原因になります。

たとえば、確認後に複数処理を走らせたい場合は、true側に処理をまとめます。Power Fxでは動作数式の中で処理を続けて書けるため、Patch後にNotifyを出すような流れも作れます。

ボタン文言は操作に合わせて変える

Confirmを実務で使うなら、文言設計も重要です。ダイアログの本文があいまいだと、ユーザーは反射的にボタンを押してしまいます。

たとえば「実行しますか？」より、「この申請を削除しますか？」のほうが具体的です。さらに取り消せないなら、Subtitleへ「削除後は元に戻せません」と入れると、判断しやすくなります。

保存前の確認なら、次のように書けます。

If(
    Confirm(
        "入力内容を保存しますか？",
        {
            Title: "保存確認",
            Subtitle: "保存すると一覧画面に戻ります",
            ConfirmButton: "保存",
            CancelButton: "戻る"
        }
    ),
    SubmitForm(EditForm1)
)

この例では、確認ボタンが保存、キャンセルボタンが戻るになります。ボタンの意味がそのまま操作名になるので、ユーザーが迷いにくいです。

文言の作り方は、次の基準で見ると整えやすくなります。

1. 何を対象にするかを書く
2. 実行すると何が起きるかを書く
3. ボタン文言は短い動詞にする
4. 取り消せない操作は明記する

Confirmは小さな関数ですが、文言が整うだけでアプリ全体の安心感が変わります。特に業務データを扱う画面では、対象と結果を短く出すことを意識しましょう。

削除や保存前にConfirmを使う例

Confirmの価値が出るのは、押したあとに戻しにくい操作です。ここでは削除、保存、リセット、画面遷移のような業務アプリでよくある場面に絞って、使い方を見ていきます。

削除前はRemoveの前で止める

一番分かりやすい使いどころは、削除ボタンです。ギャラリー内のゴミ箱アイコンにRemoveを直接書くと、ユーザーが押した瞬間に削除されます。

テストアプリなら問題になりにくいですが、業務アプリでは誤削除がそのまま問い合わせや復旧作業につながります。削除前には、Confirmを挟んでおくほうが安全です。

If(
    Confirm(
        ThisItem.Title & " を削除しますか？",
        {
            Title: "削除確認",
            Subtitle: "削除後は元に戻せません",
            ConfirmButton: "削除",
            CancelButton: "キャンセル"
        }
    ),
    Remove(Tasks, ThisItem)
)

この例では、削除対象のタイトルをメッセージに含めています。単に「削除しますか？」だけだと、ユーザーはどのレコードを削除するのか不安になります。対象名を出すだけで、判断の精度が上がります。

対象が見えない確認は見落としにつながりやすいので避けましょう。

削除前確認で意識したいポイントは、次の3つです。

• 削除対象が分かる文言にする
• 取り消せない場合は明記する
• Confirmのtrue側にだけRemoveを書く

削除対象が複数ある場合は、「選択中の3件を削除しますか？」のように件数を出すと親切です。一括処理では影響範囲が広がるため、件数や対象範囲を見せるだけでも事故を減らせます。

保存前はSubmitFormやPatchの前で確認する

保存処理でもConfirmは使えます。特に、保存すると承認フローが進む、ステータスが変わる、通知メールが飛ぶ、といった画面では確認を入れる価値があります。

フォームなら、SubmitFormの前にConfirmを置きます。

If(
    Confirm(
        "入力内容を保存しますか？",
        {
            Title: "保存確認",
            Subtitle: "保存すると内容が反映されます",
            ConfirmButton: "保存",
            CancelButton: "編集に戻る"
        }
    ),
    SubmitForm(EditForm1)
)

Patchで保存している場合も考え方は同じです。ユーザーが確認したときだけPatchを実行し、必要なら後続でNotifyを出します。

If(
    Confirm(
        "ステータスを完了に変更しますか？",
        {
            Title: "ステータス変更",
            ConfirmButton: "変更",
            CancelButton: "キャンセル"
        }
    ),
    Patch(
        Tasks,
        ThisItem,
        { Status: "完了" }
    )
)

保存前確認は、すべての保存ボタンに入れる必要はありません。単純な下書き保存や、すぐ修正できる項目の更新に毎回Confirmを出すと、ユーザーは手間に感じます。確認疲れを起こさないように、影響の大きい保存へ絞るのが大切です。

未保存のまま戻る操作を防ぐ

入力フォームでよくあるのが、保存せずに戻ってしまうケースです。編集フォームには、未保存の変更を示すUnsavedプロパティがあります。これを使うと、未保存のときだけConfirmを出せます。

If(
    EditForm1.Unsaved,
    If(
        Confirm(
            "保存せずに戻りますか？",
            {
                Title: "未保存の変更",
                Subtitle: "入力内容は破棄されます",
                ConfirmButton: "戻る",
                CancelButton: "編集を続ける"
            }
        ),
        Back()
    ),
    Back()
)

この書き方なら、未保存の変更がないときはそのまま戻ります。未保存の変更があるときだけ確認が出るので、不要なダイアログを減らせます。

画面遷移でも考え方は同じです。Navigateの前でConfirmを使えば、入力中のデータを失う前に止められます。未保存の状態だけに絞ると、使いやすさと安全性のバランスを取りやすいです。

Confirmでつまずきやすいポイント

Confirmは便利ですが、入れれば安心というものではありません。使いどころを間違えると、ユーザーが毎回止められて操作しにくいアプリになります。ここでは失敗例と判断基準を先に押さえます。

すべてのボタンにConfirmを入れない

Confirmは、ユーザーの手を一度止めます。これは危険な操作には効果がありますが、軽い操作にまで入れると、アプリ全体のテンポが悪くなります。

たとえば、検索条件のクリア、タブ切り替え、詳細画面の表示など、すぐ戻せる操作に毎回Confirmを出す必要は薄いです。確認が多いほど、ユーザーは内容を読まずに押すようになります。その結果、本当に大事な確認まで流されることがあります。

Confirmを入れるか迷ったら、次の表で判断すると決めやすいです。

ポイントは、戻せるかと影響範囲です。戻せない操作、重要データへ影響する操作、一括処理、外部通知が飛ぶ操作にはConfirmを検討します。一方で、すぐ戻せる操作には入れすぎないほうが使いやすいです。

入力チェックや権限制御の代わりにしない

Confirmは、ユーザーへ「本当に実行しますか？」と聞く関数です。入力値が正しいか、操作してよい権限があるか、処理が成功したかを保証するものではありません。

ここを勘違いすると、危険です。たとえば削除ボタンにConfirmを入れても、削除権限のないユーザーをデータソース側で止められないなら、設計としては弱いです。また、必須入力が空のままでも、Confirmは入力内容を検証してくれません。

役割を分けると、次のようになります。

• Confirm: 実行前の意思確認
• DisplayMode: ボタンを押せる条件の制御
• Validateや入力チェック: 値の妥当性確認
• IfErrorやNotify: 実行後のエラー表示
• データソース権限: 実際にできる操作の制御

Confirmは最後の確認としては便利ですが、守りの中心ではありません。Confirmだけに頼る設計は守り不足になりやすいです。業務アプリでは、入力条件、権限、エラー処理を別で整えたうえで、Confirmを足すのが自然です。

文言があいまいだと逆に危ない

Confirmの文言があいまいだと、ユーザーは何を判断すればよいか分かりません。「よろしいですか？」だけでは、対象も結果も伝わらないからです。

悪い例は、次のような書き方です。

Confirm("実行しますか？")

この文だと、何を実行するのか分かりません。削除なのか、保存なのか、承認なのか、ユーザーは画面全体から推測する必要があります。曖昧文言は避けましょう。

改善するなら、次のように対象と結果を入れます。

Confirm(
    "この申請を承認しますか？",
    {
        Title: "承認確認",
        Subtitle: "承認後は申請者に通知されます",
        ConfirmButton: "承認",
        CancelButton: "キャンセル"
    }
)

これなら、対象はこの申請、結果は申請者に通知、実行ボタンは承認だと分かります。短い文でも、判断に必要な情報を入れれば十分です。

ConfirmとNotifyを組み合わせる設計

Confirmは実行前に止める関数で、Notifyは実行後に結果を知らせる関数です。この2つを組み合わせると、ユーザーは確認、実行、結果の流れを追いやすくなります。

Confirmは実行前、Notifyは実行後に置く

ConfirmとNotifyを組み合わせるときは、役割を混ぜないことが大事です。Confirmはユーザーの意思を確認し、Notifyは処理の結果を伝えます。

たとえばステータス更新なら、まずConfirmで「変更しますか？」と聞きます。ユーザーが確認したらPatchを実行し、成功したらNotifyで「更新しました」と伝えます。

流れは次の順番です。

1. ユーザーがボタンを押す
2. Confirmで実行前確認を出す
3. trueならPatchやSubmitFormを実行する
4. 成功したらNotifyで結果を知らせる

この順番にすると、ユーザーは何が起きたかを追いやすいです。逆に、ConfirmなしでNotifyだけ出すと、処理がすでに終わったあとに気づく形になります。事前確認が必要なら、Notifyだけでは足りません。

結果通知だけで止めたつもりになるのは設計ミスです。

Patch後に成功通知を出す

ステータス更新の例を、ConfirmとNotifyで書くと次のようになります。

If(
    Confirm(
        "完了に変更しますか？",
        {
            Title: "ステータス変更",
            ConfirmButton: "変更",
            CancelButton: "キャンセル"
        }
    ),
    Patch(
        Tasks,
        ThisItem,
        { Status: "完了" }
    );
    Notify(
        "ステータスを更新しました",
        NotificationType.Success
    )
)

この例では、Confirmのtrue側でPatchを実行し、その後にNotifyを表示しています。キャンセルした場合は、PatchもNotifyも実行されません。

実務では、Patchが失敗する可能性も考えます。接続エラー、権限不足、入力値の不整合などがあるからです。そのため、重要な更新ではIfErrorやエラー表示も一緒に検討すると安心です。

シンプルな画面では、まず次の設計で十分です。

• 実行前: Confirm
• 実行処理: Patch、SubmitForm、Remove
• 実行後: Notify
• 失敗時: エラー通知や画面上のエラー表示

この形を基本にしておくと、ボタン処理の読みやすさも保ちやすくなります。後から見た人も、確認前と実行後の役割を追いやすいです。

標準Confirmで足りない場合は自作ダイアログへ

Confirmは便利ですが、標準の確認ダイアログなので、自由に何でもできるわけではありません。入力欄を置く、3つ以上の選択肢を出す、一覧を見せながら確認する、といった用途には向きません。

次のような要件があるなら、自作ダイアログやコンポーネントを検討します。

• 削除理由を入力させたい
• 承認、差し戻し、保留のように選択肢が3つ以上ある
• 確認対象の明細を表で表示したい
• ブランドに合わせたレイアウトが必要
• 画面全体のモーダルとして細かく制御したい

ただし、自作にすると変数、表示制御、フォーカス、キャンセル時の処理など、管理するものが増えます。まずは標準Confirmで足りるかを見て、足りない理由がはっきりしたら自作へ進むのが現実的です。

Confirmは、小さな関数で大きな事故を減らすための道具です。入れどころを絞り、Notifyやエラー処理と組み合わせると、業務アプリの操作感がかなり安定します。

PowerApps Confirmに関するよくある質問

まとめ

PowerApps Confirmは、削除、保存、画面遷移の前にユーザーへ確認を挟める便利な関数です。基本はIfで戻り値を受け、true側にだけRemove、SubmitForm、Patchなどの処理を書きます。

ただし、Confirmは安全設計の一部です。入力チェック、権限制御、エラー処理、Notifyによる結果表示と組み合わせて、本当に止めたい操作だけに入れていきましょう。