エラー画面と空の状態を Google Stitch で設計する——見落とされがちなUIを丁寧に作るために

2026.04.12

UIデザインで最も見落とされがちなのは、「うまくいかなかったとき」の画面だ。データが空のとき、エラーが起きたとき、ロード中のとき——こういった「例外状態」の設計は後回しにされやすく、実装直前になって慌てて作られることが多い。

Google Stitch を使い始めた当初、私もそうだった。メインの画面はStitchで素早く作れるようになったが、エラー画面や空の状態（エンプティステート）を作るときは、なんとなく後で考えようと先送りにしていた。

あるとき、開発チームから「エラー時の画面が決まっていないので実装できない」と指摘された。その画面を急いでStitchで作ろうとしたとき、「どうプロンプトを書けばいいのか分からない」という壁にぶつかった。これを機に、エラー画面・エンプティステートをStitchで設計する方法を体系的に学んだ。

結論から言うと

一言で言えば、Google Stitch でエラー画面・エンプティステートを設計するには、「状態をプロンプトで明示的に指定する」ことが最大のポイントだ。Stitch のデフォルトはハッピーパス（正常状態）の生成に最適化されているため、例外状態は意識的に指示しないと出力されない。

具体的には、「ローディング・空・エラー・成功の4状態を、同一コンポーネント構造で生成する」というプロンプト戦略が最も効果的だった。これを習慣にすると、設計の抜け漏れが大幅に減る。

エンプティステートとエラー画面とは何か

エンプティステートとは、コンテンツが何もない状態の UI のことだ。たとえば通知リストが空のとき、検索結果が0件のとき、購入履歴が何もないとき——データがない状態でユーザーに何を見せるかを決めたのがエンプティステートだ。

エラー画面とは、操作が失敗したとき・接続が切れたとき・権限がないときなど、何らかの問題が発生した状態でユーザーに提示する UI のことだ。「500 Internal Server Error」のような技術的なメッセージをそのまま表示するのではなく、ユーザーが次にどうすればよいかを伝える設計が必要になる。

これらの「例外状態」の設計は、製品の印象を大きく左右する。エラーが起きたときにどんな画面が出るかで、そのサービスへの信頼感が決まることさえある。

4つの状態を常にセットで考える

UIの状態は大きく4つに分類できる。ローディング（読み込み中）・エンプティ（空の状態）・エラー（失敗状態）・サクセス（正常状態）だ。

多くのデザイナーはサクセス状態だけを設計し、残りを後回しにする。しかし4状態を最初からセットで設計することで、実装時の「この状態どうするんだっけ」という往復が減る。Stitch を使うなら、1つの画面を作るたびにこの4状態を同時に出力する習慣をつけることを強く推奨する。

エンプティステートの設計実践

効果的なプロンプトの書き方

エンプティステートを Stitch で出力するためのプロンプト例を紹介する。

悪い例：「通知リストの画面を作って」

良い例：「通知リストの画面を4状態で作って。(1)ローディング：スケルトンスクリーン表示 (2)エンプティ：通知が0件のとき、イラストとメッセージ「まだ通知はありません」を表示し、行動を促すCTAを置く (3)エラー：取得失敗時、エラーメッセージと再試行ボタンを表示 (4)サクセス：3件の通知アイテムを表示。全状態でコンポーネント構造を統一すること」

このように各状態を明示的に指定することで、Stitch は4状態のデザインをそれぞれ生成する。実際に使ってみて分かったのは、Stitch は「指示されたことを忠実に出力する」ツールであり、「指示されていない状態は生成しない」という前提で使うのが正しい、ということだ。

エンプティステートのデザイン原則

良いエンプティステートには、3つの要素が含まれている。まず「何もないことの説明」——ユーザーになぜ何もないかを伝える（例：「まだタスクが追加されていません」）。次に「次のアクションの提示」——ユーザーが次に何をすべきかを明示するCTA（例：「タスクを追加する」ボタン）。最後に「感情的な配慮」——空白をポジティブな体験に変えるイラストや文言（例：「一息ついて！今日のタスクは完了です」）。

Stitch のプロンプトにこの3要素を明示すると、意図通りのエンプティステートが出力されやすい。

エラー画面の設計実践

エラーの種類に応じた画面設計

エラーには複数の種類がある。ネットワークエラー（接続失敗）・サーバーエラー（500番台）・クライアントエラー（404・権限なし）・入力エラー（バリデーション）——それぞれに適切なUI設計が異なる。

Stitch でエラー画面を作るときは、「どの種類のエラーか」を具体的に指定する。「接続エラーの画面。オフライン状態であることを示すイコン、メッセージ「インターネット接続を確認してください」、再試行ボタン、オフラインでも使える機能へのリンク」というようにだ。

ユーザーを「次の行動」に導くエラー画面

エラー画面で最も重要なのは、ユーザーが「何をすれば解決するか」を理解できることだ。技術的なエラーコードだけを表示するのではなく、「〇〇が原因でエラーが起きました。△△を試してみてください」という人間的な言葉で伝えることが大切だ。

Stitch でこれを実現するプロンプト例：「データ取得エラー画面。エラーアイコン（赤×ではなくオレンジの注意マーク）、見出し「データの読み込みに失敗しました」、説明文「しばらく時間をおいてから再試行してください。問題が続く場合はサポートにお問い合わせください」、再試行ボタン（プライマリ）、サポートへ連絡ボタン（セカンダリ）。怖くない、穏やかなデザイン」

DESIGN.md でエラー/エンプティの標準を定義する

Google Stitch には DESIGN.md という、デザインシステムをナチュラルな文章で定義できるファイルフォーマットがある（2026年3月のStitch 2.0で追加）。これを使うと、エラー画面・エンプティステートの標準を一度定義すれば、以降の生成に一貫して適用できる。

例えば DESIGN.md に「エラー画面：背景は白、エラーアイコンはオレンジ、メッセージは日本語で丁寧語、再試行ボタンは必ず含める」と定義しておくと、以降のプロンプトでいちいち同じ指示を繰り返さなくて済む。プロジェクトの一貫性が大幅に向上する。

よくある質問（FAQ）

Q1. 4状態を1つのプロンプトで同時に生成できますか？

はい、できます。「以下の4状態のUIを生成してください：(1)ローディング (2)エンプティ (3)エラー (4)サクセス」と明示することで、1回の生成で4画面が出力されます。Stitch 2.0のマルチスクリーンキャンバス（最大5画面）を使えば、4状態を1セッション内で並べて確認・比較できます。

Q2. エラー画面のビジュアルデザイン（イラストなど）もStitchで作れますか？

テキストと基本的なシェイプを組み合わせたUIレベルのデザインは生成できます。ただし、カスタムイラストや独自のキャラクターを使ったエラー画面は、Stitch単体での生成には向いていません。シンプルなアイコンとテキストで構成されたエラー画面のたたき台を作り、細かいビジュアルは別途作成する分担が現実的です。

Q3. バリデーションエラー（入力フォームのエラー）はどう設計しますか？

入力フォームのバリデーションエラーは「フィールドごとのインラインエラー」と「フォーム全体のサマリーエラー」の2種類があります。プロンプトには「メールアドレスフィールドのインラインエラー：赤枠、エラーアイコン、メッセージ「正しいメールアドレスを入力してください」、フォームの上部にサマリーエラーバナーを追加」のように、表示場所と内容を具体的に指定するのが効果的です。

Q4. ローディングUI（スケルトンスクリーン）はStitchで作れますか？

作れます。「スケルトンスクリーン：実際のコンテンツが入る予定の場所に、グレーの長方形をプレースホルダーとして配置。アニメーションの指定は不要（静止画で可）」とプロンプトに書くと、スケルトン状態のUIが生成されます。実際のアニメーションはCSS実装時に追加します。

Q5. エラー画面が怖くなりすぎないようにするには？

プロンプトに「怖くない・穏やかな・フレンドリーな雰囲気」という感情的な指示を追加することが有効です。赤色よりオレンジやイエローを指定する、「エラー」という言葉を避けて「問題が起きました」という言い回しを使う、人に語りかけるようなトーンで文言を指定する——これらをプロンプトに含めると、威圧感の少ないエラー画面になりやすいです。