こんにちは、ファインディCTOの佐藤(@ma3tk)です。この記事は、ファインディエンジニア #1 Advent Calendar 2025とファインディデザインチーム Advent Calendar 2025の4日目の記事です。
先日、Findy AI+という新規プロダクトのデザインシステムを1から設計しました。
片手間ながら1人で2〜3週間かけてベースの設計を仕上げた結果、これからのデザインシステムは「コードで管理すること」が不可欠だという思いが強くなりました。
なお、Figmaとコードの関係性の変化やAI時代における開発フローの変化など、関連するテーマは多くありますが、今回は「なぜコードで管理するのか」という背景を中心にお伝えします。
ユーザーと同じ環境でものを見る
デザインツールと実装環境の違い
従来のワークフローでは、Figmaなどのデザインツールでデザインを作り、実装はそれに追従する形でした。Figmaは優れたデザインツールですが、そこで見ている画面と、ユーザーが実際に触るプロダクトは異なる環境です。
デザイナーが意図した色やスペーシングが実装段階で微妙にズレることもあります。また、レスポンシブ対応で想定外の挙動が起きることもあります。デザイン時と実装時での乖離は、デザインツールと実装環境の違いから生まれる課題です。
例えば、ボタンの角丸が場所によって4pxだったり8pxだったり、余白が16pxと20pxで混在したりといった問題です。Figmaでは統一されているように見えても、実装では微妙に異なる値が使われることもあるでしょう。
これは、デザインツールと実装環境という2つの異なる場所で管理しようとすることの難しさです。
プロダクト開発に関わるメンバーが最も注目すべきは、プロトタイピングの画面ではなく、ユーザーが触る実際の画面だと考えます。
コードで管理する最大の価値
「ユーザーと同じ環境で、ものを見ることができる」
これがコード管理における最大の価値だと思います。
コードをマスターにすることで、実装された状態が常に正しい状態となります。
どれだけデザインツールで美しく見えていても、ブラウザで崩れていたら意味がありません。コードをマスターにすることで、デザイナーとエンジニアが「ユーザーが見ているもの」を直接触りながら改善できるようになります。
FigmaプラグインのToken StudioやCode Connectを使えば、コードで定義したトークンをFigmaに反映できます。つまり、Figmaでのデザイン作業は今まで通り行いながら、真実の情報源(Single Source of Truth)はコードに置くことができるのです。
効率化の話だけではなく、ユーザー体験の品質そのものに関わる問題だと捉えられます。
型の力で強制できる
無理やり実装を防ぐ仕組み
Findy AI+の設計で最も意識したのは、「デザインシステムから逸脱できない仕組み」を作ることです。
テーマを作った後、実際にデザインシステムを適用させようとすると、無理やり実装しがちです。css=やstyle=のような直接スタイルを当てる方法を使ってしまうケースです。
一度この逃げ道を許すと、デザインシステムは形骸化します。「急いでいるから今回だけ直接スタイルを当てよう」が積み重なり、気づけば誰も使わないものになってしまいます。
コードだからこそ実現できる強制力
Findy AI+では、Chakra UIをベースにデザインを行っています。Chakra UIのStrict Tokenモードを導入し、ESLintのルールを整えました。さらに、CLAUDE.mdとClaude Skillsでルールを明文化し仕組みを整え、生成AIにもデザインシステムを守らせるようにしました。
すると、エンジニアは必ずデザインシステムで定義されたトークンやコンポーネントを使わざるを得ない状況になります。例えば、直接スタイルを当てようとすると、Lintエラーが出てしまいます。
この強制力があることで、デザインシステムを形骸化させない鍵になると考えています。そして、この仕組みは今後デザインツールでできるようになるかもしれませんが、現在はまだ実現できません。コードで管理するからこそ、型の力で強制できます。
デザインされたものを一からコンポーネントとして実装するには多大な設計が必要です。しかし、Findy AI+では最初からデザインシステムをコードで定義し、逸脱できない仕組みを整えてきました。その結果、開発者が迷わずに実装でき、ルールが統一しつづけられる環境を作りました。
最初から徹底できる
後付けでは浸透しない
デザインシステムの導入で最も難しいのは、浸透させることです。
すでに動いているプロダクトに後からデザインシステムを導入しようとすると、既存のコードとの整合性を取る作業が膨大になります。そして、その移行期間中は「デザインシステムを使っている部分」と「使っていない部分」が混在し、一貫性が失われます。
既存のプロダクトでも徐々にデザインシステムを適用していっていますが、浸透するまでに時間がかかります。デザインとしての一貫性がない状態からのスタートだったり、エンジニアがコンポーネントを置き換える作業が必要だったりと、後付けの導入には多くの障壁があります。
AI時代の開発スピードに対応する
AI時代の開発スピードを考えると、後から統一する時間的余裕はありません。
最初に型を作り、デザインシステムを稼働させながら作ることがAI時代の作り方だと考えています。
Findy AI+では、プロダクト開発の初期段階からデザインシステムをコードとして定義し、そこから逸脱できない仕組みを整えました。この「最初から徹底」を実現するには、コードで管理することが不可欠です。
デザインをコード管理することは必要不可欠
Findy AI+でのデザインシステム設計を通じて、「なぜコードで管理することが不可欠なのか」を改めて実感しました。
ここまでを改めてまとめると、コードで管理すべき理由は大きく3つです。
- ユーザーと同じ環境でものを見ることができること
- 型の力で逸脱を防ぐ仕組みが作れること
- プロダクト開発の初期段階から徹底して効率を上げられること
デザイナーとエンジニアの両者が、デザインシステムの重要性を理解し、そして「コードで管理すること」の価値を理解していただけたら幸いです。
Figma Schemaが示す方向性
ちょうど先日、Figmaが「Schema」というイベントで発表した内容がこの考え方と合致していました。
Figmaの方針として、デザインシステムを「AIが読み取りやすいルールブック」として整備する方向に舵を切っています。Code Connect UIでFigmaコンポーネントとGitHub上のコードを紐付ける機能が発表されました。Figma MCP ServerでAIツールからFigmaデータを参照しやすくする機能も登場しています。VariablesのエクスポートでFigma変数をコードへ持っていきやすくなるなど、「FigmaデータとコードをつなぐAI前提の機能」が続々と出てきています。
この流れは、本記事で述べた「コードで管理する」という考え方を後押ししてくれるものだと感じています。Figmaは引き続き強力なデザインツールとしてプロトタイピングに活用しながら、ユーザーが見る実コードに主眼を置くことが大事だなと改めて思いました。
なお、今回は「Why」を中心にお伝えしましたが、FigmaとCode Connectの連携方法、Token Studioの活用、Storybookでの運用など、具体的な「How」についても今後記事にしていきたいと思います。
ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味がある方はこちらから ↓
