メイン PC の OS を Windows から Linux (Ubuntu 26.04) に移行した話

Page content

先日、自宅 PC のメイン OS を Windows から Linux (Ubuntu 26.04 LTS) に置き換えた。

背景としては、最近 PC でやっている作業の殆どが AI のトレーニング、ローカル推論、そして AI エージェントの利用といった分野にシフトしたことにある。 Windows 環境でこれらを実行しようとすると、どうしてもシステムの安定性に欠けたり、パフォーマンス上のオーバーヘッドが大きかったりするのが気になっていた。 これは WSL (Windows Subsystem for Linux) を利用したところで、この傾向が変わるわけではない。むしろ仮想化層が加わる分、オーバーヘッドは余計にかかるのが現実だ。 自分は PC でゲームを遊ぶわけではないため、Windows でなければ絶対にできないことはほぼ存在しない。 仮に今後ゲームをプレイしたくなったとしても、現在の Steam は Linux (Proton) 上でそれなりに快適に動作するし、そもそも Windows を完全に消去するわけではない。 Linux と Windows のマルチブート構成にしておき、必要に応じて Windows に切り替えれば良いだけだ。

そのような理由から、メイン環境を Linux へと完全移行することにした。 移行プロセスや設定の記録、そして実際に運用してみた感想をまとめておく。

マルチブートとファイルシステムの課題

メイン OS を Linux に移行するとはいえ、Windows はマルチブート用としてディスクに残しておく。 そのため、移行後も Windows 側からデータにアクセスできる環境を整える必要があった。 ここで直面する一番の課題がファイルシステムだ。

WSL2 を利用すれば Windows 側から Linux の ext4 ファイルシステム等にアクセスすることは可能だが、コンテキストスイッチや仮想化のオーバーヘッドが大きく、パフォーマンス的に不満が残る。 一方で、Linux 側からであれば、いくつかの制限はあるものの NTFS パーティションに対して直接アクセスが可能だ。 そのため、基本方針としては「既存の NTFS ストレージをそのまま維持し、そこに Linux 側からアクセスする」という形をとりつつ、新規に Linux 専用のストレージ領域を用意して運用を開始することにした。

なお、昨今のストレージ(HDD/SSD)価格は高騰しており、新規で大容量 SSD を購入するのは躊躇された。 今回は新規のパーツ購入を避け、既存のストレージ構成を整理してドライブの 1 つを完全に空け、それを Linux 専用領域に割り当てることにした。 SSD の価格が暴騰する直前に、4TB NVMe SSD を購入しておいた自分を褒めたい。あの時買っておいて本当に良かった。

Linux 移行で実施した手順

今回の Linux 移行にあたり、具体的に行った作業手順を整理しておく。

Windows パーティションの縮小

システムドライブ内の Windows パーティションを縮小し、Linux インストール用の空きスペースを確保した。 昔は NTFS パーティションを安全に縮小するために Linux の Live環境から専用ツールを使う必要があり、データ破損のリスクと隣り合わせだった。 しかし、現在は Windows の標準機能である「ディスクの管理」からパーティションの縮小が簡単に行えるため、これを利用した。 ただ、Windows 標準の縮小機能は、ディスク後方に配置された移動不可能なシステムファイルの影響により、実際の空き容量に対して縮小可能なサイズが非常に少なく制限されてしまう傾向がある気がする。この点だけは相変わらず少し使い勝手悪い。

インストーラの準備と OS インストール

Ubuntu の最新 LTS バージョンである 26.04 の ISO イメージをダウンロードし、USB メモリにブート用イメージを書き込んだ。 作成した USB メモリから PC を起動し、先ほど Windows 側で空けたシステムドライブの未割り当て領域に対して Ubuntu 26.04 をインストールした。

ファイルシステム(/etc/fstab)の設定

ここからが実務的な Ubuntu の設定作業となる。 Windows と共用する NTFS パーティションを起動時に自動マウントするため、 `/etc/fstab` に設定を追加した。 この際、ファイルシステムのタイプには `ntfs` ではなく、必ず `ntfs3` を指定した。

最初、従来通りの `ntfs` を指定していたのだが、これだと FUSE (User-space File System) 経由でのマウントになってしまい、CPU オーバーヘッドが極めて大きくなってしまう。 これをカーネル直で動作する `ntfs3` ドライバーに変更することで、カーネル空間での高速な読み書きが可能になった。 また、 `ntfs` と `ntfs3` とで、ファイルシステム上のシンボリックリンクの扱いが大きく異なる。 後からマウント設定を切り替えるとシンボリックリンク周りでトラブルが発生するため、インストールの最初から `ntfs3` を選定しておくべきだ。

ホームディレクトリの英語化とキャッシュ対策

Ubuntu インストール直後、ホームディレクトリ配下にある「ドキュメント」や「ダウンロード」といった日本語のディレクトリ名を、端末での操作性を考慮して英語(Documents, Downloads 等)に変更・固定した。

また、AI トレーニングやパッケージ管理を行うと、 `~/.cache` や `~/.local` 配下に巨大なキャッシュファイルが大量に蓄積され、システムドライブ(SSD)を逼迫させる。 これを避けるため、消費量がデカくなることが予想されるディレクトリ群は、別途用意した大容量 NTFS ストレージ(`ntfs3` マウント領域)上に実体を作成し、ホームディレクトリからシンボリックリンクを張る形にした。

ホームディレクトリ自体を丸ごと別ストレージにマウントしてしまう(例えば `/home` を別パーティションとして別ディスクに割り当てる)方法もあるが、これだとそのストレージが Linux システム側に密結合しすぎてしまう。あくまでも別ストレージは純粋なデータ用として独立させておきたいため、ホームディレクトリごとマウントするのではなく、肥大化する特定のディレクトリのみを個別に逃がしてシンボリックリンクを構築するという構成を選択した。これなら、将来的なシステムの再構築や Windows 側からのデータ管理の際にも、無用な複雑化を避けられる。

NAS 接続の自動化

自宅の NAS に対しては、 `autofs` を用いて必要時にのみ NFS で自動接続する設定を行った。 これにより、ネットワークの切断時にシステム全体がハングアップするのを防ぎつつ、透過的に NAS のデータにアクセスできる。

デスクトップ環境のカスタマイズ

デスクトップの使い勝手を Windows 時代に近づけ、また自分好みの動作にするために、様々なツールを導入して調整した。

  • ファイラーの変更: Ubuntu 標準のファイラー(Nautilus)は操作感や機能面で自分のユースケースにイマイチ合わなかったため、軽量で高機能な `PCMan File Manager` (PCManFM) を追加でインストールしてメインのファイラーに据えた。
  • ブラウザの復元: Firefox 等のブラウザをインストールし、Windows 側からエクスポートしておいたブックマークや設定データをコピーして完全に復元した。
  • 日本語入力 (IME): 日本語入力環境には、現代的な `Fcitx5` と、自分が長年愛用している `SKK` (Simple Kana-Kanji) の組み合わせを設定した。
  • エディタ: もちろん `emacs` をインストールし、使い慣れた設定ファイルを移行して配置した。
  • 動画再生: メディアプレーヤーには実績のある `VLC` を選定してインストールした。
  • キーとマウスのカスタマイズ: `Input Remapper` を導入し、キーボードやマウスのボタン割り当てを細かくカスタマイズした。
  • ショートカットの整理: Ubuntu 標準のシステムショートカットのうち、ウィンドウメニューを開くショートカットなど、自分の作業の邪魔になる幾つかのキーバインドを無効化した。
  • リモート接続: 他の PC やサーバーへの接続用として `remmina` を導入した。
  • リソースモニター: システム負荷を可視化するため、Windows のタスクマネージャー風のモダンな UI を持つ `Mission Center` をインストールした。
  • ターミナル: Windows の標準的なターミナルでは、自分が設定したキーカスタマイズの一部がうまく反映されない問題が発生したため、高機能な `konsole` を追加でインストールして使用している。

Antigravity によるバイブコーディングでのツール自作

様々なアプリを試してみたものの、どうしても自分の細かい要望に合致するものが見つからなかったり、探すこと自体が面倒になったりした領域が存在した。 具体的には、オーディオ再生アプリと、画像ビューワである。 これらについては、AI エージェントである `Antigravity` に指示を出し、一気に「バイブコーディング」で自分専用のアプリケーションをスクラッチから開発させた。 作成したツールはデスクトップのシステムメニューに直接登録し、Windows 時代と同等以上の手軽さで起動できるようにした。

また、システム起動時に USB 接続している Bluetooth アダプタの初期化がうまく動かない事が多かったので、 `usbreset` コマンドを叩いて Bluetooth USB アダプタを強制的に再起動させる初期化スクリプトも `Antigravity` を使って一瞬で作成し、スタートアップに組み込んだ。 こうしたニッチなトラブルに対し、自力でシェルスクリプトやコードを書き下ろすことなく、AI に投げ捨てるだけで解決ツールが出来上がるのは非常に快適だ。

移行の教訓となった「WSL2 イメージ破損事件」

実は、今回の物理的な Linux 移行を進める過程で発生した、非常に手痛いトラブルがある。 それが、これまで開発や AI の実行環境としてヘビーに利用していた「WSL2 ディスクイメージの破損」だ。 実はこの事件そのものが、最終的に Windows を完全に捨ててネイティブ Linux デスクトップ環境へと一本化する決断を後押しする強い動機にもなっている。

元々の発端は、Windows 上の WSL2 で作業をしていた時のことだ。 WSL2 上で AI モデルのファインチューニングを実行していた際、処理が完全に反応しなくなり、やむを得ず強制終了したことがあった。 この強制終了の瞬間にイメージが破損したかどうかは不明だが、無理やりプロセスを落としたのだから、何らかの致命的なダメージが与えられていた可能性は極めて高い。

その後、Linux への移行を開始した当初、自分はそれまで Windows 側で使っていた WSL2 の仮想ディスクイメージ(ext4)を Linux 上で直接マウントしてデータをそのまま引き継ぎ、運用していた。 ところがある日、何かの拍子にそのイメージファイルが突如として完全に壊れてしまったのだ。

ただでさえ互換性に課題を抱えていた状況下で、Windows 側で強制終了によるダメージを受けていた可能性が高いディスクイメージを、Linux 上で直接マウントして使用するというのは、あまりにも無防備で危険すぎる行為だったと言わざるを得ない。 幸いにして、一部の重要データや Emacs の設定ファイル等は外部にバックアップしてあったため、すべてのデータを失うという最悪の事態は免れた。 とはいえ、バックアップしていたのはあくまでデータの一部であり、復旧できなかったファイルも少なくない。 これは今回の移行プロセスにおける、文句なしで一番の残念ポイントであり、深い反省点となった。

ただ、見方を変えれば、ディスクイメージの根本にそれだけのダメージが蓄積していたのだとすれば、あのまま Windows 上で WSL2 を騙し騙し使い続けていたとしても、いずれ近い将来に同じように破損していただろう。 その結果としてデータを失うリスクを考えれば、この痛烈なトラブルこそが、中途半端な仮想環境を廃してネイティブな Linux デスクトップ環境へと完全に脱出する決定的な引き金になったとも言える。

Linux デスクトップ環境の現在地と総評

細々とした設定や調整は他にも多々あるが、上記の環境構築を施した結果、現在は Windows 時代と比べてもほとんど違和感を覚えないレベルで、日々の業務や AI 開発を快適に運用できている。

しかし、冷静に総評を下すならば、Linux デスクトップ全体の「完成度」や「ユーザーフレンドリーさ」は、依然として Windows には及ばないと言わざるを得ない。 特にマルチメディア関連ツールの豊富さや、有料・無料アプリを問わないエコシステムの充実度に関しては、Windows の圧倒的な優位性は揺るがないだろう。

とはいえ、前述の通り、現代には AI エージェント(Antigravity)という強力な支援ツールが存在する。 アプリの機能が自分のユースケースに足りていなければ、AI に仕様を伝えて数分で自分専用のツールを作らせれば良いだけだ。これによって、Linux デスクトップのアプリ不足という伝統的な弱点は、現在においては大きな問題ではなくなりつつある。 もちろん、作れるのはあくまでちょっとしたツールやスクリプトのレベルであり、例えばプロのクリエイターが使用するような高度なマルチメディア編集ソフトウェアを AI で簡単に自作できるかと言えば、流石にそれは不可能だ。

そして最大の課題は、どれだけ AI に聞きながら作業を進められるようになったとはいえ、システムを不具合なく構築し運用するためにはそれなり以上のリテラシーが必要なのは間違いないので、決して万人に勧められるものではない。

しかし、AI モデルをローカルでブン回し、エージェントを日常的に稼働させるエンジニアにとって、オーバーヘッドのないネイティブな Linux 環境がもたらす安定性と圧倒的なパフォーマンスは、何物にも代えがたい魅力であることは間違いない。