Dart

この用語をシェア

概要

Dartは、Googleが2011年に発表したオブジェクト指向・クラスベースのプログラミング言語です。当初は「JavaScriptに代わるブラウザ向け言語」として構想されましたが、この目標は市場に浸透せず、2015年前後からサーバーサイドやAngularDart（Google社内のAngularフレームワーク移植）での採用を経て模索が続きました。転機となったのは2017年にGoogleが発表したUIツールキット「Flutter」です。2018年にFlutter 1.0が正式リリースされて以降、Dartの採用数はFlutterの普及と完全に連動する形で拡大しており、現在では「Dart単体の言語」というより「Flutterを動かすための言語」という位置づけが実態に近くなっています。

言語仕様としては、null安全（sound null safety）を前提とした静的型システム、クラス・ミックスイン・拡張メソッドを備えたオブジェクト指向設計、async/awaitによる非同期処理を特徴とします。最大の実用的価値は「1つのDartコードベースからiOS・Android・Web・Windows・macOS・Linux向けの成果物を生成できる」点にあり、モバイルアプリを中心に業務システムの管理画面や社内ツールまで、幅広い開発現場で採用が進んでいます。一方で、Dart単体（Flutterを使わないサーバーサイドやCLI用途）の採用事例はまだ限定的で、エコシステムの厚みという点ではJavaScript/TypeScriptやKotlin/Swiftに及ばない、という非対称な立ち位置を理解しておくことが重要です。

仕組み・設計思想

Dartを理解するうえで押さえておきたいのは、「開発時の生産性」と「本番実行時の性能」を1つのランタイムで両立させるための二段構えのコンパイル戦略です。開発中はDart VM上でJIT（Just-In-Time）コンパイルを行い、コードの変更を数百ミリ秒〜1秒程度でアプリに反映する「ホットリロード」を実現します。一方、リリースビルドではAOT（Ahead-Of-Time）コンパイルによってARM/x64向けのネイティブ機械語を生成し、インタプリタのオーバーヘッドを排して実行速度を確保します。Web向けにはJavaScriptへのトランスパイル（`dart compile js`）に加え、近年はWebAssembly（Wasm）への出力（`dart compile wasm`）も実験的に提供されており、ターゲットに応じてコンパイル方式を切り替えられる点がDartの技術的な核です。

並行処理のモデルもDart特有です。JavaScriptと同様にシングルスレッドのイベントループを基本としますが、真の並列実行が必要な場合は「Isolate」と呼ばれる、メモリを共有しない独立実行単位を生成します。スレッド間でメモリを共有するJavaやKotlinのマルチスレッドモデルとは異なり、Isolate間の通信はメッセージパッシング（SendPort/ReceivePort）に限定されるため、データ競合（race condition）が構造的に発生しにくい設計になっています。反面、Isolate間でオブジェクトを直接共有できないため、大きなデータをやり取りする処理では設計の工夫が必要になります。

型システム面では、Dart 2.12（2021年リリース）でsound null safetyが導入され、Dart 3.0（2023年リリース）以降はnull安全が必須（オプトアウト不可）になりました。変数は明示的に`?`を付けない限りnullを許容せず、コンパイル時にnull参照エラーの多くを検出できます。Dart 3系ではさらに、複数の値をまとめて返せる「レコード型（Records）」、値の構造に応じて分岐する「パターンマッチング」、継承や実装の範囲をクラス定義側で制御する「クラス修飾子（sealed・base・interface・final）」が追加され、関数型言語的な表現力が強化されました。

具体例・ユースケース

まずは基本的なクラス定義とnull安全の挙動を示す例です。

class Counter {
  int _count = 0;
  int get value => _count;
  void increment() => _count++;
}

void main() {
  final counter = Counter();
  counter.increment();
  counter.increment();
  print(counter.value); // 2
  // int? のように ? を付けない限り、count は null を代入できない
}

次に、Dart 3系で追加されたレコード型とパターンマッチングを使った例です。APIレスポンスのようなMapから複数値を安全に取り出す場面でよく使われます。

(int id, String name) parseUser(Map json) {
  return (id: json['id'] as int, name: json['name'] as String);
}

void main() {
  final user = parseUser({'id': 1, 'name': 'Taro'});
  final (:id, :name) = user; // パターンマッチングで分解代入
  print('$id: $name'); // 1: Taro
}

実務でのユースケースとしては、次のような使われ方が典型的です。

• ECサイトの在庫管理アプリ：Flutter+Dartで1つのコードベースからiOS/Android両対応の店舗スタッフ向けアプリを開発し、リリースサイクルを一本化する。
• 業務システムの管理画面（社内ツール）：既存のWeb管理画面をFlutter Webで置き換え、モバイル版アプリと状態管理ロジックやAPIクライアントを共有する。
• MVP（最小実用製品）開発：スタートアップがiOS/Android同時リリースを短期間で実現する手段として、ホットリロードによる高速な試行錯誤を活用する。
• CLIツール・自動化スクリプト：`dart:io`を用いたコマンドラインツールを作成し、Flutterチームが使い慣れた言語のまま社内ツールを内製する。

メリット・デメリット（注意点）

メリット

• クロスプラットフォーム開発の効率 - 1つのコードベースでiOS・Android・Web・デスクトップに対応でき、開発・保守コストを大きく圧縮できる。
• Flutterとの高い親和性 - Widgetツリーの宣言的UI構築、ホットリロードによる高速な試行錯誤など、UI開発体験がFlutterと一体化して設計されている。
• 型安全性とnull安全 - コンパイル時にnull参照エラーの多くを検出でき、実行時クラッシュを減らせる。
• Googleによる継続的な投資 - 言語・SDK・ツールチェーンがGoogle社内チームによって継続的にメンテナンスされている。
• パッケージエコシステムの充実 - pub.devには状態管理・DB・通信系など実務で使うパッケージが揃っており、車輪の再発明を避けやすい。

デメリット・注意点

• 単体言語としての採用実績の薄さ - サーバーサイドやWeb単体（Flutter抜き）でのDart採用事例は少なく、求人市場でも「Flutterエンジニア」としての募集が大半を占める。
• ネイティブAPI連携の追加コスト - OS固有の機能（Bluetooth、バックグラウンド処理など）を使う際は、プラットフォームチャネルやプラグイン経由での実装が必要になり、ネイティブ言語を直接書くより一段階回りくどくなる場合がある。
• Isolateモデルの学習コスト - スレッド共有メモリ型の並行処理に慣れたエンジニアには、メッセージパッシング中心のIsolateモデルへの発想の切り替えが必要。
• バイナリサイズ - AOTコンパイル後のアプリサイズが、同等機能のフルネイティブアプリと比べて大きくなる傾向があり、リリースサイズを気にするプロジェクトでは最適化作業が発生しやすい。
• コミュニティ・情報量 - JavaScriptやPythonと比べると日本語・英語ともに技術記事や質問回答（Stack Overflowなど）の蓄積が少なく、トラブルシューティングで一次情報（公式ドキュメント・ソース）に当たる頻度が高くなる。

混同されやすい用語・類似技術との違い

Dart と Flutter の違い - もっとも混同されやすい組み合わせです。Dartは「言語」、Flutterはその言語で書かれた「UIフレームワーク（SDK）」であり、両者は別物です。ただし実務上はほぼ一体で語られ、「Dartを学ぶ」と言った場合の大半は「Flutterアプリ開発を学ぶ」ことを指しています。Dart単体で学習してもFlutterのWidget体系や状態管理の知識は別途必要です。

Dart/Flutter と React Native（JavaScript）の違い - React NativeはJavaScript（またはTypeScript）でロジックを書き、UI描画は基本的にネイティブのUIコンポーネントに橋渡し（ブリッジ）する方式です。対してFlutter/Dartは、SkiaやImpellerといった独自の描画エンジンでUIを直接ピクセル単位で描画するため、プラットフォーム標準のUIコンポーネントに依存しません。この違いにより、Flutterは見た目の再現性が高い一方、OS標準のUI変更に自動追従しにくいという特性があります。

Dart/Flutter と Kotlin Multiplatform / Swiftの違い - Kotlin Multiplatform（KMP）はビジネスロジックの共通化に主眼を置き、UI層は原則としてプラットフォームごとにネイティブ（Jetpack Compose、SwiftUIなど）で実装する設計思想です。対してFlutter/Dartは、UI層まで含めて完全に共通化する設計思想であり、「どこまで共通化するか」という思想の違いが両者の使い分けの分岐点になります。Swift（SwiftUI）はiOSに特化しネイティブ性能・OS新機能への追従が最速な反面、Android版は別途開発が必要です。

Dart と TypeScript の違い - どちらも静的型付けを重視する言語ですが、TypeScriptはJavaScriptに型を後付けする「上位互換」的な立ち位置でWeb開発が主戦場です。Dartは独立した言語仕様を持ち、主戦場はFlutterによるクロスプラットフォームUI開発です。型システムの成熟度・構文の柔軟性はTypeScriptの方が高い一方、Dartはコンパイル戦略（JIT/AOT）とUIフレームワークとの統合が強みです。

技術	UI描画方式	対応範囲	主な強み
Flutter（Dart）	独自エンジン（Skia/Impeller）で直接描画	iOS/Android/Web/デスクトップ	UIまで含めた完全共通化、高い表現の一貫性
React Native	ネイティブUIコンポーネントへブリッジ	iOS/Android（Web別途）	JavaScript/TypeScript資産の流用、Web人材の転用しやすさ
Kotlin Multiplatform	UIはプラットフォームごとにネイティブ実装	iOS/Android（ロジック共通化）	ロジックのみ共通化、UIはOS標準に忠実
Swift（SwiftUI）	ネイティブ（iOS専用）	iOS/macOSのみ	最速のOS新機能追従、最高のネイティブ性能

学習難易度

初級〜中級者向け

Dart自体の文法は、Java・C#・JavaScript（特にTypeScript）の経験があれば数日〜数週間程度で基本を把握できる程度に平易です。クラス、ジェネリクス、async/awaitといった概念は他の主要言語と共通しているため、言語仕様の壁は高くありません。学習の本当のハードルはDartそのものではなく、Flutterの宣言的UI設計（Widgetツリー、setState、状態管理パターン）とプラットフォーム固有の知識（ビルド設定、ストア申請、ネイティブ連携）にあります。したがって「Dart入門」に取り組む際は、言語仕様だけを単独で学ぶより、最初から簡単なFlutterアプリを作りながら学ぶ方が実務に直結しやすく、挫折も少ない傾向があります。公式サイト（dart.dev、docs.flutter.dev）のチュートリアルとDartPad（ブラウザ上で動くオンラインエディタ）は、環境構築なしで試せる学習の入り口として有用です。

関連技術・エコシステム

• UIフレームワーク - Flutter（事実上の標準用途）、AngularDart（初期のWeb向けフレームワーク、現在は開発縮小）
• 開発環境 - Android Studio、Visual Studio Code（Dart/Flutter拡張機能）、IntelliJ IDEA
• パッケージマネージャー - pub（`pub.dev`でパッケージを公開・検索できる公式レジストリ）
• テストフレームワーク - testパッケージ（ユニットテスト）、mockito（モック）、integration_test（E2Eテスト）、golden_toolkit（見た目の回帰テスト）
• 状態管理 - Provider、Riverpod、BLoC（flutter_bloc）、GetX。プロジェクト規模とチームの好みに応じて選定されるのが実情で、統一された「唯一の正解」はない
• データ層 - Hive・Drift（ローカルDB）、Firebase（BaaS）、Dio（HTTPクライアント）
• サーバーサイドDart - Shelf（軽量Webサーバーライブラリ）、Dart Frog、Serverpod。Flutterと言語を統一できる利点はあるが、採用実績はNode.jsやGoなどに比べて少数派

実務ポイント：採用可否の判断基準

• 新規モバイルアプリでiOS/Android同時リリースが必須な案件では第一候補になりやすい。特に少人数チームで両OSを1つのコードベースで賄いたい場合に効果が大きい。
• 既存のネイティブアプリ（Swift/Kotlin）の部分的な機能追加には不向き。Flutterは基本的に画面全体をFlutterのレンダリングエンジンに置き換える前提の技術であり、既存ネイティブ画面への部分導入はハイブリッド構成の複雑さを伴う。
• Web用途は補助的な位置づけで検討するのが定石。既にReact/Vue.js等でWebフロントエンドが構築済みの組織が、Flutter Webへ全面移行するメリットは薄いことが多い。モバイルアプリとロジックを共有したい管理画面など、限定的な用途での採用が現実的。
• 状態管理ライブラリの選定はプロジェクト初期に固めるべき事項。Provider/Riverpod/BLoCは思想が異なり、途中での大規模な乗り換えはコストが大きい。
• テスト戦略は3層で考える - ロジック単体のユニットテスト、UI部品単位のウィジェットテスト、画面遷移を含む統合テスト（integration_test）を組み合わせるのが一般的な設計。
• 採用市場を見据えるなら「Flutterエンジニア」として募集・応募するのが実態に即している。Dart単体スキルを前面に出した求人はほぼ存在しない。

2025-2026年の最新動向

Dart 3系では、レコード型・パターンマッチング・クラス修飾子（sealed/base/interface/final）が出揃い、より厳密な型設計と分岐処理が可能になりました。特にsealedクラスは、列挙しきれるパターンを網羅チェック付きで扱えるため、状態管理コードの堅牢性向上に活用されています。

Web領域では、従来のJavaScriptトランスパイルに加えてWebAssembly（Wasm）へのコンパイル対応が進められており、対応環境ではブラウザ上での実行性能改善が見込まれています。ただし本番運用での安定性やブラウザ互換性は発展途上の部分もあり、採用時は対象ブラウザでの動作検証を前提にするのが無難です。マクロ（コード生成の仕組み）についてはGoogleが開発を継続していますが、正式導入の時期や仕様は流動的であり、現時点で本番プロジェクトの前提にするのは時期尚早です。全体としては「言語仕様の大きな追加」よりも「既存機能の安定化とツールチェーンの改善」に軸足が移ってきている段階と捉えるのが実情に近いでしょう。

関連用語

• Flutter - Dartのメイン用途となるUIフレームワーク
• TypeScript - 型付き言語としての比較対象
• JavaScript - Web開発の主要言語、React Native等の比較文脈で登場
• Kotlin - Android開発・Kotlin Multiplatformとの比較対象
• Swift - iOSネイティブ開発言語としての比較対象
• React Native - クロスプラットフォーム開発の代替選択肢

外部リンク

• Dart公式サイト
• pub.dev（パッケージレジストリ）
• DartPad（ブラウザ上のオンラインエディタ）
• Flutter公式ドキュメント

この用語についてもっと詳しく

Dartに関するご質問や、システム導入のご相談など、お気軽にお問い合わせください。