委任を知らずにアプリを作ることは、ユーザーに見えないバグを仕込むことと同じです。Power Appsの委任（Delegation）は、すべてのアプリ開発者が最初に理解しておくべき仕組みです。
委任を無視したアプリが危険な理由
委任の警告（黄色い三角マーク・青い下線）はPower Appsの編集画面にしか表示されません。アプリを使うユーザーの画面には何も出ません。検索しても結果が少ない、一覧に出ないデータがある、選択肢に新しいカテゴリが出てこない。こうした症状がユーザー側で静かに起き続けます。
社内の承認フローや日報管理など、意思決定に使われるアプリで委任問題を放置すると、見えていないデータに基づいて判断を下すことになります。作った本人は気づかないまま、ユーザーだけが不完全な情報を見続ける状況は、無責任なアプリと言わざるを得ません。私が社内でアプリ開発を教えるとき、委任の話を最初にする理由はここにあります。
委任とは何か
委任とは、Power Appsがデータの処理をデータソース側に丸投げすることです。丸投げできる＝委任できる、丸投げできない＝委任問題が発生する、というのが基本の構図です。
Filter関数はSharePointに仕事を投げられます。SharePointサーバーが絞り込みを実行して結果を返すので、10万件のリストでも正しく動きます。一方、Search関数はSharePointが処理を断ります。先頭500件だけブラウザに送られ、ブラウザ上のJavaScriptで検索が走ります。残りのデータは最初から存在しない扱いです。
Power Appsが何もしない＝良いこと、というのが委任の核心です。直感に反しますが、この考え方を掴むと設計の判断が大きく変わります。委任の仕組みと、データが消える具体的な症状については委任とデータの欠落を解説した入門記事で詳しく扱っています。
委任問題が引き起こす3つの症状
ギャラリーの件数不足
ギャラリーはデフォルトで先頭100件しか読み込みません。Search関数を使った検索では、先頭500件の中からしか結果を返しません。リストが成長するほど、新しいデータが検索対象から外れます。数年問題なく動いていたアプリが、ある時期から最新の申請を表示しなくなる、というのが最もよくある症状です。
SearchとDistinctの無警告バグ
Search関数は委任警告が表示されますが、Distinctは警告が出ません。Distinct(リスト, 列名) でドロップダウンの選択肢を生成していると、先頭500件にしか存在しない値しかリストアップされません。新しいカテゴリを追加しても選択肢に出てこない、という問題が警告なしで進行します。
Collectionに逃げても解消しない
ClearCollectでSharePointのデータをコレクションに入れれば委任問題が解消する、という誤解が広まっています。ClearCollect自体が委任の対象なので、先頭500件しかコレクションに入りません。委任警告が消えることで解決したと勘違いしやすい、最も危険なパターンです。コレクションの使い方と委任の関係も参照してください。
主な回避策の概観
委任問題への対処は大きく3つです。それぞれの詳細は委任の回避策を深掘りした記事にまとめています。
StartsWithを使う
Search関数の代わりに、Filter内でStartsWith(列名, 検索文字) を使う方法です。SharePointで委任可能な前方一致検索になります。名前の先頭文字で絞り込む要件であれば、これで十分です。
FilterとSearchをネストする
委任できるFilterで先にレコード数を500件以内に絞り込んでから、その結果にSearchをかける方法です。完全な解決策ではありませんが、ドロップダウン選択後にフリーワード検索するような場面では現実的な選択肢です。FilterとSearchの使い分け基礎も参考になります。
データソースを移行する
DataverseやSQL ServerはSearch関数も委任できます。リストが1万件を超える見込みがある、意思決定に使われる重要なアプリ、SearchやDistinctを避けられない要件がある。このいずれかに当てはまるなら、データソースの移行が根本的な解決策になります。委任対策はアプリのパフォーマンス改善とも直結するので、Power Appsのパフォーマンス改善記事も合わせて読むと判断の材料が増えます。
データソース別の委任力マップ
どのデータソースが何を委任できるかを整理します。移行を検討するときの参考にしてください。
| 機能 | SharePoint | Dataverse | SQL |
|---|---|---|---|
| Filter | ◎委任可 | ◎委任可 | ◎委任可 |
| Search | ✗委任不可 | ◎委任可 | ◎委任可 |
| Distinct | ✗委任不可（無警告） | 要確認 | 要確認 |
| StartsWith | ◎委任可 | ◎委任可 | ◎委任可 |
ユーザーフィルターへの橋渡し
委任を正しく理解した上で次に必要になるのが、ログインユーザーのデータだけ表示するフィルターです。自分の申請だけ表示する、自分宛の承認依頼だけ表示するといった要件は、ほぼすべてのビジネスアプリで発生します。
SharePointではCreated By.Emailで組み、DataverseではAzure AD Object IDで合わせるのが基本です。実装の全パターンはユーザーフィルターの実装ガイドにまとめています。
このクラスターの読み方
委任を初めて知る方はまず入門記事から読み始めることをすすめます。症状の確認と仕組みの理解が先にあると、回避策の話が腹落ちしやすくなります。
- 委任の仕組みとCollectionの罠を知りたい → Power Apps でデータが足りない原因は委任にある
- 回避策の選び方・データソース移行の判断基準を知りたい → Power Apps 委任 完全理解ガイド
- ログインユーザーのデータだけ表示したい → Power Apps でユーザーフィルターを実装する
- 委任警告の表示の意味が分からない → 委任の警告とは？意味と対処法
まとめ
委任はPower Appsにおける設計の根幹です。知っていると知らないとでは、アプリの信頼性に大きな差が出ます。症状を知り、原因を理解し、要件に合わせて回避策を選ぶ。この流れを身につけておくことが、ユーザーに使ってもらえるアプリを作る上で欠かせません。
Power Apps全体の開発フローについてはPower Apps開発の全体マップも参照してください。市民開発とはこういう地道な積み重ねだと、個人的には思っています。
