こんにちは、AI ShiftでUI/UXデザイナーをやってる後藤です。この記事はAI Shift Advent Calendar 2025の21日目の記事です。
この記事は、Figmaの使用をいったん停止して、AIとコードでUIデザインをするとどうなるのか、という経過報告です。
実験の途中ですので、まだ成功も失敗もはっきりしておりません。なので、本日18:30からのM-1グランプリをご覧になった方がより楽しい休日をお過ごしになられるかと思います。
結論から言うと
「デザインと実装の境界をなくした」 ことで、UIデザインの時間を「考える」に全振りできるようになりました。
そして、これからの私は課題や価値の探索というUXデザインのタスクに、多くの時間を費やしていくんだろうなと思いました。
具体的には、UIデザインを手を動かして作る時間がほぼゼロになり、考える時間を増やすことができました。様々なパターンのUIを検証できるようになったのでトライアンドエラーの回数も増えました。
クオリティが上がったかどうかはまだ判断できませんが、納得感のあるものになっていると思います。
では、わたしはなぜこんな事をするに至ったのでしょうか。
きっかけ
弊社はAI使いまくりが推奨されておりまして、AIの使用を躊躇ったりしようものなら
「もっと使おうよ！ね、使お！」
と強めに励ましてもらえる稀有な企業だと思います。
私はそこで3つのプロダクトのUI/UXデザインを1人で担当しておりまして、UIデザインはFigmaを使って手作業で行っておりました。
しばらくは持ち前のハッタリと誤魔化しのウマさでなんとか乗り切っていましたが、Claude Codeの登場あたりからでしょうか。急に潮目が変わり始めまして、あれよあれよという間に私がチームの完全なボトルネックとなってしまったのでした。
「負けるな。頑張れ。」
そうやって自分を励まして過ごしました。
しかしこのままではかなりマズい状況になりそう、いや既に悲劇は始まっていたのですね。
開発チームはコード生成にもレビューにもAIを使い、開発速度がどんどん上がっていきます。大変素晴らしいことですね。しかし完全にデザインが追いつかなくなりました。開発チームを待たせてしまう焦りから、私は遠くを眺める時間が次第に増えていき、気がつくと「自分の仕事って何だっけ？」という問いが頭をよぎりました。
仕事を分解してみた
ピンチはチャンスです。いったん立ち止まって、自分の仕事を整理してみることにしました。
私の仕事を大きく分けると、このような感じでしょうか。
- 探索：ユーザーの価値・ペインを見つける（UXリサーチ）
- 考案：解決策を考える
- 形にする：UIに落とし込む
改めて気づいたことは、探索や考案に時間を全く使うことができていません。
そして、いま一番コストがかかってるのは形にするということです。
「形にする」コストの正体
最初は「手の速さの問題かな」と思いました。たしかに私は手が速くないです。
でも、どうやらもっと深いところに問題があるようです。
1. 試行錯誤の不足
振り返ってみると、1人でやってることもあり、時間に追われてトライアンドエラーを十分にやり切れていなかったと思います。「より良い形はなんだろう？」と考えて試す回数が少ない。妥協してOKを出してしまうことが多くて、クオリティにも影響していたように思います。
2. デザインと実装の分断
もっと根本的な問題は、現状のままFigmaでデザインをいくら効率化しても、フロントエンドの実装工数は変わらないということでした。あたり前かもしれませんがデザインと実装が完全に分かれている構造的な問題です。
Figmaじゃないとダメなのか？
「そもそもFigmaって何のためにあったんだろう？」
改めてそう思い返してみると、Figmaで何かを作るとこのような会話が始まります。
- 何を作ろうとしているのか
- どうやって作れば良いか
- どんな障壁がありそうか
- 実現可能性は？
- どれくらい時間がかかりそうか
つまり、 「議論の題材」 という中間生成物としての役割です。
「何を、どうやって、いつまでに、誰が、作るのか、売るのか、使うのか」チームでこれらを共有できればOKなので、この役割は必ずしも Figmaじゃないと無理！ というわけではありません。
今の状況を打破できる案として真っ先に思いつくのはCursorなどを使いコードでUIを作ることです。FigmaにもFigma Makeを使ってコードを生成する機能がありますので、Figma MakeとCursorを使う方法を比較してみます。
実際はこんなに単純に進むわけではありませんが、私の中で時間軸や工数感はこのようなイメージです。
Figma Makeを使うとUIデザインの工数には大きなインパクトが見込めそうですが、後続の実装タスクは今と変わらないのかなと思いました。
一方でCursorなどを使ってコードでデザインすれば大幅な時間短縮につながるのでは？と、気づいた日から毎晩自分に暗示をかけて眠ることにしました。
実際にやってみた
この実験をどのプロダクトで行うかですが、ちょうど良いタイミングで大規模な改善を行う予定のプロダクトがあるので、そこで実験をしようと決めました。すでにUXリサーチは済ませており、材料も揃っているので進めやすそうです。
実験として進めるので、プロダクションコードからは切り離したリポジトリとして始めました。この実験がうまくいけば、より大きな生産性向上が期待できますね。
実験は次のようにAI(主にClaude Code)と進めました。
- UXリサーチの資料を共有し、AIにユーザーを理解してもらう
- プロジェクトの目的を共有し、AIに理解してもらう
- 大まかな計画や方針をAIと相談しながら決める
- 大切にしたい価値観や守ってほしいことをまとめたUX原則
- デザインシステム
- プロジェクトの計画とタスク
- 画面や機能の棚卸しを行う
- プロダクトの現状と理想の状態について話し合いながらドメインを整理する
- 計画に沿ってスプリントを繰り返す
- ページやコンポーネントをStorybookに作ってもらう
- フィードバックを返す
- アップデートしてもらう
- 形になったらUI仕様書を作成
- UI仕様書を元にゼロからUIを構築してテストする
- フィードバックを返す
- UI仕様書を更新する
- いい感じになったら次のスプリントへ
この一連の流れの中で私の主な役割は判断することなのですが、その際にUXリサーチをやっておいて良かったなと改めて思いました。判断する際に、コンセプトやペルソナを意識して決めることができるので迷うことが少なかったと思います。
また、UI仕様書を元にゼロから構築できるのかどうかをテストしているのは、より多くの人が簡単にUIを構築できる将来を夢見てのステップです。
再現性のために整えたもの
AIに丸投げするのではなく、 AI と私が迷わないための「地図」 を作りました。
何回か試してわかったのは、判断の基準になる事実が無いとAIも私も、すぐに迷ってしまうということです。
そして、迷いなく再現性を高めるために次のような材料を用意して今は実験をしています。
UXリサーチの資料
UXリサーチの資料は次のようなものをAIと共有しています。
「誰の、どんな価値か」を、評価軸としてAIに渡します。
これを北極星として使うよう共有することで、AIがブレなくなるんじゃないかと考えています。
| 成果物 | 共有形式 |
|---|---|
| KA法で分析した価値マップ | CSV |
| ペルソナ | ドキュメントと画像 |
| コンセプト | テキスト |
| リサーチまとめ | スライド画像 |
「なんとなく」なものはAIでは作れない、とも言い切れませんが「誰の何を解決するか」「どんな価値を提供するか」が明確なっている方がAIも私も迷子になりづらいと思います。
ドキュメント構造
自分もAIも迷わないためにできるだけ多くの結果をdocs/ に集約しました。（その一部です。）
docs/
├── concept/
│ ├── product-vision.md # プロダクトの価値定義
│ └── ux-principles.md # UXの原則
├── specs/
│ ├── project-settings-spec.md
│ ├── preview-mode-spec.md
│ └── inspector-spec.md
├── design-system/
│ └── design-guidelines.md # デザイントークン、コンポーネント
└── prompt-templates/
│ ├── basic-template.md # 汎用プロンプト
│ ├── analysis-template.md # 分析用プロンプト
│ └── generation-template.md # UI生成用プロンプト
...
プロンプトテンプレート
プロンプトテンプレートは用途に応じていくつか作成しましたが、概ね共通しているのは次のような内容です。
各テンプレートには：
- コンテキスト：目的と背景
- 入力情報：TypeScript型定義まで明記
- 制約条件：やっていいこと、ダメなこと
- 出力形式：期待する結果の構造
- 具体例：良い例と悪い例を両方
# Basic Prompt Template
> 汎用的なプロンプトテンプレート
---
## 1. コンテキスト（Context）
**この Prompt の目的**:
[このプロンプトが何のために存在するかを1-2文で説明]
例:
- この Prompt は、メンバー管理機能の概要情報を生成するためのものです。
- ユーザーはメンバー管理機能の全体像を素早く把握したいと考えています。
---
## 2. 入力情報（Input）
**受け取るデータ**:
[受け取るデータの構造を JSON/TypeScript 型で明示]
---
## 3. タスク定義（Task）
**実行すべきタスク**:
[具体的なタスクを優先順位順にリストアップ]
1. **タスク1**（最重要）
- サブタスク1-1
- サブタスク1-2
2. **タスク2**
- サブタスク2-1
- サブタスク2-2
3. **タスク3**（オプション）
- サブタスク3-1
---
## 4. 制約条件（Constraints）
**守るべきルール**:
### 技術制約
- [ ] 使用可能なライブラリ/コンポーネント
- [ ] 使用不可のライブラリ/パターン
- [ ] スタイリング方式
### デザイン制約
- [ ] 色変数（tokens.json を参照）
- [ ] フォントサイズ
- [ ] 角丸、影などのスタイル
### コンテンツ制約
- [ ] 文字数制限
- [ ] 絵文字使用の可否
- [ ] トーンとスタイル
---
## 5. 出力形式（Output Format）
**期待する出力**:
[出力形式を具体的に指定]
**例**:
---
## 6. エッジケース（Edge Cases）
**特殊な状況での振る舞い**:
| 状況 | 期待される振る舞い |
|------|------------------|
| データが空の場合 | "No data" と表示 |
| null の場合 | デフォルト値を使用 |
| エラーの場合 | エラーメッセージを表示 |
---
## 7. 具体例（Examples）
### 良い例
### 悪い例
---
## 変更履歴
| バージョン | 日付 | 変更内容 |
|-----------|------|----------|
| v1.0 | YYYY-MM-DD | 初版作成 |
---
**最終更新**: YYYY-MM-DD
**作成者**: [Your Name]
**目的**: [Prompt の目的]
いろいろ失敗談
もちろん、すべてが順調だったわけじゃありません。順調に進まないこともけっこうありました。
1. 急に実装を始めちゃう
主に使っていたのはClaude Codeはなのですが、画面設計についての相談をしたい旨を伝えたにも関わらず、いきなりコードを書き始めてしまうことがけっこうありました。コーディングエージェントですので、コードを書きたくて仕方がない気持ちは、よくよく考えてみれば当然なのかも知れません。
この経験をふまえ、プロンプトにアクションの指示をしっかり書くようにする事で解決できたと思います。
2. 前後関係を無視する
今のプロセスでは画面単体で作っているので、AIはユーザーがその画面に訪れる前にどこにいたのか、次はどこに訪れるのかを想像できません。最初のうちは、単体としては立派だけどつなげると違和感がある画面がいくつかできあがりました。
対策として、ジャーニーマップを確認してもらって大まかな流れを理解してもらいつつ、プロンプトには前後関係をコンテキストとして明示するようにしました。
3. 人間が全体最適を担保する
気づいたこととして、今やってるこのプロジェクトにおいてAIは「局所最適」の強さは活かしつつ、「全体最適」をするには人間が担保した方がうまく進む感じがしました。自分なりのAIとの協働における役割分担です。
今後の課題
いろいろと取り組んでいますが、まだ実験中ですのでこれが正解かどうかまだわかりませんし、課題もたくさんあります。
- UIをモックとしてどのように共有するか
- コミュニケーションハブ的なFigmaの役割をどう解決するか
- デザインの仕様をどこに置くか（リポジトリ？ 社内MCPサーバー？）
などなどやり残していることはたくさんあります。
おわりに
タイトルの「Figmaやめた」というのは、正確じゃないかもしれません。
正しくは、「デザインと実装の境界をなくした」 ですね。
「形にする」と「実装する」を統合することで、私が本来やりたかった「探索」と「考える」に時間を使えるようになりました。
AIは魔法じゃありませんが、問いが明確なら、爆速で形にできる増幅器にはなってくれそうです。
そのために必要なのは：
- UXリサーチで価値を明確にする
- 評価軸をAIと共有する
- プロンプトテンプレートで迷わせない
- ドキュメント構造で事実を一元化する
これらを整えれば、少なくとも私は「探索」と「考える」ことに集中できそうです。
それが、この取り組みで得られた一番大きな気づきでした。
そして、「私がボトルネック」という最大の課題は、この実験の結果次第です。
Discussion