バイブコーディングに足りないのはコードではなく UI/UX の概念

同じ画面が、六日でこう変わった

PillDoc 薬局立地は、ソウルの医院開業候補と薬局開設候補を 100 点満点で採点して地図に載せる画面だ。ログインなしで開く。機能は七月末の時点ですでに全部動いていた。

下の二枚は同じタブ（薬局開設候補）だ。前が 7 月 31 日、後はいま同じ画面を開き直したもの。この間に足された機能はなく、一覧に出ている候補も順位まで同じだ。変わったのは、画面が使う人にさせる仕事の量だ。

原則 1 — 使う人が IT に明るくないなら、馴染みがあるほうが正しい

この画面を使うのは薬剤師だ。地図アプリは毎日使うが、地図アプリの操作子がどんな形であるべきかを考えたことは一度もない人たちである。こういうとき、新しくよく設計された操作子は、よく設計されたというまさにその理由で見慣れない。

そこで参照先を、国内で最も使われている地図に定めた。ネイバー地図だ。ネイバー地図は背景地図を選ぶとき、文字で尋ねない。同じ場所に地図の小さな絵を置いて選ばせる。文字を読み、頭の中でその地図の姿を思い浮かべる段階がまるごと抜ける。

薬局立地もそのやり方に変えた。基本地図・詳細地図・カカオ・衛星の四つをそれぞれ小さな絵で見せる。絵は実際の地図タイルを切り貼りしたものではなく、手描きのベクター画像だ。地図サービスのタイルを保存して再配布するのは利用規約が禁じているし、プレビュー用の地図をさらに四つ立ち上げればその分だけ重くなる——低スペックの端末を想定して詰めた画面なのだから本末転倒になる。だから描いたのは「その地図の実際の姿」ではなく「性格が見分けられる絵」だ。選ぶのに要るのはそれだけである。

馴染みから真似るのは絵ではなく、位置とやり方だ

真似たのはネイバーの絵そのものではない。操作子が画面のどこにあるか、何で選ばせるか、この二つだ。

この二つは使う人が他のサービスですでに学習を終えている部分なので、真似れば学習コストがゼロになる。逆にここで独創性を出せば、使う人はあなたの画面のためにもう一度学習しなければならない。そのコストを払う気のある相手かをまず見極める。薬剤師はそうではなかった。

原則 2 — 並べずにまとめる。まとめたものは閉じていても値を言うこと

7 月 31 日の画面のツールバーには、操作子が六つ平らに置かれていた。自治区セレクト、行政洞セレクト、既存病院チェックボックス、既存薬局チェックボックス、地点分析ボタン、背景地図セレクト。

問題は数ではない。今なにを見ているのかを知るのに、六つ全部を見渡す必要があったことが問題だった。セレクトを並べると、画面の現在状態が操作子のあいだに散らばる。

まとめて三つになった。地域・地点分析・背景地図。肝心なのは数が減ったことではなく、閉じたボタンが自分の現在値を書いていることだ。地域ボタンには「ソウル全域」あるいは「江南区駅三洞」と書いてある。開かなくても読める。この条件が付かないかぎり、まとめることはただ隠すことになる。

まとめずに残す基準も要った。病院立地／薬局立地のタブはそのまま出しておいた。この画面に二つのモードがあるという事実そのものが最初の情報だからだ。畳めば、薬局立地があることを最後まで知らない人が出る。逆に既存施設のチェックボックス二つはツールバーから外し、地図の上の凡例の中へ移した。色の意味と、その色を点けたり消したりするスイッチは一か所にあるべきで、その場所を凡例がすでに持っていた。

まとめの規則は三つだ。関係のあるものを一つのボタンの裏へ入れる。そのボタンは閉じていても現在値を見せる。その画面に何があるかを教える操作子はまとめない。

原則 3 — 全部広げず、必要なときだけ出す

7 月 31 日の画面は、知っていることを全部画面に書いていた。計算時刻と取り込み件数がタブの横に常に出ていて、地図の下には「淡い＝別タブの候補」「標識の大きさ＝候補は点数、既存病院は種別」「地図の右クリック＝その地点の即時分析」が二行常駐していた。右の詳細欄には、予想処方流入、月調剤売上、月 OTC 純利益、譲渡料の参考、妥当な月額賃料、処方元の集中度、実在処方元の処方が一度に広がっていた。

これらはすべて正しい情報だ。問題は、全部が同時に必要ではないことである。はじめて来た人は標識の意味を知りたいし、慣れた人にとってその説明は毎回地図の高さを削る邪魔物だ。一つの画面が二人を同時に相手にすることになる。

そこで常時表示を情報アイコンの裏へ移した。消さずに移したことが重要だ。根拠をなくすと、使う人が推定値を検証する手段が消える。今は凡例の横のアイコンを押すと標識の読み方が出て、リストの足元のアイコン二つが計算時刻と計算に使った資料に答える。画面は静かになり、根拠は残った。

同じ原則は用語にも当てはめた。7 月 31 日の画面には「処方元の集中度 HHI 0.847」という行があった。HHI は市場の集中度を測る統計指標だが、この画面の読み手は薬剤師だ。一度読んで理解できない言葉は画面の本文に置かない。今そうした用語は説明の中に入り、本文へ漏れ戻らないよう禁止語リストを検査に組んである。人が毎回目で捕まえられる種類の誤りではないからだ。

原則 4 — 全項目に共通する事実は、項目ではなく見出しが持つ

リストには候補が四十件入る。四十件すべてに当てはまる事実が三つある。何の候補なのか、どの範囲から選んだのか、いくつまで見せるのか。この三つを項目ごとに書けば、同じ言葉が四十回繰り返される。繰り返される言葉は情報であることをやめて背景になる。それでいて場所と視線は取り続ける。読まれないのにコストだけが残る状態だ。

だから三つは見出しの一行が持つ。「病院開業候補 · ソウル全域 · Top 40」。項目には互いに異なるものだけが残る。順位、洞の名前、住所、点数、推奨診療科。

計算時刻も同じ理由で場所を移した。7 月 31 日には「計算 07-30 16:12 · 病院 19,911 · 薬局 5,903」が画面の一番上、タブの横に貼り付いていた。だがこの鮮度が説明する相手は画面全体ではなく、すぐ下のリストの点数だ。いまはそのリストの足元に下りて、「計算時刻」の一言とアイコンになった。説明する相手の隣に置けば、何についての時刻かを別に書く必要がなくなる。新しい部品も、レイアウトの組み直しも要らない——認知負荷を減らす一番安い方法だ。

おまけもある。見出しが範囲を言うようになると、その文を作る関数を地域ボタンも一緒に使うことになる。見出しとボタンが違う範囲を言う事故が構造的に塞がれる。表示を整えたら、状態の管理まで一緒に整った。

なぜこれがバイブコーディングの問題なのか

この画面のコードを人が一行ずつ打ったわけではない。かなりの部分を AI が書いたので、機能は速く付いた。要件で測れば 7 月 31 日の画面もすでに完成だった。候補を点数順に見せ、地域を絞れ、詳細を開け、任意の地点を分析できる。仕様書に書かれたものは全部あった。

仕様書になかったのが UI/UX の判断だ。六つを三つにまとめるか、背景地図を文字で選ばせるか絵で選ばせるか、標識の説明を常に出すかアイコンの裏に置くか、全項目に共通する事実を項目ごとに繰り返すか見出しで一度だけ言うか。これは「実装して」からは出てこない。

要件に書かれていなければ、AI は最もありふれた形を出す。操作子を順に並べ、持っているデータを全部画面に書く形だ。それが誤りだからではなく、最も安全な既定値だからである。抜けで減点されない側を選ぶのだ。

だからバイブコーディングが速くなるほど、UI/UX の概念がより必要になる。コードが書けなくて詰まる区間が消えると、残る隘路は何を畳んで何を残すかを決める人になる。この画面も実装は別の開発者がしていて、最後に別途コーチしたのは上の四つだけだった。その四つに六日かかっている。

いま作っている画面に当ててみる四行

一。この操作子と同じ仕事をする操作子が、使う人が毎日開くアプリにすでにあるか。あるならその位置とそのやり方をまず真似る。独創性はその次の問題だ。

二。一列に置かれた操作子が四つを超えているか。超えていればまとめる。ただしまとめたボタンは閉じた状態で現在値を見せること。見せられそうにないなら、まとめずそのまま置くほうがよい。

三。画面に常時出ている説明文があるか。使う人が最初の三十秒より後にもそれを読むかを自問する。読まないなら情報アイコンの裏へ移す。消しはしない。

四。リストの項目ごとに同じ言葉が繰り返されていないか。あれば項目から外し、リストの見出しに上げる。

四つとも新機能ではなく配置の問題だ。だから AI に任せてよい仕事だが、任せるには人が先にこの四つを知っている必要がある。バイブコーディングで人が握っていなければならないのは、まさにこの場所である。

自分で見てみる

この画面はログインなしで開く。https://www.pilldoc.co.kr/PharmSite で右上の「基本地図」ボタンを押すと、原則 1 と 2 が一度に見える。リストの足元のアイコン二つと凡例の横のアイコンが原則 3、リストの見出しが原則 4 だ。

画面のすべての金額と件数はモデルの推定値だ。実際の開業判断に使うときは、別に現地確認が要る。