Stitch の逆方向ワークフロー：URL からデザインシステムを抽出する

AI で画面を生成するとき、よくある出発点は「モダン、シンプル、余白が十分」といった説明を書くことです。問題は、こうした形容詞の理解が人によって違い、生成結果も「なんとなく違う」ことが多い点です。

発想を変えましょう。スタイルを説明するより、スタイルをそのまま参照するほうが有効です。Stitch に参考サイトの URL を渡すと、そのサイトの背後にあるデザインシステム——色、フォント、角丸、コンポーネントのスタイル——を抽出し、そのままイテレーションを続けられ、エクスポートして再利用できる規約を生成します。

これが本記事で扱う「逆向きワークフロー」です。URL からデザインシステムへ、さらに design.md へ、そして規約を自分のプロジェクトに持ち込みます。

注記：URL からの抽出はコミュニティの実測で検証されている能力で、公式が完全な機能範囲のドキュメントを示しているわけではありません。複雑なサイトでの抽出結果は実際のテストを基準にしてください。

1. 「スタイルを説明する」から「スタイルを参照する」へ：URL が形容詞より優れる理由

形容詞は曖昧で、参照物は具体的です。「大胆でモダンな雰囲気」と言えば、モデルは無数の可能性から推測する必要があります。具体的なサイトを示せば、モデルがすべきことは「読み取って翻訳する」だけです。

これには 3 つの直接的な利点があります。

すり合わせのコストが低い：「あのサイトのように」のほうが「もう少し上質に」よりずっと有効です。
スタイルの一貫性が強い：複数ページが同じ抽出結果から出発するため、ばらばらになりにくい。
資産化できる：抽出結果は design.md としてエクスポートでき、プロジェクトをまたいで再利用できます。

2. 実践：URL でデザインシステムを抽出する（fireship.dev を例に）

手順

参考サイトを 1 つ選ぶ（開発者コミュニティでよく知られる fireship.dev を例にします）。
URL をデザインシステム抽出の入力として Stitch に渡す。
Stitch がデザインシステム定義一式を出力するのを待つ。
抽出結果の色、フォント、角丸、コンポーネントスタイルが期待どおりか確認する。
生成されたプロジェクト内で対話を続けてイテレーションするか、design.md をエクスポートして保管する。

抽出結果に含まれるもの

カラー体系：プライマリ、背景、テキスト、ボーダーの階層。
フォントと文字サイズ：見出しと本文の組み合わせと比率。
形状の言語：角丸の大きさ、ボタンとカードの形態。
コンポーネントスタイル：ナビゲーション、カード、フォームなどの視覚ルール。

見落とされがちな点がもう 1 つあります。生成結果はインタラクティブなコンポーネントであり、静止画像ではないということです。つまり、抽出したスタイルはそのまま「修正を続ける」状態に入れ、スクリーンショットの段階で止まりません。

3. 音声で修正するときの正しい言い回し：機能＋雰囲気のアンカー

音声や対話で修正を続けるときは、記述をシンプルな公式に構造化します。

機能＋雰囲気のアンカー（既知のプロダクトを引用）。

形容詞の積み重ねよりずっと有効です。そのまま使える 3 つの例：

「チャット機能を作って。大胆でモダンな雰囲気のソーシャルプロダクトのような感じで。」
「現在のデザインシステムを保ったまま、設定ページを追加。アカウント、通知、プライバシーの 3 グループを含めて。」
「ホームを開発者ツールのサイト寄りにして。情報密度を上げて、色は抑制して。」

抽出の指示自体も公式化できます。

[参考サイト URL] のデザインシステムを出発点に、再利用可能なデザイン規約を生成してください。
色、フォント、余白、角丸、コンポーネントのルールを含み、各ページのスタイルを一貫させてください。

4. design.md をエクスポート：デザインシステムをプロジェクト横断で再利用する

抽出は第一歩にすぎず、再利用できてこそ目的が果たされます。

抽出結果を design.md としてエクスポートする。
トークンが完全か確認する（色、フォント、余白、角丸など）。
新しいプロジェクトでコーディングエージェントにこのファイルを参照させる（例：AGENTS.md に「UI 作業の前に DESIGN.md を読む」と宣言する）。
公式の lint ツールで定期的に規約が破られていないか検証する。

この流れは DESIGN.md を CI に組み込むで紹介した検証方法と完全に互換です——まず抽出し、次に凍結し、最後にツールで下支えを守ります。

5. Brand Kit との役割分担：いつ順方向で、いつ逆方向か

Stitch はデザインシステムに至る 2 つの経路をサポートしており、方向が逆で適したシーンが異なります。

ワークフロー	起点	適している	適していない
Brand Kit（順方向）	自社のブランド VI、ロゴ、プロダクト画像	既にブランド資産があり、規約に沿った画面を生成したい	明確なブランドビジュアルがまだない
URL 抽出（逆方向）	参考サイトのデザインシステム	成熟したスタイルへ素早く寄せる、方向性の探索	完全にオリジナルの視覚的識別が必要

実用的な提案：初期の探索段階では逆方向のワークフローで方向を探し、プロダクトがブランド化の段階に入ったら順方向に切り替えます。

6. 境界と注意点：スタイルの参考 ≠ 模倣

デザインシステムの抽出が抽出するのはルールであり、具体的なデザインカンプではありません。使う際にはいくつかの境界を守る必要があります。

参考サイトの具体的なページレイアウトや素材をそのままコピーしない。
抽出した色とフォントは、自分で 1 巡調整して差別化を図る。
商用プロジェクトでは、参考サイトのブランド要素（ロゴ、イラスト）を再利用しないことを確認する。
生成結果に対して「AI っぽさの自己点検」を 1 回行う：文字サイズの階層は妥当か、余白は機械的でないか、コンポーネントの状態は完全か。

7. よくある質問（FAQ）

Q1：どんなサイトでも抽出できますか？

公開アクセス可能なページは通常試せます。構造が複雑なサイトやインタラクションの強いサイトは結果の差が大きいため、まず小さく実測してから正式な流れに入ることをおすすめします。

Q2：抽出したデザインシステムは商用プロジェクトにそのまま使えますか？

抽出されるのはスタイルのルールであり、自分のデザインの着想には使えます。ただし具体的なデザイン、素材、ブランド要素はオリジナルを保ち、直接コピーしないようにしてください。

Q3：抽出後、複数ページのスタイルの一貫性はどう保ちますか？

結果を design.md としてエクスポートして凍結し、すべてのページ生成とコード実装が同じ規約を参照するようにし、lint で定期的に検証します。

8. まとめ

逆方向のワークフローが解決するのは「0 から 1 でスタイルを見つける」効率の問題です。1 つの URL が形容詞の一節に代わり、1 つのデザインシステムが一度きりの視覚的な試行に代わります。これを design.md とエージェントのワークフローにつなげれば、再利用可能な完全な経路が得られます。

続けて読む：

規約の検証方法を知る：DESIGN.md を CI に組み込む
ターミナルのワークフローを知る：Stitch CLI 完全ガイド
既成のスタイルとプロンプトを見る：スタイルギャラリー