日単位から分単位へ：「バイブコーディング」でDesign Systemを開発に適用する

今回は社内コラボ企画として、開発企画部のメンバーに寄稿いただきました。

普段はインフラやセキュリティを中心にお届けしている当ブログですが、本日は開発領域のトピックとして「バイブコーディング」をご紹介します。ぜひ最後までご覧ください。

こんにちは！私はアダムで、開発企画部のエキスパートです。現在、AIを現在の開発ワークフローへ統合する方法や、データがビジネスの意思決定をサポートする方法について研究を進めています。常に新しい技術について学び、それらをどのように活用して仕事をより効率的にできるか考えています。本日は『Vibe Coding』についてご紹介し、現在のワークフローでそれがどのような意味を持つのかを説明したいと思います。

これまでのソフトウェア開発におけるデザインの適用はまるで「伝言ゲーム」のようなリレー競技でした。プロダクトオーナーが要件を書き、デザインチームがFigmaを作り、エンジニアがそれをコードに翻訳し、QAが確認する。

しかし、バトンを渡すたびに文脈は失われ、解像度は落ちていきます。そしてエンジニアは、「ここの余白は8pxですか？10pxですか？」という確認作業や、CSSの微調整という「翻訳作業」に何時間も費やすことになります。

この問題を解決するために、私たちは 「バイブコーディング」を用いたアプローチを導入しました。これは単なるAIによるコード生成ではありません。「要件 → デザイン → 実装」のパイプライン全体を構造化し、エンジニアがコーディング（タイピング）ではなく、アーキテクチャと品質に集中するためのワークフローです。

本記事では、概念だけでなく、「具体的にどうやってFigmaとコードを繋いでいるのか」「ビジネスロジックはどう扱うのか」 という実装の裏側まで踏み込んで解説します。

1. ワークフローの全体像

Figma（SSOT） → MCP Server（構造化） → Cursor（生成） → Gitlab（レビュー/CI）

重要な構成要素

Design System Figma: デザインのマスタ（Single Source of Truth）。
Figma MCP Server: ここが肝です。Figmaのデザインデータを、AIが理解しやすいJSON形式に変換するブリッジ役です。
Cursor (AI): エンジニアのIDE。MCPサーバーから受け取ったJSONを元に、React/Vueなどのコンポーネントコードを生成します。

2. 前提知識：なぜ「Design System」が必要なのか？

このワークフローの核心は、「AIにゼロからコードを書かせない」ことです。そのために不可欠なのが Design System（デザインシステム） です。

Design System とは？

単なる「UIキット」ではありません。デザインとコードの共通言語として機能する、再利用可能なコンポーネントとルールの集合体です。

Design Tokens (Atoms): 色（#0055FF → primary-blue）、余白（8px → spacing-sm）、タイポグラフィなどの最小単位。
Components (Molecules): ボタン、入力フォーム、カードなど、トークンを組み合わせて作られたUI部品。
Guidelines: 「いつPrimaryボタンを使うか」「エラー時はどう表示するか」などのルール。

Figmaでの運用

私たちのFigmaファイルでは、Design Systemの厳格な実装を行います。例としてデザイナーは「ライブラリからButtonコンポーネントを配置し、プロパティ（Variant）を切り替える」 という操作を行います。これにより、MCP Serverは「幅100pxの青い四角」ではなく、「Buttonコンポーネント（Primary, Large）」 という意味のあるデータとしてデザインを認識できるのです。

3. 技術的詳細：Figmaとコードをどう繋ぐのか？

では「どうやってFigmaの絵を正確なコードに変換しているのか？」という点を解説します。

秘密は「MCP Server」と「Design System」

私たちは Figma MCP (Model Context Protocol) Server を使用しています。これは単に画像を解析しているのではなく、Figmaの Dev Mode API を通じてノード情報を取得し、以下のような「意味のあるJSON」に変換しています。

AIが受け取るデータのイメージ:

{
  "componentName": "CheckoutCard",
  "structure": [
    {
      "type": "Frame",
      "layoutMode": "AUTO_LAYOUT",
      "gap": "var(--spacing-md)",
      "children": [
        {
          "type": "Instance",
          "componentId": "Button_Primary",
          "props": { "label": "購入する", "state": "disabled" }
        },
        {
          "type": "Text",
          "content": "¥1,200",
          "style": "text-xl-bold"
        }
      ]
    }
  ]
}

既存コンポーネントへのマッピング

AIへのプロンプトには、「プロジェクト内の既存コンポーネントライブラリ（Storybook等）の定義ファイル」 をコンテキストとして与えています。これにより、AIは「四角形を描画するコード」ではなく、「<Button variant="primary" /> をインポートして配置するコード」を生成します。

ここでのポイント：

Figma上のコンポーネント名と、コード上のコンポーネント名を一致させておく（命名規則の統一）。
Design Systemが整備されていない（CSSがカオスな）環境では、このワークフローは機能しません。

4. エンジニアの仕事はどう変わったか？（Before / After）

Before: 1日がかりの「翻訳」作業

Figmaを見て div を組み、CSSを書く。
「このボタンのhover時の色は？」とデザイナーにSlackで聞く。
レスポンシブ対応で崩れたレイアウトを直す。
結果: ロジックを書く前に体力を消耗する。

After: 30分の「統合」作業

エンジニアはCursorで次のように指示します。

「FigmaのCheckoutCardを選択中。これを実装して。ローディング状態とエラー状態も考慮して。Playwrightのテストも書いて。」

すると、UIの骨組み（Scaffold）が数秒で生成されます。エンジニアの仕事はそこから始まります。

ロジックの注入: 生成されたUIに、実際のAPIフック（useMutation など）を接続する。
エッジケースの対応: 「在庫切れの時はボタンを非活性にする」といったビジネスルールを実装する。
セキュリティ: 入力値のバリデーションや権限チェックを追加する。

つまり、「見た目を作る」時間がほぼゼロになり、「動きと品質を作る」時間に全振りできるようになったのです。

5. 導入の壁：デザイナーへの負担

このフローを成功させるには、デザイナー側の協力と準備が不可欠です。

StrictなFigma運用: Auto Layoutを正しく使う必要がある。
変数の徹底: #F5F5F5 のような直書きは禁止。bg-surface-secondary のようなトークンを使う必要がある。

当初、デザイナーがこの厳格なルールや新しいワークフローに慣れるまでには少し時間が必要でした。しかし、「自分が作ったデザインが、1ピクセルのズレもなく、即座に動くコードとして目の前に現れる」 という体験をした瞬間、大きな感動になりました。「実装時の手戻り」が激減したことで、結果的にデザイナーも本来のUX設計に集中できるようになったのです。