初めて Google Stitch で作った画面をクライアントに見せた日のことは、今でもよく覚えている。
あれは新規事業のプロジェクトで、サービスの方向性がほぼ決まりかけたタイミングだった。「アプリのイメージを早めに共有したい」というクライアントの要望があって、私はデザイン担当として「じゃあ、まず粗いモックアップで雰囲気を見てもらいましょう」と提案した。
いつもならFigmaでワイヤーフレームを作り、それをもとに説明するところだ。でも、そのとき私の手元には Google Stitch があった。前週から使い始めたばかりのツールで、プロンプトを入力するとAIが画面を生成してくれる——そのスピードと完成度に正直驚いていたところだった。
「これをプレゼンに使ってみよう」。そう決めたのは、会議の3時間前だった。
準備をしながら、心の中では葛藤があった。「これはデザイナーとして誠実な選択なのか」「クライアントは『AIが作った画面』をどう受け取るだろうか」「もし期待以上の完成度に見えてしまったら、後で大変なことにならないか」。そういう不安が頭をぐるぐると回っていた。
それでも「やってみないとわからない」という気持ちが勝った。
結果として、あの日のプレゼンは私の働き方を変えた。それはうまくいったからではなく、「予想していなかった問題が起きて、それに対処する方法を学んだ」からだ。この記事では、その体験をできる限り正直に書く。同じようにStitchをプレゼンに使おうと思っている人、あるいは「AI生成UIをどう活かすか」を考えている人に、何か参考になれば嬉しい。
結論から言うと、Google Stitch のUIをクライアントに見せることは「使える」が、「何をどう見せるか」の準備が通常のプレゼン以上に重要だった。AIが生成したビジュアルの完成度が高いぶん、「これが最終デザインですか？」という誤解も生まれやすく、見せ方の文脈設計が欠かせない。この記事では、実際に経験したことをもとに、StitchをUIプレゼンに活かすための考え方を整理する。
Google Stitch とは何か、改めて整理する
Google Stitch（以下、Stitch）とは、テキストのプロンプトや音声入力をもとに、AIがアプリケーションのUIデザインを自動生成するGoogleのデザインツールです。stitch.withgoogle.comで無料で利用でき、Googleアカウントさえあれば今日から使い始められる。
使い方はシンプルで、「〇〇というサービスの〇〇画面を作って」とプロンプトを入力すると、数秒から十数秒でUIが生成される。生成されたデザインは、そのままブラウザ上で確認でき、「再生成」「部分修正」「テキスト変更」などの操作も可能だ。
実際に使ってみて感じるのは、生成されるUIの「それっぽさ」の高さだ。Figmaで1時間かけて作るようなクオリティのワイヤーフレームが、数秒で生成される感覚がある。当然、細部の作り込みや会社固有のブランドカラー反映などは追加の操作が必要だが、「ラフな方向感を共有する」という目的には十分すぎるほどだ。
AIがUIを生成するまでの流れ
Stitchの基本的な使い方の流れを整理すると、以下のようになる。
最初にキャンバスを開き、テキストボックスにプロンプトを入力する。プロンプトは「フードデリバリーアプリのホーム画面を作って」のように短くても機能するが、「30代の共働き夫婦が週3回の夕食注文に使うフードデリバリーアプリ。シンプルで操作ステップが少ないことを最優先に設計して」と詳しく書いた方が、意図に近いUIが生成される傾向がある。
生成が完了すると、キャンバス上にUIが表示される。この時点で「気に入らない」と感じた箇所は、追加のプロンプトで修正できる。「このナビゲーションバーをもっとシンプルにして」「ボタンの色をもう少しビビッドに」「このリストをカード形式に変えて」といった指示を追加することで、インタラクティブにデザインを改善できる。
最終的にHTMLコードとして出力したり、スクリーンショットとして保存したり、Google AI Studioに引き継いでコード化したりと、複数の出口がある。
2026年3月のStitch 2.0で何が変わったか
2026年3月19日にリリースされたStitch 2.0では、いくつかの重要な機能が追加された。特にプレゼン用途で関係が深いのは以下の3点だ。
まず「5画面同時生成」。以前は1画面ずつ生成していたが、Stitch 2.0からはサービスの一連のフローを説明するプロンプトを入力すると、5つの繋がった画面を一度に生成できる。「登録からホーム画面まで」「検索から詳細画面まで」といった流れをまとめて見せられるようになり、クライアントへのサービス体験の提示が格段にやりやすくなった。これは特にサービスの「流れ」を説明したい場面——新規事業のプレゼンや、ユーザーストーリーの共有——で強力な機能だ。
次に「Design System Import」。既存のブランドカラーやフォント定義を読み込ませることで、生成されるUIにブランドの色味を乗せられる。クライアントが既にブランドガイドラインを持っている場合、これを使うことで「うちのサービスらしい」画面を素早く作れるようになった。色の違いだけでも、「自分たちのもの」という感覚をクライアントに与える効果がある。
そして「Voice Canvas」。キャンバス上でAIに話しかけながらUIを作れる機能で、クライアント同席のもとでリアルタイムに「じゃあここのボタンの色を変えて」「この画面にカート機能を追加して」という修正ができる。AIがその場でデザインを変えていく様子をクライアントが目の当たりにする体験は、これまでのプレゼンにはなかった新しいコミュニケーションの形だと感じている。
クライアントプレゼンに使ってみようと思った理由
「早い・安い・そこそこよく見える」の魅力
私がStitchをプレゼンに使おうと思った理由は、正直に言えば「時間がなかった」からだ。
打ち合わせまでの3時間、Figmaで一から作っても間に合わない。でも「何もない状態でイメージを共有してください」という場に臨むのは心許ない。そのタイミングで「Stitchがある」と気づいた。
Stitchならプロンプトを10分書いて、5画面を生成して、スクリーンショットを並べる——それだけでプレゼン素材が揃う。実際、その日は2時間半で「サービスの主要5画面の方向感」を示せるスライドを作った。Figmaで同じものを作ろうとしたら、最低でも半日かかったはずだ。
しかし、単純に「速いから使う」というだけでなく、「Stitchが生成するUIの品質が、ワイヤーフレームより一段上にある」という点も見逃せない。白黒の構造図を見て「なるほど、こういうアプリですね」と理解できる人はプロだけだ。多くのクライアントにとって、ワイヤーフレームは「最終的にどうなるかよくわからないもの」として映る。一方でStitchが生成するUIは、色がつき、テキストが入り、実際に動くアプリに近い見た目をしている。それだけで「具体的なイメージの共有」という目的をはるかに達成しやすくなる。
準備をしながら、一つの懸念が頭をよぎっていた。「AIが作った画面だと気づかれたとき、クライアントはどう受け取るだろう？」
準備にかけた時間と実際にやったこと
プレゼン準備でやったことは以下の通りだ。
まず、サービスの要件をもとにプロンプトを書いた。単に「フードデリバリーアプリのトップ画面を作って」とだけ書くのではなく、「30代の共働き夫婦が使う、週3回の夕食注文に特化したアプリ。シンプルで操作が少ないことを最優先。余計な情報は出さない、必要なものだけ表示する」という形で、ターゲットやニーズ・優先順位まで含めたプロンプトにした。この一手間が、生成されるUIの方向性を大きく変える。
生成されたUIを確認し、気になる箇所を修正プロンプトで調整した。「このナビゲーションバーはもっとシンプルに」「カラーをもう少しウォームトーンに」「リスト形式をカード形式に変えて」などの指示で、3〜4回のやり取りで納得できる画面ができた。
最後に、生成したUIに「このデザインはAIが生成したラフ案です。方向性の確認が目的です」というキャプションを明示的に加えた。これは後から振り返ると、非常に重要な判断だった。
また、画面のUIに含まれるテキスト（ボタンラベル・メニュー名・説明文）を日本語に整えた。Stitchが英語混じりのテキストを生成することがあり、そのままクライアントに見せると「あれ、これ英語なんですね」という余計な疑問が生まれる。テキストの日本語化は地味だが、プレゼンの品質を上げる重要な作業だ。
プレゼン当日——起きたこと、感じたこと
クライアントが最初に言った言葉
プレゼン会場に入り、スライドを開いて最初の画面を見せたとき、クライアントの担当者（40代・事業開発担当）がこう言った。
「あ、もうここまでできてるんですか。思ったよりずっと具体的ですね」
私は「AIが生成したラフ案なのでまだ粗い部分はありますが」と前置きしたうえで説明を始めた。しかしクライアントの視線はスライドに釘付けになっていた。
その後の会議で何が起きたか——想定していたのは「方向性のすり合わせ」だったが、実際に起きたのは「具体的な改善提案の応酬」だった。「このボタンはここじゃなくて上に置いたほうがいい」「このリストは横スクロールにできない?」「色がちょっと派手すぎるかも」「ここのフォントはもう少し大きくしてほしい」——次々と具体的なフィードバックが出てきた。
通常、ワイヤーフレームの段階では「だいたいこんなイメージです」という抽象的な確認にとどまることが多い。ところがStitchが生成したUIは見た目の完成度が高かったため、クライアントは「具体的に使える画面」として受け取ってしまった。
想定より会議が盛り上がった側面もあり、それはそれで良いことだった。ただ同時に、「この話は今日するべき話か？」と内心焦る場面もあった。フォントのサイズやボタンの配置は、今日決めることではなかった。
予想外だった反応の正体
会議後に振り返って気づいたのは、「ビジュアルの完成度がクライアントの認知フレームを変えてしまった」ということだ。
ワイヤーフレームは「設計図」として認識される。だから「この構造でいいですか?」という問いに自然と答えてもらえる。
一方、StitchのUIは「デザイン案」として認識される。だから「このデザインでいいですか?」という問いに、より具体的・感情的に反応が返ってくる。
これは悪いことではない。むしろ「早い段階で具体的なフィードバックを得られた」という意味では、プロセスの効率化になっていた。ただし、「ここはまだ決まっていない部分」「ここはラフで後で変えます」という区別をプレゼン側が明確にしておかないと、会議が「デザインレビュー」になってしまう。
実際、私のプレゼンでは途中から「細かいデザインの話」になりかけた場面があった。「このフォントが気になる」という話が出たとき、私は「今日はレイアウトと機能の流れを確認させてください。デザインの細部は次のフェーズで」と場をリセットした。これが必要なスキルだと実感した。
「Stitchを使うと、会議のコントロールが難しくなる」——これが最初のプレゼンから得た、正直な気づきだった。
Stitch を UIプレゼンに使うときのポイント
「AIが作った画面です」と言うべきか
これは正直に言うべきだ、というのが私の結論だ。
理由は二つある。一つは誠実さの問題。クライアントとの信頼関係において、制作物の出所を隠すのは長期的にリスクになる。万が一「実はこれAIが作ったんですよね?」と後からわかった場合、信頼を損なう可能性がある。
もう一つは、むしろ「AIで作った」と言ったほうがクライアントの反応が良い場合があるからだ。「AIで5分で作ったラフ案です」という前置きがあると、クライアントは「粗さを受け入れた上で見る」モードになる。結果として、「ここが気になる」「ここは変えてほしい」という建設的な意見が出やすくなる。
実際に複数のプレゼンで試してみた印象では、「AIが作ったラフ案です」と言ったクライアントのほうが、「ちょっとこれ変えられそう?」という感覚でフィードバックをくれることが多かった。一方で、そう言わずに見せると「これがベースになるデザインですか?」という認識で会議が進み、後で「あ、これまだラフなんですね」という場面が生まれた。
Stitchが生成するUIの「それっぽさ」が、クライアントとのコミュニケーションの質を上げるということだ。白黒のワイヤーフレームより、カラーが入ったUIのほうが「自分たちのサービスのイメージ」として受け取ってもらいやすく、「自分ごと化」されたフィードバックが返ってきやすい。ただしその前提として、「これはあくまでラフである」という文脈設定が不可欠だ。
クライアントに刺さるプレゼンの準備方法
Stitchを使ったUIプレゼンで効果的だったのは、「画面の流れ」を意識したプロンプト設計だ。
単一の画面を見せるより、「登録画面→ホーム画面→商品詳細画面→カート→購入完了」という一連の流れを5画面で見せると、クライアントがサービスの体験を「物語として」理解しやすくなる。Stitch 2.0の5画面同時生成はまさにこの用途に最適で、「一つのサービスとして一貫性のある流れ」を提示できる。
また、プレゼン前に「何を決める会議か」を明確にしておくことが重要だ。以下の3点をスライド冒頭に入れておくと、会議の方向性がぶれにくくなる。
- 「今日は情報構造（何をどこに置くか）を確認します」
- 「デザインの細部（色・フォント・アイコン）は今日は対象外です」
- 「このUIはAIが生成したコミュニケーション用のラフ案です」
この事前設定がないと、ビジュアルの完成度に引っ張られて「デザインレビュー」になりやすい。
さらに、Voice Canvasを活用したライブ修正も有効だった。「じゃあこのボタンを大きくしてみましょう」とプレゼン中にリアルタイムでStitchを操作し、クライアントの目の前でUIが変わる様子を見せると、「AIってこういうことができるのか」という驚きと、「このツールを使えば修正も早そうだ」という安心感が同時に生まれた。クライアントがプロセスに「参加している感覚」を持ってもらえるのも、この方法の強みだ。
プレゼン後に「次のステップ」を明確にすることも大切だ。「今日いただいたフィードバックをもとに、来週までにFigmaで詳細設計を進めます」という宣言を会議の最後に行うことで、「Stitchのラフ案」から「Figmaの本格設計」へのフェーズ移行がスムーズになる。StitchとFigmaを段階的に使い分けることで、全体のデザインプロセスが効率化できる。
失敗したこと・気をつけるべきこと
Stitchをクライアントプレゼンに使った経験から、気をつけるべき点を5つ挙げる。
1. 「完成品」として受け取られるリスクへの対処が不十分だった
最初のプレゼンで、「ラフ案です」と口頭で言いながらも、スライドのビジュアル上はしっかりした画面が並んでいた。その結果、クライアントが「ほぼ完成品」として認識してしまい、「もうデザインが固まっているなら実装もすぐでは?」という誤解が生まれかけた。その後は「ラフ案である旨」を画像の上に半透明テキストで重ねるか、スライドのキャプションに大きく「AIラフ案（未確定）」と明記するようにした。
2. ブランドと乖離したビジュアルを補正しないまま見せてしまった
最初のプレゼンでは、クライアントのブランドカラーをStitchに読み込ませずに生成したため、「うちのサービスっぽくない」という感想が出た。Stitch 2.0からはDesign System Importができるので、最低限のカラー情報は事前にインポートしておくべきだった。ブランドカラーを1〜2色でも設定するだけで、クライアントの「自分たちのもの感」が大きく変わる。
3. 画面の「繋がり」を説明する準備が足りなかった
5画面を一度に見せたとき、クライアントが「この画面からこの画面にどうやって遷移するの?」という疑問を持ったが、私はフロー図を用意していなかった。Stitchの画面と合わせて、簡単な遷移図（どの画面からどの画面に行くか）を1枚用意しておくことで、体験の流れが格段に伝わりやすくなる。矢印を書いただけの簡単なものでも十分だ。
4. 会議がデザインレビューに脱線した
前述の通り、ビジュアル完成度が高いために「デザインの細部」の話に流れた場面があった。「今日はここまでを決める」という議題の境界線を、スライドに明示するか、冒頭にアジェンダとして口頭確認するかのどちらかを必ずやるべきだった。「今日決めること・決めないこと」リストをスライドに入れるのが、最もシンプルで効果的な対策だ。
5. AIが生成したテキストをそのまま使った
Stitchが生成したUI内のテキスト（ボタンラベル、見出し、説明文など）は、英語混じりだったり、サービスの実際のコンセプトとズレた表現になっていたりすることがある。プレゼン前に必ず「テキストの日本語化・サービス内容への適合」の確認を行い、誤解を招く表現を修正しておく必要がある。特にCTAボタン（「今すぐ始める」「購入する」など）のラベルは、サービスの実態に合わせた表現に直しておくだけで、クライアントの「自分ごと化」度が上がる。
よくある質問（FAQ）
Q1. Google Stitch で作ったUIをクライアントに見せることに問題はありますか？
問題はありません。Stitchはあくまで「デザインのラフ案生成ツール」であり、生成した画面はプレゼン・コミュニケーション用の素材として自由に使えます。ただし、「AIが生成したラフ案である」ことをクライアントに事前に伝えることで、誤解を防ぎ信頼関係を保てます。著作権・商標の観点からも、Stitchが生成する画面に既存ブランドのロゴ等を無断で含めないよう注意が必要です。
Q2. Stitch の画面は「本格的なデザイン」として使えますか？
ディスカバリー段階（方向性確認）やプロトタイプのデモとしては十分な品質があります。ただし、最終納品物としての本格デザインには向きません。FigmaやAdobeXDなど専門のデザインツールでの作り込みが必要です。StitchはあくまでFigmaへの橋渡しとして使うか、「エンジニアへの参考渡し」用途に留めると健全です。「Stitchで方向感を決め、Figmaで詳細を詰める」という2段階のフローが実務では現実的です。
Q3. プレゼン中にリアルタイムでStitchを操作しても大丈夫ですか？
Voice Canvasを使ったライブ修正は、うまく機能すれば非常にインパクトがあります。ただし、インターネット接続が必須で、プロンプトによっては意図しない生成がされることがあります。重要なプレゼンではライブ操作をメインにせず、「軽いデモとして見せる」位置づけにするのが安全です。事前に何度か練習しておき、「こういう指示を入れるとこう変わる」というパターンを把握しておくと本番で落ち着いて操作できます。
Q4. Stitch 2.0 の「Design System Import」は何を取り込めますか？
カラーパレット（HEX値）、タイポグラフィスタイル（フォントファミリー・サイズ・ウェイト）、スペーシングシステムが主な対応項目です。クライアントのブランドガイドラインがある場合は、カラーコードとフォント名を確認してから使うと、生成結果がブランドに近づきます。コンポーネントレベルの取り込みはまだ限定的で、既存のFigmaコンポーネントライブラリを完全に読み込ませることはできません。まずはブランドカラーのHEX値だけでも設定するだけで効果があります。
Q5. クライアントが非技術者でも、Stitch のUIを理解してもらえますか？
はい。むしろ非技術者の方が、ワイヤーフレームよりStitchのUIの方が理解しやすいケースが多いです。白黒の設計図より、色とテキストが入った画面の方が「自分たちのサービスのイメージ」として想像しやすいからです。一方で、「これが最終デザインではない」ことの説明はより丁寧に行う必要があります。非技術者クライアントには特に「今日はイメージの確認です。デザインの細部はこれから詰めます」という言葉を最初に明確に言うことが効果的です。
Q6. Stitch で生成したUIを Figma にインポートできますか？
直接的なFigmaインポート機能は現状ありません。Stitchから出力できるのは主にHTMLコードと画像ファイルです。実務では、StitchのスクリーンショットをFigmaに貼り付けてトレースする方法か、HTMLコードをFigmaのプラグインで取り込む方法が使われています。Google AI StudioへのエクスポートはStitch 2.0から公式サポートされており、デザインからコードへの橋渡しにはこちらが現状最もスムーズです。
Q7. Stitch を使ったプレゼンはどんな場面に向いていますか？
最も向いているのは「アイデアの方向性を確認する初期ミーティング」です。予算・スケジュールが確定する前のディスカバリーフェーズで、複数のUIの方向性を素早く生成・比較できます。また「プロジェクトが止まっているとき、具体的なビジュアルで議論を再起動したい」場面にも有効です。逆に、デザインの最終承認や品質担保が必要な場面では、Stitch単独ではなくFigmaとの併用が必要です。社内の提案書作成や、投資家へのピッチデッキにUIのイメージを入れる用途にも使えます。
Q8. Stitch はどこで使えますか？料金はかかりますか？
stitch.withgoogle.comからアクセスでき、2026年4月現在は無料で利用できます。Googleアカウントがあればすぐに使い始められます。ただし、Googleのプレビューサービスとして提供されているため、将来的に有料化や機能制限が入る可能性があります。Google Labsの提供ツールとして、利用規約の確認も推奨します。現在は商用利用についての制限は特になく、業務でのUIプレゼン用途での使用に問題はありません。
まとめ
クライアントに Google Stitch で作った画面を見せた体験は、「デザインツール」と「コミュニケーションツール」の境界線について、改めて考えさせてくれるものだった。
Stitchが生成するUIは、ワイヤーフレームと最終デザインの「あいだ」に位置している。白黒の構造図ほど抽象的でなく、Figmaで作り込んだデザインほど精緻でもない。その中間の温度感が、クライアントとのコミュニケーションにおいて独自の価値を持つことがわかった。
ただし「ビジュアルが具体的すぎる」という特性は、使い方を誤ると「会議がデザインレビューになる」「最終デザインと誤解される」「フェーズ感がずれる」といった問題を引き起こす。Stitchをプレゼンに使うということは、ツールの操作だけでなく「見せ方の文脈設計」も含めてセットで考える必要がある。
この記事でお伝えしたポイントをまとめると以下の通りだ。
- AIが生成したラフ案であることを正直に伝えることで、フィードバックの質が上がる
- ビジュアル完成度が高いぶん「今日は何を決める会議か」の境界線設定が通常より重要
- Voice Canvasを使ったリアルタイム修正は、クライアントの参加感を高める
- Design System ImportでブランドカラーをStitchに読み込ませると「自分たちのもの感」が出る
- プレゼン後に「次はFigmaで詳細設計」という段階移行を明示することで、ステップが混乱しない
- UIのテキストは日本語化・サービス内容に合わせた修正を行ってから見せる
デザイナーやPMとして「クライアントとのコミュニケーションを速く、具体的にしたい」と思っている人には、Stitchをプレゼン準備に取り入れることを強くすすめる。私自身、あの日以来ほぼすべての初回プレゼンにStitchを使うようになっている。
「AIが作ったものだから本物じゃない」ではなく、「AIが作ったからこそ、早くて具体的な対話ができる」——そう考え方が変わったことが、この体験の一番の収穫だったかもしれない。Stitchは単なる「UIを作るツール」ではなく、「クライアントと早く本音を話すためのツール」として、私の仕事の中に定着している。
