Upgrade to Pro — share decks privately, control downloads, hide ads and more …

エンジニアがデザインまで担うための AI駆動UIデザイン/フロントエンド開発実践

Avatar for 北見海貴 北見海貴
September 18, 2025

エンジニアがデザインまで担うための AI駆動UIデザイン/フロントエンド開発実践

Avatar for 北見海貴

北見海貴

September 18, 2025
Tweet

More Decks by 北見海貴

Other Decks in Technology

Transcript

  1. confidential 自己紹介 2 北見 海貴 (Kaiki Kitami) @kita3222 所属・業務 •

    株式会社 Almondo SWE(フロントエンドが多め ) コミュニティ • Amplify Japan User Group 運営(AWS公認コミュニティ)
  2. confidential 会社概要 3 テクノロジーの社会実装を加速 させる 東京大学松尾研究室発の 最先端のAIのスタートアップ 会社名 株式会社Almondo(アーモンド) 
 


    由来 ”AI”で”mondo”(イタリア語で世界の意)に「希望」 (Almondoの花言葉)を生み出す会社でありたい 
 

  3. confidential 取り組みの背景 7 背景 昨年まではAIソリューションの提供が中心だったが、今年は社会実装への比重が高まっている。 → これに伴い、従来以上に「より優れたユーザー体験や UIを高速に早出する」 ことが求められるよう に。

    方針 フロントエンド(UIデザイン〜実装)の開発を効率化しつつ、エンジニア自身が UI/UXの価値を高められ るように、 AIエージェントを組み込んだ開発プロセスの検討 を開始。
  4. confidential 検討したアプローチ 9 Figma MCPによる デザインからコードを生成するアプローチ デザイン生成ツールによる コードでデザインを作成するアプローチ 昨今のAIを活用したデザイン・フロントエンド開発のパターン •

    デザイナーが在籍していない • 普段から非デザイナー (PM/SWE) がデザ インの作成に関与 • デザイナーが在籍 / 普段からFigmaでデ ザインを運用 • デザインシステムが既に整備済み それぞれ、以下のケースで有効
  5. confidential 検討したアプローチ 10 Figma MCPによる デザインからコードを生成するアプローチ デザイン生成ツールによる コードでデザインを作成するアプローチ 昨今のAIを活用したデザイン・フロントエンド開発のパターン •

    デザイナーが在籍していない • 普段から非デザイナー (PM/SWE) がデザ インの作成に関与 • デザイナーが在籍 / 普段からFigmaでデ ザインを運用 • デザインシステムが既に整備済み それぞれ、以下のケースで有効
  6. confidential UIデザイン生成ツールの特徴 11 生成AIとの対話を通して、 UIデザインを生成 コードでデザインを行う「 Design as Code」の発想 •

    ユーザーは思い通りのデザインが生成されるまで何度も チャット上で試行錯誤が可能。 • AIによってコーディングコストが下がり、これまでは難しかっ たコードを用いたデザインの検討・構築が現実的に。 • これにより、UIデザインの構築 ≒ フロントエンド開発 が可能 となり、開発効率が向上
  7. confidential AIコーディングエージェント による代替 13 CursorやClaude Codeをはじめとする AIコーディングエージェントを活用 • 細かいセッションの切り替えが可能 ◦

    単一リポジトリに対して、セッションを切り替えながら継続的に開発が可能 ◦ 画面/機能単位でセッションを分割し、 コンテキスト肥大を回避 • エンジニアとの親和性の高さ ◦ エンジニアにとっては、開発エディタの方がコードの編集が手軽 ◦ 逆に、v0などのノーコード体験は必須ではなく 場合によっては冗長 • 運用一貫性 ◦ 実装は最終的にはエディタ上で行うため、ツールは分散しない方が効率的 ◦ ツールを一極化することで開発コストも抑えられる
  8. confidential AIコーディングエージェント による代替 課題:自由度が高い分、適切なルール設計による制御が必要 • v0 などは、まずデザインシステム を作り、生成されたコンポーネントライブラリ で実装する流れがおそらく 事前にルール化されており、

    統一性のある綺麗な UIを作りやすい仕組みになっている。 • これに対してAIコーディングエージェントを使用する場合、自由度が高い分、そのプロセスを自前で設計・ 運用しないと、生成されるデザインが一貫性のないものに なってしまう。 → 実際に行った AIエージェントを活用して統一性のあるデザインを生成するための工夫 をご紹介
  9. confidential UI開発の流れ デザイントークンの定義 カラー・フォント・スペーシングなどの定 義 コンポーネント ライブラリの定義 ボタンやテキストフィールドなどの 定義 画面の実装

    コンポーネントを組み合わせて定義 するレイアウトや画面の実装 デザインシステムの構築 デザインシステムに基づき 各画面を実装 このフローに沿って進めることで、 統一性があり、運用しやすいデザイン・実装を行える
  10. confidential デザインシステムの構築 shadcn/ui を活用してデザインシステムを構築 • CLIの実行を通して元々用意されたコードを落としてくる ◦ 例: pnpm dlx

    shadcn@latest add button をプロジェクト内で実行すると、 Buttonの実装が自動で components/button.tsx に作られる ◦ ソースが隠蔽されないため、 生成AIとの相性が良い ◦ 実際、v0やlovableが生成するコードでも shadcn/uiが使われている • デザインシステムに乗せやすい ◦ デフォルトのデザイントークンと各コンポーネントに適切なユーティリティクラスが最初から設定されて いる ◦ コンポーネント側の修正は行わず、 globals.cssの変更のみでデザイントークン(フォント・カラー・ スペーシング)の一括調整ができる
  11. confidential 1. デザイントークンの定義 • カラー、フォント、スペーシングなどデザインシステムの最小構成要素を定義したもの ◦ shadcn/ui の場合は、globals.cssにCSSカスタムプロパティとして一括定義 • 各値は、そのシステムの想定ユーザー(年齢層・業界・職種

    など)に合わせて決定 ◦ 例:シニア層がターゲットの場合は、フォントサイズ・行間・スペーシングを大きめに調整 デザイントークンの定義 カラー・フォント・スペーシングなどの定 義 コンポーネント ライブラリの定義 ボタンやテキストフィールドなどの 定義 画面の実装 コンポーネントを組み合わせて定義 するレイアウトや画面の実装
  12. confidential 1. デザイントークンの定義 1. 事前に用意した質問に沿って、 AIエージェントが開発者へヒアリングを実施 a. ルールファイル(例: design-system.mdc)に、デザイントークンの作成に必要な質問を定義 2.

    開発者の回答に基づき、 AIがデザイントークンを提案 3. 案を globals.cssに反映し、次工程で作成するコンポーネントで表示を確認 4. 以降、試行 → 確認 → 微調整を繰り返す AIエージェントを活用してデザイントークンを作成 デザインの知識がなくても、エンジニアがデザイントークンを定義できるように
  13. confidential 2. コンポーネントライブラリの定義 • ボタンやテキストフィールドなど、再利用可能なコンポーネントの集まり • shadcn/ui の場合、事前に用意されたコンポーネントを CLIの実行を通して、プロジェクトに追加 デザイントークンの定義

    カラー・フォント・スペーシングなどの定 義 コンポーネント ライブラリの定義 ボタンやテキストフィールドなどの 定義 画面の実装 コンポーネントを組み合わせて定義 するレイアウトや画面の実装
  14. confidential 2. コンポーネントライブラリの定義 • shadcn/ui で追加したコンポーネントに Storybook を設定 ◦ CLIで追加した各コンポーネントに対し、

    AIエージェントへ *.stories.tsx の作成を指示 ◦ バリアント/状態(hover・focus・disabled・error など)を一覧で確認 ◦ 画面では見落としがちな コンポーネント単位のデザインの一貫性を Storybookでの確認を通して 担保 Storybookを用いて状態ごとのコンポーネントのデザインを確認
  15. confidential 3. 画面の実装 • ここまでに定義したデザインシステム(トークン/コンポーネント)を用いて画面を組み立てる ◦ デザイン一貫性のため、 画面内での独自スタイルの実装を禁止し、定義済みコンポーネントの使 用を必須とする方針 をルールファイル(例:

    Project Rules)に明文化 ◦ しかし、それでもハードコーディングしてしまうことはあるので、やはり開発者による生成されたコード のレビューは欠かせない。 デザイントークンの定義 カラー・フォント・スペーシングなどの定 義 コンポーネント ライブラリの定義 ボタンやテキストフィールドなどの 定義 画面の実装 コンポーネントを組み合わせて定義 するレイアウトや画面の実装
  16. confidential 導入してみて • 良かった点 ◦ デザインがFixした時点でモック実装が完了した状態となる ▪ 従来と比べて、開発効率が大幅に向上 ◦ Presentation

    / Container パターンと好相性 ▪ AIによるモック実装をPresentation層に留めておけば、 API結合時はContainer層だけ実 装すればよい状態となる • 課題 ◦ Figma と比べて、小さなデザイン修正が手間 ▪ コードの修正が必要な分、 Figmaの方が手軽