はじめに
OPTiM Support & Growth Portal（SGP） のフロントエンドを開発している亀田です。フロントエンド推進室の運営メンバーも務めています。
（フロントエンド推進室は2025年度の10月に発足した社内横断組織で、全社のフロントエンド（製品・人問わず）をより強化し良いものにすることをミッションとしています。）
目次
- はじめに
- UI自動生成に興味を持ったきっかけ
- 前提-私のAI活用アプローチ
- Figma MCPでUI生成を試みる
- 改善プロセスの全体像
- 課題の分析で特定した6つの課題
- 課題の自然解決と新ツールの登場
- Skillsによる課題解決
- 残った課題とfew-shotによる最終改善
- 結果
- おわりに
本記事について
「AIにUIを作らせたい」
そう思ったことのあるフロントエンドエンジニアは多いのではないでしょうか。
本記事では、AIによるUI自動生成に取り組んだ実験の全過程を紹介します。Figma MCPとの出会いから始まり、失敗と課題分析を経て、最終的に Skills と few-shot（少数の実装例をAIに参照させるプロンプト手法）を組み合わせる手法にたどり着きました。この組み合わせにより、ほぼ修正不要なUIを生成できるレベルが見えてきました。
この記事を通じて、「AIにUIを作らせるにはどんな知識が必要で、それをどう補うか」という考え方を共有できればと思います。
補足
本記事で扱うUI自動生成は、Presentationalレベル（見た目のみを担当する）コンポーネントが実装対象です。 ロジックを含むContainerコンポーネントは対象外です。
UI自動生成に興味を持ったきっかけ
UIのAI生成に活用できると考え始めたのは、2025年4月のことです。きっかけは以下のUbieさんの記事でした。
社内デザインシステムをMCPサーバー化したらUI実装が爆速になった
当時は MCP（Model Context Protocol：AIとツールを接続するためのオープンプロトコル）が登場して間もない時期で、「MCPってなに？」という状態でした。記事を読んで「そんなことができるのか、MCPいいな」と感じたのを覚えています。
前提-私のAI活用アプローチ
本題に入る前に、私がAIを使うときに共通して行っている方法を紹介します。この考え方が記事全体の基盤になっています。
- まず、自分が何かを作る際に参考とする情報や知識を集める
- 「これだけあれば自分なら作れるな」という状況になったら、AIに作らせる
- AIの成果物がうまくいっていない場合、何がうまくいかなかったのか・何が欲しかったのか を洗い出す
- プロンプトを調整して再度生成させ、成果物を見て上記を繰り返す
この反復プロセスによって、AIの出力精度を上げていきます。この手法は、事前に答えを自分自身が知っていることが重要です。頭の中にある答えとAIの出力が完全に一致し、かつAI出力までの労力がゼロに近ければ近いほど良いというイメージです。したがって、答えがないような場合はまた別の方法を考える必要があります。
Figma MCPでUI生成を試みる
Figma MCPの調査
Figma MCPは有料ツールだったため、使用申請を出す前にフロントエンド推進室メンバーの有識者に確認しました。そのときに聞いた話では、Figma MCP単体での精度は高くないとのことでした。例えば nucleus（社内のデザインシステム）を意識した実装はできないという話でした。それでは困ると思い、一度使用を見送りました。
また、お昼の同時視聴会で「Figma MCPだけではUIは作るのは難しい。デザイントークンとの連携を人間側で補助する必要がある」という話を聞きました。
補足: 同時視聴会について
同時視聴会はフロントエンド推進室が推進する活動のひとつです。ランチタイムや夕方〜夜に開催されるテック系イベントのうち、リモート視聴できるものを対象としています。社内の興味のある人を集め、時には知見を活かせそうな人も誘って、みんなで物理的に同じ場所で一緒に視聴します。
Figma MCPに触れてみる
しばらくして、フロントエンド推進室メンバーがFigma MCPの活用を推進し始めたことを契機に、私も使用する機会を得ました。まずはUIを生成するのに必要な情報の整理から着手しました。
最初の生成に必要な情報の整理
前述のアプローチに沿って、まずUIを生成するのに必要な情報を洗い出しました。
- Figmaのリンク
- UIの仕様（バリデーションルールや活性・非活性の条件など）
当時用意できたのはこの2点だけでした。MUIコンポーネントの使い方やデザイントークンは、実装しながら都度確認するものであり、事前に整理されたものがなかったため、含めませんでした。
結果: 失敗
結果は以下の通りです。全くうまくいきませんでした。
- AIがMUIコンポーネントをほとんど使わなかった
- AIがデザイントークンをほぼ適用しなかった
- コンポーネントの分割粒度が不適切だった
- React Hook Formなどのライブラリの使い方を誤っていた
事前に聞いていた「Figma MCP単体では精度が高くない」という話の通り、想定どおりの結果でした。だからこそ、「足りないのはAIに与える知識なのでは？」という仮説が裏付けられました。
改善プロセスの全体像
以下は、今回の実験の全体的な流れを示したタイムラインです。
課題の分析で特定した6つの課題
最初の失敗から、以下の6つの課題を特定しました。
| # | 課題 | 補足 |
|---|---|---|
| 1 | AIのレベルが低い | 時間が解決するだろうと予想 |
| 2 | MUIの知識が足りない | 膨大な知識量のため自分で用意するのは困難 |
| 3 | デザイントークンの知識が足りない | Nucleusのトークン体系をAIが知らない |
| 4 | Reactの実装知識が足りない | ベストプラクティスに沿った実装ができない |
| 5 | ライブラリの知識が足りない | React Hook Form、zod、nuqsなどプロジェクト依存のライブラリ |
| 6 | アーキテクチャの知識が足りない | Container/Presentationalパターンなど |
自分が実装するときには上記をすべて考慮しているわけですから、AI側にも当然これらの知識が必要です。端的に言えば、6つの課題が残る以上、Figma MCPとAIを組み合わせただけでは不十分 であることがわかります。
few-shotへの着目
回避策として当時考えていたのが few-shot です。既に開発では、ボイラープレートを解消するためにfew-shotを活用したプロンプト（カスタムコマンド）の実績がありました。そのため、この手法は使えるという確信がありました。
改善を一時保留に
次は改善フェーズに進みたいところでしたが、当時は難しいと判断しました。理由は2つあります。
- AIのレベルがまだ低かったこと
- UIを作るための知識があまりにも多すぎたこと（特にMUIの知識を自前で用意するのは現実的ではなかった）
そのため、一旦保留とすることにしました。AI業界の急速な成長を考えると何かしら解決策が出てくるだろうという予想と、当時は工数を確保できなかったことが理由です。
課題の自然解決と新ツールの登場
しばらく経つと、一部の課題が自然に解決されていました。課題の状況を更新してみます。
| # | 課題 | 状況 | 解決手段 |
|---|---|---|---|
| 1 | AIのレベルが低い | 解決 | AIモデルが大幅に進化した |
| 2 | MUIの知識が足りない | 解決 | MUI MCPが登場した |
| 3 | デザイントークンの知識不足 | 未解決 | ── |
| 4 | Reactの実装知識不足 | 未解決 | ── |
| 5 | ライブラリの知識不足 | 未解決 | ── |
| 6 | アーキテクチャの知識不足 | 未解決 | ── |
課題1と2が解消されたことで、「残りの3〜6をどうにかすればUI生成ができるのでは？」という状態になりました。
そこに Agent Skills（以降Skillsと呼称） が登場しました。これで一気にUIの自動生成が現実味を帯びてきました。Skillsとは知識やルールをAIエージェントに教えるための仕組みで、エージェントに新しい能力や専門知識を与えるためのオープンスタンダードです。
Skillsによる課題解決
課題3〜6はすべてSkillsで解決できる範囲でした。実際に以下のSkillsを作成しました。
| 課題 | 作成したSkills | 内容 |
|---|---|---|
| 3. デザイントークン | デザイントークンSkills | nucleusのトークン体系をAIに教える |
| 4. React実装 | useEffectアンチパターンSkills | よくあるuseEffectの誤用パターンを定義 |
| 5. ライブラリ知識 | React Hook Form / zod / nuqs Skills | 各ライブラリの正しい使い方を定義 |
| 6. アーキテクチャ | Container/Presentational Skills | コンポーネント設計パターンを定義 |
課題4については、AIモデル自体が賢くなったことで、そこまでおかしな実装にはならなくなっていました。ですので問題になりそうな useEffectのアンチパターン をSkills化する方針としました。
残った課題とfew-shotによる最終改善
Skills導入後の結果
課題への対策を講じたうえで、もう一度AIにUIを生成してもらいました。今度はかなり改善しましたが、まだ十分ではありませんでした。
残った課題を整理すると、以下の2点でした。
- React Hook Form・MUIの使い方が一部間違っていた
- 共通コンポーネントを使用せず独自実装してしまっていた
原因としては、AIが参考にする既存コードベースの中に誤った実装があり、それを正として学習してしまうことが考えられました。すべてのコードをリファクタリングすることは現実的ではなく、正しい実装だけを参照させるのも困難です。
few-shotで解決
この課題に対しては、few-shot を使うことで解決できると考えました。
具体的な方法は以下のとおりです。
- プロジェクト内に exampleフォルダ を作成する
- 頻出UIパターンの 正しい実装例 を配置する
- 各UIの 説明をカタログ化 する
- AI実装時に、まずカタログを確認させ、FigmaのUIと最も近いExampleをマッチング させる
- マッチしたExampleを参考に実装させる
これにより、既存コードベースの間違いに引きずられることなく、正しい実装パターンに基づいたUI生成が可能になりました。
設計Skillsの導入
加えて、AIと二人三脚でUIの設計を行うSkillsも導入しました。これまで準備してきたSkillsへのエイリアスとUI設計の知識を与えることで、AI駆動で設計を進めつつ、不明点があればAIから質問してもらう形で精度を向上させました。
結果
Exampleカタログを導入した状態で再度生成したところ、ほぼ修正不要なUI ができあがりました。バリデーションやフォームの状態管理といったロジックも意図どおりに動作しました。
使用したモデルは「Claude Opus 4.6」です。
作成着手（生成に必要な情報を集めてプロンプトを入力するまで）から生成完了までは10分ほどでした。同じコンポーネントをAIなしで実装すれば、おそらく1〜2時間以上かかると思います。
最終的な生成結果とFigmaの比較は以下のとおりです。
実装：
Figma：
設計Skillsによる対話の様子
設計Skills実行時には、AI側から不足した観点について以下のように質問してくれます。今回はバリデーションに加えて、Figma側の誤りも伝えてみましたが、柔軟に対応してくれました。
なお、今回は質問の動きを確認するためにあえて設計書を渡していません。Skills側ではまず設計書を求めるように設計しており、設計書を初めに渡せばこのようなやり取りなしに一息で実装することも可能です。
おわりに
わかったこと
今回の実験を通じて、AIによるUI自動生成で重要なのは以下の3点だとわかりました。
- AIに必要な知識を明確にする： 自分がUIを作るときに何を考慮しているかを言語化し、それをAIに渡す知識として整理する
- 解決手段を適切に選ぶ： MCP、Skills、few-shotなど、課題の性質に応じたツールを使い分ける
- すべてを一度に解決しようとしない： AIの進化やエコシステムの成長を待つことも有効な戦略
今後の展望
現時点では2つのコンポーネントでしか実験できていません。また、few-shotのExampleカタログは人間が用意する必要があります。ただし、ある程度の型ができればカタログ作成の多くはAI自身に任せられると考えています。
また、設計はAIだけに任せず二人三脚で進めているため、完全自動化と比べると実装スピードの面では課題が残ります。とはいえ、現在のAIのレベルを踏まえると、UIの設計に人間が介入すること自体は妥当な判断だと考えています。
整理すると以下が展望です。
- Exampleカタログを拡充し、対応できるUIパターンを増やす
- 生成品質の定量的な評価指標を整備する
- チーム全体への展開と知見の共有を進める
- Storybookの自動実装を実現する
オプティムでは、AIとフロントエンド技術を活用したアプリケーションを開発しています。 ご興味のある方は、ぜひ一度ご連絡ください。
