【テクニカル・上級編】 constによる定数宣言と不変性 – JavaScript実践ガイド

現代JavaScriptにおける`const`の真実：不変性という名の「幻想」と「武器」

JavaScriptのコードベースを眺めていると、至る所で`const`が使われている。現代のフロントエンド開発において、`const`は一種の「正義」であり、Linter（ESLint）に強制されるまでもなく、我々は無意識に定数を切るようになった。

しかし、シニアエンジニアである君に問いたい。君が書いているその`const`は、本当にアプリケーションの「堅牢性」を担保しているか？

今日は、`const`というキーワードがメモリ空間で何をしているのか、そしてなぜ「オブジェクトの不変性」という言葉が、実務において時に危険な罠となるのかを、アーキテクトの視点から紐解いていこう。

—

`const`の正体：メモリ上のポインタを固定する「封印」

まず、基本を整理しよう。`const`は「値」を固定するものではない。「識別子（変数名）とメモリ上の参照先（アドレス）の結びつき」を固定するものだ。

JavaScriptのエンジン（V8など）において、`const`で宣言された変数は、そのスコープ内での代入操作をコンパイル（またはバイトコード生成）時に禁止する。これによるメリットは、単なるバグ防止ではない。

静的解析の効率化: `const`であることが確定していれば、JITコンパイラは「この値が再代入されない」という前提で最適化をかけられる。
認知負荷の低減: コードを読む際、「この値は宣言時以外に変更されない」という保証は、複雑な非同期処理やクロージャの中で、状態の生存期間を追跡するコストを劇的に下げる。

「再代入不可」という甘美な罠：参照の不変性

ここで多くのエンジニアが躓くのが、「オブジェクトや配列のプロパティ変更」が可能であるという事実だ。

const config = { apiEndpoint: ‘/api/v1’, timeout: 5000 };

// これは可能（メモリ上のオブジェクトの内容は書き換わる）
config.timeout = 3000;

// これはエラー（configという「住所」を別のオブジェクトに変えることは許されない）
config = { newConfig: true };

これは仕様としては正しいが、リアクティブなフロントエンドフレームワーク（ReactやVueなど）を扱う上で、この「中身の書き換え」は最大のバグの温床となる。

例えば、コンポーネントのレンダリングを最適化するために`memo`や`useMemo`を使っている時、参照そのものは同じだが中身が書き換わったオブジェクトを渡すと、フレームワークの「浅い比較（shallow comparison）」をすり抜けてしまい、UIの更新漏れや、追跡不能な同期バグを引き起こす。

堅牢性を高めるための「不変性」の担保

実務において、オブジェクトのプロパティすら変更させないためには、言語レベルで強制力を働かせる必要がある。

// 凍結による不変性の担保
const settings = Object.freeze({
endpoint: ‘https://api.example.com’,
retries: 3
});

// strictモードであればエラー、それ以外でも変更は無視される
settings.retries = 10;
console.log(settings.retries); // => 3 (変更されていない！)

ただし注意が必要だ。`Object.freeze`は浅い凍結（Shallow Freeze）であり、ネストされたオブジェクトまでは防げない。真の不変性を求めるなら、`Deep Freeze`を実装するか、あるいは`Immer`のようなイミュータブルなデータ構造を扱うライブラリを採用するのが、大規模アプリケーションにおけるアーキテクチャの正解だ。

—

パフォーマンスとメモリ効率の最適化

`const`を過剰に使用してメモリが圧迫されることはないが、逆に「不変性を保つために毎回新しいオブジェクトを生成する」ことは、メモリ使用量とGC（ガベージコレクション）の頻度に直結する。

1. 高頻度なイベントでの生成: `mousemove`やスクロールイベントの中で毎回新しいオブジェクトを生成して不変性を保とうとすると、短寿命なオブジェクトが大量に生成され、GCの負荷が上がる。
2. 型付き配列の活用: 数値の集合を扱うなら、オブジェクトのプロパティとして保持するよりも、`Float32Array`などの型付き配列を使う方がメモリ効率は圧倒的に高い。

アーキテクトとしては、「論理的な不変性」と「ハードウェアへの負荷」のトレードオフを常に天秤にかける必要がある。不変性が重要なのは「データの整合性」が求められるビジネスロジック層であり、レンダリング直前のパフォーマンスが求められるホットパスではない、という切り分けが重要だ。

—

最後のアドバイス：コードは「意図」を語るべき

最後に、技術的な正しさ以上に重要な話をしよう。

`const`を使うことは、単にエラーを避けるためではない。それは「私はこの値を変更するつもりはない」という、未来の自分やチームメンバーへのドキュメントだ。

`let`を使うべき場所で`const`を使い、無理やり不変性を保とうとして複雑なコードを書くのは本末転倒だ。だが、安易に`let`を使って変数を使い回し、スコープの果てまで状態が汚染されているコードは、もはや「技術的負債」というより「時限爆弾」に近い。

「`const`で宣言できるものは全て`const`にする」。
この規律をベースにしつつ、必要に応じて`Object.freeze`やイミュータブルな設計を取り入れる。そのバランス感覚こそが、泥臭い実務を乗り越えてきたシニアエンジニアの証だ。

さあ、エディタを開こう。君のコードは、今日からより堅牢になるはずだ。