作業の中断を一切強要せず、「結果」だけを静かに一過性でフィードバックするためのコンポーネント。
この記事を読むと、トースト・アラート・モーダルの正確な使い分けや、消滅のタイミング・A11y要件が自分でできるようになります。
1. UI例（Preview / Live）
実装で見る（GunjoUI）
この部品を、デザインシステム GUNJO の実装で確かめられます。
2. 定義（Definition）
画面の隅（下部や上部）に一定時間表示され、自動的に消える一時的なフィードバック用の小さなメッセージ。
Alert（インライン）との違い：インラインのアラートは画面の一部に鎮座し「消さない限り出続ける（または状況が解決するまで消えない）」のに対し、トーストはユーザーの操作と無関係にタイムアウトで消滅する。
3. 使い分け（When to use / When NOT to use）
3.1 When to use
- アクションの成功（「保存しました」「コピーしました」等）、確実なフィードバックを返したいとき
- ユーザーの現在のタスクや画面滞在を一切邪魔したくないとき
- 即座の対応を求めない、システムからの情報共有のとき
3.2 When NOT to use
- 致命的なエラーや、ユーザーが「必ず読んで対応しなければならない」クリティカルな問題（AlertDialogや固定のAlertを使うべき）
- 長文のメッセージ（数秒で読める短い文章にすべき）
- 「元に戻す（Undo）」等のアクションが必要だが、時間が短すぎて押せない・あるいは頻繁に押す場合
3.3 代替UI（Alternatives）
- 解決を強要する警告・エラー →
Alert/Inline Banner - 破壊的アクションの確認・同意 →
AlertDialog/Dialog
4. 設計判断の核（Decision Principles）
「見逃されても致命的でない」情報か？
判断の優先順位：① 見逃しリスクの許容度 → ② メッセージの短さ → ③ 自動消滅までの時間
- トーストは「気づかない」「読む前に消える」リスクが常に伴うため、重大なエラー通知やユーザーアクション待ちのフローに組み込んではならない。
5. 状態設計（States）
5.1 必須状態（Required）
- Success（成功）：アイコン（✓等）を伴い、アクションが無事完了したことを伝える
- Info（通知）：中立な情報（例：バックグラウンドでの受信等）を伝える
5.2 条件付き状態（Conditional）
- Warning/Error（エラー）：保存の軽微な失敗等。ただし重大なエラー（決済失敗等）には原則使わず、使う場合はタイムアウトの自動消滅を無効化する工夫が必要
- Hover (Pause)：マウスオーバー中、消滅のカウントダウンタイマーが一時停止している状態
5.3 State Gallery
| 状態 | 必須 | 何を伝えるか |
|---|---|---|
| Success | ✅ | 正常に完了。次の操作へ移ってよいという安心感 |
| Info | ✅ | 知っておくべきだが、特にすぐ行動しなくてよい事実 |
| Warning / Error | — | 軽微な失敗やリトライ可能な事象。※致命的なものには使用不可 |
| Hover (Pause) | — | 読んでいる途中で勝手に消えないための配慮 |
6. バリエーション設計（Variants）
メッセージの種類・緊急度に合わせてバリアントを選ぶ。
| バリアント | 目的 |
|---|---|
| Simple Toast | アイコンと1行のテキストのみ。最も基本的でノイズが少ない |
| Toast with Action | メッセージの横に「Undo（元に戻す）」や「再試行」ボタンを持つ |
| Descriptive Toast | 1行のタイトルと、短い説明文（2行程度）を持つやや詳細な通知 |
禁止パターン：トースト内部に長い入力フォームを配置したり、長大なエラーの内容を全て書き連ねる。
7. パターン集（Good / Bad / How to fix）
7.0 よく崩れる設計パターン（3つ）
- 消えないトースト：「完了しました」というメッセージが出たまま消えず、裏のボタンを永遠に隠し続ける
- 重要情報の見逃し：決済失敗など「絶対に見逃してはいけないエラー」を数秒で消えるトーストで出す
- 連打スパム：毎回の保存等でトーストが無限に積み重なり、画面が埋め尽くされる
7.1 Bad（典型3つ）
- 「プロフィールの更新に失敗しました。パスワードは8文字以上で記号を含み、メールアドレスは……」という長大な説明が3秒で消滅する
- ユーザーが操作（閉じるボタン押下）しない限り絶対に消えない邪魔な成功トースト
- 画面中央の真ん中に巨大なトーストが出て、元のテキストを覆い隠す
7.2 Good（対になる3つ）
- フォームの上部に赤文字で「入力を確認してください」と固定表示し（インラインAlert）、成功時のみToastの「保存しました」を使用する
- 成功時は3〜5秒（文字数による）で自然に消え、フェードアウトして邪魔にならない
- 画面の左下または右下に配置され、重ねて出ても最大3つ程度で古いものから消えていく
7.3 How to fix（手順）
- 返すべきフィードバックが「成功（見逃してもOK）」か「失敗（修正が必要）」かを分ける
- 失敗の場合はインラインのAlertやエラー文に変更し、自動消滅させない設計に切り替える
- トーストの文言は10〜20文字程度（主語＋動詞）に極限まで圧縮する
- 実装時に Auto-dismiss（自動消滅）処理を入れる
8. ルール（Must / Better）
Must（守らないと壊れる）
Better（品質が跳ねる）
9. アクセシビリティ要件（必須）
Keyboard
- トースト内部にアクション（Undo等）がある場合、出た瞬間にTabキーで到達できるようにするか、ショートカットを提供すること
Focus
- トーストが出現した際、基本的にフォーカスは奪わない（現在の作業を邪魔しないのがトーストの要件であるため）
Screen Reader
- トーストが表示された際、フォーカスを移動させなくても等しくテキストが読み上げられるよう、コンテナに
role="status"やrole="alert"（エラー用）、またはaria-live="polite"（エラーなら"assertive"）を適切に設定する
Touch / Pointer
- スマホ等の小さい画面では、トースト本体を左右にスワイプ（Swipe to dismiss）で直感的に消せるようにする
Contrast / Readability
- 文字と背景のコントラスト比は4.5:1以上を確保する
- 背景のコンテンツに溶け込まないよう、BorderやShadowで物理的な「浮き」を作る
10. 実装メモ（Implementation Notes）
- React等のSPAでは、全画面共通の
ToastProviderをRootに置き、状態（配列）を一元管理してどこからでもtoast('メッセージ')と呼べる構造が一般的 framer-motionやCSSアニメーションを使って、出没時のイージングを入れると高品質に見える- A11y要件の
aria-liveは、DOMに追加された瞬間でないと読み上げられないことがあるため、Toastのラッパー自体は常にレンダリングしておき、中身を動的に注入する手法が確実
11. 関連リンク
- 関連するUIデザイン原則: フィードバック (Feedback), 明瞭性と確実性 (Clarity & Certainty), エラーの回復 (Error Recovery)
- 用語集（定義）: アクセシビリティ (Accessibility)
- 関連するUIコンポーネント（横）: AlertDialog（警告ダイアログ）
12. まとめ
Toastは「通知スパム」にならないさじ加減がすべてです。ユーザーの作業を止めないという最大の恩恵を生かすため、「短い文言」「適切な表示時間」、そして「見逃されても構わない情報に限定する」という基本方針を守りましょう。
