委任問題を知っているだけでは足りません。どの回避策を選ぶか、そしてデータソースをどのタイミングで移行するか、その判断基準を持っているかどうかが、アプリの品質を左右します。
大きなリストはPower Appsで使えない は誤解
10,000件のSharePointリストがあるとき、Power Appsでは使えないと思っている方がいます。これは半分正解、半分間違いです。委任問題は関数の問題であって、リストのサイズの問題ではありません。
Filterのように委任できる関数を使えば、10,000件のリストでも問題なく動きます。ギャラリーをスクロールし続ければ全件にアクセスすることも原理上は可能です。問題が起きるのは、Search関数やDistinctのように委任できない関数を使ったときだけです。大きなリストが悪いのではなく、非委任関数と大きなリストの組み合わせが問題だということを最初に押さえておきましょう。
委任の定義を再確認する
委任とは、Power Appsがデータの絞り込みや処理をデータソース側に任せることです。先頭500件をブラウザに送り、ブラウザ側のJavaScriptで検索処理が行われます。
仕組みの詳細については委任の基礎とCollectionの罠をまとめた記事で解説しています。この記事では症状の説明は最小限にとどめ、どう対処するかに絞って話を進めます。
500件の意味するもの
非委任クエリの上限は500件（デフォルト値）です。ただしこれは、条件に一致する先頭500件という意味ではありません。リスト全体の先頭500レコードのうち、条件に一致するもの、という意味です。この違いは重要です。
SharePointのリストはレコードが追加された順に並んでいます。新しいレコードはIDが大きく、末尾に積み上がっていきます。リストが育つほど、最近登録されたデータは先頭500件から遠ざかります。Search関数で検索しても最新の申請が見つからない、という症状は、この構造から必然的に生まれます。リストを長期運用するほど深刻化する、構造的な問題です。
警告が出ない非委任の罠
Distinctは青線が出ないまま非委任で動く
Power Appsの編集画面では、委任できない関数に青線や黄色い三角マークが付きます。ただし、Distinctはこの警告が出ないまま非委任で動作します。警告がないから大丈夫、と思っていると痛い目を見ます。
Distinctでドロップダウンの選択肢を生成しているとき、実際には先頭500件にしか存在しない種類しかリストアップされません。新しいカテゴリを追加しても選択肢に出てこない、という問題が静かに進行します。CollectionもClearCollect段階で委任を受けるため、同様の問題があります。青線が消えた＝解決した、は間違いです。
回避策① StartsWithを使う
Search関数の代わりに、Filter内でStartsWith関数を使う方法です。StartsWith(列名, "検索文字") はSharePointで委任可能なため、10,000件のリストでも正しく絞り込めます。
// Search関数（委任不可）
Search(Mega, TextInput1.Text, "AnimalName")
// StartsWithに置き換え（委任可）
Filter(Mega, StartsWith(AnimalName, TextInput1.Text))StartsWithは前方一致です。入力した文字列で始まるレコードを返します。検索ワードが先頭から一致していればよい要件、たとえば名前の先頭文字で絞り込む場合はこれで十分です。
一方で、文字列の途中に含まれるものも検索したい場合にはStartsWith単体では対応できません。たとえば田中太郎を太郎で検索してヒットさせたいケースは、StartsWithでは拾えません。この場合は回避策②を使います。
回避策② FilterとSearchをネストする
Filter（委任可）で先にレコード数を大幅に絞り込んでから、その結果に対してSearch（委任不可）を重ねる方法です。FilterがSharePointに仕事を投げてレコード数を減らすことで、Searchが処理する対象を500件以内に収めることを狙います。
// FilterとSearchのネスト
Search(
Filter(Mega, AnimalColor = Dropdown1.Selected.Value),
TextInput1.Text,
"AnimalName"
)たとえばFilterで絞り込んだ後のレコードが400件以内であれば、そこにSearch関数をかけても全件対象にできます。ただしFilter後のレコード数が500件を超える場合は、Search側でまた漏れが出る可能性があります。
この回避策は完全な解決策ではありませんが、Filter単体では物足りない場面、たとえばドロップダウンで絞り込んだ結果をさらにフリーワード検索したい場合に現実的な選択肢になります。Filterネストのより詳細な実装パターンについてはギャラリーの複合フィルター解説記事も参考にしてください。
回避策の使い分け基準
どちらの回避策を使うかは、要件によって決まります。以下の表を判断の基準にしてください。
| 要件 | 推奨回避策 |
|---|---|
| 名前の先頭文字・コードの前方一致検索 | ① StartsWith |
| 複数列にまたがるフリーワード検索 | ② Filter＋Searchネスト |
| どちらも使えない（部分一致・大量データ） | データソース移行を検討 |
前方一致で十分な要件であれば①、複数列をまとめて検索したいなら②、というシンプルな判断フローです。②で対応しきれない場合はデータソース自体を変えることを考える必要があります。
データソース移行の判断基準
DataverseやSQL ServerはSearch関数も委任できます。SharePointで委任問題に悩んでいるなら、データソースの移行が根本的な解決策になります。ただしDataverseはライセンスコストが別途かかるため、費用対効果のトレードオフが必要です。
移行を検討するタイミングの目安として、私はいくつかの条件を持っています。リストが継続的に成長して1万件を超える見込みがある。SearchやDistinctを使わざるを得ない要件が複数ある。アプリが意思決定に使われる重要な業務に組み込まれている、このいずれかに当てはまるなら、移行コストを払う価値があります。反対に、使用者が少なく件数も増えない運用なら、SharePointのまま回避策で対応する判断もあります。データソース別の委任対応状況は以下の表にまとめています。
| 機能 | SharePoint | Dataverse | SQL |
|---|---|---|---|
| Filter | ◎委任可 | ◎委任可 | ◎委任可 |
| Search | ✗委任不可 | ◎委任可 | ◎委任可 |
| Distinct | ✗委任不可 | 要確認 | 要確認 |
| StartsWith | ◎委任可 | ◎委任可 | ◎委任可 |
Pro Tip｜本番投入前の委任チェックリスト
アプリをリリースする前に、以下の項目を必ず確認するようにしています。委任限界値を1にするテスト手法については委任の基礎記事で紹介しているので、そちらを参照してください。
| 確認箇所 | チェック内容 |
|---|---|
| ギャラリー | Filter条件は委任可能な関数だけで構成されているか |
| ドロップダウン | 選択肢の生成にDistinctを使っていないか（使っている場合は件数が少ないか） |
| 検索ボックス | SearchをStartsWith or Filterネストに置き換えられているか |
| コレクション | ClearCollectのデータソースが500件を超えないか |
委任の警告はメーカー画面にしか出ません。ユーザーは何も知らないまま不完全なデータを見続けます。回避策を選んだ根拠と、その限界をドキュメントに残しておくことが、責任ある開発者の習慣だと思っています。
まとめ
委任の回避策は、要件と現実のデータ量に合わせて選ぶものです。StartsWithで済むなら①、複合条件が必要なら②、それでも足りないならデータソースの移行を検討する、というフローで考えると整理しやすくなります。
委任を正しく理解して設計に反映させることが、長く使えるアプリを作る上で欠かせません。地道な確認の積み重ねが、ユーザーへの信頼につながります。楽しみながら開発を続けていきましょう。
