Power Apps キャンバスアプリの動作が遅い！？そんな時にはパフォーマンスを改善できるかも！

Power Apps キャンバスアプリのパフォーマンスの改善方法について、Microsoft 公式ドキュメントに記載されている内容を参考にピックアップしつつ、簡潔に整理してみました。（参考リンクは後述）

Power Apps キャンバスアプリのデータ取得や更新が遅い、起動が遅い、処理が遅い、今後大きめのアプリを作る予定で不安だ、といった方のご参考になりましたら幸いです。

パフォーマンス改善のヒント

データソースに対する一般的なパフォーマンス改善のヒント
SharePoint に関するパフォーマンス改善のヒント
Dataverse に関するパフォーマンス改善のヒント
アプリの構成や実装に関するパフォーマンス改善のヒント
その他のパフォーマンス改善のヒント

データソースに対する一般的なパフォーマンス改善のヒント

データソースとの地理的距離による影響

実行ユーザーとデータソースの距離が地理的に遠い場合、様々な側面でパフォーマンスに影響する場合があります。簡単に対策できない場合もありますが、そういった影響があることはひとまず認識しておきましょう。

データソース側の制限、スロットリングによる影響など

一時的にデータソースからデータが取得できない場合がある、というような場合には、データソースの制限にかかっている可能性があります。接続先のデータソースによっては、サービス保護の観点から短時間に大量アクセスを行うと制限がかかるなど、様々な制限事項が存在しており、それに抵触しているかもしれません。

詳細は各接続先のコネクタや、サービスの詳細を確認しましょう。

コネクタ参照の概要 | Microsoft Learn

Dataverse の場合には、こちらにサービス保護に関する制限について記載されています。

サービス保護 API の制限 (Microsoft Dataverse) - Power Apps | Microsoft Learn

SharePoint に関するパフォーマンス改善のヒント

リストの構成列を少なくする

リストの列構成が大きくなってしまうほど、パフォーマンスに悪影響を与えます。特に画像列や添付ファイルサイズなどは影響が大きくなります。これにはリストの構成列を最低限の構成にしたり、以下のリンクを参考に明示的な列選択の機能を有効にすることで対策が可能です。

Microsoft Dataverse とデータソースエクスペリエンスの向上 - Power Apps | Microsoft Learn

リストのデータを大量に保持しない、またはリストを分割する

数十万件レベルの大量データを含むリストのデータ処理はパフォーマンスに影響を与えます。リストにデータが大量に含まれる場合には、リストを年度や種別などで複数のリストに分割、分散させることを検討しましょう。

参照列や計算列など、動的な列を多用しない

動的な列を多用するとSharePoint内でのデータ処理に時間がかかってしまいます。ユーザー列の代わりに、ユーザー名やメールアドレスを1行テキストの列で直接持つ形にするなど、静的な値として保持するようにしましょう。

Dataverseを使用する

Dataverse は Power Apps との親和性が高く、データ要求も直接行われるため、SharePointと比較して非常に高速です。SharePoint をデータソースとしたことを起因とするパフォーマンス面での問題が発生した場合には、データソースをDataverse へ変更することも検討しましょう。

Dataverse に関するパフォーマンス改善のヒント

Dataverse は高速なアクセスが可能

Dataverse をデータソースとした場合には、Power Apps と親和性が高く、ほかのデータソースと比較して高速にアクセスすることが可能です。

Dataverse のビューをキャンバスアプリで利用する

もし関数によるフィルタやソート、データの結合などを行っている場合には、Dataverse のビューの機能の利用を検討します。すべての場合で利用できるわけではありませんが、数式を記述することなく複雑なフィルタやソートを構成できたり、結合されたデータを取得することができます。この処理はサーバーサイドで行われるため、データの転送量も低減することができます。

アプリの構成や実装に関するパフォーマンス改善のヒント

多機能アプリを作らない / 大きなアプリを作らない

あまり大きなアプリを作ると、パフォーマンスに影響します。1つのアプリに機能を入れすぎないようにしましょう。明確な制限としては、以下のような要素が公式ドキュメントに記載されています。

1アプリ内に30を超える接続を追加しない。
1つのアプリ内に500を超えるコントロールを追加しない。

例えばユーザー向けと管理者向けの機能が1つのアプリに含まれている場合には、分割を検討しましょう。

OnStartの肥大化に対処する

パフォーマンス改善の大きなトピックとして、OnStartの肥大化の問題があります。OnStartに含まれる処理が大きくなることで長大なコード全体を解釈して処理する必要があり、処理が遅くなってしまう問題が発生します。

対策としては、処理を分散させることで個別に解釈させることができ、処理を高速化させることができます。また、後述の手段で分割することにより、必要になったタイミングで初めて処理されることになり、起動時の負荷も低減させることができます。公式ドキュメントによれば、個別化により80%処理が高速になる場合もあるようです。

処理の分散、個別化には、以下の選択肢があります。

OnVisible に処理を分散する。
App.Formulas を使用する（試験段階の機能）。
Power Apps コンポーネント　カスタム出力プロパティを使用する。

GAされていれば App.Formulas の機能が利用しやすそうです。

Power Apps の App オブジェクト - Power Platform | Microsoft Learn

ただし、現状試験段階の機能となっており運用アプリでの利用は難しい状態です。代替手段としてはコンポーネントのカスタム出力プロパティを利用した疑似関数化が選択可能です。

キャンバスコンポーネントのプロパティ (実験的) - Power Apps | Microsoft Learn

長大な数式を分割し、再利用する

キャンバスアプリ内に含まれる長文の数式によって、アプリの起動パフォーマンスに影響を及ぼします。先に挙げた App.OnStart 以外でも、長大になってしまった OnVisible や OnSelect プロパティなどがある場合には、数式を分散させ、なるべく再利用しましょう。

分割、再利用する手段としては以下のものが挙げられます。

コンポーネントのカスタム出力プロパティの利用
With()関数の利用
ボタンコントロールなどのOnSelect と Select()による疑似メソッド化の利用

キャンバスコンポーネントのプロパティ (実験的) - Power Apps | Microsoft Learn

With 関数 - Power Platform | Microsoft Learn

関数を選択する - Power Platform | Microsoft Learn

小さなデータセットはローカルで保持する

小さなデータセットに何度もアクセスしに行くような処理が含まれている場合には、コレクションやグローバル変数としてローカルで保持してしまうこともできます。こうすることで、データソースへのアクセス回数を低減し、処理速度を向上させることができます。ただし、大きなデータセットで行う場合にはメモリを大量に消費してしまうため、注意が必要です。