THE UI EXPERTS - AIとMCPの現在地
https://gyazo.com/3dbe96f01fd7e09c27be22ea784d93aa
バクラクのUI開発
爆速開発、半年に1個のペース
UIエキスパートでなくてもUI開発できるようにしたい
デザインシステム
ガイドライン
デザイントークン
アイコン
UIコンポーネント
UIパターン
昨今の開発
AIによる開発が当たり前になっている
MCPの登場によりAIが外部リソースを利用できるようになった
UIコンポーネントを使ってくれない、独自の実装になってしまう
コンポーネントの情報は多いので全部突っ込むと不必要な情報が多くなる
MCPだと概要→詳細とドリルダウンっしていくので必要十分な情報を参照できる
プロンプト
FigmaのURLを渡す
AI側で詳細な動きをドリルダウンしていく
MCPの内部実装
Storybookをデータソースにする
資産を活用する
ソースコードをそのまま返すのは大変
Tools
コンポーネント一覧
サイドバーにある情報を返す
詳細情報
使用感
UIの再現度は70点くらい
座標情報を間違えてそう
UIコンポーネントやデザイントークンの使い方は比較的精度高め
UI以外の情報（インタラクション）を伝えるのが難しい
日付フォームだからDatePickerで判断するのは難しい
今後の展望
星５つで評価してもらえる感じに
段階的実装記録
前提
社内ではUIコンポーネントがnpm packagesとして整備されていた
Storybookのカバー率高め
addToolで登録していく
利用フローの想定
引数modeで一覧、詳細
実装1
catで最小限実装
catで一覧を返す
モノレポ構成だったのでパッケージを参照しやすい
Storybookファイルをcatで提供する
これだけでもきちんと使ってくれている
課題
Propsが渡せていない
Unionだと何を渡せばいいのかわからない
tokenが無駄になった
実装2
Props型を提供
Props型が取れるようになった
課題
コーディング精度が落ちる
実装3
Storyの提供
token数は増えたが動作には問題ない
知見
人間が読みやすいフォーマットで返している
必要な情報はそこにある
追加情報が必要なら人間が書くべき
やりたいこと
インプットがスクリーンショットなのでFigmaにしたい ファインディのMCP x UIの話
Lo-Fiプロトタイプの作成に使っている
プロジェクトフォルダにフォルダが生成されてmdが生成
ローカルに設置したTokenやReactコンポーネント情報を元に作られる
企画からLo-Fiまでは高速化できたがそれ以外はできてなかった
大量の文脈との扱い
文脈をどうマネジメントしていうのか
Contextとどう向き合うか？
10万Tokenは使える、100万もいけそう
どの文脈で使われているかわからない
出来上がった後に何を参照したのかを聞いている
なんでもかんでもぶち込んでいいわけではない
だれがマネジメントするのか？デザイナーの使命
あらゆる文脈を扱えるようになる
デザイントークン、Reactコンポーネント、アイコン集が含まれる
OSSで公開
課題
Ubie Vitalsのことを知らない
適切に使ったUIを構築するために手直し・書き直しが必要
施策を打つチームとUI実装が開発のボトルネック
社内に公開
インターナルに配布、npx経由でローカルで実施
UI実装が2~3倍早くなった
解空間を狭くできる
目的に会うように道具の表現力を弱くする
ユビーっぽい
出力確度・提案精度を上げるコツ
整ったものをつくるのはどうする？
デザインシステムに則ったStack、Flexの命名をちゃんとするとマシになった
人間だと思って接した方がいい
ちょっと違う動きがしたら誤解の余地があるなとわかる
何をしたいのか、会社・目的次第
今まで自動でできたことの固定概念を取っ払ってみる
AIアプリ自体に無茶をさせてみる、実現してもらいたいことを壁打ちしてもらう
どういうデザインデータであると実装しやすいか
デザインする時にも開発を知っておく必要がある
やるべきこととやらないことを明確に分けていく
リスクがある状態を認識して使っている