開発チームの皆さん、コードレビューお疲れ様です。テクニカルリードの私だ。
本日は、Dart 3で導入された「switch式（Switch Expressions）」と、それがもたらす網羅性チェック（Exhaustiveness Checking）を用いた堅牢なコンポーネント設計について、実務の現場ですぐに応用できるレベルで徹底解説する。
Webフロントエンド開発、特にFlutterや複雑な非同期APIの状態管理において、「APIレスポンスの型が増えたのに、UI側のハンドリング漏れでクラッシュした」というインシデントを踏んだ経験はないだろうか？
if-elseの連打や、従来のステートメントとしての `switch` では、新しい状態を追加したときにコンパイラは何も警告してくれない。結果として、テスト漏れや本番環境でのランタイムエラー（NullPointerExceptionや予期せぬStateError）の温床になってきた。
Dart 3のコンパイラとパターンマッチング機構を正しく理解すれば、「状態の網羅漏れをコンパイルエラーとして絶対に検知させる」極めて堅牢なアーキテクチャを構築できる。今日はその極意を伝授しよう。
—
なぜ従来の `switch` では不十分なのか
まず、アーキテクチャの観点から「何が問題で、どう進化すべきか」を共有する。
従来の `switch` 文は、あくまで「文（Statement）」であり、処理の制御フロー分岐に過ぎなかった。そのため、以下のような問題があった。
1. フォールスルー（Fall-through）の危険性: `break` の書き忘れによる意図しないバグ。
2. 網羅性の欠如: `enum` や `sealed class` の要素が増えても、コンパイラは `default` 節があれば沈黙し、将来の修正漏れを素通りさせる。
3. 副作用の温床: 変数への代入を伴う処理で、イミュータブル（不変）なデータフローを作りづらい。
Dart 3の `switch` 式 は、これらを根底から覆す。式（Expression）であるため値として評価され、さらにDart VMの静的解析器は、対象の型が持つすべてのバリエーション（サブタイプ）が網羅されているかをコンパイル時に厳密に検証する。`default` や `_`（ワイルドカード）に頼った瞬間、この網羅性チェックの恩恵は失われる。ここに設計の肝がある。
—
実践：API連携とコンポーネント状態管理のプロダクションコード
では、実際のWeb/Flutterフロントエンド開発を想定したコードを見ていこう。
非同期APIから返る「ユーザー認証状態」を表現するモデルと、それに応じたUIコンポーネントをレンダリングする設計例だ。
ここで、`sealed class`（シールデッドクラス）と `switch` 式を組み合わせる。
import ‘package:meta/meta.dart’;
// ==========================================
// 1. ドメインモデルの定義 (Sealed Class)
// ==========================================
// sealed修飾子により、このファイル外で勝手にサブクラス化されることを防ぎ、
// コンパイラがすべての派生型を完全に把握できるようにする。
sealed class AuthState {}
class AuthInitial extends AuthState {}
class AuthLoading extends AuthState {}
class AuthAuthenticated extends AuthState {
final String userId;
final String role;
AuthAuthenticated({required this.userId, required this.role});
}
class AuthError extends AuthState {
final String message;
final int errorCode;
AuthError({required this.message, required this.errorCode});
}
// ==========================================
// 2. UIレンダリングロジック（switch式による網羅性チェック）
// ==========================================
String renderAuthUI(AuthState state) {
// Dart 3のswitch式。代入の右辺として直接記述し、網羅性を強制する。
return switch (state) {
// 1. 初期状態
AuthInitial() => ‘アプリを初期化中…’,
// 2. ローディング状態
AuthLoading() => ‘読み込み中（スピーカー表示）’,
// 3. 認証成功（パターンマッチングでプロパティも直接抽出）
AuthAuthenticated(:final userId, :final role) when role == ‘admin’ =>
‘管理画面へようこそ: $userId’,
AuthAuthenticated(:final userId) =>
‘ホーム画面へようこそ: $userId’,
// 4. エラー状態
AuthError(:final message, errorCode: 401) =>
‘セッションが切れました。再ログインしてください: $message’,
AuthError(:final message) =>
‘エラーが発生しました: $message’,
// 【重要】ここに `default:` や `_ =>` を書いてはならない。
// 書いてしまうと、将来新しい状態クラスを追加した際にコンパイラがエラーを吐かなくなる。
};
}
void main() {
// 実行例
AuthState currentState = AuthAuthenticated(userId: ‘user_999’, role: ‘admin’);
print(renderAuthUI(currentState));
// 出力: 管理画面へようこそ: user_999
}
このコードの優れている点（アーキテクチャの解説）
1. ワイルドカード・`default` の排除:
あえて `_ =>` や `default` を記述していない。もし明日、仕様変更で `AuthMfaRequired`（二要素認証待ち）という新しい状態を `sealed class AuthState` の下に生やした場合、Dartのコンパイラは即座にビルドを失敗（コンパイルエラー）させ、開発者に「`renderAuthUI` 内で新しい状態がハンドリングされていません」と警告する。 これにより、修正漏れによる本番障害を100% preven（予防）できる。
2. 高度なパターンマッチングとガード節 (`when`):
`AuthAuthenticated(:final userId, :final role) when role == ‘admin’` のように、型チェックと同時にプロパティの分解（Destructuring）を行い、さらに `when` 節で条件分岐まで1つの式にインライン化している。可読性が劇的に高い。
—
パフォーマンスとコンパイル時の挙動についての知見
「こんなに複雑なパターンマッチングや網羅性チェックを毎フレーム（例えばFlutterの60fps/120fpsの描画ループで）実行したら、パフォーマンスに影響があるのではないか？」と懸念する鋭いエンジニアもいるだろう。
安心してほしい。Dart AOT（Ahead-Of-Time）コンパイラおよびJITコンパイラにおいて、Dart 3の `switch` 式は高度に最適化される。
- ジャンプテーブル（Jump Tables） / 決定木（Decision Trees）へのコンパイル:
型タグや定数に基づく分岐は、人間が書く愚直な `if-else` チェーンよりも効率的な機械語（ネイティブコード）にコンパイルされる。
- ゼロ・コスト・абстракции（Zero-cost abstractions）:
パターンマッチングやプロパティの分解はランタイムに動的なリフレクションを行っているわけではない。すべて静的に解決されるため、ランタイムオーバヘッドは実質的にゼロである。
—
テクニカルリードからの設計指針まとめ
1. 網羅性が必要な場所では `sealed class` と `switch` 式をセットで使うこと。
状態管理（BLoC, Riverpod, ReduxなどのState）、APIレスポンスのパース結果、UIの表示モードなどのドメインロジックには必ず適用せよ。
2. `default` や `_` を「思考停止の逃げ道」として使わない。
例外的にフォールバックが必要な場合を除き、ビジネスロジックの中核で `_` を使うことは、網羅性チェックという強力な安全装置を自らドブに捨てる行為と同義である。
3. コードレビュー時のチェックポイント:
プルリクエストで `sealed class` に新しいサブタイプが追加された際、関連するすべての `switch` 式にケースが追加されているかをレビュアーは厳しく確認すること。
Dartは単なる「書きやすい言語」から、厳格な型システムで大規模開発を守る「堅牢な言語」へと進化を遂げた。この言語の重みとコンパイラの意図を正しく理解し、保守性の高い美しいプロダクションコードを共に組み上げていこう。