第2講で「何もしていないのに壊れる」話をしました。この講は、その最大の犯人を名指しします。更新です。
ある日、公開物が動かなくなる。自分は何も変えていない。でも世界のどこかで、あなたのプログラムが借りている部品の新しい版が出て、どこかの前提が1つ崩れた・・・。この講のゴールは、更新と正しい距離感で付き合えるようになることです。放置でも、全部すぐ更新でもない、その中間の距離感です。
建物の部品にたとえます。
棚を壁に留めているネジを想像してください。ある日ネジの規格が変わって、新しいネジは頭の形が少し違うとします。ネジ1本なら大した話ではない。でも棚の金具が新規格の前提になり、金具に合わせて板の穴の位置も変わり・・・と連鎖して、気づけば「棚ごと替えないと壁に付かない」ことがあります。部品は単独では存在せず、互いの規格を前提に組み合っているからです。
プログラムの世界では、この連鎖が日常的に起きます。あなたのプロジェクトは、依存パッケージ（プログラムが借りている他人製の部品）の集合体です。第7講の備品棚・・・node_modulesにどっさり入っていた、あれです。部品には版（バージョン）があり、作者たちは改良や安全上の修理のために、新しい版を出し続けます。あなたが何もしなくても、部品の世界は動き続けている。
ここで大事なのは、放置と更新のどちらにもリスクがあると知ることです。
だから答えは、更新するかしないかではなく、更新の仕方になります。小さく試す。1つずつ、戻れる状態（第13講のセーブ）を作ってから。第12講の「同時に2箇所を直さない」と同じ理屈が、ここでも効きます。
自分のプロジェクトの、部品一覧を見てみます。
部品管理の仕組みがあるプロジェクト（AIに作らせたアプリは、たいてい該当します）の人は、質問例1をAIに貼ってください。一覧の出し方と、更新が長く止まっている部品を教えてもらえます。今日は更新しません。「うちの備品棚には部品が何個あって、いくつが古いのか」を知るだけで十分です。
自分の一枚のような素のHTMLの人は、そもそも部品管理の仕組みが無いことが多い。それを確かめるのが演習です。質問例2で、「このプロジェクトに部品管理はあるか、無いなら何が更新で壊れる原因になりうるか」を聞いてください。借り物がほとんど無いページは、更新で壊れる心配も少ない・・・その身軽さを確認できたら合格です。
そのまま貼って使えます。
全部の部品を、まとめて最新にすること。
更新のお知らせが20件たまっているのを見ると、一括更新で一気に片づけたくなります。押すと何が起きるか。20個の部品が同時に変わり、どれか1つが前提を崩し、アプリが起動しなくなります。そして、犯人が20人のうちの誰なのか、特定する手がかりがありません。第12講で、ブレーカーを1部屋ずつ上げた理由を思い出してください。あれと真逆のことを、自分からやってはいけません。
正しい手順は地味です。セーブしてから、1つ更新して、動作を確認する。壊れたら戻して、その部品だけ後回しにする。20件あっても、この繰り返しです。時間がかかるようでいて、原因不明のまま丸2日止まるより、はるかに速く終わります。