こんにちは、グッドパッチのUI/UXデザイナーの西山です。

2025年6月に公開したデザインシステム「Sparkle Design」、皆さんはもう使っていただけましたか？

今回の記事では、誰もがよいデザインを生み出せるように設計された「Sparkle Design」を活用して、デザイナーがバイブコーディングでガイドラインサイトのフロント実装に挑戦して得た「学びと気づき」についてお話しします。

作成したガイドラインサイト

以下のリンクから、ガイドラインサイトにアクセスできます。Sparkle Designの具体的な利用方法、アクセシビリティ原則、コンポーネントの用法、UI要素を組み合わせたパターンなどを参照できます。ぜひご覧ください！

👉 Sparkle Design Guidelineページを見る

フロント実装に挑戦する前のスキルセット

まず、デザイナーである私がバイブコーディングに挑戦する前の実装スキルについて触れておきます。正直なところ、Reactでサイトのフロントを実装するには、開発の基礎知識が足りていない状態からのスタートでした。

• GitHub：Issueの起票のみに使用し、PR（プルリクエスト）の作成経験はなし
• 実装経験：過去にWordPressでポートフォリオサイトを作成したり、Studioでコーポレートサイトの実装を行った程度
• 言語理解：HTML/CSS、PHPは基礎知識あり。一方で、JavaScriptは未修得

この状態から、Cursorを用いてAIと対話しながらコードを書く「バイブコーディング」の手法を取り入れて、Reactでの実装に挑みました。

開発環境の構築とエンジニアとの協業

今回、バイブコーディングを実践するにあたり、以下のようなモダンな技術スタックを採用することになりました。

• Framework：Next.js 16 (App Router)
• Language：TypeScript
• Styling：Tailwind CSS v4
• Component Documentation：Storybook
• Package Manager：pnpm

それぞれの公式サイトのドキュメントや、初心者向けの記事や動画でインプットした内容をFigJamにまとめながら、CursorとGeminiを駆使することで、エラーを解消しながら開発環境を構築できました。

構築した開発環境で、実際にデザイナーがフロントを実装するといっても、すべて一人で完結するわけではありません。バイブコーディングで生成したコードを実用レベルに引き上げるには、良いコードかどうかを判断できるエンジニアとの協業が不可欠です。

以下のGitHub上でのやり取りのように、共通化すべき部分と特例として処理する部分の判断など、エンジニアの視点を借りながら実装を進めました。

そして、コンポーネント実装を開始後に、以下の仕組みを整備してもらったことで、レビュー前の段階から実装方法が大きくズレることを防ぐことができました。

• テスト環境の整備、Linter/Formatterの導入（コードの品質を自動でチェック）
• Sparkle Design導入スキルの作成（AIへの指示を最適化）
• PRテンプレートの作成（レビューの依頼内容の型化）

このように、エンジニアからサポートを受けながら、デザインからフロント実装までを一貫して関わることで、下記のような変化が生まれていきました。

フロント実装を担うことで得られた「2つの変化」

1. Figmaのデザインデータとコードの接続への関心

Reactでのフロント実装に挑戦して、最初に直面したのは、Figma上の「デザインデータ」と実際の「コード」の構造的な違いです。

Figmaでプロトタイプやデザインを検討する段階では、どうしても試行錯誤のスピードを優先しがちです。とりあえず作って、共通化は後回し。

「あとで整理しよう」と思っても、すでに多くの画面で使われているコンポーネントを差し替えるのは大変で、結果として「似たようなバリアント」がどんどん増えてしまう。そんな経験はないでしょうか。

一方、コードの世界では構造が似ているものは 「一つのコンポーネント」にまとめ、props（プロパティ）で差分を切り替えて扱う方が、管理がしやすくて柔軟性も持たせることができます。

エンジニアからのレビューを通じて、「このバリアントは本当に必要か？」「構造が似ているので、プロパティで切り替えた方が管理しやすいのではないか？」という「見た目の差分」だけでなく「構造」で捉えるという視点が生まれました。

結果として、デザインの初期段階からコードとの接続を意識するようになり、新しいバリアントを安易に作らず、構造が類似しているならプロパティで管理するようになりました。

フロント実装に触れたことで、デザインデータへの向き合い方も大きく変わったと感じています。

2. 実装を考慮したUI設計の解像度が向上

次に、コードの制約や特性をデザイナーも理解することで、デザインの品質向上に直結することを実感しました。

スマホ基準のレスポンシブ設計

今回採用したTailwind CSSは「モバイルファースト」の思想で作られています。

これまではFigmaでPC版から作成し、「画面幅が狭くなったとき」の表示を後から考えていました。Tailwind CSSでスタイルを記述するときは「スマホ表示」が基準となり、そこから画面幅が広がった場合のスタイルを上書きしていく形になります。

この仕組みを肌で理解したことで、ブレークポイントごとのレイアウト変化をより論理的に捉えるようになり、レスポンシブデザインへのアプローチ自体が変化しました。

コンポーネントの再利用によるUIの一貫性

Reactでの実装は、コンポーネントをブロックのように組み合わせていく作業です。実際にやってみると、想像以上に共通部分をコンポーネント化して、親から子にpropsを渡して、使い回せるように実装していることに気付きました。

このコンポーネントを再利用する観点をUIデザインに取り入れることで、設計意図も明確になり、サイト全体のUIの一貫性が保たれるようになりました。

コンポーネントの状態管理に対する解像度

エンジニアへの連携時に、テキストリンクのようなコンポーネント化していなかった細かい要素の「ホバー時」「フォーカス時」の状態定義が漏れてしまい、エンジニアからフィードバックをもらってから、追加検討を行うことがありました。

しかし、自分で実装するとなれば、すべてのコンポーネントの状態やプロパティを正確に記述しなければ動きません。そのため、デザイン段階から「必要なプロパティはそろっているか」を深く意識するようになりました。

こうした経験から、エンジニアと連携する前に、画面全体だけではなく、クリッカブルなUI要素をすべて状態定義ができているかを、実装観点で確認することを意識しています。

デザイナーでもエンジニアリングの領域に染み出していける

これまでは、エンジニアリングの領域は「専門外」だと線を引いていました。しかし、バイブコーディングを実践することで、その壁を無くすことができました。

分からないこともAIに聞きながら進めれば形になります。エラーが出てもAIと共に解決し、実践の中で専門知識も学ぶことができます。この成功体験により、エンジニアリング領域へ一歩踏み込むことへの心理的ハードルが劇的に下がりました。

また、エンジニアへのリスペクトが深まったことはもちろん、共通言語で話せるようになったり、UIの設計にも良い影響につながるプロジェクトとなりました。

おわりに 

先ほどもご紹介しましたが「Sparkle Design」のガイドラインは、どなたでも自由にご確認いただけます。ご興味を持たれた方は、ぜひ試してみてください。

👉 Sparkle Design Guidelineページを見る

👉 構成や思想をもっと知りたい

導入方法に迷った方は、こちらの記事（導入ガイド：課題から考える、最適なスタートの切り方）を合わせてどうぞ。Sparkle Designが、「もっと速く、もっと良いモノをつくりたい」と願うすべてのデザイナーやチームの力になれたらうれしいです。

そして、組織に合わせたデザインシステム構築支援も行ってるので、デザインシステムの導入にお困りの企業は、ぜひお問い合わせください。一緒に、“使える・続く”デザインシステムを育てていきましょう！