Power Apps のフォームで送信ボタンを押したとき、画面上部にちっぽけなエラーが出て終わる。そんな経験はありませんか。ユーザーはそのエラーに気づかず再度ボタンを押し、なんで保存されないの？と混乱します。入力ミスを防ぐには、エラーをユーザーの目線で、わかりやすい場所に、わかりやすい言葉で伝える設計が必要です。
この記事では、Power Apps で必須チェックを実装し、入力項目のすぐ下にエラーメッセージを出す方法を解説します。
標準フォームのエラー表示が弱い理由
Power Apps の標準フォーム（EditForm）には SubmitForm 関数を使った保存機能があり、必須列の未入力も検出してくれます。ところが、そのエラーは画面上部のシステムメッセージとして表示されるだけです。スマホアプリで画面を下にスクロールしていると、上部のエラーは視野の外に出てしまい、ユーザーがエラーに気づかないまま何度もボタンを押すことになります。
私が社内でアプリを展開したとき、現場のスタッフから、保存ボタンを押しても何も起きないという報告が複数きました。原因を調べると、必須項目が空欄のままで上部にエラーが出ていたのに、全員がそれを見ていなかったのです。エラーを出す場所と伝え方を変えるだけで、そういった問い合わせはほぼゼロになりました。
標準フォームの弱点をまとめると、エラー位置が固定（上部のみ）、エラー文言が英語や無機質な自動生成メッセージ、どの項目が問題なのかパッと見てわからない、の3点です。これを解決するのが、本記事で解説するカスタムエラー表示の実装です。
IsBlank と IsEmpty の違いと使い分け
必須チェックを実装する前に、よく混同される IsBlank 関数と IsEmpty 関数の違いを整理しておきます。この2つは名前が似ていますが、チェックする対象が根本的に異なります。
IsBlank はテキスト入力・日付・数値など単一のフィールドや値が空かどうかを判定します。テキスト入力コントロールの空欄チェックにはこちらを使います。一方 IsEmpty はテーブル（コレクションや Recordset）が0件かどうかを判定するものです。テキスト入力に IsEmpty を使うと、空欄でも必ず false を返してしまい、バリデーションが機能しないので注意が必要です。
| 関数 | 対象 | 空のとき | 使うケース |
|---|---|---|---|
| IsBlank | 値・フィールド | true | テキスト入力・日付・数値の未入力チェック |
| IsEmpty | テーブル・コレクション | true | ギャラリーの件数ゼロ・コレクション未初期化チェック |
必須チェックの基本構文は次のとおりです。IsBlank 関数にテキスト入力コントロールの Text プロパティを渡します。
IsBlank(TextInput_Name.Text)これが true を返したとき、エラーラベルを表示するという設計になります。
エラーメッセージを入力項目のすぐ下に配置する
実装の考え方はシンプルです。各入力項目の直下にエラー用ラベルコントロールを配置し、Visible プロパティを条件式で制御します。エラーがない状態ではラベルは非表示になっていますが、未入力で送信しようとした瞬間に赤字のメッセージが現れます。
ただし、ここで一点注意があります。画面を開いた直後から入力前にいきなりエラーを出すのは、ユーザーにとってストレスになります。名前欄に何も入れていないのに最初から「未入力です」と赤字が出ていたら、使いにくいですよね。そこで varFormSubmitted という変数を使い、送信ボタンを押した後にだけエラーを表示する設計にします。
varFormSubmitted パターンの実装手順
- 送信ボタンの OnSelect に
Set(varFormSubmitted, true)を追加します - エラーラベルの Visible プロパティに
And(varFormSubmitted, IsBlank(TextInput_Name.Text))を設定します - キャンセルボタンの OnSelect と画面の OnVisible に
Set(varFormSubmitted, false)を追加してリセットします
この設計の利点は、ユーザーが送信を試みるまではまったくエラーが見えないため、入力作業中の余計なストレスがゼロになることです。送信ボタンを押した瞬間に問題のある項目だけが赤くなるので、どこが問題かが一目でわかります。
送信ボタンの表示と無効化のルール
エラー表示と合わせて、送信ボタンの状態制御も設計しておく必要があります。ここで陥りやすいミスが2つあります。
1つ目は DisplayMode.View を使うことです。Power Apps の DisplayMode.View は見た目はボタンに見えますが、実際にはタップできません。ユーザーがボタンを押しても反応がなく、故障していると思われます。ボタンのモードは DisplayMode.Edit（通常）か DisplayMode.Disabled（非活性）のみを使うようにしましょう。
2つ目はボタンを Visible:false で隠すことです。入力前から送信ボタンが消えていると、どこで保存するの？とユーザーが迷います。ボタンは常に表示した状態を保ち、条件を満たさないときは DisplayMode.Disabled で押せない状態にするのが正解です。
// 送信ボタンの DisplayMode プロパティ
If(
Or(IsBlank(TextInput_Name.Text), IsBlank(TextInput_Email.Text)),
DisplayMode.Disabled,
DisplayMode.Edit
)グローバル変数とコンテキスト変数の使い分けを理解していると、varFormSubmitted のようなフラグ変数の管理がスムーズになります。
モダンフォームのバリデーション設計
Power Apps にはクラシックフォームとモダンフォームの2種類があります。モダンフォームの場合は ValidationState プロパティと ValidationMessage プロパティを使うことで、よりシンプルにエラー表示を実装できます。
モダンフォームのテキスト入力では、ValidationState プロパティに Error または None を設定します。Error にすると自動的に赤枠が付き、ValidationMessage に指定した文字列がエラーメッセージとして表示されます。カスタムのラベルコントロールを別途配置しなくても済むのが利点です。
// モダンフォームの ValidationState プロパティ
If(And(varFormSubmitted, IsBlank(Self.Value)), "Error", "None")
// ValidationMessage プロパティ
"名前は必須です"また、複数フィールドのバリデーション状態を一括管理したい場合は、名前付き計算式（App.Formulas）を使ったアプローチが有効です。たとえば formValid という named formula を App.Formulas に定義しておくと、送信ボタンの DisplayMode や各エラーラベルの Visible を1箇所で管理できます。
// App.Formulas に定義する named formula の例
formValid = Not(Or(lbl_NameError.Visible, lbl_EmailError.Visible));この formValid を送信ボタンの DisplayMode 判定に使えば、フィールドを追加するたびに各所の条件式を書き直す手間がなくなります。再利用性が高く、メンテナンスしやすい設計です。
タイマーで変数セット→バリデーション→送信の順序を保証する
Power Apps の OnSelect はすべての処理が同時に評価されるため、変数を true にしてからバリデーションを動かし、問題なければ保存、という順番を素直に書いてもうまくいかないことがあります。
Set(varFormSubmitted, true) を書いた直後に SubmitForm を書いても、変数の更新がバリデーションの再評価より先に終わらない場合があるのです。これはモダンフォームで特に顕著です。
解決策はタイマーコントロールを使うことです。送信ボタンの OnSelect でタイマーを起動し、OnTimerEnd の中で formValid が true のときだけ SubmitForm を実行します。Duration を 100〜200 ミリ秒に設定するだけで、評価順序の問題を回避できます。
// 送信ボタンの OnSelect
Set(varFormSubmitted, true);
Set(varStartTimer, false);
Set(varStartTimer, true) // タイマーを起動
// Timer コントロールの OnTimerEnd
If(formValid, SubmitForm(Form1))
この設計は少し手間に見えますが、一度作ればほぼどんなフォームでも使い回せます。私はこのパターンをテンプレート化して、新しいフォームを作るたびにコピーして使っています。
まとめ：エラーの見せ方が、アプリの信頼感を決める
Power Apps で入力ミスを防ぐには、エラーを出すこと自体よりもどこでどう伝えるかの設計が重要です。入力項目のすぐ下にエラーメッセージを出し、ボタンは常に見えていて条件次第で押せない状態にする、この2点を守るだけで、現場からの問い合わせは大きく減ります。
バリデーション設計は コンテナを使ったレイアウト設計とも組み合わさると威力を発揮します。エラーラベルの配置をコンテナで管理すれば、レイアウト崩れを気にせずフォームを改修できます。地道な設計の積み重ねが、使ってもらえるアプリに近づく一歩です。
入力エラーに関する一覧はこちらの記事をご覧ください。
