コードでデザインを作り、管理するという発想
はじめに
最近は生成AIを使ってこれまでのソフトウェア開発をどう効率化できるかをひたすら模索しています。
特に、「デザインからフロントエンドの実装の工程において、どのようにデザインからコードをシームレスに生成できるのか」と言うことを考えていたのですが、ある時ふと思いました。
「コードを生成するコストが生成AIによって格段に下がったのなら、デザインからコードを自動生成する方法を考えるよりも、コードを使ってデザインを作ると言う発想（Design as Code とも言えるでしょう） の方がもはや正しいのではないか。」
v0.dev はこの発想のもと生まれたサービスの先駆者とも言えるでしょう。
これまでは、出来上がったデザインからコードをどう自動生成するのかということに囚われていました。
冷静に考えるとそれは生成AIが登場する以前だと当たり前のフローでした。
今ですと、生成AIによってコードそのものを生成するコストが下がった分、そもそもコードを使ってデザインを検討し、作成すると言うことも現実的になってきたのではないかと考えました。
本記事では、上記仮説について考察していこうと思います。
これまでのデザインから実装までの工程について
まず、これまでの一般的なデザインからフロントエンドの実装を行うまでの工程を振り返ってみます。
そもそも、開発工程の全体の流れは以下が一般的ではないでしょうか。（かなりざっくりですが）
- 要件定義設計
- ワイヤーフレーム
- デザイン
- 実装（フロントエンド・バックエンド・インフラ）
- 試験
- リリース
要件定義・設計フェーズで決まった作るべき機能や画面に対して、ワイヤーフレームとデザインをFigmaなどのデザインツールを使って定義していきます。
デザインツールを用いて行われる作業は主に以下です。
- デザインの検討・検証
- デザインの作成
- デザインの運用管理
ここで作成されたデザインを再現するような形で、エンジニアはReactなどでフロントエンドのコードを書いて行く、と言うのがこれまでの一般的なデザインからフロントエンド実装までの流れになります。
つまり、上述したデザインツールで行う3つの作業がそもそもコードによって実現できるのであれば、一度Figmaで作ったデザインをフロントエンドのコードを使って改めて再現する、といったある意味二度手間とも言える工程を省略することが可能になります。
ここからは、上述した工程がコードによって実現が可能かどうかを検証していこうと思います。
コードを使ってデザインの検討・検証、作成が可能か
まず、デザインの検討・検証の工程についてです。
この工程において重要なのは、検討・検証を行う上で必要なパーツ（ボタンなどのコンポーネント）とレイアウトの調節を行うコストがいかに低いかと言うことだと思います。
例えば、メンバー管理画面のデザインを検討する際に、構成される要素としては以下が挙げられます
- メンバー招待ボタン
- メンバー一覧の表示 etc...
その中で、メンバーの一覧表示のデザインを作成する上で、「テーブルUIを採用すべきか」「リスト形式のUIを採用すべきか」といった観点が検討事項として挙げられます。
その際「一旦どちらのパターンのデザインも作ってみて、それらを見比べてどちらかに決めよう」と、デザイン検討・検証の段階においては何度もスクラップ&ビルドを繰り返し行う必要があります。
つまり、デザインを検討・検証する上で必要なパーツやレイアウトの調節を行うコストが低くないと、デザインの試行回数を重ねられず、検討・検証に時間がかかりすぎてしまいます。
そのため、コードを書くことと比べるとGUI操作で簡単にデザインが作れるFigmaのようなデザインツールが使われてきたと考えられます。
しかし、生成AIの登場によってデザインの検討・検証工程で必要なパーツやレイアウトの調節のコストが一気に下がりました。
Figma上でメンバー一覧表示のパターンを何パターンも作るコストよりも、Claude3.7 sonnet を使ってCursor上でReactのコードを生成させて、何パターンも作る方が単純なデザインの作成時間で言うと短いはずです。
少し前に話題になったOnlookはその発想なのではないでしょうか。
このツールは、Figmaと似たようなUI上で、AIと自然言語による対話形式でデザインを生成ができるツールですが、裏側では「Reactのコード」が生成されています。
コードを使ってデザインの運用管理が可能か
次に、デザインの運用管理の工程についてです。
一度リリースしたら終わり、と言うわけではないのはデザインも開発も一緒です。運用し続ける必要があります。
新しい機能をつけるためにデザインを新たに作ったり、トレンドに合わせてデザインシステムそのものを刷新したりなどさまざまだと思います。
なんと、OnlookにはFigmaのバリアブルやスタイルのようなデザインシステムを管理する機能もこれから入ってくるそうです。（すごい）
こちらはまだリリースされていないようなので試せていないですが、おそらくプライマリカラーやセカンダリカラーなどのカラーの設定、タイポグラフィーの設定が可能のようです。
Onlook を例にとると、コードを用いることによってデザインの作成、検討・検証だけに留まらず、デザインの運用管理もある程度は可能なようです。
では、Onlook が銀の弾丸なのか
ここまでを振り返ると、「Onlookが銀の弾丸である」と言うように聞こえるとは思いますが、必ずしもそう言うわけではないと思います。
Onlook はFigmaのような直感的な操作性を備えつつ、デザインの運用管理もできる上、Reactのコードを使ってデザインを生成しているため、結果的に実装も兼ねていると言う私にとってかなり理想的なツールです。
ただし、もちろん課題もあると思います。それは、現状だと 「デザイナーが使いこなすには技術的な面で少しハードルが高いツール」 であるという点です。
実際にOnlookを使ってデザインを作ってみて気づいたのですが、裏側が「Reactのコード」で動いていると言うこともあり、結構エラーが発生します。
以下のエラーはフロントエンドエンジニアが見れば「あぁ、useStateが重複してインポートされてしまってるのね」とわかりますが、デザイナーの方にとってはそもそもuseStateという言葉自体が何のこっちゃという感じだと思います。
エンジニアにとっては「エラーを読み解いて問題を分析し、解消する」というプロセスは慣れたものだと思うのですが、普段Figmaでデザインを作っている方にとってはこれが中々ハードルが高いのではと感じました。
この点については、「そもそもAIによる自動生成によってエラーが発生することはないようにする」などのサービス側で裏側のReactのコードをユーザーに意識させないような工夫が必要になってくるのではないでしょうか。
ただ、こうした問題についても時間の問題のような気がしています。
まとめ
いかがでしたでしょうか。
冒頭にあげた「コードを使ってどこまでデザインの作成・管理が可能か」という問いに対してここまで検証してきましたが、Onlookというツールが出てきたようにかなり現実的なアプローチになってきているのではないでしょうか。
生成AIを用いたデザイン・フロントエンド実装の工程の効率化という点は今後も注目していきたいです。
Discussion