判断をコードに残す。AI時代のデザインプロセス再設計 ―― 思考を蓄積し、改善を止めないプロダクト開発へ

はじめに

AIで速くなった実装に、どう「意図」を残すのか

AIによって、バックエンド開発のスピードは大きく向上しました。
実装は速くなり、試行錯誤にかけられる時間も増えています。

では、企画やデザインはどうするのか。
実装が先に進む状況の中で、体験の良し悪しを、誰が・どの段階で判断するのかは、
これまで以上に重要なテーマになっています。

もしUI構築までAIに委ねてしまうと、「なぜこの形になったのか 」「どこをどう改善すべきか 」といった判断軸が、プロダクトの中に残らない可能性が高くなります。
そうならないためには、

デザインを「後工程」にせず、早い段階からプロダクトの意図に組み込む必要がある

この疑問に対して、
私たちは「判断の背景を構造として残す」ことが、ひとつの答えになると考えました。

1. 何をやったのか（What）

早期に「デザインが活きたプロトタイプ」を成立させる構造をつくった

私たちが取り組んだのは、
「UI構築をAIに丸投げしない」という判断を前提に、
AI時代のプロダクト開発において、企画・デザイン・仕様を分断せず、
判断の背景ごとコードに束ねる構造をつくることです。

その結果、AIとヒトが同じ前提で会話でき、改善の判断がプロダクトに残り、
スピーディに人間中心設計（HCD）が回せるプロセスを構築することが出来ました。

2. なぜこの取り組みが必要だったのか（Why①）

UIには「意図」が必要である

UIは、「UXの5階層モデル（ジェシー・ジェームズ・ギャレット氏著書：The Elements of User Experience）」で言えば最上位の「表層」にあたります。
その下には、情報構造・機能・要件・目的といった階層が積み重なっています。

この下位の階層が整理されていなければ、UIの良し悪しを正しく判断することはできません。

見た目の違和感や使いづらさは、多くの場合、「なぜこの構成なのか」「なぜこの機能が必要なのか」という下位の判断が曖昧なまま進んでいることに起因します。

つまり、UIを正しく判断し、改善し続けるためには、
その判断を支えている「意図」が、後から辿れる形で残っている必要があります。
判断の前提が残らない状態では「どこを、なぜ直すのか」を合意すること自体が難しくなってしまいます。

3. なぜ従来のやり方では限界があったのか（Why②）

そしてもう一つ、
前段の問いを深める中で、従来の進め方そのものにも限界があると感じていました。

これまで私たちは、

・線画のワイヤーフレーム
・静止画のビジュアルデザイン
・文章中心の仕様書

を使って、企画や設計を進めてきました。
それは、早期に動く最終形を作ることが難しかった時代の、合理的な選択でした。

しかしこの構造では、「静止画と文章を行き来する必要がある」「作成者の文才や説明力に理解度が左右される」「判断の背景が、成果物に残りにくい」という問題が常にありました。

結果として、「なぜこのデザインにしたのか？」という問いに、
本来は企画や課題設定の話であるはずなのに、デザイン工程が責任を背負う構造が生まれていました。

AIが普及する以前は、それを解消する現実的な手段がなかったのです。

4. 構造を再設計するために、何から始めたか（How①）

出発点：Figma MCP とデザインシステム

この時点で私たちが考えていたのは、構造を再設計することではありませんでした。

AI活用が進む中で、「デザイン工程において、AIをどう活かせるのか」 その可能性を探る、効率改善の取り組みから着手しました。
その中で着目したのが、オリジナルのデザインシステムと、Figma MCPです。

※「デザインシステム」については、以下の記事で詳しく紹介しています。
https://www.fabrica-com.co.jp/techblog/design/11599/

デザインの判断基準が整理された状態であれば、それをAIに伝えることで、デザイン工程における作業や確認の負荷を下げられるのではないかと考えました。

コード生成の工程では、以前から Figma MCP を利用していました。その際、言語化されたデザインシステムを AI に伝えることで、コード生成における判断のばらつきを抑えられるのではないかと考えました。

この検証を進める中で、私たちは別の可能性に気づき始めます。
この気づきが、この記事で扱っている開発プロセスへとつながる、大きな分岐点となりました。

5. 構造を再設計する中で見えてきた、v0の役割（How②）

企画工程におけるAI活用について整理を進める中で、
判断を具体的な形として扱える手段として、v0に辿り着きました。

私たちはv0を、UIを完成させるためのツールではなく、
判断の前提を整理し、企画を具体化するためのツールとして採用しました。

画面構成や要素の整理を目的とし、
関係者と企画内容を詰めていくための手段として利用しています。

v0 は本来、スタイルや振る舞いまで含めて生成できるツールです。
しかし、それらを同時に扱うと、企画とデザインの判断が混ざりやすくなります。
そのため私たちは、v0 では企画に必要な情報だけを扱うという使い方を選びました。

そんな中、作成した画面構成が shadcn/ui ベースのコードとして書き出せることを知りました。
このとき、私たちはある可能性に気づきました。

v0で作った企画は、そのままコードとして存在します。
つまり、企画を、より具体的で実装可能な形として共有できる状態です。

この企画コードに、言語化したデザインルールがスムーズに当てられたら、
新しい開発プロセスが成立するのではないか、と考えました。

この仮説を前提に、コードを3つの役割に分けて整理しました。

6. 3つの「コード」で構造を整理する（How③）

私たちはコードを、次の3つに整理しました。

企画コード
v0で企画した内容を、shadcn/ui ベースのコードとして出力した状態。
画面構成・要素・画面遷移、といった、企画の検討結果そのものです。

デザインコード
デザインの判断軸を言語化したドキュメントと、企画コードに合わせて整えたコンポーネント群。
AIが判断するための前提となる情報を含みます。

プロトタイプコード
企画コードにデザインコードを当てた状態。
プロダクト仕様、デザイン仕様、判断の背景、対応済み／未対応のタスクが含まれています。
単なるフロントエンドの仮実装ではなく、仕様と意図が束ねられた、判断可能なコードです。

7. 試行錯誤と方針転換（How④）

当初は早い段階で企画コードとデザインコードを組み合わせ、企画コードの差分を随時取り込む方向で進めていましたが、取り込み作業が複雑かつ不安定になり、判断の前提を保つことが難しくなりました。

そこで方針を切り替えました。

企画がある程度まとまった段階で、はじめてプロトタイプコードを組む。
以降は、そのプロトタイプコードを起点に、企画・デザイン・実装を並行して育てていく。

8. この構造がもたらした変化（Result①）

プロトタイプコードには、プロダクト仕様とデザイン仕様、そしてそれらを選択してきた意図と判断の背景が含まれています。

企画・デザイン・仕様・タスクが、コードという共通の形式で束ねられているため、
AIはそれらを前提条件として扱うことができます。

その結果、

・タスクを与えれば、AIが実装方法を提案できる
・仕様を、AIを介して自分が理解しやすい形で引き出せる
・作り手の技量に依存せず、内容を把握できる

という状態が生まれました。

9. HCDを回せる仕組みとしても機能（Result②）

この手法を採用したことで、

ある程度デザインが当たった状態のプロトタイプを早期に成立させ、
実際の操作感を試しながら、改善を重ねてリリースを目指す

という進め方が可能になりました。

プロトタイプコードを起点に、
検証 → フィードバック → 改善 を繰り返していくこの流れは、
結果として人間中心設計（HCD）の考え方にも当てはまっています。

HCDを目的としてプロセスを設計したというより、
この構造で開発を進めた結果、HCDに沿った改善が自然と回る状態になった、
という感覚に近いかもしれません。

10. まとめ

AIが変えたのは「アウトプットの速さ」だけではない

AIによって、コードを書くスピードは大きく向上しました。私たちも、その恩恵を日々感じています。一方で、この取り組みを通して実感したのは、速くなったのはアウトプットだけではない、ということでした。

企画やデザイン、仕様といった情報をコードとして束ねておくことで、
AIを介して必要な情報を引き出し、理解し直すことができるようになった。

その結果、
プロトタイプコードは単なる実装結果ではなく、
プロダクトの判断背景を共有するための基盤として機能しています。

記憶や経緯はデータとして保持され、ヒトは思考と判断に集中できる。
アウトプットばかりに目が行きがちですが、
個人的には、企画におけるAI活用として、インプットにも大きな価値があると感じています。

これからもAIと協働しながら、
意図あるプロダクトづくりにつながるプロセスを磨き続けていきます。

※以下記事では、デザイナーの視点から、「デザインの言語化」を実践レベルで掘り下げています。
【AIと役割分担することで、デザイナーがコードに関われるようになった話】