Google Stitch 2026 アップデート：AI UI ジェネレーターからデザインエージェントのワークフローへ

これまで Google Stitch に触れたことがあるなら、それは単純な AI UI ジェネレーターだと理解しているかもしれません。自然言語を入力し、Web の画面を生成し、フロントエンドコードをエクスポートする、というものです。

2026 年の公開されたプロダクト資料と Google Labs の関連オープンソースプロジェクトを見ると、Stitch の価値はより完全なデザインワークフローへと拡張しつつあります。「ページはどう見えるべきか」に答えるだけでなく、チームが複数ページを整理し、デザインシステムを表現し、デザインのコンテキストをコーディングエージェントに渡す手助けを始めています。

まず混同しやすい境界を説明しておきます。Stitch の Web プロダクト、Stitch MCP／SDK、そして google-labs-code/stitch-skills は同じ階層のものではありません。 本記事ではプロダクトの能力と拡張ワークフローを分けて紹介します。公開資料で Stitch 内蔵と明確に説明されていない能力は、Skills またはエコシステム連携の能力として注記します。

1. 2026 年の Stitch 能力マップ

重複する能力を統合すると、2026 年に注目すべき方向性は 5 つに整理できます。

能力の方向	代表的な能力	解決する課題
AI ネイティブのデザインワークベンチ	Canvas、継続的な編集、Design Agent ワークフロー	一度のページ生成から、継続的なデザイン探索へ
プロダクトフローと Prototype	マルチページ、User Flow、インタラクティブプロトタイプ	単一 Screen から完全なプロダクト体験へ
Design System とデザインコンテキスト	Design System、`DESIGN.md`	複数ページの一貫性を保ち、エージェントにデザイン意図を理解させる
Design ↔ Code	Code-to-Design、HTML、スクリーンショットとコードのインポート	既存のコードとデザインを双方向に流動させる
コーディングエージェント連携	MCP、SDK、Stitch Skills	Stitch を Claude Code、Cursor、Codex などにつなぐ

これら 5 つの能力がともに指し示す変化はこうです。Stitch は孤立した 1 ページの生成だけでなく、プロダクトの方向性を探索し、デザインコンテキストを整理し、それを開発ツールに実装させる用途により適するようになりました。

2. UI ジェネレーターから AI ネイティブのデザインワークベンチへ

Google は Introducing “vibe design” with Stitch の中で Stitch を AI-native software design canvas と説明しています。この位置づけの変化は「生成品質が上がった」ことより重要です。デザインのプロセスを一度きりの出力から、継続的に修正できるワークスペースへと変えたからです。

典型的な進め方はもはや次のようなものではありません。

Prompt
  ↓
ページを 1 つ生成
  ↓
終了

次のようなものです。

プロダクトのアイデア
   ↓
初期デザインを生成
   ↓
現在のコンテキストで修正
   ↓
方向性を比較してイテレーションを続ける

実際には、まず Dashboard を生成し、続けて部分的な修正要求を出していけます。例えば：

Dashboard をよりコンパクトにし、カード間の余白を減らす。
Sidebar を 1280px のデスクトップ幅に合うよう狭める。
モバイルはボトムナビゲーションに変更し、現在のページの主要操作は保つ。

ここで鍵となるのは特定のプロンプトではなく、以降の修正が現在のデザインコンテキストに依存し、毎回ゼロから生成しないことです。

3. 単一ページからプロダクトフローへ拡張

実際のプロダクトが 1 ページだけであることはまれです。ログイン、ホーム、詳細、決済、成功フィードバックの関係は、多くの場合、単一ページの視覚効果よりも重要です。

そのため、Stitch のマルチページと Prototype のワークフローは User Flow の検証に適しています。

Login
  ↓
Home
  ↓
Product
  ↓
Checkout
  ↓
Success

Google は Stitch、Gemini 3 と Prototype の紹介で、こうした画面からフローへの方向性を示しています。注意すべきは、Prototype は 2026 年に初めて登場した能力ではないという点です。ここでより注目すべきは、それが継続的なデザインとコーディングエージェントのワークフローにどう組み込まれるかです。

実用的な判断基準は次のとおりです。

視覚的な方向性を比較したいだけなら、まず同じページの複数のバリアントを生成する。
ユーザータスクを検証したいなら、複数の Screen をつなぎ、フローが完全かを確認する。
開発者に渡すなら、まずページの命名、主要な状態、重要なインタラクションを固定してからコード段階に入る。

4. Design System と `DESIGN.md`

AI は美しいページを生成できますが、ページごとに色、フォント、コンポーネントのルールを推測し直すと、最終的なプロダクトは一貫性を失いがちです。

Design System は統一された視覚とコンポーネントの制約を提供する役割を担い、DESIGN.md はどちらかといえば AI エージェントが読むためのデザインコンテキストファイルです。次のことを記述できます。

色の用途（色値だけでなく）
フォントの階層と情報密度
余白、角丸、シャドウ
Button、Card、Input、Navigation などのコンポーネントルール
レスポンシブレイアウトとアクセシビリティの要件

例えば：

# Design System

## Colors

Primary: #2563EB — 主要な操作と重要なリンクに使用
Background: #F8FAFC
Foreground: #0F172A

## Typography

Font: Inter
Heading: 600
Body: 400

## Components

Button: 8px radius, solid primary color for the main action
Card: 12px radius, subtle border, no heavy shadow

重要なのは、すべてのデザインパラメータをファイルに詰め込むことではなく、「いつ使うか」を説明することです。Primary は単なる青ではなく、主要な操作を意味します。高密度レイアウトも単に padding を減らすのではなく、情報階層と読みやすさを保つことです。

AI デザインワークフローにおける DESIGN.md の公開実践については、Google Labs の Stitch Skills リポジトリを参照してください。現時点でより堅実な理解は、それがエージェントが使えるデザインコンテキストの取り決めであり、すべてのデザインツールが統一対応済みの正式な業界標準ではない、というものです。

5. Design ↔ Code：既存プロジェクトも Stitch に入れる

従来の流れは通常こうでした。

Design
  ↓
Code

Stitch エコシステムは逆方向の流れを補いつつあります。

Code
  ↓
ページとデザイン情報を抽出
  ↓
Stitch にインポート
  ↓
デザイン方向を再探索

stitch-skills の code-to-design スキルは React、Vue などのフロントエンドコードを対象とし、HTML の抽出、デザイン情報の整理、Stitch へのアップロードといった進め方を含みます。次のシーンに適しています。

既存プロダクトをリデザインしたいが、完全なデザインカンプがない。
複数ページの既存実装をデザインコンテキストとして整理したい。
まず Stitch で視覚的方向を探索し、その後コーディングエージェントにコードを修正させたい。

これは Stitch がすべてのビジネスロジックを自動で理解するという意味ではありません。権限、データリクエスト、フォームバリデーション、複雑なインタラクションは依然として開発者の確認が必要です。Code-to-Design は画面構造と視覚的な手がかりの抽出に向いており、コードレビューの代替ではありません。

6. MCP、SDK、Stitch Skills の違い

この 3 つの名称はよく並べられますが、用途は同じではありません。

能力	役割	向いている人
Stitch MCP	互換エージェントが Stitch の能力を呼び出せるようにする	Claude Code、Cursor などを使う開発者
Stitch SDK	プログラムから Stitch 関連の呼び出しを組織する	自動化や独自統合が必要なチーム
Stitch Skills	デザイン、ビルド、補助フローを Agent Skills としてカプセル化する	完全なワークフローを再利用したい開発者

stitch-skills 公式リポジトリによると、現在公開されているスキルはデザイン生成、Code-to-Design、デザインシステム管理、静的 HTML 抽出、React／React Native コンポーネント生成、プロンプト強化、マルチページループなどの方向をカバーしています。

これらのスキルは Stitch MCP と対応する認証設定に依存します。それらは Google Labs がオープンソース化したワークフロープロジェクトであり、Stitch の Web で既定で有効になっているすべての機能と同一視すべきではありません。インストール前に、リポジトリの README と Stitch MCP ドキュメントの最新の説明を基準にしてください。

7. 実行可能な SaaS Dashboard の例

以下では、SaaS 分析管理画面を例に、これらの能力をどうつなぐかを説明します。最初のステップは色だけを説明するのではなく、プロダクトの目標を記述することです。

Create a responsive SaaS analytics dashboard for a small product team.
Include a sidebar, KPI summary, weekly revenue chart, recent activity,
and a clear primary action for inviting a teammate.
Use a compact desktop layout and a mobile bottom navigation.
Keep the visual language calm, accessible, and suitable for daily work.

次に、現在のデザインコンテキストの中で制約を続けます。

Create three screens: Dashboard, Analytics, and Settings.
Use the same navigation, spacing scale, button hierarchy, and card treatment
across all screens. Show the main user flow from Dashboard to Settings.

方向が定まったら、デザインシステムの要件を補足します。

Apply the project's DESIGN.md rules.
Do not introduce new accent colors, arbitrary shadows, or one-off border radii.
Preserve the same information hierarchy on desktop and mobile.

チームにすでにフロントエンドプロジェクトがある場合は、まず code-to-design で既存ページを整理し、Stitch に戻ってリファクタリングの方向を比較できます。デザインの確認が完了したら、コーディングエージェントにコンポーネント、ルーティング、データインターフェースの実装を任せます。

推奨する受け渡しの順序は次のとおりです。

要件
  ↓
Stitch で UI を生成・探索
  ↓
Prototype で主要フローを検証
  ↓
Design System と DESIGN.md を固定
  ↓
Stitch MCP / Skills
  ↓
Coding Agent がコードを実装
  ↓
ブラウザと実データで検証

8. どの能力が明確で、どれが慎重な理解を要するか

現在公開されている Google の資料と stitch-skills リポジトリによると、比較的確実に確認できます。

Stitch は自然言語駆動の画面デザインとイテレーションに向いている。
マルチページ、Prototype、プロダクトフローは重要な利用方向である。
Stitch Skills はデザイン生成、Code-to-Design、デザインシステム、コード生成などのワークフローを公開している。
MCP は Stitch と外部エージェントをつなぐ重要な統合方法である。
React、React Native、静的 HTML などのコード関連能力は、主に対応する Skills や統合フローを通じて理解すべきである。

以下は、追加の公式情報源がない限り、プロダクトの約束として書くべきではありません。

すべての機能がすべてのアカウントと地域で開放されている。
Stitch の Web プロダクトにすべての Skills が内蔵されている。
SDK の具体的な API、クォータ、商用条件が長期的に不変である。
自動生成されたコードがレビューなしでそのまま本番環境に使える。

この区別は重要です。記事の過度な宣伝を避けられ、読者が最新の状態をどこで確認すべきかも分かります。

9. Stitch は何を解決するのに適しているか

Stitch は次の仕事により適しています。

開発前に複数のプロダクト方向を素早く探索する。
マルチページと Prototype でユーザーフローを検証する。
デザインシステムと視覚的意図を、AI が読めるコンテキストに整理する。
デザイナー、プロダクトマネージャー、コーディングエージェントが同じ参照を使うようにする。
既存のフロントエンドページをデザイン段階に戻し、構造とビジュアルをリファクタリングする。

すべてのプロフェッショナルなデザインとエンジニアリングの仕事を置き換えるものではありません。複雑なインタラクション、アクセシビリティの細部、パフォーマンス、データセキュリティ、権限モデル、本番コードの品質は、依然として専門家の確認が必要です。

10. 2026 年 10 月のアップデート：CLI と画像エンジン

2026-10-01：Stitch CLI がリリース、ターミナルが 3 つ目の入口に

10 月 1 日、公式が Stitch CLI（@google/stitch）をリリースしました。それまで Stitch の接続方式は主に MCP と SDK の 2 つでした。CLI が加わり、接続の構図は MCP + SDK + CLI の 3 入口になりました。

CLI の 3 つの能力：

ローカルのコーディングエージェントと接続する。
画面とデザインシステムを生成する。
ローカル開発サーバーのスナップショットを Stitch に送り返す。

うち stitch agent-skills add --user の 1 コマンドで、Claude Code、Cursor、Codex、Gemini CLI、Antigravity に Skills をまとめてインストールできます。コマンド単位の実践と注意点は Stitch CLI 完全ガイドをご覧ください。

同じ時期に、公式の stitch loop コマンドも公開されました。コードベースとユーザーフィードバックを継続的に監視し、改善案を自律的に提案するもので、現在も公開されている詳細は限られています。

2026-10-06：Nano Banana 2.1 が登場、画像素材生成が世代交代

10 月 6 日、Nano Banana 2.1 がリリースされ Stitch に統合されました。公式は 2 つの用途を明確にしています。Hero 画像とベクター風ロゴです。これにより画像とロゴを Stitch のワークフロー内部で完結でき、外部の画像ツールに依存しなくなりました。

プロンプトテンプレートと使い方は Nano Banana 2.1 で Hero 画像とロゴを生成するをご覧ください。

同じ時期に、公式は「Stitch のデザインカンプ → Jetpack Compose ネイティブコンポーネント → エミュレーターと実機」という完全なワークフローもデモしました。別途整理しています：Stitch のデザインを Android ネイティブアプリに。

11. まとめ：Stitch はデザインとコードの間の 1 層になりつつある

以前の Stitch はこう要約できました。

Prompt
  ↓
UI
  ↓
HTML

今は次のように理解するほうが適しています。

プロダクト要件
  ↓
AI デザインワークベンチ
  ↓
マルチページと Prototype
  ↓
Design System / DESIGN.md
  ↓
MCP / SDK / Stitch Skills
  ↓
Coding Agent
  ↓
React、Vue その他のフロントエンドコード

2026 年で最も注目すべきは、孤立した 1 つの生成ボタンではなく、Stitch がより完全な経路を補おうとしていることです。

プロダクトを理解する → デザインを探索する → デザインコンテキストを固定する → エージェントに実装させる → 結果に基づいてイテレーションを続ける。

Stitch を使い始めたばかりなら、まず小さなマルチページのフローから始め、最初から完全なプロダクトの生成を求めてはいけません。まずページ構造とユーザータスクを検証し、次に DESIGN.md を整理し、最後にコーディングエージェントの実装段階に入る——この順序のほうが安定した結果を得やすいです。