Google Stitch Web App デザインガイド

Web アプリは「ログインボタンが付いたランディングページ」ではありません。ナビゲーション、権限、データテーブル、フォーム、設定、空状態、レスポンシブレイアウトがあります。プロンプトがビジュアルだけでなく製品構造を説明していれば、Stitch は説得力のある初稿を作れます。

この記事では、Web アプリを使いやすくするページと仕組みに焦点を当てます。7 つの主要ページ、レイアウトモデル、再利用できるプロンプトの型、デザインからコードへの引き継ぎです。

Web アプリ、ランディングページ、モバイルアプリの違い

ランディングページには 1 つのコンバージョン目標と一直線のストーリーがあります。Web アプリは繰り返し発生するタスクを支えるため、ナビゲーション、状態、情報密度、権限が必要です。モバイルアプリはタッチ、片手操作、短いセッションを優先します。同じ構造で 3 つをプロンプトすると、少なくとも 1 つはうまくいきません。

プロンプトの最初の文で画面の種類を明示します。次にページタイプを書きます。同じ製品でも「ダッシュボード」と「設定」では必要なコンポーネントが違うからです。

すべての Web アプリに必要な 7 つのページ

認証

ログイン、新規登録、パスワードリセット、確認。レイアウトはシンプルにし、主アクションを明確にし、エラーと読み込み状態を含めます。

オンボーディング

製品が最初の有用な結果を出すために必要な情報だけを集めます。進捗表示、1 ステップ 1 判断、スキップまたは戻る手段を用意します。

ダッシュボード

ダッシュボードは走査と比較のための画面です。少数の指標、1 つのトレンド、注意が必要な作業への導線を優先します。製品内のすべてのグラフを並べる場所ではありません。

リストとテーブル

リストには並べ替え、絞り込み、ページネーション、行選択、一括操作、明確な空状態が必要です。テーブルは実際のデータを載せても読みやすい密度にします。

詳細

詳細ページは「これは何か、何が起きたか、次に何ができるか」に答えます。主アクションを見える位置に置き、副次アクションはまとめます。

設定と請求

設定では ID、環境設定、チーム権限、支払いを管理します。明確なセクション、安全な初期値、破壊的操作の確認を使います。

空状態とエラー状態

新しいアカウントは空です。ネットワークは失敗します。権限は変わります。インターフェースが崩れる前に、これらの状態を意図して設計します。

Web アプリのレイアウトシステム

サイドバー + コンテンツ

最も一般的な SaaS レイアウトです。固定ナビゲーション、検索とアカウント操作のトップバー、リスト・詳細・設定を切り替えるコンテンツ領域で構成します。情報密度の高い製品に向いています。

トップナビゲーション

比較的シンプルな Web アプリやマーケティング寄りの製品に向いています。コンテンツ領域は広くなりますが、セクションやロールが増えると混み合います。

分割ビュー

受信箱、サポートツール、リストと詳細を比較する画面に向いています。左ペインが選択、右ペインが文脈と操作を担当します。

レスポンシブのブレークポイント

1440px から始め、1280px、1024px、768px を確認します。サイドバーを畳み、テーブルの列を減らし、副次アクションをメニューに移します。複数サイズを生成する前に、Stitch のデバイスタイプを確認してください。

Web アプリのプロンプトの型

各ページでこの構造を使い、角括弧を製品固有の情報に置き換えます。

Design a [web app type] for [audience].
Page: [page type] whose primary job is [job].
Navigation: [sidebar / top nav / split view].
Layout: [columns, density, max width].
Components: [table, filters, forms, charts, modals].
States: [loading, empty, error, success, permission denied].
Style: [design system or visual direction].
Constraints: [breakpoints, accessibility, data volume].

この型は、ページ、ナビゲーション、状態を同じプロンプトにまとめます。美しいモックアップと使えるアプリ画面の差は、多くの場合ここで生まれます。

ダッシュボードのプロンプト例

Design a B2B analytics web app dashboard for a customer support platform.
Page: dashboard; primary job is to show queue health and surface the most urgent conversations.
Navigation: left sidebar with Inbox, Analytics, Team, Settings; top bar with date range and search.
Layout: 12-column grid, four KPI cards, two charts, and a conversation table below.
Components: KPI cards, line chart, stacked bar chart, sortable table, filter bar.
States: loading skeletons, empty queue, error banner, permission-denied state.
Style: clean SaaS interface with neutral surfaces and one blue accent.
Constraints: 1440px first, responsive to 1024px; table must remain scannable.

ランディングページのプロンプト例

Design a landing page for a developer tool that turns API logs into dashboards.
Audience: backend engineers at small SaaS teams.
Primary goal: start a free trial.
Sections: hero with code sample, three feature blocks, integration logos, pricing preview, FAQ, final CTA.
Style: technical editorial, monospace accents, restrained color, generous whitespace.
Constraints: mobile-first; one primary CTA repeated; no stock-photo hero.

ランディングページは Web アプリではありませんが、同じ製品に両方が必要な場合があります。ビジュアルシステムは共有し、ナビゲーションと密度を変えます。

コンポーネントと状態

Web アプリの成否はテーブルで決まることが多いです。並べ替え、絞り込み、ページネーション、一括操作、列の優先順位、データがないときの挙動を指定します。フォームにはラベル、検証、エラーメッセージ、成功フィードバック、明確な主ボタンが必要です。モーダルとトーストは、独立したページにすべき内容ではなく、判断と短いフィードバックに使います。

Stitch には「うまくいった状態」だけでなく状態そのものを依頼します。読み込み、空、エラー、権限を含むプロンプトは、より完全な画面を生み、レイアウトの問題を早く見つけられます。

ページの一貫性を保つ

製品、ユーザー、スタイルルール、制約を含む共通のプロンプト接頭辞を書きます。その後、すべてのページで同じ色、書体、余白、角丸、コンポーネント語彙を再利用します。ページがずれたら、プロンプトでごまかさず共通の制約を直します。

Stitch のバリアントは、ビジュアルシステムを変えずにレイアウト案を試すのに役立ちます。より大きなシステムでは、デザインルールを DESIGN.md に書き、画面やコーディングエージェント間で再利用します。

デザインからコードへ

Web アプリのデザインは、開発者が実装できて初めて役に立ちます。まずレイアウト、コンポーネント名、状態を整理します。次に Stitch の HTML、React、Tailwind 指向の出力を出発点にし、リリース前にレビューします。

書き出し機能は成果物のダウンロード、ターミナルでの流れは CLI チュートリアル、コードベースとデザインシステムの往復はコードからデザインへのワークフローを参照してください。

QA チェックリスト

Web アプリ画面を引き継ぐ前に確認します：

主アクションが 1 つで、ページタイトルが明確か；
ナビゲーションがユーザーのロールとタスクに合っているか；
テーブルやリストが 1024px でも読めるか；
読み込み、空、エラー、成功、権限の状態があるか；
フォームにラベル、検証、確認があるか；
色、書体、余白、角丸が一貫しているか；
次のブレークポイントへのレスポンシブ方針があるか；
重複したり衝突したりする操作がないか。

よくある質問

Stitch は複雑な管理画面に向いていますか？

レイアウト、階層、ビジュアル方向の初稿には向いています。複雑な管理製品には、実際のデータモデリング、権限、ユーザビリティテストが依然として必要です。Stitch で探索と方向合わせを行い、ユーザーで検証します。

レスポンシブな Web アプリ画面を生成するには？

まずデスクトップレイアウトを生成し、次に 1024px と 768px での具体的な変更を依頼します。サイドバーを畳む、テーブル列を減らす、カードを積む、などです。AI がすべてのブレークポイントを推測するとは考えないでください。

Web アプリのデザインをコードに書き出すには？

Stitch の書き出しオプションを使い、生成された HTML、React、Tailwind の出力をレビューします。出発点として扱い、自社のアーキテクチャ、アクセシビリティ、テスト基準を適用します。繰り返し可能なパイプラインには SDK または CLI を使います。

次のステップ

より広い設計プロセスが必要なら、Google Stitch AI UI デザインガイドを読んでください。Web アプリのスタイルを見る、エディタを試す、チュートリアルで体系的に練習するのもおすすめです。