はじめに
こんにちは、ログラスの南部です。
AIを活用してフロントエンドを開発していて、画面の動作や遷移を伝えるのが難しいなと感じたことはありませんか？
Figmaなどのビジュアルデザインツールは、画面の「見た目」を定義する上では強力です。しかし、ユーザーの操作による「動作」や「遷移」になると、MCPでの連携や画像の提供に加えて、さらに個別に自然言語での指示が必要な場合があります。
私は常々、デザインも動作も一度に渡して一気に開発できないかなと思っていました。
そこで今回、YAMLスキーマを試作し、複雑なダッシュボード画面で検証してみました。結果として、タブ切り替え・モーダル開閉・フォームバリデーション・トースト通知といった振る舞いを、AIが正確に解釈してReact + MUIのコードを生成できました。
ひとつのアイデアとして参考にしていただけたら幸いです。
仮説：「振る舞い」をテキストで定義すれば伝わるのでは？
AIは原則テキストとの相性が良いです。なので、画面についての情報をテキストで渡すことができればコード生成の精度が上がるのでは？と考えました。
画面の構成・動作・遷移を構造化テキストで定義すれば、AIが正確に解釈できるはずです。
この仮説を検証するため、YAMLベースのプロトコルを試作してみました。
試作：画面振る舞いプロトコル（SBP: Screen Behavior Protocol）
Screen Behavior Protocol(以下、SBP)というものを試作してみました。
プロトコルといっても通信に使う意図はなく、デザイナーとエンジニアが画面について会話するためのプロトコルになるといいなという意味を込めて名付けました。
コンポーネントの名前はMaterial UIを参考にしています。そのため、実装にはMaterial UIを使うと一番威力を発揮する想定です。
まだまだ仕様は曖昧ですが、少なくとも検証段階でAIに渡す分には困らないかと思い一定の曖昧さは許容しています。
書き方の例
# 商品一覧・詳細画面の例
#
# ┌─────────────────┐ ┌─────────────────┐
# │ 商品一覧 │ │ 商品詳細 │
# ├─────────────────┤ ├─────────────────┤
# │ ┌─────────────┐ │ │ 商品名 │
# │ │ 商品A → │─┼─────→│ ¥1,000 │
# │ └─────────────┘ │ │ │
# │ ┌─────────────┐ │ │ [カートに追加] │
# │ │ 商品B → │ │ │ │
# │ └─────────────┘ │ │ [← 一覧に戻る] │
# └─────────────────┘ └─────────────────┘
screens:
ProductList:
# 動作: 状態の定義
state:
products:
type: Product[]
source: external
# 構成: UIの構造
layout:
- List:
for: product in $products
children:
- ListItem:
content: $product.name
# 動作: クリック時の処理
on:click: "navigate(ProductDetail, { id: $product.id })"
ProductDetail:
params:
id: string
state:
product:
type: Product
source: external
layout:
- Typography:
variant: h1
content: $product.name
- Typography:
content: $product.price
- Button:
label: カートに追加
on:click: addToCart($product.id)
- Button:
label: 一覧に戻る
on:click: navigate(ProductList)
# 遷移: 画面間の移動ルール
flows:
ProductFlow:
initial: ProductList
transitions:
- from: ProductList
to: ProductDetail
trigger: navigate(ProductDetail)
- from: ProductDetail
to: ProductList
trigger: navigate(ProductList)
このシンプルな記述で、AIは「一覧表示→詳細画面への遷移→パラメータ渡し→外部データの取得→カートへのアクション」といった基本的なアプリケーションの振る舞いを理解できます。on:click: navigate(ProductDetail) のように、意図（何をしたいか）と作用（どう動くか）が明確に分離されているため、AIが解釈しやすい構造になっています。
検証：想定されるSBPを使った開発フロー
想定する開発フロー
現実的に考えて、デザイナーがいきなりSBPを書くといったことは難しいかなと考えています。
1番想像しうる使われ方としては以下のフローに示す通りと考えます。
1. デザイナー → Figmaでデザイン作成
↓
2. Figma → AIでSBPのベース生成（構造部分）
↓
3. エンジニア + デザイナー → 振る舞い・遷移を追記
↓
4. SBP → AIでコード生成
このフローをシミュレーションして、SBPの有効性を検証して行こうと思います。
検証用の画面：分析ダッシュボード
SBPの威力を試すため、動作・遷移が複雑な画面を用意します。
動作の複雑性が高い画面であることを重視しているので、アプリケーションとして良いデザインかどうかは考慮していません。
ステップ1: Figmaでデザイン作成
画面構成：
- ダッシュボード: タブで概要/売上/ユーザーを切り替え、カード表示
- データ管理: テーブル＋CRUD操作（編集モーダル、削除確認）
- 設定: トグルスイッチによる設定変更
含まれるコンポーネント：
- サイドナビゲーション（ページ遷移）
- ヘッダーメニュー（通知ドロップダウン、ユーザーメニュー）
- タブ切り替え（ダッシュボード画面内）
- テーブル → 行アクション（編集モーダル、削除確認）
- トースト通知
ステップ2: SBPでコンポーネント構造を書く
Figmaデザインを元に、AIでSBPのベースを生成します。
ステップ3: 振る舞いを追記
ここがSBPの本領発揮。Figmaだけでは伝わらない「動き」を定義します。
定義した振る舞いの例：
- 「通知バッジは未読数を表示し、クリックで既読にする」
- 「編集ボタンでモーダルを開き、保存成功時にトースト表示」
- 「削除は確認ダイアログを挟み、失敗時はエラートースト」
- 「フォームは名前が空 or 値が0以下なら保存ボタンを無効化」
状態定義（state / computed）：
アクション定義：
画面遷移定義（flows）：
ステップ4: Claude Codeでコード生成
SBPのファイルだけ渡してSBPの仕様と一緒に渡し、以下のプロンプトでClaude Codeを使って開発してみました。
与えたプロンプト:
dashboard.sbp.yaml をReact MUIを使って実装して
SPEC.mdにSBPの仕様はあります
結果以下のようなアプリケーションが完成しました。
画面構成でいうと概ねFigmaデザイン通りですが、ヘッダーの長さが明らかに短く左側に余白があります。
そして大事なのはふるまいですが、定義した通りに動くかを確認すると、以下の動きを全て満たしていました。
- サイドナビでページ遷移（ダッシュボード→データ管理→設定）
- タブ切り替え（概要/売上/ユーザー）
- ドロワー開閉
- 編集モーダル開閉
- 削除確認ダイアログ表示
- トースト表示
- フォームバリデーション
- 保存成功/失敗時の分岐
N=1ではありますが振る舞いに関してはこのくらいの複雑さであれば一定適切に読み取って実装できそうということがわかりました。
ヘッダーの長さについても修正は簡単なレベルの誤差と捉えられる範囲かなと思います。
なぜSBPはAIに正確に伝わったのか
SBPが高精度でコード生成できた理由として、以下が考えられます。
- 意図と作用の分離:
on:click: navigate(ProductDetail)のように「何をトリガーに」「何が起きるか」が明確 - 状態の宣言的定義:
computedで派生状態を定義することで、AIが状態管理ロジックを推論しやすい - 構造の一貫性: YAMLの階層構造がそのままコンポーネントツリーに対応するため、変換ロスが少ない
従来の自然言語指示では「モーダルを開く」「成功したらトースト」といった記述が曖昧になりがちですが、SBPでは editModalOpen: true や toast: { message: "保存しました", type: success } のように、状態変更として明示的に記述できます。
まとめと今後の展望
今回の検証で、YAMLベースのプロトコル（SBP）を使って画面の振る舞いを定義し、AIにコード生成させるアプローチが一定有効かもしれないことがわかりました。
わかったこと
SBPは、UI開発における「動作ロジックの翻訳ロス」という課題に対応できる可能性があります。
これまでデザイナーとエンジニアの間では「ボタンを押したら何が起きるか」といった振る舞いの認識が曖昧になりがちでしたが、SBPを使うことで構造化テキストとして共有できるようになります。Figmaでは表現しにくいdisabled条件やエラー時の分岐なども明確に定義できます。また、AIへの指示も「モーダルを開いて」という曖昧な表現から「set editModalOpen to true」という明確な状態変更に変わるため、解釈の揺れがなくなります。
今後の展望
今回のダッシュボードでは一定の複雑さを持つ画面で検証できましたが、今後はリアルタイム更新や認証フローなど、さらに複雑なアプリケーションでも検証してみたいと考えています。また、デザイナーとエンジニアが共同でSBPを編集するワークフローを実際のプロジェクトで試して揉みたいと思っています。
また、SBPがテンプレートとなり、事前に必要な動作を検討し切れるので、画面実装におけるシフトレフトにも繋げられるのではと考えています。
そして現時点ではSBPの仕様がまだ曖昧で、人間が一から書くには難しい状態です。今回の検証でもAIにベースを生成させてから手を加える形を取りました。今後は仕様をより厳密に定義して、人間でも迷わず書けるようにしていきたいと考えています。画一的な書き方ができるようになれば、書きやすく読みやすいものになるはずです。
実際の開発現場で想定される課題
一方で、実際の開発現場に導入するにはいくつかの課題もあります。既存プロダクトに途中からSBPを導入するのは難しく、新規開発向きのアプローチだと感じています。また、コーポレートデザインやデザインシステムとの統合には工夫が必要ですし、色や余白、アニメーションといった細かいデザインのカスタマイズは別途指定する必要があります。SBP自体の学習コストも考慮しなければなりません。
まだ実験段階ですが、「動くUIをAIに伝える」という課題に対する一つのアプローチとして、引き続き試行錯誤を続けていきます。皆さんも画面の振る舞いをテキストで定義してAIに渡してみてはいかがでしょうか。
検証用SBP: https://github.com/gonambu/screen-behavior-protocol/blob/6752f9a/examples/dashboard/dashboard.sbp.yaml
生成されたコード: https://github.com/gonambu/screen-behavior-protocol/tree/6752f9a/examples/dashboard/implementation
Discussion