はじめに 🌟
Fluent UI 2 の Switch は、見た目は小さなトグルですが、実務では「いつ反映される設定か」を明確に伝える重要なコンポーネントです。
特に Checkbox と混同すると、オンにした瞬間に反映されるのか、保存ボタンでまとめて反映されるのかが曖昧になり、事故の原因になります。
この記事では、Fluent UI 2 の Switch を中心に、次を整理します。
- Fluent UI 2 とは何か
- これまでの Fluent UI 2 シリーズ記事(リポジトリ内既存分)の紹介
- Switch と Checkbox の違い(特に即時適用と明示的送信の違い)
- Fluent UI Blazor と Fluent UI 2(React / Web Components 文脈)における Checkbox の違い
- Switch のガイダンス / レイアウト / アクセシビリティ / コンテンツ設計
参照した一次情報:
- Fluent UI 2 Switch usage
- Fluent UI 2 Checkbox usage
- Fluent UI Blazor: Switch
- Fluent UI Web Components: Switch
- WAI-ARIA APG: Switch Pattern
- WAI-ARIA APG: Checkbox Pattern
Fluent UI 2 とは
Fluent UI 2 は、Microsoft Fluent 2 デザインシステムに沿って UI を設計・実装するためのガイダンスとコンポーネント群です。
見た目をそろえるだけではなく、情報設計、操作の一貫性、アクセシビリティ、コンテンツ設計まで一体で扱うことを重視します。
そのため Switch も「On/Off の見た目」だけではなく、次を満たすように設計します。
- 変更タイミング(即時適用か、後で送信か)が利用者に伝わる
- ラベルだけで意味が通る
- キーボードや支援技術でも状態変化を把握できる
Fluent デザインシステム全体像は、公式サイト(Fluent 2)が基点になります。
この前提を押さえたうえで、まず Switch と Checkbox の違いを確認します。
これまでの Fluent UI 2 シリーズ記事一覧 📚
※ 本記事執筆時点で、public/ 内の既存 Fluent UI 2 関連記事を調査して列挙しています。
- Fluent UI 2 の Accordion を理解する — 情報設計・アクセシビリティ・React 実装 — 折りたたみ情報の設計基礎
- Fluent UI 2 の Breadcrumb を理解する — Fluent UI Blazor 5 との対応とアクセシビリティ — 階層ナビゲーションの導線設計
- Fluent UI 2 の Card を理解する — React と Fluent UI Blazor の違い — 情報ブロックの意味づけ
- Fluent UI 2 の Dropdown を理解する — Fluent UI Blazor 5 の近縁コンポーネント比較とアクセシビリティ — 選択 UI の判断軸
- Fluent UI 2 の Checkbox を理解する — React と Fluent UI Blazor v5 の違い — 複数選択と状態管理
- Fluent UI 2 の Select を理解する — Dropdown / Combobox / Field との使い分けと Fluent UI Blazor 5 比較 — シンプル選択の適用範囲
- Fluent UI 2 の Button を理解する — 種類・レイアウト・アクセシビリティ・Blazor 5 比較 — アクション設計の基本
- Fluent UI 2 の Searchbox を理解する — Fluent UI Blazor 5 との比較とアクセシビリティ・コンテンツ設計 — 検索入力体験の設計
- Fluent UI 2 の Label を理解する — Fluent UI Blazor 5 と比較するラベル設計の基礎 — ラベル文言の原則
- Fluent UI 2 の Popover を理解する — Fluent UI Blazor 5 との比較と Tooltip / Dialog の使い分け — 軽量オーバーレイ設計
- Fluent UI 2 の Input を理解する — Textarea・Fluent UI Blazor TextInput / Number 比較とアクセシビリティ — 入力欄の使い分け
- Fluent UI 2 の Divider を理解する — Fluent UI Blazor 5 との比較 — 視覚的な区切り方
- Fluent UI 2 で始めるアクセシビリティ実装 — キーボード操作・支援技術・WCAG 2.1 の実践ガイド — a11y 実装の土台
- Fluent UI 2 の Image を理解する — Fluent UI Blazor 5 と比較しながらレイアウトとアクセシビリティを整理する — 画像表現の注意点
- Fluent UI 2 の Rating を理解する — Fluent UI Blazor 5 と比較する評価 UI の設計とアクセシビリティ — 評価入力の設計
- Fluent UI 2 の Menu を理解する — Fluent UI Blazor 5 と比較するガイダンス・動作・アクセシビリティ — コマンド選択の導線
- Fluent UI 2 の Nav を理解する — ガイダンス・動作・レイアウト・アクセシビリティと Fluent UI Blazor 5 比較 — 主要ナビ設計
- Fluent UI 2 の Spin button を理解する — Slider との違い、Fluent UI Blazor 5 の Number / StepButtons 比較とアクセシビリティ — 段階入力の実務整理(リポジトリ版)
- Fluent UI 2 の Icon を理解する — Fluent UI Blazor の FluentIcon 比較とアクセシビリティ — 記号表現の意味づけ
- Fluent UI 2 の Radio Group を理解する — Fluent UI Blazor 5 との比較・使い分け・アクセシビリティ — 単一選択の原則
- Fluent UI 2 の Link を理解する — Fluent UI Blazor 5 と比較するリンク設計とアクセシビリティ — リンク文言設計
- Fluent UI 2 の MessageBar を理解する — Fluent UI Blazor 5 と比較する機能・使用方法・アクセシビリティ — 状態通知の優先度
- Fluent UI 2 の Avatar を整理しつつ Fluent UI Blazor 5 でどう実装するか — 人物情報の表現粒度
- Fluent UI 2 の Progress Bar を理解する — Fluent UI Blazor 5 比較と Skeleton 使い分け・アクセシビリティ — 進捗可視化の判断基準
- Fluent UI 2 の Badge を理解する — Fluent UI Blazor 5 との比較と実装ポイント — 補助情報の強調
- Fluent UI 2 のアクセシビリティを色から読む ─ WCAG 2.1 と対比しながら整理する — 色依存の回避
- Fluent UI 2 の Skeleton を理解する — ProgressBar・Spinner との使い分けと Fluent UI Blazor 5 比較 — ローディング体験設計
- Fluent UI 2 の Drawer を理解する — Tooltip / Popover / Dialog との使い分けと Fluent UI Blazor 5 比較 — 補助面の使い分け
- Fluent UI 2 の Spinner を理解する — Progress Bar / Skeleton との使い分けと Fluent UI Blazor 5 比較 — 待機表示の整理(リポジトリ版)
- Fluent UI 2 の Combobox を理解する — Fluent UI Blazor 5 との比較と使い分け — 入力兼選択の整理
- Fluent UI 2 の Field を理解する — Fluent UI Blazor 5 と比較する入力設計の基礎 — 入力群の責務分離
- Fluent UI 2 の Slider を理解する — Input/Number 比較と Fluent UI Blazor 5 との違い、アクセシビリティとコンテンツ設計 — 概算入力の設計
- Fluent UI 2 の Persona を理解する — ガイダンス・レイアウト・アクセシビリティ・Fluent UI Blazor 5 比較 — ユーザー表現設計
- Fluent UI 2 の Dialog を理解する — React と Fluent UI Blazor 5 の違いと使い分け — モーダル中断設計
今回のゴール ✅
- ✅ Switch と Checkbox の設計意図を誤解なく区別できる
- ✅ 「即時適用」と「明示的送信」の違いを説明できる
- ✅ Fluent UI Blazor と Fluent UI 2(React / Web Components)で Checkbox の扱いの違いを説明できる
- ✅ Switch の a11y / コンテンツ設計を実務レベルでチェックできる
Switch と Checkbox の違い(最重要)
Fluent UI 2 の文脈では、次の違いが実務上の分岐点です。
| 観点 | Switch | Checkbox |
|---|---|---|
| ⚡ 反映タイミング | 即時適用(切り替えた瞬間に状態を反映) | 送信ステップ向き(Fluent UI 2 ガイドでは選択後の送信を伴う文脈が中心。単独トグル用途もあり) |
| 🎯 主用途 | 機能の有効/無効、表示切り替え、ライブ設定 | 複数選択、同意、後でまとめて確定する選択 |
| 🧠 メンタルモデル | 「今この設定を切り替える」 | 「候補を選んでから確定する」 |
| 🧾 画面設計 | 切り替え後の影響がすぐ見える配置が向く | フォーム文脈・送信ボタンとの組み合わせが向く |
| ♿ 状態伝達 | On/Off の現在状態を明確に提示 | checked/unchecked(必要なら mixed)を提示 |
「保存ボタンを押すまで反映されない設定」に Switch を使うと、利用者は即時反映だと誤解しやすくなります。
逆に「切り替えた瞬間に反映される設定」に Checkbox を使うと、反映タイミングが曖昧になります。
即時適用と明示的送信の使い分け
- 即時適用(Switch)
例: ダークモード、通知の有効化、サイドバー表示切り替え - 明示的送信(Checkbox)
例: 一括削除対象の選択、プロフィール公開項目の選択、購読カテゴリ選択
実装レビューでは、次を必ず確認しておくと安全です。
- 操作直後にシステム状態が変わるなら Switch
- 複数項目を選んで最後に送信するなら Checkbox
- 切り替え失敗時の戻し方(楽観更新か、結果待ちか)を UI で説明できているか
補論: Fluent UI Blazor と Fluent UI 2(React / Web Components)での Checkbox の違い
Checkbox は同じ名前でも、設計の重心が少し違います。
| 観点 | Fluent UI 2(React / Web Components) | Fluent UI Blazor |
|---|---|---|
| 🧭 重心 | ガイドライン主導(いつ使うか・どう伝えるか) | フォーム実装主導(バインド・検証・状態管理) |
| 🧩 実装スタイル | React は Checkbox を使用して構成し、Web Components は <fluent-checkbox> を直接配置 |
FluentCheckbox に @bind-Value などを設定 |
| 🔁 状態モデル | 基本は二値、文脈に応じた表現を重視 |
Value + CheckState / ThreeState で制御しやすい |
| 🏷️ ラベル設計 | ラベル文言・グループ説明のガイドが中心 |
Label / AriaLabel / Name など API 設定が中心 |
| 🧪 実務の着眼点 | 誤解しない操作モデルを選ぶ | 入力バインドと送信フローを安全に組む |
使用方法の違い(コードイメージ)
import { Checkbox } from "@fluentui/react-components";
export function Preferences() {
return (
<>
<Checkbox label="メール通知を受け取る" />
<Checkbox label="製品アップデートを受け取る" />
</>
);
}
<fluent-checkbox>メール通知を受け取る</fluent-checkbox>
<fluent-checkbox>製品アップデートを受け取る</fluent-checkbox>
<FluentCheckbox @bind-Value="ReceiveMail" Label="メール通知を受け取る" />
<FluentCheckbox @bind-Value="ReceiveProductNews" Label="製品アップデートを受け取る" />
@code {
bool ReceiveMail = true;
bool ReceiveProductNews = false;
}
Fluent UI 2 Switch のガイダンス
Switch は「状態をただ選ぶ」よりも、「設定を切り替える」文脈に向いています。
設計時は次を先に決めると迷いにくいです。
- 切り替えた瞬間に何が変わるか(表示、動作、通知など)
- 変更結果をどこで確認できるか(直下、トースト、補助テキスト)
- 失敗時にどう戻すか(自動で戻す / エラー表示して再試行)
Switch を使うべき場面
- 即時に有効/無効を切り替える設定
- 現在状態(On/Off)が利用者の目的に直結する設定
- 反映結果をその場で把握できる設定
Switch を避けるべき場面
- 最後にまとめて送信するフォーム項目
- 複数候補から複数選ぶ選択
- 変更に確認ダイアログが必須で、即時反映しない操作
レイアウト(Layout)
Switch はラベルとのセットで意味が決まるため、レイアウトは「見た目」より「意味伝達」を優先します。
- ラベルは必ず近接させる(離して配置しない)
- 複数の Switch を縦に並べるときは、間隔と説明文の規則を統一する
- 設定カテゴリごとにグルーピングし、見出しで文脈を先に示す
- 即時反映で副作用がある項目は、補助説明をすぐ下に置く
import { Switch, Field } from "@fluentui/react-components";
export const NotificationSettings = () => (
<>
<Field label="メール通知">
<Switch label="障害通知をすぐ受け取る" />
</Field>
<Field label="表示設定">
<Switch label="ダークモードを有効にする" />
</Field>
</>
);
アクセシビリティ(厚め)♿
Switch は二値コントロール(binary control)なので、支援技術に対して「何の設定が」「今どういう状態か」を正しく伝える必要があります。
実務では次をチェックリスト化すると品質が安定します。
1) role と状態属性
-
role="switch"を使う - 状態は
aria-checked="true|false"で伝える -
switchではmixedを使わない(必要なら Checkbox を検討)
2) ラベル関連付け
- 視覚ラベルとプログラム上の名前を一致させる
-
aria-labelのみで済ませず、可能なら視覚ラベルを表示する - ラベル文言だけで「オンで何が起きるか」が伝わるようにする
3) キーボード操作
-
Tabでフォーカス到達できること -
Spaceで切り替えできること - フォーカス可視化(outline / ring)を消さないこと
4) コントラストと状態知覚
- On/Off を色だけで区別しない(位置・テキスト・補助説明も併用)
- フォーカス表示のコントラストを確保する
- Disabled 状態でも「操作不可」であることが分かる視覚差を持たせる
5) 状態変化の伝達
- 切り替え後に重要な副作用がある場合は補助メッセージで伝える
- 非同期保存なら「保存中」「保存失敗」の状態を明示する
- 必要に応じて
aria-live領域で結果通知する
スクリーンリーダー検証では、「フォーカス時の読み上げ(ラベル + 状態)」と「切り替え後の状態更新」が連続して確認できるかを必ず見てください。
コンテンツ設計(厚め)📝
Switch の文言は、操作の正誤を左右します。実務では次が効きます。
1) 肯定形ラベルを使う
- 良い例:
通知を有効にする - 悪い例:
通知を無効にしない
否定形は、On/Off の意味を頭の中で反転する必要があり、誤操作につながります。
2) 文言だけで状態が判別できるようにする
- ラベルを読んだだけで「On にすると何が起きるか」が分かる
-
オン/オフのテキスト依存ではなく、機能名をラベルに含める
3) 曖昧表現を避ける
- NG:
有効化 - OK:
メール通知を有効にする
4) 影響範囲を書く
- 重要設定には補助文言を付ける
例:オンにすると全プロジェクトへ即時反映されます
5) 連続配置時の文体を統一する
- すべて「〜する」で統一する
- 名詞止めと動詞形を混在させない
- 同一グループ内で主語の粒度をそろえる
Switch と Checkbox を誤用しないための実務チェック
リリース前レビューで、次の 5 つを通すと事故を減らせます。
- この項目は切り替え直後に反映されるか
- 反映タイミングを UI 文言で説明できているか
- 後で送信する項目を Switch にしていないか
- ラベルを読んだだけで On/Off の意味が分かるか
- キーボード操作と読み上げ結果が確認できているか
まとめ / おわりに
Switch と Checkbox の差は、見た目よりも反映タイミングにあります。
即時適用なら Switch、明示的送信なら Checkbox。この軸を守るだけでも、UI の誤解は大きく減らせます。
また、Fluent UI 2 ではガイドライン主導、Fluent UI Blazor では API 主導で実装する場面が多いため、同じ「Checkbox」でも設計の着眼点が変わります。
最後は必ず、a11y(role/状態/ラベル/キーボード)とコンテンツ(肯定形・曖昧回避・影響範囲明示)まで含めて確認してみてください。