WindowsからXubuntuへ開発環境を移した記録――移行前後に確認したこと

Windows 11の最小システム要件を満たさないサブノートPCで、WSL2とDocker Desktopを使っていました。そのPCでWindows 11を使い続けるのをやめ、Xubuntuへ移行しました。

この記事では、移行前に何を調べ、何を退避し、移行後にどこを確認したかをまとめます。インストールコマンドを順に実行するためのガイドではなく、開発環境を移す際の判断と確認の記録です。

移行前後の性能を同じ条件で測定した比較記事ではありません。第1部では移行を決めた理由と初期動作の結果、継続利用の評価計画を、第2部では準備から設定の点検までを紹介します。

第1部：Windows 11を使うのをやめるまで

対象環境と記事の範囲

項目	内容
移行前	Windows 11、WSL2、Docker Desktop
移行先	Xubuntu 26.04 LTS系、amd64
ハードウェア	2コア4スレッドのCPU、メモリ16GB、内蔵SSD
主な用途	VS Code、Claude Code、Codex CLI、ブラウザ、Dockerによる開発
インストール方針	Windowsとの併用ではなく、内蔵SSDのOSを置き換える

環境欄は移行当時の構成です。機種ごとのBIOS設定や各ツールの導入方法は扱わず、このPCで行った確認と、ほかの環境でも検討できる観点を分けて記載します。

先に負荷を測り、移行する理由を整理する

OSの置き換えに入る前に、重さの原因を切り分けました。熱によるクロック低下と、CPUやメモリの不足では、先に検討する対処が異なるためです。

ACアダプタをつないで再起動し、ログイン後に5分待ちました。その後、何もしない状態を3分、普段の重い作業を再現した状態を10分測定しました。これは今回の測定条件であり、すべてのPCに必要な測定時間という意味ではありません。

見る項目	切り分けの観点
熱	負荷中の温度上昇とクロック低下が重なっていないか
CPU	普段の作業でCPU使用率の高い状態が続いていないか
メモリ	重い作業中に空きメモリが不足していないか
ディスク	ディスクの高負荷が続き、作業を待たせていないか

この事例では、熱によるクロック低下よりも、CPU使用率の高さと空きメモリの不足が問題と判断し、移行しました。ただし、ここで分かったのはWindows環境での負荷の状況です。Xubuntuへ変更すれば解消する、という証明ではありません。

初期動作の結果と、継続利用の評価を分ける

移行と初期セットアップを行い、Wi-Fi、音声、タッチパッド、輝度キー、日本語入力などの初期動作を確認しました。

一方で、移行前後の性能を同じ条件で測定した比較結果は示していません。WindowsでCPUやメモリが不足していたことだけから、OS変更の効果を数値で断定することはできません。

継続利用の判断には、普段の作業を回しながら2週間試す計画にしました。次の基準は今回の用途に合わせた評価計画であり、合格した結果でも、一般的な推奨基準でもありません。

Xubuntu上で負荷とメモリを確認する

以下は、移行後のXubuntuのターミナルで実行する確認用コマンドです。Windows側の負荷測定とは別で、設定変更やファイル削除は行いません。vmstatとfreeが利用できる環境を前提とします。

CPUの動きやスワップ入出力を継続して見るには、次を実行します。

vmstat 3

3秒間隔で表示が続くので、終了するときは Ctrl+C を押します。CPUなどの初回の統計は起動後の平均のため、作業中の変化は2行目以降を見ます。idはCPUのアイドル時間の割合、siとsoはスワップの読み込み・書き出しの量です。単発の値ではなく、普段の作業中にどのような状態が続くかを見ます。このコマンドだけで温度やクロックまで確認できるわけではありません。

利用可能なメモリの目安を見るには、別のターミナルを開くか、vmstatを終了してから次を実行します。

free -m

結果は1回表示され、自動で終了します。Mem:行のavailableは、スワップせずに新しいアプリケーションへ使えるメモリ量の推定値です。free列だけで判断しないようにします。-mの表示単位はMiBです。下表の1.5GBという基準と比べる際は、単位をそろえて読みます。

これらは継続利用の評価を補助するもので、このコマンドを実行しただけで移行前後の性能比較が成立するわけではありません。

評価項目	不合格とする条件
ウィンドウ切り替え	10回中9回が1秒以内という条件を満たさない
メモリ	重い作業中にfree -mのavailableが1.5GBを下回る
VS Codeの入力	入力遅れに1日3回以上気づく日が3日ある
開発の停止	OSや環境が原因で、1日2時間を超えて止まる日がある
保守時間	2週間で合計2時間を超える
Windowsが必要な作業	2週間で2回以上ある
日本語入力	変換や入力ができないことが2週間で3回以上ある

OSの置き換えが終わることと、開発環境として使い続けられることは別です。初期動作だけで移行成功と結論づけず、入力の快適さや作業停止、保守にかかる時間まで評価する計画にしました。

第2部：移行前後に確認したこと

1. Windowsが動くうちに、データと設定を退避する

用意したものは、データ退避用の外付けSSDまたはHDD、別のUSBメモリ、ACアダプタ、手順やログイン用メールを確認できる別の端末です。

退避用のディスクを、インストール用USBとして使わないでください。 インストールメディアを書き込むと、そのディスクの中身が消えます。

退避はWindowsが動いているうちに済ませ、Windows側とWSL側を分けて整理しました。

対象	退避・確認する内容
作業リポジトリ	未コミット・未pushの変更を確認し、必要な変更をGitHubへ反映する
WSL側の設定	SSH、Git、シェル、開発ツールの設定を退避する
リポジトリ外の設定	.env、.env.*、.clasp.jsonなどを洗い出す
入れ直し用の一覧	手動導入したaptパッケージ、グローバルnpmパッケージ、リポジトリの一覧を残す
Windows側	設定ファイルとDocuments、Desktop、Downloadsを退避する
ブラウザ・ネットワーク	ブラウザの同期状態とWi-Fi接続情報を確認する

シェル設定は、退避することと、そのまま新環境へ上書きすることを分けました。WSL固有のパスやコマンドを含む設定は参照用に残し、新環境で必要な部分を選んで戻す方針です。

また、移行直後の待ち時間を減らすため、ChromeとVS CodeのLinux用インストーラーを先に保存しました。必要なツールを一覧にしておくと、データの復元とツールの再導入を分けて進められます。

2. インストール用USBと、書き込み先を確認する

インストール用USBの準備では、対象のISOファイルと、それに対応するハッシュ値を照合する工程を設けました。リリースが異なるファイルの値を取り違えないことが確認点です。

USBへの書き込みにはRufusを使いました。書き込む前に退避用の外付けディスクを外し、対象がインストール用USBであることを確認しました。

ここではRufusの設定値をほかのPC向けの推奨として示すのではなく、データ退避先と書き込み先を取り違えないことを準備の要点とします。

3. OSを消す前に、BIOSとUSB起動を確認する

このPCでは、BIOSの確認・更新をWindowsの削除前に行いました。移行後にWindows上の作業が必要だと分かって困らないよう、メーカーが提供する保守方法を先に確認するためです。BIOS更新そのものを、すべてのPCで必要な移行作業とする意図はありません。

USB起動では、高速起動、起動メニューの待ち時間、USBストレージブートを確認しました。このPCでは、高速起動が有効で待ち時間がないと、USBを選べないことがありました。

Secure Bootは有効のまま試し、起動できました。これは当該環境での結果です。BIOSの項目名や起動方法は機種によって異なるため、ここでは共通の操作手順として扱いません。

BIOS情報とSecure Bootの状態を調べる

Windowsを消す前のBIOS情報は、WindowsのPowerShellで確認できます。WSLやXubuntuのターミナルで実行するコマンドではありません。

Get-CimInstance Win32_BIOS | Select-Object SMBIOSBIOSVersion, ReleaseDate

BIOSのバージョンとリリース日時が表示され、自動で終了します。これは現在の情報を取得する操作で、BIOSの更新は行いません。また、この結果だけでは最新版かどうかは判断できません。更新の要否は、対象機種のメーカー提供情報と照らして考えます。

Xubuntuの試用環境やインストール後の環境で、mokutilが利用できる場合は、XubuntuのターミナルでSecure Bootの状態を調べられます。

mokutil --sb-state

状態を表示して終了します。有効・無効の表示を確認するためのもので、このコマンドはSecure Bootの設定を変更しません。コマンドが見つからない場合や状態を取得できない場合は、無効だとは判断せず、そこで確認できなかったものとして扱います。

4. 試用環境で動作を確認してからインストールする

USBから試用環境を起動し、インストール前に次の点を確認しました。

• Wi-Fiで接続し、Webページが開けること
• 音が出ること
• タッチパッドが動くこと
• 輝度キーが効くこと

このPCでは、いずれも動作しました。どれかが動かなければ、インストールを中止する判断にしていました。

インストール時は、内蔵SSDの容量と型番を確認してから、Windowsを置き換える方式を選びました。最後の確認画面でも、変更対象が意図した内蔵SSDだけであることを確認しました。

ディスクを消去する段階と、試用環境で動作を確かめる段階を分けたことが、今回の移行で設けた区切りです。

5. 開発ツールを導入し、必要な設定だけを戻す

初期セットアップでは、次の順序で作業しました。各ツールの導入コマンドではなく、復元する対象と順序の記録です。

順序	作業
1	システムを更新する
2	保存しておいたインストーラーからChromeとVS Codeを導入する
3	Git、GitHub CLI、Pythonのvenv・pipなどを導入する
4	Docker Desktopではなく、Docker EngineとComposeプラグインを導入する
5	Claude CodeとCodex CLIを導入する
6	nvm、Node.js LTS、claspを導入する
7	退避した設定を戻す。シェル設定などは参照用に分ける
8	Windowsの認証ヘルパー参照が残っていないか確認する
9	平文の認証情報が戻っていないか点検する

ツールの導入とログインは別の工程として扱いました。インストールが終わっただけでは、以前と同じアカウントやリポジトリを利用できるとは限らないためです。

また、設定を復元する際は、古い環境のパスや認証ヘルパーへの参照をそのまま持ち込まないようにしました。退避したファイルをすべて上書きするのではなく、新環境で使うものを選ぶ方針です。

6. VS Codeの同期後に、Linux向けの設定を点検する

VS Codeでは、他端末の設定や拡張機能を同期で取り込む方針にしました。ただし、同期による取り込みと、Linux向けの調整は別の作業として扱います。

点検対象	確認すること
改行コード	files.eolなどの設定が、リポジトリの方針や扱うファイルに合っているか
メモリ上限	TypeScriptサーバーなどに設定した独自の上限値を、新環境でも引き継ぐ必要があるか
パスやコマンド	Windows向けのパスやwslviewなど、新環境に存在しない参照が残っていないか
MCPなどの接続設定	平文のAPIトークンや、以前の接続方式が残っていないか

この表は点検の観点であり、すべての設定が実際に存在した、または変更済みだったという実績を示すものではありません。

同期後にLinux向けの調整を加える場合は、再同期でほかの端末や取り込み済みの設定に与える影響も考える必要があります。この記事では、同期画面の選択肢や上書き操作の案内ではなく、取り込んだ後の点検に範囲を絞ります。

日本語入力は、このPCではMozcを追加調整せずに使えました。全角／半角キーで切り替わったことも、この環境で確認した結果です。

7. 設定の復元後に、認証情報と接続を点検する

設定の復元や同期では、古い接続設定や認証情報も持ち込む可能性があります。設定ファイルだけでなく、自動バックアップ、過去の会話履歴、参照用に戻した設定も点検対象にしました。

確認する内容は、新環境から接続できるかどうかだけではありません。不要になった認証情報が残っていないか、同じトークンを使う別の端末がないかも、対応を決める際の確認点です。

古い認証情報が見つかった場合は、設定からの除去、接続方式の変更、トークンの無効化を分けて考えます。無効化すると、同じトークンを使っている別の端末で接続が止まることがあるためです。漏えいが疑われる場合と、単なる設定整理では対応の緊急度も異なるので、一律の切り替え順は示しません。

この移行では、Claude CodeからNotionへ接続できることも確認しました。ただし、新しい接続が使えることと、古い設定や認証情報が残っていないことは別です。接続確認だけで点検を終えないようにしました。

8. 「接続済み」と、実際に使えることを分けて確認する

移行後、Bluetoothキーボードが接続済みと表示されるのに、文字を入力できない事象がありました。このPCでは、PC側からペアリングをやり直した後に入力できました。

この結果だけで、同じ症状の原因や対処を一律に決めることはできません。今回の記録から残したいのは、接続済みという表示だけで動作確認を終えず、実際に文字を入力するところまで確かめる、という点です。

Bluetooth機器の状態を調べる

bluetoothctlが利用できるXubuntuでは、ターミナルから対話モードを開きます。入力できないキーボードとは別に、内蔵キーボードなどの操作手段を用意します。

bluetoothctl

開いた対話モード内で、次を1行入力します。以下はbashへ直接入力するコマンドではありません。

devices

一覧に対象機器があれば、そのアドレスと名前を確認します。次は書式例です。対象機器のアドレスを一覧に表示された実際のアドレスへ置き換えてから、同じ対話モード内で実行してください。

info 対象機器のアドレス

Connected、Pairedなどの表示を確認します。表示項目は環境によって異なり、一覧に機器がない場合や情報を取得できない場合も、この確認だけで原因は特定できません。対話モードを終了するには、次を入力します。

quit

ここに載せたのは機器一覧と状態を調べる操作だけです。登録の削除や再ペアリングは行いません。結果を他人に共有する場合は、機器のアドレスや個人を特定できる名前を伏せてください。

まとめ

今回の移行では、OSを入れ替える操作だけでなく、移行前の負荷の切り分け、Windows側とWSL側の退避、復元後の設定と認証情報の点検までを一続きの作業として扱いました。

試用環境と移行後の初期動作は確認できました。一方、性能改善の定量的な比較結果や、2週間の継続利用で評価基準を満たしたという結果は、この記事では示していません。

移行を検討する際は、今回の設定値や操作をそのまま再現するよりも、何を失うと困るか、どこで中止するか、何を確認したら使い続けると判断するかを、自分の作業に合わせて決めるための参考にしてもらえればと思います。