なぜ私たちの vibe coding サイトはデザイナーが作ったように見えるのか

vibe coding で作ったサイトと言われて思い浮かべるのは、だいたいこんなやつだろう：よくある AI 生成のランディングページ。暗いグラデーション背景に紫のアクセント 例として作った偽サイト（ただし、例でも何でもない本物のサイトにそっくりではある） ところが、今あなたが見ているこのサイトも私が vibe coding で作ったもので、見た目はこうなっている：正直に言うと、デザイナーが作ったみたいだと言うのは買いかぶりすぎだと思う。でも実際にそう言ってくる人がいる！このサイトをどうやって作ったのか、誰と組んだのかと、何人にも聞かれた。あまりに何度も聞かれるので、不可能な挑戦をしてみることにした。Railcode のサイトをどう作ったか、最初から最後まで全部書いてみよう。自分が大した人間だと言いたいわけでも、デザイナーは不要だと言いたいわけでもない（むしろ逆だ）。ただ、LLM が生成するデザインのゴミの話ばかりが飛び交う中で、coding agent に手伝ってもらえるようになってから、私はデザインにむしろ熱が入るようになった。以前はどうしようもなかったことが、今は頭の中のアイデアを実際に形にできる。だからこの記事の目的はこうだ。coding agent を使えばセンスのあるデザインができる（センスがある＝自分が気に入っている）。しかも、やるべきだ。すべてのサイトプロトタイプと、それを生成した prompt を並べたインデックスページこの記事を書くために、すべてのプロトタイプを、それを生成した元の prompt ごとインデックスページにまとめた。こうして自分の過程を実際にたどれるし、記事に根拠を持たせられる

ジェットコースターが山ほど

Railcode という名前は「code on rails」から来ている。Railcode のアプリと agent はコードそのもので、私たちはインフラとガードレール（つまり rails）を担当し、安全な環境へ素早くデプロイできるようにする。サイトを作ると決める一週間前、私は Railcode で自分用のものを作るのがやたら楽しいことに気づいた（ヘビーユーザーである）。顧客に聞いてみたら、彼らも結構楽しいと言っていた。 Rails + fun = rollercoaster。だからサイトにはジェットコースターを入れることにした。とはいえ私はデザイナーではない。ゼロからコンセプトを考えるのは私には難しすぎる。つまり事例とインスピレーションに頼るしかない。方法は二つある：

ネットで好きなデザインを片っ端から見る
agent に同じものをいろんなスタイルで大量に生成させる狙いは視野を広げ、どんな可能性があるかを見ることだ。たいていは複数の場所から少しずつ拾って組み合わせ、納得いくまで反復する。たいていは行き止まりだ。今回、最初のジェットコースターのデザインはこうだった： ASCII 風の二つ（上の二つ）は、その週の初めに見た友人のサイトから着想を得た。残りは Fable に自由にやらせた。これらはインスピレーションの種としての役割を果たす。いくつかの要素が助けになった：

強度の段階分け： agent に一つのコンセプト／アイデアを渡し、強度や複雑さのスペクトル上で異なる位置に落ちるデザインをまとめて生成させる。こうすると、そのコンセプトが全体として面白いかどうか（スペクトル上に一つも気に入ったものがないなら、たいていスペクトルの選び方が間違っている）も、もっとミニマルに寄せたいのか、それとももっと狂った方向に振り切る余地があるのかも判断できる。
自由にやらせる： あるコンセプトを試すとき、たいていは agent に少なくとも 4 バージョン、時には 10 バージョン要求する。そのうち少なくとも半分にはある程度の指示を出し、残りは自由にやらせる。ほとんどは完全にダメだが、火花は飛ぶし、新しいアイデアが生まれる。あの狂った醜いネオンも「自由にやらせる」枠だったことは、たぶん見てわかるだろう。実際に使うことは絶対にないが、ASCII の路線から私を引きはがし、もっと野心的な方向へ向かわせてくれた。

Rollercoaster Tycoon

Rollercoaster Tycoon の遊園地のスクリーンショット

子供の頃、Rollercoaster Tycoon というゲームをよく遊んでいた。目標は（少なくとも私にとっては）最高にクールな遊園地を作ることだ。上の画像でわかるように、✨美意識✨にあふれた園区を作れる。

Claude が生み出したあのネオンの怪物を見て、このゲームを思い出した。そして、自分のサイトはこれにオマージュを捧げるものにしようと決めた。

まず Fable にミニ版のゲームを作らせた：

「Rollercoaster Tycoon 風の自己完結型コンポーネントを作って。html で直接遊べるやつ——実は並行して二つ。片方は透明背景で」

なかなかクールで、一瞬はサイトに本当にゲームを埋め込むつもりでいた。でもしばらく遊んでみて、これはやりすぎだと気づいた。

そこで原点に戻り、本当に気に入ったジェットコースターを一つだけ選ぶことにした。十分に試した末、ようやくこれができた：

これで決まりだと思っていた。テンプレートにジェットコースターを貼り付けて、しばらくはこれでいいかと思っていた。

確かにこれはかなりクールだが、ウェブサイトのど真ん中にジェットコースターが一本突っ立っているのはどうなのか。浮いている。

明らかに、必要なのはパーク全体だ。

脱線

パークを作ると決めたとき、なぜかそれはheroの下端に置くべきだという気がした。以前見たどこかのサイトに影響されたのは間違いないが、どれだったかは思い出せない。

そこで生まれたのがこの横帯だ：

「高さ200pxくらいの細い横帯を作って、ジェットコースターと同じスタイルの遊園地の設備を並べて」

この時点で方向性は見えてくるが、サイトに載せるとまだひどい。

サイトに載せた設備の横帯。浮いている

この時点で既に並行して作業を進めていて、coding agentsセクションを追加すると決めてそのコンポーネントを作っていた

これをベースに反復を重ねてできたのがこちら：

洗練されたファーストビュー。遊園地の帯が次のセクションへと遷移する

ここまでの進め方はこうだ。素材のデザインは以前のジェットコースターを基準に固定し、各アニメーションを一つずつ選んで磨き込み、この帯は独立して存在するのではなく、次のセクションへ向かう色の遷移であるべきだと判断した。この最後の点は、どこかのサイトで見たのは間違いないが、どれだったかは思い出せない。

フォークの上のフォーク

最後のデザインが決まったときはとても満足して、すぐに友人に見せた。だが何かが引っかかり、こうしてフォークが生まれた。サイトを作るときは、ほぼ公開できる状態になるまでHTMLファイル一つだけで進め、そこからReactに分割して各種コンポーネントに分け、agentに並行して編集させる。このやり方の利点は、デザインを複製して一箇所か二箇所変えて並べて比較する、というのが非常に速くできることだ。

同じデザインの複数のフォークを並べて比較

いわゆる「playground」も作る。色やその他の変数を試すためのものだ。今回はまず手元の芝生の色を青から緑に変えた（芝生は緑だ、当たり前だが）。しかし調整した緑は自分が求めていたものではなかった。そこでClaudeにplaygroundを作らせ、アクセントカラー、テキスト色、芝生の色、背景色などをいろいろ試せるようにして、ようやく欲しかった芝生の色にたどり着いた。（これらのフォークとplaygroundを管理するための小さなオープンソースツールすら作りたい気がしている。時間ができたら試すかもしれない。）芝生が片付くと、細部を詰め始めた。ジェットコースターの方向へ舵を切る前、実はまずFableに「開発者ツールのサイトの楽しいmockup」を作らせたのが、この一連の流れの始まりだった。そのmockupはほぼゴミだったが、CTAの設計をどうすればいいか考えているとき、ぴったりのものを見たことを思い出した：

初期mockupから切り出した小さなCTAボタンのデザイン

だからこそ、プロセスの早い段階でデザインをたくさん見るべきなのだ。たとえひどくても。後になって、草稿の山から宝物を掘り出せるかもしれない。また、白い背景はサイトを楽しくなく見せていた（そして自分が欲しかったのは楽しさだ）。そこで空色に変え、雰囲気を出すために雲もいくつか加えた：

白から青へ、効果は雲泥の差

あとは自然な流れだ。ファーストビューで調子を決めれば、サイト全体がそれに従う。 Railcodeの製品のアクセントカラーは今ブルーだが、サイト上の緑があまりに自然に馴染んだので、あえて受け入れて無理に戻さなかった。こうして薄緑と深緑の二つのセクションが生まれ、最後にはフッターの土もそこから来ている。となると、製品自体のデザインも見直す必要があるかもしれない…… サイトの残りの部分はまだ何度も手を入れたが、スタイルがおおよそ固まれば、新しいアイコンや素材を作るときにいつでも参照できる。まずトーンを決めることが重要なのは、それで明確な方向性が生まれるからだ。とはいえ細部に終わりはない。最後の例はナビゲーションバーだ。固定色がどうもしっくりこないので、現在いるセクションに応じて対応する背景色へグラデーションするようにした。自分としては雲泥の差だ！

白、薄青、薄緑、深緑と固定版を試したが、最終的に最良の解は全部入りだった

インスピレーション

前述のとおり、非デザイナーとして既存の作品からインスピレーションを得ることは、自分の制作フローに欠かせない一环だ。そして明確な作例は、coding agentに方向を示す最良の方法でもある。参考対象に非常に近いものを作ってしまうこともある。例えばこの明るいセクションから暗いセクションへの切り替えは、それ自体よくあるパターンだが、自分がよく参考にするのはContextual AIだ：

contextual.aiとrailcode.devの明→暗セクション遷移の並列比較

左がcontextual.ai、右がRailcodeのサイト

だがインスピレーションの出どころがそこまではっきりしないこともある。例えばRailcodeのこのセクションは、実はClayに触発されたものだ：

clay.comとrailcode.devのセクションの並列比較

左が clay.com、右が Railcode のサイト

私もこれまで、いろいろなサイトを大量に眺め続けてきた。結局その中の具体的な要素を何も使わなかったとしても、影響は受ける。Railcode のサイトは Sentry とは似ても似つかないが、ずっと見続けて、コンテンツに合ったイラストのスタイルを感じ取ろうとしている。

深夜のメッセージのやり取り。デザインをもう何パターンか作るよう頼んでいる

深夜0時を30分過ぎたところ：「more」

まだ話せることはあるが、この記事はもう十分長い。自分のプロセスで最も重要な部分をまとめるとすれば、こうなる：

デザインには Anthropic のモデルしか使わない。OpenAI のモデルは、具体的な方向性を与えてもうまくやれないと感じている。Fable が一番いい。
デザインに満足して、コピーなどに取りかかる準備ができるまでは、すべてを1つの HTML ファイルに入れておく。
インスピレーションのために 大量に サイトを見る。気に入ったサイトは何度も見返すし、新しいものも探し続ける。特に気に入ったコンポーネントがあれば、それを土台にして上に積み上げていく。
最初は Claude に大量の異なるサイトを生成させ、最後には99%を捨てる。だが時々そこから1つのコンポーネントを持ってきたり、試してみる価値のある新しいアイデアを得たりする。
coding agent にいくつかのデザインを「自由にやらせる」ことはよくあるし、1つのアイデアの種から、ミニマル -> 誇張まで複数バージョンを一連で作らせることもある。
自分のプロセスに後から見返しやすい痕跡を残すのが好きなので、デザインを絶えず「fork」して、数か所変えて、元と比べる。その後 fork で続けることもあれば、元に戻ることもあるが、fork は決して消さない。
playground を作って、色やフォント、位置を気軽に試し、リアルタイムで結果を見る。agent に変更させるあの遅い反復作業はやらない。
反復して、反復して、また反復する。ほとんどの反復は行き止まりだ。

何より、このプロセスを楽しんでいる :)

POV: me when Fable did heavy lifting というキャプション付きのミーム画像

POV：Fable が大車輪の活躍をしたときの私