Power Appsが「エラーを出さずに間違う」とき ─ 委任の警告を放置するとどうなるか

Power Appsで最も危険なのは、エラーが表示されないまま誤った結果が返る不具合です。委任の警告を放置したアプリは、データが増えた時点で静かに壊れます。

本記事で解決できるお悩み

委任に関する警告の意味と、放置したときのリスクが分からない
Power Appsが「動くのに正しくない」原因を切り分けたい
エラーが出ないタイプの不具合を、開発中に見つける方法を知りたい

委任の警告は「動かない」ではなく「途中までしか見ない」という意味

委任の警告は、数式が壊れているという意味ではありません。Power Appsがその数式をデータソース側で処理できず、手元に取り込んだ一部の行だけで計算していることを知らせる通知です。

Power Appsは本来、絞り込みや並べ替えをデータソースに任せます。SharePointやSQL Serverに「条件に合う行だけ返してほしい」と依頼し、結果だけを受け取る仕組みです。この委譲ができない数式を書くと、警告が表示されます。

赤い波線ではなく黄色い三角形で表示されるのは、多くの場合そのまま動いてしまうからです。動いてしまうがゆえに、見過ごされます。

既定では先頭500件しか処理していない

Power Appsが委任できない数式を処理するとき、データソースから取得するのは既定で先頭500件です。2026年8月時点のMicrosoft公式ドキュメント「キャンバスアプリでの委任について」に明記されています。

上限はアプリ設定の「データ行の制限」から1〜2,000件の範囲で変更できます。ただし2,000件に引き上げても、それを超えるデータでは同じ問題が起きます。

100万件のテーブルに対して委任できない絞り込みを書いた場合、Power Appsは先頭500件しか見ません。目的のレコードが501件目にあれば、見つからないという結果が返ります。エラーではなく、正常終了として返ります。

危険なのは、データが少ないうちはテストに通ってしまうこと

委任の問題が厄介なのは、開発中に発覚しないからです。テスト用のデータが数十件しかない環境では、委任できない数式も正しい結果を返してしまいます。

本番に移してデータが積み上がり、500件を超えた時点で結果が変わります。アプリ側は何も変えていないのに、ある日から検索に引っかからないレコードが出てきます。

利用者からは「たまに出てこない」という曖昧な報告になります。再現条件がデータ件数に依存するため、原因の特定に時間がかかります。

警告すら出ない委任の抜け穴がある

委任の警告が出ないのに委任されていない、という状況が存在します。Set関数やUpdateContext関数で変数に格納したデータは内部的にコレクションになり、委任の対象から外れます。

コレクションはメモリ上の静的なリストです。データソースへの問い合わせではないため、そもそも委任という概念が適用されません。Power Apps側も警告を出しません。

一度変数に入れてから絞り込む書き方は、読みやすく見えて危険です。変数に格納した時点で件数が確定してしまうためです。

データ行の制限を1にしてテストすると、問題が開発中に現れる

委任の問題を開発段階で見つける方法があります。アプリ設定の「データ行の制限」を一時的に1へ下げると、委任できない数式は1件しか返さなくなり、異常が目に見える形で現れます。

Microsoft公式ドキュメントでも、概念実証のアプリを本番環境へ移す際に予期せぬ事態を避ける手段として案内されています。

テストデータを本番相当の件数まで増やすより手軽です。数式を書いた直後に切り替えて確認する習慣にすると、後から原因を探す手間がなくなります。

委任できない代表的な関数を先に覚える

委任できない関数を先に把握しておくと、設計の段階で回避できます。CountRowsやCount、GroupBy、Concat、FirstN、LastN、Collect、ClearCollectは委任できません。

Filter、Search、LookUp、Sortは委任できますが、内部で使う演算子によって結果が変わります。MidやLenのような文字列操作関数を条件に混ぜた瞬間、その数式は委任されなくなります。

委任できるかどうかはデータソースによっても異なります。DataverseとExcelでは対応範囲が違うため、接続先を変えた際に挙動が変わることがあります。

変数がブランクを返すのは、初期化の順番の問題

変数が空になる不具合の多くは、初期化の順番が原因です。Power Appsの変数はSetやUpdateContextで代入するまでブランクであり、代入前に参照する処理が走れば空の値が返ります。

起動直後の画面で変数を参照している場合、OnStartでの代入が間に合っているかを確認してください。画面のOnVisibleで代入した変数を別の画面から参照する構成も、事故のもとになります。

SetとUpdateContextの使い分けも影響します。UpdateContextで作った変数は画面単位のスコープを持つため、画面を移動した先では参照できません。

まとめ

Power Appsのつまずきは、エラーが出るものより出ないもののほうが深刻です。委任の警告と変数の初期化は、どちらもアプリが動いてしまうがゆえに発見が遅れます。

数式を書いた直後にデータ行の制限を1にして確認する。変数に入れる前に絞り込む。この2つを習慣にするだけで、本番で静かに壊れるアプリはかなり減らせます。

よくある質問

委任の警告が出ていても、そのまま使って問題ないケースはありますか？

データが常に500件未満に収まるテーブルであれば、実害は出ません。ただし今後件数が増える見込みがあるなら、警告を放置せず委任できる数式に直しておくほうが安全です。

データ行の制限を2,000件に上げれば解決しますか？

根本的な解決にはなりません。2,000件を超えた時点で同じ問題が再発します。件数を増やすほど読み込みも重くなるため、委任できる数式へ書き換えるほうが確実です。

委任できるかどうかは、どこで確認できますか？

数式に黄色い三角形と青い波線が表示されるかで判断できます。ただしSetやUpdateContextで変数に格納した後の処理は警告が出ないため、変数を使う箇所は自分で確認する必要があります。