Google Stitch でアニメーション・インタラクションは作れるか？——動きのあるUIを試して気づいた現実と可能性

2026.04.14

Google Stitch を使い始めてしばらく経ったとき、ふと気になることがあった。

画面そのものはきれいに作れる。プロンプトひとつでボタンの配置が整い、色もバランスよく決まる。でもそれをクライアントや開発チームに見せると、決まって同じ反応が返ってくる。

「実際に触るとどんな感じになりますか？」

そう、「動き」の話だ。ボタンを押したときのフィードバック、画面が切り替わるときのトランジション、スクロールに連動してヘッダーが縮む、そういった細部の「動き」があるかどうかで、ユーザーがそのUIを「使いやすい」と感じるかどうかは大きく変わる。

では Google Stitch は、その「動き」をどこまで作れるのか。

この記事では、実際に Google Stitch でアニメーションやマイクロインタラクションを設計しようとして試行錯誤した記録を書く。できること、できないこと、そして「できない部分をどう補うか」の実践的なワークフローまで、正直に全部話す。

結論から言うと

Google Stitch は、2026年4月時点で静的UIデザインと画面遷移プロトタイプには対応しているが、ホバーエフェクト・マイクロインタラクション・スクロールアニメーションなどの「動き」設計には対応していない。

一言で言えば、「Stitch は動かないUIを速く作るツール」であり、「動くUI」を作るためには別のツール（Framer・コード）との組み合わせが必要になる。

ただし、それはすぐに諦める理由にはならない。Stitch で作ったベースUIを活用しながら動きを設計する方法は確実に存在するし、Stitch の「プロトタイプ機能」「Voice Canvas」を組み合わせると、思った以上のことはできる。

Google Stitch のアニメーション・インタラクション機能の「現在地」

対応していること——プロトタイプ遷移・クリック操作・音声インタラクション

Google Stitch（2025年5月 Google I/O で発表、Google Labs 提供）とは、テキストプロンプトや画像からUIデザインを自動生成するAIツールのことです。2026年3月の大型アップデート以降、単純な静的UIの生成を超えた機能を持ち始めている。

プロトタイプ遷移（Play ボタン機能）： 2025年12月に追加された Play ボタンを使うと、複数の画面を繋いでクリッカブルなプロトタイプを作れるようになった。ボタンやリンクをクリックしたとき「次にどの画面に遷移するか」を AI が自動的に判断して画面を生成する仕組みで、フローを手動でワイヤリングする必要がない。

実際に使ってみると、ログインボタンを押したらダッシュボードへ、「戻る」を押したらトップに戻る、という基本的な遷移は自然に組みあがった。デザイン開発の初期フェーズで「このフローで伝わるか？」を確認するには十分な精度だ。

Voice Canvas（音声インタラクション）： 2026年3月に追加された Voice Canvas は、マイクに向かって話しかけることで AI エージェントがリアルタイムでキャンバスを編集する機能だ。「もう少しフォントを大きくして」「このボタンをもっと目立つ色に」といった口頭での修正指示が通る。

多画面同時生成： 2026年3月アップデートからは、AIネイティブな無限キャンバス上に複数画面を同時に展開できるようになった。「この5画面のフローを作って」と指示すると、ユーザーフローとして繋がりのある画面群が一気に生成される。

実際にユーザー登録フローの全6画面を一度に生成する指示を出したとき、各ステップの文脈が一貫していて驚いた。手動で画面を繋いでいたときに生じていたズレが自動的に解消されていた。

対応していないこと——ホバーエフェクト・マイクロインタラクション・スクロールアニメーション

一方で、Google Stitch が対応していない「動き」は明確だ。

ホバーエフェクト：マウスを乗せたときにボタンの色が変わる、アンダーラインが出るといった視覚的フィードバック
マイクロインタラクション：フォームに入力したときの即時バリデーション表示、チェックボックスのアニメーション、トグルスイッチの動き
スクロールアニメーション：スクロールに連動して要素がフェードインする、ヘッダーが固定・縮小する
ローディングアニメーション：スピナー・プログレスバーの動き
モーダル・ドロワーのトランジション：表示・非表示時のフェードやスライド
パーティクル・装飾アニメーション：背景の動く要素

これらはすべて「静的なUIデザイン」の範疇を超えており、現時点の Stitch では生成できない。プロンプトで「ボタンを押したときにバウンスアニメーションをつけて」と指示しても、Stitch はそのアニメーションを生成するのではなく、「アニメーション付きボタンのデザイン案」として静止画を返してくるだけだ。

実際に「動き」を試してみた——プロトタイプ機能を使い倒した記録

Play ボタンで画面遷移をつなぐ——思った以上に「伝わる」プロトタイプができた

実際に Play ボタンを使ってプロトタイプを作ってみたとき、最初は「どうせ簡易的なものだろう」と思っていた。ところが、想定以上に使えるものができあがった。

試したのは、フリーミアム SaaS の「無料プランからアップグレードするまでのフロー」だ。

ダッシュボード上部に「制限に達しました」バナーが表示されている画面
バナーをクリックすると料金ページに遷移する画面
プランを選択するとクレジットカード入力フォームが出る画面
入力完了後に「アップグレード完了」の確認画面

この4画面を Stitch で一気に生成し、Play ボタンで繋いだ。結果、開発チームとのレビュー会議でそのまま共有できる水準のクリッカブルプロトタイプが約20分で完成した。

もちろん遷移の「動き」はない。画面がパツっと切り替わるだけだ。ただ、ユーザーフローを確認する目的であれば、それで十分だと気づいた。重要なのは「このボタンを押したら次はこう変わる」というロジックの確認であり、そのためにアニメーションは必ずしも必要ない。

Stitch のプロトタイプ機能が特に役に立つ場面：

ユーザーインタビューや社内レビューでフローを説明するとき
開発チームへの「この画面の次はこうなる」という仕様共有
投資家やクライアントへのコンセプト説明

逆に向いていないのは、「このアニメーションの質感が好みかどうか確認したい」という目的のレビューだ。

Voice Canvas を試した結果——「声でデザインする」感覚は本物

2026年3月のアップデートで加わった Voice Canvas（音声インタラクション機能）は、マイクボタンをオンにして話しかけると AI がリアルタイムでキャンバスを更新する。

実際に試してみた感想を率直に言うと、思ったより正確で、使い続けると「会話しながらデザインする」感覚が自然になる。

日本語での指示も問題なく通った。「ヘッダーの高さをもう少し縮めて」「このカードのシャドウを消して」「フォームのフィールドをもう1つ追加して」といった指示は、タイピングより速く確実に反映された。

ただし Voice Canvas で「このボタンをクリックしたときにリップルアニメーションをつけて」と指示しても、Stitch はデザイン上の見た目を変えるだけでアニメーションコードは生成しない。「動き」に関する指示は、Stitch の外でコーディングするか別ツールで補う必要がある。

「アニメーションなし」の限界を感じた3つの場面

1. ログイン後の演出でつまずいた

SaaS ツールのオンボーディングUIを作っていたとき、「初めてログインした直後に歓迎メッセージがふわっと表示される画面」を設計しようとした。

Stitch は「歓迎メッセージのある画面」は作れる。でもそれは静止画だ。「ふわっと」という要素、つまりフェードインアニメーションは Stitch では表現できない。

結果として、この部分だけ別途 Framer でアニメーションを加えて、クライアントレビューには Framer のプレビューリンクを送る運用にした。Stitch と Framer を行き来する手間が増えたのは事実だが、「Stitch でベースを作ってから Framer に渡す」という流れは意外とスムーズだった。

2. モーダル・ドロワーが「ただ切り替わるだけ」問題

ダッシュボードの設定画面を設計していたとき、「設定パネルが右からスライドインしてくる」という動きを想定していた。Stitch ではモーダルやドロワー自体のデザインは作れるが、それが「どう表示されるか」のアニメーションは作れない。

そのため Stitch のプロトタイプを見たデザインレビュアーから「このドロワー、実装時に動きはつくの？」という質問が来た。仕様書に「スライドイン 0.3s ease-out」と書き添えて説明したが、それは本来 Stitch の画面で表現されていてほしい情報だ。

この体験から、Stitch で作ったデザインには「動きの仕様をコメントとして書き添える」習慣をつけるようになった。

3. ローディング表示が作れない

非同期処理の多い管理画面では、データ取得中の「ローディング状態」のUI設計が重要になる。Stitch はローディングスピナーやスケルトンスクリーンの「見た目」は生成できるが、それが実際に「くるくる回る」「ゆらゆら動く」状態は表現できない。

特にスケルトンスクリーン（コンテンツが読み込まれるまで薄いグレーのプレースホルダーが波打つように動く表現）は、動きがあって初めて意味をなすデザインだ。静止画では「なんか色が薄い画面」にしか見えない。

開発者に「このスケルトンはシマー効果をつけてください」とコメントで補足したが、デザインファイルだけでは意図が伝わりにくい場面だった。

Google Stitch → Framer / コードで動きを補う実践的なワークフロー

Stitch でベースUIを作り、Framer でアニメーションを加える

実際にプロジェクトで試して効果があったのが、「Stitch で構造とビジュアルを固め、Framer でインタラクションを乗せる」というハイブリッドワークフローだ。

手順のイメージ：

Stitch でベースのUIを生成（プロンプト → 画面）
Stitch のコードエクスポート機能でHTMLとCSSを書き出す
書き出したコードを Framer のカスタムコードコンポーネントに貼り付ける
Framer 上でアニメーション・インタラクションを追加する
Framer のプレビューリンクをレビュー共有に使う

このフローのメリットは、Stitch の「ゼロからビジュアルを作る速さ」と Framer の「インタラクション表現力」を両立できる点だ。デメリットは、コードを移行する際に若干の手直しが必要なこと。完全なノーコードでは済まない。

コード出力を活用してCSSアニメーションを追加する

Framer を使わないケースでは、Stitch のコードエクスポートに直接CSSアニメーションを追記する方法が手軽だ。

たとえばボタンのホバーエフェクトであれば、Stitch が出力したCSSに .button { transition: background-color 0.2s ease, transform 0.1s ease; } .button:hover { background-color: #0056d3; transform: translateY(-1px); } のような記述を加えるだけでいい。

Stitch が作ったビジュアルの品質はそのまま活かしながら、動きの部分だけコードで追加する。「デザインの全体品質は Stitch に任せ、動きだけ手で書く」という役割分担は、HTMLとCSSの基礎知識があれば十分に現実的なアプローチだ。

実際にこの方法でランディングページを作ったとき、Stitch でビジュアルを作る部分に30分、CSSアニメーションを追加する部分に15分かかった。フルスクラッチで書くよりも大幅に速い。

それでも Google Stitch で「動き」の設計は進められる

コメント・注釈で動きを「設計書」として記述する方法

Stitch 上で動きを直接表現できなくても、「動きの仕様をデザインの一部として記述する」ことはできる。具体的には、画面の横や要素の近くに注釈テキストを置く形だ。

「このモーダルは右からスライドイン 0.3s ease-out」
「ボタンクリック後 0.5s のローディングスピナーを表示、完了後フェードアウト」
「スクロール量50px以降でヘッダーを固定・高さを64px→48pxに縮小」

こういった記述を画面に添えておくと、開発者への引き継ぎがスムーズになるだけでなく、「自分が作ろうとしているUIに本当にこの動きが必要か？」を設計段階で整理できる効果がある。

実際に使ってみると、アニメーションの仕様を言語化する作業を通じて「この動きは本当にユーザーにとって必要か？過剰ではないか？」と自問する習慣がついた。これは Stitch の限界から逆に生まれた、思わぬ副産物だ。

プロンプトに「〇〇後に表示」と書いて構成を先に固める

アニメーションが絡む画面でも、「動き後の状態」を静的なUIとして先に固める使い方が有効だ。

たとえば「エラーメッセージが表示された後の画面」を Stitch に作らせるとき、プロンプトを「フォーム送信後にエラーメッセージが赤字で入力欄の下に表示されている状態」と書く。Stitch は「エラーが表示されている静的な画面」を生成する。

この画面を「アニメーション後の到達状態」として使い、「この状態に0.2sのフェードインで遷移する」とコメント注釈を付ける。こうすることで、動きのある UI の仕様を「Before → After の静止画 + 動きの説明」という形式でまとめられる。

フルアニメーションを Stitch 単体で作れなくても、「設計の言語化」という観点では十分に使えるツールだと実感している。

FAQ：Google Stitch のアニメーション・インタラクションについてよくある疑問

Q1. Google Stitch で CSSアニメーションのコードを書き出すことはできますか？

Stitch はアニメーション自体のコードは生成しません。HTMLとCSSのエクスポートは可能ですが、書き出されるのはレイアウトと見た目のスタイルのみです。アニメーションは書き出したコードに手動で追加する必要があります。ただし Stitch が生成したコードの品質は比較的クリーンなため、追記作業は難しくありません。

Q2. Google Stitch のプロトタイプ機能はどこまで使えますか？

2025年12月に追加された Play ボタン機能を使うと、複数の画面をクリッカブルにつないだプロトタイプが作れます。「このボタンを押したらこの画面に移動する」という基本フローは問題なく設計できます。ただし遷移時のアニメーションはなく、画面がパツっと切り替わるだけです。ユーザーフローの確認・説明目的には十分ですが、インタラクションの質感を検証したい場合は Framer などと組み合わせる必要があります。

Q3. Framer と Google Stitch を組み合わせることはできますか？

直接的な統合機能はありませんが、Stitch のコードエクスポート機能で書き出したHTMLとCSSを Framer のカスタムコードコンポーネントとして取り込む方法が実践的です。「Stitch でビジュアルを作り、Framer でインタラクションを加える」というハイブリッドワークフローは実際にプロジェクトで活用できます。

Q4. Google Stitch は今後アニメーション機能を追加する予定はありますか？

Google の公式発表（2026年4月時点）では、アニメーション機能のロードマップは明らかにされていません。2026年3月の大型アップデートでは無限キャンバス・Voice Canvas・MCP統合などが追加されましたが、アニメーション生成は含まれませんでした。Google Stitch は「UIの静的デザインとプロトタイプ」に特化する方向性を維持しているように見えます。

Q5. Google Stitch でマイクロインタラクションのアイデアを考えるために使えますか？

直接「動き」を作ることはできませんが、「Before/After の状態を素早くビジュアル化する」ツールとしては有効です。「入力エラー発生時の画面」「ローディング完了後の画面」など、動きの各フレームを静止画として高速に生成できます。アニメーションのコンテを作る感覚で Stitch を使い、詳細はコードで補うアプローチが現実的です。

Q6. Google Stitch を使うためにデザイン経験や技術的な知識は必要ですか？

基本的なUIデザインの知識があれば十分に使えます。プロンプトを日本語で書くだけで画面が生成されるため、デザインツール未経験の方でも操作は簡単です。ただし、アニメーションを追加するためにコードを扱う場面ではHTMLとCSSの基礎知識があると作業が大幅にスムーズになります。

Q7. Google Stitch の利用料金はいくらですか？

2026年4月時点で Google Stitch は完全無料で利用できます（Google Labs 提供）。将来的な有料化については Google の公式アナウンスを確認することをお勧めします。Google アカウントがあればすぐに使い始められます。

注意点・失敗しやすいポイント

1. 「アニメーションなし」と「インタラクションなし」は違う

Stitch のプロトタイプ機能（Play ボタン）は「画面遷移のインタラクション」は提供している。「アニメーションがない＝インタラクションが全くない」という誤解から、プロトタイプ機能を使わず静止画だけをクライアントに送ってしまうのは損だ。まずプロトタイプ機能を使ってフロー確認できる状態を作ることを習慣にしよう。

2. Framer 連携を前提にすると作業見積もりが変わる

「Stitch で作ってすぐ実装できる」と思って受けた仕事で、「アニメーションも必要」とあとから発覚することがある。Framer や直接コーディングでの追加作業が発生すると、制作時間は1.5〜2倍になると見積もっておいた方が安全だ。プロジェクト開始前にアニメーションが必要かどうかを確認する習慣をつけたい。

3. コードエクスポートした後に構造が崩れることがある

Stitch のコードエクスポートは高品質だが、複雑なレイアウト（段組みが多いダッシュボードなど）では書き出し後にCSSが崩れることがある。Framer や本番コードに移行する際は、一度ブラウザで表示確認してから作業を進めることを強くお勧めする。

4. Voice Canvas でアニメーションを指示できるという誤解

Voice Canvas は非常に便利だが、「ボタンにアニメーションをつけて」と音声で話しかけても、Stitch はデザインの見た目だけを変えてアニメーションコードは生成しない。音声入力でできることのスコープはテキストプロンプトと同じであることを理解しておこう。

5. アニメーション仕様のコメントを「あとで書こう」と先延ばしにしない

Stitch で画面を作った直後がいちばん「この動きはこうしたい」というイメージが鮮明な瞬間だ。あとで仕様コメントを書こうとすると、意図が薄れてしまう。画面生成直後にすぐ動きの仕様を注釈で書き残す習慣をつけると、開発引き継ぎのクオリティが大幅に上がる。

まとめ：Google Stitch の「動けないこと」を知った上で使いこなす

Google Stitch でアニメーションを試してわかったのは、「できないこと」を把握することが、ツールを正しく使うための第一歩だ、ということだった。

Stitch は「動かないUIを驚くほど速く作れるツール」だ。それ以上でも、それ以下でもない。アニメーションやマイクロインタラクションを期待してツールを開くと、必ず失望する。でも「ビジュアルとフローの設計を爆速で終わらせ、動きの実装は別のレイヤーでやる」という設計に切り替えると、Stitch の価値は一気に高まる。

Stitch が得意なこと：