Vibe Design vs Vibe Coding：どこで分かれ、なぜそれが重要なのか

vibe design vs vibe coding についての説明のほとんどは、定義で終わってしまう。一方はデザインを作り、もう一方はコードを作る、以上。これは正しいが、何の役にも立たない。私は Open Design でこの両者の継ぎ目——生成されたデザインが動くインターフェースに変わるはずの部分——を担当しているが、断言できる。価値があるのは定義ではない。価値は両者のあいだのギャップにある。美しいモックアップが決してリリースされない場所、生成されたコードが一貫したデザインから静かに逸れていく場所だ。この分岐を取り違えると、毎回どちらかの通貨で代償を払うことになる。

だからこれはまた別の用語集ではない。実際に何が違うのか、機能ページには載らない 2 つの失敗モード、そしてどちらに手を伸ばすべきかのフレームワークだ。まず基礎の定義が欲しいなら、what is vibe design の入門記事にそれがある。

本当の違い：同じ衝動、異なる成果物

どちらも同じ衝動から始まる——一つひとつの矩形を手で配置したり、すべての div を手で打ち込んだりするのではなく、vibe（感覚、方向性、参照）を記述して AI に何かを生成させる。両者が分かれるのは、手元に何が残るかだ。

• vibe design はデザイン——眺めて反応する画面、レイアウト、モックアップ——を生み出す。成果物は決定だ。「そう、この方向でいこう」。
• vibe coding はコード——クリックできる動作するフロントエンド——を生み出す。成果物は納品物だ。「これは動く」。

あとはすべてこの一つの分岐から導かれる。デザインは変更が安く、リリースは不可能だ。コードはリリースでき、スタイルの作り直しは高くつく。つまりこの 2 つのツールは正反対の仕方で失敗する——そして定義ではなく、それこそがあなたの選択を左右すべきものだ。

	vibe design	vibe coding
得られるもの	編集可能なデザイン／モックアップ	動作するフロントエンドのコード
最適化対象	方向性の探索	動くものを生み出すこと
変更は	安い——絵だから	高い——ビルドだから
そのままリリースできる？	いいえ——作る必要がある	はい——ただしモデルが推測したスタイルのまま
代表的ツール	Visily、Uizard、Figma AI	v0、Lovable、Bolt
失敗の仕方	モックアップの崖	デザインドリフト

誰も警告してくれない 2 つの失敗モード

モックアップの崖（vibe design の失敗）。 30 秒で何か見事なものを生成し、その場の全員がうなずく。そしてそれはそこに留まったまま動かない——モックアップはアプリの記述であって、アプリそのものではないからだ。誰かがそれを作らなければならず、モックアップが美しいほど、ビルドが違う形で上がってきたときの埋没コストは大きくなる。私は同じ「完成した」画面をコードで作り直した回数を、認めたくないほど重ねてきた。モックアップは進捗のように感じられた。実際には約束手形だった。

デザインドリフト（vibe coding の失敗）。 これがチームを驚かせるやつだ。コード生成ツールに画面を次々と要求すると、どれももっともらしいのに微妙にズレている——ここのボタンの角丸が違い、そこにパレット外のグレーがあり、間隔がほとんど合っているだけ。Reddit のスレッドにはただ「the design drift created by vibe coding is insane（vibe coding が生むデザインドリフトはヤバい）」とだけ書かれていて、問題のすべてが一行に収まっている。コードは動くので、リリースされたように見える——だが、合わせるとシステムにならない十数個のニアミスを積み上げてしまっている。誰もデザインを決めていない。モデルが 12 回推測しただけだ。

ここが肝心な部分だ。この 2 つの失敗は同じ根本原因を持つ。 モックアップの崖もデザインドリフトも、どちらもデザインとコードが信頼できる単一の情報源を共有していないために起きる。モックアップは自分がどう作られるかを知らず、コードはデザインシステムが何と言っているかを知らない。その一点を直せば、両方の失敗モードはほとんど消える。

どちらに、いつ手を伸ばすか

「場合による」は飛ばそう。私ならこう判断する。

成果物が決定のときは vibe design に手を伸ばす。 方向性を探っている、誰かがコードを書く前にステークホルダーの賛同が必要、まだエンジニアがその場にいない、あるいは 10 個の方向を捨てることこそが目的になるゼロイチの混沌のなかにいる。選択肢を見て却下する、できるだけ安い方法が欲しい。リリースするな——それで決めるのだ。

成果物が動く必要があるときは vibe coding に手を伸ばす。 プロトタイプに本物のインタラクションが必要、方向性を過ぎて「動かす」段階に入った、あるいは学びへの最短経路が動くものをクリックすること。ただし、ドリフトを管理する責任を引き受けたと承知して臨むこと——つまり、vibe だけでなく、生成が実際に従えるデザインシステムが必要だということだ。

自分がどちらにいるかの見分け方： 「次の決定はこれは何であるべきかなのか、それともこれは動くかなのか」と問う。前者は vibe design。後者は vibe coding。たいていのチームは、実際に答えようとしている問いではなく、自分が好きなツールに手を伸ばす——それが間違いだ。

本当の答え：両者を一つのループにする

「design vs coding」という枠組みそのものが罠だ。別々のステップとして扱えば、ハンドオフが生まれる——そしてハンドオフこそ両方の失敗モードが棲む場所だ。血を流さないチームは両者を一つのループとして扱う。そしてそのループを閉じるものは、退屈だ。両方の半分が従う、本物の、共有された成果物としてのデザインシステムだ。

それが Open Design が賭けているものだ。デザインシステムは、コードが読めない Figma ライブラリでも、モデルが無視するスタイルガイドでもない——デザインステップとコード生成ステップの両方が消費する、ポータブルな DESIGN.md ファイルだ。そこからデザインを生成し、それに対してコードを生成すれば、モックアップは崖になりようがなく（すでに本物のコードを指しているから）、コードはドリフトしようがない（システムに固定されているから）。vibe design と vibe coding は対立であることをやめ、意図からリリースまでの一つの動きになる。今日この境界線の両側に存在するツールについては、vibe design tools でこの分野を一通り見て回った。

FAQ

vibe design と vibe coding の違いは？ vibe design はあなたが反応するデザインを生成し、vibe coding はあなたが使える動作するコードを生成する。同じ意図ファーストの衝動、異なる成果物——決定 対 納品物だ。

vibe design はデザイナー向けの vibe coding にすぎない？ 違う。vibe coding はコードを生成し（システムが制約しない限りデザインはドリフトする）、vibe design はデザインを生成する（誰かが作らない限り決してリリースされない）。両者は補完し合う半分であって、対象者が違うだけの同じものではない。

どちらを先に学ぶべき？ 次の決定に合うほうを。これは何であるべきか（vibe design）か、これは動くか（vibe coding）か。長期的には、レバレッジは両者をつなぎ、どちらも単独で失敗しないようにすることにある。

vibe coding はデザイナーを置き換える？ 矩形を手で配置することは置き換えるが、何が正しいかを決めることは置き換えない。何が存在すべきかについての判断——そしてそれを一貫させるシステム——こそ、まさに自動化されない部分だ。ドリフトがその証拠だ。

まとめ

vibe design と vibe coding は競合相手ではない。一つの動きの両端であり、それらを別々のステップとして扱うチームはすべて、中間で通行料を払う——決してリリースされないモックアップか、ドリフトする UI かだ。目の前の問いで選べ。これは何であるべきかを決めているのか、それとも動かそうとしているのか。そして、ほとんど誰もやらないことをやれ——両方の半分に同じデザインシステムを従わせ、vibe が意図から、自分が所有するリリース済みのコードまで、ずっと生き残るようにするのだ。