約20年ぶりの自宅サーバ回帰——レンタルサーバの20年を経て、手元にデータを取り戻した話

この記事は、ひとぅブログ Deep の2本目です。

1本目では、WordPressをやめて静的サイトエンジンを自作し、記事をMarkdownで扱える形にした話を書きました。今回は、その延長線上にあるもう一段の話です。約20年ぶりに、自宅サーバへ戻った——2008年に片付けてから、ほぼ20年。そう言うと、懐かしさや技術オタクの回帰劇のように聞こえるかもしれません。でも、私にとっては「昔に戻った」のではなく、条件がそろったから、もう一度自分の足元に置けるようになった、という記録に近いです。

2003年ごろ、WindowsでIISやメールサーバ、FTPサーバを立て、自宅サーバを始めました。2008年ごろにそれを片付け、レンタルサーバへ軸足を移します。XREAやCORESERVER、海外のHostMonster（Bluehost）、Sixcore、そして長く使っているXServerなど、いくつかのサービスを渡り歩きました。自宅サーバをやめてから約20年。2026年のゴールデンウィークに、Linux MintとTailscale、そしてAIの支援を借りて、再び自宅にサーバを置きました。

手順書ではありません。どのコマンドを打ったかより、なぜ戻したか、何を守りたいか、何を手放したかを残す記事です。

2003年——Windowsでサーバを立てた頃

今から振り返ると、あの頃の「自宅サーバ」は、いま言うセルフホストとはかなり違います。インターネットに常時接続できる家庭自体が、まだ珍しかった時代です。2003年ごろ、WindowsマシンにIISを入れ、メールサーバやFTPサーバを立てました。自分のドメインからページが見え、メールが届き、ファイルが置ける——今の若い世代には想像しにくいかもしれませんが、当時はそれだけで十分にワクワクしました。1台に全部載せる集中ぶり自体が、むしろ楽しさの源泉でもありました。ネット上に「自分の場所」がある——その感覚は、20年経っても忘れていません。

当時の風景を、いま手元に残っている写真で確認できます。部屋の高い棚に、ベージュのタワー型PCを置き、その上に白いモデムを載せた——いわゆるDIY感たっぷりの、2000年代初期の自宅サーバそのものです。キーボードが壁に立てかけられ、ケーブルがごちゃごちゃしている。美しくはない。でも、自分で置いた感じが写真から伝わってきます。

ただ、当時の自宅サーバは脆いものでもありました。停電や回線断、Windows Updateの再起動、セキュリティの穴——家庭で24時間安定稼働を守るのは、趣味の延長というより、常に神経を使う仕事に近かった。それでも、1台に集約すること自体を重いと感じてやめたわけではありません。若さと、試してみたい衝動が勝っていたのだと思います。2008年ごろに片付けるまで、およそ5年間、続きました。

2008年——自宅サーバを片付け、レンタルへ

自宅サーバの熱は、2008年ごろまでに自然と収束しました。レンタルサーバへ軸足を移した理由は、大きく三つあります。

ひとつ目は安定です。ブログや家族のサイトを載せ始めると、「今日も見えるかな」と毎日気になる状態は続けにくい。プロのデータセンターで動いているほうが、読者にも家族にも申し訳ない、という感覚が勝ちました。

ふたつ目は容量とメンテの楽さです。ここは、よく言われる話とは少し違います。当時の自宅には、今思えば十分なディスク容量がありました。逆に、最初に触ったレンタルサーバは契約容量が小さく、写真やログ、メールボックスを載せるたびに「そろそろ限界かも」と感じる場面が多かった。2008年ごろに自宅サーバを片付け、レンタルへ本格移行したときも、レンタル側の容量は自宅より狭い、というのが実情に近いです。その後、レンタルサーバ同士の競争で契約容量は増え続け、載せ替えや移転が現実的になってきました。OSやミドルウェアの更新を任せられる楽さと合わせて、レンタル側の容量が追いついてきたことも、長く預ける理由のひとつになっていきました。

三つ目は書くことへの集中です。サーバをいじる時間と、記事を書く時間は、同じ1日の中で取り合いになります。20代の自分は、いじるほうが好きでした。でも運用が続くほど、「書くためのインフラ」にしたい気持ちが強くなっていきました。

レンタルサーバへの移行は、自宅サーバを諦めたというより、役割を外注したに近いです。2008年にタワー機を片付けてから、公開面の安定をプロに預ける年数のほうが、はるかに長くなりました。

レンタルサーバの20年——移転と「便利さ」の積み上げ

2008年以降、レンタルサーバは何度か移りました。最初の頃はXREAやCORESERVERといった、当時よく名前を見かけたサービスも使いました。英語圏のHostMonster（のちのBluehost系）で海外向けの実験をした時期もあります。Sixcoreを経由した移転もあり、現在の公開サイトの多くはXServer上で動いています。

移転のたびに学んだのは、便利さには代償があるということです。XREAやCORESERVERの頃は、PHP4とPHP5の狭間でコードを直す苦労もしました。HostMonster（Bluehost）系の海外サーバでは、日本からの距離とサポートの壁を味わい、向き不向きを学びました。Sixcoreを経由した移行は、データの持ち運びそのものが作業になることを思い出させてくれます。いまの拠点であるXServerは、容量とサポートのバランスが自分には合っていて、長く置ける場所になりました。

管理画面、PHPのバージョン、メール、SSL、バックアップオプション——サービスごとに良し悪しは違いますが、どこも「契約の中で完結する」設計です。自分で触らなくていい分、中身を直接見られない不安も少しずつ積み上がっていきました。どの事業者も悪いわけではありません。むしろ、お世話になった、というのが本音に近いです。

とはいえ、レンタルサーバの20年は否定できません。ひとぅブログを2007年からWordPressで続けられたのは、レンタルサーバがあったからです。家族のブログも、外から見える形で長く維持できました。停電の心配を読者に押し付けなくて済んだ。セキュリティパッチの大半を任せられた。移転の手間はあっても、公開の連続性は守れました。

自宅サーバへ戻ろうと思ったのは、レンタルサーバが悪いからではありません。役割分担をはっきりさせたい、という側面が大きいです。ひとぅブログの生データはXServer上にあり、GitHubでバックアップと履歴管理もしています。一方、家族のブログは公開サーバから完全に引き上げ、自宅側で扱うようにしました。レンタルサーバは「ひとぅブログの公開拠点」として残し、自宅は「家族のデータと複製の倉庫」——そう切り分けています。

「手元に生データがある」——戻ろうと思った本当の理由

レンタルサーバだけでは足りなくなった理由を、ひと言で言うなら「手元に生データが欲しい」です。

2026年に静的サイトエンジンへ移行し、記事をMarkdownファイルとして整えました。ひとぅブログについては、生データの置き場所はXServer、変更履歴のバックアップはGitHub——という形です。でも、家族のブログや写真、長年のメール、試行錯誤のログ——家族側のデータが、レンタルサーバの契約ディレクトリの中だけにある状態は、どうしてもモヤモヤが残りました。

気になったのは大きく二つです。セキュリティとデータ消失です。

かつて公開されていた家族のサイトは、世界中から見えていました。レンタルサーバ側の対策は信頼していても、「アカウント乗っ取り」「プラグインの脆弱性」「うっかりの設定ミス」——リスクはゼロではありませんでした。被害が起きたとき、自分で中身を確認し、止め、復旧する余地がほしい。サポートにチケットを出して待つ、というだけでは足りない場面がある。自分の家族のデータなら、なおさらです。これが、家族のブログを公開サーバから引き上げた理由のひとつでもあります。

もうひとつは、サービス終了や移転のときのデータの行方です。20年間、いくつかの事業者を渡り歩きました。移転のたびにバックアップは取りました。でも、バックアップは「復元できる形」で手元に眠っているでしょうか。クラウドのZIPを置いたきり、中身を見ていないアーカイブは、本当はバックアップなのでしょうか。Sixcore経由の移行のとき、FTPで全部引っこ抜いたはずなのに、あとから「あのディレクトリ、取り忘れたかも」と冷や汗をかいた記憶があります。そう考えると、生データが自分の物理ディスク上にあることには、安心以外の意味があると感じています。

ひとぅブログを静的化したのも、同じ方向を向いています。WordPressのデータベースの中だけに閉じていた状態から、ファイルとして扱える形にしました。家族のデータについても、同じ問いを自分に投げかけ続けていました。

「レンタルサーバをやめる」とは言っていません。ひとぅブログはXServerで公開しつつ、GitHubに履歴を残します。家族のサイトは公開をやめ、生データを自宅に置きました。レンタルは「外向きの店舗（ひとぅブログ）」、自宅は「家族の倉庫兼作業場」——そういう役割分担が、いまの自分にはしっくりきます。

2026年ゴールデンウィーク——再び自宅へ

実際に自宅サーバを再構築したのは、2026年のゴールデンウィークです。

ハード構成は、次の三つに集約できます。ミニPC（TRIGKEY-S5）、外付けHDD（4本）、UPSです。ミニPCの内蔵SSD（メインSSD）にOSとDockerコンテナを載せ、日常使いとミラー用のデータは外付けHDD4本に逃がします。停電対策のUPSも、2003年ごろにはなかった配備です。

TRIGKEY-S5は、省電力で24時間回しやすい小型機です。据え置きのベージュ塔だった20年前の自宅サーバと並べると、机の上の風景はまったく別物です。写真に写っているのは、AMD Ryzen搭載のミニPCが4ベイの外付けHDD筐体（Yottamaster）の上に載り、横にUPSが添えられた、いまの「要塞」の全体像です。OSはLinux Mint。「本丸は小さく、倉庫は外付け、電源は守る」——この三つが、2026年版のハードの前提になりました。

今回うまくいった理由は、ミニPCが手に入りやすくなったからだけではありません。小型機ならではの省スペースさと、外付けストレージとの組み合わせ——こういうハード構成の選択肢が増えたことも含めて、三つの条件が重なったからだと思っています。

LinuxのGUIが十分使えるようになったこと。サーバ構築＝黒い画面だけ、という時代はだいぶ過去です。Linux Mint上では、ブラウザからPortainerやNginx Proxy Managerの設定画面を触れます。サーバを家族に使ってもらう予定はありませんが、自分がメンテするとき、すべてをターミナルだけでやらなくて済みます。自分にとっての運用ハードルが下がったのは、大きかったです。

Tailscaleのような無料VPNが実用的になったこと。自宅サーバでいちばん嫌なのは、ルーターに穴を開けて全世界に晒すことです。Tailscaleなら、自分の端末同士だけがつながる暗号化トンネルが張れます。外出先からも、まるで自宅LANにいるように安全にアクセスできます。20年前には、個人がここまで手軽にVPNを張れるとは、想像しにくかったと思います。

AIが構築を支援してくれること。設定ファイルの雛形、Docker Composeの記述、エラーログの読み解き——全部を自分の頭だけでやる必要がなくなりました。丸投げではなく、対話しながら試行錯誤を速くする相棒として使っています。2003年の自分に「20年後、AIと一緒にサーバを立てるよ」と言われても、意味がわからなかったでしょう。2026年は、現実です。

タイトルに「AIで」と入れたのは、流行りに乗ったからではありません。ひとぅブログの静的エンジンをCursorで触っている流れの延長で、自宅サーバの設計も同じ道具で進められたからです。知らないエラーメッセージをそのまま貼り、候補を絞り、自分の環境に合わせて直す——この繰り返しが、週末の数日で要塞の骨格まで進めてくれました。人間が全部暗記している必要はない。判断と検証さえ自分の手元にあれば、構築速度は桁違いになります。

要塞化の設計思想——ポートを開けない、Docker、SSL

今回の自宅サーバで最初に決めたのは、ルーターのポートを開けないことです。インターネットの正面玄関は、自宅のIPに直接向けません。TailscaleでVPN越しに入り、必要なサービスだけを内部で公開する——この方針は、2003年ごろの自宅サーバとは真逆に近いです。あの頃は「見えることが正義」でした。今は見えないことを前提に安全に使うほうが正しい、と考えています。

アプリケーションは、可能な限りDockerで動かしています。OS本体を汚さず、サービスごとに箱を分け、壊れたら箱を捨てて作り直す——この方針です。20年間レンタルサーバで「共有ホスティングの制約」と戦ってきた経験が、逆にDockerのメリットを理解しやすくしてくれました。

HTTPSについても、こだわりました。Vaultwardenやメモ同期のようなサービスは、SSLなしでは正常に動きません。外部にポートを開けずに正規の証明書を使うため、CloudflareにDNSだけ委任し、内部ではNginx Proxy Managerでリバースプロキシを集約しています。各サービスをサブドメインで束ね、常にHTTPSへリダイレクトする——細部は省略しますが、要点は「自宅サーバ＝穴だらけの古いサーバ」というイメージを、設計で否定することでした。

2003年ごろの自宅サーバでは、SSLは高くて面倒なものでした。TailscaleのようなVPNも、当時はありませんでした。いまは、CloudflareにDNSを預けつつNginx Proxy Managerで証明書を管理し、Tailscaleで安全にアクセスする——こういう組み合わせが、個人でも現実的になっています。Let's Encryptを直接使っているわけではなく、Cloudflare経由で正規SSLを運用しています。レンタルサーバ時代、SSLは「おまかせで無料化」が進みました。自宅でも、DNSとリバースプロキシの組み合わせで、同じ方向のことができる——20年の差は、こういうところに表れます。

バックアップは趣味ではなく前提——多段の防衛線

自宅サーバを語るとき、いちばん聞かれるのが「停電したら？」「ディスクが壊れたら？」です。正直、自宅だけに1本化するのは危険だと思っています。だから、バックアップは構築と同時に設計しました。趣味のオプションではなく、前提です。

ざっくり言うと、四層あります。

ローカルの二重化。 日常使いのSSDと、毎日ミラーするHDD。同じデータが、物理的に別のドライブにも眠っています。1台が死んでも、もう1台から復旧できます。

世代管理のアーカイブ。 変更や削除の差分を、一定世代（たとえば100世代）残します。うっかり削除や、同期ミスから巻き戻す余地を確保します。

暗号化クラウドへの複製。 rcloneなどで、クラウド上の暗号化領域へ吸い上げます。自宅が火事や水害で全滅しても、遠隔に復号可能なコピーが残ります。

レンタルサーバからの取り込み。 ここが、20年のレンタルサーバ経験との接点です。XServer上にあるひとぅブログをはじめ、複数ドメインの公開資産を定期的に自宅へ逆流同期しています。自宅からXServerへ公開ミラーを返す、という使い方はしていません。XServerは公開の拠点であり、自宅はその複製と家族データを預ける倉庫——役割が違います。

毎晩動く自動スクリプト、手動で月1回触る第二防壁——細かい工夫はありますが、思想は単純です。1箇所に賭けないのです。

2003年ごろの写真や動画のように、ファイル数が膨大で、かつめったに触らないアーカイブは、別の扱いをしています。年度ごとにtarにまとめ、日次同期のスキャン対象から外す——内部では「石像化」と呼んでいます。動かない重い塊にしておけば、毎晩のバックアップが軽くなります。必要なときだけ、ratarmountのような道具で中身を覗き、解凍せずにマウントして、当時の思い出を直接開きます。アーカイブは、眠らせて守るものだと、20年分のデータを前にして改めて思いました。

rsyncの --delay-updates や、HDDのスリープ対策のような細部は、記事に書くほどではありません。大事なのは、停電1回で全部失う設計にしないという意志です。レンタルサーバ時代、shared hostingの隣人トラブルや、うっかり消したファイルの復旧不能——他人事ではなかった経験が、今の多段構成の説得力になっています。

レンタルサーバだけの時代、「バックアップは契約者の責任」と何度も言われました。その言葉は正しいです。自宅に戻った今、その責任はより直接的に自分に返ってきます。だからこそ、面倒くさがりの自分でも回る仕組みにしました。

何を動かし、何をやめたか——セルフホストの取捨選択

自宅サーバの誘惑のひとつは、なんでも動かしてしまうことです。Docker Hubを見ていると、すべて必要に見えます。でも、ミニPCのリソースと、自分のメンテ時間には限りがあります。今回は、動かしているものと、試して止めたものの両方が、設計の一部です。

動かしているものは、インフラと生活の両方に跨ります。Portainerでコンテナ管理、Vaultwardenでパスワード、Uptime Kumaで死活監視。SambaとFile Browserで家族のファイル共有——端末を問わず、自宅のストレージにファイルを置けます。CouchDBベースのObsidian LiveSync、Joplin、PDF操作用のStirling-PDF。メモとパスワードと書類が、すべてVPNの内側に収まっています。

OllamaとOpen WebUIで、ローカルLLMも置いています。文章の下書き、設定の相談、コードのたたき台——家族のデータを外のAPIに送らなくて済む場所として重要です。GPU付きミニPCなら、7B〜9Bクラスのモデルでも、日常の相談相手には足ります。CloudのLLMを否定しているわけではありません。Cursorで本番執筆するときは、クラウド側を使います。でも、メールの下書きや個人的なメモの整理は、家の中で完結させたい。プライバシーと速度の両方で、ローカルLLMには意味があります。

止めたものも、ちゃんと理由があります。

Discord風のチームチャット（Mattermost、Rocket.Chat、Misskeyなど）は、通知と設定の複雑さに対して、家族の使い方ではDiscordのほうが楽でした。既存の慣れに勝てないときは、勇気を持って撤退しました。

PhotoPrismは、50万枚規模の写真原本に対して、サムネイル生成のキャッシュがNVMeを圧迫し、毎晩のバックアップも膨らみすぎました。「動く」ことと「続く」ことは別だと、身銭を切って学びました。

Anytypeは、ObsidianとAFFiNEへナレッジを集約した結果、役目を終えました。Cryptomatorは、rcloneの透過暗号化で足りると判断し、検証で終了しました。Homeboxのような在庫管理は、便利だったものの、優先度の問題で棚上げにしました——全部、失敗というより選択です。

セルフホストの成熟度は、「なんでも載せられるか」ではなく、何を載せないか決められるかでも測れる、と今は思っています。

20年前との違い——回帰ではなくアップデート

約20年で一周した、と書きました。でも、2003年ごろの自宅サーバと2026年の自宅サーバは、同じものではありません。

2003年ごろは、公開そのものが目的に近かった。自分のページをネットに出し、メールサーバを持つ——それ自体が楽しかったです。ベージュの塔を棚に載せ、モデムを上に置く——写真に残っているのは、その頃の姿です。

2026年は、データの所有と複製が目的に近い。ひとぅブログの公開はXServer、家族のデータの正本は自宅。VPN越しにだけ触れる要塞。AIと一緒にメンテできる環境。バックアップの多段防御——こういう分担です。机の上には、ミニPCと外付けHDD4本、UPS。20年前の写真と並べると、同じ「自宅サーバ」でも、守っているものの重心が違うことがはっきりします。

「自宅サーバに戻った」と言うより、自宅の役割を再定義したほうが正確です。レンタルサーバの20年は、そのための準備期間だった面もあります。安定した公開、移転の経験、SSLの当たり前化、容量の問題——すべて、今の設計の材料になっています。

静的サイトエンジンで記事をMarkdown化した流れも、同じ方向を向いています。書く → ファイルとして扱う → ビルドして公開する。ひとぅブログの生データはXServer、履歴はGitHub。家族のデータは自宅——置き場所を自分で決めるという意味で、Deepの1本目と2本目は、別の話題に見えて、根っこではつながっています。

これからこの要塞で何を守るか

書きながら思うのは、自宅サーバは浪漫の装置ではなく、家族と自分のデータを預ける場所だということです。20年前の自分がワクワクしていたのは、技術の新しさでした。今、大切にしたいのは、長く続く安心です。

守りたいものは、家族のブログ（いまは自宅側）、長年の写真と動画、パスワードとメモ、自分の書いた記録。ひとぅブログの公開と速さは、これまでどおりXServer側に残しています。家族のデータは自宅、ひとぅブログはレンタル——その分担を、実装で試しています。

TailscaleやCloudflareが将来変わったら、WireGuardや別のDNSへ移ります。サービスが終わったら、Dockerの箱を入れ替えます。設計は、いつか変わる前提で書いてあります。20年間、XREAからXServerまでレンタルサーバを移転してきた自分には、それが自然です。サービスは永続しません。だからこそ、データの持ち運びやすさを、最初から設計に入れています。

BCP（事業継続計画）と言うと大げさに聞こえるかもしれません。個人の家庭に、そんな言葉は似合わない。でも、自宅が全損したらどうするかだけは、頭の片隅に置いておきたい。ひとぅブログはXServer上に生データがあり、GitHubにも履歴がある。家族のデータは自宅に正本がある。自宅のディスクが複数段で互いにバックアップし合い、暗号化クラウドにも複製する——広域災害を想定した出口は、自宅からレンタルへ公開を返すミラーではなく、複製の分散に置いています。

約20年ぶりの「自宅サーバ」は、完成形ではありません。ゴールデンウィークに立ち上げ、夏のあいだに試し、足りないところを直し、不要なものを外す——動いている最中の記録です。Deepに書いたのは、成功報告ではなく、その時点での考え方のスナップショットです。

あとから読み返したとき、「なぜ2026年に戻したか」が残っていれば十分です。2003年に始めた熱、2008年に片付けた自宅サーバ、それからのレンタルサーバの年月、そして2026年の要塞——全部つながった一つの流れだった。そう思えるように、ここに置いておきます。