はじめに：夢見るローカルLLM開発

「RTX 4060 Ti 8GBで日本語LLMを動かしたい」
そんな野望を抱え、私はDocker環境構築に着手しました。まさかこれが、Windowsとの壮絶な戦いの始まりになるとは。

① LOCAL LLMの機械学習へ向けてのスタート

目的： Japanese-stablelm-instruct-gamma-7bを4-bit量子化し、DockerでAPI化
環境： Windows 11 + WSL2 + Docker
理想： 手軽な開発環境から本格的なLLM推論まで

しかし、理想と現実の間には深い溝が待ち受けていました。

② 問題点：WSLという名の「便利な罠」

「Windows上でLinuxが動くなんて便利そう」ー そう思ったのが全ての過ちでした。WSLは開発者を甘やかす甘い罠だったのです。

根本的問題：

• WSLはWindowsの「客人」に過ぎない
• システムの深い部分で常に制限を受ける
• 破損時の回復手段が脆弱

③ 症状：REGDB_E_CLASSNOTREG ～ 呪われたエラーコード

wsl –install
wsl: WSL インストールが壊れている可能性があります
（エラー コード: Wsl/CallMsi/Install/REGDB_E_CLASSNOTREG）

このエラーは、WindowsのMSIインストーラーシステムが深く破損していることを示していました。

試みた修復（全て失敗）：

1. sfc /scannow、dism.exe ー Windows標準修復ツール
2. WSL機能の無効化・再有効化
3. Microsoft Storeからの再インストール
4. セキュリティソフト完全アンインストール

さらなる症状：

• WSL関連のすべてのコマンドがエラー
• 通常のアンインストールも不可能
• Windowsの「高速スタートアップ」によるディスクロック

④ 解決策あれこれ：試行錯誤の記録

フェーズ1：WSL修復という幻想（3時間）

• レジストリ編集によるMSI修復
• システムファイルの手動修復
• 様々な管理者コマンドの実行

結果： 一時的な改善もなく、根本解決には至らず。

フェーズ2：代替手段の模索（2時間）

• Docker Desktop for Windows（WSLなしモード）
• VirtualBox + Ubuntu
• Hyper-Vの直接使用

気付き： これらは全て「仮想化のレイヤー」を追加するだけ。根本的なパフォーマンス低下を招く。

フェーズ3：パラダイムシフト（決断）

ここで閃いたのは、あるシンプルな事実でした：

「このPCはLLM開発専用マシン。仕事用PCは別にある」

これが全てを変えました。WSLにこだわる理由が消え去った瞬間です。

⑤ 結果：Bazzite Linux ～ 苦難の先にあった光

選択：Bazzite Linux

Fedora Silverblueをベースにした不変OS。ゲーム/コンテナ開発に最適化されています。

決め手：

• 不変性：OS本体が読み取り専用で安定
• コンテナファースト：開発環境をコンテナで完全分離
• NVIDIAドライバ自動検出

インストールの試練（さらなる困難）

まさかの展開：「Windowsの呪い」はOSインストール時にも続きました。

パーティション地獄

GParted Live USBがフリーズ。ディスク認識エラー。自動パーティション分割失敗。

突破口： WindowsインストールUSBからの diskpart clean コマンド。これでようやくディスクがクリーンに。

セキュアブートの壁

error: ../../grub-core/kern/sb.c:192: bad shim signature

BIOSでセキュアブートを無効化することで解決。これが最後の障害でした。

成功：Bazzite起動

ついに、澄んだBazziteのデスクトップが眼前に。

最初の感動：

nvidia-smi

RTX 4060 Tiがネイティブに認識！ WSL時代の遅さとは別次元のレスポンス。

日本語入力設定

少し戸惑ったキーボード設定も、JIS配列（Mouse 109キー）に合わせた適切な設定で解決。

学び：技術的気付きと哲学

1. 「対症療法」から「根本治療」へ

WSLの問題は症状であって原因ではなかった。根本原因は「Windows上での仮想化」そのもの。

2. 適材適所の重要性

• ゲーム/Office：Windows
• 開発/LLM：Linux
• 専用マシンで役割を分ける勇気

3. 不変性の価値

Bazziteの不変OS設計は、開発環境の安定性において革命的でした：

システムを破壊する実験も安心

sudo btrfs subvolume snapshot / /backup_before_experiment

失敗したら

sudo btrfs subvolume delete /
sudo btrfs subvolume snapshot /backup_before_experiment /

現在の環境：理想的なLLM開発基盤

Distroboxで開発環境コンテナ作成

distrobox-create –name llm-lab –image ubuntu:22.04
distrobox-enter llm-lab

コンテナ内で

docker build -t japanese-llm .
docker run –gpus all -p 8000:8000 japanese-llm

まとめ：Windowsの呪縛からの解放

この旅で最も価値があったのは、問題解決のパラダイムシフトでした。

Before： 「壊れた環境をどう修復するか」
After： 「目的に最適な環境をどう構築するか」

WSLのエラーコード REGDB_E_CLASSNOTREG は、今思えば祝福のエラーでした。これがなければ、私はずっと「Windowsという檻」の中で開発を続けていたでしょう。

「しょうがないからUbuntuで」と妥協せず、Bazziteという最適解を選んだことが、すべての苦労を価値あるものにしました。

次のステップ：LLM開発本編へ

環境構築という「メタな問題」が解決した今、ようやく本来の目的である「日本語LLMの開発」に集中できます。

諦めないこと。 それが技術者としての唯一の、そして最強の武器です。

---

この記事は、実際のトラブルシューティング経験に基づいています。WSLの深いエラーからBazzite Linuxへの移行まで、約12時間に及ぶ戦いの記録です。