Vibe Coding で作った UI は、なぜどこか DEMO っぽく見えるのか

最初に疑ったこと

最初は、どの層が効いているのか、正直なところ自分でもよく分かりませんでした。

仕上げ（polish）の問題かもしれない。余白、文字、色、状態表現といった細部がまだ足りないから、DEMO っぽく見えるのだと。

情報の強弱の問題かもしれない。どのモジュールも同じくらい重要に見えて、最初にどこを見ればよいのか分からない。

あるいは、もっと上流のプロダクト上の判断の問題かもしれない。画面は、要件にある機能を並べただけで、誰が使うのか、なぜ今開くのか、今いちばん判断したいことは何か、何を弱めてよく、何を消してよいのか、に答えていない。

三つとも、それぞれ理由は説明できました。

自分で試してみたい

本当の差が仕上げ（polish）にあるのではなく、その前の判断が行われたかどうかにあるのなら、自分で試してみたいと思いました。

サポートシステム「Relay」を架空に作り、画面は、サポート責任者が朝に開く全体の概要ページにしました。同じ製品、同じデータ、同じモデルで、どの版も、ほかの版が見えない新しい独立したコンテキストで生成しています。主に変えたのは Prompt です。

Prompt A

Build a modern, clean, production-ready support dashboard page for “Relay”…

「Relay 向けに、モダンでクリーンな、本番利用を想定したサポート Dashboard ページを作ってください……」

そのあとに、10 個のモジュールを並べました。KPI、推移、capacity の予測、SLA チケット、最近のチケット……。ごく普通の機能の依頼で、わざと悪く書いたわけではありません。

Prompt B

Nadia is the support shift lead. It is Monday 9:05 AM and she has just opened Relay. She has about ten minutes before the 9:30 standup, and the busy US East Coast hours start at 10:00.

「Nadia はサポートの shift lead です。現在は月曜日の朝 9:05 で、Relay を開いたところです。9:30 の standup まであと約 10 分で、米国東海岸の繁忙時間は 10:00 から始まります。」

…is the team about to fall behind in a way that will hurt customers, what is driving it, and what should she do first.

「……チームは、顧客に影響が出るほど遅れそうなのか。原因は何か。そして彼女は、何から手をつけるべきか。」

Structure the page from her task, not from a typical dashboard template.

「ページの構成は、典型的な Dashboard のテンプレートではなく、彼女のタスクから組み立ててください。」

Prompt B には、モジュールの一覧も、何をどこに置くかの指定もありません。彼女が誰か、なぜ今このページを開くのか、何を判断したいのかだけを伝え、情報はまとめても、弱めても、省いてもよい、としています。

データには、ひとつ隠れた変化があります。金曜日のリリース後、SSO ログインの問題が急増しています。どちらの Prompt も、それが重要だとは示していません。

1つ目：画面に「何を入れるか」を伝える

実際、悪くない出来でした。

KPI があり、アラートがあり、推移があり、SLA の表があり、最近のチケットもあります。明らかなデザイン上の問題はありません。

でも、もし私が Nadia だったら、今、何を最初に見て、何から手をつければいいのでしょう。

2つ目：ユーザーが「今、何を判断したいか」を伝える

この版では、最初にひとつの判断が出てきました。

“You are already behind, and the 10:00 peak will make it worse.”

「すでに遅れが出ていて、10:00 のピークでさらに悪化する」

その次が “Do these first”。右側の capacity のグラフは、なぜ 10:00 にさらに悪化するのかを説明していました。

KPI は最初の画面より下に移り、7 日間の推移グラフとチャネル別の内訳はなくなっていました。

並べて見ると、違いはどこにあるのか

ここからは、ユーザーテストではなく、場面を想定した検討です。月曜日の 9:05 に shift lead の立場に立ったつもりで、この 2 つの画面を使ったらどう感じるかを想像してみます。

A：画面に「何を入れるか」を伝える

もし私が shift lead なら：「使える。データも十分そろっている。でも、重要な点は自分で探さなければならない。」

滞留、SLA、capacity、異常は見えます。全体の概要としては強く、慣れた人なら、自分で探索して判断できます。

でも、9:30 に standup が始まるというときには、私はまだ、複数の領域を自分でつなぎ合わせなければなりません。いちばん大きなリスクは何か、なぜそうなっているのか、今まず何を処理するのか。

B：ユーザーが「今、何を判断したいか」を伝える

もし私が shift lead なら：「開いてすぐ、今日の問題が何か、そして最初にやるべきことがいくつか分かる。」

B は、すべての情報を最初の画面に置いてはいません。まず、今何が起きているのか、なぜ 10:00 が危ないのか、どれから先に行うべきかに答えています。capacity のグラフは、主に「なぜ」を説明する役割です。

本当に変わったのは、途中のいくつかのステップだった

A は、使えないわけではありません。むしろ、データをひと通りそろえたワークスペースのようなものです。慣れた shift lead なら、これらの手順をたどるのは難しくありません。代わりに、「データ」から「行動につながる briefing」までの間の整理は、主に人が担います。

B も、より完全だというわけではありません。この具体的な場面でやるべきことに、より寄り添っているだけです。整理作業の一部が、人から画面へ移りました。最終的な判断は、今も人がします。画面は、異常の発見、情報の集約、briefing の組み立て、行動の優先順位づけといった前段の整理を、一歩前に進めただけです。

だから私は、のちに、違いは視覚的な階層だけではなく、その前にあるプロダクト上の判断が画面に持ち込まれているかどうかだ、と思うようになりました。

A にも強みがあります。より情報がそろっていて、全体を広く見るのに向いています。慣れた人なら、こうした情報を残しておきたいかもしれません。

B の強みは、このときの具体的なタスクから生まれています。時間がなく、まもなく standup があり、10:00 のピークも迫っていて、シフトやチケットをすぐに調整する必要がある。そのため、このタスクでは全体を見渡すための情報を一部あえて手放しています。

これは今回の生成で出た違いにすぎず、一般的なルールではありません。

では、最初の推測は当たっていたのか

ひとつずつ振り返ってみます。

視覚的な仕上げ（polish）：まったく無関係ではありませんが、主な原因には見えません。

2つの版の視覚表現はよく似ていて、どちらもカード、グラフ、警告色です。B は、より多く磨き込んだから A と差がついたわけではありません。

「情報の強弱」という仮説は当たっていました。

B は、重点、行動の順番、根拠が、より絞られていて、はっきりしています。

でも、そこから別の問いが出てきます。なぜ B には、自然にこうした強弱が生まれたのでしょうか。

それは、Prompt B が先に、誰が使うのか、なぜ今開くのか、何を判断したいのか、そして何を手放してよいのかを伝えていたからです。強弱は、それらから導かれたものです。

だから、情報の強弱は結果にすぎないのかもしれません。もっと上流にあるのは、先にひとつの判断をしたかどうか。このページは、ユーザーが何を判断するのを助けるためのものなのか、ということです。

「DEMO 感」という言葉は、少し違うのかもしれない

この 2 つを見て、私はむしろ、「DEMO 感」はあまり正確な言葉ではないのかもしれない、と思いました。

1つ目は粗くなく、見た目も悪くなく、機能も十分で、単独で見ればきちんと務まっています。

違うと感じたのは、その選択の多くが、「Dashboard を作る」という作業から自然に生えてきたように見えることでした。KPI が 1 列、グラフが 2 つ、表が 1 つ、最近の動きが 1 列。

どれにも理由はあります。けれど、その優先順位を誰かが真剣に並べたわけではありません。

私が「DEMO 感」と呼んでいたものは、ときには、自分で言うなら default-output 感に近いのかもしれません。

画面ができても、その前の判断まで終わっているとは限らない

Vibe Coding では、あいまいな一言の依頼が、あっという間に「もう完成して見えるもの」になります。

結果がそれほど早く出てくると、まだ真剣には決めていない選択が、すでに決めた選択のように見えてしまいがちです。

自分のサイトのトップページでも、似たことがありました。

Hero、Featured、Recent、Series、Thinking、Projects。ひとつひとつに理由はありました。

でも並べると、伝わるのは「学習も実験もプロジェクトもたくさんやっている」ということ。

私が本当に伝えたかったのは、問題にどう向き合い、どう判断し、それをどう形にしていくか、でした。

これは Agent に限った話ではありません。人にモジュールの一覧を渡すのと、ユーザーがいま本当に解決したいことを伝えるのとは、もともと別の問題です。

画面ができたことは、その前の判断まで終わったことを意味しません。

もう一歩、深く

これは、「これからは Prompt を詳しく書けばいい」という話ではありません。

Prompt B を書けたのは、Nadia が誰で、彼女が今何を判断したいのかを、先に自分で考えてあったからです。

作り手自身が、誰がいちばん重要なのか、何を削るべきか、何がまだ決められていないのかを分かっていなければ、もっと長い Prompt を書いても役に立つとは限りません。

そのとき価値があるのは、私の代わりに推測する Agent でも、UI をさらに作り込み続ける Agent でもないのかもしれません。

そうではなく、

「ここには、まだ決めていないことがある」

と気づき、その問いを私に返してくれる Agent です。

Agent の価値は、生成を続けることだけではないのかもしれません。まだ決まっていないことがあると、私自身が気づけるようにすることにも価値がある。