前回との接続——変数の話から、データの中身の話へ
前回のF-02では、変数が見える範囲であるスコープを学びました。あの話は、変数という名札そのものの扱いでした。今回は一歩進んで、配列やオブジェクトといったデータの中身を変えるとき、2つの流儀があることを扱います。片方は既存のデータを直接書き換え、もう片方は元を残して新しいものを作ります。この違いが、後のカテゴリIで学ぶ画面開発で大きく効いてきます。
このスライドのポイント
- 前回F-02: 変数が見える範囲＝スコープを学んだ（変数という名札そのものの扱い）
- 今回: 配列やオブジェクトの「中身」を変えるときの2つの流儀
- ①既存のデータを直接書き換える ②元を残して新しいものを作る
- この違いは、後のカテゴリI（画面開発）で大きく効いてくる
定義——2つの更新方式と「参照」
用語を定義します。ミューテーションとは、既存の配列やオブジェクトの中身を直接書き換えることです。イミュータブルな更新とは、元は変えず、変更を反映した新しいデータを作ることを指します。ここで大切な前提があります。JavaScriptでは、配列やオブジェクトは値そのものではなく、本体への参照として渡されます。そのため、直接書き換えると、そのデータを共有しているすべての場所に影響が及びます。つまり、変えるつもりのない場所のデータまで、いっしょに変わってしまうのです。
このスライドのポイント
- ミューテーション＝既存の配列・オブジェクトの中身を直接書き換えること
- イミュータブルな更新＝元は変えず、変更を反映した新しいデータを作ること
- 前提: JavaScriptでは配列やオブジェクトは「本体への参照」として渡される
- そのため、直接書き換えると共有先すべてに影響が及ぶ
なぜ必要か——追いにくいバグの正体
この区別を知らないと、関数にデータを渡しただけなのに、元の一覧まで変わってしまうという、原因を追いにくいバグの構造が読めません。渡した側は変えていないつもりでも、参照が共有されているため中身が書き換わるのです。画面に表示している一覧が意図せず変化したり、逆に更新されなかったりする不具合の背景にも、この仕組みがあります。原因が見えないまま時間を溶かさないために、今のうちに構造を押さえておきましょう。
このスライドのポイント
- 「関数に渡しただけなのに元の一覧が変わった」バグの構造が読めるようになる
- 渡した側は変えていないつもりでも、参照が共有されているため中身が書き換わる
- 画面の一覧が意図せず変化する／更新されない不具合の背景（詳細はI章）
- 原因が見えないまま時間を溶かさないための土台
構造——直接書き換え vs 新しく作る
全体像を対比で捉えます。左が直接書き換える方式です。1つの本体をみんなで共有しているため、どこか1か所の変更が、共有先すべてに波及します。右が新しく作る方式です。元のデータには手をつけず、変更を反映した新しい版を別に用意します。こうすれば、元データは無傷のまま残ります。どちらが安全側かは図を見れば明らかで、共有されるデータほど、右のやり方が事故を防ぎます。
このスライドのポイント
- 左（ミューテーション）: 1つの本体を全員が共有→片方の変更が全員に波及
- 右（イミュータブル）: 元は無傷のまま、変更を反映した新しい版を別に作る
- 共有されるデータほど、右のやり方が事故を防ぐ
具体例——経費一覧から承認済みを抜き出す
経費アプリで考えます。経費の一覧から、承認済みのものだけを抜き出したいとします。元の一覧を削って作れば、それはミューテーションです。抜き出した結果は得られますが、元の全件一覧は失われます。一方、条件に合うものだけを集めた新しい一覧を作れば、それがイミュータブルな更新です。この場合、承認済みの一覧と、元の全件一覧の両方が手元に残ります。後から全件を参照したくなる場面は多いので、元を壊さない後者が扱いやすいのです。
このスライドのポイント
- 経費の一覧から承認済みだけを抜き出したい場面
- 元の一覧を削って作る＝ミューテーション（元の全件一覧が失われる）
- 条件に合うものだけの新しい一覧を作る＝イミュータブル（元の全件も残る）
- 後から全件を参照したい場面は多い→元を壊さない後者が扱いやすい
技術サンプルカード——filterは元を変えない
サンプルを見ます。種別はコードです。目的は、元を変えずに新しい配列を作る操作を確かめることです。allという配列に対して、filterで1万円未満のものだけを取り出し、smallという新しい配列を作っています。読み方の要点は2つです。filterは元を変えず、条件に合う要素だけの新しい配列を返します。だからログを見ると、smallには絞り込んだ結果が入り、元のallは書き換わらずそのまま残っています。AIには、この関数は渡したデータを直接書き換えますか、それとも新しいデータを返しますか、と聞いて確かめましょう。
このスライドのポイント
- 種別: code
- 目的: 元を変えずに新しい配列を作る操作（イミュータブルな更新）を確かめる
- サンプル本体:
混同しやすい概念——constと「中身の不変」
混同しやすい点を整理します。const宣言で作った変数は再代入できませんが、これは中身が変わらないという意味ではありません。constは名札の付け替えを禁止するだけで、配列やオブジェクトの中身は書き換えられてしまいます。つまり、constで宣言したからデータは安全、という思い込みは誤りです。名札の固定と、中身の保護は別の話だと覚えておいてください。
このスライドのポイント
- 「const宣言（再代入できない）」vs「中身の不変」は別の話
- constは名札の付け替えを禁止するだけ
- constで宣言しても、配列やオブジェクトの中身は書き換えられる
- 「constだからデータは安全」は思い込み
バイブコーディングでの確認点
AIに一覧の処理を作らせたときの確認点です。まず、元のデータは変更されますか、と必ず聞きます。特に、複数の場所で共有されるデータは、原則としてイミュータブルに扱わせるのが安全です。AIは短く書くために直接書き換える書き方を選ぶことがあるため、人間の側から明示的に、元を残して新しく作る形を指定するとよいでしょう。
このスライドのポイント
- AIに一覧処理を作らせたら「元のデータは変更されますか」を必ず確認
- 複数の場所で共有されるデータは、原則イミュータブルに扱わせる
- AIは短く書くため直接書き換えを選ぶことがある→人間が明示的に指定する
- 質問例: 「この処理は元の配列を書き換えますか。元を残して新しく作る形にしてください」
一問一答とまとめ
最後に一問一答です。filterは元の配列を変えるでしょうか。少し考えてみてください。答えは、変えません。新しい配列を返す、イミュータブルな操作です。30秒でまとめます。データの更新には、既存を直接書き換えるミューテーションと、元を残して新しく作るイミュータブルな更新の2つがあり、共有されるデータは後者で扱うほど事故が減ります。次回のF-04では、待つ処理と待たない処理、つまり同期処理と非同期処理へ進みます。関連資料は、「リファクタリング指示文50」と「UI改善プロンプト50」です。
このスライドのポイント
- 一問一答: 「filterは元の配列を変える？」→ 答: 変えない（新しい配列を返すイミュータブルな操作）
- 30秒まとめ: 更新には直接書き換える「ミューテーション」と元を残す「イミュータブルな更新」がある。共有データは後者で扱うほど事故が減る
- 次回F-04: 待つ処理と待たない処理（同期処理と非同期処理）へ
- 関連資料: 「リファクタリング指示文50」「UI改善プロンプト50」
