AI にメニューを作らせると「全部載せ」になる — 削るのが苦手な 5 つの理由

01前提 — 階層設計は「作る」仕事ではなく「捨てる」仕事

ヘッダーに 5 項目を残すとは、40 個の候補から 35 個を捨てる判断のこと。

ヘッダーに 5 項目を残す仕事は、5 個を「作る」仕事ではない。40 個の候補から 35 個を「捨てる」仕事だ。サイトやアプリには載せられる候補が常に大量にある。機能、設定、お知らせ、ヘルプ、キャンペーン。

設計者の仕事は、その全部に優先順位を付けて、大半を置かないと決めることにある。ところが LLM は、この「捨てる」がいちばん苦手だ。

02理由 1 — 「漏れなく答える」訓練が削ることを罰する

網羅バイアス: 漏れなく載せようとする癖。足すコストをモデルは払わない。

LLM は「漏れなく答えること」を良い応答として学んでいる。だから、削ることが失敗のように扱われてしまう癖がついている。本稿ではこれを網羅バイアス (= 漏れなく載せようとする癖) と呼ぶ。

しかも、項目を足すコストをモデル自身は払わない。画面が煩雑になる、ユーザーが目で探す手間が増える — この代償は生成した本人には見えない。結果、放っておくと「全部載せた索引」に寄っていく。

03理由 2 — 「意味の近さ」で束ね、「使う頻度」で束ねられない

辞書としては正しいが、導線としては死んでいる階層ができる。

良い情報設計は「それが何であるか」ではなく「人が何をしに来るか」で組む。存在の分類ではなく、タスクと頻度の分類だ。

人間の設計者は、この判断をアクセスログやユーザー観察という外部データで決める。LLM はそのデータを持たない。代わりに意味の近さで束ねる。

似ているものを集める作業は LLM の得意分野だ。しかし、どの塊がヘッダーの一等地に値するかは、似ている度合いからは出てこない。結果は「辞書としては正しいが、導線としては死んでいる階層」になる。

04理由 3 — 粒の大きさを揃える制約は、先頭から順に書く生成と相性が悪い

階層の全体を同時に見て守る制約を、先頭から順に書きながら守ることはできない。

同じ階層に並ぶ項目は、粒の大きさ (抽象度) が揃っていなければならない。「製品」の隣に「料金の FAQ」が並んだら破綻だ。

これは階層の全体を同時に見て、初めて守れる制約だ。ところが文章の生成は先頭から順に、局所的に進む。だから書いているうちに粒の大きさが少しずつずれていく。

3 階層になるとさらに悪化する。項目が増えるほど「これはあの項目と並ぶのか、下にぶら下がるのか」という判断が掛け算で増える。しかも上位の切り方を 1 つ間違えると、その下が全部歪む。誤りが増幅する構造なので、深くなるほど下手に見えるのは必然だ。

05理由 4 — 学習データに写っているのは「完成したナビ」だけ

何百万のナビを見ても、「40 を 5 に絞った」過程は 1 つも見ていない。

モデルは学習で何百万というナビバーを見ている。だが見えているのは、排除判断が終わった後の表面だけだ。

「分析の結果、40 項目を 5 つに絞った」という選抜の過程は、公開された Web ページには写らない。写るのは完成品だけ。つまり、何百万のナビを見たことは、何百万の「削る判断」を見たことにはならない。

だから EC サイトのような定番の形は、型としてうまく再現できる。崩れるのは、型の無い新しい分野で、選抜の工程そのものを回す場面だ。

06理由 5 — 「歩いてみる」検証を省略する

人間は作りながら頭の中でユーザーとして歩く。LLM は宣言して一発で終える。

人間の設計者は、作りながら頭の中で歩く。「初見のユーザーが請求書を探しに来た。最初にどこをクリックするか」。

LLM は明示的に求められない限り、この「頭の中で歩く」検証をしない。構造を宣言して一発で出し、そこで終える。自分の作った階層の行き止まりに、自分で気づく工程が抜けている。

07示唆 — 半分は作り方の工程で補正できる

人間の設計者が使う外部のデータと、繰り返し直す工程を組み込む。

この仮説が正しいなら、対策の向きも決まる。人間の設計者が使っている外部のデータと、繰り返し直す工程を、LLM の作業に組み込めばいい。経験上、半分ほどはこれで補正が効く。

• 主要タスクと利用頻度の上位 5 つを先に確定させてから、組ませる。
• 捨てた項目とその理由を必ず出力させる — 排除を明示的な仕事にする。
• 完成後、主要タスクごとに到達経路を歩かせて、詰まりを直させる。