Dartコンパイラが隠蔽する「真のイミュータビリティ」：`const`コレクションの再帰的定数化とメモリ最適化の低レイヤ解剖
Dart言語の設計において、`var`、`final`、そして`const`の境界線を曖昧に理解しているエンジニアは多い。特に「コレクションにおける`const`の伝播（Propagation）」に関しては、表面的な不変性（Immutability）の議論に終始しがちだ。
シニアエンジニアやランタイムの挙動にこだわるアーキテクトであれば、こう問いかけるべきである。
「コレクションリテラルに付与された単一の `const` キーワードは、その内包するネスト構造の深部へどのように作用し、Dart VMのメモリアロケータと定数プール（Constant Table）をどう書き換えるのか？」
本稿では、Dartのコンパイルパイプライン、AOT（Ahead-Of-Time）コンパイル時の定数畳み込み（Constant Folding）、そしてIsolate間のメモリ共有メカニズムの深部まで踏み込み、`const`がもたらす真の低レイヤ最適化の正体を暴く。
—
1. 表面的な `final` と、絶対的な `const` の決定的な断絶
まず、前提として `final` と `const` のメモリ上の振る舞いの違いを正確に把握しておかねばならない。
- `final`: 実行時（Runtime）に一度だけ代入可能であることを保証するマーカーに過ぎない。指し示しているオブジェクト自体がミュータブル（可変）であれば、その内部状態は自由に変更可能である。
- `const`: コンパイル時（Compile-time）に完全に評価され、不変のデータ構造としてバイナリ（RODATAセクション等）に焼き込まれる。
以下のコードを見てほしい。
void examineImmutability() {
// 1. finalによるリスト宣言
final List
finalList.add(4); // 実行時エラーにならない！要素の追加・変更が可能。
// 2. constによるリスト宣言
const List
// constList.add(4); // コンパイルエラー: Unsupported operation: Cannot add to an unmodifiable list
}
`finalList` は「変数の再代入が禁止されている」だけであり、ヒープ上に生成された `List` インスタンスは通常通りミュータブルである。一方、`constList` は、インスタンスそのものがDart VMの「定数プール（Canonicalized Constant Table）」に常駐し、書き込み不可のメモリ領域に配置される。
—
2. コレクションにおける `const` の「再帰的伝播（Deep Propagation）」
本題である。深部にネストされた複雑なコレクション構造（例：`Map` の中に `List` があり、その中にさらに `Map` があるような構造）に対して、最外殻にのみ `const` を付与した場合、コンパイラは何を行うのか。
答えは明快である：`const` は、リテラル構文ツリーの末端（Leaf）に至るまで、完全に再帰的に伝播する。
コンパイル時のトランスフォーメーションと正規化 (Canonicalization)
Dartのフロントエンドコンパイラ（cfe: Common Front End）およびCFA（Constant Folding Analyzer）は、`const` コレクションリテラルに遭遇すると、その配下にあるすべての要素、キー、バリューを再帰的に走査し、それらがすべて「コンパイル時定数」として評価可能であるかを厳密に検証する。
検証を通過した場合、その構造全体が単一の不変な定数オブジェクトとしてメモリ上にフラットに、あるいは効率的なツリー構造として構築され、重複排除（Canonicalization）の対象となる。
void demonstrateDeepConst() {
// 深いネスト構造を持つ定数マップ
const Map
‘version’: 1,
‘features’: {
‘auth’: [‘oauth2’, ‘biometric’],
‘timeouts’: {
‘connection’: 30,
‘read’: 15,
},
},
‘flags’: [true, false, true],
};
// 伝播の検証：配下のListやMapもすべて定数（Unmodifiable）である
// deeplyNestedConfig[‘features’][‘auth’].add(‘saml’);
// -> 実行時例外: Unsupported operation: Cannot add to an unmodifiable list
}
ここで重要なのは、開発者が `features` や `timeouts` の各リテラルに対して個別に `const` キーワードを付与していない点だ。最外殻の `const` 一つで、配下のすべてのコレクションが自動的に完全な定数へと昇格（Promote）している。
—
3. メモリレイアウトとDart VMの定数プール（Canonicalization）の魔術
では、このコードがDart VM上で実行される際、メモリ上では何が起きているのか。
Dart VMは、アプリケーションの起動時（またはIsolateの生成時）、コンパイル時に生成された定数を「定数プール（Canonicalization Table）」にロードする。ここで驚異的な最適化が行われる。
同一性（Identity）の極限最適化
同じ `const` 構造を持つオブジェクトは、メモリ上で完全に同一のインスタンス（同じメモリポインタ）を共有する。
void verifyMemoryCanonicalization() {
const listA = [1, 2, {‘a’: 10}];
const listB = [1, 2, {‘a’: 10}];
// 参照の比較
// ignore: unnecessary_const
print(identical(listA, listB)); // 出力: true
// ネストされた内部のMap同士も同一インスタンスを指す
print(identical(listA[2], listB[2])); // 出力: true
}
一般的なオブジェクト指向言語であれば、これらはヒープ上に別々のインスタンスとしてアロケートされ、ガベージコレクション（GC）の負荷となる。しかし、Dartの `const` 伝播メカニズムにより、コンパイラとVMはこれらを同一視し、メモリ消費量を劇的に削減し、GCの走査対象外（Permanent Generation / Old Generationの静的領域）とする。
これは、ミリ秒単位の応答速度が求められるFlutterのビルドフェーズや、高スループットなサーバーサイドDartアプリケーションにおいて、GC一時停止（Stop-the-world）の確率を物理的にゼロへと近づけるための最強の防壁となる。
—
4. `const` 伝播を破壊する「アンチパターン」とコンパイルエラーの真意
この強力な再帰的定数化も、一つでも「実行時でなければ評価できない値（Runtime Evaluation Value）」が混入した瞬間に瓦解する。
シニアエンジニアが最も警戒すべきは、「うっかり変数を混ぜてしまった場合のコンパイルエラーの読み方」である。
void invalidConstPropagation(int dynamicTimeout) {
// 以下のコードはコンパイルエラーになる
/
const Map
‘version’: 1,
‘timeouts’: {
‘connection’: dynamicTimeout, // ❌ 実行時変数混入による汚染
},
};
/
}
コンパイラエラー（`Const variables must be initialized with a constant value`）が発生する理由は単純ではない。`dynamicTimeout` が存在することで、親である `Map` リテラル全体がコンパイル時に評価不可能となり、定数プールへの配置が拒絶される。
もしこのような動的な値を含めつつ、不変性を担保したい場合は、`const` ではなく `const` と `final` のハイブリッド、あるいは `UnmodifiableMapView` などのラッパーを使用せざるを得なくなる（そしてそれは、定数プールの恩恵を失い、ヒープアロケーションが発生することを意味する）。
—
5. アーキテクチャへの応用：シニアが実践すべき設計指針
大規模なDart/Flutterコードベースを構築する際、この `const` コレクションの再帰的伝播の特性をどう設計に落とし込むべきか。
1. UIコンポーネントのスタイル・テーマ定義の完全定数化
デザインシステムにおけるカラーパレットやスペーシング定義は、すべて最深部まで `const` で構築されたマップやリストとして定義する。これにより、Widgetツリーの再描画（Rebuild）時における不要なオブジェクト生成を防ぎ、メモリ帯域を極限まで温存できる。
2. ステートレスなドメイン設定のハードニング
アプリケーションのルーティングテーブル、APIのエンドポイント定義、権限マトリクスなどは、すべて `const` コレクションとして静的に定義する。これにより、実行時の意図しないミューテーション（バグや脆弱性につながる状態汚染）を型システムとランタイムの両面から完全に封鎖する。
—
結言
Dartの `const` は、単なる「書き換え不可の糖衣構文」ではない。
それはコンパイラに対する強烈な最適化の指示であり、Dart VMのメモリアロケータとランタイム効率を極限まで引き出すための、エンジニアからVMへの「契約」である。
コレクションリテラルに打たれたたった一つの `const` が、再帰的に構造を貫き、バイナリの深部にまで最適化の波及効果をもたらす。この低レイヤのメカニズムを脳内に完全に同期させた者だけが、Dartという言語の性能を極限まで引き出すことができるのだ。