以前は、クライアントへの提案資料をパワーポイントで作っていた。
デザインのイメージを伝えるために、スクリーンショットを貼り付けたり、参考サイトのURLをスライドに並べたりしていた。「こんな雰囲気で作りたいと思っています」という説明を添えて、それで伝わることを期待していた。
でも正直、それで伝わることはあまりなかった。
「なんとなくわかった」という顔でうなずかれて、いざ制作が進んだ段階で「あ、こういうことじゃなかった」という修正が飛んでくる。このサイクルをどれだけ繰り返しただろうか。
Google Stitch でプロトタイプを作り、それをクライアントに直接見せるようになってから、その状況が変わった。承認がスムーズになっただけでなく、「なぜ変わったのか」を自分なりに言語化できるようになった。その話を、今日は書く。
結論から言うと
Google Stitch のプロトタイプをクライアントに見せることで変わったのは、「クライアントが意見を言えるようになった」ことだ。スクリーンショットや言葉では「なんとなく」で済ませていたことが、実際に操作できる画面を前にすると「ここがちょっと違う」と具体的になる。具体的な意見が早い段階で出てくるほど、後の修正コストは下がる。
変わる前——「言葉とスライドで伝える提案」の限界
「わかりました」は「わかった」ではなかった
参考サイトを3つ並べて「このサイトのA要素と、このサイトのB要素と、このサイトのC要素を組み合わせたイメージです」と説明するとき、自分の頭の中には鮮明なビジョンがある。でもクライアントの頭の中で何が組み合わさっているかは、確認する術がない。
「イメージ、伝わりましたか？」と聞けば、多くのクライアントは「はい」と答える。でもそれは「あなたの説明は聞こえました」という意味であって、「私もあなたと同じ画を思い描いています」という意味ではない。
この「わかりました≠わかった」のギャップが、後工程での修正の温床だったとあとから気づいた。
修正が「後半」に集中していた
以前の提案スタイルでは、修正のピークが制作の後半に来ていた。デザインカンプが完成したとき、コーディングが8割終わったとき——そのタイミングで初めて「思っていたのと違う」という反応が出てくる。
後半の修正は高コストだ。作り直しの時間だけでなく、スケジュールのズレ、チームのモチベーション低下、クライアントとの信頼関係のダメージまで含まれる。
変わった後——Google Stitch のプロトタイプを持ち込む提案スタイル
提案前日に Stitch で作る30分
提案の前日、私は Google Stitch を開く。クライアントの事業内容と要件をもとに、3〜5画面のプロトタイプを作る。完璧なデザインである必要はない。「こういう構造で考えています」という方向性が伝わる水準で十分だ。
かつては「プロトタイプを作るには数日かかる」という感覚があった。でも Stitch を使い始めてから、「提案用のプロトタイプ」に必要な時間は30分〜1時間になった。Stitch の速さがあってこそ成り立つ提案スタイルだ。
実際に試したのは、中規模ECサイトのリニューアル提案だった。「トップページ」「商品一覧ページ」「商品詳細ページ」「カートページ」の4画面を Stitch で生成し、Play ボタンで繋いでクリッカブルにした。プロンプトには「参考サイトのスクリーンショットを取り込んで」という形で既存サイトのイメージも反映させた。
提案当日、パワーポイントの代わりにそのプロトタイプを開いた。
クライアントの反応が変わった
プロトタイプを見せたとき、クライアントの最初の一言は「あ、触れるんですか？」だった。
画面を操作してもらうと、5分も経たないうちに「このボタン、もう少し目立つといいですね」「この商品の並び方、縦より横の方がうれしいかも」「カートページでもう一度この情報を見せてほしい」という具体的な意見が次々と出てきた。
これは革命的な変化だった。言葉では「わかりました」で終わっていた話が、プロトタイプを前にすると「ここは違う」「ここはいい」に変わる。クライアントが自分で触ることで、自分の意見を「発見」するのだ。
その場で出た意見を Stitch に反映して修正した画面を見せると、「そうそう、これです」という反応が即座に返ってくる。提案1回で方向性を合意できた。
提案でのプロトタイプ活用——私が気をつけていること
「これは最終デザインではありません」を必ず伝える
プロトタイプを見せるとき、最初に「これは方向性確認のための初期案です。色・フォント・細部は今後調整します」と必ず口頭で伝える。
これを言わないと、クライアントによっては「もうここまで作ってくれているなら、これで進めましょう」と言ってしまい、後から本格デザインの工数が取れなくなるケースがある。Stitch の生成速度は速い。でもそれはあくまでプロトタイプの速さだ。
「これは方向性を合わせるための試作品」という位置づけを明確にすることで、プロトタイプが「最終物と誤解される」リスクを防いでいる。
プロトタイプは「質問を引き出す道具」として使う
プロトタイプの主目的は「完成形を見せること」ではなく、「クライアントの頭の中にあるイメージを引き出すこと」だと考えている。
実際、プロトタイプに対してクライアントが「これは違う」と言ってくれる方が、「なんとなくわかりました」より価値がある。「違う」という反応の中に、本当の要件が隠れているからだ。
だから私は、提案の場でプロトタイプを見せながら意図的に質問する。「このナビゲーション構成で御社のお客様は目的のページに辿り着けると思いますか？」「このトップページを見て、御社の強みは伝わっていると感じますか？」といった問いかけだ。
プロトタイプが「問いへの答えを引き出す触媒」として機能したとき、提案の質は格段に上がる。
提案後に「修正バージョン」を翌日送る
提案の場でフィードバックをもらったら、その日のうちまたは翌日に Stitch で修正バージョンを作ってクライアントに送る。
「先日の提案でいただいたご意見を反映した修正版です」と一言添えて、更新したプロトタイプのリンクを送る。クライアントは「ちゃんと聞いてくれていた」という信頼感を持ち、次のアクションへの同意が得やすくなる。
この「フィードバック → 翌日修正版送付」のサイクルを Stitch の速さがあってこそ回せている。
Google Stitch のプロトタイプ共有機能
Play モードのリンク共有
Stitch の Play ボタンで作ったクリッカブルプロトタイプは、URLで共有できる。クライアントに「このリンクを開いてみてください」と送れば、Stitch のアカウントがなくてもプロトタイプを閲覧・操作できる（閲覧のみ）。
画面共有が難しい状況（クライアントが海外にいる、非同期でのフィードバックを求める場合など）でも、リンク1本で同じプロトタイプを確認してもらえる。
スクリーンショットとリンクの使い分け
メールでの非同期フィードバックには「スクリーンショット + 説明テキスト」が伝わりやすい場合もある。プロトタイプリンクは「触ってフローを確認してほしい」場面で、スクリーンショットは「この画面のこの部分について意見がほしい」場面で使い分けている。
FAQ
Q1. Google Stitch で作ったプロトタイプをクライアントと共有する方法は？
Stitch の Play ボタンで作ったプロトタイプは、URLリンクで共有できます。リンクを受け取ったクライアントは Stitch のアカウントなしでプロトタイプを閲覧・操作できます。ミーティングでの画面共有、メールでのリンク送付、Slack等のチャットツールへの貼り付けなど、様々な場面で活用できます。
Q2. プロトタイプの共有リンクに有効期限はありますか？
2026年4月時点の Google Stitch のリンク共有には特定の有効期限は設けられていませんが、Google Labs のサービスとして仕様が変更される可能性があります。重要な提案時は最新の仕様を公式サイト（stitch.withgoogle.com）で確認することをお勧めします。
Q3. クライアントがプロトタイプにコメントを付けることはできますか？
2026年4月時点では、共有リンクからのコメント機能は Stitch に備わっていません。フィードバックを収集するには、Stitch のプロトタイプを見ながらビデオ通話でメモを取る、Loom等の画面録画ツールで操作記録を送ってもらう、フィードバックフォームを別途用意するといった方法が現実的です。
Q4. デザインが得意でないクライアントでも Stitch のプロトタイプは理解できますか？
はい、むしろデザインに慣れていないクライアントほど効果的です。Figma のデザインカンプを見せると「デザイナーが見るもの」という印象から「正直な感想を言いにくい」という心理が働くことがあります。一方、クリッカブルなプロトタイプは「使ってみた感想」として自然にフィードバックしやすいです。「専門的な知識がなくていい」という安心感が、率直な意見を引き出します。
Q5. 提案段階で Stitch のプロトタイプを作ることをクライアントに知らせるべきですか？
伝えておく方がトラブルを防げます。「AI を使ったプロトタイプ生成ツールを使って初期案を作っています」と事前に共有することで、クライアントが「この人はどうやってこんなに速く作ったのか」という疑問を持つリスクを防げます。また、「AIツールを積極的に活用してコスト・時間の効率化を図っている」という姿勢は、多くのクライアントにポジティブに受け取られる傾向があります。
Q6. Stitch のプロトタイプを見せた後、Figma でのデザイン工程は省けますか？
省くかどうかはプロジェクトの規模と要件次第です。小規模なランディングページや内部ツールなら、Stitch のプロトタイプ → コードエクスポート → 実装という流れでFigmaを省くケースも現実的です。一方、本格的なサービスのUIデザインでは、コンポーネントの体系化・デザインシステムの構築・チームでの共同編集のために Figma を使う方が効率的です。Stitch で方向性を決め、Figma で詳細を詰める「ハイブリッドフロー」が現時点では最もバランスが良いと感じています。
注意点・失敗しやすいポイント
1. プロトタイプの完成度が高すぎると修正依頼が増える
提案段階のプロトタイプが「完成品に近い」見た目になっていると、クライアントは細部の修正（フォントサイズ・色・余白）に注目し始める。提案段階では構造・ナビゲーション・情報の順番といった「大きな方向性」に集中してもらうため、あえてビジュアルの完成度を落とした「ワイヤーフレームに近い」プロトタイプを提示することも有効だ。
2. プロトタイプを見せる前の「準備時間」を確保する
Stitch でプロトタイプを作るのが速くなっても、「クライアントに何を確認したいか」という設計は事前に考える必要がある。「とりあえず見せれば何か言ってもらえる」という期待だけでミーティングに臨むと、フィードバックが散漫になって収穫が少なくなる。提案の目的（今日この場で何を合意したいか）を明確にしてからプロトタイプを準備することをお勧めする。
3. リモートでのプロトタイプ共有は「操作案内」をセットで送る
リンクを送るだけでは、ITリテラシーが高くないクライアントがプロトタイプをうまく操作できないことがある。「リンクを開いて、右下の再生ボタンを押すと操作できます。〇〇のボタンを押してみてください」という短い操作案内をセットで送ることで、スムーズにフィードバックを得やすくなる。
まとめ
Google Stitch のプロトタイプをクライアントに見せるようになってから変わったのは、「伝える方法」だけではなかった。クライアントとの対話の質が変わり、合意の速度が変わり、後工程の修正が減った。
プロトタイプが「クライアントの頭の中にあるイメージを引き出す道具」になることで、提案は「説明する場」から「一緒に決める場」に変わった。
Stitch の速さは、「作るコスト」を下げた。でもそれ以上に価値があったのは、「早い段階で試せるようになった」ことだ。試して、見せて、フィードバックをもらって、また試す。このサイクルを提案段階から回せることが、Stitch を使い始めてから一番大きな変化だったと感じている。
まだスライドだけで提案しているなら、次の提案に Stitch のプロトタイプを1つ持ち込んでみてほしい。クライアントの反応が変わるはずだ。
