
Power AppsのFilter・Search・LookUpは、どれもデータを絞り込む関数です。ただし返り値の型と得意な使い方が違うため、場面によって使い分ける必要があります。
3つの関数の根本的な違い
返り値の型がそれぞれ違う
最も重要な違いは、何を返すかです。Filter と Search はどちらも条件に合う複数のレコードをテーブル(表)として返します。LookUp は条件に一致した最初の1件だけをレコードとして返します。
この差が使い分けの基本になります。ギャラリーの Items に設定するなど複数件を一覧表示したい場合は Filter か Search を使います。1件の特定レコードの特定列の値を取り出したい場合は LookUp を使います。
| 関数 | 返り値 | 件数 | 主な使い道 |
|---|---|---|---|
| Filter | テーブル(Table) | 0件以上 | ギャラリーの一覧表示・絞り込み |
| Search | テーブル(Table) | 0件以上 | テキスト検索ボックスとの連携 |
| LookUp | レコード(Record) | 最大1件 | 特定レコードの値を取得・Patchの対象指定 |
LookUp の返り値はテーブルではなくレコードなので、LookUp の結果をギャラリーの Items に設定しようとするとエラーになります。これは初心者がよくはまるポイントです。
委任(delegation)の対応状況も違う
データが大量にある場合に気にしなければならない委任の可否も、3つの関数で異なります。委任の詳細は委任の警告についての記事で解説していますが、簡単にいえば委任できないとデータが500件(最大2000件)しか取得できなくなります。
| 関数・条件 | SharePoint | Dataverse |
|---|---|---|
| Filter(=、<、>、StartsWith) | 委任可能 | 委任可能 |
| Filter(in、Mid、Left) | 委任不可 | 一部可能 |
| Search | 委任不可 | 委任可能 |
| LookUp(=、<、>) | 委任可能 | 委任可能 |
SharePointリストを使っているなら、Search は委任できないと覚えておくと安全です。件数が多くなる可能性があるデータソースで Search を使うと、500件以降のデータが検索に引っかからなくなります。
Filter関数の使い方
基本の書き方
Filter はデータソースと条件式を渡すだけです。
// ステータスが「申請中」のレコードだけを返す
Filter(申請リスト, ステータス = "申請中")
// 自分が申請したレコードだけを返す
Filter(申請リスト, 申請者 = User().DisplayName)
// 複数条件(AND)
Filter(申請リスト, ステータス = "申請中" && 申請者 = User().DisplayName)
&&(アンパサンド2つ)で AND 条件、||(パイプ2つ)で OR 条件を書けます。SharePointリストで等号や比較演算子を使う場合は委任が成立するので、データ件数を気にせず使えます。
テキスト入力と組み合わせた絞り込み
ギャラリーに絞り込み検索を実装する場合、Filter と StartsWith の組み合わせが定番です。
// タイトルの前方一致で絞り込む(SharePointで委任可能)
Filter(申請リスト, StartsWith(タイトル, 検索テキスト.Text))
テキスト入力が空のときは全件表示したい場合は、条件を追加します。
Filter(
申請リスト,
IsBlank(検索テキスト.Text) || StartsWith(タイトル, 検索テキスト.Text)
)
テキスト入力欄が空のとき(IsBlank)は全件表示し、値が入っているときは前方一致で絞り込むという書き方です。このパターンは実務で非常によく使います。
Search関数の使い方
複数列をまとめて検索できる
Search が Filter と異なる点は、複数の列をまとめてあいまい検索できることです。タイトルと担当者名のどちらに検索ワードが含まれていても一発で拾いたい、という場合に便利です。
// タイトルと担当者名の両方から部分一致で検索
Search(申請リスト, 検索テキスト.Text, "タイトル", "担当者名")
列名を文字列(ダブルクォーテーション)で渡すのが Filter との大きな違いです。複数列を指定するときはカンマで並べます。
SharePointでSearchを使うときの注意
繰り返しになりますが、SharePointリストに対してSearchを使うと委任の警告が出て、500件しかデータを取得できません。データ件数が少ないアプリや、コレクションに取り込んだデータに対してSearchを使うのであれば問題ありません。SharePointリスト直接に対して Search を使う場合は、件数の上限を意識した設計にしましょう。
個人的には、SharePointリストを使うときは原則 Filter + StartsWith で代替できないか先に検討します。部分一致の検索どうしても必要な場合は、OnVisible で ClearCollect してコレクションに落としてから Search するという回避策を使っています。
LookUp関数の使い方
1件のレコードまたは列の値を取得する
LookUp は条件に合う最初の1件を返します。テーブルではなくレコードを返すため、特定の列の値を直接取り出すことができます。
// IDが一致するレコードの「担当者名」列を取得
LookUp(申請リスト, ID = 選択ID, 担当者名)
// 3番目の引数で取り出す列を指定できる
LookUp(マスタリスト, 部署コード = ドロップダウン1.Selected.Value, 部署名)
3番目の引数で「どの列を返すか」を指定できます。省略するとレコード全体を返しますが、値だけが欲しいときは列名を指定したほうがシンプルです。
Patchと組み合わせた更新処理
LookUp の大事な使い道がもう1つあります。Patch 関数で更新対象のレコードを特定するときに使います。
// ギャラリー外から特定レコードを更新する
Patch(
申請リスト,
LookUp(申請リスト, ID = gv_SelectedID),
{ステータス: "承認済み"}
)
グローバル変数 gv_SelectedID に保存している ID と一致するレコードを LookUp で見つけ、そのレコードを Patch で更新するパターンです。Patch関数の使い方と組み合わせると、ギャラリーから選択したレコードを別の画面で編集・更新するという設計が実現できます。
条件に一致するレコードがない場合
LookUp は一致するレコードが存在しない場合、Blank(空値)を返します。その後の処理で LookUp の結果を使うときは、IsBlank で存在チェックを入れるほうが安全です。
If(
IsBlank(LookUp(申請リスト, ID = gv_SelectedID)),
Notify("対象のレコードが見つかりませんでした", NotificationType.Warning),
// 更新処理を実行
Patch(申請リスト, LookUp(申請リスト, ID = gv_SelectedID), {ステータス: "承認済み"})
)
少し冗長に見えますが、現場アプリでは複数人が同時に操作する可能性があります。誰かが削除した後に別の人が承認ボタンを押すといった事態も起こりえるので、このチェックは入れておいて損はありません。
3つの関数を使い分ける判断フロー
まとめとして、どの関数を選ぶかの判断基準を整理します。
- 複数件を一覧表示したい → Filter または Search
- 1件のレコードまたは特定列の値を取得したい → LookUp
- 条件が等号・比較・StartsWith で済む → Filter(SharePointでも委任可能)
- 複数列をまとめてあいまい検索したい → Search(ただしSharePointでは件数に注意)
- Patchで更新対象を指定したい → LookUp
どれが正解というより、状況によって組み合わせて使うものです。ギャラリーの Items に Filter をかけて表示しつつ、承認ボタンでは LookUp + Patch で更新する、というパターンが実務では一番多いと思います。
まとめ
Filter・Search・LookUp の最大の違いは、返り値がテーブルかレコードかです。複数件の表示には Filter か Search、1件の取得や Patch の対象指定には LookUp。これを基本に使い分けましょう。
SharePointリストを使うなら委任の問題も頭に入れておく必要があります。Search は件数が多いデータソースには向かないので、Filter + StartsWith で代替できないか先に考えるクセをつけるといいです。3つの関数が使いこなせると、Power Appsでのデータ操作がぐっと楽になります。