個人開発

Stitch + Claude Code でデザインから実装まで自動化してみた話

ワイヤーフレームのスケッチ
Photo by picjumbo.com on Pexels

Stitch とは

Stitch は Google Labs が提供している AI デザインツールです。テキストでイメージを伝えると、モバイルや PC 向けの UI 画面を生成してくれます。

特徴的なのはデザインシステム機能で、カラーパレットやフォント、コンポーネントのルールを定義しておくと、生成される画面が一貫したデザインになります。

無料で使えて、月 550 回(Standard 350 + Pro 200)生成できます。個人開発のデザインには十分です。

MCP 連携でできること

Stitch には MCP サーバーがあって、Claude Code から直接操作できます。API キーは Stitch の設定画面から取得できます。

Stitch の API キー取得画面

使えるツールはこんな感じです。

  • プロジェクト管理: create_project, get_project, list_projects
  • 画面生成: generate_screen_from_text, edit_screens
  • デザインシステム: create_design_system, apply_design_system, list_design_systems
  • 画面取得: list_screens, get_screen (HTML コードとスクリーンショット)

読み取り系は安定して動きます。プロジェクトの一覧取得、画面のスクリーンショット取得、デザインシステムのカラートークン取得など、問題なく使えました。

実際のワークフロー

個人開発のアプリで、こういう流れで使っていました。

  1. 新機能の UI を Stitch でデザイン: generate_screen_from_text でモバイル版と PC 版を生成
  2. デザインシステムの同期: Stitch のカラートークンと CSS 変数を突き合わせて一致させる
  3. Claude Code で実装: get_screen で HTML を取得して、コンポーネントに落とし込む

Stitch をデザインの source of truth にして、コード側をそれに合わせる、という運用です。

デザインシステムの同期では、Stitch 側の 40 以上のカラートークン(Primary, Surface, Accent 等)と CSS のカスタムプロパティを比較して、ズレている箇所を特定→修正するということをやっていました。

ハマりどころ: タイムアウト地獄

一番ハマったのは画面生成のタイムアウトです。

generate_screen_from_text は Stitch 側で AI が画面を生成するので、処理に数十秒かかります。MCP クライアント側のタイムアウト上限を超えることがあって、リクエストがタイムアウトします。

厄介なのは、タイムアウトしてもサーバー側は処理を続けている ということです。

リクエスト送信 → タイムアウト (エラー) → リトライ送信 → タイムアウト (エラー) → ...
                  ↓                        ↓
            実は生成されてる          これも生成されてる

結果、リトライした分だけ同じ画面が大量に生成されました。最初 13 画面だったプロジェクトが、気づいたら 34 画面に膨張していました。LP の画面だけで 11 枚の重複です。

対策として学んだのは「投げたら待たずに list_screens で確認する」というパターンです。タイムアウトしてもバックグラウンドで完了していることがほとんどなので、エラーを見ても焦らず確認するのが正解でした。

ハマりどころ: 削除 API がない

で、34 枚に膨らんだ画面を整理しようとしたら、MCP に画面削除のツールがありません。

生成、編集、取得はできるのに、削除だけできない。重複した 16 枚を消すには、ブラウザで Stitch の Web UI を開いて手作業で消す必要がありました。

これは地味にストレスでしたね。今後のアップデートで追加されるといいんですが。

デザインツールの指示に盲従しない

Stitch のデザインシステムには「ボタンに Primary → Primary Container のグラデーションをかける」というルールが書いてありました。でも、自分のアプリではフラットな塗りのほうが好みだったので、意図的にそのルールは無視しています。

AI デザインツールの生成結果をそのまま使う必要はなくて、自分の判断で取捨選択するのが大事です。Stitch のデザインシステムは「ベースライン」として活用しつつ、合わないところは自分の好みを優先する、くらいのスタンスがちょうどいいと思います。

意図的な逸脱はメモに残しておいて、あとで Stitch 側を更新するか判断する、という運用にしています。

結局どう使っているか

Stitch + Claude Code の連携は、読み取り系の用途では安定して使えます。

  • デザインシステムのカラートークンをコードに同期する — これは便利
  • 既存画面の HTML を取得して、コンポーネント実装の参考にする — これも使える
  • 新しい画面のデザインを AI に生成させる — 使えるが、タイムアウトに注意

画面生成のタイムアウト問題がなければもっと活用したいところですが、現状は「デザインの探索ツール」として使って、本格的な実装は Claude Code に任せる、という棲み分けに落ち着きました。

個人開発でデザイナーがいない環境だと、「とりあえず Stitch で方向性を出す → コードに落とす」の流れはかなり助かります。


参照リンク