DartのRecord型とNull安全が導く「多値返却」の最適解：型安全を犠牲にしない設計の極意
Dartの進化は、単なるシンタックスシュガーの追加ではない。特にDart 3.0で導入されたRecord型は、かつて私たちが「クラスを作って返す」か「Mapで誤魔化す」かという二択で妥協していた多値返却の歴史に終止符を打った。
しかし、多くのエンジニアがRecordを「単なるタプルの代用」として使っている。これは非常にもったいない。Sound Null Safety（健全なNull安全）が効くこの世界で、Recordをどう定義し、どう分解するか。その解像度が、プロダクションコードの堅牢性を決定づける。
—
1. なぜ「Data Class」ではなく「Record」なのか
非同期APIのレスポンスや、コンポーネントの状態管理において、複数の値を返すために「わざわざ専用のクラスを定義する」のは、コードのノイズを増やすだけだ。
クラス定義が不要ということは、メモリ上のヒープ割り当てのオーバーヘッドを抑え、コンパイラが静的に型を追いやすくなることを意味する。Recordはコンパイル時に構造が確定するため、VMは最適化されたパスでこれらの値を扱うことができる。
2. Null許容性をRecordのフィールドに「埋め込む」技術
多くの現場で見かけるのが、以下のような「不完全な設計」だ。
// 良くない例：利用側で毎回 null チェックを強制される
(User?, String?) fetchUserData() { … }
これでは、呼び出し側が「UserがnullならStringもnullなのか？ それともエラーメッセージなのか？」という推論を強いられる。Null安全の本質は、型を通して「状態のあり方」を明示することにある。
推奨される設計：ResultパターンのRecord活用
複数の戻り値には「成功」と「失敗」の明確なコントラストを持たせるべきだ。
/// 成功と失敗を明確に分けた型定義
/// 成功時は値が必ず存在し、失敗時はエラーメッセージが必ず存在する
typedef Result
// 改善された設計
Result
try {
final user = _service.get(id); // 仮のメソッド
return (data: user, error: null);
} catch (e) {
return (data: null, error: e.toString());
}
}
この定義の強みは、呼び出し側で `switch` 文またはパターンマッチングによる「網羅的な型チェック」が強制される点にある。
3. 実践：パターンマッチングで「Nullを消し去る」
Recordの真価は、定義ではなく「分解」にある。`if-case` や `switch` を使うことで、Null許容型の変数から「Nullの可能性」を安全に剥ぎ取ることができる。
void main() {
final result = fetchUser(“123”);
// パターンマッチングによる分解とNullガード
switch (result) {
case (data: final user, error: null):
// このスコープ内では user は絶対に null ではない
print(‘Welcome, ${user.name}’);
case (data: _, error: final msg):
// エラーハンドリング
print(‘Error occurred: $msg’);
}
}
なぜこれが最強なのか
- 型推論の最適化: `case` 内でDartのフロー解析が働き、`user` が `User` 型として確定する。
- 保守性: もし将来的に `(data: T, error: String, code: int)` のようにRecordの要素が増えても、コンパイラが `switch` 文の網羅性をチェックし、修正漏れを即座に指摘してくれる。
4. パフォーマンスの深淵：IsolateとRecordの親和性
Dart VMのアーキテクチャにおいて、Isolate間でのデータ受け渡しはシリアライズ（コピー）が発生する。しかし、Recordはその構造がコンパイル時に確定しているため、他の複雑なオブジェクトと比較して、VMが内部で軽量にハンドリングできる可能性がある。
特に、UIスレッドから重い計算結果を戻す際、クラスインスタンスを生成して返すよりも、Recordでプリミティブやシリアライズ可能な型をまとめて返す方が、ガベージコレクション（GC）の負荷を劇的に軽減できる。
—
5. チーフアーキテクトからの提言
実務の現場でコードレビューをする際、私は以下のルールを徹底させている。
1. 戻り値が3つを超える場合はRecordを諦めよ: それはRecordの責務ではなく、ドメインオブジェクト（Class）を作るべきサインだ。
2. `null` を返すフィールドは「理由」を添えよ: Recordのフィールドに `?` を付けるときは、その値が「無い」状態がビジネスロジック的に妥当かを自問すること。
3. 名前付きフィールドを活用せよ: `(User, String)` ではなく `(user: User, message: String)` と書け。位置引数のRecordは可読性を破壊する。
結論
Recordは単なる便利な記法ではない。「Null安全」と「型推論」を武器に、動的な柔軟性と静的な堅牢性を両立させるための、現代Dartにおける必須のツールだ。
コードは「書く」ものではなく、「設計する」ものだ。Recordを使いこなし、Nullチェックという退屈な作業から解放され、より本質的なビジネスロジックの構築に魂を注いでほしい。