Overview
仮想通貨取引所アプリbitFlyerにおいて、プロダクトデザイナーである私が単独で主導した、AI-Readyなデザインシステムの構築プロジェクトです。
デザインシステムの整備を進める中で、会社全体のAI化推進を受け、AIとの協働を前提としたデザインシステムへと再構築するという方針が加わりました。
- Problem
- デザインシステムが未整備・未文書化で、開発との対応も不明確なため、AIを導入できない状態。
- Goal
- デザインシステムを整備し、Design Contextとして体系化
- 運用フローの構築
- 実務でDesign Contextの有効性を検証
- My Contribution
- 単独で主導。Design Context・コードマッピング・運用フローを設計し、実務で有効性を検証。
- Outcome
- 経営層との議論用プロトタイプを、デザイナー・エンジニアを介さずに作成可能に
- 外部デザイン案のプロトタイプ化を、約1週間から1日に短縮
- 開発チームとの運用フローを構築・運用
Challenge
AIをデザインフローに組み込むにあたり、現状のデザインシステムを精査したところ、以下の問題が明らかになりました。
デザインシステム自体が不完全
カラーのコントラストなどがアクセシビリティ基準を満たしておらず、海外展開するプロダクトとして法的リスクを抱えていました。
また、同種のコンポーネントでもレイアウトルールが統一されず、pressedやdisabledの状態が定義されていないなど、新たに同種のコンポーネントを作る際に設計判断の拠り所がない状態でした。
デザインルールが文書化されていない
ルールは制作者の記憶に依存し、多くはすでに追跡不可能でした。AIに参照させるべきデザインの根拠そのものが存在しない状態でした。
デザインと開発実装の対応関係が不明確
各プラットフォームが個別に開発を進めてきた結果、コンポーネントの命名・構造がプラットフォームごとに異なっていました。AIがデザイン上のコンポーネントから対応する実装を特定できず、実装と乖離したアウトプットになってしまう状態でした。また、根本解決にはコード改修が必要ですが、開発リソースの不足により短期での対応は困難でした。
Strategy
開発リソースの制約を踏まえ、デザインシステムの現状に対して以下の方針を立てました。
- デザインシステムを整備し、コードとの対応関係も含めてAIが理解できるDesign Contextとして体系化する
- デザインシステムの運用フローを整備する。新コンポーネントの開発はそのフローに準拠する
- コードベースをデザインシステムに段階的に近づけていく
Execution
デザインシステムの整備
Design Contextの土台として、まずデザインシステム自体を整備しました。既存ページを精査して使われているパターンを洗い出し、同種コンポーネントのレイアウトルールの統一、pressed・disabledなどの状態定義、アクセシビリティ基準に沿ったカラーの見直しを行いました。カラーはダークモード対応も兼ねて再設計し、開発側への影響を最小限に抑えています。
Design Contextの構築
AIが参照するデザインシステムに何が必要かを、利用者ごとに整理しました。
| 利用者 | 必要な情報 |
|---|---|
| 開発者 | コンポーネントの種類・名称・パラメータ |
| デザイナー | コンポーネントの見た目・デザインルール |
| AI | 具体的かつ構造化されたデザイン情報 |
FigmaやStitchなど主要なデザイン生成ツールで検証したところ、AIには情報を具体的に渡す必要がある一方、量が多すぎると誤りが増えることがわかりました。そこで、情報を粒度ごとにファイルに分け、必要な分だけを読ませる構成にしました。
| 役割 | |
|---|---|
 Design.md
|
「何があるか」と「どう見えるか」を分けて管理しています。AIは最初にこのファイルだけを読み、索引から必要な詳細ファイルのみを参照します。 |
 Page Templates
|
既存のページ構成を型として用意し、生成される画面の構成を揃えます。 |
Design Patterns
|
既存のコンポーネントの組み合わせを定義し、画面の部分単位でも一貫性を保ちます。 |
Components
|
各コンポーネントの詳細仕様。AIが参照する最小単位です。 |
Assets
|
アイコンやロゴは既存の素材を使わせ、AIが独自に描くことを防ぎます。 |
コードとのマッピング
iOS・Android・Webの既存コンポーネントをAIで洗い出して比較したところ、名称は違っても実態は同じものが多数ありました。そこで、デザインと各プラットフォームのコンポーネントの対応関係をマッピングとして定義し、Components層に組み込みました。これにより、AIはデザイン定義から対応する実装コンポーネントまで一貫して参照できます。
運用フローの整備
今後の追加・変更で同じ問題を繰り返さないよう、開発チームと運用フローを整備しました。デザイン側から理想の連携方法を提案し、開発側の意見を取り入れながら、リーダーとも相談を重ねてすり合わせました。
- 開発前：デザインと開発が共同で仕様・命名をレビューし、各プラットフォームで揃える
- 開発後：デザイナーが実装をレビューし、デザインシステムへの準拠を確認する
Validation
非デザイナーによる活用
自分で検証したうえでチームにデモ・共有し、非デザイナーのメンバーも使える状態にしました。
- Before：経営層との議論には、デザイナーやエンジニアが作ったプロトタイプが必要だった
- After：PM的な役割のメンバーが、Design ContextとAIで自ら画面を生成し、そのまま議論に使えるようになった
プロトタイプ変換の事例
外部デザイン会社による、デザインシステムに準拠していないデザイン案を変換した事例です。
- Before：開発経由でプロトタイプを作成し、約1週間かかっていた
- After：Design ContextとAIで準拠したインタラクティブなプロトタイプに変換し、1日で完了した
Reflection
AIをめぐる状況は日々変化していますが、大切なのは自分のチームの段階に合った方法論を見つけることだと感じました。発展途上のデザインシステムと限られた開発リソースの中で、大手企業の理想形をそのまま当てはめず、最小限のリソースで課題を解決する。それがこのプロジェクトでの一番の学びです。今回の方法もあくまで一つの解決策であり、AIの進化とともに変わり続けるものだと考えています。