こんにちは、Amebaのデザインシステム「Spindle」でテックリードをしている原 (@herablog) です。
本記事では「Spindle 2025」と題し、今年の変化と具体的な取り組みを振り返ります。
※ 本文は2025年時点の活動を振り返った内容のため、現在の状況とは一部異なる場合があります。
2024年から2025年への変化
2024年までの Spindle は、「人と人の協業」を軸に、ブランドガイドラインやデザイントークン、UIライブラリを整備してきました。特に UI ライブラリでは、デザイナーとエンジニアが Design Doc を共に作り、実装・運用まで進めることで、職種をまたいだコミュニケーションの円滑化に注力してきました。
2025年からは、この流れに AI が本格的に加わりました。要件整理や事例収集、デザイン案や命名支援、Design Doc のドラフト生成、実装支援、リリース時の整理まで、ほぼ全工程で AI が関与するようになっています。
以降では、2025年に Spindle で取り組んだ具体的な事例を紹介します。
Spindle MCP サーバーの作成
2025年に最初に取り組んだのが Spindle MCP サーバーの開発です。特定の課題解決というより、「これまで Spindle に蓄積してきた資産を AI エージェント からも使えるようにしたい」という動機が出発点でした。また、様々なプロダクトやツールが MCP 対応していた時期でもありました。Spindle の GitHub リポジトリにはコンポーネント実装、ドキュメント、デザイントークン、アイコン、Design Doc などが揃っており、これらを MCP 経由で提供すれば活用の幅が広がると考えました。
Spindle は OSS として公開されていたためセキュリティ面のリスクが低く、開発から公開までをスピーディに進められた点も後押しとなりました。Spindle MCP サーバーの詳細については「Spindle MCP で変わるデザインシステムの開発 ~ Figma 連携で実現する超高速開発 ~」をご参照ください。
Spindle MCP サーバーの活用事例
それでは Spindle MCP サーバーの活用事例をいくつか紹介します。
新規コンポーネント作成時の Design Doc とコード生成
新規 UI コンポーネントでは、Spindle MCP サーバーから取得したデザイントークンやアクセシビリティチェックリスト、過去実装をもとに Design Doc を自動生成できるようになりました。初期生成の精度は高く、ほぼ基準を満たした状態でスタートできます。さらに、この Design Doc から実装コードを生成することで、開発時間も短縮できています。
詳細は「Spindle MCPと作るAI時代のSpindleコンポーネント」をご覧ください。
デザイントークン整理・新規作成
Spindle には色や影、アニメーションなどのデザイントークンはありましたが、余白は未対応でした。そこで Spindle MCP サーバーから既存トークンや実装コードの情報を取得し、余白の実装を整理・トークン化しました。手動では時間がかかる作業を効率化でき、大きな時間短縮につながりました。この作業はデザイナーが好みの AI ツールを使って実行しました。リポジトリに繋がなくても AI エージェントにつなげる MCP サーバーという存在が役に立った例でした。
社内ツール「MCPポータル」のUI改修
AIオペレーション室で運用している社内ツール「MCP ポータル」の UI 改修では、Spindle MCP サーバーを用いて画面を段階的に Spindle 準拠へ置き換えました。管理画面では「作り込みに時間をかけられない」「ページごとに実装すると統一感が出ない」「デザイナー不在」といった課題がありますが、この手法によりデザインレビューの負担を抑えつつ、統一感のある UI を短時間で実現できました。
Design to Code
次に取り組んだのは、Figma のデザインデータやスクリーンショットからのコード生成です。2025年初頭は「デザインをそのまま実装に落とせるのでは」という期待がありましたが、実際には余白や文言、サイズのズレが多く、一つ一つを目視で確認し直す必要がありました。
その後、Figma 公式の MCP サーバーが登場し状況が改善しました。React + Tailwind CSS での出力に加え、Code Connect によるデザインとコードの紐づけが可能になり、生成精度が大きく向上しました。詳細は「Figma MCP Serverで変わるWeb開発」をご覧ください。
お問い合わせフォームのUIを、Figma MCP 連携で10倍はやく実装する
Figma MCP サーバーがリリースされ、ある程度 Design to Code の現実味が増してきたところで、どれくらいのポテンシャルがあるのか実験をしてみました。Figmaでデザインしたお問い合わせフォームを 「人が一から」と「MCP 利用」で実装した場合の時間を計測し比較してみたところ、以下の結果になりました。
- 人が Spindle コンポーネントで一から実装：27分9秒
- Figma MCP + Spindle MCP を使って実装：2分24秒
＼Spindle🤝AIを検証🟢／
デザインシステムとAIの融合はどれだけ開発を加速させるのか？
先日発表された「Figma Dev Mode MCP Server」を使ってみました✋🧐
自作のSpindle MCP Serverと連携するとさらに・・・
高精度かつ「約10倍はやい」可能性が😮💫
検証の様子は動画でご覧いただけます😉▶️ pic.twitter.com/AerBHLdnVg
— Ameba Design System Spindle (@AmebaSpindle) June 6, 2025
MCP を使うと、作業速度はおよそ 10 倍改善しました。この例では、従来のように Figma を見ながら細部確認と実装、再確認を繰り返す必要がなく、高精度なコードが生成されるため、人は軽い調整と確認だけで済みました。プロンプトも「この Figma の URL を Spindle で実装して」といったシンプルな指示で十分でした。
Spindle での「ワンクリック実装」はまだ先
先ほどの事例はうまくいったケースですが、Design to Code の「完全自動化」にはまだ届いていません。ページ全体を生成しようとすると細かなずれが残り、それぞれ実装の修正が必要になります。
また精度は Figma デザインの作りに大きく依存し、オートレイアウトや Variables、Code Connect を適切に使わないと求める結果は出にくかったです。
今後は Design to Code に限らず、要件からのプロトタイプ生成や UI のランタイム生成も想定しています。その基盤となるのがデザインシステムで、UI コンポーネントやデザイントークンは、AI と協業する際に役に立つはずで、中長期で検証していきたい領域です。
AI 時代に向けたリポジトリ整備
AI 導入により成果物が増える一方、開発サイクルが整っていないと PR が滞留します。特に AI 開発では、正しさの基準と自動チェックの仕組みが重要です。Spindle ではある程度その仕組みは用意されていたものの十分に整備できていなかったため、AI エージェントを活用してリポジトリと開発フローを改善しました。
その結果、導入前 (6〜8月) は 3か月で 19件だったマージ数が、整備後 (9〜11月) には 123件まで増加しました。機能追加だけでなく、依存更新やドキュメント整備といった後回しになりがちな PR も消化できるようになった点が大きな変化です。言い換えれば以前は必要なリポジトリ整備を後回しにし、機能追加だけを優先してマージしていたということです。
以降では、2025年に行った具体的なリポジトリ整備の例を紹介します。
AI を活用したリポジトリ改善
開発サイクル改善の第一歩は、依存アップデートのエラー解消でした。従来は更新によるテスト失敗の原因調査が重く、PR のマージが滞りがちでした。しかし AI エージェントにリリースノートやエラーログ、該当コードから調査を依頼し、修正してもらう形にしました。その提案を起点に判断することで大幅に問題解決までの時間が短縮されました。この流れから、依存更新時のランタイムエラー修正の自動化も生まれました。
あわせてテスト環境も整理し、不要なテストや古い設定を見直して高速かつ信頼できる構成に改善しました。テストの実行タイミングや結果が安定すると AI エージェントが自動で修復しやすくなりました。結果的に大量の変更が来ても自動的にテストでき、マージ・リリースできるリポジトリになりました。
AI エージェントを前提にしたワークフローの整備
AI エージェントに継続的に動いてもらうには、作業中に出てきた問題を解決し「AI エージェントが利用できる形」に落としこんでいく必要がありました。今年はベースとなる情報を AGENTS.md / CLAUDE.md に記載したり、レビューガイドラインを整備したり、繰り返す作業はフローを定義し記載したり、より探索しやすいようにディレクトリ構造に一貫性を持たせたりしました。また、ChatGPT と Spindle リポジトリを連携し、エンジニアでないメンバーでも仕様を調査できるようにしました。仕様の調査をエンジニアがソースコードから紐解いていた時間 (約2分) に比べ、ChatGPT 経由で調査すると約10秒ほどに時間を短縮できた例もありました。
Design Doc を量産できる状態に
Spindle には過去の経緯で Design Doc がないコンポーネントがいくつかありました。文章を書くことが得意でなかったり、時間がかかるといった理由で、開発者の心理的なハードルになっていることもありました。そこで Design Doc 作成フローをコマンド化し、たとえば /create-design-doc Button のように実行すると、草案が自動で出てくるようにしました。
このコマンドでは、まずコンポーネントのステータスを確認し、Design Doc テンプレートや既存の Design Doc を参照します。次に既存の実装コードを解析したうえで Design Doc を生成します。その過程で、「どんな Story やテストを書くべきか」といった提案や、不足しているテストの生成もできるようにしました。これにより、Design Doc 作成が属人化せず、誰でも (AI エージェントでも) 一定品質の Design Doc を量産できる体制が整いました。最近では Codex にクラウド実行環境を用意したことで、ローカル環境に依存せず、いつでも実行できるようになっています。
さらに副産物として、Design Doc を埋めていく過程で AI エージェントがレビューガイドラインで指示されたテスト不足や実装の抜け漏れを見つけてくれました。ドキュメントが整備されただけでなく、プロジェクト全体の信頼性も向上しました。
Spindle は人と AI の共通言語へ
2025年は、AI エージェント向けに環境を整備し、自律的に AI が使われ始めた年でした。AI によって実装の多くが自動化されていきますが、「何が正しいのか」を判断し、ブランドとしてどう見せるかなど成果物の品質を管理するのは、依然として人の役割です。 また、AI に関連する技術やツールの進化もはやく、その時に応じた仕組みにアップデートし続ける必要があります。Spindle はこれからも、人間と AI の両方が利用する「共通言語」として進化し、Ameba の品質を支える基盤でありたいと考えています。