AIと役割分担することで、デザイナーがコードに関われるようになった話

※本記事は、以下のデザインディレクターによるプロセス設計の記事を受け、デザイナー視点での具体的な実践を紹介する位置づけのものです。
【判断をコードに残す。AI時代のデザインプロセス再設計 ―― 思考を蓄積し、改善を止めないプロダクト開発へ】
はじめに
体験の良し悪しを、誰が・どの段階で判断するのかが、これまで以上に重要なテーマになっている現在、
デザインチームでは「AIとの協働」により、早い段階からデザインを判断に組み込み、より本質的な「どうあるべきか」を考える部分に時間を割くことができる状況が作られています。
この流れの中で、デザインを担当している私の業務が大きく変わったのが、
「デザインをカタチにしたものをフロントエンド実装する」
という役割分担から、結果的に
「デザイナーがフロントエンドコーディングまで対応できる」
という状態になれたことです。
上記を実現するために、デザイナーの立場の私が「AI」をどのように活用しているかをお話ししたいと思います。
1. AIとの協働は「デザインの言語化」
私たちは独自のデザインシステムをFigmaを使って構築・運用してきました。
ここには、プロジェクト内でどのように振る舞うべきかが、
「バリアブル」「コンポーネント」に加えて、レイアウトのサンプルやルールをテキストで添えるなどで、Figma内にすべて表現されています。
※このデザインシステムについては、以下の記事で詳しく紹介しています。
https://www.fabrica-com.co.jp/techblog/design/11599/
デザインシステムをもとに、各ページの配置などのデザインを作り上げ、フロントエンドエンジニアにバトンタッチして実装するというという役割分担が基本でした。
これは合理的ですし、今もこの前提自体が間違っているとは思っていません。
ただ、この分業には、1つ特徴があります。同じ画面を、実質的に2度設計しているという点です。
Figmaで設計したものを、実装段階で再解釈し、コードとして再構築する。
その過程で、
- 見た目は近いが、考え方が違う
- どこまでがルールで、どこからが調整なのかが伝わりきらない
といったズレが生まれることがありました。
コメントや注釈で補おうとしても限界があり、修正依頼を出す側としても、どこまで踏み込んでよいのか迷う場面がありました。
今回の取り組みで、企画時にv0で作成されたコードがすでに存在するため、そのコードにデザインシステムのルールを適用することとなりました。
そのため、Figmaですべてのページのレイアウトを作成する必要はありません。
v0のデータをCursorで扱えるようにし、そのコードにデザインを適用できるよう、私自身がCursorとやりとりします。
今までFigmaにまとめられてきた「バリアブル」「コンポーネント」をはじめとした具体的な内容から、どのような理由でそうなっているか、それをどう使って欲しいか、私の頭の中のデザインルール・仕様などすべて、Cursorの中で実現できるように伝えます。
それをサイト全体に適用することで、shadcn/uiベースのv0のページが、デザインシステムのルールで置き換わるのです。
伝えた内容がすべて、AIによってドキュメントに落とし込まれています。
デザインシステムが適用された各コンポーネントと、このドキュメントを元に、ページ全体に適用されます。

これにより、私がすべてのルールを頭の中に記憶しておかなくても、AIに「この部分のデザインルール、どうなっていた?」と聞けば、すぐに、詳細を返してくれます。
今までは確認したい場合、Figma上のデータを再度確認する必要がありましたが、格段に早く、的確です。
これは、ルール作成しているデザイナーの私だけではなく、他の担当者も同じようにルールを参照できます。
2. ChatGPTも参戦、指示と判断と実行を分ける連携プレー
Cursorに方針を伝え、実装結果を確認し、それが守られているかを都度チェックする、という進め方を行っていましたが、徐々に違和感が出てきました。
私がコード全体を把握しきれていないため、どうして欲しいかは明確に決まっているが、その指示と結果が本当に最適か、確信が持てない。
見た目のスタイルは問題なさそうだが、裏側の仕様まで、本当に伝えた通りに仕上がっているかがチェックしきれない。
また、Cursor が最初に伝えた方針に引っ張られ、途中でより良い解決策に切り替えにくいと感じる場面もありました。
これはつまり、
自分がすべてを理解していない以上、
正確で柔軟な指示を出し続けるのは難しい
という状態でした。
このままでは、「方針の番人」であるはずの私が、知らないうちに実装の細部まで背負ってしまいます。
そこで、Cursor の前に ChatGPT を挟む構成に切り替えました。
ChatGPT には、
自分が守りたい方針や違和感を受け取りそれを整理しCursor が迷わない形の指示文に変換する
という役割を持たせました。
この時点で、私の立ち位置は明確になります。
実装を指示する人ではなく、判断を渡す人という役割です。
実際に回していたフローは、次のようなものです。
ヒト(デザイナー)が、やりたいことや守りたいルール、違和感を ChatGPT に伝える。
ChatGPT がそれを整理し、実装可能な指示文として Cursor に渡す。
Cursor が実装を行い、結果を返す。
ChatGPT が実行結果を評価し、意図とのズレを確認する。
ヒトは結果を見て、最終的な見極めだけを行う。
重要なのは、実行に対して、人が直接介入しないことでした。

<バイブコーディングとFigmaMCPの使い分け>
文章で指示する方が複雑で手間になるという内容は「FigmaMCP」を活用します。
すでにルールを伝えているCursorに渡すと、複雑なものでも8割程度は正確に伝わる印象です。そこから少しメッセージのやり取りで仕上げられるのでスムーズです。
それ以外は、すべてバイブコーディングで対応しています。
言葉で伝えたらすぐにブラウザで確認できるので、とてもストレスなく実装ができます。
「もうちょっとこうしてみようか」といった微調整もすぐに実画面で確認でき、効率的に意図した通りのデザインが仕上げられます。
3. ChatGPTのプロジェクト機能活用と「チャットを分ける」という運用
ChatGPTとのやり取りにおいて、最初は過去の文脈があった方が方向性がブレないという感覚があったので、すべてを可能な限り1つのチャットで続けていました。
しかし、長くなりすぎて処理が重たくなる、以前の内容を振り返るのが難しい、といったデメリットが出てきました。
そのため、デザインルールやコンポーネント、画面や機能単位など、文脈が異なるものはチャットを分けられないか?と考えました。
この際に気になったのが、毎回同じ方針・クオリティでやり取りしたい、ということでした。
この問題はChatGPTの「プロジェクト機能」を使うことで解消することができました。
どのチャットでもChatGPTと認識を合わせるためのドキュメント(project-overview.md)を用意し、プロジェクトに参照ファイルとして保存しておきます。
ここには、
- このプロジェクトの前提
- 判断時に守るべき方針
- ChatGPT が担う役割
をまとめています。
これにより、チャットが変わっても判断基準がブレない状態を保てました。
デザインシステムのルール自体は、Cursor も参照する正式なドキュメント(design_principles.md、component_specifications.mdなど)を正とし、内容を二重に書かないことも意識しています。
チャットはテーマごとに分けて管理しています。
その内容は多岐に渡ります。一例としては以下のようなものです。
- コンポーネントごとの編集
- Cursor使用時のトラブル解消
- gitの使い方
- コードの構造についてなど解説
- ローディング遅延解消についての検証と改善提案
- 運用方法の相談
などなど・・・
思いついたものすぐにテーマを分けて相談でき、さらにコミュニケーションがスムーズになりました。
一旦完了まで進んだ内容については、チャット名に(完)をつけておき、また同じ箇所で変更が発生したら戻るか新規作成か、ChatGPTと相談して決めています。

4. やれることが広がった実感
AIと協働しているので、自分でゼロからコードを書けるようになったわけではありませんが、今までと違う領域にも踏み込めたと感じます。
指示を出す際に意識しているのが、「適用がスムーズ」「運用管理がしやすい構造」を徹底するよう方針に盛り込み、意図しないスタイルの崩れが発生しないようにという点を常に心がけていました。
これをChatGPTと共有し、一方的に最善案を採用するだけではなく、「どうしてこうした方がいいのか」と解説をしてもらうことも多々ありました。
全てを理解できないこともありますが、「こういう方針でいきたい」と意向を伝えれば、私たちのデザインシステムでの最善案を選べるような感覚がありました。
それにより自然と、今まで気にかけてこなくても進められた、コードの構造なども少しずつ見えてきたと感じます。
データの取り扱いもプロジェクトに携わるメンバーと共有しますので、今まで一切関わってこなかったgit管理の用語も身についたりしているのは、自分でも驚きです!
Figmaを使い始めた時も、「オートレイアウト」や「バリアブル」での管理など、コーディングに近いデザインを制作するといった、新しい領域について身についている感覚が心地よく、ワクワクした記憶があります。
今回もまた、新たな領域に踏み込んで吸収できている高揚感があります!
5. まとめ
判断できる前提を用意する、ということ。
今回の取り組みを通して感じたのは、AIによって「できること」が増えた、というよりも、
自分が判断できる範囲が明確になった、という変化でした。
デザインシステムのルールや前提を言語化し、project-overview.md や各種ドキュメントとして固定したことで、「これは判断してよいことか」「どの責務として扱うべきか」を迷わずに済むようになりました。
自分ですべてを覚えておく必要はなく、必要なときに AI に確認すれば、確定しているルールや構造を引き出せる。
その前提があるからこそ、実装結果を見て「これは意図と合っているか」「共通化すべきか」を落ち着いて判断できます。
結果として、これまで自分の役割外だと感じていた領域にも、判断という形で関われるようになりました。
私にとっての「AIを活用する」とは、作業を肩代わりしてもらうことではなく、
判断に集中できる構造を整えることだったのだと思います。
ファブリカコミュニケーションズで働いてみませんか?
あったらいいな、をカタチに。人々を幸せにする革新的なサービスを、私たちと一緒に創っていくメンバーを募集しています。
ファブリカコミュニケーションズの社員は「全員がクリエイター」。アイデアの発信に社歴や部署の垣根はありません。
“自分から発信できる人に、どんどんチャンスが与えられる“そんな環境で活躍してみませんか?ご興味のある方は、以下の採用ページをご覧ください。


