イミュータブル（不変）

📖 もうちょい詳しく

何が新しいの？

イミュータブルは「一度作ったら中身を変えられない」という性質のことです。プログラムでは、あとから値をどんどん書き換えていくやり方が一般的でした。でも、その書き換えが原因で「いつ、誰が、どこで変えたのか」が分からなくなり、不具合の元になりがちです。そこで、あえて「変えない」値を使う考え方が広く使われるようになりました。

どうやって動いてるの？

イミュータブルな値は、作ったあとに書き換えようとしても、中身そのものは変わりません。変えたいときは「元はそのまま」にして、変更を加えた新しい値を別に作ります。たとえば数字や文字を1つ足したいなら、元のデータを書き換えるのではなく、足したあとの新しいデータを用意します。元が残るので、あとから状態をたどりやすくなります。

何ができるの？

意図しない書き換えが起きないので、動作が読みやすく安全になります。複数の処理が同じデータを同時に使う場面でも、誰かが勝手に中身を変えてしまう心配が減ります。結果として、不具合の原因を追いやすくなり、テストもしやすくなることが多いです。

🌱 身近なたとえ

契約書のコピーで例えると分かりやすいです。一度ハンコを押した契約書は、あとから文面を書き直しません。内容を変えたいときは、新しい契約書をもう1枚作り直します。元の1枚はそのまま残るので、「いつ何が変わったか」が後から見比べられます。イミュータブルも、これと同じで「元は残して、新しいものを作る」やり方です。

✅ まず覚えるポイント

• イミュータブル＝一度作ったら中身を変えられない値やデータ。
• 変えたいときは、元を残して新しい値を作る。
• 意図しない書き換えが起きないので、動作を追いやすい。
• 複数の処理で共有しても安全になりやすい。
• 反対の性質は「ミュータブル（書き換え可能）」。

🧭 よくある勘違い

値を変更できないと不便じゃないの？

「変えられない」と聞くと使いにくそうに思えますが、実際は変更後の新しい値を作るだけなので、やりたいことはちゃんとできます。元のデータが壊れない安心感のほうが大きい場面が多いです。

イミュータブルなら必ずバグが減るの？

変更にまつわる不具合は減りやすいですが、すべてのバグがなくなるわけではありません。あくまで「予期しない書き換え」という原因を1つ取り除く手段の1つだと考えておくとよいです。

🧩 関連して覚えると楽な言葉

• 変数: あとから使う値に名前をつけて入れておく入れ物。書き換えられるかどうかが対になる話題です。
• 状態管理: アプリの画面間で共有するデータを一カ所にまとめて扱う仕組み。不変な値を使うと管理しやすくなります。
• オブジェクト指向: データと操作を「モノ」にまとめて組み立てる考え方。そのデータを不変にする設計とよく組み合わせます。
• リファクタリング: 動きを変えずにコードを整理する作業。不変な値を取り入れると見通しが良くなりやすいです。

🏁 ひとことでまとめ

「元は触らず、変えたいときは新しく作り直す」。それがイミュータブルという考え方です。