こんにちは。私はＳｋｙスタイル部デジタルソリューション課のデザインチームに所属しています。今回は、要件定義などのテキスト情報をインプットとして、AIにデザインの実装までを任せるアプローチ、「Vibeデザイン」をやってみた話をご紹介します。
Vibeデザインの実践検証 ： デザインプロセスをAI駆動開発のフローに乗せる試み
現在、開発の世界ではAIの活用が急速に進み、コーディングなどの開発速度が劇的に向上しています。その恩恵を受ける一方で 「デザインプロセスが開発スピードのボトルネックになってしまう」 という新たな課題が浮き彫りになってきました。
特に私が担当している社内システム開発の現場では、UI / UXよりも機能の価値が優先される傾向にあります。もしデザインプロセスをAI駆動開発のフローに乗せられない場合、スピードを優先してデザインのクオリティーを落とすというシビアな選択肢を取らざるを得なくなります。
つまり、デザインプロセスをAI駆動開発のフローに乗せることは必達目標です。
今回は要件定義から一気にデザイン生成・実装までをAIに任せるアプローチ、通称 「Vibeデザイン」 の実践検証をしてみました。
どのような「インプット」と「Skill」でAIを動かすか？
AIにクオリティーの高いデザインと実装を行わせるためには、与える「インプット（要件定義ドキュメント）」と、AIの役割や処理手順を定義した「Skill」の両輪がそろうことが不可欠です。どちらか片方だけでは、狙ったアウトプットは得られません。
1. インプット（入力ドキュメント）
単なるテキストの指示ではなく、以下のような詳細なMarkdownファイルを用意しました。
- ユーザーストーリーマッピング.md（機能・受入基準・アクター）
- イベントストーミング_ToBe.md（フェーズ詳細・UI要素・データ項目）
- 状態遷移フロー.md（状態と画面の対応・遷移トリガー）
- バリューシナリオ.md（ペルソナ・利用文脈・ユーザーの心理面）
デザイン、特にAIがワイヤーフレーム（WF）を組み立てる上で最も重要になるのが、この 「バリューシナリオ.md」 です。ほかのドキュメントは「機能」や「状態」のデータしか保持していません。AIがただの無機質な画面を作ってしまうのを防ぐためには、「ユーザーが感じる価値や不安」といった心理面をバリューシナリオからインプットし、AIのコンテキストに含める必要がありました。
2. Skill（AIの処理定義）
そして、このインプットを処理させるための「Skill」として、今回は特にデザインの核となる以下の3つを作成して臨みました。
- 情報設計をするSkill
- WF（画面レイアウト）を作るSkill
- デザインシステムとデザインルールを参照しデザイン実装計画を立てるSkill
最大の課題は「暗黙知の言語化」
今回の検証を通じて、AIにデザインを任せる際の最大のハードルが明確になりました。それが 「暗黙知の言語化」 です。
後半のコードに落とし込む「実装計画」などのステップは比較的スムーズでした。なぜなら、弊社はすでにデザインシステムを持っており、デザインルールが普段から明文化されていたからです。AIがうまく実装できなかった部分を洗い出し、ルールとして追記していけば機能します。
しかし、その前工程である「情報設計」や「WF作成」はどうでしょうか？ 今回、情報設計のSkillとWFを作るSkillの2つを用意して挑みましたが、私たちは普段、どの情報をグルーピングし、どう優先順位をつけてレイアウトするかを、デザイナーの「感覚」で行っている部分が大半です。
WFのレイアウトを組み立てるためのルールは何とか言語化できたものの、その前段階である情報設計における 「判断軸」の言語化は今後の大きな改善テーマです。
AI時代、デザイナーが生き残る道とは？
今回の検証を経て、これからの時代にデザイナーが生き残る道は大きく2つあると感じました。
- 感覚を論理に翻訳する「言語化Skill」
前述のとおり、暗黙知となっているデザイナーの判断軸を言語化し、AIにルール（Skill）として定義し直す力です。 - プロダクトオーナーとしての「ドメイン知識」
AIには自社特有の例外処理や過去の経緯といった「現場の文脈」は理解できません。業務アセットを熟知し、AIに「自社にとっての最適解」を出させるための前提条件を定義する役割です。
先の読めない時代ですが、これからの時代に何が求められるのか探りながら仕事をしていこうと思います。
