ドロップダウンのフィルターが不正解に近い理由
前回は、相談申込フォーム、つまり値を入力して一度に送る様式が、保存の流れをたどればナンプレのように解けるという講義の内容をまとめた。講義は続けて、フォームではない場所にも正解があるのかと問う。例はサービス紹介ページの事例セクション、つまりページを上下に区切った区画のうち、顧客事例を集めた一角だ。この会社が売るサービスパッケージは A・B・C の三つで、その事例がカード数枚で並んでいる。
カード一覧の上にはフィルターが一つある。全体と書かれた箱の右に下向きの山形の矢印が付いていて、押すと全体・A・B・C が開く。B を選ぶと箱の文字が B に変わり、B の事例だけが残る。このように押すと一覧が開く選択箱をドロップダウンという。よく見る形で、動きも問題ない。
講義は、これが正解か不正解かを問う。判断の基準はこのセクションの意図だ。事例は一種の証言である。A・B・C それぞれの事例を見せて、訪問者が相談を申し込みたくなるようにする場所だ。
ところが訪問者の多くは、このセクションに来て初めて、この会社のサービスが A・B・C に分かれていると知る。ページ上部のバナー、つまり大きな宣伝画像の枠が A・B・C を一枚ずつめくって紹介していても、めくらずにそのまま下りてきた人には見えていない。ドロップダウンはその三つの名前を再び箱の中に畳んでしまう。押してみなければ、全体という一語しか見えない。
だから正解に近いのは、選択肢を最初から外に出しておくことだ。全体・A・B・C が並んで見え、いま何を見ているかが示される。サービスに区分があるというセクションの意図が、押す前から伝わる。
| 形 | 選択肢は見えるか | いま何を見ているかは見えるか |
|---|---|---|
| ドロップダウン | 押すと開く | 箱の中の一語だけ |
| 外に出した選択肢 | 最初から並んで見える | 選んだものが目立つように示される |
カード一枚に入っているデータ
講義はここでもう一歩踏み込む。このカードにもデータが隠れている。事例 1 番、2 番、3 番、4 番のカードは、二つの方式のどちらかで画面に来る。
一つは、見せる内容を画面のコードに直接書いておく方式だ。値をコードにがっちり打ち込んだということでハードコーディングと呼ぶ。事例を変えるにはコードを直さなければならない。もう一つは、管理者が入力した値を見せる方式だ。運営者だけが入る管理画面で事例を登録すると、その値はデータベース、つまり値を表計算の表のように積んでおく場所に入り、事例一覧はその値を受け取ってその都度見せる。相談申込の内容を管理者が確認するのと同じく、事例も普通はこちらだ。
受け取った値はどんな形をしているだろうか。カードが何枚もあるので一覧だ。複数の値を順に入れた一覧を配列と呼び、角かっこで開いてカンマで区切って書く。角かっこの中に事例 1、2、3、4 が順に入っている。
カード一枚に必要な値を数えてみよう。事例のタイトル、顧客企業、画像、日付だ。詳しく見るボタンはどのカードにも同じく付くので値ではない。画像は固定でなければ値だ。画面に画像を出すにはその画像が保存された住所が要るので、カードごとに画像の住所が入る。このようにカード一枚分の値を波かっこで束ねた塊をオブジェクトという。
しかしこれで全部ではない。B を押せば B の事例だけが残らなければならないので、カードごとにどのサービスの事例かを示す値がもう一つ要る。画面には見えない種類の値だ。まとめると、カード一覧のデータは配列の中にオブジェクトがいくつも入った形で、オブジェクトごとに見える値四つと見えない値一つが入っている。
[
{
title: "事例 1 のタイトル",
customer: "顧客企業 1",
imageUrl: "/cases/case-1.webp",
createdAt: "2026-09-01",
type: "A" ← 画面には出ない
},
{
title: "事例 2 のタイトル",
customer: "顧客企業 2",
imageUrl: "/cases/case-2.webp",
createdAt: "2026-09-08",
type: "B"
},
...
]
角かっこ [ ] = 一覧（配列）、波かっこ { } = カード一枚（オブジェクト）いま何を見せるか — 状態
データだけでは画面は完成しない。訪問者が B を押したら、B の事例だけを見せる動きが起きなければならない。そのためには、画面がいまどの種類を見せている最中かをどこかで覚えていなければならない。
この記憶を状態、英語で state と呼ぶ。目には見えないが画面の側に付いている値だ。表計算で言えば、表に積まれた値がデータで、いまかけているフィルターの条件が状態に近い。データが何があるかなら、状態はいまその中の何を見せるかだ。
状態の値の形は二通りに考えられる。複数の種類を同時に選べるようにすれば、状態は一覧だ。全体のときは A・B・C が配列に全部入っていて、A と C を選んだ状態なら A と C の事例が見え、三つとも選べば再び全体を見せる。前回の相談申込フォームのチェックボックス、つまり前の選択を残したまま複数を選べる欄と同じ構造だ。
逆に、B を押した瞬間に A が外れて B だけが見えるべきで、しかも全体も A・B・C を全部選んだものではなく独立した一つの選択肢として扱うなら、状態は値一つだ。別のものを選ぶと前の選択が外れる論理、つまりラジオボタンである。
講義が求める考え方がこれだ。フィルターを見ながら、これはチェックボックスの論理かラジオボタンの論理かをまず問う。その答えが決まれば状態の形が決まり、状態の形が決まれば AI に何を頼むかも決まる。
複数選べるとき（チェックボックスの論理）
selectedTypes = ["A", "B", "C"] → 全体
selectedTypes = ["A", "C"] → A と C の事例だけ
一つだけ選ぶとき（ラジオボタンの論理）
selectedType = "all" → 全体
selectedType = "B" → B の事例だけタブは見た目だけ違うラジオボタンだ
ラジオボタンの論理とよく似た動きをする、見慣れた形がある。タブだ。全体・A・B・C が横に並び、押したものがいちばん前に出て見える形である。選択肢を外に出せという先ほどの正解とも合う。
タブは二通りに作れる。一つは、全体の画面と A・B・C の画面をそれぞれあらかじめ作っておき、押すたびに該当する画面に差し替える方式だ。もう一つは、中身をラジオボタンとまったく同じにしておく方式だ。状態には選んだ種類一つだけを持ち、タブは選ばれたものを前に出す演出だけを受け持ち、下のカード一覧は状態が変わるたびに描き直される。見た目は同じでも裏は違う。
講義の結論はこうだ。画面で目にする多くの UI、つまり人が見て押す画面の要素は、二種類のデータに結びつけて考えるとかなりの部分で正解が出る。データベースに入力されるデータと、状態に入るデータだ。
今日やってみることはこうだ。自分のサービスやよく使うアプリでフィルターかタブを一つ選び、三つを確かめる。押す前から選択肢が見えるか、いま何を見ているかがわかるか、一つだけ選べるのか複数選べるのか。直すべき所が見えたら、下のように AI に頼む。
残る問題が一つある。どんな意図にどんな UI の選択肢があるかを知ることだ。次回は、その選択肢の名前、つまりコンポーネントの名前を知ってこそ AI に画面を伝えられる理由を扱う。
直す前に二つを先に見せて。
1) 事例一覧のデータがどんな形か（配列の中のオブジェクトのフィールド名）
2) いま選ばれているフィルターをどんな値で覚えているか（状態の名前と形）
そのうえで、事例一覧の上のドロップダウンのフィルターをタブに変えて。
- 全体・A・B・C を最初から全部見えるようにする。
- 一度に一つだけ選ばれる（ラジオボタンの論理）。全体は独立した一つの選択肢。
- いま選ばれているタブを目立つように示す。
- カード一覧は各事例の type の値で絞り込む。