はじめに
こんにちは。ラクスル Advent Calendar 2025 9 日目を担当する、ラクスル事業 Web エンジニアの長澤です。
ラクスルには、デザインシステムとして kamii というものがあります。 designsystem.raksul.com
しばらくの間、あまりアクティブな開発が行われていない状態だったのですが、今年に入り小さく無理のない範囲から再構築の取り組みを行ってきました。
本記事では、再構築の第一歩となったデザイントークンの取り組みと、その成果物を活用した MCP サーバーの開発について説明します。そして、Figma MCP Server との併用により実現した、デザインシステムに準拠した AI ネイティブな開発手法について紹介します。
デザイントークンの再構築
kamii は、UI コンポーネントライブラリを内包しているデザインシステムですが、すでに様々なチームから使用されており影響が大きいため、いきなり UI コンポーネント側に手を入れるのは難しい状況でした。
そこで、まずは比較的プリミティブなものである、デザイントークンの再構築から小さく始めてみることにしました。
まず、Figma を「信頼できる唯一の情報源」(Single Source of Truth) とする方針を定め、Variables 機能を用いてデザイントークンを定義しました。その定義から JSON ファイルを生成する仕組みを kamii-token という社内ライブラリとして開発し、CSS 変数などでアプリケーションから参照できるようにしました。
JSON のデータ形式は、標準化団体である W3C 内の Design Tokens Community Group が策定している Design Tokens specification に準拠する形としました。（最近仕様が stable になりましたね）
www.designtokens.org
Variables では Code Syntax というものを設定でき、これを使うと CSS 変数と紐づけることができます。その結果、Figma Dev Mode で表示できるコードスニペットで適切な CSS 変数が使われるようになります。
以上の取り組みにより、デザイントークンをアプリケーションから CSS 変数として参照できるようになりました。
これまでデザイントークンの配布は TailwindCSS plugin 経由のみでしたが、CSS 変数として提供することで、Tailwind を使用していない既存のアプリケーションでも小さく導入しやすくなりました。
以前は、Figma 上のデザイントークンの値と実装上の値が異なってしまうという問題も発生していたのですが、機械的に生成を行うようになったのでその心配もなくなりました。
kamii-mcp の開発
今年は MCP サーバーが一般化し、デザインシステムにおいても、コンポーネントのデータを MCP サーバー経由で参照できるようにする動きが広まりました。
個人的にも技術的な興味があったので、kamii-token を活用し、kamii-mcp という MCP サーバーを開発しました。
デザイントークンの再構築と同様の考えで、まずは最小限の機能を実装しました。
kamii-mcp は、現時点では get_design_tokens という 1 つの tool のみ提供しています。その tool は、kamii-token が持つ Design Tokens specification 準拠の JSON をコンテキストに応じて AI に渡すだけのものです。他のデザインシステムの MCP サーバーはコンポーネントのデータも返せることが多いですが、kamii-mcp ではまずデザイントークンに絞って小さく始めることにしました。
Figma MCP Server と kamii-mcp の併用
そんな中、Figma 公式の Figma MCP Server が GA（General Availability）になりました。
先ほども触れた通り、Figma の Variables 機能の Code Syntax を kamii では活用しています。Figma MCP Server では、この Code Syntax をもとにしたコードを提案してくれます。非常に便利な MCP サーバーで、ラクスルのフロントエンド開発においても積極的に活用しています。
しかし、活用する際に開発現場で問題が発生していました。
それは、Figma で UI をデザインする過程で、スペーシングや色指定において Variables を使った指定を忘れてしまう（ハードコードしてしまう）ケースです。
Figma MCP Server は、あくまで「設定された Variables」を読み取るため、紐付けが漏れている箇所では Code Syntax が機能せず、単なるカラーコード（例: #646C75）などが提案されてしまいます。せっかく kamii-token で提供される CSS 変数を使えるのに、使われなくなってしまいます。
このような類のヒューマンエラーは注意していても起こってしまうことなので、仕組みで解決したいところです。1
そこで、kamii-mcp の登場です。
kamii-mcp はデザイントークンの正確な JSON データを AI に提供します。
これにより、たとえ Figma からは #646C75 のようなハードコードされたカラーコードしか渡ってこない場合でも、AI は kamii-mcp の情報を参照し、「#646C75 は var(--kamii-color-text-gray-light) である」と逆引きして推論できます。
つまり、Figma 上のヒューマンエラーがあっても、Figma MCP Server と kamii-mcp が組み合わさることで、相互に補完しあう（フォールバックする）形になります。
この組み合わせにより、デザインシステムに準拠したコード生成がより堅牢に実現できるようになりました。
kamii-mcp は Figma MCP Server の機能強化に伴い、いずれ完全に置き換わるだろうと考えていたため、開発した際にはこのようにフォールバックとして使われることはあまり想定していませんでした。使ってもらったメンバーからそのような活用事例を聞いた際には、驚いたとともに、kamii-mcp の可能性を感じました。
まとめ
本記事では、デザイントークンの再構築と、そこから派生した MCP サーバーの開発とその活用方法について紹介しました。
デザインシステムの再構築という大きな課題に対し、まずはプリミティブなデザイントークンから小さく始めたことで、デザインシステムを導入しやすい環境を整備できました。
さらに、独自の小さな MCP サーバーである kamii-mcp が、想定外の形で機能し、より堅牢なデザインシステムに準拠した AI ネイティブな開発手法の実現に寄与しました。
AI ネイティブな開発を行うにあたって、デザインシステムという考えは非常に相性が良いと考えています。
今後も、着実な取り組みで、デザインシステムの再構築を進めていきたいと思います。本記事が、何かしらの参考になれば幸いです。
参考
- 大塚亜周, 稲葉志奈, 金森悠ほか. ちいさくはじめるデザインシステム. 東京, ビー・エヌ・エヌ, 2023, 324p.
-
Schema 2025 という Figma のイベントで発表された「Check designs」機能で、この問題は将来的に改善される可能性があります。（ハードコードされた値を検出し、正しい Variables の設定を提案する機能）
↩
リンク: https://help.figma.com/hc/en-us/articles/35794667554839-What-s-new-from-Schema-2025#h_01K84PBY9TFHJ40AEC4Q47DGKH
