こんにちは！Flutterでのアプリ開発やDartを使ったバックエンド構築、楽しんでいますか？
他のプログラミング言語からDartの世界に飛び込んできた方から、よくこんな質問を受けるんです。「変数の型を調べる時、従来の `is` 演算子と、Dart 3で入ったパターンマッチングの `case` や `switch`、どっちを使えばいいの？」って。
実はこれ、単に「書き方が新しくなったんでしょ？」で片付けるにはもったいない、DartのコンパイラやVMの動きに直結する非常に深いテーマなんですよ。
ここをクリアすれば、あなたの書くコードはただ動くだけでなく、Dartのエンジンが歓喜するような「美しく最適化されたコード」に生まれ変わります。一緒に、Dartの奥深い世界を覗いてみましょう！
—
1. おさらい：従来の `is` 演算子と「型テストプロモーション」の魔法
まずは、おなじみの `is` 演算子のお話です。
Dartには、コードを書いていて思わず「おっ」と感心してしまう強力な機能があります。それが「型テストプロモーション（Type Test Promotion）」です。
まずは以下のコードを見てください。
void processValue(Object input) {
// inputはObject型だが…
if (input is String) {
// ここに入った瞬間、Dartのコンパイラは「お、inputはStringだな」と推論する
print(input.toUpperCase()); // String型のメソッドがそのまま呼べる！
}
}
このコード、何が起きているか分かりますか？
`input` はもともと `Object` 型として渡されてきます。普通なら、`String` 型のメソッドである `toUpperCase()` を呼ぶには、 `(input as String).toUpperCase()` のようにキャスト（型変換）を書かないといけないはずですよね。
しかし、Dartのコンパイラ（および静的解析器）は、`if (input is String)` という扉をくぐった瞬間、そのスコープ内での `input` の型を自動的に `String` に昇格（プロモート）してくれます。
従来の `is` 演算子の限界
非常に便利な `is` ですが、少し複雑な条件になるとボロが出始めます。例えば、「複数の型を綺麗にハンドリングしたい」と思ったときです。
void handleLegacy(Object input) {
if (input is int) {
print(‘整数だね: ${input 2}’);
} else if (input is String) {
print(‘文字だね: ${input.length}’);
} else if (input is double) {
print(‘小数だね: ${input + 1.0}’);
} else {
print(‘その他だよ’);
}
}
`if-else` のチェーンが長くなってしまいましたよね。読めなくはないですが、少し冗長です。そして何より、コンパイラが「網羅性（すべてのパターンを網羅しているか）」を強制してくれないため、将来 `bool` 型が追加されたときなどに、この `if-else` の迷宮に新しい条件を書き忘れるバグを埋め込みやすくなります。
—
2. Dart 3の真骨頂！「型テストパターン」の登場
そこで登場するのが、Dart 3で導入されたパターンマッチング（特に `switch` 式と型テストパターン）です。
先ほどのコードを、Dart 3の作法で書き直してみましょう。
void handleModern(Object input) {
// switch「式」としてスマートに書く
final result = switch (input) {
int i => ‘整数だね: ${i 2}’,
String s => ‘文字だね: ${s.length}’,
double d => ‘小数だね: ${d + 1.0}’,
_ => ‘その他だよ’,
};
print(result);
}
見てください、この圧倒的な美しさを！
ここで使われている `int i` や `String s` が、まさに「型テストパターン」です。
コードの意味と動きのイメージ
- `int i` というパターンは、「もし `input` が `int` 型であれば、それをマッチさせて、一時変数 `i` にバインド（代入）しなさい」という意味になります。
- 従来の `is` 演算子＋キャストの組み合わせを、より宣言的かつ安全に一行で表現しているわけです。
さらに、Dart 3の `switch` は網羅性チェック（Exhaustiveness checking）をサポートしています。もし `input` が取りうる型（この場合は `Object` なので無限にありますが、例えば `sealed class` のサブクラスなどを想定してください）に対して、処理の漏れがあると、コンパイラが「おいおい、このケースが抜けてるよ！」と赤線を引いて教えてくれます。
—
3. コンパイラ最適化の視点：裏側で何が起きているか？
さて、ここからがチーフアーキテクトとしての本領発揮です。
「じゃあ、どっちを使ってもコンパイル結果や実行速度は一緒なんでしょ？」と思ったそこのあなた。実は、コンパイラの視点ではいくつかの違いと、Dartチームの巧みな最適化戦略があります。
1. 内部的なジャンプテーブルの最適化
従来の `if (x is A) … else if (x is B) …` は、Dart VMのC++層から見ると、上から順番に型チェック（`IsInstanceOf` や `SubtypeTest`）を評価していく線形探索になりがちです。
一方、`switch` によるパターンマッチングは、コンパイラ（CFA: Control Flow Analysis およびバックエンドのコードジェネレータ）にとって、分岐の構造が非常に解析しやすい形をしています。
特に定数パターンや特定の型階層（`sealed class` など）が絡む場合、DartのAOT（Ahead-Of-Time）コンパイラは、効率的なジャンプテーブルやインラインキャッシュを構築しやすく、ディスパッチ（処理の振り分け）を高速化できます。
2. スコープと変数のライフサイクル
`is` 演算子によるプロモーションは、制御フロー解析に強く依存します。複雑な論理演算子（`&&` や `||`）が絡むと、プロモーションが効かなくなる「不気味な現象」に出くわしたことはありませんか？
// 例：複雑な条件式の中ではプロモーションが外れることがある
bool isValid(Object? a, Object? b) {
if (a is String && b is String) {
// ここでは両方Stringとしてプロモートされる
return a.isNotEmpty && b.isNotEmpty;
}
return false;
}
これに対し、パターンマッチング（特に `switch` 式）は、「パターンに一致したその瞬間に、スコープが限定された新しいバインド変数（例：上のコードの `i` や `s`）が生まれる」という明確な構文木を持ちます。これにより、コンパイラは変数の生存期間（ライフタイム）やレジスタ割り当てを非常にクリーンに最適化できるのです。
—
4. 陥りやすい文法エラーと罠
ここで、開発現場でよくある「やっちまった！」ポイントをいくつかご紹介しておきますね。
罠その1：型テストパターンでの「変数名」の忘れ
初心者の頃、以下のようなコードを書こうとしてコンパイルエラーになる人が続出します。
void badExample(Object input) {
switch (input) {
// ❌ エラー！型を書くだけではダメで、変数名（バインド名）が必要
case int:
print(‘intだ！’);
break;
case String:
print(‘Stringだ！’);
break;
}
}
【正しい書き方】
void goodExample(Object input) {
switch (input) {
// ○ 型の後に「変数名（i, sなど）」を必ず書く！
case int i:
print(‘intだ！値は $i’);
break;
case String s:
print(‘Stringだ！長さは ${s.length}’);
break;
}
}
「型をテストするだけ（変数名は不要）」に見えても、Dartのパターンマッチングでは、マッチした値をキャプチャするための変数名が必須となります。ここ、テストに出ますよ！笑
罠その2：nullable（NULL許容型）の扱い
Dartの厳格なNull安全において、`is` 演算子とパターンマッチングでは、nullに対する挙動を意識する必要があります。
Object? nullableInput = null;
// is演算子の場合
if (nullableInput is String) {
// nullableInputは非nullのStringにプロモートされる（nullはis Stringを通らないため）
}
// パターンマッチングの場合
switch (nullableInput) {
case String s:
// ここには絶対にnullは来ない（String型にマッチするため）
break;
case null:
// nullを明示的にキャッチする必要がある
print(‘nullだったよ’);
break;
default:
break;
}
Dart 3の `switch` では、対象がNullableな型の場合、`null` ケースを明示するか、デフォルトスロット（`_`）を用意しないと、網羅性チェックに引っかかります。この「nullをうっかり見落とさない仕組み」こそが、Dart 3の最大の強みです。
—
5. 最適な選択基準：結局、どう使い分けるべき？
長々と解説してきましたが、現場での実用的な使い分けの指針はとてもシンプルです。ここを覚えておけばバッチリですよ！
🟢 パターンマッチング（`switch` 式 / `case`）を積極的に使うべき場面
1. 3つ以上の複数分岐があるとき
- `if-else if-else` の連鎖を避け、可読性と網羅性チェックの恩恵を受けるため。
2. データのアンストラクチャリング（分解）や値の変換を伴うとき
- `switch (json)` のように、型チェックと同時にJSONの構造をパースしたい場合。
3. `sealed class`（シールクラス）と組み合わせるドメインロジック
- 状態管理（BloCやStatefulなUIのステートなど）で、取りうる状態を網羅的にさばくとき。
🔵 従来の `is` 演算子を使うべき場面
1. 単一のガード節（Guard clause）で早期リターンしたいとき
void doSomething(Object input) {
if (input is! String) return; // ここでサクッと弾く
// 以降、inputはStringとして使える（プロモーションの恩恵）
print(input.toUpperCase());
}
※ このような「ただの型チェックによる早期リターン」を書くために `switch` を書くのは、かえってコードが冗長になります。
—
まとめ
いかがでしたでしょうか？
- 従来の `is` 演算子は、シンプルな早期リターンや単一の型チェックでその真価を発揮します。
- Dart 3の「型テストパターン」は、複雑なデータ構造の分岐や、堅牢な網羅性を担保したいビジネスロジックにおいて、コンパイラの最適化を引き出しつつ最高の安全性をもたらしてくれます。
それぞれの特徴を正しく理解し、適材適所で使い分けることができるようになれば、あなたのDartコードは一段も二段も洗練されたプロフェッショナルなものになります。
ここをクリアしたあなたなら、もうDartの型システムを怖がる必要はありません。自信を持って、素晴らしいコードを書き続けてくださいね！