「フィルターとソートくらい、すぐ作れるだろう」
Google Stitch で商品一覧ページのUIを設計していたとき、そう思っていた。でも実際に作り始めると、「絞り込み」の設計は思っていた以上に判断が多かった。
フィルターはドロップダウンにするか、チェックボックスにするか、タグ型にするか。複数条件を組み合わせられるか。適用中のフィルターはどこに表示するか。全件に戻るボタンはどこに置くか。モバイルではどう見せるか——そのひとつひとつに「なぜそうするのか」という理由が必要だった。
この記事では、Stitch でフィルター・ソートUIを設計する過程で突き当たった3つの壁と、それを突破するために使ったプロンプトの書き方を正直に紹介する。
結論から言うと
フィルター・ソートUIの設計で最も重要なのは、「ユーザーが今どんな条件で絞り込んでいるかを常に見えるようにすること」だ。適用中のフィルターが見えなくなると、ユーザーは「なぜこの結果が表示されているのか」がわからなくなる。この「可視性の設計」を最初に決めてから Stitch でプロンプトを書くと、フィルターUIの生成精度が大きく上がった。
フィルター・ソートUIの基本パターン
フィルターUIの主な種類
フィルターUIとは、一覧・検索結果の表示件数を条件に基づいて絞り込むUIコンポーネントのことです。代表的なパターンは以下の通りだ。
ドロップダウン型は、項目名をクリックすると選択肢のリストが展開する形式だ。選択肢が多い（10個以上）場合や、値が動的に変わる場合に向いている。「カテゴリ」「価格帯」「メーカー」のような単一選択フィルターに多く使われる。
チェックボックス型は、選択肢が常に表示されており、複数を同時に選べる形式だ。「複数選択できる」ことを一目でユーザーに伝えられる。選択肢が5〜10個程度に収まる場合に見やすい。
タグ型（ピル型）は、選択肢がタグの形で横並びに表示される形式だ。選択中のタグは色が変わり、もう一度クリックで解除できる。ECサイトのサイズ選択（S・M・L・XL）やカラー選択でよく見られる。
サイドバー型は、左側に絞り込み条件をパネル表示する形式だ。Amazon や楽天市場のような多段階・多条件フィルターに適している。PCでのコンテンツ密度が高い一覧ページで多く使われる。
ソートUIの主な種類
ソートUIとは、一覧の表示順序を並び替えるUIコンポーネントのことです。主な実装形式はドロップダウン（「並び順：新着順▼」）と、カラムヘッダークリック型（テーブルの列名をクリックで昇順・降順切り替え）の2種類だ。
Google Stitch でソートUIを生成するとき、「右上に並び順ドロップダウン（選択肢：新着順・価格が安い順・評価が高い順）」というプロンプトが明確で生成精度が高かった。
壁1：フィルターの「適用状態」の見せ方
「今どんな条件で絞り込んでいるか」が見えなくなる問題
フィルターUIを設計していて最初に突き当たったのが、「ユーザーが条件を選んだあと、何を選んでいるかが画面上でわからなくなる」問題だ。
サイドバーにチェックボックス型のフィルターがあり、ユーザーが「カテゴリ：〇〇」「価格帯：5,000円以下」「評価：星4以上」の3条件を選んだとする。その後、ページをスクロールして一覧を見始めると、サイドバーが見えなくなる。ユーザーは「何で絞り込んでいたっけ？」となる。
この問題の解決策として、「適用中のフィルターを一覧上部にタグ形式で表示する」設計が一般的だ。各タグに×ボタンをつけ、個別に解除できるようにする。「全条件をリセット」ボタンも添えると使いやすい。
Stitch でプロンプトを書くとき、「フィルター適用済み状態。一覧の上部に選択中のフィルター条件が『カテゴリ：〇〇 ×』のようなタグで横並びに表示されている。右端に『すべてクリア』テキストリンク付き」と指定した。この表現で適用状態の可視化を含むデザインが生成できた。
フィルターパネルの「開いた状態」と「閉じた状態」
モバイルでは、フィルターパネルを常時表示するとコンテンツエリアを圧迫する。そのため「フィルターボタンを押すとドロワー型のパネルが開く」設計が一般的だ。
Stitch で「モバイル版のフィルターパネルが閉じた状態（上部にフィルターボタンのみ）」と「フィルターパネルが開いた状態（画面下からスライドアップしてチェックボックスが並んでいる）」の2画面を別々に生成し、Play ボタンで繋いだ。このプロトタイプを共有することで「モバイルでフィルターがどう動くか」をクライアントに伝えやすくなった。
壁2：複数条件の「AND」と「OR」の設計
「複数選択は全部満たすのか、どれかひとつでいいのか」
フィルターで複数条件を選べる場合、「AND 絞り込み」（すべての条件を満たすもの）か「OR 絞り込み」（いずれかの条件を満たすもの）かでヒット件数が大きく変わる。
たとえば「カテゴリ：書籍 + カテゴリ：雑誌」を選んだとき、AND なら「書籍でもあり雑誌でもあるもの（ほぼ0件）」になり、OR なら「書籍または雑誌のもの（多数ヒット）」になる。同一カテゴリ内の複数選択は通常 OR で、カテゴリをまたいだ絞り込みは AND が自然だ。
この仕様はUIのデザインだけでは伝わらない。「このチェックボックスは OR で動く」ということを、Stitch のデザインにコメントとして書き添えておく必要がある。設計段階でこの仕様を決めておくことで、実装時の「どちらの動作にしますか？」という質問を防げた。
「フィルターを選ぶたびにリアルタイムで結果が変わる」か「確定ボタンを押したら反映する」か
フィルターの適用タイミングも設計の判断が必要な点だ。チェックボックスを選ぶたびにリアルタイムで一覧が更新されるパターン（Amazon型）と、「適用」ボタンを押したときに一括で反映するパターン（モーダルフィルター型）の2種類がある。
リアルタイム更新はレスポンスが速い体験を提供するが、複数条件を同時に選ぶ操作では途中の検索が余分に走るコストが生じる。「適用ボタン型」は操作の確認感があるが、ボタンを押すまで変化がなく「本当に選択されているのか」の不安が生じることがある。
Stitch でこの差異を表現するとき、「条件選択中の状態（一覧にスケルトンローディングが表示されている）」と「適用ボタン付きのフィルターパネル」のパターンをそれぞれ生成して比較することで、レビュー時の議論がしやすくなった。
壁3：フィルター後のゼロ件結果と「戻り口」の設計
「厳しすぎる絞り込み」でゼロ件になったとき
フィルターを複数組み合わせた結果、ヒット件数が0件になることがある。この状態を「デッドエンド」と呼ぶが、ユーザーを行き止まりに追い込まないことが設計のポイントだ。
ゼロ件時の対処法としては、3つのアプローチがある。条件を1つずつ緩める提案（「評価：星4以上」を外すと○件あります）、近い条件の結果を表示（「他のカテゴリでは○件あります」）、全条件リセットへの誘導（「条件をすべてクリアして○件から探す」）だ。
Stitch で「フィルター結果が0件の状態。中央に空状態のメッセージ。『条件を変えると〇〇件見つかります』の提案テキスト。『フィルターをリセット』ボタン付き」と指定した。このプロンプトで適切な空状態 + 次のアクションを含む画面が生成できた。
フィルター後の件数表示をリアルタイムで見せる
「適用ボタン型」のフィルターパネルで有効な設計が、「適用すると○件になります」という件数プレビューだ。条件を選んだ時点でボタンに「○件を表示する」と件数が反映される設計は、ユーザーが「この条件にすると何件残るのか」を確認してから確定できるため、ゼロ件のデッドエンドを事前に防げる効果がある。
Stitch でプロンプトに「フィルターパネルの下部に『23件を表示する』という件数付き適用ボタン」と指定した。動的に件数が変わる挙動は静止画では表現できないが、「こういう状態がある」という設計意図を示す画面として生成できた。
Stitch でフィルター・ソートUIを生成する実践プロンプト
ECサイトの商品一覧フィルター（PC版）
「ECサイトの商品一覧ページ（PC版）。左側にサイドバー型フィルター（カテゴリ：チェックボックス5項目、価格帯：スライダー型、評価：星マーク5段階）。右上に並び順ドロップダウン（新着順・価格が安い順・評価が高い順）。一覧上部に適用中フィルター『カテゴリ：〇〇 × 価格：〜5,000円 ×』のタグ表示と『すべてクリア』リンク。一覧エリアに商品カード3列×4行」
このプロンプトで、PC版の充実したフィルターUIが一発で生成できた。細部（スライダーのつまみのサイズなど）は修正が必要だったが、全体構造は意図通りだった。
モバイル版フィルター（ドロワー展開状態）
「スマートフォン版商品一覧ページ。上部にフィルター・ソートボタン。フィルタードロワーが画面下から展開した状態。ドロワー内にカテゴリ（チェックボックス4項目）と価格帯（スライダー）。下部に『23件を表示する』適用ボタン」
このプロンプトで、モバイルのドロワー型フィルターが正確に生成できた。
FAQ
Q1. フィルターとソートはどちらを先に設計すべきですか？
フィルターを先に設計することをお勧めします。フィルターは「表示するデータの絞り込み」でソートは「絞り込んだデータの並び順」です。先にフィルターで結果セットを定め、その中でソートするという順序がユーザーの思考フローに合っています。UIの配置もフィルターが上・左に、ソートが右・下に来ることが多いのはこの理由からです。
Q2. フィルター条件をURLに保存することは設計で考える必要がありますか？
はい、設計段階で決めておくことをお勧めします。「?category=books&price=under5000」のようにフィルター条件をURLのクエリパラメータに反映させると、ユーザーが絞り込んだ状態のURLを共有・ブックマークできます。Stitch のデザインでは表現できませんが、開発仕様のコメントとして「フィルター条件はURLに反映する」と書き添えておくと、実装チームとの認識のズレを防げます。
Q3. Google Stitch でスライダー型のフィルター（価格帯指定）は生成できますか？
はい、静的なデザインとして生成できます。「価格帯スライダー。最小値1,000円・最大値50,000円。現在3,000円〜15,000円に設定された状態。左右にハンドル（つまみ）あり」と指定すると、それらしいスライダーUIが生成されます。実際のスライドする操作はJavaScriptで実装が必要ですが、見た目の設計確認には使えます。
Q4. フィルターのデフォルト状態（何も選ばれていない状態）はどう設計すべきですか？
フィルターが未選択の状態では「すべて表示」が最も直感的です。選択肢の先頭に「すべて」「指定なし」の選択肢を入れるか、チェックボックスがすべて未選択の状態で全件を表示する設計にします。「デフォルトで何かが選ばれている」状態でページが開くと、ユーザーが「なぜ件数が少ないのか」と混乱することがあります。
Q5. フィルター条件が多すぎる場合（20個以上）どうすればいいですか？
フィルターカテゴリをグループ化するか、「もっと見る」で一部を折り畳む設計が有効です。また「フィルター内検索」（フィルター項目を入力して絞り込む）機能を追加する方法もあります。20個以上のフィルターが必要な場合は、本当にすべて必要か一度見直すことをお勧めします。ユーザーが実際に使うフィルターは上位3〜5項目に集中することが多く、残りは「詳細フィルター」として折り畳む設計が使いやすい場合があります。
Q6. ソートの「デフォルト順」はどれが良いですか？
サービスの目的によります。ECサイトなら「おすすめ順（アルゴリズムによる関連度）」または「新着順」、口コミサイトなら「評価が高い順」、求人サイトなら「新着順」または「マッチ度順」が一般的です。ユーザーが「この一覧で何を最初に見たいか」という視点から、デフォルトのソート順を設計段階で決定しておくことをお勧めします。
注意点・失敗しやすいポイント
1. フィルターの種類を詰め込みすぎない
「便利にしよう」と思ってフィルターを増やすと、使い勝手が逆に悪化する。フィルターが多すぎると、ユーザーはどこから絞り込めばいいかわからなくなる。実際に使われる頻度の高い条件に絞ってフィルターを設計し、使われない条件は「詳細フィルター」として折り畳むか、最初から省く判断も大切だ。
2. PCとモバイルで異なるフィルターUXが必要なことを忘れない
PCではサイドバー常時表示が機能しても、モバイルでは画面を占有しすぎる。PCとモバイルの両方のフィルターUIを Stitch で別々に生成して確認する工程を必ず入れること。
3. フィルターを解除する「逃げ道」を必ず作る
ユーザーがフィルターを選んだ後、条件を解除して全件に戻れる導線を必ず設計すること。タグの×ボタン、「すべてクリア」リンク、フィルターのリセットボタン——どれかひとつは必ず画面上に存在させる。解除できないフィルターはユーザーをフラストレーションに追い込む。
まとめ
Google Stitch でフィルター・ソートUIを設計してわかったのは、「絞り込みは検索の延長ではなく、ユーザーと対話する設計だ」ということだ。
適用中の条件を常に見せること、複数条件の論理を決めること、ゼロ件でもデッドエンドにしないこと——この3つの壁を超えてはじめて、使いやすいフィルターUIが完成する。
Stitch でフィルターUIを作るときは、「フィルター未適用状態」「フィルター適用中状態」「ゼロ件状態」の3画面を必ずセットで生成することをお勧めする。その3枚を並べて見ることで、設計の抜けが見えやすくなる。
