Power Appsで数式が赤くなったとき、何から手をつければいいか分からなくなることがあります。エラーメッセージを読んでも意味がつかめない、直したつもりなのに別のところが壊れる。そういう経験は市民開発者なら誰でも通る道です。
この記事では、数式エラーが起きたときの診断の順番とよくある原因のパターンを整理します。全体の流れを頭に入れておくと、どんなエラーが出てもあわてずに対処できるようになります。
Power Appsのエラーはなぜ読みにくいのか
Power Appsのエラーメッセージは、初見だと意味がつかみにくいものが多いです。英語で表示されることもありますし、日本語でもこの関数は引数を2つ受け取りますのように、具体的に何が問題なのかすぐには分からない言い方をします。
私が最初にPower Appsを触り始めた頃、数式バーが赤くなるたびに検索エンジンを頼っていました。ところが、検索で出てくる解説は前提知識が必要なものが多く、自分の状況と合致しているかどうかも判断しにくい。結果的に、エラーを直すたびに30分以上かかることもありました。
そこで大切なのは、エラーの種類を素早く見分ける力です。Power Appsで起きるエラーは大きく3つに分類できます。構文エラー・型エラー・実行時エラーです。それぞれ原因が違うので、診断の方向性も変わります。
数式エラーの3分類と見分け方
構文エラー：式の書き方が間違っている
もっとも多いのが構文エラーです。括弧の閉じ忘れ、カンマの位置ミス、全角スペースや全角カンマが混入している、などが典型的な原因です。
構文エラーは数式バーが赤くなる段階、つまりアプリを実行する前の時点で検出されます。エラー表示の下に波線が引かれている箇所が原因です。数式バーのカーソルをそこに合わせると、ツールチップでメッセージが表示されます。
確認ポイントは以下の通りです。
- 括弧の開き・閉じの数が合っているか（Visual Studioなどのエディタと違い、Power Appsは対応する括弧をハイライトしてくれません）
- 引数の区切りがセミコロン（;）かカンマ（,）か（地域設定によって変わる）
- 文字列のダブルクォートが正しく閉じているか
- コピペしたコードに全角文字が混じっていないか
特に全角文字の混入は見た目で気づきにくく、私も何度か引っかかりました。コピペで式を作ったときに起きやすいので、手で書き直すと解決することがあります。
型エラー：データの種類が合っていない
型エラーは、関数が期待するデータの種類（型）と、実際に渡している値の型が食い違っているときに起きます。例えば、テキスト型の列に数値を直接渡そうとした場合や、日付型の列に文字列を入れようとした場合です。
よくある組み合わせミスを表にまとめます。
| やりがちなミス | 原因 | 対処 |
|---|---|---|
| 数値列に & でテキスト結合しようとした | & 演算子はテキスト型同士が必要 | Text() 関数で数値をテキストに変換 |
| 日付列に DateValue() を使わずに文字列を入れた | 文字列と日付型は別物 | DateValue("2024/01/01") で変換 |
| Patch で選択肢列に文字列を渡した | 選択肢列は {Value:"..."} の形式が必要 | {Value: "選択肢名"} に直す |
| Filter の条件式に論理型でない値を書いた | Filter の条件は true/false でなければならない | = や <> で比較式にする |
型変換が必要な場面では、Text()・Value()・DateValue()・DateTimeValue() の4つを覚えておけばほとんど対応できます。
実行時エラー：動かしてみて初めて出るエラー
実行時エラーは、数式バーの段階では問題がないのに、アプリを動かしたときに起きるエラーです。データソースが見つからない、権限がない、レコードが存在しないといった、実際の処理を動かさないと分からない問題が原因です。
実行時エラーが出たときは、アプリ上部にエラーバナーが表示されます。バナーをタップするか、モニター（Monitor）ツールを開くと詳細が確認できます。
実行時エラーの主な原因は3つです。
- SharePointリストやDataverseへのアクセス権限がない
- Patch関数で存在しない列名を指定している
- 委任警告のある関数がデータ上限（2000件）を超えた部分で動作している
委任の問題は特に見落としやすいです。委任警告が出ていても動作するので直さなくていいと思いがちですが、データが増えた段階で突然おかしな動きをし始めます。委任の警告と対処法については別記事で詳しく解説しています。
エラーを自力で特定する5ステップ
エラーの種類が分かったら、次は原因を特定します。私が実際に使っている診断の手順を順番に紹介します。
ステップ1：エラーが出ているプロパティを確認する
Power Appsでは、コントロールのプロパティごとに数式を書きます。どのプロパティでエラーが出ているかを最初に特定することが大切です。
ツリービューでコントロールを選択し、プロパティドロップダウンを切り替えながら赤くなっているプロパティを探します。エラーアイコンが付いているプロパティが原因です。
- ツリービューで問題のコントロールをクリック
- 画面上部のプロパティドロップダウンを確認
- 赤いエラーマークが付いているプロパティを選択
- 数式バーでエラーの内容を確認
ステップ2：式を最小構成まで削る
エラーが出ている数式が複雑な場合は、式を分解して最小構成に削ることが有効です。
例えばFilter関数にネストした条件が複数ある場合、まず条件を1つだけにして動くか確認します。動くなら条件を1つずつ追加していくことで、どの条件が問題かを切り分けられます。
体感的に、複雑な数式のエラーの7割はこの「削る→確認→追加」のサイクルで特定できます。デバッグの基本は動く状態から育てることです。
ステップ3：作成（Compose相当）でデバッグ変数に値を出す
式の途中の値が何になっているか確認したいときは、ラベルコントロールを使ってデバッグ表示する方法が便利です。
画面上の適当な場所にラベルを追加し、Textプロパティに確認したい式を直接書きます。例えば、変数の値が正しいかどうかを確認するには以下のように書きます。
"変数の値: " & Text(varMyValue)アプリを実行して、このラベルに表示される値を見ることで、数式の途中の状態を確認できます。確認が終わったらラベルを非表示（Visible: false）にするか削除します。
パフォーマンス改善の記事でも触れましたが、デバッグ用のラベルを大量に残したままにするとアプリが重くなります。確認が済んだらすぐに片付けることをおすすめします。
ステップ4：IfError関数でエラーを可視化する
実行時エラーが出るタイミングと場所をもっと詳しく特定したいときは、IfError関数が役に立ちます。IfError関数は、第1引数の式がエラーになったとき、第2引数の代替値（またはアクション）を返す関数です。
IfError(
Patch(データソース名, Defaults(データソース名), {列名: 値}),
Notify("エラーが発生しました: " & FirstError.Message, NotificationType.Error)
)FirstError.Message はエラーの詳細メッセージを取得できるプロパティです。Notify関数と組み合わせることで、画面上にエラーの内容を表示できます。本番アプリでも活用できるパターンです。
ステップ5：Monitorツールで実行ログを確認する
Power Appsにはモニター（Monitor）という公式のデバッグツールがあります。アプリの実行中にどんなAPIリクエストが発生しているか、どのデータソースにアクセスしているか、エラーが何件出ているかをリアルタイムで確認できます。
- Power Apps スタジオの上部メニューから詳細設定→モニターを開く
- アプリのモニターをクリックしてモニターを起動
- 別ウィンドウでアプリが開くので、エラーが起きる操作をする
- モニター画面にログが積み上がるので、エラー行（赤くなっている）をクリック
- 右ペインで詳細を確認する
私はSharePointへのPatch操作が失敗するとき、必ずMonitorを確認します。エラーメッセージに列名が書かれていることが多く、この列の型が合っていないという原因が一発で分かります。
よく出るエラーと解決パターン一覧
エラーの種類とよくある原因・解決策をまとめます。同じパターンを何度も調べることになりがちなので、手元に置いておくと役立ちます。
| エラーメッセージ（抜粋） | よくある原因 | 解決策 |
|---|---|---|
| Expected {Table} | テーブル型が必要な場所にレコードや値を渡している | データソース名を直接渡す。または Table() 関数でラップする |
| Invalid argument type | 引数の型が期待されるものと違う | 型変換関数（Text, Value, DateValue）を使う |
| The function 'X' has some invalid arguments | 引数の数か型が違う | 公式ドキュメントで引数の仕様を確認する |
| Delegation warning（委任の警告） | Filter・Search・LookUpが委任非対応の書き方になっている | 委任対応の書き方に変更するか、Collectionに取り込んでから処理する |
| Network error | SharePoint・Dataverseへの接続が切れた、または権限不足 | ブラウザをリロードしてみる。権限設定を確認する |
| Record not found | Patch・Remove・LookUpで対象レコードが見つからない | 条件式が正しいか確認。レコードが実際に存在するか確認 |
エラーを減らすための設計習慣
エラーを直す力と同じくらい大切なのが、エラーを出にくくする設計の習慣です。
変数の型をあらかじめ決める
Power Appsの変数は型宣言がなく、Set関数で代入した値の型になります。途中で別の型の値を代入してしまうと、型エラーが起きます。変数を使い始めるときに、テキストなら空文字列（""）、数値なら 0、テーブルなら ClearCollect で初期化しておく習慣をつけると型エラーが減ります。
// OnStart や OnVisible で変数を初期化する
Set(varSelectedId, 0); // 数値型として初期化
Set(varMessage, ""); // テキスト型として初期化
ClearCollect(colItems, []); // テーブル型として初期化数式を短い単位に分割する
1つのプロパティに複雑な式を詰め込むほど、エラーが出たときの特定が難しくなります。With関数を使って式を分割したり、名前付き計算式（App.Formulas）を使ってアプリ全体で使い回せる形にしたりすることで、デバッグのしやすさが大きく変わります。
コンテナで構造を整理する
画面の構造が複雑になるほど、どのコントロールのどのプロパティにエラーがあるかを追うのが大変になります。コンテナを活用してコントロールの階層を整理することで、ツリービューが見やすくなりエラーの発生場所を素早く特定できるようになります。
まとめ
数式エラーの診断は、構文エラー・型エラー・実行時エラーの3種類に分けて考えると整理しやすくなります。エラーの種類が分かれば、確認すべき場所と使うべき道具も自然と決まります。
最初は一つひとつ調べながらで構いません。同じパターンのエラーを何度か直しているうちに、数式バーが赤くなった瞬間にこれは括弧の問題だなと分かるようになってきます。市民開発のデバッグスキルはそうやって地道に積み上げていくものです。
