基本操作

Power Apps 式が動かないときの調べ方｜ラベルに式を貼って確認するデバッグ入門

Power Apps 式が動かないときの調べ方｜ラベルに式を貼って確認するデバッグ入門

Power Appsで式を書いたのに動かない、変数に値が入っているはずなのに画面に出ない。そういうときに使えるデバッグ手法を整理します。難しいツールは必要ありません。ラベルを1つ置くだけで大半の問題は特定できます。

この記事はエラー・デバッグクラスターのサテライト記事です。エラーの種類の全体像と調べ方の地図はPower Apps 数式エラー解決の全体マップで整理しています。

ラベルデバッグとは何か

ラベルデバッグとは、画面に一時的なラベルコントロールを置き、確認したい式をそのままTextプロパティに書いて結果を目で見る方法です。Power AppsにはVisual Studioのようなステップ実行機能がないため、今この瞬間の値が何かを確認するには、画面に表示するか、Monitorツールを使うかのどちらかになります。

私がPower Appsを使い始めた頃、変数に値が入っているかどうかを確認する方法が分からず、とにかく式を書き直しては試すという非効率な作業を繰り返していました。ラベルデバッグを知ってからは、問題の特定にかかる時間が体感で半分以下になりました。

手順はシンプルです。ラベルを追加して式を書き、アプリを実行して値を確認し、確認が終わったらラベルを非表示にする。これだけです。

変数の中身を確認する

グローバル変数を確認する手順

グローバル変数（Set関数で設定した変数）の中身を確認するには、ラベルのTextプロパティに変数名を直接書きます。

  1. 画面にラベルコントロールを追加する
  2. Textプロパティに確認したい変数名を書く（例：varUserName）
  3. アプリを実行して、そのラベルに表示される値を確認する
  4. 確認後はラベルを選択してVisibleプロパティを false に設定するか、削除する

変数の値がテキスト型以外の場合は、Text()関数でラップして表示します。

// 数値型の変数を表示する
Text(varCount)

// 日付型の変数を表示する
Text(varSelectedDate, "yyyy/mm/dd")

// 論理型（true/false）の変数を表示する
Text(varIsApproved)

グローバル変数とコンテキスト変数の使い方でも触れていますが、変数の型は最初の代入時に決まります。型が分からなくなったときも、このラベルデバッグで実際の値と型を確認できます。

複数変数を一度に確認する

複数の変数を同時に確認したいときは、& 演算子で結合して1つのラベルにまとめると効率的です。

"ID: " & Text(varSelectedId) & " / 名前: " & varUserName & " / フラグ: " & Text(varIsApproved)

これでラベル1つに複数変数の状態がまとめて表示されます。デバッグ専用のラベルとして画面の隅に固定しておくと、複数の操作を試しながら状態を追いやすくなります。

ギャラリーのデータが出ないときの確認

件数ゼロの原因を切り分ける

ギャラリーにデータが表示されないとき、原因は大きく2つです。データソース自体が空か、Filter関数の条件が厳しすぎてヒットしていないかです。この2つを切り分けるためにCountRowsを使います。

  1. ラベルのTextプロパティに `Text(CountRows(データソース名))` を書く
  2. アプリを実行してラベルの数値を確認する
  3. 0より大きい数が出ればデータソースにはデータがある。Filter条件が原因
  4. 0が出ればデータソースへの接続か権限の問題

次に、ギャラリーに適用しているFilter条件だけを取り出してCountRowsで確認します。

// ギャラリーのItemsに書いているFilter式をそのままCountRowsに入れて件数確認
Text(CountRows(Filter(SP_Tasks, Status = "進行中")))

0が返ってきたら、条件の文字列が列の値と一致していないことが多いです。列の実際の値（英語・全角半角・スペースなど）と比較している値が一致しているかを確認してください。

複雑な式を分解してデバッグする

With関数で中間値を確認する

長い式の途中の値を確認したいときは、With関数を使うと便利です。With関数はローカルな中間変数を定義できる関数で、式の途中の状態を名前付きで取り出せます。

With関数で数式をすっきり書く方法の記事でも解説していますが、デバッグ目的でも非常に有効です。例えば以下のような複雑な式があったとします。

// デバッグしたい元の式
Text(DateDiff(LookUp(SP_Projects, ID = varProjectId).StartDate, Today(), Days))

この式をWith関数で分解して、中間値をラベルに表示します。

// With関数で分解してデバッグ
With(
    {
        targetRecord: LookUp(SP_Projects, ID = varProjectId),
        startDate: LookUp(SP_Projects, ID = varProjectId).StartDate
    },
    "レコード: " & Text(IsBlank(targetRecord)) &
    " / 開始日: " & Text(startDate, "yyyy/mm/dd") &
    " / 経過日数: " & Text(DateDiff(startDate, Today(), Days))
)

これをラベルのTextプロパティに書いてアプリを実行すると、LookUpがレコードを取得できているか、StartDateに値が入っているか、DateDiffが計算できているかを一度に確認できます。

バイナリサーチ的に問題を絞り込む

式が長くてどこでおかしくなっているか分からないときは、式を半分に切って動くかどうかを確認します。動けば後半が問題、動かなければ前半が問題です。これを繰り返すことで原因箇所を素早く特定できます。

ネストが深い式の場合は内側から外側に向かって確認します。まず一番内側の関数だけをラベルに書いて確認し、正しい値が返ってきたら一段外側の関数を加えて確認する、という順番です。

IfError関数で実行時エラーをキャッチする

IfErrorの基本的な使い方

式の書き方に問題はないのに実行したときだけエラーが起きる場合は、IfError関数でエラーの内容をキャッチして画面に表示します。IfError関数は第1引数の式がエラーになったとき、第2引数の値または処理を実行します。

// Patch操作のエラーをキャッチして画面に表示する
IfError(
    Patch(
        SP_Tasks,
        Defaults(SP_Tasks),
        {Title: TextInput_Title.Text, Status: "未着手"}
    ),
    Notify("エラー: " & FirstError.Message, NotificationType.Error)
)

FirstError.Message には発生したエラーの詳細メッセージが入ります。Notify関数と組み合わせると、アプリ上部にバナーとしてエラー内容が表示されます。

エラーメッセージに列名が含まれている場合は、その列の型や値が正しいかを確認します。Patchで列が見つからない系のエラーが出たときは、SharePointの列の内部名（英語名）とPowerAppsで指定している列名が一致しているかを見直してください。

OnStartやOnVisibleの初期化エラーを確認する

OnStartとOnVisibleの使い分けの記事でも触れていますが、OnStartやOnVisibleに書いた処理でエラーが起きると、変数が初期化されないまま画面が表示されます。そのため、変数が空のままという症状として現れることがあります。

OnStartやOnVisibleの処理をIfErrorでラップしておくと、初期化時のエラーをNotifyで表示できます。

// OnVisibleの処理全体をIfErrorでラップする
IfError(
    ClearCollect(colUsers, SP_Users);
    Set(varCurrentUser, LookUp(colUsers, Email = User().Email)),
    Notify("初期化エラー: " & FirstError.Message, NotificationType.Error)
)

デバッグ用ラベルの後片付けルール

デバッグに使ったラベルを放置しておくと、アプリが重くなる原因になります。確認が終わったらすぐに片付ける習慣をつけてください。

削除するのが一番すっきりしますが、後でまた使うかもしれない場合はVisibleプロパティをfalseにして非表示にしておく方法もあります。ただし、非表示のラベルでも数式は評価されるため、パフォーマンスへの影響がゼロではありません。長期間放置するなら削除することをおすすめします。

後片付け方法メリットデメリット
削除する式が評価されなくなる。アプリが軽いまた使いたいときに書き直しが必要
Visible: false式を残しておける。すぐ確認再開できる式は評価され続けるため微妙に重くなる
別画面に移動デバッグ専用画面として集約できる管理が複雑になる

私は開発中は Visible: false で残しておき、公開前にまとめて削除するやり方をとっています。公開直前に一度ツリービューを上から確認して、デバッグ用のラベルが残っていないかチェックする癖をつけると安心です。

まとめ

ラベルデバッグは地味ですが、Power Appsで最も頼りになる確認手段です。ラベル1つで変数の状態、ギャラリーの件数、式の途中の値をすべて確認できます。

デバッグが速くなると、開発のリズムが変わります。エラーで詰まる時間が減る分、機能を作る時間が増える。市民開発を続けていく上で、デバッグの習慣は早めに身につけておくと後々かなり楽になります。

この記事を書いた人
守屋 祐輔
守屋 祐輔
物流会社の非エンジニアサラリーマン。Power Platformを独学で学び、営業職からDX担当に職務変更し、社内ツールを作っています。個人事業のデザイン業務にもPower Platformを活用し、市民開発.comの運営者として、アプリ開発やDX推進の経験を発信中。

Xでフォローしよう