概要
「イミュータブル（immutable）」── 不変性を意味するこの設計概念は、関数型プログラミングにおいて中心的な思想だ。
だが、なぜ「値を変えない」ことがそれほどまでに重要視されるのか？
本稿では JavaScript をベースに、イミュータブル設計の意味、メリット、誤解、実装技術を
「なぜ」「いつ」「どのように」使うべきかという設計的視点から明快に解き明かしていく。
1. 可変 vs 不変：その違いを明示する
❌ ミュータブル（可変）
const user = { name: 'Alice' }
user.name = 'Bob' // 値が書き換えられる
- 値が直接変更される
- 参照元のオブジェクトも変わってしまう
✅ イミュータブル（不変）
const user = { name: 'Alice' }
const updatedUser = { ...user, name: 'Bob' } // 新しい値を作る
- 元のオブジェクトは変更されない
- 状態が明示的に管理される
2. なぜ不変性が強いのか？
| 利点 | 説明 |
|---|---|
| 予測可能性 | 値が変化しないので、どこでどう変わったかを追う必要がない |
| デバッグ容易性 | 前の状態がそのまま残るため、履歴が追える |
| 並行処理との親和性 | 複数スレッド・非同期処理でも状態の衝突が起こらない |
| Undo/Redoが容易 | 状態が履歴として残るため、時間軸的制御が可能 |
3. JavaScriptでのイミュータブル実装技術
✅ 配列の例
const arr = [1, 2, 3]
const updated = [...arr, 4] // 新しい配列を返す
✅ オブジェクトの例
const settings = { darkMode: false }
const nextSettings = { ...settings, darkMode: true }
✅ ネストされた構造：ライブラリ使用推奨（例：Immer）
import produce from 'immer'
const nextState = produce(state, draft => {
draft.user.name = 'Charlie'
})
4. 状態を持たない「思考」へのシフト
Before: 命令型的な設計
let total = 0
for (let n of [1, 2, 3]) {
total += n
}
After: イミュータブル + 宣言的設計
const total = [1, 2, 3].reduce((acc, n) => acc + n, 0)
- 状態の更新がなく、ロジックが明示的に読める
5. 設計判断フロー
① この値は複数箇所から変更されうるか？ → YES → 不変性で守るべき
② 前の状態を保持したいか？ → YES → イミュータブルが適している
③ 関数が副作用を含むか？ → NO → イミュータブル設計が生きる
④ 複雑な変更を追うのが辛い？ → YES → 値を破壊せずに更新する方針に切り替える
よくある誤解と対策
❌ イミュータブルだとコードが冗長になる
→ ✅ 初期はそう見えるが、長期的に破壊的変更のバグが消える
❌ オブジェクトがどんどんコピーされてパフォーマンス悪化
→ ✅ 実際にはシャローコピー＋参照共有で問題にならない。必要なら永続データ構造の導入を
❌ 「全部イミュータブルにすればいい」
→ ✅ 副作用を隔離したい“境界”に対して適用。すべてを不変にするのではない
結語
イミュータブル設計とは、「値が変わらない」ことに価値があるのではない。
それは「変わるという概念を管理可能にする構造」であり、設計の本質的な安定性を担保する技術である。
- 値を破壊しない
- 状態を管理ではなく構築する
- 時間・履歴・副作用を構造に内包できる
イミュータブル設計とは、
“変化に強いソフトウェアを、不変という前提から築く構造的な戦略である。”