2026年の春、バイブコーディング（Vibe Coding）のツール群が一斉にメジャーアップデートを迎えました。
旧Stitchはプロンプトを入れると1画面が出てくる「テキスト→UI変換ツール」でした。2.0はそこから大きく飛躍し、AIネイティブな無限キャンバスに生まれ変わりました。 Googleはこれを「Vibe Design」と呼んでいます。 ワイヤーフレームを描く代わりに、作りたいものの雰囲気やビジネス目的を言葉で伝え、AIが複数のデザイン方向を同時に提案する。
固定のアートボードが消え、無制限のワークスペースになりました。テキスト、画像、コードスニペット、スクリーンショットを自由に配置でき、AIエージェントがキャンバス全体の文脈を理解して動きます。 Agent Managerが複数のデザイン方向を並列管理可能。「ミニマル版」「カラフル版」「ダーク版」を同時に走らせ、比較しながら進められます。 以前は1画面ずつ個別に指示する必要がありましたが、2.0のエージェントはプロジェクト全体を見渡して動く。「全画面のロゴを差し替えて」「このデスクトップ版のモバイル版を作って」といった横断的な指示が通ります。
生成されたUIの上で、テキストをクリックして直接書き換える、画像をクリックして差し替える、余白をドラッグで調整する、色をカラーピッカーで変更する——といったFigma的な直接操作がキャンバス上で可能になりました。 これまでは「キャッチコピーを○○に変えて」とプロンプトで指示する必要があった微調整が、クリック1つで終わります。構造を変えたいときだけプロンプトに戻ればOK。
Gemini Liveを活用した音声入力機能。キャンバスに向かって話しかけると、AIがリアルタイムでデザインを更新する。 「メニューのバリエーションを3つ見せて」「この配色をもっと落ち着いた感じに」といった指示を、手を止めずに音声で出せる。AIが質問を返してくることもある。「ターゲットユーザーの年齢層は？」「CTAのコンバージョン目標は？」のように、要件を深掘りしながらデザインが進みます。 現時点ではプレビュー版で、精度は今後改善される見込み。
Playボタンを押してプロトタイプモードに入ると、画面上のクリック可能な要素を自動検出し、タップ先の次画面をAIが自動生成します。 ログイン画面→ダッシュボード、商品一覧→商品詳細ページ、設定アイコン→設定パネル——といった遷移先をAIが推測して生成。ログイン/ログアウト状態、空状態、エラー状態も自動で作られます。 生成されたプロトタイプには共有リンクとモバイル用QRコードが即座に発行。従来Figmaで行っていた画面遷移プロトタイプの作成が、Stitch内で完結します。
Stitch 2.0で最も実務インパクトが大きいのがこれです。 DESIGN.mdは、色、タイポグラフィ、余白、コンポーネントルールをMarkdown形式で記述したファイル。Stitchのプロジェクトに自動でデザインシステムが含まれるようになり、このDESIGN.mdを編集すると接続された全画面に反映されます。
# Design System: コーポレートサイト
## Colors
- Primary: #003366 (Dark Navy)
- Secondary: #0066CC (Blue)
- Accent: #FF6600 (Orange)
- Background: #F5F5F5
## Typography
- Heading: Noto Sans JP Bold
- Body: Noto Sans JP Regular
- Base size: 16px / Line height: 1.75
## Components
- Button: 角丸8px, hover時に明度+10%
- Card: 角丸12px, shadow(0 2px 8px rgba(0,0,0,0.08))このファイルはポータブルです。
Stitch 2.0はMCP（Model Context Protocol）サーバーを搭載しました。
Claude Code、Cursor、Gemini CLI、VS Codeなどから、Stitchのデザインデータに直接アクセス可能。
たとえばClaude Codeに「Stitchプロジェクトのダッシュボード画面を実装して」と指示すると、MCP経由でデザイン情報を取得し、コードを生成。デザインと実装の間でコピー&ペーストを繰り返す必要がなくなりました。
接続方法はHTTPサーバー（https://stitch.googleapis.com/mcp）をエディタに登録するだけ。Google Cloud APIの有効化と認証設定が必要だが、セットアップは数分で終わる。
Stitch上のデザインをFigmaに書き出せるようになりました。Auto Layout構造、名前付きレイヤー、編集可能テキストが保持されます。公式のFigma Communityプラグイン経由で利用可能。 Figmaを中心としたワークフローを持つチームでも、Stitchで高速にプロトを作り→Figmaで詳細を詰める、という連携が成立します。
完全無料。有料プランは存在しません。Googleアカウントのみで利用可能で、クレジットカードも不要です。 生成回数にはキャップがあり、Standard Mode（Gemini 2.5 Flash）で月350回、Experimental Mode（Gemini 2.5 Pro）で月50回。個人利用には十分な量だが、チームで大量に使う場合は意識しておく必要があります。 主な制約
Bolt.newは以前から「プロンプトからWebアプリを生成→デプロイ」ができるツールだったが、データベースや認証は外部サービス（Supabase等）に接続する必要がありました。 Bolt V2ではBolt Databaseが標準搭載され、認証・データベース・エッジファンクション・シークレット管理・ファイルストレージがすべて内蔵されました。新規プロジェクトを作ると、必要に応じてデータベースが自動生成されます。 LLMにはClaude Opus 4.6を含むAnthropicモデルが使えるようになり、タスクの難易度に応じてモデルを切り替えられます。
Stitchで作ったUIのHTMLコードをBoltにペーストし、「このHTMLをベースにユーザー認証とデータベースを追加して」と指示します。Bolt DatabaseまたはSupabase（オプション）を使ってバックエンドが自動構築され、デプロイボタンひとつでNetlifyに公開されます。 UI生成30分 + Bolt実装1〜2時間 = 半日でMVPが完成するイメージです。
Lovableは自然言語でアプリを生成するツールですが、2.0で最も大きく変わったのはチーム対応でsy。
FigmaのURLをLovableに貼り付けるだけで、レイヤーとスタイルを読み取りReact + Supabaseの動くアプリに変換します。Stitchで作ったUIをFigmaエクスポートし、そのままLovableに持ち込むルートも現実的になりました。 無料枠はクレジットカード不要。
v0はVercelが提供するAIアプリビルダー。UIコンポーネント生成ツールとして始まったが、2026年時点ではフルスタックアプリビルダーに進化しています。 特徴的なのはGitワークフローとの統合です。GitHubリポジトリをインポートし、Vercelの環境変数を自動取得、ブランチ作成→PRまでv0のUI上で完結します。非エンジニアでもGit経由のデプロイフローに乗れる設計。
これらのツールは単体でも強力だが、組み合わせたときに真価を発揮する。実務で使える3つのルートを紹介します。
プロトタイプからMVPまで、デザイナーひとりで完結するルート。
テキスト/画像 → Stitch（UI生成・Direct Edits・Instant Prototyping）
↓ HTMLコードをコピー
Bolt.new（バックエンド追加・DB構築・デプロイ）
↓ ワンクリック
公開URLコードが書けなくても、認証・データベース・デプロイまで一気通貫で進む。Bolt Databaseのおかげで外部サービスの設定すら不要になりました。
Figmaを中心にしたチーム開発ルート。
Stitch（高速プロト生成）
↓ Figmaエクスポート（Auto Layout保持）
Figma（チームでデザイン詳細を詰める）
↓ URL貼り付け
Lovable（React + Supabaseアプリに自動変換）Stitchの速度 × Figmaのチーム機能 × Lovableのアプリ化を組み合わせる。デザイナーとエンジニアが分かれているチームに向いています。
デザイナーがプロトを作り、エンジニアにバトンを渡すルート。
Stitch（UI生成 + DESIGN.md作成）
↓ MCP Server接続
Claude Code / Cursor（DESIGN.mdを参照しながら本番実装）MCP経由でエンジニアのIDEからStitchのデザインデータを直接参照できるため、「Figmaと実装が違う」問題が起きにくい。渡す成果物セットは以下の通りです。
引き継ぎセット:
├── requirements.md — 要件定義
├── DESIGN.md — デザインシステム（Stitch/Claude Code共通）
├── prototype/ — StitchのHTML/CSS出力
└── states/ — 状態バリエーション（ローディング/エラー/空）ツールは週単位で進化する。今日覚えたUIの操作方法は半年後には変わっている可能性が高いです。 しかし、requirements.md（何を作るか）とDESIGN.md（どう見せるか）を構造的に定義するスキルは、ツールが変わっても使い続けられます。
Step 1：最初の案件でベースを作る
vibe-coding-assets/
├── clients/
│ ├── A社/
│ │ ├── requirements.md
│ │ ├── DESIGN.md
│ │ └── refine_log.md ← うまくいった修正指示の記録
│ └── B社/
├── templates/
│ ├── requirements_base.md
│ ├── design_corporate.md
│ ├── design_app.md
│ └── design_lp.md
└── cheatsheet/
└── refine_patterns.md ← 修正指示パターン集Step 3：refine_log.mdを書く習慣をつける うまくいった修正指示をコピー&ペーストで記録していく。3案件もやれば「自分の勝ちパターン」が見えてくる。 Step 4：デザインシステムは段階的に育てる 最初から完璧を目指さない。
AIが出力したUIを「磨き込む」工程で最も重要なのは、作り直すか、直すかの判断です。 作り直し = 上流（requirements.md / DESIGN.md）の問題。修正 = 下流の微調整。 この切り分けが速くなると、Refineの速度が劇的に上がります。
AIが指示を無視する場面は必ず来る。その場合
クライアントの要望が「なんかいい感じに」「もうちょっとモダンに」だったとき、従来は言語化に苦労しました。 バイブコーディングでは、言葉で伝わらないなら動くものを見せて選ばせる。
ツールは進化し続ける。Stitch 2.0も半年後にはまた別の姿になっているかもしれません。 しかし、requirements.mdで「何を作るか」を構造的に定義し、DESIGN.mdで「どう見せるか」をルール化するスキルは、どのツールを使っても通用します。バイブコーディングの本質はプロンプトのテクニックではなく、この「定義する力」にあります。 Sources: