はじめに
Power Appsでデータソースを扱う際、「なぜ表示できる件数とFilterやSortしたときに扱える件数が異なるのか？」という疑問を抱く場面は少なくありません。
本記事では、2000以上件のデータを単純に表示できるのに、関数処理（Filter／Sort／Searchなど）をはさむと先頭2000件しか処理されない仕組みを調査しました。
個人で調べたものになりますので、間違ったことがございましたらドシドシ指摘していってください。
データ取得アーキテクチャの全体像
Power Appsの動作は大きく「サーバー側処理」「クライアント側処理」「データの受け渡し」の3フェーズに分かれます。
各フェーズで何が起きているかを押さえると、2000行制限の本質がクリアになります。
-
サーバー側処理
-
Filter、Sort、CountRows、Sumなどデリゲート対応関数は、ODataクエリとしてサーバーへ投げられる - SharePoint、SQL Server、Dataverseといったリモートデータソースがサーバー代わり
-
-
データの受け渡し
- ネットワーク越しに取得済みのレコードセットがクライアント（ブラウザやモバイルアプリ）へ転送
- 転送済みセットはアプリ内のコレクションやギャラリーで使用可能
-
クライアント側処理
- デリゲート不可関数（
Contains、Len、複雑な式など）は、取得済みバッファ上でクライアントがローカル計算 - バッファサイズは「既定500件／最大2000件」に制限
- デリゲート不可関数（
このうち「サーバー側で返却されるレコードセット」が最大2000件に制限されているため、Filterをかけたときは2000件あるデータのうち先頭2000件分しかサーバーから返ってこない。
2000行制限が発生する具体的タイミング
1. デリゲーション（委任）処理時
- 条件
-
Filter(MyList, 条件)／Sort(MyList, 列, Asc)／Search(MyList, キーワード, 列)など - コネクタがODataクエリの発行に対応している
-
- 挙動
- Power Appsは「可能ならサーバー側で処理すべし」と判断
- ODataクエリに変換し、対象システムへ送信
- サーバーは最大2000件の結果セットを返却
- クライアントにはその2000件だけが到達
2. 非デリゲーション（ローカルバッファ）処理時
- 条件
-
Contains、Len、複雑なネスト式など、委任非対応関数をFilterに含む -
AddColumnsやWithで未知の演算を含む場合も該当
-
- 挙動
- Power Appsは「委任できない」と判断し、バッファリング可能な件数だけダウンロード
- 既定500件／設定で2000件まで取得
- クライアント側でローカルフィルタリング
3. 単純バインド（生データ表示）の場合
- 条件
-
Items = MyListのみを指定し、FilterやSortを置かない
-
- 挙動
- 初期表示時に100件など最小バッチ分を取得
- ギャラリーやデータテーブルのスクロールに合わせて、次バッチ100件ずつ取得
- 取得済み合計が「アプリ設定 > 詳細設定 > データ行の制限（既定500／最大2000）」に達するまで延長
- Dataverseコネクタ等では透過的にページングを続け、2000件以上表示できることも
委任警告と行数制限設定の見かた
Power Apps Studio では、FilterやSortに委任不可の要素が混在すると▼マークで警告が表示されます。
- 警告右クリック → 「詳細の表示」で、どの関数／演算が非委任なのかを逐一確認可能
- 「アプリ設定 > 詳細設定 > データ行の制限」で、ローカルバッファ上限を500→2000へ増加可能
ただし、ローカルバッファを2000件に増やしても、サーバー側で返却される2000件の壁は突破できない
回避パターン：大規模データを安全に処理する方法
以下4つのアプローチを組み合わせることで、2000件以上のデータに対しても全件処理や集計を可能にできます。
パターン①：インデックス付き列でレンジ分割
- SharePointリストなどでインデックス設定済みの列（IDや日付）を用意
- Filterで範囲を区切り、2000件以下のバッチを取得
ClearCollect(colBatch1, Filter(MyList, ID <= 2000)); ClearCollect(colBatch2, Filter(MyList, ID > 2000 && ID <= 4000)); - Collectで複数バッチをマージ
Clear(colAll); Collect(colAll, colBatch1); Collect(colAll, colBatch2);
パターン②：コネクタ固有のページングAPI活用
SharePoint RESTやDataverseのListRowsには$top/$skip相当のパラメータが存在します。
これをPower Appsのコネクタ関数で呼び出し、明示的にSkipをずらしながら取得することでサーバーの制限を回避できます。
// SharePoint:GetItems例
ClearCollect(
col1,
MySharePointList.GetItems({Top:2000, Skip:0}).value
);
ClearCollect(
col2,
MySharePointList.GetItems({Top:2000, Skip:2000}).value
);
Clear(colFull);
Collect(colFull, col1);
Collect(colFull, col2);
パターン③：Power Automate（Flow）で前処理
- Power Automateで「全件取得→集計／絞り込み」を実行
- 結果だけをPower Appsに返すHTTPレスポンス／コネクタで受け取る
- アプリ側はFlow実行結果を使うだけなので、2000件制限を気にせず大量データ処理が可能
パターン④：大規模データ向けプラットフォーム移行
- Azure SQL DatabaseやDataverseへの切り替えで、サーバー側ページングやストリーミングが強化
- Power Appsのデリゲーション制限もコネクタ単位で緩和される
- 複雑なクエリを直接SQLで書けるため、パフォーマンス最適化の自由度が上がる
実践的チェックリスト
- Filter／Sortを使う際、Studioの▼委任警告を必ず確認
- アプリ設定で「データ行の制限」を2000に上げているか
- 頻度の高い絞り込み条件はインデックス列で処理
- コネクタ固有のページング関数が用意されていないか調査
- Power Automate連携で集計ロジックをFlowに分離可能か検討
- 将来的に数万～数十万件扱うなら、SQL／Dataverse移行を視野に
おわり
2000件以上のデータを「ただ見るだけ」ならPower Appsのスクロール機能で容易に達成できました。
FilterやSortをはさむとサーバー側で処理された先頭2000件のみがクライアントに返ってくる、という動作原理がありました。