子どもが2人になって、写真と動画が爆発的に増えた。スマホ2台ぶん、ことあるごとに撮るので、置き場所がずっと曖昧なままだった。

クラウドの無料枠はとっくに溢れ、有料プランは「払い続ける限り人質」感がある。何より、子どもの記録という一生もののデータを、いつ仕様が変わるかわからない他人のサービスに預けっぱなしにしているのが落ち着かなかった。

そこで Immich（イミッチ）を自宅サーバーに立てることにした。Google Photosにそっくりな見た目とスマホ自動バックアップを持つ、セルフホスト型の写真・動画管理ソフトだ。

この記事は2軸で書く。(1) どう構築したか（技術) と、(2) その作業をまるごとAI（Claude）に任せたらどうだったか だ。

---

なぜImmichなのか

• 自分のディスクにオリジナルが残る — サービス終了や値上げと無縁
• スマホアプリで自動バックアップ — Google Photosと同じ運用感のまま移行できる
• 顔認識・アルバム・地図表示 — 機械学習による検索が、クラウド製品と遜色ない
• 家族写真という「外に出したくないデータ」を、家庭内ネットワークで完結できる

我が家はWindowsのデスクトップPCにDドライブの空きがたっぷりあったので、ここを写真の母艦にすることにした。

(1) 構築：やったことの全体像

Immichは公式がDocker Composeでの導入を推している。つまり「設定ファイルを2つ置いてコマンドを1回叩く」だけで、本体・データベース・機械学習エンジンがまとめて立ち上がる。手順の骨子はこうだ。

1. Docker Desktop（Windows版）を入れる
2. 公式の docker-compose.yml と .env（環境設定ファイル）をダウンロードする
3. .env を自分の環境に合わせて書き換える
4. docker compose up -d で起動する
5. ブラウザで管理画面を開き、最初の管理者アカウントを作る
6. スマホにImmichアプリを入れ、自宅サーバーのアドレスを登録して自動バックアップをオンにする

実際に使った .env の中身は、こんな勘どころだけ押さえればいい。

# 写真・動画の保存先。ここに家族の写真が溜まっていく
UPLOAD_LOCATION=D:/immich/photos

# タイムゾーン（これを入れないと撮影日時がずれる）
TZ=Asia/Tokyo

# 追従するバージョン系列
IMMICH_VERSION=v2

# データベースのパスワード（自動生成された長い文字列をそのまま使う）
DB_PASSWORD=（自動生成された値）

ポイントは UPLOAD_LOCATION を Dドライブの実フォルダ に向けたこと。これで、Immich経由でもエクスプローラーからでも、同じ実体ファイルに触れる。万一Immichをやめても写真はただのファイルとしてそこに残る——この「逃げ道がある」安心感が大事だった。

データベース（PostgreSQL）はDockerの名前付きボリュームに任せ、写真の実体だけをDドライブに置く構成にした。バックアップで本当に守りたいのは写真そのものなので、対象がはっきりする。

起動後は同じ宅内Wi-Fiにつないだスマホから http://（PCのローカルIP）:2283 でアクセスできて、アプリのバックアップをオンにした瞬間から、撮った写真が勝手にDドライブへ吸い込まれていくようになった。気分はもう自宅版Google Photosだ。

(2) この構築、ぜんぶAIに任せた

正直に書くと、上の作業をひとつずつ自分で調べてやったわけではない。Claudeに「家族写真をDドライブに集約したい。ImmichをこのPCに立てて」と頼んで、ほぼ丸投げした。

具体的にClaudeがやってくれたのは、

• Immichという選択肢の提示と、我が家の環境（Windows＋Dドライブ余裕あり）での妥当性の説明
• 公式構成に沿った docker-compose.yml と .env の用意
• UPLOAD_LOCATION をDドライブに向ける、TZ を日本にする、といった我が家用の書き換え
• 起動コマンドの実行と、立ち上がらないときの原因切り分け
• スマホアプリからの接続方法（ローカルIPとポート）の案内

私がやったのは「立てて」と言ったことと、ブラウザで最初のアカウントを作ったこと、スマホでバックアップをオンにしたことくらい。Dockerのことも、Composeのことも、ほとんど理解しないまま動くものができてしまった。

任せてみてどうだったか

よかった点

• 自分で2〜3時間は溶かしていたはずの「調べる→詰まる→検索する」が消えた
• セルフホストにありがちな初期の罠（タイムゾーン、保存先の指定、ポート）を最初から踏まずに済んだ
• 「なぜこの設定なのか」をその場で日本語で説明してもらえるので、ブラックボックスにならない

気をつけた点

• .env にデータベースのパスワードが平文で入るので、この記事でも実際の値は伏せている。自動生成された値をそのまま使い、外部には絶対出さない
• 自宅ネットの外から見られるようにする（公開する）のはセキュリティの難易度が一段上がるので、今回は宅内からのアクセスだけに留めた
• 「動いた」で満足せず、写真の実体がDドライブにちゃんと増えているかは自分の目で確認した

導入メモ： セルフホストは「やってみたいけど最初のハードルが高い」の典型。そのハードル——調査・設定ファイル・トラブル切り分け——こそ、いまのAIがいちばん肩代わりしてくれる部分だった。逆に、パスワード管理や「どこまで外部に公開するか」の判断は人間が握っておくべきところ。面倒は任せ、責任は持つの切り分けがちょうどいい。

まとめ

家族写真の置き場問題は、Immichを自宅に立てることで「自分のディスクにオリジナルがある」状態に着地した。月額も人質感もなく、運用感はGoogle Photosのまま。

そして今回いちばんの発見は、こういう”ちょっと敷居の高い自宅サーバー構築”が、AIに任せれば週末の片手間で終わる時代になっていたことだ。せどりのツールも、子どもの記録の仕組みも、この健康データ分析環境も、同じやり方で積み上げてきた。「やりたいけど面倒で後回し」が一個ずつ片付いていく感覚は、地味だけれど確かに生活を良くしている。

関連記事

• 週1しかジムに行けない社会人のリコンプ戦略——AIと健康データを見ながらメニューを作り直した 2026年7月17日 — 3年分の健康データを土台にAIと会話しながら、「もう痩せなくていい、次は筋肉」という結論と週1前提のジムメニューにたどり着いた。汎用の筋トレ論ではなく自分の数字で答えが返ってくる体験と、できあがったルーティンカードを載せる。
• 大学費の「谷」はFIREの後に来る——教育費×FIREを自作シミュレーションで検証した 2026年7月2日 — 子ども2人の大学在学とFIRE後の取り崩しが正面衝突する時期を、積立と取り崩しを1本につないだ自作シミュレーションで検証。名目と実質を混ぜると結論が反転した話と、目標1.5億円の「安全マージン」が実は飾りではなかったという結論。
• 自動で動く道具が、ちゃんと動いているかを見張る道具——連載のしめくくり 2026年7月1日 — 十数個の自動ジョブが静かに止まっていても気づけない。それを防ぐために、全部の道具の死活を毎朝チェックしてSlackに報告する監視役を立てた。いちばん地味で、家庭OSにいちばん効いている土台の話。家庭OS連載の最終回。