Google Stitch の DESIGN.md でエンジニアとの連携が変わった——デザイン仕様書の新しいかたち

2026.04.12

デザインとエンジニアリングの間にある「溝」は、どのチームにも存在する。デザイナーが作った画面をエンジニアに渡すとき、「このマージンは何px？」「このフォントサイズは何px？」「このボタンの色のコードは？」という確認のやりとりが何度も繰り返される。

私はデザインを担当することが多い。以前は Figma の画面を共有して「あとはここを見てください」と言っていたが、エンジニアから「Figmaの数値と実装が微妙にずれてしまう」「このコンポーネントの状態別の挙動がわからない」という返答がよく来ていた。

Google Stitch 2.0で追加された DESIGN.md という機能を知ったとき、最初は「また新しいフォーマットか」と思った。でも使い始めてみると、エンジニアとのコミュニケーションの仕方が変わった。この記事では、その変化を正直に書く。

結論から言うと

一言で言えば、DESIGN.md は「デザインシステムを自然言語で書いたドキュメント」であり、Stitch の生成に適用できると同時に、エンジニアへのハンドオフ資料としても機能する。専門的なデザインツールの知識がなくても読み書きできる形式であることが、エンジニアとの連携を変えた最大の理由だ。

DESIGN.md とは何か

DESIGN.md とは、Google Stitch 2.0（2026年3月）で追加された、デザインシステムをマークダウン形式の自然言語で定義するファイルフォーマットのことだ。Google Labs が公式に発表した。

従来のデザインシステムは Figma のコンポーネントライブラリや Storybook のようなコード中心のドキュメントとして管理されてきた。これらはデザイナーやエンジニアが専門ツールを使いこなすことを前提としている。

DESIGN.md は違う。「ボタンのプライマリカラーは #1A73E8、角丸は8px、ホバー時は10%暗くする」「エラーメッセージは赤色、フォントサイズは14px、アイコンと一緒に表示する」という具合に、普通の文章でデザインルールを書ける。このファイルを Stitch にインポートすると、以降の生成にルールが自動適用される。

DESIGN.md の構成要素

DESIGN.md に定義できる主な要素は次のとおりだ。

カラーパレット（プライマリ・セカンダリ・エラー・成功・警告・中立色）
タイポグラフィ（フォントファミリー・見出しサイズ・本文サイズ・行間）
スペーシングシステム（余白・パディングの基本単位）
コンポーネントルール（ボタン・フォーム・カード・モーダルの標準仕様）
状態定義（ホバー・フォーカス・ディセーブル・エラーの挙動）
アイコン・画像の使用ルール

これらを一度定義しておくと、Stitch に「前回と同じデザインシステムで」という指示を毎回出す必要がなくなる。また、プロジェクトをまたいで同じデザインシステムを適用することも容易になる。

Figma のデザイントークンとの違い

Figma のデザイントークン管理は強力だが、エンジニアがアクセスするには Figma のアカウントが必要で、表示方法も専門的だ。DESIGN.md はテキストファイルであるため、エンジニアが通常使う Git リポジトリに含めることができる。「デザインの仕様がコードと同じ場所に存在する」という状態を作れることが、開発者フレンドリーな点だ。

エンジニアとの連携がどう変わったか

DESIGN.md を使い始めてから、エンジニアとのやりとりで最も変わったのは「仕様確認の往復が減った」ことだ。

以前のフローはこうだった。Stitch でデザインを生成 → Figmaに移してハンドオフ → エンジニアが確認して質問 → デザイナーが答える → 実装 → 確認 → 修正。この「質問→回答」のループが案件によっては10回以上発生していた。

DESIGN.md を軸にした新しいハンドオフフロー

DESIGN.md を導入してからのフローは次のようになった。まずプロジェクト開始時にDESIGN.mdを作成し、Gitリポジトリに追加する。次にStitchでデザインを生成するときはこのDESIGN.mdを適用する。エンジニアへの引き渡し時はStitchの出力とDESIGN.mdを一緒に渡す。エンジニアはDESIGN.mdを参照しながら実装する。

実際に使ってみて分かったのは、DESIGN.md があることでエンジニアが「仕様を聞かずに判断できる範囲」が増えるということだ。「このボタンのホバー時の色は？」という質問が来る前に、DESIGN.md に「ホバー時は10%暗くする」と書いてあれば、エンジニアは自分で判断できる。

Stitch MCP サーバーによるさらなる統合

2026年3月のStitch 2.0アップデートでは、MCP（Model Context Protocol）サーバーとSDKが追加された（Google Labs 公式発表）。これにより Stitch を開発ツール（AI Studio、Antigravity 等）と連携させ、デザインから実装への移行をより直接的につなぐことが可能になっている。

DESIGN.md + Stitch MCP の組み合わせは、「デザインシステムをAIが参照しながらコードを生成する」というワークフローを実現しつつあり、デザインとエンジニアリングの境界を今後さらに縮めていく方向性が見えている。

DESIGN.md の書き方：実例

実際に私が使っている DESIGN.md の構成例を紹介する（プロジェクト固有情報は省略）。

カラーの定義例：「プライマリカラー：#1A73E8（Googleブルーに近いトーン）。テキストはプライマリカラーの濃い版（#1558B0）。背景色：#FFFFFF。エラー：#D93025。成功：#1E8E3E。警告：#F29900。」

タイポグラフィの定義例：「フォント：Noto Sans JP（日本語）+ Inter（英数字）。見出しH1：28px・太字。見出しH2：22px・太字。本文：16px・標準。注記：13px・標準。行間は本文フォントサイズの1.6倍。」

コンポーネントの定義例：「プライマリボタン：背景#1A73E8・テキスト白・角丸8px・パディング上下12px左右24px。ホバー：#1558B0。ディセーブル：背景#BDC1C6・テキスト#9AA0A6。アイコン付きボタンは左にアイコン8px間隔。」

このように書いたDESIGN.mdをエンジニアに渡すと、「どこを見ればわかる」状態が生まれる。

よくある質問（FAQ）

Q1. DESIGN.md は Stitch 上でどうやって使いますか？

Stitch のプロジェクト設定からDESIGN.mdファイルをアップロードするか、テキストとして貼り付けることで適用できます。適用後は、新しい生成リクエストにDESIGN.mdのルールが自動的に反映されます。既存の生成済みデザインには遡及適用されないため、新規プロジェクト開始時から設定することを推奨します。

Q2. DESIGN.md は技術者でないデザイナーにも書けますか？

書けます。DESIGN.md は専門的なコーディング知識を必要とせず、「このボタンは青色で角丸にする」という自然な日本語でも機能します。より正確な実装のためにカラーコードやpx値を含めることを推奨しますが、最初は大まかな方向性を書くだけでも始められます。

Q3. 複数のプロジェクトで異なる DESIGN.md を使い分けられますか？

はい、プロジェクトごとに異なるDESIGN.mdを設定できます。クライアントAの案件にはクライアントAのブランドガイドラインを反映したDESIGN.mdを、クライアントBには別のDESIGN.mdを使う、という管理が可能です。DESIGN.mdをGitリポジトリで管理すれば、プロジェクトの切り替えもスムーズです。

Q4. DESIGN.md と Figma のデザイントークンは併用できますか？

できます。Figmaのデザイントークンで定義した値（カラーコード・サイズ・間隔）をDESIGN.mdに転記するという使い方が実際的です。DESIGN.md はFigmaの代替ではなく「エンジニアへの補足ドキュメント」として機能させることが、現状の最適な使い方です。

Q5. DESIGN.md はどこで管理するのがベストですか？

開発チームのGitリポジトリのルートディレクトリに置くのが最もシンプルです。エンジニアが普段使うリポジトリと同じ場所にあることで、「仕様を確認するためにFigmaを開く」という手間がなくなります。また、GitのバージョニングでDESIGN.mdの変更履歴も管理できます。

Q6. DESIGN.md に書いた内容が Stitch に正しく反映されているか確認する方法は？

DESIGN.mdを適用したあと、「ルールに従ってシンプルなボタンを生成してください」という短いテストプロンプトを実行します。生成された結果がDESIGN.mdに記載したカラー・フォント・サイズと一致しているかを目視で確認するのが最も確実な方法です。