Google Stitch を好意的に紹介する記事は多い。私もこのツールを気に入っているし、実務でも使い続けている。
だが、使い込むほど「ここはちょっと違うな」と感じる瞬間もある。ツールへの愛着があるからこそ、正直に書いておきたいと思った。
この記事はネガティブキャンペーンではない。Google Stitch の限界を理解した上で使うと、期待外れを感じることが減り、強みをより活かせる。そういう視点から書く。
その1：「ちょっとだけ直したい」が難しい
Google Stitch で生成したUIに対して、「全体は気に入っているが、このボタンの色だけ変えたい」というケースは頻繁に起きる。
こういうとき、プロンプトで「ボタンの色を〇〇に変えて」と再指示すると、ボタンの色だけが変わるわけではなく、全体が再生成されることが多い。結果、「直したかったところ」は直るが「気に入っていたところ」が変わってしまう。
現時点では、生成結果を「部分的にアンドゥ」する機能が弱い。全体を再生成するか、出力されたHTMLコードを直接編集するか、どちらかを選ぶことになる。コードを直接触れる人には問題ないが、コードに慣れていない人にとっては大きなハードルだ。
この問題への現実的な対応策は「セクション単位で管理する」こと。ヘッダー、コンテンツエリア、フッターを別々のプロンプトで生成し、それぞれを独立して管理すれば、「このセクションだけ再生成」という操作が可能になる。最初から「分割して作る」設計が重要になる。
その2：「意図の微妙なニュアンス」が伝わりにくい
「少しカジュアルな雰囲気で」「もう少し落ち着いた印象で」——こういった「空気感」を言語化する難しさを、Google Stitch を使っていると特に痛感する。
AIは言葉を解釈するが、「カジュアル」の定義は人によって違う。あるUIが「十分カジュアル」に見える人と、「まだ硬い」と感じる人がいる。この主観的なニュアンスをプロンプトで伝えるのは難しく、「思い通りにならない」という体験の多くはここに起因していた。
突破口になったのは、形容詞での指定をやめて「具体的な属性」で指定することだ。「カジュアル」ではなく「角丸16px、パステルカラー、サンセリフ体、行間1.8」と具体化する。主観的な言葉を客観的な数値や要素に翻訳するスキルが、Google Stitch の使いこなしに直結する。
その3：長いセッションで「履歴の記憶」が薄れる
一つのプロジェクトを複数のセッションにわたって作業していると、「前回こういう方向性で決めたのに」という指示が引き継がれない場面が出てくる。
Google Stitch はセッションをまたいで「デザインの文脈」を持続させる仕組みが現時点では限られている。「前のセッションでフォントをこれに決めた」「このコンポーネントはこのスタイルと決めた」という蓄積が、次のセッションでは最初から伝え直す必要がある。
これが特に困るのは、長期プロジェクトや複数人が関わるケースだ。毎回スタイルガイドをプロンプトの冒頭に貼り付けることで対処しているが、「それをやらないといけない」こと自体が地味な摩擦になっている。
対応策として、プロジェクトごとに「スタイル定義テキスト」をテキストファイルに保存しておき、毎回冒頭にコピペする習慣をつけた。面倒だが、これを徹底すると一貫性が保てる。
「惜しい」を感じながらも使い続ける理由
三つの「ちょっと違う」を書いたが、それでも私は Google Stitch を使い続けている。探索フェーズのスピードと、アイデアを可視化するまでのハードルの低さは、現時点で他のツールにはない強みだからだ。
限界を知っているからこそ、「このフェーズはStitchで、この作業は別のやり方で」という判断が自然にできる。ツールに振り回されるのではなく、ツールを使いこなすとはそういうことだと思っている。
改善を期待しているポイント
個人的に今後のアップデートで改善されることを期待しているのは次の点だ。
- 部分的な再生成・編集の精度向上
- プロジェクト単位でのスタイル定義の永続化
- セッションをまたいだコンテキストの継続
- 生成UIに対するビジュアルエディタ的な細部調整機能
どれも「あれば格段に使いやすくなる」機能だ。Google Stitch はまだ発展途上のツールであり、これらが改善されていく可能性は十分あると思っている。
よくある質問
Q1. 「ちょっとだけ直したい」場合の最善策は何ですか？
生成されたHTMLコードを直接編集することが最も確実です。コードに慣れていない場合は、修正したい部分を含む「セクション単位」で再生成し、他のセクションには触れないようにする方法が現実的です。
Q2. 「カジュアルな感じ」のようなニュアンスをうまく伝えるコツはありますか？
形容詞を使わず、具体的な視覚属性（角丸の大きさ、フォントサイズ比率、配色の数値、余白の単位）に変換して指定することが効果的です。また、「〇〇のようなスタイル」と既知のアプリやブランドを参照することも有効です。
Q3. スタイル定義を毎回コピペするのは面倒ですが、効率化する方法はありますか？
テキストファイルとして保存し、テキストエクスパンダーや定型文ツールを使うと入力コストを減らせます。また、プロジェクト専用のプロンプトテンプレートを作っておくことで、毎回の設定コストを最小化できます。
Q4. これらの限界はすべてのユーザーに影響しますか？
コードを読み書きできるユーザーにとっては「部分編集が難しい」問題の影響は小さくなります。短期プロジェクトや単発の探索であれば「セッションをまたいだ記憶」の問題も気になりにくいです。自分の用途と照らし合わせて、どの制約が本当に問題になるかを確認してみてください。
Q5. これらの問題は他のAI UIツールでも同様ですか？
程度の差はありますが、「セッション記憶の限界」と「微細編集の難しさ」はAI生成ツール全般に共通する課題です。一方で、各ツールが異なる解決策を模索しており、今後の差別化ポイントになっていく領域だと思います。
Q6. 記事の内容はいつ時点のものですか？
2026年時点での使用経験に基づいています。Google Stitch は継続的にアップデートされており、一部の問題はすでに改善されている可能性があります。最新の機能については公式ドキュメントを参照してください。
まとめ
Google Stitch を使っていて「ちょっと違う」と感じた瞬間は、ツールの限界を教えてくれる機会でもある。
- 部分編集の難しさ → セクション分割で管理する
- ニュアンスの伝わりにくさ → 具体的な属性値で指定する
- セッションをまたいだ記憶の薄れ → スタイル定義を毎回冒頭に貼る
限界を知って使うツールは、期待を超えることがある。「惜しい」と感じながら使い続けているのは、それでも手放せない強みがあるからだ。
