Power Appsが遅いときの改善策｜公式が示す上限とOnStartの最適化
Power Appsで作ったアプリが「開くまで遅い」「操作の反応が鈍い」——業務で使い始めると、この不満が必ず出てきます。
幸いなことに、Microsoftは具体的な数値を含む上限とベストプラクティスを公開しています。この記事では、公式が示す基準と、実際に効果の大きい改善策を優先度順に解説します。
まず守るべき2つの上限
公式ドキュメントに、はっきりと数値で書かれている制限があります。
| 項目 | 上限 | 超えると何が起きるか |
|---|---|---|
| データ接続の数 | 1アプリに30まで | 接続ごとにサインインが必要になり、起動時間が延びる。30を超えると、データ表示に15秒以上かかることがある |
| コントロールの数 | 1アプリに500まで | 画面を描画するための処理が増え、起動が遅くなる |
接続数はデータソースの種類を問わずカウントされます。SharePointリストもDataverseもSQL Serverも、それぞれ1つとして数えられます。
コントロール数については、公式が代替案を示しています。個別のコントロールを並べる代わりにギャラリーを使うと、同じ結果をより少ないコントロールで実現できます。
またPDFビューアー・データテーブル・コンボボックスなど、表示に時間のかかるコントロールがあることも明記されています。同じ画面に置くコントロールの種類を減らすことも有効です。
起動を速くする｜OnStartの最適化
アプリの起動が遅い場合、原因の多くはOnStartにあります。ここで複数のデータを読み込んでいると、その分だけ待たされます。
Concurrent関数で並列読み込みにする
これが最も効果の大きい改善策のひとつです。公式は「アプリがデータを読み込むのに必要な時間を半分に短縮できる」と述べています。
通常、複数の ClearCollect を並べて書くと、1つずつ順番に読み込まれます。
ClearCollect( Product, ... );
ClearCollect( Customer, ... );
ClearCollect( SalesOrder, ... )これを Concurrent で囲むと、同時に読み込まれます。
Concurrent(
ClearCollect( Product, ... ),
ClearCollect( Customer, ... ),
ClearCollect( SalesOrder, ... )
)書き方を変えるだけで、待ち時間が短縮されます。区切りが「;（セミコロン）」から「,（カンマ）」に変わる点に注意してください。
変わらないデータはキャッシュする
セッション中に変化しないデータは、Set や ClearCollect で最初に読み込んでおき、以降はそれを参照します。同じデータを何度もサーバーに取りに行かないためです。
公式が例に挙げているのは、連絡先情報・既定値・ユーザー情報など、頻繁に変わらないデータです。
見落とされやすい原因｜画面をまたぐ参照
これは知らないと気づけない問題です。
Power Appsは必要な画面だけをメモリに読み込むことで速度を保っています。ところが画面1の式が画面2のコントロールを参照していると、画面1を表示する前に画面2も読み込む必要が生じます。
さらに画面2が画面3を、画面3が画面4を参照していれば——連鎖的に多数の画面が読み込まれます。1画面開くだけのはずが、アプリ全体を読み込むことになりかねません。
対策は、画面をまたぐ参照を避けることです。画面間で値を渡したいなら、グローバル変数やコレクションを使います。
効果の大きい改善策
①委任できる書き方にする
公式は「可能な場合、データ処理をデータソースに委任する関数を使用」と明記しています。ローカルで処理すると、処理能力・メモリ・通信量をすべて消費します。とくにデータが多いほど影響が大きくなります。
公式が挙げている具体例が示唆的です。SharePointのID列（数値型）に対して:
| 式 | 委任 |
|---|---|
Filter(リスト, ID = 123 ) |
できる |
Filter(リスト, ID = "123" ) |
できない |
数値型の列に文字列で比較しただけで、委任できなくなります。型の不一致がパフォーマンスを落とすという、見つけにくい問題です。詳細はデータソース選びと委任で解説しています。
②同じ式を何度も書かない
複数のコントロールで同じ複雑な式を使っている場合、1つに書いて、残りはその結果を参照します。
公式の例では、A〜Eの5つのコントロールに同じ式を書くのではなく、Aに式を書き、BはAの結果を参照、CはBを参照——という形にします。
③テキスト入力はDelayOutputを有効に
テキスト入力の値を参照する式が複数ある場合、1文字打つたびにすべての式が再計算されます。
DelayOutput をtrueにすると、入力が止まってから更新されるようになり、無駄な再計算を減らせます。検索ボックスのように、入力しながら結果が変わる箇所で特に有効です。
④ギャラリーが重いときの対処
ギャラリーの表示が遅い場合、公式は次を推奨しています。
- テンプレートを簡素化する——1行あたりのコントロール数を減らす
- DelayItemLoadingをtrue、LoadingSpinnerを設定する——ギャラリーの描画を後回しにして、画面の他の部分を先に表示させる
後者は体感速度の改善です。実際の処理時間は変わらなくても、画面が先に出れば「速くなった」と感じられます。
⑤定期的に再公開する
意外な推奨事項ですが、公式に記載されています。「Power Appsプラットフォームは継続的に最適化されるため、アプリを再公開すると、最新のプラットフォーム最適化内でアプリが再生成される」。
作りっぱなしのアプリは、古い状態のまま動き続けます。定期的な再公開だけで改善する場合があります。
測り方｜推測で直さない
公式が案内している方法は明快です。ブラウザの開発者ツール（EdgeやChrome）でネットワークを見ることです。
どのデータ取得に時間がかかっているかが具体的に分かるため、「なんとなく遅い」を「この読み込みが3秒かかっている」に変えられます。改善は、測ってから始めるべきです。
改善の優先順位
- 接続数とコントロール数を数える——30と500を超えていないか。超えていれば構造の見直しが必要
- OnStartを見直す——Concurrentで並列化できないか。不要な読み込みはないか
- 委任できているか確認する——警告が出ていないか、型の不一致はないか
- 画面をまたぐ参照を探す——連鎖的な読み込みが起きていないか
- ギャラリーのテンプレートを簡素化する
- 再公開する——コストゼロで効果がある場合がある
よくある質問
Q. アプリの起動が特に遅いのですが、まず何を見るべきですか？
OnStartです。ここで複数のデータを読み込んでいれば、Concurrent関数で並列化できます。公式は読み込み時間を半分に短縮できるとしています。
Q. 接続数30、コントロール数500は厳密な制限ですか？
公式は「超えて追加しない」という推奨として示しています。技術的に不可能というより、超えると実用的な速度を維持できなくなるという基準です。
Q. データが多いと遅くなるのは避けられませんか？
委任できる書き方なら、データ量が増えても速度は保てます。遅くなるのは、大量のデータをアプリ側に持ってきて処理している場合です。列にインデックスを付けることも公式で推奨されています。
Q. 画面数が多いアプリはどうすればよいですか？
画面が10以上ありコントロールも多い場合、公式は遅延読み込みの利用を案内しています。有効にしないと、開いていない画面のコントロールにもデータを入れる必要があり、性能が落ちます。
Q. 体感速度を上げる方法はありますか？
あります。ギャラリーのDelayItemLoadingと読み込み中スピナーを使うと、画面の他の部分が先に表示されます。処理時間そのものは変わりませんが、待たされている感覚は減ります。
まとめ
- 公式が示す上限はデータ接続30・コントロール500。接続が30を超えると15秒以上かかることがある
- 起動改善の要はOnStart。Concurrent関数で並列化すると読み込み時間が半減し得る
- 画面をまたぐ参照は連鎖的な読み込みを招く。値の受け渡しは変数を使う
- 型の不一致だけで委任が効かなくなる（数値列を文字列で比較するなど）
- 定期的な再公開で最新の最適化が反映される
- 改善はブラウザの開発者ツールで測ってから。推測で直さない
委任の詳細はデータソース選びと委任、変数の扱いは変数とコレクションで解説しています。
参考・出典
- キャンバス アプリのパフォーマンスを向上させる（Microsoft Learn）――接続30・コントロール500の上限、Concurrent関数、画面間依存、DelayOutput、DelayItemLoading、再公開の推奨
