見出し画像

【Power Apps】 FetchXML のページング完全ガイド：大規模データを確実に扱うための実務ポイント #0201

Shinichi Kawara

1. 導入（仮想ストーリー）

大阪の企業で社内アプリ開発を担当する 30 代の IT エンジニア「近畿さん」。Power Apps / Power Platform の経験はあるものの、最近ユーザー数が増え、「数万件のデータを扱う」シナリオが日常になってきました。

ある日、営業部からこう相談を受けます。

「1 年分の商談データを検索するとアプリが固まります。もっとスムーズにできませんか？」

近畿さんは Dataverse のデータ取得を FetchXML で実装していますが、
ページングの仕組みを完全に理解しているとは言えませんでした。

そんな中、Microsoft Learn の “Page results with FetchXML”
の記事を読むことで、FetchXML のページングがどのように仕組み化されているのか、実務に必要な理解が一気に深まっていきます。

この記事では、Learn の内容を忠実に、「なぜ必要か」「どんなメリットがあるか」「現場でどう使うか」の視点で解説します。

2. 本文（技術解説）

FetchXML ページングとは何か

Dataverse（Microsoft Dataverse）のデータを大量に取得する場合、
1 回のクエリで返せる件数には上限があります。
Learn によると、最大 5,000 件までです。

したがって、大量データを扱う際は
複数ページに分けて取得する「ページング」処理が必須になります。

Microsoft Learn の記事では、このページングを FetchXML で行う方法を
C# SDK（.NET）と Web API の両方で示しています。

ページングが必要となる現場シナリオ

近畿さんのようなケースでよくある悩みは次の通りです。

  • 大量データの取得でタイムアウトする

  • キャンバスアプリのギャラリーに一度に読み込みすぎてパフォーマンスが落ちる

  • バッチ処理などで 10 万件以上を順番に読みたい

こうした場面で、FetchXML のページングは現場の安定運用を支える重要な技術になります。

ページング処理の基本メカニズム

Learn に示されている FetchXML のページングは 次の 3 つで構成されます。

  1. page（ページ番号）

  2. count（1 ページあたりの件数）

  3. paging-cookie（次ページ取得に必要なトークン）

paging-cookie がポイントで、
毎回サーバーが返してくる「次にどこから取得するか」の印です。

Learn の例（C# SDK の場合）

Microsoft Learn の記事では、.NET の SDK を使ったページングの実装例が示されています。

▼ 重要ポイント

  • RetrieveMultiple リクエストに FetchXML を設定

  • 結果から paging-cookie を取り出し、次の FetchXML に挿入

  • 次ページがある場合は MoreRecords が true になる

この記事はサンプルコードを Learn に沿って説明する形式ですが、コード自体は転載できないため仕組みと動きに特化して解説します。

Web API の場合

Web API では XML ではなく
URL に FetchXML をエンコードして渡す方式になります。

Learn の記事では、Web API のレスポンスに
次ページ URL が含まれているため、それをそのまま呼べばよい
という動作が説明されています。

SDK との違いは、SDK は paging-cookie を埋め込む必要がある一方、
Web API は “続きの URL が返ってくる” という点です。

ページングの注意点（Learn ベース）

Learn 記事に明記されているポイントを整理します。

● 5,000 件制限

1 クエリで取得できる件数は最大 5,000 件。

● ページングを正しくしないとデータが欠落する

paging-cookie を使わずに page だけ増やすと
重複や抜けが発生するリスクがある。

● ソート順が必須

ページング利用時、order（Ascending/Descending）を必ず指定しなければならない。
これは Dataverse の動作の一貫性を保つため。

● 最後のページ判定

MoreRecords=false で終了を判断すること。

3. 実務で欠かせない理解ポイント

なぜ paging-cookie が重要なのか

paging-cookie は「次のページがどこから始まるか」を確実に示すため、
データが更新された環境でも安全にページングできます。

page だけ変えると危険な理由

記事では明言されていますが、page=1→2→3… と指定するだけでは
データの追加・削除が発生した場合に整合性が崩れます。

Web API の方が実装が容易なケースもある

SDK では cookie を毎回 XML に埋め込む必要がありますが、
Web API では次ページ URL をそのまま呼べるため、
Azure Functions や外部アプリでは Web API の方が楽な場合があります。

4. 実務に即した活用例

活用シナリオ 1：大量データのレポート生成

  • 月次レポートで 数万件以上のデータを順次集計

  • FetchXML のページングで安定的に全件を取得できる

活用シナリオ 2：データ移行・ETL 処理

  • Dataverse から別システムへ移行

  • 5,000 件ずつ確実に読み込む

活用シナリオ 3：キャンバスアプリの高速化

  • 最初の 1 ページだけ表示

  • ページングで必要なときだけ追加読み込み

明日から試せる行動例

  • SDK／Web API のどちらでページングするか検討する

  • 既存の FetchXML クエリに order 要素があるか確認

  • paging-cookie を使ったループ処理をサンプルとして試す

5. まとめ

この記事では、Microsoft Learn
“Page results with FetchXML”
にもとづき、FetchXML のページングの仕組みを実務目線で解説しました。

今日の持ち帰りポイント

  • Dataverse では 1 回で 5,000 件までしか取得できない

  • 大量データはページング必須

  • paging-cookie を使うことでデータの整合性が保たれる

  • Web API と SDK では実装方法が異なる

  • ソート順（order）の指定は必須

特に、大規模データを扱う企業システムでは、
ページングは「必須の基礎技術」です。
近畿さんのように現場で苦労している方ほど、
Learn の内容を正しく理解することで運用が安定していきます。

※ この記事についてのご質問は、「こちら」からお願いします。

いいなと思ったら応援しよう！