
Windowsでセルフホステッド(自宅クラウド)すべき5つの理由
Googleやマイクロソフトなどのテック大手と同じようなクラウドサービスを、手もとのパソコンで動かすセルフホステッド。アプリはFOSS(Free and Open Source Software)が基本であり、ソースコードが公開されていて、だれでも自由に無償で使える。
高額なサブスクで提供されるクラウドサービスの代替アプリも、たいていは迷うほどの数が見つかる。ビジネス用でもNotionやTableau、Slack、Salesforce、Zoomの代替アプリなんてのが揃っている。
そのうえ、セルフホステッドは米国発祥の「今年はなにも買わない」トレンドにもあっている。新しいパソコンは必要ない。そればかりか、いま課金しているサブスクをいくつもキャンセルできるかもしれない。
というわけで、この記事は、これまでnoteに書いてきたセルフホステッドの記事の原点というか「そもそもなんでWindowsでCasaOSなの?」をテーマにしてみる。一番のポイントは「かんたん」だからなのではあるけど、5つほどよいポイントを書いてみた。
1. 始めるのがかんたん
手もとに「Windows 11 Homeが動くパソコン」があれば、15分ほどで、少々手間どったとしても30分後にはCasaOSのダッシュボードは立ち上がり、セルフホステッドが動いている。アマゾンでマウスカチカチすら必要ない。本当にかんたんだ。
「MacBook Airユーザーなんだけど?」であれば、メモリが16GBの、メルカリで売っているリース落ち1万5000円ほどのDellやLenovoのノートパソコンがおすすめ。型番調べてメモリ増設できるモデルを選ぶのもよい。MacBook Airは3万円でメモリ8GB増設がやっとだけど、Windowsなら1万5000円でメモリ16GBにSSD 500GBほどのノートパソコンがまるっと1台手に入る。
なお、CasaOSで使うメモリはアプリをあれこれ10個ほど同時に動かしても4GBほどで、かつWSL(Windows Subsystem for Linux)の「使うときに必要な分だけ」メモリを確保する仕組みから、お試しであれば8GBでも問題ない。
また、CasaOSというと、安価なミニPCにDebianやUbuntuを入れたり、Synologyなどの専用NASやRaspberry Pi(ラズパイ)に構築する記事が目に付く。それでもいいんだけど……どれも「動かしてみた」までは手順どおりに進めればどうにかなるものの、何年かのスパンで長く動かすにはLinuxやDockerに詳しくなるのはもちろん、その機器特有のクセや不具合回避に「ムダに」熟練する必要もあって、わりとしんどいのだ。
私はいまではWindows一択だ。WindowsのWSLはとんでもなく使い勝手がよくて、開発環境だけでなく本番環境にさえ「WSL=Linuxを動かす標準プラットフォーム」として、もっともっと広まっていくと確信さえある。

2. バックアップがかんたん
Windowsで動くCasaOSは、iPhoneと同じくらいバックアップやリストアがかんたんだ。
だれもが、iPhoneの機種変更を一度は経験したことがあると思う。手間ゼロあるいはわずかな手間で、古いiPhoneから新しいiPhoneにまるっとデータの引き継ぎがされる。iPhoneを壊してしまった場合も、iCloudのバックアップデータを使ってできる限りの復元がされて、前と同じ状態になる。
CasaOS(WSL Ubuntu)は、Windowsからは「ext4.vhdx」として見える。このたったひとつのファイルに、仮想マシンの情報やOS、Docker、アプリとその設定、データなど「すべて」が含まれている。そして、このファイルをUSBドライブなどに入れておけば、どんなWindowsパソコンでも、まったく同じCasaOSを動かせる。

基本は手動のバックアップ。CasaOSで[設定 → シャットダウン]してから、エクスプローラーで ext4.vhdx をUSBドライブなりなんなりにコピーすれば完了だ。そう、ファイルのサイズがでかいだけで、オフィスドキュメントのコピーと何も変わらない。
ファイル(ext4.vhdx)のある場所はちょいとややこしい。検索すればよさそうなもののWindowsの検索機能って使い物にならないので、直接探すほうが早いかもしれない
(C:\Users\%USERNAME%\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx)。
バックアップを自動化したい場合は、PerplexityなどのAIに「Windowsでext4.vhdxのバックアップを取得するためのバッチスクリプトを書いてください。バックアップ前にWSLを停止し、バックアップ後にWSLを起動させてください」といったおねだりをすれば、次のようなスクリプトを書いてくれる。DドライブはUSBドライブなどを想定しているようだ。もちろん、スケジュール実行の設定手順についても丁寧にアドバイスしてくれる。
@echo off
setlocal enabledelayedexpansion
:: 管理者権限チェック
NET FILE 1>NUL 2>NUL
if '%errorlevel%' neq '0' (
echo 管理者権限で実行してください
pause
exit /b
)
:: バックアップ設定
set WSL_VHDX_PATH="C:\Users\%USERNAME%\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx"
set BACKUP_DIR="D:\wsl_backups"
set TIMESTAMP=%date:~0,4%%date:~5,2%%date:~8,2%%time:~0,2%%time:~3,2%
set BACKUP_FILE=%BACKUP_DIR%\ext4_%TIMESTAMP%.vhdx
:: WSL停止
echo WSLを停止中...
wsl --shutdown
timeout /t 5 /nobreak >nul
:: バックアップ実行
echo バックアップ作成中 %BACKUP_FILE%
if not exist %BACKUP_DIR% mkdir %BACKUP_DIR%
copy %WSL_VHDX_PATH% %BACKUP_FILE%
:: エラーチェック
if errorlevel 1 (
echo バックアップ失敗
exit /b 1
)
:: WSL再開
echo WSLを起動中...
wsl -d Ubuntu
echo 完了
pause
そして、新しいパソコンを買ったり、セルフホステッド専用のパソコンを用意したら、USBドライブをパソコンにさして次のようなコマンドを実行して、コピーしておいたファイルからリストアする。
wsl --import Ubuntu c:\CasaOS "D:\wsl_backups\ext4_202502051116.vhdx" --vhd
これだけで、苦労して安定稼働させた10ほどのアプリも、Tailscaleでのセキュアなアクセスもそっくり復元される。パソコンが壊れたときの復旧に使えるのはもちろん、世界中のどこででも「Windowsが動く何か」があればそれでCasaOSを元どおりに動かせる。
なお、バックアップに限らず、WSL関連のコマンドはググってしまうと古い情報や、近ごろの日付でも古い情報をなぞっただけのサイトがたくさん出てくる。ので、マイクロソフト本家のページをみるのがおすすめ。
外部メディアへのファイルバックアップは、もちろん使い慣れたWindows用バックアップアプリでもOK。Linuxや仮想化プラットフォームの「無限とも思える」ほど流派が分かれるバックアップ流儀をマスターする必要はない。
私は無償のDuplicatiを使っている。Duplicatiは高度な暗号化や重複データ排除も備えていて、バックアップ先がUSBドライブでもクラウドストレージでも、設定変更なしで最適なバックアップができるのを気に入っている。酷評も目に付くのだけど、解決に向けた協力者が登場すると逃げたりID削除をしたり、強い言葉での罵倒とあわせて「〇〇に乗り換えました」と特定のアプリを推す傾向が気になったりして、まあ、無視でよさそう。
なお、Windows用のバックアップアプリでは「\wsl.localhost\Ubuntu\DATA」といったようなパス指定をすることで、WSLのファイルレベルバックアップもできる。とはいえ、WindowsからWSLのファイルへのアクセスはけっこう遅く、効率が悪いので、使わなくてもよいかと。便利そうだけど。
ちなみに、CasaOSで動かすアプリごとのバックアップは、私はとっていない。それぞれのアプリでDBが動いているなどして静止点の確保が難しいのと、バックアップが大変そうなアプリほど日次でバックアップファイルを自動作成していたりするのが理由。あれこれ試した結果、ext4.vhdxをコピーするだけにしている。

3. セキュリティ対策がかんたんで万全
セルフホステッド界隈のフォーラムをみていると、わりと頻繁にセキュリティ侵害された話題が出てくる。セキュリティ対策に年間で何億円、何十億円とかける企業のクラウドサービスと同じようなことを、セキュリティ対策予算ゼロでど素人もやっているのだから、まあ、当然といえば当然なのだ。
これまでにnoteで記事にした手順では、CasaOSのアプリへのアクセスはTailscaleを入れたiPhoneやパソコンからに限定される。パブリックなクラウドサービスと同じようにみえつつも、巨大な企業が社内システムへのアクセスで使う仕組みと同じの、もっとも高いレベルでのアクセス制限がかかっている。そう、安心安全保障型だ。
しかしながら、CasaOSをパブリックにするのも実にかんたんだったりする。一度ならずとも、やってみたくなる(私もやってみた)。ルーターのポート開けたり、なんならDMZに置いてみたりして。その場合は、Windows 11が標準でもつセキュリティ機能が役立つ。
たとえばランサムウェア対策もWindowsは標準でもっていて、「フォルダー単位で、特定のアプリ以外からのファイル変更を禁止」がOSレベルでできる。デフォルトではこの機能はオフなのだけど(Zoomなどを使うとエラー出ちゃう)、オンにするだけでファイル改ざんを防いだり緩和できる。

ネットにはセルフホステッドをリモートから管理する方法についての記事も多いが、それって「悪者用に外部からアクセスできる仕組みをつくってあげる」ことでもある。
私たちは、ググった結果からついつい「分かりやすそうな記事どれかなー」で参考にするサイトを選んでしまうが、それがセキュリティ対策の観点でもっともすぐれた、網羅された記事かどうかはわからない。むしろ逆で「セキュリティ的に穴だらけなことを気にしない記事だからこそ、シンプルにまとまっていて、分かりやすくみえた」可能性が高いだろう。
で、Windows WSLで動くCasaOSにはこの心配がない。「CasaOS(Ubuntu)を動かしているWindowsからしかアクセスできない」の原則が、このセキュリティ対策で大きく効いてくる。「Windowsをのっとる」というハイレベルなチャレンジを成功させない限り、だれも外からはCasaOSにもアクセスできないのだ。
「外部からアクセスできる仕組みをつくってあげる」の代表は、SSH(Secure Shell)やRDP(リモートデスクトップ)用のポートをあちこちで開けることだ。それに対し、WSLで動くCasaOSではSSHもリモートデスクトップ(に似た仕組み)も、外部にポートを開くことやポートフォワーディングの設定もなく使える。しかも、専用のアプリもいらない。
もちろん、WSLのUbuntuでもSSHは標準では使えない。そして、SSHを使えるようにする手順はネットにあふれているけど、その9割が間違っていたり、セキュリティホールを量産してしまう(ように見える)。必要なのはこの2行だけでほかにはいらない。
sudo apt install ssh -y
sudo systemctl enable ssh
あとは、CasaOSの「Terminalとログ」からアクセスすればよい。ユーザー名とパスワードは「WindowsにUbuntuをインストールしたときのUserとパスワード」を使う。

そして、セキュリティを気にしつつリモートでデスクトップ接続したい場合は、Windows(Pro)のリモートデスクトップではなく、Chromeデスクトップでよいと思う。これはGoogleのサイトを見ながら設定すればよいだけなので、手順は割愛する。
4. ほとんどのアプリが動く
セルフホステッドのアプリはほぼすべてがDocker使用を前提とし、「どんなデバイスでも動く」のが原則。
……ではあるのだけど、Appleシリコン(Mシリーズ)のMacやRaspberry PiといったArmベースのプロセッサーでは動かないアプリや、動くものの機能が制限されたり、特定の不具合をかかえていたり、あちこち試行錯誤しながら設定ファイルの編集が必要なアプリも実は多い。
インテルやAMDで動くWindowsであれば、ほとんどのアプリがそのまま動く。また、WSLでの動作報告も増え続けていて、問題が発見された場合の対応も早いように見える。
特にセルフホステッドを始めたばかりのころは、アプリが動かないときに何が原因なのかの勘も働かないわけで、「ほとんどのアプリが動く」という前提は切り分けもかんたんになるからうれしい。
5. アプリの動作が速い
ミニPCなどにCasaOSを動かすためにUbuntuをインストールした場合と(いわゆるベアメタル)、これまでに記事にしてきたようなWSL Ubuntu+Dockerとして動かす場合との性能差も気になると思う。
結論は「誤差レベルだから気にしないでよい」だろう。GPUを使った動画のエンコードなどでは大きな差が出ているものの、LinuxでのGPU利用は個人的には悪夢にしか思えないので、興味がなかったりする。

もっとも、リンク先の性能比較はWSLにとって客観的に見て「かなり不利」と思われる内容だ。おそらく、Proxmoxなどの代表的な仮想化プラットフォームと対決をしたら、ベアメタルが完全勝利するだろう。それがWSLでは同等あるいは誤差レベルの性能差におさまっているのだから、たいしたものだ。
くわえて、noteでもいつだったか書いたが、WindowsのCPU性能や電源の制御は、Linuxよりもすぐれていることが多い。Windowsでは同じ性能でもより低い消費電力で動いたり、アイドル時の電源制御が神がかっていたりする。逆に、CPUによってはWindows限定で「より高い消費電力で長時間動作させる」専用アプリが用意されていて、CPUをドーピング動作できたりする。
というか、そもそも、セルフホステッドのアプリはふだんは眠っていてCPUを使わない。非力なスペックでも数十もの同時アクセスに対応できる、地球にやさしいつくりだ。だから、ふだんづかいのWindowsと同居させても、なにも問題がないのだ。
それでも、これまで使っていたWindowsに新たな同居人が増えたのだから、これを機にWindowsの中身をダイエットしてみたくもなる。
そこで、おすすめは Win11Debloat。「勝手に立ち上がってバックグラウンドで動いて、しかも、かんたんには削除ができないWindows標準アプリ」も手軽に削除できるツールだ。シンプルすぎてインストールさえいらないのが面白い。
リンク先に記載のとおり、ターミナル(管理者)を立ち上げて、次のコマンドを打つだけで使える。もちろん、日本語環境でも問題なかった。
& ([scriptblock]::Create((irm "https://win11debloat.raphi.re/")))

Win11Debloatを実行すると選択肢が出る。私は「1」を選んでおまかせ削除や設定をしてから、もう一度同じように実行して「3」を選んで、改めて使わないアプリにチェックして削除している。

とまあ、セルフホステッドをはじめるうえでの漠然とした不安感や、どんなバックアップやセキュリティ対策をすればいいんだろうといった疑問に、ざっくりながらもなんらかの回答になっていたら幸いだ。
