開発チームの皆さん、お疲れ様です。テクニカルリードの私だ。
本日は、コードレビューで最も見落とされがちでありながら、ランタイムのパフォーマンスとアプリケーションの堅牢性に致命的な影響を与えるテーマについて話をしよう。
Dart 3で導入されたパターンマッチングと `switch` 表現（および `case` 句）は、私たちのコーディングスタイルを劇的にモダンにした。しかし、その強力な機能の一つである「ガード句（`when`）」を、何気なく「便利なif文の代わり」として書いていないだろうか？
フロントエンド開発、複雑なUIコンポーネントの状態管理、そして非同期API連携のレスポンスハンドリングにおいて、ガード句の評価メカニズムを誤ると、予期せぬパフォーマンス劣化や、最悪の場合はバグの温床となる。
今回は、Dart VMがガード句をどのように評価し、それが実行時にどう作用するのか。その深層を紐解きつつ、実務で即座に使える美しいプロダクションコードの設計パターンを伝授する。
—
1. Dart VMにおけるガード句（`when`）の評価メカニズム
まず、コンパイラとVMの視点に立とう。
Dart 3の `switch` パターンマッチングにおいて、パターン（構造的一致）の検証と、`when` キーワードに続くガード句（Boolean式）の評価は、明確にフェーズが分かれている。
1. 構造的マッチング（Structural Matching）: オブジェクトの型、プロパティ、形状がパターンに一致するかをO(1)〜O(N)で高速に判定する。
2. ガード句の評価（Guard Evaluation）: 構造的マッチングが成功したその瞬間に、`when` の条件式が評価される。
ここで重要なのは、「ガード句は構造が一致した後に評価される遅延評価（Lazy Evaluation）的性格を持つが、一度マッチ候補になれば必ず評価される」という点だ。そして、ここにパフォーマンスの罠がある。
「重い計算」をガード句に含めた場合の致命傷
例えば、非同期APIから受け取った膨大なJSONツリーや、フロントエンドの複雑な状態（State）を `switch` でハンドリングする際、以下のようなコードを書いたことはないか？
// 【アンチパターン】ガード句の中で重い処理や副作用を行っている例
switch (apiResponse) {
case Success(data: final items) when _isComplexValidatonPassed(items):
// 処理A
break;
case Success(data: final items) when items.any((i) => _heavyComputation(i)):
// 処理B
break;
default:
// フォールバック
}
このコードの何が問題か？
もし `_heavyComputation(i)` がO(N)のコストを持つ計算であった場合、Dart VMはパターンマッチの候補にヒットするたびに（場合によっては評価順序の最適化の過程で複数回）この重い関数を実行する。
さらに最悪なのは、ガード句の中で副作用（Stateの書き換えやロギングなど）を行っている場合だ。ガード句の評価順序やコンパイラの最適化（JIT/AOTによる分岐予測や並べ替え）によって、「意図したタイミングで1回だけ呼ばれるはずの関数が、評価の過程でスキップされたり複数回評価されたりする」という、デバッグ泣かせの非決定的バグを引き起こす。
> リードからの鉄則:
> ガード句（`when`）は、純粋関数（Pure Function）による軽量な条件判定のみに限定せよ。重い計算や副作用は、パターンマッチに入る前に事前計算（Preprocessing）すべきである。
—
2. 実務で使える：堅牢で美しいプロダクションコード設計
では、非同期API連携や複雑なコンポーネントの状態分岐において、どのようにコードを設計すべきか。
以下のプロダクションコードを見てほしい。ここでは、APIからのレスポンス状態に応じてUIコンポーネントの振る舞いとキャッシュ戦略を制御する堅牢なパターンを提示する。
import ‘dart:async’;
// — ドメインモデルの定義 —
sealed class ApiResult
const ApiResult();
}
class Success
final T data;
final DateTime receivedAt;
const Success(this.data, this.receivedAt);
}
class Error extends ApiResult
class Loading extends ApiResult
const Loading();
}
// — ビューモデル / コンポーネントの状態 —
enum UiState { idle, syncing, stale, error }
/// 【推奨設計】重い判定ロジックはガード句に書かず、事前にドメイン層や
/// ユーティリティ関数で安全に評価・キャッシュしておく。
class ComponentPresenter {
/// ガード句で使用する判定は、副作用のない軽量なものに絞る
bool _isFresh(DateTime receivedAt) {
return DateTime.now().difference(receivedAt).inMinutes < 5;
}
/// メインのハンドリングメソッド
UiState evaluateComponentState(ApiResult
// 【ベストプラクティス】
// パターンマッチに入る前に、必要な前処理やプロパティの抽出を完了させておく。
return switch (result) {
// 1. ローディング中は即座に同期状態を返す
Loading() => UiState.syncing,
// 2. エラー時はステータスコードで安全に分岐（ガード句なしでパターンで吸い取る）
Error(statusCode: >= 500) => UiState.error,
Error(statusCode: 401) => UiState.error, // 認証切れなどの特殊処理へ誘導可能
// 3. 成功時：軽量なガード句（_isFresh）のみを適用
Success(data: final items, receivedAt: final time)
when items.isNotEmpty && _isFresh(time) =>
UiState.idle,
// 4. データが古い、または空の場合のフォールバック
Success() => UiState.stale,
// sealedクラスのため、defaultは不要。網羅性が保証される。
};
}
}
この設計が優れている理由
1. 網羅性（Exhaustiveness）の担保:
`ApiResult` を `sealed class` にしているため、Dartのコンパイラが `switch` の網羅性を完全に静的チェックしてくれる。将来新しい状態（例: `Maintenance`）が追加された際、コンパイルエラーとして検知できるため、フロントエンドのハンドリング漏れを防げる。
2. ガード句の軽量化:
`_isFresh` は単なる日時の引き算（O(1)）であり、パフォーマンスペナルティがゼロに近い。重いリストのフィルタリングや集計処理は、この `switch` に到達する前に済ませておくか、モデルのイニシャライザ（コンストラクタ）で計算を終えておくべきだ。
3. 可読性と保守性の両立:
「構造の検証（パターン）」と「値の条件判定（ガード句）」が美しく分離されており、コードレビュー時にレビュワーが処理の意図を1秒で脳内トレースできる。
—
3. Webエンジニアへのメッセージ：コンポーネント設計への応用
Flutter Webや、Dartをベースにしたフロントエンドアーキテクチャにおいて、UIの状態遷移はそのままUX（ユーザー体験）の品質に直結する。
複雑な非同期APIのレスポンスを受け取り、画面のコンポーネントを描き分ける際、無駄に複雑なガード句を書いてDart VMの評価サイクルに負荷をかけたり、予測不可能なバグを生み出したりしてはならない。
- ガード句は「小さく、純粋に、速く」保つこと。
- 重い処理はパターンマッチの手前でプリコンピュート（事前計算）すること。
- `sealed` とパターンマッチを組み合わせて、コンパイラに型安全性を強制させること。
この原則を遵守するだけで、あなたの書くDartコードは、コンパイル時にも実行時にも、圧倒的に美しく、そして強靭なものに生まれ変わる。
次のコードレビューでは、チームメンバーの `when` の使い方を厳しく、しかし愛を持ってチェックしてあげてほしい。健闘を祈る。