商品は登録されているのに、利用者が目的のものへたどり着けない。そんな一覧ページでは、検索条件の数よりも、条件の分け方と見せる順番に問題があるかもしれません。絞り込み検索UIは、一覧を狭めるための部品ではなく、候補を比較できるところまで案内する仕組みです。
BtoBサイトでは、型式を知っている人と、用途や仕様から探す人とで必要な入口が異なります。検索窓だけでは前者に偏り、すべての条件を最初から並べると後者も選びにくくなります。まず利用者の探し方を分け、よく使う条件から選べるようにします。
この記事では、チップ、アコーディオン、モーダル、サイドバーの使い分けをはじめ、検索・絞り込み・並び替えの役割、AND・OR条件、0件時の案内、URLへの条件保持まで解説します。製品検索、物件検索、求人検索、管理画面のどれを設計する場合にも使える判断基準をまとめました。
絞り込み検索UIを考えるとき、最初に決めるのは、チップ型にするか、アコーディオン型にするかではありません。利用者が何を手がかりに探し始めるのかを確認します。
同じ製品検索でも、探し始める条件は次のように異なります。
これらを同じUIだけで扱うと、探し方と画面の流れが合いません。「用途から探したい」人に細かな技術条件を何十項目も見せれば、最初の選択ができません。反対に「型番が分かっている」人に用途別の入口しか用意しなければ、目的の製品まで余分な操作が必要です。
絞り込み検索UIの設計は、条件を並べる作業ではありません。利用者の探し方に合わせて、検索窓、カテゴリー、絞り込みの入口を分ける作業です。
絞り込み条件を表示する場所と方法には、主に次の4つがあります。条件の数、説明の必要性、利用端末、結果を見ながら変更する頻度によって使い分けます。
短い言葉で意味が分かる条件を、一覧の近くに出す方式です。「色」「サイズ」「価格帯」「用途」などに向き、スマートフォンでも指で選べます。
UIイメージ：チップ型フィルター
選択中の条件がその場に残るため、軽い絞り込みや、試しながら探す場面と相性が良いUIです。
一方で、条件が多い場合や、用語の説明が必要な場合は向きません。 チップを大量に並べると、それだけで圧迫感が出ますし、何を選べばよいか分からなくなることもあります。
カテゴリが多い検索や、条件をグループごとに見せたいときによく使われる方式です。 BtoBの製品カタログや部品検索で、条件を「基本仕様」「性能」「規格」などに分ける場合に適しています。
UIイメージ：アコーディオン式カテゴリー
条件数が多いときでも、意味の近いものをまとめて見せられるため、一覧の圧迫感を抑えやすい構成です。
ただし、閉じたままだと条件の全体像が見えにくくなるため、 閉じた状態でも内容を予想できるよう、「性能・仕様（12）」のように条件の種類や件数を見出しへ示します。
一覧画面を広く使いたいときや、条件数が多いときに相性の良い方式です。 特にスマホでは、絞り込み条件を別画面のように見せる方が使いやすいケースがあります。
UIイメージ：モーダル型フィルター
一覧画面を広く確保しながら、絞り込み条件をまとめて扱いたいときに向いています。
ただし、モーダルを閉じたあとに「何を選んだか」が見えにくいと使いにくくなります。 そのため、一覧側にも「選択中の条件」を表示しておきたいところです。
PCでよく使われる定番です。製品比較や一覧性が重要なページでは相性が良く、 条件を見ながら結果も同時に確認したい場合に便利です。
UIイメージ：サイドバー固定型
条件と結果を同時に確認できるため、何度も条件を変えて比較するページに向いています。
その反面、スマホではそのまま使いにくいため、モーダル型や折りたたみ型との併用を前提にした方が現実的です。
「条件が多ければモーダル、少なければチップ」という分け方だけでは、適切なUIを選べません。条件名を見ただけで意味が分かるか、説明や数値入力が必要かも確認します。
価格帯、用途、納期、サイズ、対応エリアなど、見た瞬間に意味が分かる条件は、隠さず前に出した方が使いやすくなります。 こうした条件は、選ぶこと自体の負担が小さいからです。
とくに検索の最初の一歩として使われやすい条件は、 モーダルの奥ではなく、一覧の近くに置いた方が操作されやすくなります。
技術製品、部材、化学品、医療機器、設備条件のある商材などでは、 条件名だけを見ても意味が伝わりにくいことがあります。
説明や分類がないと、利用者は条件の選び方を判断できません。条件の数を減らせない場合でも、よく使う条件と詳細条件を分け、用語の補足を付けることで選択しやすくなります。
絞り込み検索では、条件を選んだ後に「現在、どの条件が適用されているか」を見失わないようにします。
BtoBでは複数の条件を組み合わせることが多く、検索結果を別の担当者へ共有する場面もあります。選択中の条件を結果一覧の近くへ表示し、その場で解除できるようにします。
UIイメージ：選択中条件の表示
一覧側に条件を表示すると、結果が少ない理由と、候補を増やすために外す条件が分かります。
特に0件になったときは、選択中の条件と解除ボタンを結果メッセージの近くに置き、条件を最初から選び直さなくても候補を増やせるようにします。
絞り込み検索では、条件を変えて結果を見比べる操作が繰り返されます。反映に時間がかかる、更新のたびにページ上部へ戻る、詳細ページから戻ると条件が消えるといった動作は、比較を中断させます。
条件を変更するたびにページ全体を再読み込みせず、結果部分だけを更新する方法があります。
ただし、非同期更新にすれば十分とは限りません。読み込み中であることを表示し、更新が終わるまで同じ操作を重ねて受け付けないようにします。
結果一覧の途中で条件を変えたときにページ先頭へ戻ると、見ていた製品を探し直すことになります。PCとスマートフォンの両方で、更新後の表示位置を確認します。
詳細ページから一覧へ戻った場合も、条件、並び順、ページ位置を再現できると比較を続けられます。
既存の検索画面を改修する場合は、現在の検索ログを確認します。新規に作る場合も、公開後に同じ項目を記録できるようにしておきます。担当者の想定と、実際に使われる条件が一致するとは限らないためです。
次の項目を定期的に確認します。
利用されていない条件は、名称が分かりにくいのか、必要性が低いのかを調べます。多くの人が最初に選ぶ条件は上部へ移し、0件が多い組み合わせは条件の結び方や登録データを確認します。
ここまでで、利用者の探し方と画面上の見せ方を整理しました。次に、検索・絞り込み・並び替えの役割、条件に使う入力部品、AND・OR、0件時の動作を画面仕様として決めます。
画面だけを先に作ると、チップを複数選んだときの条件や、選択肢ごとの件数、戻る操作などが実装段階で決まることになります。次の各項目を、データの持ち方とあわせて確認します。
一覧ページでは、キーワード検索、カテゴリー、絞り込み、並び替えが同じ場所に置かれることがあります。しかし、それぞれが変えるものは異なります。
| 機能 | 利用者の目的 | 例 |
|---|---|---|
| キーワード検索 | 名称や型番など、分かっている言葉から探す | 製品名、品番、住所、案件名 |
| カテゴリー | あらかじめ決められた分類から対象範囲を選ぶ | 製品群、業種、地域、記事分類 |
| 絞り込み | 複数の条件を組み合わせ、表示対象を減らす | 価格、用途、規格、在庫、状態 |
| 並び替え | 対象件数は変えず、表示順を変える | 価格順、新着順、納期順、更新日順 |
並び替えを絞り込み条件のひとつとして見せると、件数が変わる操作なのか、順番だけが変わるのか分かりにくくなります。スマートフォンでは同じモーダル内に置く場合でも、見出しと確定ボタンを分けて役割を示します。
チップ型、モーダル型、サイドバー型は、条件全体をどこへ表示するかという構成です。その中で使う入力部品は、選択肢の数と選択方法から決めます。
| 条件の特徴 | 入力部品の候補 | 使用例 |
|---|---|---|
| 少数からひとつ選ぶ | ラジオボタン、選択カード、チップ | 新品・中古、受付中・終了 |
| 少数から複数選ぶ | チェックボックス、フィルターチップ | 用途、設備、対応サービス |
| 候補が多い | 検索付き選択、候補検索 | メーカー、型番、市区町村 |
| 最小値と最大値を指定する | 数値入力、範囲選択 | 価格、寸法、重量、処理能力 |
| 期間を指定する | 開始日・終了日、期間候補 | 公開日、納品日、予約日 |
| 有効・無効を切り替える | チェックボックス、スイッチ | 在庫ありのみ、受付中のみ |
プルダウンは画面を短くできますが、開くまで候補が見えません。頻繁に使う少数の条件は表へ出し、候補が多い条件や利用頻度の低い条件だけをプルダウンや詳細検索へ入れる方法が適しています。
複数選択できる絞り込みでは、同じグループ内と異なるグループ間で、条件をどのように結び付けるかを決めます。
一般には、同じ項目内の複数選択をOR、異なる項目同士をANDとして扱うことが多いものの、商品や業務によって正解は変わります。たとえば資格検索で「資格Aと資格Bの両方を持つ人」を探す場合は、同じ項目内でもANDが必要です。画面の印象から利用者が予想する動きと、実際の検索条件を一致させます。
条件を選ぶ前に該当件数が分かると、利用者は結果を予想しながら操作できます。「在庫あり（24）」「CE対応（8）」のように候補数を表示する方法があります。
結果が0件になった場合は、「該当する製品がありません」だけで終わらせず、解除できる条件を示します。
0件になる条件を最初から無効にする方法もあります。ただし、条件が存在すること自体を伝えたい場合や、データ更新によって後から対象が増える場合は、無効表示と件数表示を併用する方が分かりやすいことがあります。
絞り込み検索の精度は、画面より先にデータの持ち方で決まります。同じ意味の値が複数の表記で登録されていると、条件に合うはずの情報が検索結果から外れます。
自由記述の説明文だけを基に条件検索を行うと、担当者の書き方によって結果が変わります。検索に使う属性は選択項目や数値項目として持ち、説明文とは分けて管理する方法が適しています。
| サイト・システム | 優先しやすい条件 | 確認したい動作 |
|---|---|---|
| BtoB製品カタログ | 用途、規格、性能、設置環境、納期 | 型番検索と条件検索を併用できるか |
| ECサイト | カテゴリー、価格、在庫、サイズ、配送条件 | 絞り込み後も商品数と並び替えが分かるか |
| 不動産・求人 | 地域、金額、契約条件、設備・待遇 | 希望条件を保存し、新着情報へ利用できるか |
| 社内管理画面 | 担当者、状態、期限、拠点、未対応 | よく使う条件を保存し、一覧へ再適用できるか |
いいえ。選定に使われない条件が増えると、重要な条件を見つけにくくなります。よく使う条件を先に表示し、専門条件や利用頻度の低い条件は詳細検索へ分けます。
条件が少なく検索処理が速い場合は、その場での更新が向いています。条件が多い、通信量が大きい、複数項目を選んでから確定したい場合は、「この条件で表示」ボタンでまとめて更新します。
主要な少数条件はチップやボタン、詳細条件は画面全体を使うモーダルが候補になります。選択後は一覧へ条件名と件数を表示し、モーダルを開き直さなくても現在の状態を確認できるようにします。
製品選定や社内確認で結果を共有する場合、同じ条件をURLから再現できると便利です。戻る操作や再読み込みにも対応しやすくなります。ただし、顧客名、担当者名、非公開の案件情報などはURLへ含めません。
絞り込み検索UIは、条件を増やせば便利になるわけではありません。利用者がどう探すのかを前提に、意味が分かる条件を、選ぶ順番に並べます。
チップ型、アコーディオン型、モーダル型、サイドバー型には、それぞれ向く条件と利用場面があります。条件の数だけで決めず、説明の必要性、利用端末、結果を見ながら変更する頻度で選びます。
製品カタログや業務システムの検索UIを見直す場合は、 「利用者は何を手がかりに探し始めているか」 「今の条件配置で途中で止まっていないか」 を最初に確認します。 この2点を検索ログと利用者への聞き取りで確かめると、優先して直す条件とUIを決められます。