鯛焼ぷろじぇくと。Official Website 
このシリーズでは、数学の研究環境を整えていった過程を順番に記録しています。
前回は【WSL導入でOSが壊れた話】について書きました。まだの方は、先にこちらからどうぞ。
目次
何が起きたのかを整理
第3回では、WSLの導入を進めた結果、最終的にOSの初期化に至ったところまでを書きました。
この回では、その出来事を単なるトラブルとして終わらせるのではなく、「なぜそのような状態になったのか」を自分なりに整理しました。
まず、実際に起きたことを整理すると、次のようになります。
- PowerShellからWSL関連の機能を有効化しました
- 途中でコンポーネントストアに関するエラーが発生しました
- 深刻ではないと判断して再起動しました
- 再起動後、Windowsが正常に起動しなくなりました
- 自動修復でも復旧できず、最終的にOSを初期化しました
この流れを見たとき、最初は「トラブルに当たってしまった」と考えましたが、振り返ってみるともう少し構造的な問題がありました。
WSLの性質を誤解していました
当初の認識では、WSLは「Windows上でLinuxが動く便利なツール」という程度の理解でした。
つまり、
- アプリケーションを追加する
- 開発環境を整える
といった延長線上の操作として捉えていました。
しかし後から調べて分かったのは、WSLは単なるアプリケーションではなく、Windowsの内部機能と密接に関わる仕組みだということでした。
今回有効化した機能には、
- Windows Subsystem for Linux
- VirtualMachinePlatform
などが含まれていましたが、これらはOSの比較的低いレイヤーに関係しています。
この時点で、自分がやっていたのは単なるツール導入ではなく、
OSの構成そのものを変更する操作でした。
仮想化機能に関わっている
また、WSL2は内部的に、
- 軽量な仮想マシン
- 仮想化基盤（Hyper-V系の機能）
の上で動作しています。
つまり、WSLを有効にするということは、Windowsの仮想化機能を有効にすることです。
この認識は、作業中にはほとんど持てていませんでした。
当時は「Linuxが使えるようになる設定」という理解で進めていましたが、実際にはシステムの基盤部分に変更を加えていたのです。
エラーの意味を軽く見ていました
第3回で出てきたエラー、
「コンポーネントストアが破損しています」
というメッセージについても、当時は深く考えていませんでした。
コンポーネントストアは、Windowsの機能や構成を管理する基盤のようなものであり、そこに問題があるということは、
- システムの整合性が崩れている可能性がある
- 機能の追加や変更が正常に行えない可能性がある
という状態を意味していました。
その状態で、
- 仮想化関連の機能を有効にし
- システム構成を変更し
- 再起動を行った
結果として、起動に必要な整合性が保てなくなった可能性があります。
判断のどこに問題があったのか
今回の流れを振り返ると、問題は「操作手順」よりも「判断」にありました。
まず一つ目は、エラーの重さを正しく評価できていなかったことです。
エラーが出たときに、
- よくある環境構築のトラブルではないか
- 再起動すれば解決するのではないか
と考えてしまいました。
しかし実際には、そのエラーはシステムの根幹に関わるものでした。
二つ目は、操作の影響範囲を理解していなかったことです。
WSLの導入を、
- 開発ツールの追加
- 環境の拡張
として捉えていましたが、実際にはOSレベルの構成変更。
この認識のズレが、そのまま判断ミスにつながっていました。
WSLが問題だったわけではない
ここは誤解しないように整理しておきました。
今回の問題は、 WSLそのものが危険だったという話ではありません。
WSLは多くの環境で安定して使われており、開発用途としても非常に優れた選択肢です。
今回問題になったのは、
- 事前の状態（コンポーネントストアの不整合）
- 操作対象の理解不足
- エラーに対する判断
といった複数の要因が重なったことでした。
僕のPCの場合何かが合わなかったのでしょう。
この経験から得た考え
この出来事を通して、環境構築に対する考え方が大きく変わりました。
それまでは、
- 手順通りに進めればよい
- エラーは対処すればよい
という認識でした。
しかしこの時点で、どこに影響する操作なのかを理解する必要がある、と考えるようになりました。
特に、
- OSに直接関わる機能
- 仮想化などの基盤部分
については、より慎重に扱うべきだと感じました。
次に考えたこと
ここまで整理した時点で、次に考えたのは、同じような問題を避けるにはどうするかという点でした。
つまり、
- OSに影響を与えない方法はないか
- 問題が起きても切り離せる構成にできないか
という視点で選択を行うということです。
もちろん一般的な方法を第一候補に挙げることは自然な流れですが、他に方法はないのか？
熟練者ではないものでも安全にできる方法はないのかと考え、いくつかの選択肢を用意した上で選択する。
また、選択してうまくいかなかったときの損失を抑えることを考えたとき、最適な優先順序はどれかなど考える必要があると感じました。
次回は、【方針転換（壊さない環境設計へ）」について書きます。