そもそも「サーバー」とは何か

普段使っているパソコンやスマホは、使う時だけ電源を入れて、使い終わったら閉じたり寝かせたりする。サーバーとは、それと逆で、24時間365日ずっと電源が入っていて、インターネットの向こう側からいつでもアクセスできる状態のコンピュータのことだ。

Google Photosも、Gmailも、実態は「Googleが管理する巨大なサーバー群」に自分のデータを預けて、そこに常時アクセスしている状態にすぎない。「データ主権を取り戻す」とは、この「常時アクセスできる置き場所」を、Google任せではなく自分の管理下に置き換える、ということだ。そのためには、自分の管理下にある「常時起動しているコンピュータ」、つまり自分のサーバーが要る。

サーバーを持つ2つの道

サーバーを持つには、大きく2つの選び方がある。

① レンタルサーバー(VPS)を借りる — 月額数百円〜数千円で、どこかのデータセンターにあるコンピュータの一部を間借りする方式。AWS Lightsail、さくらのVPS、カゴヤ CLOUD VPSなどが有名どころ。自分で機械を持たなくていい代わりに、月額費用がずっとかかり続ける。

② 自分の手元にあるPCを使う(自宅サーバー) — 使っていない古いPCや、ゲーミングPCのような性能の高いPCを、24時間つけっぱなしにして使う方式。初期投資(電気代はかかる)以外の追加費用がかからない代わりに、電源やネット回線が落ちたらサービスも止まる、という自己責任になる。

自分は最初、AWS LightsailというVPSを使っていたが、途中で②の自宅サーバー(使っていたゲーミングPC)に切り替えた。理由は、写真管理ソフト(Immich)の顔認識機能がGPU(画像処理用の高性能な部品)を使うと速く動くのに、一般的なVPSにはGPUオプションが無いか、あっても高額だったため。自宅のゲーミングPCには既にGPUが載っていたので、それをそのまま活用できるほうが合理的だった。加えて、VPSの月額費用も浮いた。

とはいえ、どちらが正解ということはない。 GPUを使う予定が無く、自宅に眠っているPCも無いなら、まずは安価なVPSを1つ借りるところから始めるほうが手軽だと思う。自分の場合はたまたま条件が噛み合って②を選んだ、という話として読んでほしい。

自分がどうやってこの作業を進めているか

このサイトのガイドは、自分がターミナルに一つ一つコマンドを手打ちして進めたわけではない。実際にはClaude(AIアシスタント)に「こうしたい」と会話しながら指示を出し、実際のコマンド実行やファイル編集はClaude側にやってもらう、という進め方をしている。使っているのはMulmoClaude(自分がGitHub上で公開している、Claudeを使ったAIアシスタントの土台)というソフトで、これ自体の成り立ちは開発日誌に書いている。

このMulmoClaude自体も、ここまでの話と同じ「自分のサーバー」の上で動いている。最初はAWS Lightsail(レンタルサーバー)の上で動かしていたが、Immichの顔認識をGPUで速く処理したいという理由で自宅のゲーミングPC(GALLERIA)に切り替えた時、Nextcloud・VaultwardenといったほかのサービスもろともMulmoClaude自体も一緒にGALLERIA側へ引っ越した。 つまり今は、この文章を書いているAI自身も含めて、全部が同じ自宅の1台のPCの上で動いている状態になっている。

なので、このサイトの文章の「自分がやった」は、実際には「Claudeに頼んで、Claudeが実行した」を指していることがほとんどだと理解しておいてもらえればと思う。とはいえ、何をどうするかの判断・決断は全部自分がしているので、「作業の手を動かす部分をAIに任せている」くらいの温度感で読んでほしい。

出てくる専門用語を一通り

ここから先のガイドで繰り返し出てくる言葉を、先にまとめて説明しておく。

• ターミナル — マウスでクリックする代わりに、文字でコマンド(命令文)を打ち込んでコンピュータを操作するための画面。最初は怖く見えるが、実態は「決まった呪文を決まった場所にコピー&ペーストするだけ」の作業がほとんどで、慣れの問題が大きい。
• Docker(ドッカー) / docker-compose(ドッカーコンポーズ) — サーバー上でソフトを動かすための仕組み。1つ1つのソフトを「コンテナ」という隔離された箱に入れて動かすので、複数のソフトを同じサーバーに入れてもお互いが干渉しにくい。docker-composeは、その箱をいくつか組み合わせて一括で起動・停止するための設定ファイルの書き方。
• ドメイン — taikiito.comのような、自分のサーバーにつける覚えやすい名前。年間数百円〜数千円で自分の名義で取得できる(自分はCloudflare Registrarで取得した)。
• DNS — 「taikiito.comというドメインは、実際にはどのサーバーを指すか」をインターネット全体に教えるための、住所録のような仕組み。ドメインを取得したら、DNSの設定でどのサーバーに繋げるかを指定する。
• Cloudflare Tunnel(クラウドフレア・トンネル) — 自宅のサーバーを、自宅のルーターの設定(ポート開放という、外から直接アクセスできる穴を開ける作業)をいじらずに、安全にインターネットへ公開するための仕組み。自分もこれを使っていて、ルーター側の設定は一切変更していない。ポート開放は誤って設定すると自宅のネットワーク全体が外部から丸見えになるリスクがあるため、この方式のほうが安心して扱える。

これらのソフト自体は、すべて無料(OSS、オープンソースソフトウェア = 誰でも無料で使える公開されたソフト)で使える。かかる費用は基本的に「サーバー代(自宅の場合は電気代のみ)」と「ドメイン代(年数百円〜)」だけだ。

実際に手を動かす: 最小構成でサーバーを1台立てる

ここから先は、自分が最初にやった手順そのままに、VPS(レンタルサーバー)でサーバーを1台立てるところまでを書く。自宅サーバー(Windows + WSL2)は環境依存が強すぎて万人向けに書き起こせないと判断し、まずは誰でも同じように再現できるVPSの手順に絞った。 自宅サーバーへの切り替えは、この記事の後半「自宅サーバーに切り替える場合」で触れる。

Step 1: ドメインを取得する

まず自分のサーバーの「名前」になるドメインを取得する。自分はCloudflareのRegistrar(ドメイン登録サービス)を使った。理由は、相場より安い実費に近い価格で提供されていて、WHOIS(ドメイン所有者情報)を公開しないプライバシー保護もデフォルトで付いてくるため。ダッシュボードの「Register a Domain」から、空いているドメイン名を選んで購入するだけで完了する。年間数百円〜数千円ほど。

Step 2: VPS(レンタルサーバー)を契約する

自分が最初に使ったのはAWS Lightsail、リージョンはシンガポール、OSはUbuntu(Linuxの一種)、**プランは月$7(メモリ1GB・2vCPU・SSD 40GB)**を選んだ。動画生成のような重い処理をする予定がなければ、この最小プランで十分動く。契約すると、そのサーバーの持ち主だけが入れる「IPアドレス」(サーバーの住所のようなもの)が発行される。

VPSは他にもさくらのVPS・カゴヤ CLOUD VPS・DigitalOcean・Vultrなど選択肢は多い。自分がAWSを選んだ決め手は、シンガポール在住で近いリージョンが使えたのと、後々AWSの他サービス(バックアップ等)との連携がしやすそうだったため——ただしこの用途では正直どれを選んでも大差ない。

Step 3: ターミナルからサーバーに接続し、Dockerを入れる

契約すると、サーバーに接続するための「SSH鍵」(パスワードの代わりに使う、より安全な鍵ファイル)が発行される。ターミナル(黒い画面でコマンドを打ち込む操作)から、次のように接続する。

ssh -i 発行された鍵ファイル ubuntu@サーバーのIPアドレス

接続できたら、Docker公式が配布しているインストールスクリプトを実行する。これ1行で、Dockerとdocker composeがまとめて入る。

curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER

(2行目は、sudo〈管理者権限で実行〉を毎回付けなくてもDockerコマンドが使えるようにするおまじない。一度ログアウトしてから入り直すと反映される。)

Step 4: Cloudflare Tunnelでサーバーを安全に公開する

サーバーは立ったが、まだtaikiito.comのようなドメインからはアクセスできない。ここで前述のCloudflare Tunnelを使う。取得したドメインをCloudflareのネームサーバーに切り替えた上で(Cloudflareのダッシュボードの指示通りに進めれば数クリックで終わる)、サーバー側で次を実行する。

# cloudflaredをインストール
curl -L --output cloudflared.deb https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb

# Cloudflareアカウントと連携(ブラウザが開くのでログインする)
cloudflared tunnel login

# トンネルを作成(名前は自分で決める。ここでは仮に my-server)
cloudflared tunnel create my-server

# ドメインとトンネルを紐付ける
cloudflared tunnel route dns my-server example.taikiito.com

最後に、どのURLへのアクセスをサーバー内のどのポートに転送するかを設定ファイル(~/.cloudflared/config.yml)に書く。

tunnel: my-server
credentials-file: /home/ubuntu/.cloudflared/<トンネルID>.json

ingress:
  - hostname: example.taikiito.com
    service: http://localhost:8080
  - service: http_status:404

再起動しても自動で動き続けるよう、サービス化しておく。

sudo cloudflared service install

ここまでできれば、あとはサーバー内のlocalhost:8080(上の設定例のポート番号)で何かソフトを動かせば、https://example.taikiito.comからアクセスできるようになる。ルーターのポート開放(外から直接アクセスできる穴を開ける、事故ると危険な設定)を一切いじらずに済むのがこの方式の利点。

Step 5: 動作確認

具体的に何かソフトを動かして確認したい場合は、このサイトの次のガイド(写真をGoogle PhotosからImmichに移す)がそのままStep 6以降の実例になる——docker-compose.ymlを書いてImmichを起動し、上のingress設定のポート番号をImmichのポートに合わせれば、そのまま公開まで到達できる。

自宅サーバーに切り替える場合

自分は後になって、AWS Lightsail(VPS)から自宅のゲーミングPC(自宅サーバー)に切り替えた。理由は前述の通りGPU(画像処理用の高性能な部品)を使いたかったのと、月額費用を浮かせたかったため。ただしこの切り替えは、Windows PCの中でLinuxを動かす「WSL2」という仕組みや、再起動時の自動起動設定など、環境固有のハマりどころが多く、万人向けの手順としてはまだ書き起こせていない。GPUを使う予定がなければ、上記のVPS構成のままで十分運用できる。自宅サーバーへの興味がある場合は、今後別記事として書く予定。

正直な難易度感

ここまで読んで「思ったより大変そう」と感じたなら、その感覚は正しい。自分の場合も、自宅サーバーへの切り替えではWindowsとLinux(WSL2)の両方の知識が必要になったり、再起動のたびにサービスが自動で立ち上がらない不具合に何度も遭遇したりと、一筋縄ではいかない場面が何度もあった。上記のVPS手順自体はそこまで難しくないが、初めてターミナルを触る場合は1〜2時間はかかると思っておいてほしい。

ただし、これは「一度整えてしまえば、あとはほぼ触らなくていい」類の作業でもある。土台さえできてしまえば、その後の写真の移行やパスワードの移行といった個別の作業は、ここまでの土台よりずっと軽い。

この先

サーバーが立ち、ドメインからアクセスできる状態まで来たら、あとは個別のサービスを動かすだけ。まずは実際に何を移したかの記録から読んでもらえればと思う。→ 写真をGoogle PhotosからImmichに移す

更新履歴 — 2026-09-13: 初版 / 同日: 「自分がどうやってこの作業を進めているか」(MulmoClaude/Claudeの利用、Lightsail→GALLERIA移設)を追記 / 同日: VPS(AWS Lightsail)でのドメイン取得〜Docker〜Cloudflare Tunnelまでの具体的手順を追記

前提: このガイドで想定している環境

以下がすでに用意できていることを前提にする。まだの場合は先に自分の「サーバー」を持つとはどういうことかを読んでほしい。

• 常時起動しているLinux環境(自分の場合はWindows機の中でWSL2〈Windows Subsystem for Linux 2、WindowsのなかでLinuxをそのまま動かす仕組み〉のUbuntu)
• Docker Engine(コンテナ、つまりソフトを隔離された箱に入れて動かす仕組み)と、そのおまけ機能であるdocker compose(複数のコンテナ設定をまとめて起動・停止するコマンド)が使える状態
• ターミナル(文字でコマンドを打ち込む黒い画面)の基本操作に抵抗がないこと

GPU(グラフィック処理用の高性能な部品)は必須ではない。無くても写真の保管・閲覧は問題なくでき、違うのは顔認識やスマート検索(自然言語でのあいまい検索)の処理速度だけ。自分はたまたま手元にゲーミングPC(GeForce RTX 3070搭載)があったのでGPUを使う構成にした。GPUを使わない場合は、後述の「GPUを使う場合の追加設定」を丸ごと飛ばして進めて構わない。

Step 1: Immichをdocker-composeで動かす

まず作業用フォルダを作り、Immich公式が配布している設定ファイル一式をダウンロードする。

mkdir ~/immich && cd ~/immich
curl -fL -o docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
curl -fL -o .env https://github.com/immich-app/immich/releases/latest/download/example.env
curl -fL -o hwaccel.ml.yml https://github.com/immich-app/immich/releases/latest/download/hwaccel.ml.yml

ここで一度ハマった: curlに-L(リダイレクト追従、GitHubのようにURLが転送される先でファイルを配っているサイトでは必須)を付け忘れて、中身が0バイトのファイルができてしまったことがあった。-fL(-fはエラー時に空ファイルを作らず失敗させる、-Lはリダイレクト追従)の組み合わせで取り直して解決した。

次に.envファイルを編集する。最低限、以下の2点は必ず変更する。

• DB_PASSWORD — デフォルトのままだと誰でも推測できるパスワードなので、自分だけの値に変更する
• UPLOAD_LOCATION — 写真の実ファイルをどこに保存するかの場所。デフォルトの./library(このフォルダの中のlibraryサブフォルダ)のままで問題ない

セットアップ中に出てくる「Storage Template」という機能(保存されるファイルの命名・フォルダ構造を人間が読みやすい形に変える機能)は、オフのままにすることを勧める。写真の閲覧はどのみちImmichの画面経由が前提になるので、生ファイルの構造を人が読みやすくする必要性が薄いことと、後から有効化すると全件の再整理ジョブが走って重くなることが理由。

準備ができたら起動する。

docker compose up -d
docker compose ps

immich_server / immich_machine_learning / database(PostgreSQL) / redisの4つのコンテナがhealthy(正常稼働)と表示されれば成功。ブラウザでhttp://localhost:2283(自宅サーバーの場合はサーバーのIPアドレスに読み替える)を開き、管理者アカウントを作成する。

GPUを使う場合の追加設定(任意)

顔認識・スマート検索をGPUで高速に処理したい場合は、上記のdocker compose up -dの前に以下を行う。

1. WSL2からGPUが見えることを確認する: nvidia-smi(GPUの状態を表示するNVIDIA公式コマンド)を実行し、GPU名やドライバのバージョンが表示されればOK
2. NVIDIA Container Toolkit(DockerコンテナからGPUを使えるようにする橋渡しソフト)を導入し、nvidia-ctk runtime configure --runtime=dockerで設定を反映
3. docker run --rm --gpus all ubuntu nvidia-smiを実行し、コンテナの中からもGPUが見えることを確認する
4. docker-compose.ymlのimmich-machine-learningサービスを編集: イメージタグの末尾に-cudaを追加し、コメントアウトされているextends: file: hwaccel.ml.yml / service: cudaの行を有効化(元はservice: cpuになっている行をコメントアウトし、cuda側を使う)

この状態でdocker compose up -dすれば、ログにCUDA関連のエラーが出ていないことを確認して完了。GPUを使わない場合はこの節をまるごと無視してよく、Immichは自動的にCPUで処理する。

Step 2: 取り込みツールimmich-goを導入する

Immich公式のCLI(コマンドライン操作用ツール)であるimmich uploadは使わない。理由は、Google Takeout(Googleのデータ一括エクスポート機能)でダウンロードした写真には、撮影日時やアルバム情報が入った.jsonという付属ファイル(サイドカーファイルと呼ばれる)が一緒に入っているが、公式CLIはこの.jsonを読まないため、アルバムの中身や正確な撮影日時が失われてしまうため。

代わりに使うのが、有志が開発した**immich-go**(自分が使ったのはv0.32.0、開発者はsimulot氏)というツール。Takeoutの.jsonサイドカーをちゃんと読んでアルバム・撮影日時・GPS情報を復元し、しかもzipファイルを展開せずそのまま読み込める(119GB分を解凍する広い置き場所を用意しなくていい)、重複した写真も自動で名寄せしてくれる。

GitHubのリリースページから、自分のOS(今回はLinux/amd64)に合ったバイナリをダウンロードして展開し、実行権限を付ける。

curl -fL -o immich-go.tar.gz https://github.com/simulot/immich-go/releases/download/v0.32.0/immich-go_Linux_x86_64.tar.gz
tar -xzf immich-go.tar.gz
chmod +x immich-go

(バージョンによって配布ファイル名やコマンドのオプション名が変わることがあるので、実行前に./immich-go --helpで最新の使い方を確認するのを勧める。)

Immich側の管理画面(Account Settings → API Keys)でAPIキーを1つ発行しておく。このキーを使ってimmich-goがImmichサーバーに写真をアップロードする。

Step 3: Google Takeoutで写真データをエクスポートする

takeout.google.comにアクセスし、「Google フォト」だけを選択してエクスポートを作成する。ファイル形式はzip、分割サイズは自分で選べる(容量が大きいとGoogleが複数のzipファイルに自動分割してくれる)。準備ができるとメールで通知が来て、ダウンロードページから一つずつ落としていく。

ここでも一度ハマった: 自分の場合は全部で12個に分割された(takeout-...-001.zip〜-012.zip)。ダウンロードし終わったつもりで作業を始めたら、途中の2つ(-002と-003)が抜けていたことに後から気づいた。ダウンロードページに戻って抜けていた分だけ再取得し、連番が最後まで揃っていることを確認してから次に進んだ。件数が多いときは、連番が全部揃っているかを作業開始前に必ず確認するべき、という教訓。

Step 4: 長時間処理に備えてtmuxの中で作業する

数万件・100GB超のアップロードは何時間もかかる処理になる。ターミナルの画面(WindowsならPowerShellやWSLの窓)を誤って閉じてしまうと処理も一緒に止まってしまうので、tmux(ターミナルの中に「もう一つの独立したターミナル」を作れるツール)のセッションの中で実行する。

tmux new -s immich-import

これで新しいセッションに入る。ここから先の作業はこのセッションの中で行い、たとえ元のウィンドウを閉じても処理は裏側で動き続ける(再接続するにはtmux attach -t immich-import)。

Step 5: まず--dry-runで確認する

いきなり本番実行するのは怖いので、実際には何もアップロードせず結果だけ教えてくれる--dry-runオプションを付けて試す。

./immich-go upload from-google-photos \
  --server=http://localhost:2283 \
  --api-key=<Step2で発行したAPIキー> \
  --dry-run \
  ~/Downloads/takeout-*.zip

自分の場合の出力はこうだった。

Total Assets: 32218
Associated metadata: 32211
Missing metadata: 7
Errors: 0

3万2千件のうち、日付やアルバム情報(メタデータ)が紐づかなかったのはわずか7件、エラーはゼロ。この結果を見て「時系列が全部壊れる」ような大事故にはならなさそうだと判断し、--include-unmatched(メタデータが無い写真も強引に取り込むオプション)は付けずに本番実行することにした。

Step 6: 本番実行

--dry-runを外すだけで、実際のアップロードが始まる。

./immich-go upload from-google-photos \
  --server=http://localhost:2283 \
  --api-key=<APIキー> \
  ~/Downloads/takeout-*.zip

結果はこうだった。

Uploaded successfully: 29408
Metadata updated: 30794
Discarded local duplicate: 1048
Errors: 2
Missing metadata: 7

3万件近くが無事アップロードされ、1,048件は重複と判定されてスキップされた(むしろ取り込み過ぎを防いでくれるので助かる動き)。エラーは2件だけ。ログファイル(~/immich-import.log)を見ると、写真本体が消えたわけではなく、「アルバムを作れなかった(failed to create album)」「タグを付けられなかった(failed to add assets to tag)」といった付随的な失敗だけだった。

Step 7: 取り込み直後に焦った話(バックグラウンドジョブの確認)

取り込み後、Immichの管理画面で最近の写真に「Error」のようなマークが出ていて、一瞬「本体が壊れたか」と焦った。よく見ると、管理画面(Administration → Jobs)にサムネイル生成(Generate Thumbnails)・顔認識(Facial Recognition)・文字認識(OCR)といった**後処理(バックグラウンドジョブ)**がまだ大量に残っている状態だった。つまり、アップロード自体は終わっていても、Immich側の後片付け処理がまだ終わっていなかっただけ。数時間待って、これらのジョブがすべて完了したのを確認してから見直したら、表示は正常に戻っていた。取り込み直後に何かエラーっぽい表示が出ても、すぐパニックにならず、まずバックグラウンドジョブが終わっているか確認する、というのが得た教訓。

Step 8: バックアップに追加する

写真ファイルだけをバックアップしても、アルバム構成・撮影日時の補正結果・顔認識結果はすべてPostgreSQL(Immichが使っているデータベース)の中に入っているため、データベースのバックアップも一緒に取らないと意味がない。自分は既存のバックアップスクリプト(~/backup-scripts/backup-to-b2.sh、Backblaze B2というオンラインストレージへrcloneで同期するもの)に以下の2つを追記した。

# データベースのダンプ
docker compose -f ~/immich/docker-compose.yml exec -T database \
  pg_dumpall --clean --if-exists --username=postgres | gzip > /tmp/immich-db.sql.gz

# 写真本体の同期(サムネイルと変換済み動画はImmichが再生成できるので除外する)
sudo rclone --config /home/ito-t/.config/rclone/rclone.conf sync \
  ~/immich/library "$B2_REMOTE/immich/library" \
  --exclude "thumbs/**" --exclude "encoded-video/**"

注意点が2つ。1つ目は、thumbs/とencoded-video/(Immichが自動生成する派生ファイル)を除外しないと、バックアップ容量が無駄に膨らむこと。2つ目は、119GBのような大容量を初回にいきなり日次の自動実行(cron)に任せると、家庭のインターネット回線の上り速度によっては半日〜丸1日かかってしまい、日中の回線を占有してしまうこと。初回だけは--bwlimit(転送速度の上限を指定するオプション)を付けて手動で実行し、完了を確認してから自動実行に組み込むことを勧める。

結果と現状の進捗

ブラウザでImmichを開いて確認したところ、昔の写真もちゃんと時系列順に並んでいた。「日付が全部壊れた」ような状態にはならず、実用上問題のない移行ができたと判断している。

2026-09-12時点の進捗として追記すると、Google Photosからの移行は完了しているが、実はiPhone側の「iCloud写真」はまだオンのままで、GoogleとImmich・iCloudの3箇所に同時保存されている状態が続いている。写真の管理元を完全にImmich一本にするには、(1)しばらくImmichと並行運用して安定を確認、(2)iPhoneの「iCloud写真」をオフにして以降はImmichアプリの自動バックアップだけに切り替え、(3)必要ならiCloudのストレージプランを見直す、という手順が残っている。Apple純正の「写真」アプリ自体をやめるつもりはなく、OS標準のビューア・共有機能としては使い続け、バックアップ・データの主管をImmichに置く役割分担にする方針。この手順は急がず進める予定で、実施したらここに追記する。

次は、同じ考え方でGoogle Driveのファイルを移した話。→ ファイルをGoogle DriveからNextcloudに移す

更新履歴 — 2026-08-24: 初版 / 2026-09-12: 「現状の進捗」を追記(iCloud写真トグルOFF化の計画) / 2026-09-13: docker-composeでのImmich構築・immich-goの実コマンド・バックアップスクリプトの追記まで、再現可能なレベルに全面書き直し

前提

以下がすでに用意できていることを前提にする。まだの場合は先に自分の「サーバー」を持つとはどういうことかを読んでほしい。

• 常時起動しているLinux環境(Docker Engineが使える状態)
• 自分名義のドメイン、およびCloudflare(無料プランで可)でそのドメインを管理していること
• Cloudflare Tunnel(cloudflaredというソフトを使い、自宅のルーターの設定を一切いじらずに自宅サーバーを安全にインターネット公開する仕組み)がすでに動いている状態。導入手順は自分の「サーバー」を持つとはどういうことかを参照

何をしたかったか

写真をImmichに移した(前の記事)のと同じ理由で、Google Driveに置きっぱなしにしていたファイルも自分の手元に戻したいと思った。写真ほど量は多くない(実質100〜150MB程度)が、契約書や身分証のコピーなど「人に預けたくないもの」が混ざっていたのが動機だった。

Step 1: Nextcloudを選び、全部は移さないと決めた

Google Driveの代わりになる自前ホスト型のソフトはいくつかある。今回は次の4つを比べた。

• Nextcloud — ファイル同期に加えて、連絡先・カレンダー・メモアプリなど周辺機能が豊富。後から機能を足しやすい。
• Seafile — ファイル同期に特化していて速いという評判だが、周辺機能はNextcloudほど無い。
• Syncthing — サーバーを介さず端末同士が直接同期する仕組み。管理はシンプルだが、Google Driveのような「どこからでもブラウザで見る」用途には向かない。
• Filestash — 既存のストレージ(自分のNASなど)にWeb UIを被せるツール。今回は土台のストレージ自体を新規に用意する必要があったので、ここでは選択肢から外れた。

最終的に、**拡張性(今後、連絡先やカレンダーも同じ場所に集約したくなる見込みがあった)**を決め手にNextcloudにした。実際にこの後、連絡先・カレンダーも同じNextcloudに移すことになったので、この判断は結果的に正しかった。

写真の時は「全部Immichに取り込む」という単純な方針にしたが、Google Driveは事情が違った。中身を確認すると、自分のファイルの他に、家族と共有しているフォルダが2つ(iPhoneの体組成計・血圧データを自動書き出しする仕組みと、ビザ手続き関連の共有フォルダ)混ざっていた。この2つは「相手(連携先アプリや家族)がGoogle前提で動いている」ため、無理にNextcloudへ移すと連携が壊れる。移行の効果(データ主権が増える度合い)と、移すコスト・壊れるリスクを天秤にかけて、この2つはGoogle側に残すと決めた。 残りの自分専用ファイル(契約書などのarchiveフォルダ)だけをNextcloudに移した。

Step 2: docker-composeでNextcloudを構築する

作業用フォルダを作り、docker-compose.ymlを用意する。

mkdir ~/nextcloud && cd ~/nextcloud

docker-compose.ymlの中身(Nextcloud本体appと、データを整理して保存しておくデータベースソフトdb〈MariaDB〉の2つのコンテナをセットで起動する構成):

services:
  db:
    image: mariadb:11
    restart: always
    volumes:
      - ./db:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=<自分で決めた強力なパスワード>
      - MYSQL_PASSWORD=<自分で決めた強力なパスワード>
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud

  app:
    image: nextcloud:latest
    restart: always
    ports:
      - 127.0.0.1:8081:80
    links:
      - db
    volumes:
      - ./data:/var/www/html
    environment:
      - MYSQL_PASSWORD=<自分で決めた強力なパスワード>
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_HOST=db
      - NEXTCLOUD_ADMIN_USER=admin
      - NEXTCLOUD_ADMIN_PASSWORD=<自分で決めた強力なパスワード>
      - NEXTCLOUD_TRUSTED_DOMAINS=drive.example.com

portsを127.0.0.1:8081:80(自分のマシンの中からしかアクセスできない設定)にしているのがポイント。外部への公開はこのあとCloudflare Tunnel経由で行うので、Nextcloud自体を直接インターネットに晒す必要はない。NEXTCLOUD_TRUSTED_DOMAINSには、実際に使う自分のドメイン(例: drive.taikiito.com)を入れる。

起動する。

docker compose up -d
docker compose ps

app・dbの2つが起動していることを確認したら、http://localhost:8081にアクセスして管理者アカウント(NEXTCLOUD_ADMIN_USER/NEXTCLOUD_ADMIN_PASSWORDで指定した内容)でログインできることを確認する。

Nextcloudの管理者ユーザー名は一度決めると後から変更できないので、adminのような分かりやすい名前で最初から決めておくとよい。

Step 3: Cloudflare Tunnelで公開する

/etc/cloudflared/config.yml(Cloudflare Tunnelの設定ファイル)のingress(どのドメイン宛のアクセスを、サーバー内のどのポートに転送するかのルール一覧)に、Nextcloud用の行を追記する。

ingress:
  - hostname: drive.taikiito.com
    service: http://localhost:8081
  # ...他のサービスの行がここに続く...
  - service: http_status:404

注意点: service:行のインデント(行頭の空白)は他の行と正確に揃えること。ここが1マスでもずれるとYAML(設定ファイルの記述形式)の解析エラーになり、Cloudflare Tunnel全体が落ちて他のサービスまで巻き込んで止まる、という事故を実際に経験している。編集後はcloudflared tunnel ingress validateで文法チェックしてからsudo systemctl restart cloudflaredで反映するのが安全。

DNS側は、Cloudflareの管理画面(またはAPI)でdrive(サブドメイン部分)のCNAMEレコードを<トンネルID>.cfargotunnel.comに向ける。反映後、https://drive.taikiito.comでNextcloudのログイン画面が表示されれば成功。

Nextcloud特有の注意点: Nextcloud(内部でApacheというソフトを使っている)は、自分がHTTPS経由でアクセスされていることを正しく認識できないと、ログイン後に無限リダイレクトを起こすことがある。Cloudflare Tunnelは末端(サーバーとの接続)を暗号化しないHTTP接続で待ち受けるため、この設定が必要になる場合がある。症状が出た場合は、Nextcloudのconfig/config.phpに以下を追記して回避する。

'overwriteprotocol' => 'https',

Step 4: Macと同期する

ここからは、サーバーさえ用意できていれば誰でもできる部分。Google DriveにはMacの「Finder」(ファイル一覧の画面)に統合される専用アプリがあったが、Nextcloudにも同じような公式デスクトップアプリがある。これをインストールしてログインすると、Finder上にNextcloudのフォルダが表示され、Google Driveの時とほぼ同じ感覚でファイルを開いたり保存したりできる。同期は「全部」ではなくフォルダ単位で選べる。最初はNextcloudが用意するお試し用のサンプルフォルダ(Documents、Photos、Templatesなど)が並んでいたが、これは削除してよい。本物のデータが入っているのは、移行したarchiveフォルダだけだった。

Step 5: バックアップを設定する

「移した先が壊れたら意味がない」ので、移行作業そのものと同じくらいバックアップ体制を大事にしている。rclone(色々なオンラインストレージをコマンドラインから操作できるツール)を使い、Backblaze B2という安価なオンラインストレージへ、Nextcloudのデータを毎日自動でコピーする設定にした。

# データベースのダンプ
docker compose -f ~/nextcloud/docker-compose.yml exec -T db \
  mysqldump -u nextcloud -p<パスワード> nextcloud | gzip > /tmp/nextcloud-db.sql.gz

# ファイル本体の同期
sudo rclone --config /home/ito-t/.config/rclone/rclone.conf sync \
  ~/nextcloud/data "$B2_REMOTE/nextcloud/data"

これを日次のcron(定期実行の仕組み)に登録しておけば、毎晩自動でバックアップが取られる。

つまづいた所・積み残し

9.68GBの謎: 作業の途中、Googleのストレージ画面で「Driveが9.68GB使用中」と表示されているのに気づいた。しかし実際に移行した中身は100〜150MB程度しかない。90倍以上の差があり、計算が全く合わなかった。調べてみると、以前どこかのタイミングで大きなファイルを削除した際、ゴミ箱を空にしていなかった可能性が濃厚だという所まで辿り着いた。Googleドライブのゴミ箱は自動では空にならず、手動で「ゴミ箱を空にする」を押さない限り容量を圧迫し続ける。ここは正直に書いておくと、この謎は最終的に自分の手では確認しきれず、保留のままになっている。

家族との共有: Google Driveで便利だったことの一つに、家族とのフォルダ共有がある。Nextcloudでも同じことは可能で、家族専用アカウントを作って権限を細かく設定する方法と、アカウント不要のリンク共有で手軽に済ませる方法の2通りがある。これは記事執筆時点でまだどちらにするか決めきれていない、現在進行系の課題として正直に残しておく。

結果

自分専用のファイルはNextcloud経由でMacからGoogle Driveと変わらない感覚で使えるようになった。家族共有フォルダ2つは「無理に移さない」という判断のままGoogleに残っており、これはこれで納得している状態。

次は、同じNextcloudに連絡先とカレンダーも集約した話。→ 連絡先とカレンダーをiCloud・GoogleからNextcloudに移す

更新履歴 — 2026-09-12: 初版 / 2026-09-13: docker-compose設定・Cloudflare Tunnel公開手順・バックアップコマンドを追記し、再現可能なレベルに書き直し

前提

以下がすでに用意できていることを前提にする。まだの場合は先に自分の「サーバー」を持つとはどういうことかを読んでほしい。

• 常時起動しているLinux環境(Docker Engineが使える状態)
• 自分名義のドメイン、Cloudflare Tunnelが動いている状態(導入手順は前々回の記事のStep 3と同じ)

何をしたかったか

写真(前の記事)やファイル(前の記事)と同じ理由で、1Passwordに預けていたパスワードも自分の手元に戻したいと思った。加えて、1Passwordは年額のサブスクリプションなので、自前ホストに切り替えれば単純にコストも減らせる。

Vaultwardenを選んだ理由

パスワードマネージャーの自前ホスト選択肢は複数ある。

• Vaultwarden — Bitwardenというサービスの非公式互換サーバー実装。公式のBitwardenアプリ・ブラウザ拡張機能がそのまま使え、UIの完成度も高い。ゼロ知識暗号化(サーバー側もマスターパスワードを知らない設計)。
• KeePassXC — サーバーを立てず、暗号化されたファイル1つで管理するタイプ。オフラインで完結するが、複数端末間の同期を自分で用意する必要がある(クラウドストレージと組み合わせるのが一般的)。
• Bitwarden公式のクラウド版 — セルフホストではなく、Bitwarden社のサーバーに預ける形。1Passwordと似た構図になるため、今回の「自分の手元に取り戻す」という目的には合わない。

普段使っているNextcloud・Immichと同じサーバー上に同居させられる手軽さと、公式アプリがそのまま使える点を決め手にVaultwardenにした。

Step 1: docker-composeでVaultwardenを構築する

Vaultwardenは公式イメージを使えばコンテナ1つで完結し、Nextcloudのようにデータベースを別途用意する必要もない分、今回の中では一番シンプルな部類だった。

mkdir ~/vaultwarden && cd ~/vaultwarden

docker-compose.yml:

services:
  vaultwarden:
    image: vaultwarden/server:latest
    restart: always
    environment:
      - DOMAIN=https://vault.example.com
      - ADMIN_TOKEN=<自分で決めた長いランダム文字列>
      - SIGNUPS_ALLOWED=false
    volumes:
      - ./vw-data:/data
    ports:
      - 127.0.0.1:8082:80

いくつか説明が要る項目がある。

• DOMAIN — 最終的に外部からアクセスする本物のURL(自分のドメイン)を指定する。ここがずれているとパスキー(WebAuthn)登録時にエラーになることがある。
• ADMIN_TOKEN — サーバーの管理画面(/admin)に入るための鍵。長いランダム文字列にし、他の誰にも教えない。
• SIGNUPS_ALLOWED=false — 新規アカウント登録を締め切る設定。自分専用サーバーなので、自分のアカウントを最初に1つ作ったらこれをオフにして、他人が勝手にアカウントを作れないようにする。

起動する。

docker compose up -d
docker compose ps

http://localhost:8082にアクセスし、「Create Account」から自分のアカウントを作成する。作成が終わったらdocker-compose.ymlを編集してSIGNUPS_ALLOWED=falseに変更し、docker compose up -dで反映しておく。

Step 2: Cloudflare Tunnelで公開する

Nextcloudの時(前の記事)と同じ要領で、/etc/cloudflared/config.ymlにVaultwarden用の行を追記する。

ingress:
  - hostname: vault.taikiito.com
    service: http://localhost:8082
  # ...他のサービスの行がここに続く...
  - service: http_status:404

編集後はcloudflared tunnel ingress validateで文法チェックしてからsudo systemctl restart cloudflared。DNS側もCloudflareの管理画面でvaultのCNAMEレコードを<トンネルID>.cfargotunnel.comに向けておく。

Step 3: ブラウザ・スマホから接続する

ブラウザはChrome・Firefoxの両方にBitwarden拡張機能を追加し、接続先の設定(拡張機能アイコン → 設定 → Self-hosted environment)に自分のvault.taikiito.comを入力する。スマートフォン用の公式Bitwardenアプリも同様に接続先を変更するだけで使える。

パスワード自体の移行は、1Password側でエクスポートしたデータ(CSV形式など)をVaultwardenの「Import data」機能でインポートするだけで数分で終わった。ここは特につまづくところがなかった。

Step 4: パスキーの移行

パスワードと違い、パスキー(WebAuthn)はエクスポート・インポートで移せない仕様になっている。サイトごとに「旧パスキーを削除 → 新しいマネージャーで再登録」という地道な作業が必要だった。手元の1Passwordを棚卸ししたところ、登録済みのパスキーは全15件。

作業中に見つかった落とし穴:

• ブラウザ拡張機能の競合: 1Password拡張機能を有効にしたままだと、WebAuthnのリクエストを1Password側が横取りしてしまい、Bitwarden/Vaultwarden拡張機能が反応できない。chrome://extensionsで1Password拡張機能を完全にOFFにする必要があった。
• スマホ側の割り込み: モバイル版Bitwardenアプリでパスキーを新規登録する際、Touch ID/Face IDのようなOS標準の認証より先にBitwarden拡張機能側が割り込んでしまい、登録に失敗することがあった。
• iCloud Keychainを使う場合の見落としがちな設定: macOSでiCloudキーチェーン経由のパスキー登録をするには、システム設定 → 一般 → AutoFill & Passwords の「Passwords」トグルが事前にONになっている必要がある(初期状態はOFF)。
• 削除する前に、実際に使っているか確認する: 「もう使っていないはず」と思っていたサービスのパスキーが、実は仕事の特定システムのログインで現役だと後から判明した件があった。1Password内の一覧だけを見て「使っていなさそう」で判断せず、実際に使う場面があるかを確認してから削除する方が安全だった。

全部をVaultwardenに寄せたわけではなく、用途によって使い分けている。会社PC(Windows)からのログインが必要なアカウントはブラウザ拡張機能のインストールが要らずQRコードでのクロスデバイス認証に対応しているiCloud Keychainへ、個人利用でデータ主権の方針に寄せたいアカウントはパスワードと同じ場所で一元管理できるVaultwardenへ、という基準にした。

Step 5: バックアップを設定する

Nextcloud・Immichと同じくrcloneでBackblaze B2へ日次バックアップする。Vaultwardenの場合はデータベース(SQLite、1ファイルにまとまった軽量なデータベース形式)がそのままフォルダの中に入っているので、フォルダごと同期するだけでよい。

sudo rclone --config /home/ito-t/.config/rclone/rclone.conf sync \
  ~/vaultwarden/vw-data "$B2_REMOTE/vaultwarden"

このバックアップの取り出し鍵自体もバックアップしておく、という一段階上の注意点がある。rcloneの設定ファイル(~/.config/rclone/rclone.conf、B2に接続するための鍵が入っている)がサーバー本体にしか無いと、サーバーが完全に壊れた時にバックアップを取り出す鍵ごと失われてしまう。自分はこの設定ファイルの中身を、Vaultwarden自身にSecure Note(パスワード以外のメモも安全に保存できる機能)として複製保存しておくことで、この「鶏と卵」問題を解決した。Vaultwardenはクライアントアプリに一度ログインしておけばオフラインキャッシュが残るため、サーバーが全損してもスマホから鍵を取り出せる。このバックアップ自体を「乗っ取られても消されない」形にする話はバックアップを「消されても戻せる」形にするに別途書いた。

結果

パスワード15件・パスキー15件、全て移行完了。1Passwordは解約し、年間の固定費を1本減らせた。パスワードの移行自体は簡単だが、パスキーは仕組み上コピーできないので、サイトごとの再登録作業を見込んでおくとよい。

次は、連絡先とカレンダーをNextcloudに集約した話。→ 連絡先とカレンダーをiCloud・GoogleからNextcloudに移す

更新履歴 — 2026-09-12: 初版 / 2026-09-13: docker-compose設定・Cloudflare Tunnel公開手順・バックアップコマンドを追記し、再現可能なレベルに書き直し

前提

すでにNextcloudが動いていることを前提にする。まだの場合は先にファイルをGoogle DriveからNextcloudに移すを読んでほしい。

何をしたかったか

連絡先はiCloudとGoogleの両方に分散していた。カレンダーは個人の予定をGoogleカレンダーで管理していた。どちらも「今後もGoogle/Appleに預け続けるほどの理由がない」データなので、ファイルや写真と同じ流れでNextcloudに集約することにした。同期方式は特定の会社に縛られない業界標準の規格(CardDAV・CalDAV)なので、Mac標準の「連絡先」「カレンダー」アプリやiPhoneからもそのまま繋げられる。

Step 1: Nextcloudのアプリパスワードを発行する

まず、CardDAV/CalDAV経由でアクセスするための専用パスワードを発行する。Nextcloud本体のログインパスワードをそのまま外部アプリに渡すのは避け、用途ごとに無効化できる「アプリパスワード」を使うのが基本。

Nextcloudの画面右上のアイコン → 個人設定(Personal settings) → セキュリティ(Security) → 「新しいアプリパスワードを作成」から、名前(例: contacts-migration)を付けて発行する。表示されたパスワードは、この画面を閉じると二度と表示されないので、一時的にメモしておく。

Step 2: 連絡先をエクスポートする(633件)

Google連絡先553件・iCloud連絡先81件を、それぞれvCard形式(連絡先データの標準的なファイル形式、拡張子.vcf)で書き出す。

• Google連絡先: contacts.google.com → 左メニュー「エクスポート」→ vCard形式を選択
• iCloud連絡先: icloud.com → 連絡先 → 全て選択 → 右下の歯車アイコン → 「vCardを書き出す」

重複1件を除いた633件を、まとめた1つの.vcfファイルにしておく(vCard形式は複数の連絡先を1ファイルに連結できる)。

Step 3: CardDAVへ直接PUTする

Nextcloud Web UI(ブラウザ上の管理画面)の「連絡先をインポート」機能も試したが、件数が多いと不安定だったため、CardDAVのエンドポイント(データの送り先URL)へ、1件ずつPUT(データをサーバーへ送り込む処理)する方式に切り替えた。

まず、まとめた.vcfファイルを連絡先1件ずつのファイルに分割する(Pythonのvobjectライブラリや、csplitのようなテキスト分割コマンドで、BEGIN:VCARD〜END:VCARDの区切りごとに切り出す)。分割できたら、1件ずつ以下のようにアップロードする。

curl -u "admin:<Step1のアプリパスワード>" \
  -X PUT \
  --data-binary @contact-001.vcf \
  -H "Content-Type: text/vcard; charset=utf-8" \
  "https://drive.taikiito.com/remote.php/dav/addressbooks/users/admin/contacts/contact-001.vcf"

これを633件分、シェルスクリプトのforループなどで繰り返す。1件ずつリソースとしてサーバーに送り込む地道なやり方だが、Web UIのインポートより確実に反映される。

Step 4: Macで連絡先を同期する

Macの「連絡先」アプリ → 環境設定 → アカウント → 「アカウントを追加」→「他のアカウント」→「CardDAVアカウントを追加」。

ここでハマったポイントがある。macOSは通常、サーバーアドレスを短く入力するだけで.well-known/carddavという決まったパスへ自動でアクセスし、正しいCardDAVのURLへリダイレクトしてくれる仕組みになっている。ところが、Cloudflare経由のリダイレクト処理の影響で、この自動検出がうまく機能しなかった。

解決策: サーバーアドレスの欄に、自動検出用の短いURL(drive.taikiito.com)ではなく、以下のフルパスを直接入力する。

https://drive.taikiito.com/remote.php/dav/principals/users/admin/

ユーザー名はadmin(Nextcloudのユーザー名)、パスワードはStep 1で発行したアプリパスワードを使う。iPhoneの「連絡先」アプリでも同じ設定項目がある。

Step 5: カレンダーの移行(232件)

個人用のGoogleカレンダーに入っていた予定(2019〜2029年、232件)をNextcloud Calendarの「Personal」カレンダーへ移す。

まずcalendar.google.comの設定画面から、対象のカレンダーを.icsファイル(カレンダーの予定データをやり取りするための標準的なファイル形式)としてエクスポートする。

最初はNextcloud Web UIの「カレンダーをインポート」機能で.icsファイルをそのまま読み込ませようとしたが、「could not be parsed」(うまく読み取れなかった、というエラーメッセージ)というエラーで通らなかった。.icsファイルの行折り返し(RFC5545というカレンダーデータの技術仕様で決められたルール)を手直ししても解決しなかったため、連絡先と同じくCalDAVへ直接PUTする方式に切り替えた。

.icsファイルを1イベントずつに分割し(BEGIN:VEVENT〜END:VEVENTの区切りで切り出す)、以下のようにアップロードする。

curl -u "admin:<アプリパスワード>" \
  -X PUT \
  --data-binary @event-001.ics \
  -H "Content-Type: text/calendar; charset=utf-8" \
  "https://drive.taikiito.com/remote.php/dav/calendars/users/admin/personal/event-001.ics"

232件全てこの方式でアップロードしたところ、全て成功した。反映を確認したうえで、Google Calendar側の元データは削除した。ただし、妻と共有しているカレンダーはGoogleに残す判断にした(相手がGoogle前提で使っているため)。ファイル移行の時の「移す理由が移さない理由に勝つものだけ移す」という基準を、ここでも踏襲した形だ。

つまづいた所

1. Web UIの一括インポートは大量データに弱い: 連絡先・カレンダーともに、NextcloudのWeb UIインポート機能は件数が多いと信頼できなかった。少数なら問題ないと思うが、数百件規模ならCalDAV/CardDAVへ直接PUTする方式を最初から選んだ方が早い、というのが今回の教訓。

2. .well-known/carddavのリダイレクトが失敗する: 上記Step 4の通り、自動検出をあきらめてフルパスを直接指定することで解決した。同じ症状はCalDAV側(.well-known/caldav)でも起こりうるので、うまくいかない場合は同じ対処(フルパス直接指定)を試すとよい。

積み残しもある。祖父の命日のような毎年繰り返す予定は、Google側で表示されていた2025〜2029年分のインスタンスだけを削除しており、繰り返しルールそのもの(マスター)は消していない。2030年以降にまた自動で出現する可能性があるため、気になったら改めてGoogle Calendar側で対応する必要がある。また、Gmailにはフライトやレストランの予約確認メールを自動でGoogleカレンダーに追加してくれる機能があるが、これは自前のメール+Nextcloudカレンダーの組み合わせには存在しない、Google独自の仕組みで、メール・カレンダーのどちらか片方だけ移しても再現できない。同等の仕組みを自作するなら別プロジェクトになるので、今回は見送っている。

結果

連絡先633件・カレンダー232件、どちらも移行完了。MacとiPhoneから、Google/iCloudの時とほぼ変わらない感覚で使えている。大量データの移行はWeb UIのインポートを過信せず、CalDAV/CardDAVへの直接PUTを検討するとよい、というのが一番の学びだった。

次は、メモをJoplinに移そうとして、結局全部は移さなかった話。→ メモをiCloud NotesからJoplinに移す

更新履歴 — 2026-09-12: 初版 / 2026-09-13: アプリパスワードの発行手順・実際のcurl PUTコマンドを追記し、再現可能なレベルに書き直し

前提

すでにNextcloudが動いていることを前提にする。まだの場合は先にファイルをGoogle DriveからNextcloudに移すを読んでほしい。Joplin自体は自分でサーバーを用意する必要がなく、既存のNextcloudをファイル置き場として使うだけなので、新しいDockerコンテナを立てる作業は無い。

何をしたかったか

iCloud Notesには、思いついたことをその場で書き留めたメモが1,649件溜まっていた。写真やファイルと同じく、Appleに預けっぱなしのデータを自分の手元に戻したいと考え、Joplinの導入を決めた。

Step 1: Joplinを選ぶ

メモアプリの自前ホスト選択肢もいくつかあるが、Markdown形式(見出しや箇条書きなどを簡単な記号だけで書ける、プレーンテキストに近いメモの書き方)でメモを書けること、Nextcloud WebDAV(ファイルをネットワーク越しにやり取りするための標準規格。専用サーバーソフトを別途用意しなくても、既存のNextcloudがそのまま使える)経由で同期できること、Mac・iPhone両方に公式アプリがあることを決め手にJoplinにした。

Step 2: Nextcloud側にJoplin専用フォルダとアプリパスワードを用意する

Nextcloudのブラウザ画面から、Files(ファイル)アプリで新しいフォルダ(例: Joplin)を作成する。

次に、前の記事のStep 1と同じ要領で、Joplin専用のアプリパスワードを発行する。個人設定 → セキュリティ → 「新しいアプリパスワードを作成」で、名前をjoplin-syncのように分かりやすくしておく。

Step 3: Joplinアプリ側でWebDAV同期を設定する

Mac・iPhoneの両方に公式Joplinアプリをインストールする。設定画面から以下の通り入力する。

• 同期対象: WebDAV
• WebDAVの URL: https://drive.taikiito.com/remote.php/dav/files/admin/Joplin/(adminの部分はNextcloudのユーザー名、末尾のJoplin/はStep 2で作ったフォルダ名)
• ユーザー名: Nextcloudのユーザー名(admin)
• パスワード: Step 2で発行したアプリパスワード

設定後、同期ボタンを押して接続が成功することを確認する。Mac・iPhoneの両方に同じ設定を入れることで、同じNextcloudフォルダを見に行く形になる。

同期は「自動」ではなく「手動」に設定している。 理由は、iPhoneで自動同期(バックグラウンドでの定期的なポーリング)を有効にすると本体が発熱する症状が出たため。常時バックグラウンドで同期し続けるより、メモを書いたタイミングで自分で同期ボタンを押す運用の方が、今のところ実用上困らないと判断した。

Step 4: 過去の1,649件をどうするか検討する

ここまで環境は整ったが、肝心の「iCloud Notesの過去メモをどうやってJoplinに移すか」で立ち止まった。

エクスポート自体は可能(Macの「メモ」アプリからPDFや個別ファイルとして書き出せる)だが、実際に中身を見返してみると、大した情報が入っていないメモがほとんどだった。買い物リストの切れ端、一度きりのちょっとしたメモ、すでに用が済んでいる下書きなど。1,649件を一つ一つ精査して移す価値があるかというと、かかる手間に見合わないと判断した。

最終的に、過去の1,649件はiCloud Notes側にそのまま残し、Joplinは今後書く新規メモ専用として運用することにした。「全部を完璧に移してから使い始める」のではなく、「新しい方から始めて、今後蓄積されるものだけを自分の手元で管理する」という割り切り方だ。ファイル移行の時の「移す理由が移さない理由に勝つものだけ移す」という基準の延長線上にある判断でもある。

結果

Joplinは新規メモの置き場として運用中。iCloud Notesの過去メモはアーカイブとしてそのまま残しているが、能動的に見返すことはほとんどない。「完全移行」にこだわらず、価値のある部分だけを新しい仕組みに乗せる、という判断も移行の一つの形だと思っている。

次は、メールをGmailから自分のドメインに移した、一番苦労した話。→ メールをGmailから自分のドメインに移す

更新履歴 — 2026-09-12: 初版 / 2026-09-13: NextcloudのWebDAV同期の実際の設定手順(URL・アプリパスワード)を追記し、再現可能なレベルに書き直し

前提

• 自分名義のドメイン(取得方法は各ドメインレジストラのサイトを参照。自分はCloudflare Registrarを使った)
• iCloud+の契約(月額サブスクリプション。iPhoneのバックアップ用など、何らかの理由ですでに契約していれば追加コストはかからない)
• ドメインのDNS(「taikiito.comというドメインは実際にはどのサーバーを指すか」をインターネット全体に教えるための住所録のような仕組み)を自分で編集できる状態(Cloudflareなど)

何をしたかったか

Gmailは便利だが、Googleに完全に預けているアカウントでもある。自分名義のドメインを取得したことで、自分のドメインでメールを受け取れる状態が整った。iCloud+はもともとiPhoneのバックアップ用に契約していたので、カスタムドメインのメールボックスを足しても容量を共有するだけで実質タダ。これなら移行のコストに見合うと判断した。

何に移すか: iCloud+ vs Fastmailで迷った話

自前ドメインでメールを使う場合、有名な選択肢としてFastmailがある。料金以外の軸(標準プロトコル対応、Apple以外の端末での使い勝手、エイリアスの上限、送信ドメインとしての評判、データの持ち出しやすさ)で比較検討した。

比較の途中で、自分の思い込みが一つ崩れた。iCloud MailはApple製品専用だとばかり思っていたが、実際には標準のIMAP/SMTP(メールの受信・送信をやり取りするための業界共通の通信規格。この2つに対応していれば、どのメールソフトからでも接続できる)にアプリ専用パスワードでアクセスすれば、Thunderbirdのような普通のメールクライアント(メールを読み書きするためのアプリ)からも使える。「ロックインされて出られなくなる」という一番の懸念はほぼ杞憂だった。すでに契約しているiCloud+の容量を共有できて実質無料な点も踏まえ、Fastmailへの乗り換えは見送り、iCloud+のカスタムドメイン機能を使うことにした。

Step 1: iCloud+でカスタムドメインを設定する

iPhoneの「設定」アプリ → 自分の名前(Apple ID) → iCloud → 「メール」→「カスタムメールドメイン」から設定を開始する(Mac版System Settingsからも同じ設定にたどり着ける)。ドメイン名(例: taikiito.com)を入力すると、iCloud側が必要なDNSレコードを画面に表示してくれるので、それを自分のドメインのDNS管理画面(Cloudflareなど)にそのまま追加する。実際に追加したレコードは以下の3種類だった。

iCloud+の設定ウィザードはこの3つだけを要求し、DMARC(後述、なりすまし対策をさらに強化するレコード)は必須ではなく任意なので、最初は追加しなくても動く。反映には数分〜数十分かかる。全て緑のチェックマークになれば、そのドメインでメールアドレス(自分の場合はme@taikiito.com)を作成できる。

Step 2: 会社のメール環境への到達を確認する

自分の場合、me@taikiito.comからGmailへは問題なく届いたが、会社のメール(Microsoft 365ベース)にはエラーも通知もなく、静かに届かないという問題が起きた。SPF/DKIMを見直しても直らなかったため、DMARC(TXTレコード)を追加した。

_dmarc.taikiito.com  TXT  "v=DMARC1; p=none; rua=mailto:<自分のメールアドレス>"

p=noneはまず様子見のモード(ポリシー違反があっても何もしない、レポートだけ受け取る)。これでも解決しなかったが、SPF/DKIM/DMARCの設定自体には問題が無いことが確認できたので、原因は取得したばかりのドメインが「送信履歴の無い新規ドメイン」として会社側のメールフィルタに警戒されていることだと判断し、時間経過で解決するのを待つ方針にした。実際、数日後には特に追加の変更をしないまま届くようになった。新しく取ったドメインでメールを送る場合、最初の数日〜1週間は主要な送信先に届かないことがあると見込んでおくとよい。

Step 3: なりすまし対策を強化する(SPF/DMARCの締め上げ)

ドメインの送信環境が安定してきたら、なりすまし対策を強める。最終的には以下の設定にした。

_dmarc.taikiito.com  TXT  "v=DMARC1; p=reject; rua=mailto:<自分のメールアドレス>"

p=none(様子見) → p=quarantine(怪しいメールを迷惑メール行き) → p=reject(なりすましメールを完全拒否)の順に段階を踏むのが一般的だが、自分の場合は送信経路がiCloudのみでSPF/DKIMがすでに正常に機能していたため、リスク評価をした上で段階を飛ばしてp=rejectまで一気に進めた。SPFも~all(該当しない送信元は「疑わしい」扱い)から-all(該当しない送信元は「完全に拒否」)へ強化した。

注意: p=rejectにすると、このドメインからのメールを送るときに使う経路(自分の場合はiCloudのみ)以外からは一切メールが届かなくなる。今後、別のメールサービスを追加で使う場合は、SPFレコードに新しい送信元をinclude:で追加し忘れないこと。

Step 4: Gmailからの引っ越しで3つハマったこと

1. Thunderbirdの「3層構造」に気づかず認証が通らなかった

WindowsでThunderbirdを使って移行作業をしようとしたところ、何度設定してもIMAP/SMTPの認証が通らなかった。原因は、iCloudのアカウント構造が3層になっていたこと。

• 表向きのApple IDサインイン用メールアドレス
• 実際のIMAP/SMTP認証に使う、真のiCloudアカウントアドレス(@icloud.com形式)
• 送受信に使う見た目のアドレス(カスタムドメインのエイリアス)

Thunderbirdの手動設定画面で、サーバー情報は以下のようにする。

ポイントはユーザー名欄で、一番上のApple IDのアドレスでも、送受信に使うカスタムドメインのアドレスでもなく、中間層の真のiCloudアカウントアドレスをフルで入力する必要がある。これはApple公式の設定手順のどこにも明記されておらず、自力で突き止めるまで何度も認証エラーに悩まされた。

2. 「完了」と判断したが、実は直近1〜2ヶ月分が抜けていた

Gmailの全メール(46,544件)をThunderbird経由でiCloud側へ移す自作スクリプトを作り、実行した。進捗ログを見ながら待ち、件数がおおよそ一致したことを確認して「移行完了」と判断した。

ところが後日、送信済みメールを見返していて、直近のメールが見当たらないことに気づいた。調べると、スクリプトは古いメールから新しいメールへ順番に処理する作りで、確認した時点では全体の約8割(37,362件/46,544件)までしか進んでおらず、直近1〜2ヶ月分がまだ移行されていない状態で「完了」と誤判断していたことが分かった。「件数がざっくり合っている」だけでは、移行完了の確認として不十分だったという教訓。

3. 復旧作業中に4,293件を誤って喪失、Google Takeoutの原本から復元

上記の見落としを受けて調査していたところ、さらに深刻な問題が見つかった。iCloud側で重複メールを整理する作業をしていた際、4,293件のメールを誤って消してしまっていた。加えて、作業の混乱の中でThunderbirdのローカルインポートフォルダ自体も誤って削除してしまい、復元の頼みの綱を一つ失った。

幸い、Gmailの公式エクスポート機能(Google Takeout、写真移行の記事で使ったのと同じ機能)で取得していた元データ(zipファイル、Gmailの全メールをmbox形式(メールをまとめて1つのファイルに保存する一般的な形式)で含む)がゴミ箱に残っていた。これは「Thunderbirdの中間コピー」ではなく「Gmail公式のエクスポート原本」なので、むしろ最も確実な復旧元だった。

Message-ID(メール1通ごとの一意な識別子、ヘッダーに必ず含まれる)単位で「Takeoutの原本」と「今iCloud側にあるメール」を突き合わせる復旧スクリプトを書き、欠落していたメールを復元した。最終的に、iCloudの1通あたりのサイズ上限を超えている(添付ファイルが大きい)ため原理的に復元不可能な2〜3件を除いて、ほぼ完全に復旧できた。

このとき得た一番の教訓: 大量データの移行を「件数がだいたい合っている」だけで完了と判断しない。Message-IDで突き合わせる方式が、確実に検証する唯一の方法だった。そしてGoogle Takeoutのような「移行元の公式エクスポート」は、移行作業が終わるまで絶対に消さないこと。

Step 5: 移行後の後片付け

Gmail側にme@taikiito.comへの自動転送(Forwarding、Gmailの設定 → 「メール転送とPOP/IMAP」から設定できる)を設定し、移行後にGmail宛へ届く新着メールも自動的に新しいアドレスへ流れるようにした。Google Takeoutのバックアップzipは、Backblaze B2とNextcloudの両方に保存。この3点(バックアップ済み・移行件数の整合性確認済み・新着メールの転送設定済み)を確認したうえで、Gmail側の整理に着手した。

整理は、GmailのAPI(他のプログラムからGmailを操作するための窓口)や管理画面からではなく、IMAP(前述の受信用の通信規格)を直接操作する自作スクリプトで、指定日より前の全メール(49,755件)をGmailの「ゴミ箱」フォルダへ移動する処理を実行した。Gmailのゴミ箱は30日後に自動で完全削除される仕組みなので、今のところ即座に完全削除したわけではなく、猶予期間を残した状態にしてある。この記事を書いている時点では、Gmail側のメールはゴミ箱送りまで完了しているが、Googleアカウント自体はまだ削除していない。しばらくme@taikiito.com側の運用が安定するのを見届けてから、次の判断(アカウント自体を消すかどうか)をするつもりでいる。

結果

me@taikiito.comが主メールとして定着し、日常的に使っている。途中でメールを実際に失いかけた一件は、この移行作業の中で一番肝を冷やした部分だったが、Google Takeoutで原本のバックアップを取っておいたことが最終的に救いになった。大量データを移す時は、移行先だけでなく移行元の生データも別途バックアップしておく、というのが今回一番強く実感した教訓だった。

更新履歴 — 2026-09-12: 初版 / 2026-09-13: DNSレコードの実際の設定値・Thunderbirdのサーバー設定項目を追記し、再現可能なレベルに書き直し

前提

• 常時起動しているLinux環境と、そこからrclone(いろいろなクラウドストレージへファイルを同期するコマンド)で日次バックアップを取っている状態
• バックアップ先はBackblaze B2(安価なオブジェクトストレージ。1GBあたり月$0.005前後)
• 構築の土台は自分の「サーバー」を持つとはどういうことか

何が問題だったか

心配していたのはランサムウェア(侵入したうえでファイルを暗号化し、戻す鍵と引き換えに金銭を要求する攻撃)のような、サーバーを乗っ取られるケース。

「B2側に30日間のバージョン保持(上書き・削除された古い版を30日間取っておく設定)があるから、仮に荒らされても戻せる」と考えていた。これが成立していなかった。

サーバーに置いていたB2のアプリケーションキー(APIから操作するための鍵。権限を選んで発行できる)の権限を一覧してみると、18個の権限が付いていた。問題はこの3つ。

• deleteFiles — ファイルの版そのものを完全削除できる
• writeBucketLifecycleRules — ライフサイクルルール(古い版をいつ消すかの設定)を書き換えられる。「0日で消す」に変えれば30日の保持は即座に無意味になる
• writeBucketReplications — 複製ルールを止められる

つまり鍵を1本盗られたら、バックアップ本体も、それを守るはずの設定も、まとめて壊せる。実際に同期スクリプトが使っていたのはlistBuckets, listFiles, readFiles, writeFiles, deleteFilesの5つだけで、残りは余分だった。

もう1つ、根本的な制約を自分に課した。「予備のハードウェアをもう1台持つ」案は採らない。将来は拠点を移して身軽に暮らしたいと思っているので、機械を持ち続ける前提の設計にはしたくなかった。ハードウェア不要・手作業ゼロで回る形に限定して考えた結果、3層構成になった。

層0: 鍵の権限を必要最小限にする

まずサーバー上の鍵を、実際に使う5権限ちょうどの新しい鍵に差し替えた。

ここで分かった制約: B2のWeb管理画面の鍵発行UIでは権限を細かく選べない。「読み書き」のような粗い単位しかないので、b2コマンド(Backblaze公式のCLI = コマンドライン操作ツール)が必須になる。全権限を持つマスター鍵を扱う作業なので、サーバー上ではなく手元のPCから実行した。

b2 account authorize
b2 key create --bucket <バケット名> <鍵の名前> \
  listBuckets,listFiles,readFiles,writeFiles,deleteFiles
b2 key list --long     # 権限が5つちょうどか確認
b2 key delete <旧鍵のID>

• b2 account authorizeとb2 key createの出力は、どこにも貼り付けない。鍵の本体(パスワード相当の文字列)が含まれる。自分はこの作業中にターミナルの出力をそのままAIチャットに貼ってしまい、鍵が会話ログに残った。同日中にマスター鍵の再発行と露出した鍵の削除で無効化したので実害はなかったが、確認はb2 key list --longで行うのが正しい(鍵のIDと権限しか出さず、本体は出ない)。
• 鍵の状態確認はWeb管理画面を信じない。削除済みの鍵が残って見えたり、新規作成した鍵が出てこなかったりした。b2 key listを正とする。

層0は次の層1とセット。層0をやらずに複製ルールだけ作っても、writeBucketReplicationsを持った鍵でルールごと止められてしまう。

層1: 削除が伝播しない複製先を作る

B2にはCloud Replicationという、バケット(ストレージ上のフォルダのような入れ物)の内容を別のバケットへ自動複製する機能がある。決定的な仕様はこれ。

削除と hideマーカー(B2が「削除された」印として置く目印)は複製されない。

つまり複製先は、構造的にappend-only(追加だけができて削除が伝わらない)なミラーになる。元のバケットでファイルが消されても、複製先には残り続ける。これがランサムウェア対策の本体になる。

同一アカウント内の別バケットへの複製で十分と判断した。理由は、サーバー上の鍵は元のバケットに限定されているので、別バケットには構造的に届かないから。別アカウントが必須になるのは「別リージョンへ複製する場合」だけで、同一アカウント・同一リージョンの別バケットへの複製は普通にできる。別アカウント構成と差が出るのは「B2のログイン自体を乗っ取られた場合」と「リージョン障害」の2つだけで、前者は後述の2段階認証のほうが本質的な対策になる。

複製元を読む鍵・複製先に書く鍵はB2が自動で2本発行し、どちらもB2の内部にしか存在しない(サーバー上に置かれない)。侵害経路にならないのがこの構成の強み。

複製先のライフサイクル設定でUIに落とし穴が2つあった。

• 🔴 「Keep only the last version」(最新の版だけ残す)を選んではいけない。上書き攻撃を受けた瞬間に正常な旧版が消え、複製先を用意した意味がなくなる。必ずUse custom lifecycle rulesを選ぶ。
• 🔴 Days Till Hideは必ず空にする。ここに数字を入れると、現役のバックアップ本体が自動削除される。埋めるのは「古い版を何日後に消すか」の1箇所だけ。

自分は古い版を180日で削除に設定した。毎晩上書きされるデータベースのダンプ(写真サーバー188MB + ファイルサーバー18MB + 認証サーバー13MB ≒ 日220MB)が積み上がって年80GB増える計算だったため。180日なら約40GBで頭打ちになる。保護が弱まるわけではない——削除は複製されないので消されたファイルには無関係で、上書き攻撃は次の層2が1週間以内に検知する。

複製元141.5GB・118,503ファイルに対して、複製先は149.0GB・118,976ファイルで完了。複製先のほうが大きいのは設計どおり(元で消えた・上書きされたファイルが残り続けるので膨らむ)。初回コピーは数日かかった。

• 初回コピーの進捗はAPIでは測れない。B2が複製の状態フラグを付けるのはルール作成後に新規アップロードされたファイルだけで、既存ファイルの後追いコピー分は全件「未設定」のまま。進捗はWeb管理画面の複製先バケットのファイル数で見るしかない。
• 初回コピー完了を待つ必要はない(層2の判定は「減った/増えていない」なのでコピー中に誤報は出ない)。ただしライフサイクル設定は初回コピー完了まで触らない——コピー中の変更は直後のファイルが消える危険があると公式ドキュメントに明記されている。
• コストは複製分で月$0.70。複製の転送料は無料。

層2: サーバーの外に見張りを置く

複製が本当に続いているかを誰も見ていなければ、仕組みは静かに壊れる。そこでデッドマンスイッチ(定期的な生存信号が途絶えたら警報を出す仕掛け)を用意した。

肝はサーバーの外で動かすこと。サーバー監視には別途Uptime Kumaを使っているが、これはサーバー自身の上で動いているので、サーバーごと死んだら自分の死を通報できない。

実装はGitHub上の非公開リポジトリ1つ + GitHub Actions(GitHubが提供する、決めた時刻やイベントでスクリプトを自動実行する仕組み)。週1回、複製先バケットを走査して、次のどれかに当たったらTelegramへ通報する。

1. ファイル件数が前回より減った
2. 合計サイズが前回比1%を超えて減った
3. 21日間まったく増えていない
4. B2へ接続・認証できない

観測値はリポジトリ内のJSONファイルにコミットして、次回の比較基準にする。外部ライブラリは使わず標準ライブラリだけでB2のAPIを直接叩く作りにした(依存が増えると、それ自体が壊れる原因になる)。見張り用の鍵は複製先バケット限定・読み取り専用なので、こちらはWeb画面の発行UIで作れる。

• 件数の減少は「複製先を直接触られた」ことのシグナルとして意味が強い(削除は複製されないので、正常運用では減らない)。
• 上書き破壊の検知は不完全だと正確に理解しておく。同サイズ・より大きいサイズで上書きされた場合は検知できない。ただしその場合も版管理で旧版が残るので復元は可能で、守りは版管理側が担っている。
• GitHub Actionsの定時実行は大幅に遅れる。0 1 * * 1(毎週月曜01:00 UTC)と書いたジョブが実際に走ったのは06:16 UTCで、5時間16分遅れだった。:00は最も混雑する分なので、奇数分(17 1 * * 1など)にずらすと改善する。週次監視なら遅延自体は無害だが、時刻を当てにした説明を書かないこと。
• 通報が空振りする状態で放置してはいけない。鍵をGitHubのSecrets(リポジトリに暗号化して保存する秘密情報)に登録する前に初回の定時実行が走り、認証情報が無くて失敗した。設計どおりの挙動だが、これを放置すると毎週失敗通知が来て、デッドマンスイッチの警報を無視する習慣がつく。それが一番の実害。

踏んだ落とし穴: 「鍵の差し替え」が設定ファイルを作り直していた

層0の鍵差し替えには、以前自分で書いたrotate-b2-key.shというスクリプトを使った。これがrcloneの設定ファイル(rclone.conf)を丸ごと作り直す作りになっていた。

同じ日の朝に、送信前に自前で暗号化するための設定ブロックをこのファイルに追加していた。スクリプトはそのブロックを知らないので、鍵の差し替え自体は成功したのに直後のバックアップが「設定ブロックが見つからない」で全滅した。

• 教訓: 構成に新しい設定ブロックを足したら、そのファイルを書き換える既存スクリプトを洗い出す。「鍵の差し替え」という名前から、設定ファイル全体を作り直しているとは読み取れなかった。
• スクリプトは、丸ごと上書きをやめて該当2行だけを置換する形に直した。加えて書き込む前に「設定ブロックが減っていないか」「新しい鍵IDが入ったか」を検査し、1つでも失敗したら一切書かずに中止するようにした。
• 🔴 もう1つの地雷: 設定ファイルはroot用と一般ユーザー用の2箇所にあり、復旧を片方だけやって放置していた。バックアップはrootで動くので「成功」と出続け、一般ユーザーで実行したときだけ静かに失敗する状態になっていた。
• 教訓: 「両方必要」と書いた手順は、実施後に必ず両方を実測で確認する。grep "^\[" <設定ファイル1> <設定ファイル2>のようにセクション名だけ出すコマンドなら値が漏れないので、安心して結果を見られる。
• おまけの罠として、ssh サーバー 'bash -s' <<'EOF'形式のヒアドキュメント(複数行のスクリプトを流し込む書き方)はsshの標準入力と競合して出力が二重化し、成功したのか失敗したのか読めなくなった。サーバー操作は1行のssh サーバー '...'に分解して1つずつ流すのが確実だった。

2段階認証が1段階だった

作業中にもっと基本的な穴が見つかった。「2段階認証は済んでいる(ログインのたびにメールでコードが来る)」と認識していたが、これはBackblazeが既定で有効にしているメールMFA(多要素認証)だった。

コードの送り先も、パスワードリセットの送り先も、同じメールアドレス。つまりメールボックス1つ取られると2要素が1要素に潰れる。同一アカウント構成を選んだ結果、このアカウントが全データの唯一のオフサイトコピーを持っているので、ここが設計上の最大の残留リスクだった。

TOTP(認証アプリが30秒ごとに生成する6桁コード方式)に切り替えて解消した。

• 認証アプリはEnte Auth のオフラインモード(アカウント登録なしで使える)を選んだ。Google Authenticatorは、自分がGoogleアカウントを削除する方針で同期が使えないこと、Google Playが載らない端末への移行を検討していることの2点で不適だった。アプリ登録が必要なものだと、復旧手段がまた別の会社のアカウントに依存して、断ち切った鎖を作り直すことになる。
• バックアップコードは必ず生成してパスワードマネージャーに保存する。ただしTOTPそのものは同じ金庫に入れない(同じ場所に入れたら1要素に戻る)。TOTPはスマートフォンのアプリに、バックアップコードはVaultwardenに置いた。

残る「鶏と卵」

この構成にも、原理的に閉じない循環が残っている。

• B2に入るには → TOTP(スマートフォン)
• スマートフォンを失くしたら → バックアップコード(Vaultwarden)
• VaultwardenはサーバーVPS上 → サーバーを失ったらB2から復元が必要 → B2に入る必要がある

スマートフォンとサーバーを同時に失うと詰む。対処は「バックアップコードを紙でもう1箇所持つ」しかない。これはパスワードの移行の記事で書いた、バックアップの取り出し鍵自体をどこに置くかという問題とまったく同じ構造になっている。自前で持つほど、最後の1本をどこに置くかという問題に必ず行き着く。

結果と、やらなかったこと

鍵の権限削減・append-onlyな複製先・サーバー外の見張りの3層が稼働状態になった。追加費用は複製分の月$0.70だけで、ハードウェアは1台も増えていない。

やらなかったことも書いておく。Backblazeというプロバイダ1社に依存しているのは未対策のまま。アカウントの凍結や会社都合に備えるなら、別会社のストレージへもう1本(追記専用の設定で月€4前後)が答えになるが、今回は見送った。手を広げる前に、今ある3層が本当に回り続けるかを数ヶ月見ておきたかった。

更新履歴 — 2026-10-01: 初版

その障害の記録と、そこから海外VPS(レンタルサーバー)へ移った記録。壊れた機械からデータを転送するのではなく、毎晩取っていたクラウドバックアップからVPS側へ引っ張って復元したのが一番再利用できる部分だと思う。実際の停止時間は26分だった。そして移行後、自宅のルーターの内側にいたから気づかずに済んでいた穴が一気に表に出た。

前提

• 自宅のWindows機〈ノート型〉(WSL〈Windowsの中でLinuxを動かす仕組み〉上でサーバーを動かしていた)で、Immich(写真)・Nextcloud(ファイル)・Vaultwarden(パスワード)・Authentik(ログインの入口)など常時14コンテナを動かしている状態
• 外部公開はCloudflare Tunnel(ルーターに穴を開けずにサーバーを公開する仕組み)経由で、ルーターのポート開放は一切していない
• 毎晩rclone(いろいろなクラウドストレージへファイルを同期するコマンド)でBackblaze B2(安価なオブジェクトストレージ)へ日次バックアップを取っている
• 構築の土台は自分の「サーバー」を持つとはどういうことか、バックアップの設計はバックアップを「消されても戻せる」形にする

何が死んだのか

最初の症状は、自分のドメインを開くとCloudflare Error 1033(トンネルの出口であるサーバー側にCloudflareが接続できない時のエラー)が出たこと。Cloudflareの障害情報ページには何も出ていない。別経路のリモートデスクトップで見ると「最後のオンライン 12:07」でオフライン表示。トンネルが切れたのではなく、サーバーの入っているPC自体が落ちている。

遠隔からできることは何もなかった。SSHも入れない。Cloudflare Tunnelは「サーバーが生きていれば外から入れる」仕組みなので、サーバーが死ぬと一緒に死ぬ。

帰ってから見たPCの状態がこれ。電源は入っていて画面も出ているのに、マウスカーソルが一切動かない。 キーボードも効かない。ブルースクリーンも出ていない。電源ボタンの長押しで強制終了して再起動したら、何事もなかったように復旧した。

後日イベントログを調べて停止時間が確定した。

EventLog ID 6008
"The previous system shutdown at 11:11:13 AM on 9/21/2026 was unexpected."

このログが記録されたのは9/26 23:45(自分が強制再起動した時刻)。つまり9/21 11:11:13にハングして、そこから5日半固まったままだった。

• 9/21〜9/26の間、Systemログにイベントが1件も記録されていない。完全な空白。瞬断の繰り返しではなく、OSが本当に何も処理できない「サイレントハング」だった裏付けになる。
• ブルースクリーンのダンプファイルが無い(残っていたのは1年半前の古いものだけ)。ディスプレイドライバのクラッシュログも0件。写真の顔認識にGPU(画像処理用の高性能な部品)を使っていたのでGPUドライバのハングが一番疑わしい候補だったが、ログが書かれる前に固まった可能性もあり確定できなかった。

根本原因は今も分かっていない。 BSODもエラーログも残さず固まる種類の故障は、原因究明が原理的に難しい。

🔴 ここで一度、原因を誤診した。 強制再起動後に別のソフトの認証セッションが切れていたので、最初はそれが5.5日の原因だと分析した。実際は「PCが固まっていた」が唯一の原因で、セッション切れは再起動後に浮上した二次的な問題だった。復旧直後に見つかった不具合は、障害の原因ではなく結果であることがある。 時系列のログで裏を取るまで原因を名指ししない。

なぜVPSに移ることにしたか

最初に考えたのは、もっと安い対策ばかりだった。ウォッチドッグタイマー(固まったら自動でリセットする機能)、GPUドライバの更新、旅行時はSSHできる端末を必ず携帯する運用ルール。

🔴 「スマートプラグで遠隔から電源を入れ直す」案は、そもそも使えなかった。 サーバーにしていたのはノート型のWindows機で、内蔵バッテリーがあるのでコンセントを切っても電源は落ちない。ノートPCを常時稼働のサーバーに流用するのは「静かで省電力」という利点があって自分もそれで選んだのだが、固まったときに遠隔で殴る手段を一つ失うという代償がついてくる。これは置き場所を決める段階で知っておきたかった。「WindowsをやめてこのPCを素のLinux専用機にする」案も検討したが否定的な結論になった。マウスも効かないOS全体の停止なのでLinux側だけの不調ではなく、原因がGPUドライバなら素のLinuxでも再発しうるので、OS再インストール＋全サービス移行という大工事に見合う保証がない。

それでも移行を決めた理由は、数日後に同じサイレントフリーズが再発したこと。原因が分からない以上「次はいつ、どれだけ止まるか」が見積もれない。データセンターの機械なら、少なくとも電源とネットワークと物理的な復旧は他人の仕事になる。

VPSの比較で実際に効いた軸

2026年9月時点の調査値。今は変わっているはず。

効いた軸は4つ。

① ディスク容量が最優先。 写真のライブラリが実測115GB、ファイル同期が16.6GB。OS・Docker・データベースを含めて170〜180GBと見積もり、200GBのプランにした。「写真が増えるたびに月額が雪だるま式に増えるのが嫌だ」という条件があったので、同じ値段でどれだけディスクが付いてくるかが一番差の出る軸になった。

② メモリは写真の量ではなくコンテナの数で決まる。 ここは一度自分で間違えかけた。「古い写真をクラウドへ逃がすならメモリも小さくていいのでは」と考えたが違う。常時14コンテナが動いていて、以前メモリ不足で全サービスが繰り返し落ちた実績がある。しかもVPSにはGPUが無いので、顔認識や画像検索の処理をCPUとメモリでやることになり、必要メモリはむしろ増える。8GBではなく12GBから始め、安定を確認してから下のプランへ落とす順序にした。

③ リージョン(どの国のデータセンターか)は在庫で決まった。 第一候補にしていたリージョンは月+$4.90の追加料金がつく上に、申し込み画面で在庫切れだった。追加料金ゼロで常に在庫があるリージョンに変えたら、結果としてバックアップ先のB2との経路が短くなり、復元も移行後の日次バックアップも速くなるという副産物があった。「近いほうが良いに決まっている」と思い込んでいた軸が、実際には料金・在庫・バックアップ先との距離で裏返った。

④ 遅延は実測すると論点が変わる。 申し込み画面の「近いリージョン4ms、遠いリージョン158ms」は生のネットワーク遅延で、Cloudflare Tunnel経由の実構成には当てはまらない。自宅のPCで動かしていた時点ですでに写真サーバーの初期応答は73〜87msだった。DNSがCloudflareを指しているので、自宅のWiFiからでも一度エッジへ出て戻る経路になり、「目の前にあるから速い」状態には元々なっていなかった。移行後は0.55〜0.7秒(自宅PC時代は0.3秒前後)。比較のためにGoogle Photosのアプリ画面を測ると248〜255msで、「すでに受け入れている遅さ」と同程度だと分かったので許容できる論点に落ちた。

• 🔴 サムネイルをCloudflare側にキャッシュさせれば速くなるが、それは自分の写真をCloudflareに置かせることになるのでやらない。速度のために主権を手放すなら移行の意味がない。

契約は6vCPU / 12GB RAM / 200GB SSD / 転送量無制限、Ubuntu 24.04、1ヶ月契約で月$9.00、初期費用ゼロ。年契約の割引は見送った。原因不明の障害から逃げるための移行で、移行先が気に入らなかった時にすぐ降りられないのは本末転倒だから。

移行方式: 壊れた機械から運ぶのをやめる

ここが今回の中心。

普通に考えると、移行とは旧サーバー → 新サーバーへデータを直接転送することだ。ランブックの最初の案もそうなっていた。150GBをrsync(差分だけコピーするコマンド)で送る、数時間〜半日かかる、という計画。

これを見て思ったのが、**「毎晩クラウドにバックアップを取っているのだから、新サーバーがそこからダウンロードすればいいのでは?」**だった。採用した。

これまでの案:  自宅PC ──(細い家庭回線)──> 新VPS
採用した案:    自宅PC ──> B2(クラウド) ──(データセンター間)──> 新VPS

1. 自宅の細い上り回線に依存しない。VPS↔B2はデータセンター間なので桁違いに速く、実測で約30MB/sだった。
2. 旧サーバーが移行作業中ずっと安定している必要がない。これが決定的だった。5.5日固まる機械を、半日の転送が終わるまで無事でいてくれと祈りながら使うのは設計として間違っている。
3. 既にそこにあるので準備作業がゼロ。写真の本体もデータベースのダンプ(中身を1つのファイルに書き出したもの)も毎晩同期済み。
4. ついでに災害復旧の予行演習になる。「クラウドのコピーしか残っていない状態から戻せるか」を本番で一度やることになるので、バックアップが本当に使えるのかが確定する。

鶏と卵の問題は先に解いてあった

前提がある。B2から引っ張るにはB2へのアクセス鍵が必要で、その鍵が旧サーバーの中にしか無ければ、サーバーを失った時点で何も取り出せない。

ここは1ヶ月前に手を打ってあった。B2アクセス用のrclone設定、Cloudflare Tunnelの設定、docker-compose.yml一式、環境変数ファイルの内容を、Vaultwarden(自分のパスワード管理サーバー)にSecure Note 4件として複製保存していた。 Vaultwardenのモバイルアプリはオフラインキャッシュを持つので、サーバーに一切アクセスできなくてもスマートフォンから取り出せる。後日このメモに書かれた値だけでB2上の全データが見えることを実測で確認した。🔴 この検証は鍵を入れ替えるたびに毎回やる。 「保存したつもり」で中身が古い、という事故が一番ありそうな場所だから。

ランブックの形

手順はPhase A〜Hに分けて1つの文書にした。実行中にその場で考える余地を削るのが目的で、特にDNSの切り替えは後戻りの判断が数秒で要る。

Phase A  旧サーバーを止めて最終バックアップ
Phase B  Vaultwardenから鍵4件を取り出す
Phase C  新VPSの初期設定(ユーザー・SSH鍵・Docker)
Phase D  B2から rclone copy でデータを引っ張る
Phase E  データベースのダンプをリストア
Phase F  docker-compose を復元してコンテナ起動
Phase G  新しいトンネルを作ってDNSを1本ずつ切替
Phase H  移行後(バックアップの再構築・監視・検証)

書き上げた最初の版には穴が4つあり、実行前のレビューで直した。

• 稼働中のままコピーしたパスワードデータは壊れている可能性がある。 Vaultwardenのデータベースファイルは書き込み中にコピーすると不整合になりうる。当日はコンテナを止めてからバックアップを手動実行する手順に変えた。これで「日次バックアップから最大24時間分が欠ける」問題も同時に消える。
• 🔴 イメージのバージョンを固定せずに復元すると壊れる。 データベースのダンプは、取得した時点のソフトのバージョンの構造に紐づいている。docker compose pullで最新版を取ると構造が合わなくなる。
• 環境変数ファイルの復元元を間違って書いていた。 以前使っていたパスワード管理サービスは解約済みで、正しくはVaultwardenだった。手順書は、書いた時点では正しくても構成変更で腐る。
• 🔴 同じトンネルを2台のホストで同時に動かしてはいけない。 リクエストが2台にランダムに振り分けられて、「たまに繋がらない」という一番デバッグしづらい障害になる。新しいトンネルを別に作って、DNSを1本ずつ向け替える形にした。

他に決めておいたこと。

• rclone copyを使い、syncは使わない。syncは転送元に無いファイルを転送先から消す。過去にこれで必要なディレクトリを消して障害にした実績がある。
• 切替順序: 一番軽いパスワードサーバー → ログインの入口(最重要。落ちると他のサービスにログインできなくなる) → ファイル → 写真 → 残り。旧サーバーへのSSH経路は一番最後。 先に向け替えると旧サーバーに入れなくなって確認作業ができない。
• DNSのTTL(切替が反映されるまでの待ち時間)を事前に短くする手順は不要だった。 対象レコードは全部Cloudflareのプロキシを通る設定で、外に返るアドレスは切替前後で変わらない。振り分けはCloudflare内部で起きるので書き換えの数秒後に反映され、戻すのも数秒。TTLを下げる必要があるのは、プロキシを通さずサーバーのアドレスを直接返している場合だけ。

実際の停止時間は26分

15:19にサービスを止めて、15:45に全部復帰した。 写真150GBを運ぶ移行としては想定よりはるかに短い。クラウド経由にしたことで、一番重い写真の転送が「停止中にやる作業」から外れたのが効いている。

復元後の検証値は、写真59,104ファイル(rclone checkでB2との差分ゼロ)、写真サーバーの登録件数29,720件、ファイル同期サーバー144テーブル・16.6GB、ログイン入口のユーザー3件。

ランブックに書いていなかった落とし穴

• 🔴 浮動タグが他にもあった。 バージョン固定は写真サーバーだけ警告していたが、ファイル同期・データベース・パスワード管理も:latest(常に最新を取るタグ)のままだった。旧サーバーで実際に動いているイメージのダイジェスト(内容に対する一意の識別子)を全部調べて固定した。docker inspectの.Imageはそのマシンの中だけのIDでダウンロードには使えないのでRepoDigestsを使う。
• 🔴 写真サーバーが起動ループした。 Failed to read /data/encoded-video/.immich。サムネイルと変換済み動画のフォルダをバックアップ対象から外していたため、そのフォルダにある整合性チェック用の目印ファイルまで一緒に欠けていた。空のフォルダではなく「目印だけがある」状態が必要だった。
• ファイル同期サーバーがCannot write into "config" directory!で503。 rcloneはファイルの所有者情報を保持しないので、復元したファイルが全部自分のユーザーの所有になっていた。クラウド経由の復元では所有者が落ちることを前提に、復元後のチェック項目に入れておく。
• 🔴 ユーザーのIDが揃っていなかった。 新VPSに旧サーバーと同じ名前のユーザーを作ってパスを揃えたので、設定ファイルを無改造で使い回せた。これは正解だった。ただし名前は同じでも内部の数値のIDが1つずれていて、一部のコンテナ内でNo user exists for uid 1001で落ちた。名前だけでなく数値IDまで揃える必要がある。
• 「Dockerのデータとワークスペースを移せば終わり」ではなかった。 動画変換用のコマンドや日本語フォントといったホスト側のOSパッケージが新VPSに無く、移行の夜に機能が動かないことで発覚した。さらにcron(定時実行の仕組み)自体が未インストールで、登録コマンドが黙って失敗していた。バックアップの自動実行が最初から動いていないところだった。
• 🔴 写真46件が旧サーバーにしか存在しなかった。 復元結果をファイル単位で突き合わせて翌日見つけた。データベースには46件の記録があるのに、写真の実体がVPSにもB2にも無い。原因は、移行当日の最終バックアップでデータベースのダンプは成功し、写真の同期ステップが完走しないまま終わっていたこと。しかも旧スクリプトはステップごとの成否をログに出していなかったので無言で失敗した。旧サーバーがまだ生きていたので手元から押し出して復旧できたが、運が良かっただけ。
  • 教訓1: 復元の検証を「ファイル数の一致」でやってはいけない。 60,525件と60,619件で0.15%差。見逃す水準だった。データベースに記録されているパスが1件ずつ実在するかを全件突き合わせる必要がある。
  • 教訓2: バックアップスクリプトはステップごとにOK/FAILをログへ出す。 まさにこの欠陥を直すつもりだった移行当日に、その欠陥に刺された。

公開IPになって初めて出た問題

ここが一番多くの人が外すところだと思う。移行そのものより危ない。

自宅のPCはルーターの内側にいた。 だから、どのサービスが「外から直接届く形」で動いていようが、外からは届かなかった。Cloudflare Tunnelという1本の出口だけが外部との接点だった。VPSは公開IPを持っている。 全部のポート(通信の入口の番号)が、世界中から直接叩ける状態で始まる。ランブックにこの観点は1行も無かった。

① 中身が剥き出しで公開されていた

写真サーバーのログイン画面が生で公開されていた。Cloudflare側のログイン要求を通らない素の入口。ログイン入口サーバーのHTTPSポートも公開で、本来Cloudflare側の防御を通ってから届くはずのものが迂回できる状態。小さな静的サイトのポートも開いていた。

原因はdocker-compose.ymlのports:の書き方。

ports:
  - '2283:2283'            # 🔴 これは全てのネットワークに向けて開く
  - '127.0.0.1:2283:2283'  # ✅ 自分自身からしか届かない

自宅では両方とも同じ結果になるので、違いに気づく機会がなかった。トンネル経由で公開する構成なら、外に向けて開く必要は最初から無い。

応急処置としてファイアウォールで遮断し、後日、設定ファイル側を127.0.0.1に直して「ファイアウォールで塞いでいる」状態をやめた。この順序は意図的で、ファイアウォールなら数秒で塞げるがコンテナの作り直しは止まる時間が出るから。ただし応急処置で終わらせない。ファイアウォールは1行消えれば無防備に戻るが、そもそも誰も外向きに待ち受けていなければ消しようがない。

② SSHのパスワードログインが「無効にしたのに有効」だった

/etc/ssh/sshd_config.d/50-cloud-init.conf   ← PasswordAuthentication yes
/etc/ssh/sshd_config.d/99-hardening.conf    ← PasswordAuthentication no(自分が書いた)

SSHのサーバーは「最初に見つけた値」を採用する。 番号が小さいファイルが先に読まれるので、99番に書いた自分の設定は永遠に負ける。VPSの初期設定が置いていった50番のファイルを無効化して解決した。🔴 設定を書いたら、書いたことを確認するのではなく、効いているかを確認する。 鍵でログインできることと、パスワードが本当に拒否されることの両方を実測する。

③ IPv6が完全に丸腰だった

ここが一番ひやりとした。遮断はしたが、IPv4のファイアウォールだけだった。

VPSにはIPv6のアドレスも付いている。確認すると、IPv6側のファイアウォールのルールは空、ポリシーは全通過。コンテナはIPv4とIPv6の両方で待ち受けていたので、塞いだつもりの写真サーバーのログイン画面は、IPv6経由では公開されたままだった。🔴 IPv4を塞いだら必ずIPv6も確認する。 設定は完全に別物で、片方だけやっても「塞いだ」とは言えない。

④ 認証なしのポート19本が素通しだった

自分のアシスタントが外部サービスと喋るための中継プロセスが、ポート19本で認証なしで待ち受けていた。ファイアウォールのルールも無かった。この中の1本は自分のメールの受信箱に繋がっていた。 写真のログイン画面(少なくともパスワードは要求する)より危険度は上だった。

思い込みが穴を作った。「外に出ているポートはdocker-composeのports:に書いてあるものだけ」と思っていた。これらはコンテナではなくホスト上で直接動いているプロセスなので、Docker向けのファイアウォール設定では止まらない。棚卸しの書き方にも罠がある。

# 🔴 これでは漏れる
ss -tlnp | grep 0.0.0.0

# ✅ 「自分自身以外」を除外方式で全部出す
ss -tlnp | grep -vE "127\.0\.0\.|\[::1\]"

待ち受けアドレスの表記は0.0.0.0:PORTだけではない。*:PORTという表記(IPv4とIPv6の両方で待ち受け)もあり、0.0.0.0では引っかからない。 19本はこの形で見落とされていた。**「危ないものを探す」のではなく「安全なものを除外して残り全部を見る」**書き方にしないと漏れる。

後日これも応急処置をやめて根本を直した。使っていた中継ソフトには待ち受けアドレスを指定するオプションが存在しなかったので、ソフト側のコードを1行書き換える形になった。直した後の確認が気持ちよかった。公開IPへは「接続拒否」が返る — ファイアウォールで弾いているのではなく、そもそも誰も待ち受けていない状態になった。これが一番強い証明。

⑤ ファイアウォールの確認は、そのサーバー自身からでは絶対にできない

遮断ルールには「外部から来た通信に対して」という条件が付く。VPSの中から自分の公開アドレスに繋ごうとすると内部の経路を通るので、必ず「繋がる」と出る。 塞がっているのに塞がっていないように見える。

# 別のパソコンから実行する(VPS内からでは意味がない)
nc -vz <サーバーのアドレス> 2283   # → Operation timed out  が正しい
nc -vz <サーバーのアドレス> 22     # → succeeded!            が正しい
nc -vz -6 <IPv6アドレス> 2283      # IPv6も必ず測る

この外部からの実測を、VPSを再起動した後・ファイアウォールを触った後・docker-composeを触った後に回す定型チェックとして手順書に書き出した。

⑥ 監視が自分の死を通報できない

死活監視にUptime Kumaを使っているが、それが監視対象と同じVPSの上で動いている。VPSごと落ちたら監視も一緒に落ちて通知が飛ばない。一番知りたい障害だけ通報されない。 バックアップの記事で書いたデッドマンスイッチ(生存信号が途絶えたら警報を出す仕掛け)と同じ構造なので、B2の複製先を見張らせていたGitHub Actions(GitHubが決めた時刻にスクリプトを自動実行する仕組み)に死活監視を1本足して解決した。サーバーの外で動くので、サーバーが丸ごと死んでも黙らない。

再起動して自分で戻ってくるかを確かめる

移行が完了した状態は、一度も再起動していない状態でもある。「今動いている」と「電源が落ちても自分で戻ってくる」は別の話で、自宅サーバー時代は再起動のたびに何かが立ち上がらない問題に何度も遭遇していた。

事前に、systemdのユニット7件がすべてenabled(起動時に自動で立ち上がる設定)か、コンテナ14個の再起動ポリシーがunless-stoppedかalwaysかを確認した。ファイアウォールのルールを永続化する仕組みも必ず含める — ここが抜けると再起動で遮断ルールが消え、さっき塞いだ穴が全部開く。厄介な事情が1つあって、自分のアシスタント自身がこのVPSの上で動いているので、再起動すると自分との会話も切れる。1分の猶予を置いて再起動し、復旧手順をチャットの外に控えておく段取りにした。自分を再起動する作業は、自分以外の場所に手順を置いてから実行する。

結果は成功。22秒で起動し、systemd 7件・コンテナ14個すべて稼働、全9サービスがHTTP 200/302、データも再起動前と完全一致。そして外部のパソコンからのnc実測で、遮断したポートはOperation timed out、SSHはsucceeded! — 永続化が再起動をまたいで効いていることを外部視点で立証できた。

後日ディスクを増設した時にこちらの意図しない強制リセットが起きた(公式ヘルプには「再起動不要」と書かれていたが実態は違った)。その時も全部がデータ欠損ゼロで自動復帰したので、この検証が本物だったことは意図せず二重に確認できた。増設系の作業は、公式が無停止と書いていてもダウンタイムを見込む。

結果

• 原因不明の5.5日間停止から、26分の停止で海外VPSへ移行した。月額は$9.00から始まり、後にディスク増設で$12.60
• 応答は0.3秒前後から0.55〜0.7秒に落ちた。遅くなったのは事実で、これは引き受けた
• 公開IPになって初めて出た露出を6種類見つけて塞いだ。うち2種類(IPv6と、認証なしの19本)は最初の対処では見落としていた

旧サーバーはすぐ捨てずに2週間温存した。これは正解で、移行翌日に「写真46件が旧サーバーにしか無い」と判明した時に助かった。復元の検証が全部終わるまでは、古い機械を消してはいけない。

そしてハングの原因は今も分かっていない。分からないまま、分からないものに依存する構成をやめた、というのが今回やったことの全部だ。

更新履歴 — 2026-10-05: 初版

結論を先に書くと、自分は古い写真を安いオブジェクトストレージへ追い出す仕掛けを一晩かけて作り、動くところまで確認してから、全部捨てた。業者が月$3.60でディスクを足せると分かったからだ。その遠回りの中身を書く。

前提

• 写真はGoogle PhotosからImmichに移した状態（Immich = 自前サーバーで動かす写真管理ソフト）
• サーバーは自宅PCからVPSへ移した直後（VPS = 仮想専用サーバー。業者のデータセンターにある自分専用のLinuxマシンを借りる形）。Contaboの6vCPU / 12GB RAM / SSD 200GB のプランで月$9.00（2026年9月時点）
• バックアップ先はBackblaze B2（安価なオブジェクトストレージ。2026年9月時点で1TBあたり月$6.95）。構成はバックアップを「消されても戻せる」形にする
• 土台の考え方は自分の「サーバー」を持つとはどういうことか

まず現実を測った

移行直後のディスクはこうだった。

df -h /
# 使用 164GB / 193GB、空き 29GB

しかもこの時点でサムネイル（一覧表示用の縮小画像）がまだ生成されていなかった。以前のサーバーでは9.6GBあったので、それが戻ると空きは約19GB。200GBのプランを選んだ数日後にもう先が見えた。

次に増える速さを測った。Immichのデータベースに撮影年が入っているので、年ごとに集計できる。

select extract(year from a."fileCreatedAt"), count(*), pg_size_pretty(sum(e."fileSizeInByte"))
from asset a join asset_exif e on e."assetId" = a.id
where a."deletedAt" is null group by 1 order by 1;

実測（写真の実体は合計115GB）。

• 直近3年分の合計で約22GB。年あたり3〜10GBのペース
• それより古い分が約19,000件・約93GB

つまり今の撮り方で年10GB弱。29GBの空きは3年もたない。いずれRAW（カメラが記録した無加工のデータ。1枚25〜50MB）で撮り始めたら桁が変わる。「毎年ちょっとずつ月額が増えていく」のが一番嫌だったので、容量と月額を切り離す方法を探し始めた。

最初の案: 古い写真を安いストレージへ追い出す

サーバーのSSDには直近1〜2年の「よく見る」写真だけ置き、古い写真はB2に預けて見たいときだけ取り出す。 SSDの使用量が年によらず一定になるので月額が増えない。B2には毎晩のバックアップで全写真の実体がすでにあるから、アップロードすらいらないのが魅力だった。

方式をいくつか捨てた

• 🔴 Immichの「External Library」（外部ライブラリ）機能は使えない。サーバーの外のフォルダを読み込む機能だが、すでにImmichの中にある写真を引き取れず、新規の写真として再登録される。アルバム・顔認識の結果・お気に入りが失われる恐れがある。
• 🔴 「年ごとのフォルダを切り出す」はそもそも不可能。ディスク上の写真はlibrary/upload/<ユーザーID>/<16進2桁>/<16進2桁>/<ランダムな名前>.拡張子という形で、ランダムな名前のハッシュで256×256のフォルダに均等にばらまかれている。年ごとのフォルダは存在しない。

残ったのは、写真ファイル1個ずつをシンボリックリンク（ファイルの位置を指すだけのショートカット）に置き換え、リンク先をB2をフォルダとして見せた場所に向ける方式。データベースに一切触らないので、Immichから見れば何も変わらない。B2をフォルダとして見せる部分はrclone（いろいろなクラウドストレージへファイルを同期するコマンド）のマウント機能で、読み取り専用で常駐させた。

# /etc/systemd/system/rclone-immich-cold.service の要点
ExecStart=/usr/local/bin/rclone mount <リモート名>:<バケット>/immich-cold \
  /home/<user>/immich/library/cold \
  --read-only --allow-other --uid 1001 --gid 1001 \
  --vfs-cache-mode full --vfs-cache-max-size 3G --dir-cache-time 24h

ここで踏んだもの。

• rcloneの場所は/usr/local/bin/rcloneで、/usr/bin/rcloneではなかった。systemd（Linuxの常駐サービス管理）はそれだけの理由で203/EXECと言って起動に失敗する。which rcloneで確かめる。--allow-otherには/etc/fuse.confへのuser_allow_otherの追記も必要。
• --dir-cache-timeは必ず延ばす。既定の5分だと期限切れごとにフォルダ一覧の問い合わせが全件走る。24時間にした。
• 🔴 Immichのコンテナ設定で写真フォルダのマウント指定に:rslaveを付けないと見えない。docker-compose.ymlの${UPLOAD_LOCATION}:/dataを${UPLOAD_LOCATION}:/data:rslaveにする。コンテナ（ソフトを隔離した箱に入れて動かす仕組み）へのフォルダ受け渡しは既定で「あとから生えたマウントを伝えない」ので、ホスト側で後から作ったマウントはコンテナの中からは空に見える。ここで30分溶かした。なおdocker compose up -d immich_serverはno such serviceになる——設定上のサービス名はハイフンのimmich-server、コンテナ名がアンダースコアのimmich_server。

一番危なかったのはバックアップスクリプトだった

実験で確証を取った、本当の地雷。毎晩のバックアップはrclone sync（送り元に無いものは送り先からも消す片方向ミラー）で動いている。ローカルの写真をシンボリックリンクに置き換えると、rcloneはCan't follow symlink without -L/--copy-linksと言ってそれをスキップし、「送り元に無い」と判断してB2側の実体を削除する。

• 🔴 行き先が存在しない壊れたリンクでも同じ挙動で、しかも終了コードは0（＝成功として記録される）。失敗として検知できない。つまり最も危険な順序は「B2へコピーする前にシンボリックリンクを作ってしまう」ことで、やると、その夜のバックアップがB2にある唯一の実体を無言で消す。
• --copy-linksを付ける解決策は不可。B2に二重保存になって容量が倍になる。

正解は--exclude "cold/**"で追い出し先を同期対象から外し、かつ順序を守ること。

# 1. B2の中で複製（同一バケット内のサーバーサイドコピー＝転送ゼロ・一瞬）
rclone copyto REMOTE/immich/library/<rel> REMOTE/immich-cold/<rel>
# 2. 宛先のサイズを照合
rclone lsl REMOTE/immich-cold/<rel>
# 3. ローカルの実体は「削除」ではなく退避（ロールバックできるように）
mv library/upload/<rel> /root/poc-staging/<rel>
# 4. 相対パスのリンクを張る（library まで ちょうど4階層）
ln -s "../../../../cold/<rel>" library/upload/<rel>
chown -h <user>:<user> library/upload/<rel>
# 5. リンク越しに md5 を照合。違ったら即ロールバック
# 6. 全件の検証が終わってから、はじめて旧パスを削除
rclone deletefile REMOTE/immich/library/<rel>

• 存在確認にrclone lsjsonを使ってはいけない。存在しないファイルを渡すとフォルダとして扱われ、空の一覧と終了コード0を返す。これで一度「B2にある」と誤判断した。rclone lslの出力が空でないことを見る。

10枚で通して、確認したこと

PoC（Proof of Concept = 動くことを示すための小さな実装）として写真10枚・46MBで最後まで通した。ホストからもコンテナの中からも同じmd5で読め、ImmichのAPI経由でオリジナル画像が10/10でHTTP 200かつmd5一致、サムネイルは10/10がローカルから配信（一覧の表示速度は一切変わらない）、エラーログなし。B2からの初回読み込みは0.39秒（636KB）、キャッシュ後は0.017秒。

そして最も確認したかったこと: マウントが切れたらどうなるか。systemctl stopで接続を落として測った。

• オリジナル画像は404、サムネイルは200のまま
• 写真のレコード件数は前・中・後で29,716件のまま不変、該当写真の削除日時もnullのまま
• マウントを戻すと即座に200に復帰

つまりImmichは、ファイルが読めなくなっても勝手にレコードを消したりゴミ箱に落としたりしない。これが成立しなければ全部やめるつもりだった。

安全網が既にあったことも実測した。B2のバケットは「隠してから30日で削除」の設定にしてあり、rclone deletefileは既定でハード削除ではなく論理削除。だから消したファイルは30日間復元できる。15分前に消した2.1MBのHEICをrclone lsf --b2-versionsで版名（<名前>-v<日時>.<拡張子>）を調べて取り出し、md5一致まで確認した（--b2-versionsを付けても元のファイル名を渡すと失敗するので、必ず版名で指定する）。これで「スクリプトのミスで写真が消える」は永久喪失ではなく30日以内なら戻せるミスに格下げされた。残る課題は復元手段ではなく30日以内に気づくことになる。

途中で前提そのものを疑った

10枚が通った時点でB2からの読み出し速度を測り直して、気が変わった。197MBのデータベースダンプが6.58秒＝約30MB/s、17MBの写真が単一ストリームで0.52秒＝約33MB/s（265Mbps）。一方で手元の動画は535本・平均11.6MB、ビットレートは平均7.3Mbps・上位5%で17.9Mbps・最大67.5Mbps。最も重い動画でも4倍近い余裕がある。

それなら「古い写真を追い出す」のではなく、写真の置き場そのものをB2にすればいいのではないか。SSDの天井が消える。コストも、写真をB2に置けば月$10前後、1TBまで増えても月$16で、大きいディスクのプランへ引っ越す月$19より安い。安いほうが天井も無いという綺麗な結論になりかけた。

そこで手を止めて2つ調べた。

自分以外に誰がやっているのか

• 主流は「オリジナルはローカル、クラウドはバックアップ専用」。Immich公式のバックアップ手順もローカル本番を前提に書かれている。クラウドを本番の置き場にしている例は少数派・実験的で、数少ない実践者は「わずかなレイテンシのゆらぎでマウントが壊れる」「ローカルキャッシュがすぐ溢れる」と報告している。
• 「クラウドが唯一のコピー」でやっている人は、調べた範囲で1人も見つからなかった。 定番は3コピー（本番＋ローカルの2本目＋クラウド）。
• 🔴 Immichに未解決の不具合がある: issue #10480 — サムネイル生成が同じファイルを2回読むため、リモートストレージではダウンロード量が実データの8〜10倍に膨らむ。16,000ファイル・110GBで900GBという報告がある。B2の無料ダウンロード枠は保存量の3倍/月なので、サムネイルの全件再生成を一度回すと枠を超えて課金が出る。
• Immich本体のS3対応（オブジェクトストレージへの公式対応）は期待できない。2026年時点で未実装、ロードマップにも無い。**「待つ」は非現実的で、マウント方式が唯一の道（公式サポート外）**という整理になった。
• 追い風もあった。B2のAPI呼び出し課金が2026-05-01に全廃された（代わりに保存料が$6→$6.95/TB/月に値上げ）ので、「マウントが大量の一覧取得を発行して請求が爆発する」という有名な事故モード（過去に約$598の実例がある）は構造的に消えていた。

暗号化のコストを測った

クラウドに本番を置くなら預け先に中身を読まれない形にしたい。界隈の多数派も「上げる前に自分で暗号化する」だった。そして改めて気づいたのだが、自分の既存のバックアップは暗号化されていなかった。毎晩のバックアップを始めた時点で、預け先は写真59,000枚を読める状態だった。

17MBの写真で測った結果は、暗号化あり0.63〜0.95秒 / 平文0.46〜0.53秒。差は0.2〜0.4秒でボトルネックは回線のまま。暗号化は速度面の障害にはならない。

• ⚠️ 最初の計測では「暗号化7.01秒 vs 平文0.46秒＝15倍」と誤った結論を出した。原因は、比較した2つのマウントで--vfs-read-chunk-sizeなどの設定が揃っていなかったこと。ベンチマークは条件を揃える。 危うく「暗号化は無理」と誤った判断を下すところだった。
• 代償は速度ではなく別の2つ。①預け先のファイル名が不可読な文字列になり管理画面から中身を確認できない ②既存の115GBを暗号化し直すには全部アップロードし直す必要があり、「移行作業ゼロ」という最大の利点が消える。

本命の答えは、ボタンひとつだった

ここまで自分は「B2へ追い出す」「オブジェクトストレージを本番にする」「大きいプランへ引っ越す」の3つを丁寧に比較していた。そして契約しているVPSの管理画面を開いて、「ディスクだけ足す」という選択肢を一度も検討していなかったことに気づいた。

Contaboの管理画面には**「Extend SSD Storage」ボタン**がある。公式ヘルプにも、既存のVPSにSSDを足せる・再インストール不要・移行不要と書いてある。200GBを400GBにした。

月額の増分で並べるとこうなる（2026年9月時点）。

差額が月$2〜3しかないなら、その$2で複雑さを全部買い取れる。 一晩かけて作った仕掛けは、この表の2行目のためのものだった。

増設の実作業

公式ヘルプの「activated right away（即座に有効、再起動不要）」は実態と違った。⚠️ 増設は業者側の強制リセットを伴った——正常なシャットダウンの記録がなく、前のログが突然途切れている。増設するときはダウンタイムを見込むこと。 結果的に、予期しない電源断からの自動復旧が完全に機能することが実証できた（コンテナ14個・常駐サービス7件・公開している9サービスすべて復帰、写真のデータ欠損ゼロ）。棚からぼた餅の検証になった。

増えた分は既存ディスクの拡大として現れた（別のディスクとしてではない）。ただしパーティションとファイルシステムは自動では広がらないので、ここだけ手作業。

# 作業前に、必ず手動でバックアップを一度完走させる
/root/backup-scripts/backup-to-b2.sh

growpart --dry-run /dev/sda 1   # まず空振りで確認
growpart /dev/sda 1             # パーティションを広げる
resize2fs /dev/sda1             # ファイルシステムを広げる

• ルートのパーティションテーブルを書き換える操作なので、直前のバックアップは作法として必須。
• 対象が最後のパーティションで、直後に連続した空き領域がある理想的なケースだった。ext4にresize_inodeがあるのでマウントしたまま、無停止でオンライン拡張できた。
• 結果: パーティション199GB→399GB、ファイルシステム193GB→387GB、使用率93%→46%、空き16GB→209GB。RAWを30MB換算で約7,000枚の余裕。
• 料金の実績は月$9.00 → $12.60。100GBあたり月$1.80（＝$18/TB/月）。

仕掛けは完全に撤去した

増設で解決したので、一晩かけて作ったものは全部元に戻した。「使っていないだけ」で残すのが一番たちが悪い——あとでバックアップスクリプトを触ったときに、忘れた除外設定が事故になる。退避していた10枚の実体を元の場所に戻してB2へ再アップロードし、追い出し先のプレフィックスを削除。常駐マウントのサービスを停止・無効化・削除し、マウント用フォルダと/etc/fuse.confの追記も撤去。バックアップスクリプトの--exclude "cold/**"とコンテナ設定の:rslaveは、事前に取った.bakとの差分で元と一致することを確認してから.bakも消した。撤去後の検証は10枚のmd5一致・シンボリックリンク0件・API 10/10・B2側も10/10復元・レコード件数29,716件で不変。

残したのはメモだけ。実際に効いた相対パスとmd5の一覧を/root/notes/に置いてある。将来TB級になってオブジェクトストレージが本当に必要になったとき、この一晩をゼロからやり直さずに済むように。

単価で見ると、いつか判断が逆転する

増設が常に正解ではない。1TBあたりの単価では増設が一番高い（VPSのSSD増設 $18/TB ＞ 同社オブジェクトストレージ $11.96/TB ＞ B2 $6.95/TB）。200GBでは差額が月$2程度にしかならないから複雑さを避けるのが正解だった、という話にすぎない。分岐点は2つ決めてある。追い出したい古い写真が1TBを超えたらB2方式を再検討する（差額が年$132になり、ようやくマウント方式の複雑さを引き受ける価値が出る）。1TB規模ならプランごと乗り換えたほうが安い（現プラン＋800GB増設の月$23.40に対し、1TBのSSDが付いたプランは月$15前後。ただし数分の停止を伴うし、SSDからNVMeへの変更は再インストール必須なので絶対に選ばない）。

残っている課題も書いておく。写真の2本目のコピーは引き続きバックアップ先の1本だけで、以前使っていた自宅のPCに全量が残っているうちは3コピーだが、あれを片付けるときに決め直す必要がある。バックアップの暗号化も未着手——速度は問題にならないと測れたが、115GBを全部アップロードし直すコストが残っている。

この遠回りから取ったもの

一晩かけて作って、10枚で実証して、全部捨てた。月$3.60のボタンを先に押していれば丸ごと要らなかった作業だ。素直に書くと、「どう作るか」を考えるのが面白くて、「買えば済むか」を確かめる手順を飛ばしていた。

構成を変える検討を始めるときは、まず今契約しているサービスの管理画面に、その問題をそのまま解決するボタンが無いかを確認する。 自分は3つの案を丁寧に比較表にしておいて、「ディスクだけ足す」をその表に入れていなかった。選択肢の作り方を間違えると、どれだけ丁寧に比べても正解には当たらない。

捨てた作業から残ったものもある。マウントが切れてもImmichのレコードは壊れないこと、削除が30日間は取り返せること、rclone syncがリンクを見て送り先を消すこと、暗号化が速度の障害にならないこと、サムネイルの全件再生成が課金を踏むこと。これはどの方式を選んでも効く知識で、1TBを超えた日に取り出せる形でメモに残した。遠回りの元は取れていないが、ゼロでもない。

更新履歴 — 2026-10-05: 初版

調べたら、どちらも完全ではなく、どちらも検証されていなかった。GitHub側を廃止して1系統に絞り、代わりに「本当に戻せるか」を確かめる作業を足した。

前提

• 常時起動しているLinuxサーバー1台に、パスワード管理・写真・ファイル置き場・認証を同居させた状態。土台は自分の「サーバー」を持つとはどういうことか
• 道具はrclone(いろいろなクラウドストレージへファイルを同期するコマンド)。送り先はBackblaze B2(安価なオブジェクトストレージ。1GBあたり月$0.006、最初の10GBは無料)
• もう1系統は、作業用ディレクトリ一式を毎日git commitして非公開リポジトリへpushする自作の仕組み

2系統が実際に守っていたもの

同じものを2箇所に置いているつもりだったが、並べたら役割が違っていた。GitHub側はテキスト類(会話ログ・設定・メモ)と添付ファイルで、強みは履歴——「このファイルは3週間前どう書かれていたか」を追える。B2側はデータベースのダンプ・写真ライブラリ・ファイル置き場の実データ・パスワードの保管庫で、強みは容量。つまり二重化ではなく分担で、片方だけでは静かに欠けが出る状態だった。

実際に測ったら、添付ファイルがB2に638件、GitHubに460件、重複ゼロ。時期で真っ二つに割れていた。git cloneだけで戻せば638件が消え、B2だけで戻せば460件が消える。

「2倍安全」ではなく「壊れたら困るものが2つ」

分担になっていた理由は単純で、2つあると、どちらも真剣に見なくなる。

B2側の同期スクリプトのログを読んだら、34回の起動のうち完走は5回だけだった。最後の処理でsudoがパスワードを求めて止まり、set -e(途中で失敗したらそこで中断する設定)で全体が終わっていた。データ本体の各工程は成功していたので実害はなかったが、問題はそこではない。「完走しました」のマーカーが1ヶ月出ていないのに、気づいていなかった。

これが冗長なバックアップ経路の本当のコストだと思う。ディスク代でもなく手間でもなく、どちらも検証されないこと。「もう片方があるから」と思っている限り、片方が壊れても痛みが出ないので、気づく機会そのものが無くなる。

GitHubがこの用途に向いていなかった理由

1. サイズと中身。Gitはテキストには強いが、画像のようなバイナリは版が増えるたびに丸ごと溜まる。.git(履歴の実体)が346MBあり、作業用ディレクトリ751MBの半分近くを占めていた(1年後には847MB)
2. 履歴は消せない。消さないことが価値の仕組みなので、間違って入れたものが残る。実際、秘密情報を含むディレクトリ(APIトークン類やサーバーの秘密鍵)が気づかないうちに毎日pushされ続けていた。「除外設定に入れてある」と自分のメモに書いてあったが、入っていなかった
3. 他人のアカウント方針の上に乗っている。容量制限も規約も将来どう変わるかは自分では決められない
4. そもそも用途が違った。置いていたのは日々の記録で、ソースコードではない。全ての版を永久に取っておく必要がない

一方で**「履歴が追える」価値は本物だったので代わりを用意した。B2のバージョン保持**(上書き・削除された古い版を一定期間取っておく設定)で、自分のバケット(ストレージ上のフォルダのような入れ物)は旧バージョンを30日保持している。実際にデータベースのダンプは26世代遡れた。30日の「取り消し」が成立していればGitの履歴機能の大部分は代替できる。なお公開しているもの(ブログ・ポートフォリオ)はGitHubのままにしている。廃止したのは「バックアップ置き場として使うこと」だけ。

一本化の本体は棚卸しだった

ここが一番再利用できる部分だと思う。片方を止める作業の本体は、「GitHub側にしか無いものが、B2側に全部入っているか」を1件ずつ確認すること。やらずに止めると、欠けたことに気づくのは復元が必要になった日になる。

1. 止める側の中身を、実物から列挙する

設計書ではなく実際のファイル一覧から出す。自分はここで一度間違えた。手元のメモの箇条書きだけを読んで「テキスト類がB2に入っていない」と誤判断したが、スクリプト本文を開いたら既に実装済みだった。メモで判断せず、スクリプト本文とファイル一覧を実見する。

2. 残す側の対象リストと突き合わせる

ここで本物の穴が見つかった。環境変数をまとめたファイル(.env。各種サービスのトークンが入っている)が、GitHubにもB2にも無かった。2系統あったのに、どちらにも無いものが存在した。

3. Gitの履歴そのものを、ファイルとして退避する

履歴は普通のファイル同期では運べない。git bundle(リポジトリ全体を1ファイルに固める機能)を使った。

git bundle create /tmp/history-20260928.bundle --all
git bundle verify /tmp/history-20260928.bundle
rclone copy /tmp/history-20260928.bundle <暗号化remote>:<保存先>/

• 🔴 rootでgitを叩くとdetected dubious ownershipで弾かれる。ディレクトリの所有者ユーザーで実行する
• 出来上がりは831MB。往復まで確認した——取り出してmd5(内容の指紋)が一致し、git clone <bundleファイル> <ディレクトリ>で162コミットが復元でき、履歴の中にしか無いPDFを元のサイズどおり取り出せた
• 🔴 一度きりのスナップショット。以後履歴が伸びても自動では更新されない

4. 止める前に「止める側にしか無いコミット」がゼロだと確認する

git rev-list --count <リモート>/main --not --allが0であること。

5. 浮いた分を別の軸に回す

テキスト類だけを対象にした軽い同期を1日4回動かすようにした(全体の同期は従来どおり夜1回)。これでRPO(障害時に失われる最大の時間幅)が最大24時間から最大6時間に縮んだ。重い写真ライブラリに触らないので約10秒で完走する。加えて30日を超える長期の記録として、テキスト類のみの日付付きtar.gzスナップショットを週1回置いた。実測16MBなので年0.8GB、費用はほぼゼロ。

• 🔴 バックアップを取る道具自体がバックアップ対象外だった。同期スクリプトを置いたディレクトリは、どちらの系統にも入っていなかった。サーバーが全損したらデータは戻るが戻し方を書いた道具が無い
• 🔴 データベースのダンプを取る行に管理者パスワードが直書きされていた。権限600の.envに切り出して読み込む形にし、読めなければexit 1、変数が空なら: "${VAR:?未設定}"で止める(黙って空のパスワードで走らせないため)。渡し方は-p'…'のような引数ではなく環境変数経由にする——引数はpsで他のユーザーから見える。なお平文の秘密はスクリプト本文を直しても消えない。過去の退避ファイルと稼働中のコンテナの環境変数に同じ値が残っており、本当に消すにはパスワードの変更が必要だった

何を金庫に入れるか

バックアップを復元するための鍵が、バックアップの中にしか無いと、永久に開かない。 いわゆるブートストラップ問題(起動するために起動済みの何かが必要になる循環)。自分の場合、B2から取り出すための接続情報(rcloneの設定ファイル)はサーバーの中だけにあった。毎日バックアップは成功していたが、サーバーが丸ごと壊れた瞬間に、無事なデータを開ける人が誰もいなくなる。

再発行できる鍵は金庫に入れない。再発行できない鍵だけ入れる。

• 入れる(再発行不能): 暗号化パスワード(失うとバックアップが永久に読めない石になる)、ストレージ事業者のアカウントの2段階認証バックアップコード、復元用の接続情報
• 入れない(再発行可能): 各種APIトークン、ストレージのアプリケーションキー。上位のアカウントにログインできれば1分で作り直せる
• 置くべきは鍵そのものではなく、上位の認証(アカウントのログイン情報と2段階認証)。それがあれば下位の鍵は何度でも生やせる
• 🔴 何でも放り込むと、金庫自体が肥大した単一障害点になる

置き場所はパスワードマネージャー(1PasswordからVaultwardenに移したもの)にした。スマートフォンのアプリは一度ログインすればオフラインのキャッシュが残るので、サーバーが全損してもそこから取り出せる。ただし金庫自身がサーバー上で動いているので、スマートフォンとサーバーを同時に失うと詰む。対処は「紙でもう1部持つ」しかない。

暗号化と、やらなかったこと

実査したら事業者側の暗号化(SSE)すら無効になっていて、写真は生のJPEGのままディスクに置かれていた。「バケットは非公開だから最低限守られている」という感覚は間違いだった。2種類あることを区別しておく。

• 事業者側の暗号化: 倉庫が金庫に入れてくれるが鍵は倉庫が持つ。退役ディスクの流出には効くが事業者自身には無力で、手間はゼロ。🔴 有効にしても遡らない
• 送る前に自分で暗号化: 自分で鍵をかけた箱を渡す。事業者にもアカウント乗っ取りにも強いが、鍵を失えば永久に読めないし、既存分は全量を再アップロードになる

やったのは前者を有効化したうえで、テキスト類・秘密情報・データベースのダンプだけを後者にすること。rcloneにはcryptという、送信前に暗号化して保存名も不可読にする仕組みがある。初回は6,710オブジェクト・69MBで5分43秒、以後は差分で数十秒だった。

やらなかったこと。

• 写真ライブラリ131GBは自分で暗号化していない。全量の再アップロードになるのと、暗号化する動機(「事業者に読まれたくない」のか「凍結で消えるのが嫌」なのか)を整理できていなかったため。後者ならもう達成済みで、前者ならまだ未達。整理できていないまま重い工事をしない
• 🔴 パスワードの保管庫も、意図的に暗号化していない。中身はそれ自体がゼロ知識暗号化(サービス側も読めない方式)済みで平文ではなく、何より暗号化パスワードの保管場所がその金庫なので、暗号化すると循環依存になる

誰も戻したことのないバックアップは、バックアップではない

1. 生のファイルから実際に復元して突き合わせる。 124ファイルが完全一致した。暗号化remote経由でちゃんと復号できることも同時に確かめられる。

rclone copy <暗号化remote>:<対象パス> /tmp/restore-test/
diff -rq /tmp/restore-test/ /home/<user>/<元のディレクトリ>

2. 週次スナップショットを取り出してtar xzfで展開する。 6,644ファイル・74MBが正常に展開でき、自動処理の定義ファイル16本まで含まれていた。

3. 全ファイルを照合する。 差分19件。中身を見たらすべて同期が走った時刻より後に生成されたファイルで、取りこぼしはゼロだった。

rclone check --one-way <ローカル> <暗号化remote>:<対象パス>

--one-wayはリモートにしかない古い版を差分に数えないので、検証にはこちらを使う。

併せて事業者からの通知メールの読み方を決めた。「マスターキーが生成されました」のような通知は、自分がコンソールを触っていた日なら本人操作、触っていない日なら本物の警戒シグナル。先に線引きしないと、通知を全部無視する習慣がつく。

残った1系統の弱いところ

• 事業者1社への依存は未対策。アカウントの凍結や会社都合には何の備えもない。別会社のストレージへ追記専用でもう1本(月€4前後)が答えだが、見送った
• 削除の伝播と容量の兼ね合いが未整理。送信側の鍵から削除権限を外すとrclone syncが使えずcopyしかできなくなり、ローカルで消したものが残り続けて容量が増える。守りと費用がここで正面衝突する
• 一番大きい穴は、サーバーを乗っ取られた場合。1系統しかないので、送信に使っている鍵を盗られたらバックアップ本体を消される。これは別テーマとして切り出し、鍵の権限削減・削除が伝播しない複製先・サーバーの外で動く見張りの3層で作り直した。そちらはバックアップを「消されても戻せる」形にするに書いた

費用は全バックアップ合計125GBで月約$0.69。一本化で減ったのは費用ではなく、気にかけておく仕組みの数だった。

更新履歴 — 2026-10-05: 初版

先に正直に書くと、Nextcloudで困っていたことは何も無かった。故障の修理ではなく、作りを良くするための工事だ。だから得たものと同じ分量で、失ったものを書く。

前提

• 常時起動しているLinux環境とDocker(ソフトを1つずつ箱に入れて動かす仕組み)が使えること。土台は自分の「サーバー」を持つとはどういうことか
• すでにNextcloudの連絡先・カレンダーを使っている状態(前の記事)
• CalDAV(予定表をやりとりするための標準的な通信規約)・CardDAV(住所録用の同じもの)の名前だけ知っていれば十分

動かした理由は「規模が不釣り合い」の一点

移す前に、Nextcloud側の中身を?exportで実測した。住所録575件、予定表236件、そして空の予定表が2つ(片方はiPhoneのリマインダーが勝手に作ったもの)。

🔴 前の記事に書いた「連絡先633件・予定232件」は誤りだった。移した件数は、移した日に書き留めただけでは当てにならない。

実データの合計は約230KB。テキストファイル1枚に収まる量だ。これに対してNextcloudはPHPで書かれた大きな母屋にデータベースまで抱えている。やっている仕事に対して仕掛けが大きすぎる、というのが唯一の動機だった。

Radicaleは何で、何ではないか

RadicaleはCalDAV/CardDAVだけを話す小さなサーバー。データベースを持たず、予定1件が.icsファイル1枚、連絡先1件が.vcfファイル1枚として、普通のフォルダにただ並んでいるだけ。

やっているのは「フォルダのテキストファイルを、CalDAVという会話の形に翻訳して端末に見せる」中継だけだ。Appleのカレンダーアプリには「このフォルダを見ろ」という設定が存在せず、CalDAVでしか話せないので、この翻訳役が必要になる。あとは各予定にetag(版番号)を付けて差分と衝突を管理するだけ。

何ではないかのほうが重要だと思う。

• 使えるWeb画面が無い。ブラウザで開いても予定を見る画面は出てこない。どうしても画面が欲しければ、CalDAVを外から繋げられるメールサービス(自分はFastmail)を窓口にする手はある。
• 共有リンクも共有のUIも無い。「この予定表をあの人に見せる」をボタンで作れない。
• ファイル置き場ではない。PDFもWordも置けない。契約書の保管はNextcloudに残した。
• 何でも1箇所にある便利さを捨てる。サーバーが1つ増え、端末のアカウントも1つ増える。

代わりに得たのは、速さ、攻撃される面の小ささ(PHPの大きな母屋とデータベースが無くなる)、そしてバックアップがフォルダのコピーで済み、ソフトが壊れても中身はテキストで読めること。この3つのために上の4つを捨てた。判断は人によって逆でいい。

立てて流し込む

構成はdocker composeで1つ、tomsquest/docker-radicale(Radicale 3.8.1)。127.0.0.1にだけ口を開け、外から直接は触れないようにした。認証はhtpasswd(ユーザー名とパスワードの対応表ファイル)だけ。設定の書き方は版で変わるので公式ドキュメントのConfigurationの項を見てほしい。

移行前にNextcloudから控えを取る。

# 住所録
curl -u "<ユーザー名>:<アプリパスワード>" \
  "https://drive.example.com/remote.php/dav/addressbooks/users/<ユーザー名>/contacts?export"
# 予定表
curl -u "<ユーザー名>:<アプリパスワード>" \
  "https://drive.example.com/remote.php/dav/calendars/<ユーザー名>/<予定表名>?export"

入れ物の一覧は同じURLに-X PROPFIND -H "Depth: 1"を付けて取る。流し込みはスクリプトを書いた。設計で効いた点が2つ。

• ファイル名をデータの中のUID(1件ごとの識別子)にする。何度流し直しても同じファイルを上書きするだけで、件数が増えない。
• 繰り返す予定の「例外日」(毎週の予定のうち1回だけ時間をずらした分)は同じUIDを持つので、1ファイルにまとめる。別ファイルにすると予定が二重になる。

結果は575件・236件でNextcloud側と完全一致、失敗0件。

🔴 立てるときに踏んだ穴

• コンテナの中のRadicaleは自分と違うユーザーで動く。自分の場合は数字のユーザーID 2999だった。パスワード表をrootの持ち物にしたままだとPermission deniedで起動しない。そのIDに所有者を変え、読み取りだけ許すのが正解。
• 🔴 「正常な応答コード」を3回続けて読み違えた。トップページのGETは302(転送)が正常で401ではない。予定表フォルダのGETは認証が通っていても403が仕様どおりで、壊れていない。正しい確認はPROPFINDを投げて207が返ることで、件数もこれで数える。

端末の繋ぎ直しに「移行」は無い

ここが一番地味で、一番時間がかかる。サーバー間でデータを移しても、端末のアカウント設定は1台も自動で付いてこない。全部手で繋ぎ直す。 Apple(Mac・iPhone)で詰まる点は1つだけで、はっきりしている。

• 🔴 アカウント種別の「自動(Automatic)」では繋がらない。Appleは.well-known/caldavという決まった入口で「本当の場所はどこ?」と尋ねるが、Radicaleはここでトップページへ転送するだけで場所を教えない。
• 必ず「手動(Manual)」を選ぶ。サーバーアドレスはホスト名(cal.example.com)、駄目なら自分のフォルダまでのフルパス(https://cal.example.com/<ユーザー名>/)を直接入れる。前の記事と同じ系統で、自動検出は当てにしない。

AndroidとThunderbirdは今回つないでいないので手順を書かない。確かなのは、Androidの標準カレンダーにはCalDAVアカウントを足す項目が無く、別途CalDAVクライアントのアプリを入れて端末のカレンダーに同期させる形になること、ThunderbirdはCalDAVに標準対応していることだけだ。

並行期間(両方に同じデータがある状態)の事故防止で効いたこと。

• 古い側の表示名を「OLD(使わない)」に変える。同じ名前が2つ並ぶと、どちらを編集しているか分からなくなる。
• 端末側で新規作成先の既定のカレンダーを新しい方に変える(Macは Calendar > Settings > General、iPhoneは 設定 > アプリ > カレンダー)。ここを変えないと、自分で作った予定だけ古い方に入り続ける。
• 古い側を消すのは、①手元に控えがある②新しい側の件数が一致している、の両方を実測してから。
• 🔴 Nextcloudの予定表は204が返っても消えていない。ごみ箱行き(論理削除)になり、一覧に出続けて中身も読める。完全に消すには削除要求にX-NC-CalDAV-No-Trashbin: 1を付ける。住所録はごみ箱が無く一発で消えるので、挙動が揃っていない。

🔴 Radicaleは重いREPORT問い合わせを同時に受けられない

Radicaleを選ぶ前に知っておくべき制約で、しかもほとんどどこにも書かれていない。自分は後から実測で踏んだ。

REPORTは、カレンダーアプリが「この日からこの日までに何が入っているか教えて」と尋ねるCalDAVの問い合わせだ。Radicaleはこれを受けるとフォルダの中の全ファイルを毎回走査する。繰り返す予定は1ファイルにルールが1行入っているだけなので、「表示を1年先までに絞る」といった対策は効かない。遅さを決めているのは問い合わせの範囲ではなく、フォルダ内のファイル総数だ。

予定表が現在2,626件まで増えた結果、1回の範囲問い合わせに約4.7秒かかる。これ自体は待てる。問題は同時に投げたときだった。

• 事前読み込みを直列3本から並列5本に変えたら、30秒で5本とも通信切れになり、取れた予定は0件になった。
• 直列に戻したら、5期間228件が23.3秒で全部成功した(1本あたり約4.7秒)。

つまりRadicaleは重いREPORTを並べて投げられると、速くなるどころか全部落ちる。「カレンダーアプリを2つ同時に開く」「月を素早く切り替える」「複数の範囲を先読みする自作ツール」のどれでも起こり得る。付き合い方は、どれも「並列化しない」方向になる。

1. 1本ずつ流す列を作る。手前のサーバーに順番待ちの列を1本入れ、範囲問い合わせは必ず直列で流す。
2. 同じ範囲の同時要求は1本に相乗りさせる。2箇所から同じ月を聞かれたら投げるのは1回で、答えを2箇所に配る。画面の操作から来た要求だけ列の先頭に割り込ませると、裏の先読みが詰まっていても人は待たされない。
3. 一度取ったら捨てない。1件保存・削除するたびに全期間のキャッシュを丸ごと捨てて再取得していたのが最悪の形だった。変わった1件だけを手元で差し替えるようにしたら、保存のたびの5秒が消えた。
4. 範囲は広めに取って一度だけ聞く。細かく刻んで何度も聞くほうが遅い。

⭐ 一般則。相手が1本ずつしか捌けない所へ、並べて投げてはいけない。速くする手は並列化ではなく、①同じものを二度聞かない ②要るものだけ聞く、の2つしかない。

時間帯は最初に片付ける

2人で共有するカレンダーを、互いに別の国にいる状態で使っている。時間帯(タイムゾーン)の扱いは後から足す機能ではなく、土台だった。救われたのは、保存の形が最初から正しかったことだ。.icsの中では開始時刻がDTSTART;TZID=Asia/Singapore:...のように**「どの地域の時計で何時か」の形で書かれている**ので、絶対の時刻として一意に決まる。Apple純正のカレンダーはこれを読む側の端末の時間帯で出し直してくれる。標準形式に素直に保存されていれば、時間帯は自動で解決する。 壊れたのは自作の画面のほうで、そこから学んだのは次の3つ。

• 変換は入口と出口の2箇所だけでやる。画面に出す直前と、入力を受け取った直後。途中の計算に混ぜると、どこが変換済みか分からなくなって必ず二重変換が起きる。
• 「いまどの時間帯で見ているか」を常に画面に出す。Google・Apple・Thunderbirdのどれもこうしている。あとから読まれる文章に時刻を書くときも、必ず時間帯を添える(保存された文は読む人の時間帯に書き直せない)。
• 時刻の変換は、画面で確かめる前に机上で全パターン流す。夏時間の切り替わりの前後、30分ずれる地域、日付をまたぐ西側の地域は、実機を1件ずつ見ても踏めない。

バックアップは単純になった

データが素のファイルになったので、バックアップはフォルダを同期するだけになった。既存の日次スクリプトに2行足して終わりで、初回送信は1,035ファイル・379KiBで32秒。ただし消されても戻せる形にしておくことは、データが素のファイルになっても別途必要で、そこは変わらない(バックアップを「消されても戻せる」形にする)。

結果

575件・236件の移行は失敗0で完了し、MacとiPhoneから繋がっている。サーバー上にあるのは1,000枚ほどのテキストファイルで、catで開けば中身が読める。

ファイル置き場のNextcloudは据え置いた。素のファイルを普通のフォルダ構造で保存しているという一点では、調べた移行先候補よりNextcloudのほうが上だったからだ。目的が「データを読める形に保つ」なのに、手段がそこを後退させるなら却下する。

更新履歴 — 2026-10-05: 初版

ドメイン名はexample.com、自分のアドレスはme@example.comと書く。実際の値は自分のものに読み替えてほしい。

前提

• 自分名義のドメインを持ち、DNS(「example.comは実際にどのサーバーを指すか」をインターネット全体に教える住所録のような仕組み)を自分で編集できる状態
• そのドメインでメールを送受信できている状態(前記事の到達点)。なりすまし対策はp=rejectまで締めてある
• 移行対象のメールは約5万通、容量10GB

きっかけは「検索が効かなくなった」こと

不満はひとつだけだった。メールソフトで検索しても出てこない。「豚汁」と打つ。その語を含むメールは確かにあるのに、ヒットしない。他のキーワードなら出る。壊れていたのは検索機能ではなく、索引(どの単語がどのメールに入っているかの目次)が一部だけ欠けている状態だった。

使っていたのはThunderbirdで、ここは索引を手元のPCの中に自分で作る方式だ。数万通あると索引作りが追いつかず壊れやすい。IMAP(メールサーバー上のメールをそのまま読み書きするための通信規約)ではサーバー側の検索と手元の検索が混在して挙動が安定しない。

索引を作り直す手はある(プロファイルフォルダのglobal-messages-db.sqliteを付随ファイルごと消して再起動すると自動で再構築が始まる)。自分はやらなかった。今回直せても、メールが増えれば同じことが起きる仕組みのままだからだ。検索はメールの価値の大半で、10年分の過去メールが「あるのに取り出せない」なら持っている意味が薄い。

メールだけは自前でホスティングしないと決めた

写真・ファイル・パスワード・カレンダーは自分のサーバーに移している(自分の「サーバー」を持つとはどういうことか)。だからメールもできるはずだと考えて、MailcowとMailuを調べた。どちらもDocker(アプリを必要な部品ごと一つの箱に詰めて動かす仕組み)で動くメールサーバーのOSS一式で、Mailcowは送信・受信・迷惑メール判定・ウイルス検査・Webメールをまとめた18コンテナ構成・メモリ最低4GB推奨のオールインワン、Mailuはより疎結合で軽い個人向け。

立ち上げまでは20分程度、初回の構築全体で3〜4時間という見積りに落ち着いた。残りはほぼ全部DNS側の作業(MXレコード、SPF/DKIM/DMARC、逆引き申請、到達テスト)だ。つまり「立てる」のは難しくない。やめた理由は別のところにある。

1. 家の回線からは原理的にできない。 送信には25番ポート(メールサーバー同士がメールを受け渡しする通信の出入口)が必要だが、ほぼすべてのISP(インターネット接続業者)が家庭向け回線でこれを塞いでいる。解除を申請できる業者もあるが、自分の住まいはサービスアパートで回線の契約者は建物の管理会社なので申請の当事者にすらなれない。多くのクラウド事業者も既定で塞いでいるので、借りる前に開放の可否を確認する必要がある。

2. 届くかどうかの9割は自分の手の外にある。 到達率を決めるのはDNSの認証設定(SPF/DKIM/DMARC)と逆引き、そして送信元IPアドレスの素性だ。前者は自分で正しく書ける。問題は後者で、VPS(レンタルサーバー)のアドレス帯は、過去に誰がどんな送信をしたかの履歴を引きずっている。自分が真面目に運用していても、同じ帯の隣人が迷惑メールを送っていれば巻き添えになる。なお新しいIPを「育てる」作業(初日10通→2日目50通→3日目200通と2〜4週間)が要るのは大量送信の場合で、個人の少量送信なら特別な対応は不要。🔴 自分はここを一度誤解していた。IPの素性が影響するのは自分が送るメールだけで、受信には関係ない。

3. 壊れたことが自分には見えない。 これが決定打だった。自前の写真サーバーが止まったら自分がアクセスして気づくし、困るのも自分だけだ。メールサーバーが止まった時に起きるのは「何も起きない」。

• 自分の受信箱は静かなままで、送った相手にもエラーが返らないことがある。相手のサーバーが黙って隔離・破棄するタイプだとバウンスメール(宛先不明で返ってくるお知らせ)すら出ない。自分はこの「エラーも通知もなく静かに届かない」状態を前記事の時点で経験している(原因は新規ドメインの送信履歴不足で、数日待つと解決した)
• 受信側が止まっていれば、その間に届くはずだったワンタイムコードや認証メールは期限切れになって消える。後から再送されない
• Mailuなどが既定で有効にしているグレイリスティング(初めての送信元のメールを一度わざと断り、再送してきたら受け取る対策)は初回を数分遅延させる。認証コードと相性が悪い(無効化可)
• 一番危ないのはドメインの失効だ。自動更新とカードの有効期限が切れていれば、サーバーが完璧でもアドレスごと死ぬ

4. 少数派であることの意味。 セルフホスト界隈の2025年のアンケート(約4,080人回答、約8割がIT系の職業)では、メールを自前ホストしている人は約14%。同じ調査でファイル共有(Nextcloud)は約30%いる。自前ホストに前向きなIT職の集団の中でさえメールは少数派で、「他の人が普通にやっているから自分にもできるだろう」という見積りはここでは通用しない。

「受信と保管は自前、送信だけ信頼のある業者から中継する」折衷案も検討した。到達率は買い取れるが構成が二重になり壊れる箇所が増える。検索の不満を解決するために構成を複雑にするのは逆方向だと判断して、検討を打ち切った。

考え方が変わった点: 「住所の層」と「倉庫の層」を分ける

自前をやめた直後、別の疑問が出た。「有料サービスに預けるなら、Googleに預けていたのと何が違うのか」。整理するとこうなる。自分をロックインしているのはアドレスであって、メールの保管場所ではない。

• @gmail.comを使っている限り、Googleをやめることはアドレスを捨てることとイコールだ。何百のサービスに登録した連絡先が全部死ぬので実質やめられない。これが代わりのきかない1社への依存
• me@example.comなら、ドメインは自分の所有物だ。業者を替える作業は、DNSのMXレコード(このドメイン宛のメールをどのサーバーが受け取るかの指定)を書き換えて、過去メールをIMAPでコピーするだけ。数時間から数日で終わる。アドレスは1文字も変わらないので登録先への連絡も要らない。これはいつでも取り替えられる部品への依存

データ主権の本質は「依存ゼロ」ではなく「依存を取り替え可能にすること」だ、という整理に行き着いた。この形なら、業者にお金を払うことは主権の放棄ではない。副産物として自分の依存の所在も見直せた。大手の個人向けサービスに本当に縛られていたのは写真とストレージの方で、メールではなかった。メールはドメインを持った時点ですでに自由だったのに、「乗り換えは大変だから」と思い込んでいた。

同じ理屈で、エイリアス層(アドレスを発行する層)とメールボックス層(メールを保管する層)も分けられる。エイリアス専業のサービスを手前に噛ませて受信箱は現状維持、という案はかなり有力だった(addy.ioはOSSで自前ホストもでき年$12、2026年9月時点)。却下したのは実質ひとりで運営されているサービスだったからで、メールの経路に置く部品としてはそこだけ飲めなかった。

比較で見た軸

見た軸は①検索の質 ②標準規格(IMAP/JMAP/CalDAV/CardDAV)への対応 ③カスタムドメインとエイリアスの扱い ④出口の広さ ⑤料金。料金はすべて2026年9月時点に自分が調べた額で、改定されるので契約前に各社の料金ページを見てほしい。

• Gmail / Google Workspace: 検索は最強。ただしデータ主権の観点では**「同じ課題を抱えた有料版」**で、変わるのは主権ではなく管理のしやすさだ。なおGoogleは2017年に個人向けGmailの広告目的の本文スキャンを公式に停止しているので、比較軸を「広告の有無」に置くのは的外れだと途中で気づいた
• 大手の個人向けサービスのカスタムドメイン機能(移行前の構成): 料金は圧倒的に安い。ただし1ドメインに作れるアドレス数に上限があり、キャッチオール(そのドメイン宛の存在しないアドレスも全部受け取る設定)に非対応。IMAPは使えるがメールソフトとの相性に癖がある
• Fastmail(豪州): カスタムドメイン最大100個・アドレス数の実質上限なし、IMAPとJMAP(IMAPの後継としてFastmail自身が標準化を主導した軽量な通信規約)に対応。Individual年€60(60GB)、30日間の無料トライアルあり
• その他: Migaduはドメイン数無制限だが最安プランは送信が1日20通まで。Proton MailとTutaは無料プランがIMAP非対応で普通のメールソフトから使えない。国内事業者は日本語サポートが魅力だが安いプランは送信用IPが他の契約者と共有で、②の「隣人の巻き添え」をそのまま引き受ける

🔴 前提がひとつ間違っていた。Fastmailを「大手の傘下」だと記憶していたが、買収は2010年で2013年に従業員が買い戻して以降は独立系だった。親会社リスクの評価をやり直すことになった。業者の資本関係は記憶で判断しないこと。

決めたこと: Fastmail

年€60を払う価値があるとすれば、それはサーバー側の全文検索だった。手元のPCで索引を作らない方式なら冒頭の問題は原理的に起きない。裏付けもあった。FastmailはIMAPサーバーの主要な開発元のひとつで、検索には全文検索エンジン(Xapian)を使い、日本語・中国語・韓国語の分かち書きに対応するためにそのフォークを自前でメンテナンスしている。日本語は英語のように単語が空白で区切られていないので、ここが検索の成否を分ける。

ただし説明文で判断せず実測で決めた。無料トライアルに申し込み、既存のメールを丸ごと流し込んだ。DNSは一切触らないので既存環境への影響はゼロ。インポートはサーバー側で自走するのでPCを閉じてよかった(前回の移行が自作スクリプト頼みで何度も中断したのとは対照的だった)。保存先のリージョンはEUを選んだ(既定は米国)。5万通強のインポート完了後、「豚汁」で検索した。即座に出た。 唯一の未検証点が消えたので課金を決めた。

🔴 トライアルではカスタムドメインが使えない(有料プラン必須)。他に送信120通/日、サーバー側の振り分けルール作成不可といった制限もある。本番切替は「先に年額を払う」ところから始まる。トライアルでできるのは検索の実測までだと割り切るしかない。

得たのは検索だ。失ったものも書いておく。

• うろ覚えに強い検索ではない。速度はGmail級だが、Gmailの「表記ゆれや曖昧な記憶でも何となく当ててくる」ランキングは無く、書いた通りに素直に探す
• 迷惑メールフィルタはGmailと同格ではない。Gmailは世界最大の受信データで学習していて事実上最強だ。漏れを感じたら自分で学習させ、振り分けルールで詰める手間がかかる
• カレンダーと連絡先は自己完結型だった。この2つの本体は自前のサーバーに置いているので「データは自分で持ったまま画面だけ借りる」ができるか調べた。カレンダーは外部のサーバーを登録して双方向に同期できる(ただし予定のコピーが業者側にも載る)。連絡先には同等の機能が無く、一度だけの取り込みしかできない。結果、この2つの移行は見送った。🔴 この件で自分は2回誤った断定をした。「外部カレンダーは読み取り専用しか無い」と書いたが、設定画面には「アカウントを追加」と「購読」という別々の欄があり、読み取り専用なのは後者だけだった。公式ヘルプの検索結果で機能の有無を断定せず、設定画面を開いて確かめること
• 「航空券やレストランの予約確認メールが自動でカレンダーに入る」機能は失われる。大手の独自のメール解析エンジンに依存した機能なので、メールとカレンダーのどちらか片方を移しても再現されない。標準規格ではないものは移行で残らないという分かりやすい例だった。取り戻す道は、予約確認メールを検知して自分のカレンダーに書き込む仕掛けを自作することだけ。まだ作っていない

切替作業: 順番を間違えると送信が全滅する

🔴 業者の案内通りにやると事故る点が2つあった。 ①**「SPFのTXTレコードを新規追加してください」と指示されるが、既存のSPFがある状態でそれをやるとドメインにSPFが2つ存在して仕様違反(PermError)になる**。認証が落ち、p=rejectなので送信が全滅する。正解は追加ではなく1つのレコードへのマージ(include:を並べる)。②案内された値の末尾が?all(該当しない送信元は判定しない)で、自分の既存設定は-all(完全に拒否)だった。言われた通りにすると防御を弱めるので採用しなかった。

もう1つ自分で踏んだ罠。受け取り先のサーバー名はリージョンによって違う。自分はEUを選んだのに、ヘルプ画面に例示されていた画像は米国リージョンのサーバー名だった。画像の値を写すと動かない。設定画面が自分のアカウント向けに表示している値を正とすること。

送信側の設定(SPF/DKIM)と受信側の設定(MX)は独立に変更できる。この性質を使って、受信を止めずに送信だけ先に検証する順序にした。①課金してカスタムドメインを登録(所有確認用のTXT) → ②SPFを1レコードにマージ(古い業者のinclude:は並行稼働の間は残す) → ③DKIM(メールが改ざんされていないことを証明する電子署名)用のCNAMEを追加 → ④差出人設定 → ⑤ここで送信テスト(受信は旧業者のまま無傷なので失敗しても何も壊れない) → ⑥合格を見てからMXを切替。

送信テストはmail-tester.comのような診断サイトに送って点数を見るのが手軽だった(自分は10/10)。加えて厳しいフィルタを持つ組織宛に実際に1通送って届くか確認すること。この手の相手は黙って捨てるので、「エラーが出なかった」は到達の証拠にならない。

• 🔴 切替直後のテストメールは旧メールボックスに着弾した。送信側のDNSキャッシュが古いMXを掴んでいたためで、30分待って再テストしたら新しい受信箱に入った。旧メールボックスを残しておいたのでメールは消えなかった。切替後は最大1時間ほど旧MXに届くと見込んで、旧メールボックスはしばらく生かしておくこと
• 復旧用メールアドレスに、移行するアドレス自身を指定してはいけない。MX切替後は復旧先が移行先の中に入り、そこに入れない事態では何もできない循環依存になる。2要素認証のバックアップコードも同じ受信箱に置かない
• 旧メールボックスを空にする前に、Message-ID(メール1通ごとの一意な識別子)で全件照合した。総通数の一致は「両方向の差が打ち消し合っているだけ」のことがあるので、集合として包含されているかを見る必要がある(前記事で4,293件を失った経験から来ている)。旧側にしか無かったのは25通だけだった
• 移行後、5万通強が業者のサーバーにしか存在しない状態になっていた。写真やファイルは毎晩クラウドへ送っているのにメールだけ体制の外だったので、IMAPで自分のサーバーへ毎晩写し、既存のバックアップ(バックアップを「消されても戻せる」形にする)に載せた。🔑 肝は追記専用にすること。同期を一方通行にしてローカル側で消さない設定にすれば、サービス側で消してもローカルからは消えない

一番時間がかかったのは「登録アドレスの付け替え」

誰も警告してくれないので強調しておく。技術的な切替は1日で終わる。各サービスに登録してあるメールアドレスを1件ずつ付け替える作業は数週間かかる。

実際に付け替えたのはこういうカテゴリだった。具体名は挙げない(自分がどのサービスを使っているかの一覧は、他人にとってはフィッシングの的だ)。ブラウザやOSのアカウント / クラウド・インフラ事業者とドメイン登録事業者 / 通販・デリバリー / 新聞や有料購読 / 健康・計測系のアプリ / 趣味の会員サービス / 銀行・カード・証券。

やり方は3つ組み合わせた。

1. パスワードマネージャーの項目一覧をチェックリストにする。これが「自分がどこに登録しているか」の唯一の全体像だった。記憶では必ず漏れる
2. 受信箱そのものを台帳として使う。アドレスを変えると「メールアドレスが変更されました」という通知が届くので、新しい受信箱に溜まったその通知が、完了したサービスの記録になる
3. 旧アドレスへの転送を残しておく。これが一番効いた。まだ切り替えていないサービスが、メールを送ってくることで自分から名乗り出てくる

🔴 順番の注意: 復旧経路になっているサービス(ドメイン登録事業者、DNS事業者、クラウドストレージ、パスワード管理、そしてメール業者自身)から先に手を付けると、作業中に自分を締め出す事故が起きうる。これらは最後、かつ新しい受信箱が確実に動いていることを確認してからにした。

そして正直に書くと、この作業はまだ終わっていない。移行から1年近く経っても、旧アドレス宛にしか届かないメールが時々ある。転送を切るタイミングはまだ決めていない。

サービスごとに別アドレスを配る案は、半分だけ採った

ドメインを持っているとサービスごとに別のアドレスを配ることができる。漏れたらどこから漏れたか分かるし、1本ずつ止められる。移行先にはこれを自動でやる機能があり、自前のパスワードマネージャー(Vaultwarden)から呼び出してログイン情報を保存する操作と同時に新しいアドレスを発行できる。実際に動かした。

• 🔑 発行するドメインを自分のドメインに切り替えてから使い始めること。既定では業者のドメインで発行される。それで何十本も発行すると、業者をやめた瞬間に全部死ぬという、まさに避けたかったロックインを自分で作り直すことになる。自分のドメインなら、移行先でキャッチオールを有効にすれば受信を継続できる
• ⚠️ 発行したアドレスは最初「保留」状態で、一度も使われないまま24時間で自動削除される。発行だけして後で使うことはできない

ここで立ち止まった。「迷惑メールはサーバー側のフィルタで止まるのだから、これに意味があるのか」。考え直して、よく挙げられる利点のほとんどは自分には効かないと認めた。迷惑メールの削減→フィルタで解決済み。使い回し攻撃の防止→すべてのパスワードが固有なので追加効果はほぼゼロ。流出元の特定→分かっても打てる手は無効化だけで、フィルタで捨てるのと同じ。フィッシングの判別→リンクを踏まない習慣があれば不要。

残る本物の利点は1つだけ。名寄せへの耐性だ。 単一のアドレスはデータブローカーにとって結合キーになり、A社の流出とB社の流出が機械的に突き合わされてプロファイルが組まれる。迷惑メールフィルタはこれに一切効かない。受信箱は静かなまま、外側で自分の像が育っていく。 困っていないが他人が自分のデータでできることを減らす、という動機で、自前ホスティング全般と同じ理由だ。日々の受信箱の快適さとは無関係なので、使っていて価値を体感できないのは当然だった。

そこで既存サービスの一括移行はやらず、新規登録の時だけ使うことにした。新規はボタン1回でコストがほぼゼロだが、既存の移行は実作業に加えて24時間ルール・ログインIDを変更できないサービス・連絡経路が切れるといった失敗モードを抱えるので、損益が非対称になる。

• 🔴 そもそも移してはいけない層がある。メール業者自身、OSやプラットフォームのアカウント、ドメイン登録事業者、DNS事業者、パスワード管理、認証基盤、クラウドストレージ、銀行・証券・カード。復旧経路にとって「1本ずつ切れる」は「1本ずつ壊れる」に反転する
• 📌 増やしすぎると出口が狭くなる。業者をやめる時、移行先でキャッチオールが必須になる。数十本なら問題ないが、数百本に膨らませると取り替え可能性を自分で削ることになる。なおキャッチオール自体は無効(拒否)にした。有効にするとinfo@やadmin@といった辞書総当たりの迷惑メールを全部受けてしまい、存在しないアドレスなので個別に止める手段がない
• ⭐ 一番しっくり来た用途は公共WiFiの登録画面だった。アドレスをマーケティングリストに流す前提のところが多く、24時間の自動削除がここでは利点になる。⚠️ ただし「メールの確認リンクを踏んでください」型だと、まだ繋がっていないのでそのメールが読めない。繋ぐ前にモバイル回線で発行しておくしかない

今の構成と、やらなかったこと

正本=メールサービス側 / バックアップ=自分のサーバー上の追記専用コピー→クラウド(暗号化) / クライアント=公式アプリのみ。デスクトップのメールソフトは撤去した。移行先の安定性を実測で確認できて見張り役が不要になり、ローカルコピーはPC1台の中にしかなくバックアップの本数に数えられなかったからだ。なお公式アプリもオフライン用にメールをキャッシュするが、これはバックアップに数えない。サーバーに無いメールを溜め込める古いメールソフトと違い、単なるサーバーの写しだ。

やらなかったこと。メールの自前ホスティング — この記事の半分を使って却下した。副産物として、サーバーを選ぶ時の「25番ポートが開放できること」「メール専用のIPを分けられること」という制約が消え、他の用途だけで選べるようになった。既存サービスのアドレスをサービス別エイリアスに移すこと — 上記の通り撤回した。カレンダーと連絡先の移行 — 「データは自分で持ったまま、一番手前の画面だけ借りる」組み合わせが存在しなかったので見送った。不満が出たら画面だけ替えればいい(倉庫が自分のものなら、アプリは捨てられる=取り返しがつく)。

残っている単一障害点はドメインの更新忘れだ。メールボックスの業者は取り替えられるが、ドメインを失うとアドレスごと失う。自動更新と登録してあるカードの有効期限は、年に一度は目で見ておくことにした。

更新履歴 — 2026-10-05: 初版

利用者は自分と、自分以外にもう1人、実際に毎日使っている利用者の2人だけ。この1人が実機で不具合を見つけて報告してくるので、6週間のあいだ「作る」より「直す」のほうがはるかに多かった。そこで身についた習慣を5つだけ書く。どれも、外した回数の記録があるものに限った。

前提

スマートフォンのホーム画面に置いて全画面で使う形式(PWA)のアプリで、iPhoneとAndroidの両方から使っている。置き場所は自分の借りているサーバーで、土台は自分の「サーバー」を持つとはどういうことかに書いた構成とほぼ同じ。自分がやるのは、不具合の報告を受け取り、エージェントに状況を伝え、出てきた直しを実機で確かめること。コードは読めるが書けない。

1. 推測で直すのをやめ、端末が実際に報告していることを出す「捨て用のページ」を作る

一番高くついたのは、日本語入力の変換候補の帯が消える不具合だった。ひらがなを打ってもキーボードの上に出るはずの候補バーが出ない、または打っている途中で消える。同じ症状を、数日かけて9回踏んだ。原因は毎回違っていた。 正確に言うと、同じ作りで動かしている自作アプリが2つあり、9回はその両方にまたがっている。同じ型の作りには同じ型の地雷が埋まる、ということでもある。

1. 画面のスクロール位置を0に引き戻す1行。変換を始めるとiOSがページを少しスクロールさせる。それを律儀に戻していたので、組み立て中のiOSが変換を打ち切っていた。
2. 入力のたびに入力欄の高さを測り直す処理。iOSのIME(日本語入力の仕組み)は、組み立て中に入力欄の寸法を書き換えられると組み立てを打ち切る。
3. 自分宛ての通知バナー。相手の発言が届いたときに通知を出していたが、自分がアプリを開いて返信を打っている最中にも出ていた。
4. 自分が保険として足した自動リロード。「新しい版を配ったら画面を読み込み直す」仕掛けが、打っている最中でも容赦なく走っていた。つまり直しを配るたびに、自分で同じ症状を起こしていた。
5. 「いま変換中か」の旗を時間切れで降ろす保険。「人が3秒も1文字も触らずに組み立て続けることはない」という前提だったが、人は言い回しを考えて平気で3秒以上止まる。止まった瞬間に旗が降り、高さが書き換えられて候補が消えた。1〜4回目を防ぐために足した保険が、1〜4回目と同じ事故を起こしていた。
6. 入力欄に付けていた「自動スペル修正を切る」属性。iOSではこれがキーボード上の予測候補バーそのものを消す。日本語の変換候補はそのバーに出るので、英語の下線を消すついでに道連れにしていた。

🔴 9回のうち7回は「ありそうな犯人」を潰していただけだった。 毎回それらしい原因が見つかり、毎回直って、毎回また同じ報告が来た。

決着したのは、直すのをやめて実況を出す仕掛けを入れてからだった。画面の左上に最後の十数行を出して、「組み立てが始まった」「入力が来た」「高さ調整を見送った」「表示領域の高さが変わった」を1行ずつ流す。これのスクショを1枚もらっただけで、自分のコードは変換中に画面を一切書き換えていないことが確定し、残っていた仮説が全部消えた。

さらに捨て用のページを別に作った。入力欄が1つあるだけで、JavaScriptを一切かけず、属性の組み合わせを6通り切り替えられるページ。実機で6通り全部試して全部で候補が出た。これで「入力欄の属性」「固定の箱」「OSの予測変換の設定」「ホーム画面アプリであること自体」が全部シロだと分かり、残りは本番のコードだけに絞れた。

この手で学んだこと。

• 調べる口は、症状が出る環境の中から開けられるようにする。 最初の実況はURLの末尾に印を付けて開く方式だったが、症状が出るのはホーム画面アプリで、そこにURL欄はない。報告をもらって初めて「一生使えない仕掛け」だと気づき、設定画面に切り替えを置き直した。
• 🔴 捨て用ページで測った数字を、本番の数字より優先してはいけない。 入力欄の下に空ける余白をその実測値に合わせたら、本番では逆に60pxの空白が出た。同じ端末・同じホーム画面アプリでも、ページによって数字が違った。捨て用のページが有効なのは「条件の切り分け」までで、寸法の絶対値は本番でしか測れない。
• 断続的な不具合は「再現を待つ」のではなく「再現したときに証拠が残っている」状態を先に作る。 流れる実況だけでは、引き金が症状の数分前にあると永久に捕まらない。重要な行だけを別枠に最大6件、端末側に保存して読み込み直しても消えないようにした。

2. 同じ報告が3回続いたら、最初の2回は症状に当てていたということ

同じ症状は、同じ不具合の証拠ではない。これを9回ぶん支払って覚えた。前回の直しに似せて今回も直す、というのが一番高くつく癖だった。他にも同じ型で踏んでいる。

• 本文が文の途中から始まる: 同じ訴えを4回受けた。4回とも同じ箇所を直したが、3回は「中身の継ぎ方」を見ていて、4回目にようやく「その処理が誰のために走っているのか」が原因だと分かった。
• 吹き出しの「しっぽ」の形: 市販アプリに寄せるのに3回作り直した。1回目は目分量、2回目は寸法を比で揃える、3回目でようやく「寸法ではなく形そのものが違う」と分かった。寸法の話をしているあいだは、何度直しても近づかない。

同じ報告が3回来たら、3回目の直しを書く前に「1回目と2回目はなぜ外れたのか」を先に書く。 書けないなら、まだ症状に当てている。

3. 「直したものが端末に届いていない」は「直っていない」と見分けがつかない

原因の種類が違うのに、画面上はまったく同じに見える。3往復むだにして気づいた。

🔴 iOSのホーム画面アプリは、閉じて開き直すだけではページを読み込み直さない。 何時間も前の状態を握ったままなので、サーバー側のファイルを直し、サーバーが正しく新しいものを配っていても、相手の画面は一切変わらない。「なおらないよ?」が3回続いたときに配信物を直接取って確かめたら、配っているものは正しかった。

やったこと。サーバーに「いまの版」を返すだけの口を足し、画面側は起動時にそれを控えて、他のアプリから戻ってきたときに照合し、違っていたら読み込み直す。そして画面に版の文字列を出し、次に報告をもらったら何よりも先にその文字列を読む。あわせて端末側から「起動した(版はこれ、ホーム画面アプリかタブか、通知の許可はどうか)」を1行だけサーバーへ送るようにした(会話の本文は送らない)。

見分け方として一番効いたのは、もらったスクショが前回とピクセル単位で同じかどうか。 同じならまず「届いていない」を疑う。コードを3通り書き直す前にこれを確かめる。

さらに厄介な形も踏んだ。画面は最新なのに、裏で動いている配信役(Service Worker)だけが取り残されて6版も古いままだったことがある。古い配信役は新しい形の通知を受け取れないので、通知が消えないという別の症状に化けていた。「効いている」だけでは足りず、「何版が効いているか」を答えさせないと気づけない。

4. 日付つきで、試したことと外れた理由を残す

6週間経つと、これが同じ輪を歩き直さない唯一の歯止めになる。やったこと・やめたこと・なぜ外れたかを、日付つきで1ファイルに積み上げている。具体的に効いた場面を2つ。

タブの切り替えアニメーションを機能ごと撤去した。 画面下にタブを足して、切り替えに横滑りの動きを付けた。その直後に「画面上のなんのボタンも反応しなくなった」と報告が来た。動かない原因を追うのではなく、動いていた時点のファイルに戻し、安全な2件だけを入れ直して、アニメーションは仕掛けごと削除した。直すより消すほうが安い機能があるという判断を記録に残しておくと、後でまた同じ思いつきが出たときに止められる。

下タブの導入をまるごと巻き戻した。 別の日、下タブを入れた版でアプリが完全に操作不能になった。部分的な修正を試さず、導入前のファイルへ丸ごと戻した。失ったのは下タブ・独立した設定画面・カレンダーの月週日の切り替え・起動時の表示先の4つで、全部もう一度作り直した。巻き戻しで何を失ったかを書いておくと、作り直しの順番がそのまま手順表になる。次は「タブバーだけ入れて実機で確認」「設定画面」「カレンダー」の3段に分け、1段ごとに実機で確かめた。

記録が無ければ成立しない言い方がある。「それはもう試した。こういう理由で外れた」。

• 「変換中は触らない」というガードを、呼び出し側だけに書いて2回再発させた。記録を読み返して「2回とも呼び出し側だけ直している」と分かり、以後は触る処理そのものに1つ残らず書くことにした。呼び口は後から増えるので、入口で止めても漏れる。
• 入力欄の下に空ける余白を、2日のあいだに4回も定数で反転させていた。記録を並べたら「実機のスクショ2枚が食い違っているのは、どちらかが嘘なのではなく、場合分けの軸がまだ見つかっていない」と気づけた。
• 🔴 過去の自分の結論が間違っていることがある。 「この寸法は常に引かれる」と書いた結論が、別の環境では成立していなかった。日付を必ず付けているのは、どの結論が新しいかを後から判定するため。

5. エージェントは画面を見られない。詰まるのは説明の側

エージェントはコードを読めるが、自分のスマートフォンに何が映っているかは見えない。だから自分の説明が唯一の入力になる。そしてこちらは非エンジニアなので、言葉で正確に言えない。この落差が、6週間でいちばん多く時間を食った。

スクショを添えて初めて診断できた不具合がいくつもある。

• タイルが潰れる件: 「縞に見える」という言葉のままでは2手外れたが、スクショで「正方形が帯になっている」と分かって真因が決まった。
• 送信済みのチェックマークが消えた件: 吹き出しに「しっぽ」を足したら、重ねて貼った小片がチェックマークをまるごと塗り潰していた。時刻も右端が覆われていたが、色が同じなので画面を見ても気づけなかった。原因は「位置を指定した要素は、同じ親の文字より上に描かれる」というだけの話。スクショを拡大して初めて確定した。
• カレンダーの縦線と幅が合わない件: 3回かかった。1回目と2回目はCSSを読んで「理屈の上では揃うはず」と判断し、揃わない前提そのものを疑わなかった。3回目にスクショの画素を1行ぶん走査し、帯の幅が列のちょうど76%だと測って、その数字で該当箇所に一発で当たった。

そしてもう1つ。市販アプリの見た目に寄せるなら、スクショは「参考にする」のではなく、画像編集ソフトで「測る」。

• 吹き出しの色をスクショの画素から直接読んだら、公称されている色と実際の画素が微妙に違っていた。目で選んだ色では一致しない。
• 角の丸みは目分量で3回外した。「全然だめだ」と言われてようやくスクショを測り、角丸 ÷ 文字の大きさ = 1.63、角丸 ÷ 2行の吹き出しの高さ = 0.436という比を出した。自分のアプリの文字サイズと行間からその比を満たす値を計算したら一発で合った。
• 青も3回外した。濃すぎる・薄すぎるを行き来したあとスクショから採った値に替えたが、その副作用で未読と既読のチェックマークが見分けられなくなった(地を薄くしたので白78%と白の差が消えた)。色で状態を表しているなら、地の色を変えたら差も作り直す必要がある。
• しっぽの形は、最終的にスクショの輪郭を1画素ずつ読み取ってそのまま図形として写し取った。向こうの形は角丸と小片の組み合わせではなく、右辺が内へ寄りながら下へ垂れる一続きの曲線だった。

エージェントに渡す材料の優先順位はこうなった。実機のスクショ > 実機の実況ログ > 実データ(保存されている記録そのもの) > 自分の言葉。 自分の言葉が一番弱い。

これで解決しないこと

• 答えが正しいかどうかを自分で判定できる必要は、まったく減らない。 エージェントは「直りました」と報告してくる。6週間で何十回も、机上では直っていて実機では直っていなかった。最後に実機で確かめるのも「これは直った/これはまだだ」を判断するのも自分。受け取る側に判定能力がないと、同じ輪をもっと速く回るだけになる。
• 分かっていないものが溜まっていく。 自分のアプリには、自分が原理を説明できない処理が入っている。説明を求めれば返ってくるが、6週間ぶんを全部覚えているわけではない。壊れたときに「ここは触るな」と言えない箇所がある、という事実は消えていない。
• 説明できない症状は、直せない症状のままになる。 「なんとなく動きが変」は、スクショも実況も実データも出せないので結局手が付かない。9回目の変換候補の件も、まだ真因には届いていない。残っているのは「本番のコードのどこか」という範囲だけで、名前は付いていない。

更新履歴 — 2026-10-05: 初版