Google Stitch × Claude Code ： AIを業務に組み込み、誰でもデザインできる仕組みをつくる

Google Stitchの大型アップデートがありました。以前設計した「Claude CodeによるtoB LP生成サイクル」にStitchを組み込むまでの思考を書き留めます。

"何をつくらないか"を設計する

自然言語で意図を伝えるだけで、高品質なUIデザインが生成される時代。「Vibe Design」という言葉が示す通り、雰囲気やトーンを伝えれば、AIが複数のデザイン方向性を提案してくれます。

「何でもつくれる」という価値はもはや当たり前になってきました。私は、Stitchができることを確認しながら、「何をつくらないか」を設計すべきだと、すぐに考えを巡らせました。

どこで活かし、どこで使わないのか

ツール選定は目的次第です。どれが優れているかではなく「自分は何を達成したいのか」で選ぶべきでしょう。

私の目的は「企業内におけるtoB LPの量産」です。デザイナー以外の社員でも、LPをデザイン・実装できる仕組みをつくること。

この目的を達成するために、まず考えたのは「Stitchを構造のなかに取り込みたい」ということでした。Claude Codeによる LP生成サイクルのどこかに組み込めるはずだと。

Stitchの創造性と自由度は大きな魅力です。しかしだからこそ「それをどこで活かし、どこで使わないのか」を決めなければ、組織活用に至らない。"制御" が必要だと考えました。

デザインからコードか、コードからデザインか

Stitchはデザインからコードへ向かうアプローチです。雰囲気や意図を伝え、視覚的なデザインを生成し、そこからHTML/CSSを出力する。強みは、デザインの多様性と洗練度。複数の方向性を高速で探索可能にします。

Claude Codeはコードからデザインへ向かうアプローチです。構造化されたmdファイルを入力として、コードを生成し、そのコードがデザインになる。強みは、実装におけるコードの精密さと構造的な品質管理。

どちらが正しいかという問いには意味がない。どちらを主軸に据えるか、目的次第です。

私はClaude Codeを軸に据えました。理由は、再現性と品質担保です。3つのmdファイルにデザインの判断基準を構造化し、それに準拠してコードを生成する。この仕組みであれば、誰が実行しても同品質のLPが生まれます。

Phase2を、2段階に分離する

今回、デザインを生成・編集していくPhase 2を、2段階に分離しました。

🟦Phase 2-A（Stitch）：可変部分のデザイン検証
design-system.mdとlp-structure.mdをStitchのキャンバスにコンテキストとして共有し、施策の可変要素（FVのトーン、業界課題への訴求表現、ビジュアルの方向性など）を複数案生成・比較。固定制約の中で、可変領域だけを探索させる。

🟧Phase 2-B（Claude Code）：3md完全準拠のコード実装
Stitchで選定したデザイン案のHTMLを「デザインブリーフ」として参照しつつ、Claude Codeが3つのmdに完全準拠した実装を行う。テキストはcontent-source.mdから一言一句変えずに適用。構造とスタイルはmd準拠で品質を保証する。

ポイントは、Stitchの出力をそのまま使わないこと。Stitchのコードはデザインの意図を伝えるためのブリーフであり、プロダクションコードではない。

枠と型を決めて、狙ったものを生成する

Stitchの創造性をどのように活かすのか。「何をつくるか」よりも「何をつくらないか」。この「やらないこと」を決めること。枠と型を決めて、狙ったものを生成される仕組みをつくる。それは、デザイナーに託された領域のひとつです。

具体的には、3つのmdファイルの中に「固定」と「可変」を明示する。ヘッダー、フォーム、FAQ、フッターは固定。ヒーローのビジュアル方向性、業種別の課題表現、コピーのトーンは可変。Stitchにやらせることは可変セクションの印象探索。やらせないことは固定セクションの生成、テキストの改変、コンポーネント構造の変更。

この境界線を引くことが、構造設計です。

SKILLが判断基準として機能する

ツールは変わります。今日のStitchが明日にはまた別の機能を持つかもしれない。新しいデザインAIが現れるかもしれない。

しかし、構造化・型化したSKILLが活きることは変わらない。デザインシステム、LP構造、コンテンツ原稿。この3層が判断基準として機能する限り、どのツールを使っても品質は担保される。

SKILLはツールに依存しない。Claude Codeに渡せば実装の基準になり、Stitchに渡せば探索の制約になる。人間が読めば設計意図の共有ドキュメントになる。ツールが変わっても、判断基準として機能します。

デザイナーの仕事は、個別のLPをつくることではなく「何をつくれるようにし、何をつくれないようにするか」という意思決定と、その仕組みを整備すること。そして、誰もがデザインできる環境をつくることです。