なぜOSは「再起動してください」と言い続けるのか——Windows Updateの深層を丸ごと解剖する
「更新をインストールしています 32%。コンピュータを電源オフしないでください」。この画面の前で時間が止まったように感じた経験は、ほぼすべてのパソコンユーザーが持っているだろう。そして翌朝、パソコンはこう告げる。「再起動してください」。なぜたった数十MBの更新のために、機械はいちばん嫌な言葉を繰り返すのか。この単純そうで見えにくい問いに、技術的な答えを順番に積み上げていく。
前提として：なぜOSは再起動を要求するのか
発端は毎年恒例の大型アップデートだ。米Microsoftは2025年10月14日で「Windows 10」のサポートを終了し、以降は「Windows 11」が主流の環境となった。新機能やAI機能がセールスポイントとして語られがちだが、実際には従来のWindowsと大差ない、という評価も根強い。一方で、アップデートそのものは続いている。そして多くのパッチは適用後に「再起動してください」と表示される。
このとき頭の中で完結している処理は、実は「ファイルを新しいものに差し替える」だけではない。本当の作業は、そのファイルを実行中のプログラムが読み込んでいない状態で開き直し、メモリの中身を新しいコードで埋め直すことにある。走っている最中のエンジンの部品は交換できない。だから一度エンジンを止める——それが再起動だ。
プロセスとスレッド、そして仮想メモリという土台
話を正確にするために、OSの基礎を揃えておく。プロセスメモリとは、プロセスごとに確保される独立したメモリ空間だ。この空間があるおかげで、プロセスAがメモリを破壊的に書き換えても、プロセスBやOS本体まで巻き添えにはならない。仮想アドレス空間は通常、下からテキストセクション（実行コード）、データセクション（初期化済みグローバル変数）、bssセクション（未初期化変数）、そしてヒープと続く。ヒープはmallocやnewで確保される領域で、上に向かって伸びていく。その逆側、スタックは下に向かって伸び、局所変数や関数呼び出しの戻りアドレス、レジスタの退避先に使われる。スタックが突き刺さってヒープに触れる境界がスタックオーバーフローであり、関数の再帰が爆発するとここに到達する。
スレッドは、同一プロセス内の複数の実行経路がメモリを共有する仕組みだ。ヒープやグローバル変数は全スレッド共通、一方でスタックとレジスタはスレッドごとに別枠になる。だからこそロックが要る。
CPUが実行するのは、常に命令とデータの実体、つまり物理メモリ上の値だ。プロセスが持つ仮想アドレスは、そのままハードウェアに届くわけではない。CPU内のMMU（メモリ管理ユニット）が、ページテーブルを引いて仮想アドレスを物理アドレスへ変換する。さらに高速化のためにTLB（ページテーブルエントリのキャッシュ）が挟まる。ページテーブルの持ち方には二通りある。1対1マップはページ番号を直接スロット番号に変換する方式で、先頭からのオフセット計算が高速だが、ページングのメリットが薄い。逆マップは、必要になった瞬間だけディスクから物理ページに読み出す方式で、いわゆるデマンドページングだ。メモリに載っていないアドレスにアクセスするとページフォルトが発生し、OSが割り込みとして拾って読み込みを行い、実行を再開する。この仕組みのおかげで、必要な分だけをメモリに載せて動作できる。
ファイルが「開いたまま」だと差し替えられない
ここからが本題の中核だ。更新プログラムが新バージョンのファイルをディスクに書き込んでも、そのファイルを実行中のプログラムがある場合、ディスク上のファイルは古く、メモリ上のコードは新しい、という状態が生まれる。しかもメモリ側が有利に振る舞うわけではない。
メモリマッピングの仕組みを見ると理由が見える。EXEC_SHAREDのように共有でマッピングしたコード領域は、ページテーブルを介して直接ファイルの実体（ページキャッシュ）を指している。書き換えられると元ファイルが壊れるため、OSは「書き込み禁止」としてマップしている。一方、書き込みが必要なデータはプライベートにコピーしてマップする。つまり実行中コードの実体は、ファイル側のキャッシュと地続きなのだ。
ではファイルの削除・差し替えはどうか。Linuxでは、開いているファイルは削除後にクローズされるまで実体が保持される。一方Windowsでは、ファイルが共有モードを持つ。これは「読み込み」「書き込み」「実行」など、次に誰が何をしてもよいかに相当するフラグで、オープン時に要求と突き合わせられて、要求と競合するモードを持つオープンがエラーになる。共有モードを指定できるのはWindows側のAPIであり、Linuxではこの種のファイル単位ロックは原則できない。Windowsの排他は、モードの集合が交わった瞬間に拒否する判定になっている。
Windowsの更新が再起動を要求する典型は、まさにこの共有モードの衝突だ。使用中で書き込めないファイルを、更新側が上書きできない。あるいは、書き換えたファイルに新しいコードを読み直させたいが、読み込み済みのコードページがメモリに居座っている。更新プログラムが起動時点のファイルスナップショットを作り、その差分を後で適用する方式（CBS／Component Based Servicing）や、複数バージョンのDLLを同居させるSXS（Side by Side）も、この「書き換えられない」問題を回避するために生まれた仕組みだ。
DLL地獄と、OS更新を難しくする構造
Windows更新が厄介になる背景には、歴史の堆積もある。Windows 3.1のころはアプリとDLLを同じフォルダに置くのが普通で、バージョン衝突は起きにくかった。Internet ExplorerやOfficeの普及に伴い、インストーラが共通のDLLを「より新しければ上書き」というルールでシステムフォルダへコピーする方式に変わると、より古いDLLに置き換えられたり、想定外の更新でアプリケーションが動作しなくなる「DLL地獄」が頻発した。対策としてSide by Sideとマニフェスト、そしてコンポーネント単位で更新を適用するCBSが入り、SxSフォルダには多数のバージョンのDLLが納まるようになった。
ただしSXSフォルダは、すべてのアプリがマニフェスト経由で正しく参照する保証がない以上、完全な解決にはなっていない。更新時に特定のプログラムが削除できない、あるいは削除されたら困る、という運用上の不安が付きまとうのもこのあたりが理由だ。その結果として「削除せず、動いているものの上に載せる」更新が主流になり、Windows Updateを繰り返すとディスクに古い部品が積み上がっていく。システムイメージやWinSxSが肥大化し、ディスククリーンアップやイメージのリセット（DISM）が必要になるのはこの構造の帰結だ。ディスク容量が逼迫して更新自体が失敗するケースも起きている。
Linuxは再起動を嫌う：inode、needrestart、kexec、ライブパッチ
比較対象としてLinuxを見ると、思想の違いがはっきりする。Linuxは「削除しても、閉じられるまで開いているファイルの実体が生きている」という性質を持つ。更新プログラムは古いバイナリをリネームし、新しいファイルを同じ名前で配置すればよい。すでに起動済みのプロセスはリネームされた古いinodeを参照し続けるので、そのまま動き続けられる。新しいプロセスだけが新バージョンを使う。こうしてOSは「再起動なし」で少しずつ更新される。ただし、プロセスがファイルを握り続けているためディスクは解放されず、再起動するまで空き容量が回復しない、という副作用もある。
だからといって完全に無関係ではない。Debian系では「needrestart」や「debian-goodstuff」が、更新後に古いライブラリをメモリに読み込んだまま動いているプロセスを検出し、ユーザーに再起動を勧めてくれる。systemd環境で「daemon-reexec」を掛けても、systemd自身の全スレッドが更新されるわけではないので、結局は再起動がいち確だ、という運用者の実感もある。
Linuxの名前空間は、PID・ネットワーク・マウントポイント・UTS（ホスト名）などをプロセスごとに分離する。Dockerはこの仕組みを組み合わせ、ホストと同じカーネルを共有したうえで、プロセスから見えないリソースを作る。まさに「中身だけ別のOSのように見せる」実装だ。
Linuxはカーネルの更新にも再起動を要するが、その手間を減らす工夫が二つある。ひとつはkexecで、BIOSやUEFIを経由して新しいカーネルを直接起動するため、POST処理が省略され、メモリに載せ替えるに近い速さで再起動できる。そしてもうひとつがライブパッチだ。カーネルの関数エントリにフックを仕込み、新しい関数へ分岐させる。hotplugやkpatchが代表例で、セキュリティ修正に限れば再起動なしで適用できる。
macOS：スナップショットと読み取り専用システムボリューム
macOSの思路も興味深い。Time Machineは、APFSのスナップショットを作り、ブロックが書き換えられるたびに差分を退避していく仕組みで、データの変更履歴を追えるようにする。スナップショット時点のファイルと現在のファイルは同一視されない。更新前の状態に容易に戻せる一方、更新後のディスク容量は減っていく。
さらにmacOSは、システムボリューム自体を読み取り専用にして、マウントの掛け直しで更新を適用する方式を採用した。OS更新の失敗を大きく減らす設計だが、一方で問題も起きた。更新の途中でSSDの故障率が跳ね上がった、という報告だ。読み取り専用なら壊れない、とは限らないことを示した例と言える。
OSのバージョン管理では、macOSはアプリごとに「動くmacOSのバージョン帯」を宣言させ、OS側が適用条件を判定する方式をとる。これに対しLinuxディストリビューションは、配布時点でアプリとライブラリの組み合わせを固定し、ユーザー側では基本的にバージョン差異を扱わない。カーネルについてはmacOSも同じで、その組み合わせを維持するため、OSの大きな更新とは事実上カーネルの更新を指す。そしてiOSやChromeOSでは「SSV（static system volume）」——読み取り専用のシステムボリュームをマウントし直す方式がさらに徹底されている。
ホットパッチとセキュリティ：再起動を待たないための工夫
Microsoftも再起動のコストを理解している。同社はセキュリティ更新プログラムを「Critical」と「Important」に分類してきたが、2016年9月からは「重要」「緊急性が高い」「低」の3段階に変更された。Criticalの修正を再起動を避けて当てるために入れたのがホットパッチングであり、これは「セキュリティ更新を適用したが再起動していない」状態を埋めるための仕組みでもある。
もっとも、ユーザー側の実態は厳しい。更新の総量が積み上がってディスクが空き、インストールできない、という報告は後を絶たない。仮想メモリを無効化して対応しようとする例もあるが、推奨はされない。メモリが不足してプロセスを退避させるページファイルは、無効化するとメモリ不足でプロセスが即座に死ぬリスクを上げるだけだ。SSD寿命への影響を気にする声もあるが、SSDの寿命はベンチマークのように書き込み量で単純に決まるものではなく、通常の使用で寿命を心配する必要はない、という見方が実際には優勢だ。
そして再起動の回避策として時折持ち出されるのが、休止状態とスリープの混同だ。スリープはRAMに給電して状態を保持する仕組みで、放電による劣化は起きるが、メモリをディスクに退避する働きはない。RAMの内容を退避して電源を落とすのはハイバネート（休止状態）であり、Windowsではファイル単位ではなくページ単位で退避する。スリープと休止状態を混ぜて覚えていると、「更新が当たったのに再起動していない」状態が延々と続くことになる。カーネルとシステムイメージが書き換わったマシンに、スリープから戻ってきた古いプロセスとレジスタ状態がそのまま復活する——想像するだけでも気分のよいものではない。
結局、再起動は「一番確実で安い手段」
全体をまとめると、再起動が要求される理由は次の三点に集約される。第一に、実行中のコードやライブラリは、メモリマッピングとファイルの共有モードのせいで、動かしたままでは安全に差し替えられない。第二に、差し替えた新旧の状態が混在したまま動き続けることが、いちばん予測不能な不具合を生む。第三に、その混在を片付ける最も安くて確実な方法が、状態をまるごと捨てて最初から起動し直すことだからだ。
だからこそ、OSベンダーは「再起動せずに済ませる」方向へ技術を進化させてきた。Windowsは共有モードとSXSとCBS、そしてホットパッチ。Linuxはinodeの寿命の性質とkexec、ライブパッチ。macOSとiOSは読み取り専用のシステムボリュームとスナップショット。それぞれ別々の道で、同じ問題——動き続けている機械の中身を入れ替える——に取り組んでいる。
次に見知らぬ人から「とりあえず再起動してください」と言われたら、それは相手を突き放しているのではなく、機械が最も誠実に直る順番を提案しているのだと理解しておきたい。そしてその再起動を何週間も先延ばしにしている自覚があるなら、ディスク容量を確認して、今夜のうちに実行するのが、結局いちばん手っ取り早い。
ネットの反応
DLL地獄の世代なので「再起動してください」を見ると条件反射で嫌な顔になる。あの頃は何を直したかったのか分からないまま再起動してた
Linuxは再起動要らずと言いつつneedrestartが延々と再起動すべきプロセスを列挙してくるの、思想と現実の差で笑う
スリープと休止状態を混同してる人ほんと多い。RAM給電版とディスク退避版で全く別物なのに
WinSxSの肥大化はどうにかならないのか。更新のたびに容量が減っていくのが精神的にきつい
macOSの読み取り専用システムボリューム化は賛否あったけど、更新の失敗が減ったのは事実。SSD故障率の件は別問題として重いけど
kexecとライブパッチの存在は初耳だった。サーバー管理者からしたら再起動ゼロは夢の仕組み
AIの所感
「再起動してください」はユーザーにとって最もイライラする指示の一つだが、技術的な中身を追うと、むしろOSが誠実さを見せている場面だと分かる。動き続けているプログラムのコードとデータは、メモリマッピングとファイルロックの性質により、安全に交換できない。Linuxのようにinodeの寿命を利用して段階的に置き換える道もあれば、Windowsのように共有モードとSXSで同居させる道、macOSのようにシステム自体を読み取り専用にしてマウントを掛け替える道もある。どの道も、新旧が混在した状態で走り続けるという最悪の状況を避けるための工夫だ。一方で、更新の蓄積でディスクが埋まり更新できない、SSDを疑いたくなる確率で壊れる、といった現実の問題が残っているのも事実である。ユーザー側にできる最も合理的な対応は、更新と再起動を可能な限り当日中に済ませ、状態の混在を長く引きずらないことだ。先延ばしにした再起動は、いつか必ずもっと高い代価で戻ってくる。