Power Apps の検索が部分一致しない・複数条件で絞れない — Dataverse で本番で踏んだ6つの落とし穴

Dataverseで業務アプリを作っていると、必ずユーザーから言われる言葉があります。

「これ、もっとサクッと検索できないんですか？」

Excelなら部分一致のオートフィルターが当たり前。Googleなら何を打っても近いものが出てくる。SharePointでもMicrosoft Searchがそれなりに賢く拾ってくれます。そういう感覚でDataverseに触ると、まず期待が裏切られます。

しかも、表面的なテキスト検索より遥かに深刻な問題があります。条件を組み合わせて絞り込む「条件検索」が、モダンUIでは事実上できないこと。そして、それを回避しようとして作った**「重いビュー」がそもそも開かなくなる**こと。

この記事では、Dataverseの「検索」周りで実際に踏んだ落とし穴を、致命度の高い順に共有します。

落とし穴1: 複数条件で検索できない（一番やばい問題）

最初に書きます。これが一番やばい問題です。

かつてのDataverseには「Advanced Find（詳細検索）」という強力な機能がありました。AND/OR、入れ子条件、関連テーブル経由の検索、保存済みビュー化 — Excelのオートフィルターを遥かに超える条件検索が可能でした。業務システムの検索要件はほぼここで吸収できていました。

モダンUIの時代になり、この機能は事実上、表舞台から消えました。リボンの目立つ位置から削除され、「フィルターを編集」ペインという別UIに置き換えられました。エンドユーザーが直感的に到達できる導線ではありません。

「複数条件で絞り込みたい」というのは業務システムでは当たり前の要求です。

契約金額が100万以上、かつステータスが受注済み、かつ営業担当が田中、かつ受注日が今月

こういう絞り込みを、現場は毎日やりたいわけです。モダンUIでこれを再現しようとすると、現実的な選択肢は2つしかありません。どちらも罠です。

回避策A: ビューに列を大量追加して列ヘッダーフィルター

ビュー定義に検索したい列を全部足しておいて、エンドユーザーには列ヘッダーフィルターで絞ってもらう作戦です。

これ、列が少ないうちはそれなりに動きます。問題は、列を追加するほどFetchXMLの取得カラムが増え、レスポンスが目に見えて遅くなることです。Lookup列を追加するとさらに重くなります（表示用に関連テーブルへのJOINが発生するため）。10列を超えたあたりから明らかに体感が悪化し、20列を超えるとユーザーから「画面が重い」と言われ始めます。

レコード数が増えると致命的です。データが積み上がるにつれて、ビューの初期表示で待たされるようになります。そして最終的には、ビュー自体が開かなくなります。これは落とし穴2で詳しく書きます。

列ヘッダーフィルター自体にも限界があります。「含む」検索が選択肢に出ない列がある、日付の選択肢が限定的、複数列をまたいだAND/OR条件は組めない、フィルター状態は画面を離れると保持されない。「列をたくさん並べてフィルターで絞る」というデザインは、Dataverseに最適化されたパターンではありません。

回避策B: 「フィルターを編集」ペイン

モダンUIの右側に出る「フィルターを編集」ペイン。ここで条件を組めば、AND/OR・入れ子・関連テーブル経由まで、旧Advanced Findと同等のことができます。機能的には残っています。

ただし学習コストが高すぎます。

エンドユーザー（経理、営業、製造の現場の人）に「ここをクリックして、グループを追加して、関連エンティティを選んで、条件を入れて…」を教えても、定着しません。「Excelのオートフィルターと違う」「前回と同じ条件を出すのが面倒」「保存できるけどどこから呼び出すんだっけ」 — 結局、現場では使われなくなります。

パワーユーザー1〜2人が代行する文化が生まれ、その人がボトルネックになります。検索のために特定の人にチャットする運用、見たことありませんか。

結論: 条件検索が中心なら標準UIに乗せない

「条件検索ができない」というのは、Excel・kintone・Salesforceに慣れたユーザーには信じられない話です。しかしDataverseのモダンUIは、現時点ではここが弱い。

業務要件で複数条件検索が中心になるなら、標準UIに乗せず、最初からカスタム検索画面（PCFコントロールまたは外部Webアプリ連携）を作る判断が必要です。後から「やっぱり検索画面作ります」となると、開発工数が倍になります。

落とし穴2: 重いビューはそもそも開かない（致命傷）

落とし穴1の回避策Aで触れたとおり、列を増やしすぎたビューはレスポンスが劣化します。が、本当の問題はその先にあります。

Dataverseのビューは、画面を開いた瞬間にFetchXMLを実行します。最初の表示の前に、まずクエリが走るわけです。このクエリが重いと何が起きるか。

初期表示まで延々と「読み込み中…」のスピナーが回る
タイムアウトに達してエラーで止まる
最悪、画面が固まってブラウザのタブが応答しなくなる

つまり、ユーザーはデータに辿り着けません。 「重いから検索しづらい」ではなく、「そもそも画面が開かない」のです。検索どころの話ではありません。

これが**デフォルトビュー（アプリのホームに表示されるビュー）**で発生すると、悲惨です。アプリを起動した時点で固まる。データの一覧すら見えない。「業務システムが起動しない」と全社的にクレームが来ます。

なぜ気づかれにくいか

この問題、開発時はほぼ気づきません。理由は単純です。

テストデータが少ない: 開発環境のレコード数が100件程度だと、どれだけ重いビューでも数秒で開く
開発者の端末が速い: 開発者のマシン・ネットワーク環境は本番ユーザーより恵まれていることが多い
本番投入直後はまだ動く: 移行データを入れた直後はレコードが少なく、運用が進んで初めて症状が出る

遅効性の毒です。本番投入から数ヶ月〜半年後、レコードが積み上がってきたあたりで突然「最近システムが重い」と言われ始め、追跡してみると重いビューが原因だった、というパターン。劣化が顕在化するタイミングはテーブル構成（列数、Lookup、Calculated/Rollup列、インデックスの有無）に強く依存するので、件数の閾値は一概には言えません。

何がビューを重くするのか

経験上、以下が組み合わさると一気に重くなります。

列数が多い（特にLookup列、Calculated/Rollup列）
関連テーブル経由のソート（FetchXMLのlink-entity + order）
Calculated/Rollup列でのフィルタや並び替え（インデックスが効かない）
デフォルトフィルターが緩い（全件返してくる）
ページング無視のCSVエクスポートをトリガーにする運用

特に「Lookup列を10個以上並べた一覧ビュー」と「ロールアップ列でのソート」は要警戒です。

対策

設計段階で次のルールを徹底します。

ビュー定義はシンプルに保つ: 列数は本当に必要なものに絞る、Lookup列は最小限
デフォルトフィルターを必ず入れる: 「自分が担当」「直近30日」「アクティブのみ」など、初期表示の範囲を絞る
ソートはインデックス対象列で: Calculated/Rollup列でソートしない
重い分析用ビューは別途用意: 日常閲覧用ビューと、月次集計用ビューを分ける
本番相当のデータ量でテストする: 開発時に運用想定のレコード件数を流し込んで開いてみる。これをやらないと本番で爆発します

そして、業務要件として「全件を縦横無尽に絞り込みたい」というニーズがあるなら、それはビューで吸収するのではなく、PCFカスタムコントロールか外部Webアプリで検索画面+一覧UIを作るべきです。標準ビューに無理をさせるのは設計の負け筋です。

落とし穴3: 簡易検索（Quick Find）は部分一致しない

モデル駆動アプリのビュー画面右上にある検索ボックス。あれがQuick Findです。多くの人が「テキストを入れたら部分一致で検索してくれる」と思っています。

違います。前方一致です。

「ABC商事」を「商事」で検索しても、出てきません。「ABC」で検索するか、ワイルドカード * を頭に付けて *商事 と打つ必要があります。エンドユーザーがそんなこと知るわけがありません。「検索しても出ない」「使いにくい」と言われ、結局Excelに書き出して検索する文化に逆戻りします。

しかも、検索対象になる列はテーブル定義で「Quick Findビュー」に指定した列だけです。新しく列を追加して「これも検索対象にしたい」と思ったら、ビュー定義を編集して検索可能列に追加する必要があります。これを忘れると「なぜこの列で検索できないんですか」案件が発生します。

そして全角半角・大文字小文字の揺れ。「ＡＢＣ」と「ABC」は別物として扱われます。日本語の業務データでこれは致命的です。住所、会社名、商品コード — どれも全角半角が混在しがちな列ばかりです。

落とし穴4: Dataverse Searchは「即時反映」じゃない

「Quick Findが微妙なら、Dataverse Search（旧Relevance Search）を有効にすればいい」 — そう思った時期が私にもありました。

Dataverse Searchは確かに高機能です。複数テーブル横断検索、関連度スコア、形態素解析、添付ファイル内検索。期待は膨らみます。

ただし:

環境管理者が明示的に有効化しないと使えません
テーブルごとに検索対象として登録する必要があります
検索対象列も個別に指定しないと検索されません
インデックスへの反映にタイムラグがあります（数分〜十数分）

レコードを作って「さあ検索」とやっても、最初の数分は出てきません。エンドユーザーが「いま作ったのに出ない」とクレームを上げます。「インデックスの反映待ちです」と説明しても、当然ながら納得してもらえません。

さらに日本語の形態素解析が微妙です。日本語は膠着語で、複合語や活用が多い言語です。「採番エンジン」で検索したとき「自動採番」が引っかかったり引っかからなかったり、「キャベツ」と「きゃべつ」が別扱いだったり、安定しません。表記揺れに強い検索体験を期待すると、ほぼ確実に裏切られます。

そして決定的なのは、Dataverse Searchは「フリーテキスト検索」であって「条件検索」ではないことです。落とし穴1で書いた「金額100万以上 AND ステータス受注済み」のような絞り込みには使えません。検索の万能薬ではないのです。

落とし穴5: Lookupの検索対象は「簡易検索ビュー任せ」

Lookupフィールドにカーソルをあててテキストを入力すると候補が出ます。これも検索です。そして罠です。

Lookupの検索対象列は、参照先テーブルの プライマリ列＋簡易検索ビュー（Quick Findビュー）の「Find Columns」に追加された列 で決まります。つまり、簡易検索ビューの設定がそのままLookupの検索体験を左右します。

ここに罠があります。新しい列をテーブルに追加しても、簡易検索ビューのFind Columnsに足さない限り、Lookupでもその列で検索できません。「顧客コード列を追加したのに、Lookupで顧客コードを打っても候補が出ない」 — 一見謎の挙動ですが、原因はLookup側ではなく簡易検索ビュー側にあります。

そして検索の挙動は 前方一致 です。Quick Findと同じ罠で、* を頭に付けないと部分一致になりません。エンドユーザーがLookupで部分一致検索を試みて「候補が出ない」とハマるのは、ここが原因です。

「Lookupで検索できない」案件は本当に多いです。設計時に簡易検索ビューのFind Columnsを意識して整備しているプロジェクトは、私の経験上、半分以下です。

落とし穴6: APIで`contains`を使うとパフォーマンスが死ぬ

Power AppsやPluginから検索ロジックを実装するとき、contains 演算子を使いたくなります。SQLの LIKE '%text%' 相当の挙動です。

これ、インデックスが効きません。テーブルが小さいうちは気づきませんが、レコード数が増えるにつれてレスポンスが劣化します。本番で気づくのが定番のシナリオです。

回避策は begins-with（前方一致）に変える、またはDataverse Search APIを直接叩く。ただし、どちらもユーザーの「Excelみたいに検索したい」という期待には応えられません。

どう設計すべきか

ここまで読むと「Dataverseの検索、全部ダメじゃん」と思うかもしれません。実際、標準機能だけで日本企業の業務検索要件をすべて満たすのは無理だと私は思っています。

ただし、設計次第で大半はカバーできます。私たちが採用している方針はこうです。

場面	採用する手段
複数条件で絞り込み（条件検索）	PCFカスタムコントロールまたは外部Webアプリで自前の検索画面を作る（標準UIに頼らない）
一覧ビューの設計	列数を絞る + デフォルトフィルター必須 + 本番相当データでテスト
ビュー画面で雑に検索	Quick Find列を戦略的に設定 + ユーザーに `*` の使い方を教育
横断検索・あいまい検索	Dataverse Searchを有効化 + テーブル/列を計画的に登録
Lookupで検索	簡易検索ビュー（Quick Findビュー）の Find Columns に検索対象列を必ず追加
大量データの全文検索	Azure AI Search（旧Cognitive Search）連携

「標準の検索ボックスにすべてを期待しない」「ビューに何でも詰め込まない」。この2つが鉄則です。検索要件はヒアリング時に必ず洗い出し、どの手段で実装するかを設計段階で決めます。後付けで対応すると、ほぼ確実に泥沼化します。

特に条件検索が業務の中心にある場合、ビューに列を足してフィルターで凌ごうとしないこと。これは初期工数を惜しんで未来の自分を殺す典型パターンです。エンドユーザーが日常的に使う検索画面なら、最初からPCFや外部Webアプリで作り込んだほうが、開発工数も運用負荷も結果的に小さくなります。

Canvas Appを第一候補に挙げない理由

「条件検索画面ならCanvas Appで作ればいいじゃないか」と言われることがあります。私たちは長期運用を前提とするシステムではCanvas Appを第一候補としていません。理由は3つです。

ライセンスコスト: Dataverseを本格的に扱おうとするとPremium機能に踏み込みがちで、ユーザー単位の従量課金が地味に効きます
委任の罠: Canvas AppとDataverseの間には委任（Delegation）の制限があり、レコード数が増えると関数が正しく動かなくなる挙動が頻発します
低コード資産の保守性: コードレビュー・差分管理・テスト自動化が難しく、改修のたびに動作確認を全画面手動で回す羽目になります

短期PoCや、限定的なシナリオで完結する画面ならCanvas Appも選択肢です。が、業務システムの中核に据える検索画面なら、PCFや外部Webアプリのほうが結果的に運用コストが低くなります。

もう一つ重要なのが、エンドユーザーは「Excel・Google検索の体験」を基準にDataverseを評価するという点です。技術的に正しい挙動でも、期待値とズレれば「使えないシステム」と判断されます。ここのギャップ管理は、運用開始前のユーザー教育セッションでカバーするのが現実的です。

まとめ

Dataverseの検索は、Excel・Google検索・SharePoint Searchのような「とにかく賢く出してくれる」体験とはかけ離れています。

最大の問題は条件検索です。旧Advanced Findの強力さを失い、列追加+ヘッダーフィルターはFetchXMLを重くし、最終的にビューそのものが開かなくなる。フィルター編集ペインはエンドユーザーに難しすぎる。加えてQuick Findは前方一致、Dataverse Searchは反映タイムラグと日本語の精度、Lookupは簡易検索ビュー任せ、APIのcontainsは遅い。

「検索くらいできるでしょ」「ビューに列足せば何とかなるでしょ」と思って設計を後回しにすると、本番後に必ず火を吹きます。逆に、検索とビュー設計を最初から正面に据えて設計すれば、Dataverseは十分に戦える土俵です。

検索・ビュー設計で迷ったら、お気軽にご相談ください。標準機能・Dataverse Search・Azure AI Search・PCF・外部Webアプリの組み合わせを、業務要件から逆算して提案します。