【実務・中級編】DartのNull安全と「Record」型の組み合わせ：多値返却の安全な実装 – Dart コア文法・オブジェクト指向・Null安全解析バイブル

Dartの深淵：Sound Null SafetyとRecord型が切り拓く「型安全な多値返却」の極意

Dart 3以降、言語の設計思想は「より堅牢で、より表現力豊か」な方向へ完全にシフトした。特にRecord型の導入は、これまで我々が悩まされてきた「メソッドの多値返却」という課題に対し、劇的な改善をもたらした。

今回は、Null安全（Sound Null Safety）の文脈において、Record型をどう活用すれば「ランタイムエラーをコンパイル時に封殺する」堅牢なコードを構築できるのか、そのアーキテクチャを深掘りする。

—

なぜ従来の「クラス定義」は非効率なのか

かつて、APIから「データ」と「エラー情報」のペアを返す場合、我々はわざわざ`Result`や`Response`といったクラスを定義していた。

// 過去の遺物：型定義のためだけのボイラープレート
class UserResult {
final User? user;
final String? error;
UserResult(this.user, this.error);
}

このアプローチには二つの欠陥がある。
1. 認知負荷: 単なるタプルを返すためだけに、名前空間を汚染するクラスを定義し、管理する必要がある。
2. Null安全の抜け穴: `user`と`error`が両方null、あるいは両方非nullである可能性を、コンパイラに強要するのが難しい。

Record型による「型空間の最小化」

Record型は、コンパイル時に構造が決定される匿名構造体だ。Dart VMレベルでは、これらはメモリ効率の良いオブジェクトとして生成される。重要なのは、「Null許容性」と「構造」を分離させず、一つの型として表現できることだ。

実践：実務で使える「安全なAPIレスポンス」パターン

以下は、非同期APIから「データ」または「エラー」を確実に受け取るための、保守性の高い実装例である。

/// 非同期APIのレスポンスをRecordで定義する。
/// (T?, String?) ではなく、成功と失敗を排他的に表現する。
typedef FetchResult = ({T? data, String? error});

Future> fetchUserData(String id) async {
try {
final response = await apiClient.get(‘/users/$id’);
// 成功: errorはnull、dataは非null
return (data: User.fromJson(response.data), error: null);
} catch (e) {
// 失敗: dataはnull、errorは非null
return (data: null, error: e.toString());
}
}

// 呼び出し側のコード
final (:data, :error) = await fetchUserData(‘123’);

if (error != null) {
// ここでは error が非nullであることが保証される
logger.e(‘Failed: $error’);
return;
}

// ここでは data が確実に非nullとみなされる（スマートキャスト）
print(‘User: ${data.name}’);

なぜこの実装が「極限」と言えるのか

1. スマートキャスト（Flow Analysis）の完全活用:
Dartのコンパイラは、`error != null` という判定を通過した時点で、`error`が非nullであることをスコープ内で保証する。Recordの分解代入（Destructuring）を行うことで、この判定が極めてクリーンに行える。
2. パフォーマンスへの配慮:
Recordは単なる構造体ではなく、Dart VM内部で最適化されたメモリレイアウトを持つ。クラスをインスタンス化するよりもオーバーヘッドが少なく、GC（ガベージコレクション）への負担も最小限だ。
3. 可読性と疎結合:
「データを受け取るための専用クラス」が不要になることで、コードのベースラインが劇的に軽量化される。特にコンポーネント設計においては、API層とUI層の境界がすっきりし、保守性が飛躍的に向上する。

—

パフォーマンスと保守性のための「禁じ手」

ただし、Record型には注意点がある。

深すぎるネストは避ける:

Recordの中にRecordを入れ子にすると、型定義が読みづらくなる。複雑なデータ構造であれば、無理にRecordを使わず、`sealed class`や`freezed`パッケージによるパターンマッチングを選択すべきだ。

ビジネスロジックの漏出:

Recordは「一時的なデータの受け渡し」に特化している。もしそのデータにメソッドを持たせたい、あるいは状態を保持させたいのであれば、それはRecordの役割ではない。即座に`class`へ昇格させるのが正解だ。

結び：Dartを掌握するということは

Dartの型システムは、あなたの「意図」をコンパイル時に検証してくれる強力な味方だ。Recordを活用した多値返却は、単なるコードの短縮術ではない。「何が成功し、何が失敗しうるのか」という設計思想を型に落とし込むための、最もモダンな作法である。

次にコードを書く際、`class`を作ろうとしたら一度立ち止まって考えてほしい。「これはRecordで表現できないか？」と。その問いこそが、君をただのコーダーから、アーキテクトへと引き上げる鍵になる。

さあ、次はどんな複雑な非同期フローを、この美しい型システムで解き明かそうか。