Dart 3 パターンマッチングの罠：網羅性チェックの限界とランタイム防壁の設計思想
Dart 3における `switch` 式とパターンマッチングの導入は、静的解析の安全性劇的に引き上げた。特に `sealed` クラスを用いた代数的データ型（ADT）の網羅性チェック（Exhaustiveness Checking）は、開発者が状態のハンドリング漏れを起こす余地をコンパイル時に完全に塞ぐ。
しかし、大規模な分散システムや外部パッケージとの境界領域において、この「完璧な安全網」はしばしばエンジニアの足元をすくう罠に変貌する。
本稿では、Dartコンパイラ（CFE: Common Front End）およびDart VMの型システムがどのように網羅性を評価しているかを解き明かし、外部要因による網羅性破綻がいかにして未定義動作（Undefined Behaviorに近いランタイム例外）を引き起こすか、そしてそれを防ぐための厳格なランタイム防壁の設計手法を解説する。
—
1. コンパイラはなぜ「網羅性」を見失うのか？
Dart 3の網羅性チェックは、CFO（Common Front End）の静的型解析フェーズにおいて、指定されたオブジェクトの静的型（Static Type）が持つサブタイプの空間を完全に列挙できるという前提のもとに成り立っている。
ここで致命的な問題が発生する。「外部パッケージで定義された `sealed` クラス」である。
// 外部パッケージ (package:remote_api) のコード
lib/remote_api.dart:
sealed class ApiResponse {}
final class Success extends ApiResponse {}
final class Error extends ApiResponse {}
このパッケージを依存関係に含めたあなたのアプリケーションコードで、以下のような `switch` 式を書いたとする。
// あなたのアプリケーションコード
String handleResponse(ApiResponse response) {
return switch (response) {
Success() => ‘成功’,
Error() => ‘失敗’,
// コンパイラはここで「網羅されている」と判断する
};
}
一見して問題ないように見える。だが、もしパッケージの作者が将来のバージョンアップ（Semantic Versioningの範囲内、あるいは破壊的変更）で、新しいサブタイプ `Loading` を追加したらどうなるか？
// 外部パッケージの v2.0.0 で追加されたとする
final class Loading extends ApiResponse {}
あなたがコードを再コンパイル（Rebuild）せず、依存関係のバイナリ（あるいはAOTコンパイル済みのモジュール）だけが差し替わった場合、あるいはパッケージの境界を越えて予期せぬサブタイプが流入した場合、Dart VMのランタイムは `SwitchExpressionError` を送出する。
ゼロコスト抽象化の代償とAOTの現実
AOT（Ahead-Of-Time）コンパイル環境において、Dartの `switch` 式は最適化され、ジャンプテーブルや効率的なインラインキャッシュ、あるいは決定木（Decision Tree）にコンパイルされる。
コンパイラは「この階層構造のサブタイプはこれらすべてである」という前提（Closed World Assumptionの局所的適用）のもとでコード生成を行うため、想定外の型インスタンスがランタイムのレジスタにロードされた瞬間、安全機構は崩壊し、Isolateは即座にクラッシュ（Uncaught Exceptionによる強制終了）に至る。
—
2. 「安全なデフォルトケース」という名のアンチパターン
このエラーを防ぐために、安易に `_`（ワイルドカードパターン）によるデフォルトケースを追加することは、静的解析の恩恵を自ら捨てる行為に等しい。
// 危険なアンチパターン
String handleResponseUnsafe(ApiResponse response) {
return switch (response) {
Success() => ‘成功’,
Error() => ‘失敗’,
_ => ‘不明な状態’, // 👈 新しい型が追加されてもコンパイラは警告しない！
};
}
このアプローチを取ると、将来APIが拡張されてもコンパイラはエラーを吐かないため、「新しい状態に対するビジネスロジックの書き忘れ」がサイレントにバグとして本番環境へデプロイされる。これは静的型付け言語の敗北である。
—
3. 実践：網羅性を維持しつつ「未知の未来」を防御する設計パターン
では、外部要因による拡張性と、コンパイル時安全性を両立させるにはどうすればよいか。
答えは、「型システムによる網羅性」と「ランタイムにおける拡張ポイント（Extensibility）」の多層防御（Defense in Depth）にある。
以下のコードは、シニアエンジニアがプロダクション環境で実装すべき、堅牢なハンドリングの模範解答である。
import ‘meta_guard.dart’; // 架空の外部パッケージ
sealed class ApiResponse {}
final class Success extends ApiResponse {
final String data;
Success(this.data);
}
final class Error extends ApiResponse {
final Object error;
Error(this.error);
}
/// 【重要】
/// 将来追加されるかもしれない未知のサブタイプ、あるいは
/// ライブラリのバージョン不整合による予期せぬ型を安全にフォールバックさせるための
/// 「拡張用エスケープハッチ」を明示的に定義する。
final class UnknownResponse extends ApiResponse {
final ApiResponse raw;
UnknownResponse(this.raw);
}
String processApiResponse(ApiResponse response) {
// 1. まず標準的な網羅的 switch 式を展開する
// ここで UnknownResponse を含めることで、「未知の型が流れてきた場合」のルートを
// コンパイル時に強制的に意識させる。
return switch (response) {
Success(:final data) => ‘Data: $data’,
Error(:final error) => ‘Error: $error’,
// 2. ライブラリ側の拡張や、シリアライズ層の不整合による未知の型をキャッチする
UnknownResponse(:final raw) => _handleUnknown(raw),
};
}
/// 外部からの予期せぬ入力や、バージョン不整合を安全にラップするファクトリー
ApiResponse sanitizeApiResponse(ApiResponse input) {
// 万が一、switchのパターンにマッチしない（コンパイラの想定外のサブタイプ）が
// 実行時に流入した場合の防御壁
if (input is! Success && input is! Error) {
return UnknownResponse(input);
}
return input;
}
String _handleUnknown(ApiResponse raw) {
// ログ基盤への送信、Sentry等へのレポート、フォールバックUIの返却など
// アプリケーションがクラッシュするのを防ぎ、優雅に縮退運行（Graceful Degradation）させる
return ‘System Notice: 互換性のないレスポンス構造を受信しました (${raw.runtimeType})’;
}
この設計がVMおよびIsolateレイヤで意味するもの
1. CFE（Common Front End）レベルの完全性:
`UnknownResponse` を `sealed` 階層に組み込む（あるいはライブラリ境界でラップする）ことで、コンパイラは「全てのケースが網羅されている」と判定しつつ、開発者に対して「未知の型への備え」をコード上で強制する。
2. Isolateの耐障害性:
ネットワーク層やIPC（Isolate間通信）のシリアライズ境界において、古いバージョンのクライアントが新しいサーバーからのペイロード（未知のenumやサブタイプ）を受信した場合でも、`SwitchExpressionError` によるIsolate全体のクラッシュを防ぐ。
3. メモリとキャッシュの効率性:
パターンマッチングはDart VM内で高度に最適化されたジャンプコードに変換されるため、余計な `if-else` チェーンを書くよりもCPUの分岐予測（Branch Prediction）のミスヒット率を最小限に抑えることができる。
—
4. チーフアーキテクトからの提言
言語仕様の進化に追従するだけでなく、「コンパイラが何を保証し、何保証しないのか」の境界線を正確に把握すること。それがシニアエンジニアとそうでない者を分かつ決定的な差である。
外部依存、動的リンク、非同期メッセージング、そしてシリアライズの境界。システムが外部世界と接続するすべてのポイントにおいて、静的な網羅性チェック過信せず、ランタイムの防壁をコードの構造体として組み込め。
コードは美しく、そして鉄の意志の如く堅牢でなければならない。