保存できた・送れなかった・メンテナンスがある、といったシステムから利用者への知らせの出し方です。部品は インラインメッセージ・アラート・モーダル・入力欄のエラー（field-error-text）をそのまま使い、このページではどの知らせを・どこに・どの色で出すかを決めます。画面の隅に出て数秒で消えるトースト／スナックバーは意図的に用意していません（トーストを用意しない理由）。

3 つの原則

知らせが届かない典型は「見ていない場所に出た」「読む前に消えた」「読み上げられなかった」の 3 つです。原則はその裏返しです。

知らせの種類

知らせは、きっかけによって 3 種類に分かれます。まず種類を決めると、使う部品が決まります。

色（テーマ）の選び方

色は知らせの内容で選びます。見た目の強さで選ばないでください。色だけでは意味が伝わらないため、どのテーマも専用のアイコンと文言がセットです。

置き場所

置き場所は、知らせが何に関わるかで決まります。迷ったら、利用者が操作した場所に近い方を選びます。

操作した場所から離れた所に出してよいのは、そこへフォーカスを移すときだけです。視線も読み上げも知らせへ移るので、見逃されません。

• 送信してエラーが 3 件以上 — フォームの上にアラート（negative）でまとめを出し、まとめへフォーカスを移す。各入力欄の真下のエラーもそのまま出す（まとめだけにしない）。1〜2 件なら、まとめは出さず最初のエラーの入力欄へフォーカスを移す（フォームの検証とエラー）
• 作業を止めて判断を求めるとき — モーダルでフォーカスを預かり、閉じたら呼び出し元へ戻す

それ以外で、フォーカスを移さずに離れた所へ出すのはやめます（下の Don't）。

成功を知らせるかの決め方

成功の知らせは控えめに使います。結果が画面を見て分かるなら、メッセージを足しても騒がしくなるだけです。上から順に当てはめます。

失敗の伝え方の決め方

失敗は必ず伝えます。どの部品でも、何が起きたかと次に何をすればよいか（直す・もう一度・時間をおく・問い合わせる）を書きます。原因が分からない失敗でも、次の手は書けます。上から順に当てはめます。

行き先の早見表

ここまでをまとめると、知らせの行き先は次の 5 つです。迷ったら「出さない」と「操作した場所の直近」に寄せます。

トースト／スナックバーを用意しない理由

画面の隅に固定して数秒で消える通知は、Material Design ではスナックバー、Android ではトーストと呼ばれ、Web でも広く使われています。relay はこれをコンポーネントとして用意しません。仕様そのものが次の達成基準とぶつかり、DS で作ると違反の入口を配ることになるからです。

• 見逃される — 隅に出る小さな通知は、繰り返し見るうちに広告のように無視される。本当に伝えるべき失敗も同じように流れる
• 誤って閉じる — スワイプや近くのタップで消える。「元に戻す」を載せると、消えた時点で取り消す機会もなくなる
• 重さが混ざる — 成功も失敗も同じ位置・同じ見た目で流れ、重大な失敗が「いつもの通知」に埋もれる
• 振る舞いがそろわない — 表示時間・重ね方・ボタン・閉じるの有無がプロダクトごとに揺れ、見た目をそろえても使い心地がそろわない

「それでもトーストが要る」と思ったときの読み替え

アクセシビリティ

部品を選んだあと、プロダクト側で確かめる項目です。各コンポーネントの「アクセシビリティ」タブと MCP get_component の同じ名前の節にも同じ内容があります。