社内v0開発の現状
セアと申します。加谷さん、よろしくお願いいたします。
加谷です。よろしくお願いいたします。
今日のテーマはですね、社内v0が流行ってるのかどうか分からないんですが、
とりあえず我々の中で話題ということで、ちょっと話してみようかなっていう感じですね。
結構最近、社内v0、そもそもまずv0が何かっていう話なんですけど、
バーセル社が提供しているプロンプトを送ったら、
いい感じのフロントエンドのコードとそのプレビューが見られるっていう、
AIのサービスなんですけれども、
それの社内のデザインを活用した版みたいなものをですね、
Xだとユビーさんがちょっと呟いてたりとか、
たまたまそれに触発されてなのか、
我々も会社でそういうものを細々と作っていたりというところで、
話せる範囲で加谷さんも作っているとお伺いしましたが、
どんなものを作っているかって聞いてもいいですか。
僕も本当最近作り始めて、
タイミング的にはちょうどユビーさんのツイートが、
ずっと社内でも、
もうちょっとフロントエンドとかデザインシステムとか、
あの辺りメンテナンスしてる人たちが反応してるのとか、
社内のスラックで見てて、
やっぱ需要あるよなっていうところと、
ちょうどそのタイミングで自分の手がちょっと空きそうというか、
もうちょっと社内LMのツールがっつり作る1ヶ月みたいなことをやろうとしてたので、
いいタイミングだったので作り始めました。
先週ぐらいからかな、そのレベルですね。
何作ってるかというと、
プロトタイプ生成の試み
ただ別にセヤさんとユビーの方とも特に変わらないと思いますけど、
やっぱなんかあれじゃないですか、
B2B SaaSとかでデザインシステムとか、
デザインのブランディングとかも含めてやっぱあるじゃないですか、
デザインの型というか、こう作るとかあるので、
V0自体はすごいなと思いつつも、
リアクトなのはまだ良いですが、
あれですよね、テイルウィンドウとシャドーCNとかですよね。
その時点であんまりプロダクト的には使えないので、正直。
なので普通に社内のデザインシステム、
UIライブラリ使った版でV0的なやつがあると、
プロダクトでも使えるよねってところだったりとか、
あとこれ結構多分また先の話だと思うんですけど、
マルチプロダクトとか結構やろうとすると、
デザインの統一性どうやって担保するとか、
例えばフォームのラベルとフォームの使い方みたいなところだったりとか、
そういうルールとか規約的なやつどうやって統一するんだっけって、
結構悩ましくなるなと思ってるんですが、
V0とか社内V0とかその辺とか、
もしいい感じにできるんだったら結構悪いとなるかも。
ちょっとV0、自分たちが定義しているデザインルールにのっとって、
最初からプロトタイプとか出してくれると、
独人性がなくなるという、
そのルールにのっとったコードが最初からバンって出てくる。
そういう効率化の側面もあるし、
ちゃんとデザインの規約を守れるようにするみたいな、
そういう効能もありそうだなという感覚ありますよね。
そうですね。
社内で作るフィギュアとか考えるときには、
規約守らせるみたいなのは期待としてはあるなとは思いますね。
大体どこもそうだと思いますけど、
似てるところの画面のコンポーネントパクってくるみたいなのとか、
やっぱりやりがちだと思うので、
そうすると、例えば新旧の書き方みたいなところとか、
本当はこっちの画面のほうが今のスタンダードに近いけど、
意図せず古いスタンダードのほうのコンポーネントの使い方とかをコピってきて、
それがバーンするとかね。
フォーメーションの使い方これじゃないんだけどな、みたいなのとかね。
どれもありがちな話。
そうですね。私の会社も割と似ているというか、
ちょっと前からプロンプトでデザインプロトタイプみたいなものが作れると、
主にターゲットユーザー、プロダクトマネージャーの人とかで、
そういう人たちが既存のデザインを活用して、
素早くプロトタイプ作れるとありがたいかもみたいな話はもともとあって、
レイアウトとかを組ませるの、
LLMにできるイメージないからなとか、
若干後回しにしてたんですけれども、
ユビーさんのツイートが社内でも話題になりまして、
私もLLMで試してみたら、
レイアウトのパターンとか定義してたら割といけそうみたいな感覚があったので、
取り始めてみたっていうのが緊張っていう感じですね。
作るにあたって最初に、
すでにこういうプロタイプの生成とかを叶えてくれるツールってあるのかなっていうのを、
いろいろ調査してまして、
いくつかそういうデザイン生成系のサービスっていろいろあったんですけれども、
UIザードとか他は名前を出現してしまったんですけれども、
一番目を引いたのは、やっぱりFigmaのAIと、
そもそもV0があるんでV0なんですけれども、
FigmaのAIって今年の6月にConfigっていうFigmaのカンファレンスでですね、
いろいろAI機能がいっぱいバーって出まして、
結構その割と実用的というか、
自動でレイヤーの名前をいい感じにつけてくれるとか、
あとワイヤーフレームとか、
サイトの案みたいなものをフロントから出してくれるみたいなものがあったりして、
かつFigma上でのプロトタイプを作る機能とか、
そういうのが結構実用的ですごい便利だなっていうところと、
なんですけれども、やっぱり現状、
自分たちのデザインを用いてみたいなところはなかったので、
たぶん来年のConfigぐらいでそういう機能が出るんじゃないかなという予感は勝手に持ってはいるんですけど、
現状はなさそうだなというところでしたね。
デザイン生成AIの活用
あと、一応VZeroもプレミアム、
なんか月20ドルぐらい課金すると、
自分のファイルアップロードできるみたいなのがあったので、
ちょっと試してみたんですけども、
外部のコンポーネントを使うとき、
レイアウトが割と微妙、
そんなになんか結構ぼくとつなデザインになるなっていうので、
これならなんか自分でレイヤーを叩くのとそんなに変わんないかなっていうのがあったりとか、
あと気になったのは、
ファイルフォルダーとかで一括でアップロードみたいなのができなくて、
なんかファイル一個一個ポチポチしてアップロードするみたいな感じだったので、
常に自分たちのデザインと同期するみたいな、
なんかそういう使い方が結構難しそうだ、
現状の機能の範囲上はちょっと難しそうだったので、
それなら自分で作る意義もあるかもしれないなっていう感覚でしたね。
この辺のデザインからのAIみたいなものって触ったこととかってありますか?
デザイン間生成AIツールだと、
それこそUIザードとか、
あとガリレオAIみたいなやつとか昔触ったことがありますが、
そんななんか活用はしてないですね、正直対して。
あんまなんか、そうですね、なんかUIザードとガリレオとV0とぐらいかな。
なんかデザインっぽいことやられたかったら結構、
途中からクロードとかに作らせて、
なんとなく参考にするみたいな方とかも一緒にやってた気がする。
V0が出てからはさすがにV0使ってますけど、
それぐらいですかね、
あんまりデザイン作成のみで使うツールとか使ってる人って、
ゼロではないんでしょうけど、
ラックの周りだとそんなにいないかもしれない。
それだったら、先ほどおっしゃってたプロトタイプ、
MVPみたいなお客様とかに紙芝居で見せるMockみたいなの作るのに
V0使うとかCreate使うとか、
あとは最近急にTwitterでXでリパイロット?
リパイロット?リピロット?
リプリ?
リプリとかの、これリーパイロットで一回覚えちゃったから、
何回見てもパイロットになっちゃう。
コーパイロットとか、リーピロットとか、
あとなんだ、GPTエンジニアとか。
MVPではあれは超面白く使うかなって感じはする。
基本的にこのデザイン生成AIみたいな、
ゼロ1のやつやってくれるだけで、
MHだったら今おっしゃったようなV0とかでのほうが良くて、
既存のデザイン資産活かすみたいなところでは特に使えないので、
そんなに出番を感じないっていうのは正直感そうでしたかね。
ですね。おっしゃるようにFigmaが自分たちのファイルとか
ベースにいい感じにやってくれるようになったら、
それを使うんだろうなと思いますが、って感じですね。
そうですね。
どうなんだろうな。
この後の話とかに入っちゃうのかもしれないですけど、
SniV0みたいなの試して作ってみて、
自分たちのサービスではこういうレイアウトよくあるから、
こういうの組みたいねとか、
あとはUIライブラリの引数の指定の仕方というか、
この辺の癖とか、
あの辺とかにうまく追随させようとすると結構苦労するというか、
ナイフを作っても結構いろいろと作り込まないと、
よく間違うとこは間違うというか、
雑なまとめ方するとやっぱTailwindとかShadowCNっぽく
定義してきたりとかしてくるから油断すると。
その辺とかは結局Figmaでコードとなっても、
そのままコピペして今の既存プロダクトに入れると、
結構違和感のある感じになっちゃう。
そうだなみたいなのはめちゃ思いますね。
そうですね。
あと仮にFigmaが自分たちのライブラリ扱えるようになったとしても、
レイアウトを定義するコンポーネントみたいなものってまだなかったりするんで、
要はレイアウトでいうチュールドレインみたいなものを持つっていうのができない。
デザインシステムの課題
一応こういう難しいテクニックを使うとできなくはないんですけど、
なんかそういうのがなかったりとか、
あとデザインシステムのコンポーネントだけっていうよりは、
デザインシステムに入ってない既存のページのデザインを使いたいとか、
なんかそういう要望も割と結構社内の人からありそうだったので、
そうなると弊社って今デザインのマスター管理みたいなのしてないんですけど、
それしないと使えないかもなんとかで、
Figmaがそういう機能を作ってきても、
自分たちがデザインファイルとかをうまく作ってないと、
こんなに使えないみたいな事象もありえそうなので、
そういうとこまで考えると割と最初からコードを使うっていうのを前提にして、
社内VRみたいなものは、
ワンチャンもうちょい長く生き残る可能性はありそうだなみたいなのをちょっと考えてました。
LLMの活用と限界
確かに。
という、ちょっと若干先の話にも入っちゃったんですが、
こういったツールを調査してみて、
自分たちで作る価値もありそうだなっていうところで、
LLMで試してみたんですけれども、
私の所感としてはレイアウトのパターンが結構しっかり定義されてたら、
割とうまくいきそう。
仕様に応じて適切なコンポーネントを選ぶとか、
変はうまくやってくれそうなので、
レイアウトの部分はやっぱりちょっと苦手かなっていう印象があったので、
なのでそこもこういうレイアウトのパターンがあるので選ぶみたいな、
そういう形なら結構ちゃんとしたものがありそうだなという感じでしたね。
なので今管理画面と本番のプロダクトをパターンでちょっと軽く試してみたんですけど、
管理画面とかだと結構レイアウトのパターンかなり決まってるんで、
こんなに手を込まなくても性能出るなっていう感じでしたね。
あと今はとりあえず試すっていう感じだったので、
コードを全部プロンプトにぶっ込むっていう、
そういうやり方で試してたんですけれども、
これでうまくいき続けるならいいと思うんですけど、
多分将来的にはプロンプトに応じてうまいこと引っ張ってくる、
このレイアウトコンポーネントだなとか、
そういう要するにラグなんですけど、
そういうのが強そうだなっていうそんな感覚でしたね。
長谷さんもこの辺作ってみてどうだったです。
僕らもやりたいとかやろうとしてるのは、
結構レイアウトとか、
例えばこういうCSVのアップロードするときの体験とかを
画面こうやって揃えるみたいなとことかがやりたいことでは一つあるので、
そういう画面とかレイアウトとかのパターン結構定義して、
ここで分岐してみたいな感じとかで、
フローエンジニアリングのフローを作るみたいなのを絶賛やってるところです。
僕も一回最初は社内のデザインシステムの、
特にUIライブラリとかの情報とかをスクリプト変えて、
ちゃんとまとまってるドキュメントとかなかったので、
無理やり引っこ抜いてドキュメントをマークダウンっぽくして、
全部プロンプトにぶち込んでみたいなのをやってたんですけど、
単純に結構プロンプトの分行が増えてしまって、
ディファイが固まるみたいな。
プロンプトの分行が多すぎて。
ディファイ、一回ディファイで試してたんですけど、
そのときディファイが固まるみたいな事象になってるとか、
やっぱり遅かったりするので。
確かにな、私も。
シンプルにちょっともったいので、
さっきのレイアウトとか、
ある程度パターンみたいなのを定義するみたいなとことか、
ある程度もう動いて、普通に動いてるというか、
社内のUIライブラリ使って、
ボタンといろんなの組み合わせて、
フォームっぽいの作るとか、
そういうとことかはもう動いてるので、
さっきのレイアウトパターンで分岐して、
例えばフォーム系とかだったら、
別にこのコンポーネントの情報いらないよね、
とかもあるじゃないですか。
ここの情報いらないよね、プロンプトにとか。
みたいなやつとかを、
フロー組んでいるとこに入れて、
ラグは僕もそんなに使わないというか、
やるつもりはない。
デザインシステムの結構、
例えばインフォメーションみたいに出すときに、
独自性と標準化のバランス
アラート1とDangerはこう使い分けたいみたいな、
みたいな情報とかを、
ちゃんとドキュメント化にまとまってたら、
それはそれで持っておいて、
どっかのタイミングでそれを引きに行くみたいなのは、
後々はやりたいなとは思いますけど、
基本作りとしては似てるんじゃないかなっていうのと、
ロングコンテキスト使いたいですよね。
レイアウト分岐すると全然使える。
ディファイで試して、
ポック作ってたら型割っちゃったんですけど。
確かに。
私もロングコンテキストを扱いたかったんで、
Geminiでやってたんですけど、
確かにコード全部の押しでぶっこんでいると、
100万トークン近く使って、
2分ぐらい毎回かかるみたいな、
そんな感じですか。
途中からスクリプト書いて、
いい感じでストーリーブックとかから、
コードのサンプルとか引っこ抜いてきて、
作れたなって、
レイも使ったスクリプト書いて遊んでたんですけど、
そろそろ使ったらめっちゃ遅くなっちゃった。
一緒ですね。
僕もこのページですかとか、
作りたいものみたいなやつ一回入力してもらって、
例えばインプット系とか、
この画面に近いやつですよねってサジェストして、
そこで分岐というか、
みたいなのとかさせた上で、
もう一回要件定義みたいなのしっかりした上で、
もう一回最後コード生成のとこに投げて、
レイアウトタイプみたいなものだったりとか、
に合わせて分岐して、
みたいな感じですかね。
僕、これでいうと、
どうやってるんですかみたいな話してみたいのは、
我々の作ってるUIライブラリのとか、
技術周りとかの影響とかはあるのかなと思いつつも、
何だろう、
絶妙にちょっと癖あるんですよね。
そのコンポーネントの名前とか、
スキスの指定の仕方とかがいい意味で。
その辺とか、
結構間違いがちだなっていうのはありますね。
ロングコンテストとかでやると結構間違えるので、
レイアウトとかある程度分岐して、
ちょっともうちょっと重ねないと精度上がらなかったというか、
よく間違える。
そうですね。
私も訂正してくれたコードを貼り付けたら、
エラーが2、3箇所表示されるみたいなものは割と。
なんかね、
僕らの公開してない話なんで説明しづらいんですけど、
ちょっとそのうちなりの癖があるところとかで、
結構間違いがちだったりとか、
ちょっとコンポーネントの名前とか、
引数の指定の仕方とか、
引数名とかでエラーになったりするんですけど、
これってなんかちょっとうちだと違うんだよなみたいな、
この引数、この指定。
こことここ逆になってるけど、
確かに一般的に考えたら逆でも違和感ないかみたいなものとかは、
結構頑張んないと間違いがちだったりとかをする。
そうですね。
私もちょっと最初既存のプロダクションの既にあるデザインを、
LLMで再現できないかみたいなのをトライしてたときに、
コンポーネントの名前が、
ちょっと具体的に名前忘れちゃったんですけど、
リストを表示するところで全然リストっぽくない名前のコンポーネントを使ってて、
それのせいで全然違うコンポーネントを選ぶみたいなのがあって、
これはもうLLMが悪いっていうよりは、
こっちの名付けがよろしくないなみたいなものがあったりして、
なのでなんていうか。
めっちゃわかりますね。
リスト系のやつやるときやっぱりリストアイテムとかしてくるし、
それわかるんですけど、
うちにリストアイテムはないみたいな。
リストアイテムのほうが確かにあってしかるべき名前。
リストのときにそういうのがないほうが確かに違和感あるかもな、
みたいなののバランスとか。
やっぱりちょっと作ってて、
現実味ないかもしれないですけど、
Web標準とかに名前とか色数のタイプとかを合わせれば合わせるほど、
LLM活用自体はめっちゃ楽にできるんだろうな、
みたいなのがすごい感じるようになってて。
今でいうと多分究極、
シャドーシーンとかに有名なやつとかにちゃんと引数とか、
コンポーネントの名前とか、
細いやつでいろいろあるじゃないですか、
プログレスバー、プログレスローディングなのかスピナーみたいな話とか、
あの辺とかやっぱ変異独自性出すと、
LLMで使うって意味だと結構むずいし、
カーゾルとかでやっぱ行動生成させてても、
やっぱその辺結構間違うんですよね。
独自性高すぎるとか。
だから標準に近いものとかに、
大多数にどれだけ近づけられるかみたいなのが、
これからは設計としては結構大事なんじゃないかな、
みたいなのをめちゃくちゃ感じてると思います。
面白いな。
その辺をもはやLintのルールにできたりとか、
そういう話になってくると結構面白いですね。
そう、めっちゃありますね。
サイズMDとかやっぱ指定結構してくるんですけど、
我々はそんな指定をしてないみたいな。
ボタンのサイズとかね。
はいはいはいはい。
我々のコンポーネント、例えばボタンには、
社内V0開発の課題
そのプロパティはありませんよみたいな。
そういうのとか結構、
そういうのとか結局FewShotとかで潰したりとかするときに、
ロングコンテクストやりすぎると、
単純さっきのトークン数が多すぎて、
今だとDefiがまず重たいみたいな。
Defiはもう使って、
どんどんどんどんどんどんどんどんどんどんどんどん、
Defiはもう使ってないというか、
最初のPoC的なとこでしか使ってないから、
別に移せばいいんですけど。
あと僕話してみたかったのは、
プレビューめっちゃだるいんですけどっていうコードプレビュー。
はいはいはい。
あれ、セヤスさんXの投稿見たんですけど、
React Live使ってます?
そうですね。Reactっていうのでやってますね。
あれ割とたまに表示できなかったときのエラーが何なのか、
分かりづらかったりはするんですけど、
そんなに手間なく表示できたんで、
今のところあれでやってますね。
React、僕あんまりその辺、フロントのその辺詳しくないので、
あれなんですが、React LiveのCSS、
React Liveに渡してコードプレビューするコードの
CSSのスタイルの定義って、
スタイルDコンポーネントみたいなやつしか対応してないですよね、これ。
スタイルDって読むのかな、これ。
何て読むのかな。
多分スタイルドコンポーネンツってやつです。
スタイルドか。
多分ちょっと動かさないとあれなんですけど、
弊社だとTailwindを使ってて、
TailwindはCSSなんでっていうのもあたつですけど、
割とそのままスタイリング当ててくれるんですけど、
多分コンポーネント以外のJSのオブジェクトも、
React Liveのスコープっていうのに入れたら動いてくれる。
Zotとかも動いてくれたんですけど、
フォームのバリエーションのやつですね。
なので、もしかしたらそれを入れたら動くかもっていう感じですね。
そうですね。スコープ、僕ら話していい気がするんですけど、
スタイルドコンポーネントは使ってないんですよ。
エモーションなのかな、使ってるのは。
エモーションは動かなかったんですよ、スコープに入れても。
CSSの、エモーションReactのCSSとかをスコープに入れても動かなくて、
スタイルドコンポーネントの書き方。
で、React Liveに渡したら動くんですよ。
Zotしかいない。ほぼドキュメントがないですけど。
あんまり。
でも、確かにスタイルドコンポーネントとか、
Tailwindっぽいやつしか書かれてないし、
そこのカスタマイズみたいな話とかはないので、
そもそも対応してないのかなと思っていて、
そうするとコード自動生成的には、
スタイルドコンポーネントとかTailwindとかでやられても困るんですよ。
変換しなくてはいけないから。
だからそれどうしようかなと思ってて、
自前でコードプレビューとか書きたくないな。
React Liveも対応してなさそうだったら、
ワンチャンでもCSSのスタイルドのやつをエモーションで変換するぐらいは、
さすがに間違わなそうだから、
プレビュー版とコピーする版みたいな面白い、
無理やりコード分けてしまうかとか、
CSS分だけ引っこ抜いてきてそこ書き換えるとか、
やる方が早いのかなみたいなのを潰さなきゃいけないですね。
なるほど。
絶望でした。
なるほどな。
利用技術によって大変な部分が出てくると。
だから僕もし新規でやるんだったらフロント、
他のこと何も考えてないですけど、
Remixing、ShadowCNにTailwindにとかを多分使える。
やっぱり手元とかでコード書いてる感覚、
コードの規模とか量とかいろいろ違いますけど、
Remix、ShadowCN、Tailwindみたいな構成で作ってるプロジェクトのほうが、
カーソルとかの自動生成のコードも再渡ってるなって思うので、
その辺とかやっぱりちょっと技術選定もし次する機会があったら考えるなっていうのを
すごい感じるきっかけにはなりました。
そうっすよね。
この辺のフロントに限らず生成愛フレンドリーな、
要するにもう市民権を得ている技術を選びたくなるというか。
そうなんですよね。
やっぱりRemixとかの辺とか使ってると本当に綺麗に書いてくれる。
アクションファンクションとかの辺とか怪しいけど、
UI周りとかは全然もういい感じなんですよ、Tailwindとかと。
そこは今一番困ってるのはコードプレビュー。
それ以外のところは作り込めばいいかなって感じ。
作り込んでさっきのレイアウトのパターンとか、
うちで一番よく使われるやつだったりとか、
こういうルールにしたいみたいなのをちゃんと作り込んで、
自動更新とかメンテできるようにしておけば全然良さそうだなと思いつつ、
コードプレビューですね、僕の場合は。
せやさんフロントエンダー強そうだから、
僕にコードプレビューの作り方を全部してもらえると。
最初バブル.トランスフォームとかで無理やりやってたんですけど、
これもちょっとやりたくないなっていう。
私も最初検討しだるすぎるなって思って、これ実行する。
ちょっとね、Ugoiって言いとくところまでは作ったんですけど、
ちょっと面倒くさくなって。
でも意外とReactライブ以外のなんかないんで。
そうですね。
あんまり。
みんなどうやってやってるんだろうな、コードプレビュー系のやつって。
そうですね。
V0とUBIさんのやつはどうやってるんだろうか。
Reactランナー。
Reactランナーっていうのもあるのかな。
Reactライブと。
Reactランナー、Reactライブ、サウンドパック。
やばいな。
Reactライブダメだったらもうこの世に2つしかないかもしれない。
このぐらいの選択肢は。
いい感じのやつもし見つけたら教えてください。
はい。
情報共有、AIアプリあるあるというか、そんなにAI関係ないところで詰まるという。
ですね。
じゃあ今日はそんなところで、割とこの社内V0を取り組んでいる方、
技術選定と自動化
とりあえず我々は2分の2で取り組んでいたので、もしかしたらちらほらいるかもしれないので、
多分やらないですけど、社内V0試験交換ミートアップとか。
やらないのか。
ちょっとこのポッドキャストの。
ちょっとミートアップだと、さすがに人数が少なすぎる気がする。
飲み会ぐらいかな。
飲み会とかだったらLT大逆ね。
はいはい。
登壇側は社内V0作ってる人の、私たちの考える最強のV0みたいな。
バーサスLTみたいなやったら成立しそうだなと思いますけど、
ミートアップだと人数が少なすぎる気がしますね。
そうですね。ご興味ある方、このポッドキャストのコメント欄にコメントください。
つぶやいてください。
今回はそんなところで、ありがとうございました。
はい、ありがとうございました。
