モーダルダイアログは、ユーザーの作業を強制的に中断させる「割り込みUI」だ。だから、使い方を間違えると、ユーザー体験を大きく損なう。
Google Stitch でUIを作り始めて気づいたのは、モーダルを「とりあえず入れてしまう」傾向が自分にあることだった。確認が必要な操作、情報の補足、設定変更——こうした場面でモーダルを選ぶのはある意味自然なのだが、振り返ってみると「本当にモーダルが必要だったのか？」と首をかしげるケースが少なくなかった。
この記事では、Google Stitch でモーダルダイアログを設計する際の判断軸と、実際に体験した失敗パターン、そしてどう改善したかを正直に書く。
結論から言うと： モーダルダイアログが有効なのは「ユーザーに必ず意思決定させる必要がある場面」に限定されるべきで、それ以外の用途では代替UIを検討すべきだ。Google Stitch でモーダルを設計するときは「なぜモーダルでなければならないか」を自問するプロセスが、品質を大きく左右する。
モーダルダイアログとは何か——定義と基本的な役割
モーダルダイアログとは、メイン画面の上に重ねて表示され、ユーザーが何らかのアクション（確認・キャンセル・入力など）を取るまで、背景の操作を受け付けなくする UI コンポーネントのことです。
「モーダル」という言葉はラテン語の “modus”（様式・状態）に由来し、UIにおいては「特定の状態に強制的に遷移させる」ことを意味する。背景が薄暗くなり（オーバーレイ）、ダイアログが中央に浮かび上がる——あの表示形式がモーダルダイアログだ。
実際に Google Stitch を使い始めた当初、私はモーダルの定義を「ポップアップウィンドウ全般」と混同していた。しかし、モーダルとモードレス（ポップオーバー・ドロワーなど）は設計思想が根本的に異なる。モーダルは「ユーザーを止める」コンポーネントであり、モードレスは「ユーザーを止めない」コンポーネントだ。この区別を意識するようになってから、UIの選択に迷う回数が明確に減った。
モーダルが向いている場面
モーダルダイアログが本領を発揮するのは、次のような場面だ。
- 取り消し不可能な操作の最終確認（削除・退会・送信）
- 重要情報の入力・確認（支払い情報・認証コード）
- クリティカルなエラーの通知（セッション切れ・権限エラー）
- 同意が必要な利用規約・プライバシーポリシーの表示
- ユーザーに必ず選択を迫る二者択一の状況（更新版への移行・プラン変更など）
共通点は「ユーザーが必ずレスポンスを返す必要がある」という点だ。Google Stitch でこうした場面のモーダルを設計するとき、私はプロンプトに「ユーザーが必ず確認する必要がある操作」という文脈を明示するようにしている。文脈を書くと、Stitch が生成するボタン配置・コピーの重みが変わる。
モーダルが向いていない場面
逆に、モーダルを使うべきでない場面も多い。私が実際に失敗したケースを含めると——
- フォームの説明・補足情報の表示（ツールチップやサイドパネルで十分）
- フィルター・検索条件の設定（ドロワーやインラインUIの方がUXが良い）
- 成功・完了の通知（トースト通知で十分）
- 単なる追加コンテンツの表示（ページ遷移またはアコーディオンで代替できる）
- ユーザーが「ながら」操作したい設定画面（バックグラウンドを見ながら設定したい場合）
「せっかく設計したのにモーダルじゃなかった」と気づくのは、実際にプロトタイプをクリックしてみたときだ。Google Stitch の Play ボタン（2025年12月に追加）でプロトタイプを動かしながら確認するプロセスが、こうした判断に役立っている。静的なビジュアルを見ているだけでは気づきにくい「操作の流れのなかでのモーダルの重さ」が、インタラクションを体験することで初めて感じられる。
Google Stitch でモーダルを生成するときのプロンプト設計
Google Stitch に「モーダルを作って」と伝えるだけでは、求めているものと大きくずれることがある。私が試してきた中で、精度の高いモーダルを生成するためのプロンプトの考え方を整理する。
実際に Google Stitch を使ってみてわかったのは、コンテキストの明示がモーダル生成の精度を決定的に左右するということだ。「どのページから」「何をトリガーに」「ユーザーに何をさせたいか」——この3点をプロンプトに入れるだけで、生成結果の質が変わる。ページ全体のコンテキストなしで「確認モーダルを作って」と指示すると、汎用的なプレースホルダーデザインが出てくることが多い。
具体的なプロンプト例と改善のコツ
以下のような形で指示を書くと、意図に近いモーダルが生成されやすい。
「タスク管理アプリのタスク一覧画面。各タスク行の右端にある『削除』ボタンをクリックした際に表示される確認モーダルを設計してください。モーダルには『本当に削除しますか？この操作は元に戻せません』というメッセージと、『削除する』（赤色・主アクション）と『キャンセル』（グレー・副アクション）の2つのボタンを配置してください。背景はオーバーレイで暗くし、クリックしても閉じないようにしてください。モーダル幅は480px、中央配置でお願いします。」
このように、配置する要素・テキスト・色・インタラクションの制約・サイズまで含めると、ほぼ意図通りの出力が得られる。逆に「削除確認のモーダル」だけだと、ボタンの色やオーバーレイの有無が意図と異なることがある。
私がよく使うプロンプト構造は「画面名 → トリガー → モーダルの目的 → 必要な要素 → インタラクション制約 → ビジュアル指定」という順番だ。この順番で書くと Stitch が文脈を正しく解釈しやすくなる。
Vibe Design を使った感覚的なモーダル設計
2026年3月のアップデートで追加された Vibe Design（ムード・スタイルを言葉で指定する機能）を使うと、モーダルのビジュアルトーンを直感的に調整できる。Vibe Design とは、「ミニマル」「フレンドリー」「コーポレート」といった感性的なキーワードでデザインの雰囲気を制御できる Google Stitch の入力機能のことだ。
「ミニマルでクリーン、角丸が大きくフレンドリーな印象の確認モーダル」「エラー系のモーダルだがパニックを感じさせないよう落ち着いた赤と白のデザイン」といった形で、機能要件とビジュアル要件を分けて指示すると整理しやすい。特にエラー系モーダルは「警告感を出しつつも圧迫しない」という絶妙なバランスが必要で、Vibe Design による表現が有効だと感じている。
実際に遭遇した失敗パターン3選
Google Stitch でモーダルを作り続けてきて、繰り返し同じ失敗をしていると気づいた。以下は、私が実際に体験した典型的なミスだ。同じ轍を踏まないための参考として読んでほしい。
失敗1：モーダルを情報の「置き場所」にしてしまう
あるSaaSの管理画面を設計しているとき、各レコードの詳細情報を表示するためにモーダルを使っていた。「詳細を見る」ボタンを押すとモーダルが開き、そこに10以上のフィールドが並ぶ設計だ。
しかし実際にプロトタイプをテストしてみると、詳細情報が多くてモーダル内でスクロールが発生し、ユーザーがどこまで読んだか把握できなくなってしまった。しかも、スクロール後に「閉じる」ボタンが見えなくなるという問題まで起きた。
モーダルはあくまでも「一時的な割り込み」のためのコンポーネントだ。大量の情報を表示する場面には、スライドインするサイドパネル（ドロワー）や別ページへの遷移の方が適している。Google Stitch でこの問題に気づいたのは、Playボタンで実際に操作してみたときだった。「モーダルで詳細を見せる設計だとスクロールが必要」という制約を認識できたのは、静的なデザインを見ていた段階ではなく、インタラクションを体験したときだった。
失敗2：すべてのモーダルに「閉じるボタン」を置く
「ユーザーが簡単に閉じられるようにしないといけない」という思い込みから、確認モーダルにも右上の × ボタンを配置し続けていた。しかしこれが問題になるケースがある。
取り消し不可能な操作（データ削除・退会処理など）の確認モーダルでは、× ボタンでモーダルを閉じることが「暗黙のキャンセル」として機能することが多い。その場合、× ボタンと「キャンセル」ボタンの2種類が存在することになり、ユーザーを混乱させる。「× で閉じたのにキャンセルされていなかった」という誤解が生じるリスクもある。
Google Stitch では、こうした意図をプロンプトで「閉じるボタンなし。キャンセルは『キャンセル』ボタンのみで行う設計にする」と明示することで対応できる。一方で、情報確認系のモーダル（ヘルプ・補足説明など）では × ボタンがあった方がユーザーフレンドリーだ。用途に応じてルールを使い分けることが重要だ。
失敗3：モーダルを重ねて（ネストして）しまう
モーダルの中に、さらに確認のモーダルを重ねる設計をしてしまったことがある。「設定変更モーダル」の中で危険な操作をした際に「本当に実行しますか？」という二重確認モーダルが開く——という構造だ。
これはユーザビリティの観点から非常に問題がある。ユーザーは「どこにいるのか」が把握できなくなり、混乱する。画面が2重に暗くなり、視覚的にも不快だ。
モーダルのネストは基本的に避けるべきで、代替策としては「インラインの警告メッセージ」「モーダル内のボタンの状態変化（クリック後に確認テキストをボタン下部に表示する）」などがある。Google Stitch でこの問題を解消するには、プロンプト段階で「モーダルのネスト禁止、危険な操作の確認はインラインの赤いテキストで対応する」と制約を書いておくのが有効だ。
モーダルの代替UIパターンと使い分け
モーダルダイアログを使わずに同じ目的を達成できる代替UIパターンを整理しておく。「モーダルかモーダルじゃないか」という二択で考えていると、設計が硬直化する。実際には多くの場面でモーダル以外の選択肢の方がユーザー体験が良い。
ドロワー（サイドパネル）
画面の端からスライドインする形式のUIコンポーネント。大量の情報表示や複雑なフォーム入力に向いている。背景の操作を完全には遮断しない点がモーダルとの違いだ。
詳細情報の表示（CRMの顧客詳細、Eコマースの商品詳細など）、設定変更（フィルタリング条件・通知設定）、複雑な編集フォームなどに適している。Google Stitch でドロワーを生成する際は「右からスライドインするサイドパネル、幅は画面の1/3、背景は半透明オーバーレイ、上部に閉じるボタン」という形で指示すると精度が高い。
トースト通知とインライン確認
トースト通知とは、操作の成功・失敗を一時的に通知するUIのことだ。画面の隅（通常は右下や上部中央）に表示され、数秒後に自動で消えるため、ユーザーのアクションを必要としない。「保存しました」「エラーが発生しました」などの軽い通知に使う。モーダルで「保存完了」を表示するのは過剰だ。
インライン確認とは、「本当に削除しますか？」という確認を、削除ボタンの横にインラインで表示する手法のことだ。ボタンをクリックすると「削除する」「キャンセル」が同じ行に展開される。モーダルを開くほどでない軽い確認——例えば、ToDoリストの単一アイテム削除、短いメモの破棄など——に有効だ。
私が実際に使ってみた感触では、インライン確認はデスクトップアプリでは非常に効果的だが、モバイルではタップターゲットが小さくなりすぎる問題がある。Google Stitch でデバイス別の設計を行う際は、この点も意識してプロンプトに含めると良い。
Google Stitch でのモーダル設計チェックリスト
Google Stitch でモーダルを設計するとき、私が必ず確認するポイントをリストにした。設計の判断軸として、プロンプトを書く前に以下を自問するようにしている。
- そのモーダルは本当に「ユーザーを止める必要がある」場面か？
- モーダルの中でスクロールが発生するほど内容が多くないか？
- モーダルをネスト（二重表示）していないか？
- 閉じるボタン（×）とキャンセルボタンの役割が重複していないか？
- オーバーレイをクリックして閉じる動作は、このモーダルに適切か？
- アクセシビリティ（フォーカス管理、Escキーでの閉じる動作）は設計書に明記されているか？
- モバイルでも同じUI形式で問題ないか？（場合によってはボトムシートに切り替える）
これらをプロンプトに組み込むことで、Google Stitch が生成するモーダルの質が上がる。特に「フォーカストラップ」（モーダルが開いている間、Tab キーでのフォーカス移動をモーダル内に限定する）はアクセシビリティ上重要な要素だが、ビジュアルデザイン上では見えにくい。エンジニアへの引き継ぎ資料には必ず補足説明を加えるようにしている。
Google Stitch のモーダル設計とアクセシビリティ
モーダルダイアログはアクセシビリティの観点から特に注意が必要なコンポーネントだ。WCAG（Web Content Accessibility Guidelines）においても、モーダルダイアログは実装要件が詳細に定められている。
Google Stitch でモーダルの見た目を設計した後、エンジニアに実装を依頼する際に必ず伝えるべき要件を整理しておく。これは Stitch のビジュアルデザインには現れない部分だが、実際のユーザー体験に大きく影響する。
- フォーカス管理：モーダルが開いたときに最初のインタラクティブ要素にフォーカスが移動すること。モーダルが閉じたときにフォーカスをトリガー要素（モーダルを開いたボタン）に戻すこと
- フォーカストラップ：モーダルが開いている間、Tabキーでのフォーカス移動をモーダル内に限定すること
- aria属性：モーダルのコンテナ要素にrole=”dialog”とaria-modal=”true”を付与すること。aria-labelledbyでモーダルのタイトルと紐付けること
- Escキー対応：キーボードユーザーがEscキーを押してモーダルを閉じられるようにすること（取り消し不可能な操作の最終確認モーダルは例外）
- スクロールロック：モーダルが開いている間、背景のスクロールを無効化すること
これらの要件を Google Stitch のデザイン段階でコメントとして付記しておくと、エンジニアへの引き継ぎがスムーズになる。私は実際に、Stitch で設計したモーダルに注釈を加えて「このモーダルはEscで閉じない（削除確認のため）」「フォーカストラップが必要」といった実装指示を一緒に渡すようにしている。
モーダルのサイズと配置——Google Stitch での設計パターン
Google Stitch でモーダルを設計するとき、サイズと配置の指定も品質に影響する。実際に使ってみた経験から、以下のパターンに分類して指示するようにしている。
サイズ別の使い分け
スモールモーダル（幅400〜480px）は、シンプルな確認ダイアログ（「削除しますか？」）やアラート系に使う。コンテンツが少なく、ボタンが1〜2つの場合に適している。Google Stitch では「幅480px、中央配置、2つのアクションボタン」と指定する。
ミディアムモーダル（幅560〜640px）は、フォームを含む設定変更・情報入力に使う。テキストフィールド数個＋ボタン構成が入る。入力フォームがある場合は、ラベルとフィールドの間隔も指定しておくと生成精度が上がる。
ラージモーダル（幅720〜800px以上）は、詳細情報の表示や複数セクションを持つフォームに使う。ただし、この規模になるとドロワーへの置き換えを検討した方が良いことが多い。「ラージモーダルが必要になった時点でドロワーを検討する」という自分なりのルールを持つと設計の迷いが減る。
配置と縦位置の調整
配置についてはほとんどのケースで「画面中央・上から20〜30%の位置」が標準だ。ただし、長いコンテンツを持つモーダルでは上揃え（画面上端から10〜15%の位置）の方がスクロールしやすい場合もある。
モバイルでは「ボトムシート形式」への切り替えを検討すべき場面が多い。ボトムシートとは、画面下から引き出すように表示されるパネルのことで、親指で操作しやすいモバイルUIに最適化された形式だ。Google Stitch では「モバイル版はボトムシート形式、画面高さの60〜70%を占める、スワイプで閉じる」といった形で指定できる。
よくある質問（FAQ）
Q：Google Stitch でモーダルを生成すると、なぜかデザインがぼんやりしてしまうのですが？
A：プロンプトの具体性が不足している可能性が高いです。「モーダルを作って」ではなく、「幅480px・中央配置・オーバーレイあり・タイトル1行・メッセージ2行・ボタン2つ（プライマリ赤・セカンダリグレー）」のように、寸法・色・要素数を明示してみてください。実際に試したところ、この詳細度でプロンプトを書くと出力のバラつきが大幅に減りました。特に色指定はあいまいにしがちなので「プライマリアクションは赤（#D32F2F）、セカンダリは薄いグレー（#F5F5F5）」のように HEX 値まで書くと精度がさらに上がります。
Q：削除確認のモーダルに「× ボタン」は必要ですか？
A：削除などの取り消し不可能な操作の確認モーダルでは、× ボタンを省略してキャンセルボタンのみにする設計が推奨されます。× ボタンとキャンセルボタンが両方あると「どちらが正しいキャンセルか」ユーザーが迷うためです。ただし、軽い情報確認モーダル（「詳細を見る」「ヘルプ」系）では × ボタンがあった方がユーザーフレンドリーです。用途によって判断し、Google Stitch のプロンプトに明示することをおすすめします。
Q：モーダルとドロワーはどう使い分ければいいですか？
A：「ユーザーを完全に止める必要があるか」が判断軸です。削除確認・重要な同意取得のようにユーザーが必ずレスポンスを返す必要がある場面はモーダル、詳細情報の表示・設定変更・フィルタリングのように「メインコンテンツを見ながら操作できると便利な場面」はドロワーが適しています。Google Stitch では両方を並べてプロトタイプを作り、どちらがユーザーフレンドリーか Play ボタンで試してみることができます。
Q：Google Stitch で作ったモーダルをそのままコードに実装できますか？
A：Google Stitch が生成するコード（HTML/CSS/React）はモーダルの見た目に関しては精度が高いです。ただし、フォーカス管理・aria 属性・Esc キー対応などのアクセシビリティ要件は別途実装が必要です。スタイルのベースとして使い、インタラクション部分はエンジニアが補完する形が現実的なワークフローです。デザインとコードの橋渡しとして Stitch を活用することで、実装工数を大幅に削減できます。
Q：モバイルでのモーダル設計で注意することはありますか？
A：画面幅が狭いモバイルでは、通常のモーダルが画面をほぼ占有してしまうことがあります。幅を画面の90%程度に設定し、高さが長くなる場合はモーダル内スクロールよりも「フルスクリーンのボトムシート」への変更を検討してください。Google Stitch では「モバイル画面でのボトムシート形式の確認ダイアログ」と指定することで、スマートフォン向けのUI変種を生成できます。また、タップターゲット（ボタンの高さ）は最低44px以上にする指定も忘れずに。
Q：モーダルを頻繁に表示するアプリ設計はなぜ問題なのですか？
A：モーダルはユーザーの作業を強制的に中断させるため、頻繁に出現するとユーザーは「モーダル疲れ」（alert fatigue）に陥ります。「またモーダルか」と無意識に内容を読まずに閉じるようになり、本当に重要な確認モーダルも無視されるリスクが高まります。モーダルの使用頻度を下げることが、1つひとつのモーダルの効果を高めることにつながります。実際の設計では「セッション内にモーダルが何回表示されるか」を意識し、不必要なものをトースト・インライン通知に置き換えていくのがおすすめです。
Q：Google Stitch でモーダルアニメーションは設定できますか？
A：Google Stitch は現時点（2026年4月）でネイティブなアニメーション設定には対応していません。Google I/O 2025でのローンチ以来、アニメーション・マイクロインタラクション機能は非対応のままです。フェードイン・スライドインなどのモーダル出現アニメーションは、エンジニアの実装段階で追加する必要があります。ただし、Vibe Design でトーン・スタイルを調整することで、「このモーダルはソフトに出現してほしい」というニュアンスをエンジニアと共有しやすくなります。
注意点・失敗しやすいポイント
- モーダルを「ページの代わり」に使わない：コンテンツ量が多い詳細情報を表示するためにモーダルを使うと、スクロールが発生し、ユーザーが迷子になる。100文字程度の情報はOK、数百文字以上の詳細情報はドロワーまたは別ページへ。
- アクションボタンの順番・配置に一貫性を持たせる：「確認」「キャンセル」の配置が画面によって変わると、ユーザーは誤操作しやすい。プライマリアクションを右に置くパターンで統一するなど、サービス全体のルールを先に決めてから Google Stitch で設計する。
- オーバーレイクリックで閉じる挙動を設計段階で明示する：情報確認系のモーダルはオーバーレイクリックで閉じてよいが、削除確認系のモーダルは閉じないようにすべきだ。この違いをプロンプトで明示するか、エンジニアへの引き継ぎ資料に記載する。
- モーダル内にリンクを置かない：モーダル内に外部リンクや別ページへのリンクを置くと、ユーザーがどこに遷移したか把握できなくなる。必要な情報はモーダル内に完結させるか、閉じてから遷移する設計にする。
- テキストは「見られない」前提で書く：モーダルはユーザーが急いで閉じることが多い。長い説明文は読まれない。タイトル・操作に必要な情報・ボタンラベルの3要素に情報を絞り込み、メッセージは1〜2文にとどめる。
まとめ
Google Stitch でモーダルダイアログを設計するにあたって最も大切なのは、「これは本当にモーダルが必要な場面か？」という問いを毎回立てることだ。
モーダルは「割り込みUI」であり、ユーザーの流れを強制的に止める力を持つ。その力を正しく使えば、削除確認・重要な同意取得など、ユーザーに必ずアクションを取らせるべき場面で大きな効果を発揮する。しかし、情報表示・軽い通知・設定変更などにモーダルを乱用すると、ユーザー体験を著しく損なう。
Google Stitch でモーダルを設計する具体的なコツは次の3点だ。
まず、プロンプトに「どのページから」「何をトリガーに」「ユーザーに何をさせたいか」という3点のコンテキストを必ず含めること。これだけで生成の精度が大幅に上がる。
次に、生成後は Play ボタン（2025年12月追加）で実際のインタラクションを体験すること。静的なデザインでは気づかない問題——スクロールの発生、ボタン配置の違和感、視線の流れのズレ——がインタラクションを体験することで初めて見えてくる。
最後に、アクセシビリティ要件（フォーカス管理・aria 属性・Esc キー対応）はビジュアルデザインには現れないため、エンジニアへの引き継ぎ資料に必ず補足すること。Google Stitch は見た目の設計ツールとして優れているが、動的な挙動はエンジニアとの連携で補完する必要がある。
モーダルを「なんとなく」使うのをやめた日から、設計の精度が上がった気がしている。その問いを持ち続けることが、Google Stitch を使いこなすための、地味だが大切な習慣だ。
