PRO+ 公開サンプル · ログイン不要で全文をご覧いただけます。

PRO

インストール前の試食 · ログイン不要

immich-app/immich 写真・セルフホスティング

家族の写真を、自分のサーバーへ

スマホのアルバムを送り、写真を探し、必要なアルバムだけ共有。原本とDBの別のバックアップまで、手描き動画で確認します。

63秒の動画説明図3枚選び方
まず動画で理解する ↓すぐに始める ↓

01 · 動画でひと目に

家族の写真を、自分のサーバーへ

Google Flowの韓国語ナレーション・字幕とBGMを使った手描き解説です。公開コードと公式資料を基にした説明図で、インストールや実行の録画ではありません。

02 · 実際のアプリ画面

公式文書の実際の画面で見てみる

Immichの公式文書に掲載されている画面です。Webのライブラリから管理者の登録、スマホのバックアップ、アルバムの共有、DBの復元まで、使う順に選んで見られます。文書の画面は古い版で撮られたもので、v3.3.3の画面とは異なる場合があります。

ImmichのWeb写真タイムラインとスマホアプリの2画面（公式文書の画像、v1.112.1の表記）
Webのライブラリとスマホアプリ（代表画像）リポジトリの文書画像フォルダー（docs/static/img）にある代表画像です。この画像を説明する文書本文は見つからなかったため、READMEの紹介だけを載せます: Immichは「高性能なセルフホストの写真・動画管理ソリューション」で、機能表には写真・動画のアップロードと閲覧がスマホアプリとWebの両方でできると書かれています。左下のv1.112.1の表記のとおり古い版の画面なので、v3.3.3とは異なる場合があります。

画面: immich-app/immichの公式文書の画像（v3.3.3のタグのコミットd2dac658）、Immich and contributors、AGPL-3.0。Webのライブラリ・DBの復元の2枚はギット飯が幅2000pxに縮小してWebPで保存し直し、残りの4枚は元のファイルのままです。版の表記（v1.112.1、v2.4.1）が見える画面のように古い版の画面のため、v3.3.3とは異なる場合があります。実在の人物の顔が写った文書の画像は使っていません。ギット飯が撮影した画面ではなく、Immichがギット飯を保証するものでもありません。

03 · すぐに始める

まずサーバーを起動し、スマホアプリをつなぐ

Immichは、まずサーバーを起動し、スマホアプリをそのサーバーにつなぐ順番です。公式文書が推奨する方法はDocker Composeで、インストール前にデモサーバーで見て回ることもできます。コマンド横のコピーを押して、サーバーの端末に貼り付けます。

元リポジトリv3.3.3（2026-10-14 UTCリリース）の文書に基づく · 2026-10-19確認 · ギット飯では実際にインストール・実行していません。公式文書のダウンロードのURLは固定の版ではなく最新（latest）のリリースを指し、.envのIMMICH_VERSION=v3もv3の中の新しい版に追従します。そのため、今日取得するとv3.3.3より新しい版が入る場合があります。ギット飯の補足: この記事と同じ版で試すなら、下の「v3.3.3に固定して取得」を使ってください。要件はRAM最小6GB（推奨8GB）、CPU最小2コア（推奨4コア）、amd64・arm64です。v3からamd64の機械学習コンテナはx86-64-v2以上に対応したCPUが必要で、RAMが4GBしかなければ機械学習の機能を切って動かせると書かれています。コマンドはComposeプラグインのdocker composeである必要があり、古いdocker-composeには対応していません。サムネイルと変換した動画のため、ライブラリの容量は平均10〜20%増えます。

どうやって始める？

Docker Compose（公式推奨）

Linuxサーバー（推奨）にDockerとdocker composeプラグインがあるとき

  • docker-compose.yml
  • example.env

手順1 · フォルダーを作って移動

mkdir ./immich-app cd ./immich-app

手順1 · 2つのファイルを取得（文書どおり、最新リリース）

wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env

手順3 · .envを直してからコンテナを起動

docker compose up -d

公式文書の「Docker Compose [Recommended]」の手順です。手順1でフォルダーを作り、docker-compose.ymlと.envの2つのファイルを取得します（ブラウザーで取得したらexample.envの名前を.envに変えます）。手順2で.envを直し（下の「最初にやること」の1番）、手順3でコンテナをバックグラウンドで起動します。

原文のコマンドはlatestのURLなので取得した日の最新リリースのファイルが届き、.envのIMMICH_VERSION=v3はv3の中の新しい版に追従します。「unknown shorthand flag: 'd' in -d」のようなエラーが出たら、ディストリビューションの古いDockerパッケージが原因の場合があるとして、原文はDockerの公式インストール手順（古い版の削除を含む）に従うよう案内しています。

v3.3.3に固定して取得（ギット飯の補足）

この記事と同じ版で試したいとき

  • docker-compose.yml
  • example.env

v3.3.3のリリースのファイルを取得（ギット飯の調整版）

mkdir ./immich-app cd ./immich-app wget -O docker-compose.yml https://github.com/immich-app/immich/releases/download/v3.3.3/docker-compose.yml wget -O .env https://github.com/immich-app/immich/releases/download/v3.3.3/example.env

.envのIMMICH_VERSIONの行をこう変える

IMMICH_VERSION=v3.3.3

コンテナを起動（.envを直してから）

docker compose up -d

ギット飯が、文書のコマンドのlatestのURLだけをv3.3.3のリリースのURLに変えた調整版です。ギット飯が確認したv3.3.3のリリースの2つのファイルは、タグのコミットのdocker/docker-compose.yml・docker/example.envとバイト単位で同じで、ghcr.ioにv3.3.3のイメージのタグもあります。example.envのコメントにも、IMMICH_VERSIONを特定の版に固定できると書かれています。

固定すると新しい版は自動では入りません。更新するときはリリースノートを読み、IMMICH_VERSIONを変えてから更新のコマンドを実行するよう原文（upgrading）が案内しています。下の「更新するとき」を見てください。

スマホアプリ（サーバーを起動したあと）

サーバーが起動していて、スマホからそのサーバーのアドレスに届くとき

http://<machine-ip-address>:2283

アプリはApp Store、Google Play、GitHubのリリース（APK）、Obtainium、FUTO F-Droidから入手します。サーバーのアドレスでログインし、右上の雲のアイコンからバックアップするアルバムを選んでEnable Backupを押すと、アプリを開いたときや戻ったとき、そしてバックグラウンドで定期的に新しい写真・動画をアップロードします。

既定ではWi-Fiのときだけアップロードします。iOSではAppのバックグラウンド更新をオンにする必要があり、バックグラウンドのアップロードの時刻はアプリではなくiOSが決めます（アプリをよく開くほど頻繁に動きます）。Androidでは、一部の機種のバッテリー最適化がバックグラウンドの処理を止めることがあります。

デモサーバーで先に見て回る

インストールする前にWebとアプリの画面を先に見たいとき

アドレス（Web · アプリのServer Endpoint URL）

https://demo.immich.app

メールアドレス

demo@immich.app

パスワード

demo

READMEにある公開デモです。Webはこのアドレスで開き、スマホアプリはServer Endpoint URLに同じアドレスを入れてログインします。

ギット飯の補足: 多くの人が一緒に使うデモのアカウントなので、自分の写真や個人情報はアップロードしないでください。

v3.3.3リリースページ ↗

最初にやること（順番に）

  1. .envを直す（コンテナの起動前）

    取得した.envで3つを直します。UPLOAD_LOCATIONは空き容量が十分なサーバーの新しいフォルダーに（既定値は./library）、DB_PASSWORDは既定値postgresの代わりにA-Za-z0-9だけを使ったランダムな値に、TZ=の行は先頭の#を消してタイムゾーンを決めます。ギット飯の補足: 日本ならTZ=Asia/Tokyoです。この記事と同じ版に合わせるなら、IMMICH_VERSION=v3.3.3に変えます。

  2. ブラウザーでアクセスして管理者を登録

    <machine-ip-address>をサーバーのIPに置き換えて開き、Getting Startedを押します。最初に登録したユーザーが管理者になり、家族のアカウントは管理者が追加します。ギット飯の補足: この画面が開けば、サーバーが応答しているということです。

    http://<machine-ip-address>:2283

  3. 開かないときはコンテナを確認

    原文のDockerヘルプにあるコマンドです。動いているコンテナの一覧と、サーバーのコンテナ（immich_server）のログを見ます。ログを見続けるなら--followを付けます。

    docker ps docker logs immich_server

  4. スマホアプリをつなぐ

    アプリを入手し、ログイン画面に同じサーバーのアドレスを入れます。原文のようにWebから写真を1枚アップロードしておけば、その写真がアプリにも表示されたときにつながっています。

  5. バックアップをオンにする

    右上の雲のアイコン → 送るアルバムを選ぶ（ダブルタップで除外）→ いちばん下のEnable Backup。選んだアルバムの写真・動画のアップロードが始まります。写真が多いと時間がかかるため、原文は数枚だけ選んで先にアップロードする方法も案内しています。処理の状況はWebの管理画面のJob Queuesで見られます。

更新するとき

新しい版が出たら、リリースノートの互換性が壊れる変更（breaking changes）を先に確認し、.envでIMMICH_VERSIONを使っているなら希望の版に変えてから、docker-compose.ymlのあるフォルダーで実行するよう原文が案内しています。

更新して再起動

docker compose pull && docker compose up -d

ギット飯の補足: 更新する前に、DBのバックアップとUPLOAD_LOCATIONのコピーがあるかを先に確認してください。

起動する前に必ず知っておくこと

  • サーバーはLinuxが推奨です。それ以外のOSはDockerの使い勝手が悪く「強く非推奨」で、導入やトラブル対応の支援も大きく減ると原文に書かれています（Windows・macOSはDocker Desktopで試すことはできます）。DBのフォルダー（DB_DATA_LOCATION）はローカルのSSDに置き、どんな種類でもネットワーク共有には置かないよう書かれています。
  • DBに入っているのはメタデータとユーザー情報だけです。写真・動画の原本があるUPLOAD_LOCATIONは自分で別にバックアップする必要があると原文が警告しています。自動のDBバックアップ（既定: 毎日午前2時、直近14件を保存）はUPLOAD_LOCATION/backupsにたまりますが、写真・動画は入っていません。READMEも、3-2-1バックアップを常に守るよう書いています。
  • docker compose down -vはImmichのデータをすべて消すコマンドです。原文の復元の手順に「CAUTION! Deletes all Immich data」というコメント付きで含まれているので、そのままコピーして実行しないでください。管理画面のDBの復元も、現在のDBを消してバックアップに置き換えます。
  • 2283番ポートをインターネットへ直接転送しないよう原文が警告しています。Web画面が暗号化なしのhttpで公開され、中間者攻撃にさらされるためです。外から使うなら、リモートアクセスの案内（VPNなど）を先に読んでください。ギット飯の補足: 既定のdocker-compose.ymlは「2283:2283」でポートを開くため、同じネットワークの他の機器もこのアドレスでアクセスできます。
  • 整理済みのフォルダーを外部ライブラリとしてつなぐときは、マウントの行の末尾に:ro（読み取り専用）を付けてください。原文の例には、:roがないとImmichがそのフォルダーのファイルを削除できると書かれています。また、ライブラリ内でファイルを移したあと再スキャンすると、Immichで加えたアルバム・説明などのメタデータが失われると書かれています。
  • UPLOAD_LOCATIONの中のファイルは、バックアップするとき以外は絶対に触らないよう原文に書かれています。ファイルを変えたり消したりすると、追跡されないファイルや消えたファイルが生じるためです。バックアップはサーバーのコンテナを止めて行うか、止められなければDBを先に、ファイルを後に取るよう書かれています。
  • アプリのFree Up Space（空き容量の確保）は、サーバーにバックアップ済みの写真・動画のスマホ側のコピーを端末のごみ箱へ移します。原文には、サーバーが正常でバックアップされていれば、消した写真をアプリで引き続き見られると書かれています。iCloud写真を併用している場合、双方向の同期のため、iCloudと同じApple Accountの他の機器からも消えると原文が警告しています（iCloudを補助のバックアップにしているなら、代わりに「iPhoneのストレージを最適化」を使うよう勧めています）。ギット飯の補足: サーバーのバックアップと復元を確かめる前には使わないでください。
  • インストールスクリプト（install.shをbashで直接実行する方法）は、原文が「実験的」で本番には勧めないと書いているため、このページでは扱いません。

AIアプリにインストールを任せるなら

下の指示文をClaude CodeやCodexに貼り付けると、固定したv3.3.3の文書とリリースのファイルでサーバーだけを起動し、Dockerのインストール、保存先、版、外部公開の前には先に確認します。データを消すコマンドは同意なしに使わないようにしています。指示文はギット飯が公式文書をもとに書いたものです。

AIアプリに貼り付けるインストールの指示文

Docker Composeでのインストール（推奨） ↗インストール手順（取得・.env・起動） ↗example.envの既定値 ↗要件 ↗Quick start（DBにはメタデータだけ） ↗管理者の登録 ↗モバイルアプリの入手 ↗モバイルアプリのログイン ↗モバイルアプリのバックアップ ↗モバイルバックアップ ↗アルバムの共有 ↗README（3-2-1バックアップ・デモ） ↗バックアップと復元 ↗リモートアクセス（2283番ポート） ↗外部ライブラリ（移動後のメタデータ） ↗外部ライブラリのマウント（:ro） ↗Free Up Space（iCloudの警告を含む） ↗アップグレード ↗インストールスクリプト（実験的） ↗Dockerヘルプ ↗ライセンス: AGPL-3.0 ↗

仕組みの説明図3枚を開く

動画の要点をギット飯が描いた図で整理しました。任せることと準備することを分けて見ます。

01 / スマホから送るアルバムを選ぶ

スマホから送るアルバムを選ぶ

旅行・家族アルバムを選び、仕事の資料を除外して送る図
ギット飯の韓国語説明図 · 実行画面ではありません根拠の資料 ↗機能のドキュメント ↗画像を大きく見る ↗
図が説明すること
選択したモバイルアルバムの写真・動画を送ります。除外アルバムやWi-Fi条件も設定できます。
自分の状況なら
最初は小さなコピーのアルバムで範囲を決め、実際の送信状態を確認します。
自分で用意すること
権限、バッテリー、通信設定を確認します。iOSのバックグラウンド実行時刻はOSが決めます。

韓国語の説明図で、公式資料に基づく利用例です。実際の写真のアップロード・共有・検索・復元を検証した結果ではありません。

説明図・動画：ギット飯。根拠：Immichの公式コード・資料。レポのコードライセンス：AGPL-3.0。確認：2026年10月15日。 レポのコードライセンス ↗

04 · 選び方

自分の条件なら、どちらを選ぶ？

自分の状況に合わせて選ぶ

3つの質問で結論まで

答えを選ぶと、下の比較と判断の根拠をもとにギット飯がまとめた結論がすぐに表示されます。

家族の写真は主にどこにありますか？
ライブラリはどう分けますか？
サーバーを運用し、故障時に復元する人はいますか？

3つ選ぶと結論が表示されます。

結論は、下の比較と「条件が変わったら」の判断、元の分析の推薦・保留の条件をそのまま反映したものです。 公式文書: DBのバックアップに写真は入らない ↗

ひと目で比較

同じ「家族3人の写真を集める」を、両ツールを自分で運用する（セルフホスト）構成どうしで比べました（Immich v3.3.3の文書・PhotoPrismの文書は2026-10-15に確認した版）。

基準Immich · セルフホストPhotoPrism · セルフホスト
新しいスマホ写真をどう入れる？専用アプリで送るアルバムを選択PhotoSyncなどWebDAV送信アプリ
整理済みフォルダーは？外部ライブラリ、移動後の再スキャンでメタデータが消える原本インデックスが名前・フォルダーを保持
家族ごとに資料が分かれる？利用者ごとに自分のライブラリuserロールがライブラリ全体を編集
故障後、誰が何を復元する？原本＋DB、自動ダンプに写真なし原本＋インデックスDB、storageフォルダーも推奨

こんなときは Immich · セルフホスト新しいスマホ写真を集め続け、利用者別ライブラリと選択的共有が必要で、サーバー担当者がいる場合。

こんなときは PhotoPrism · セルフホスト整理済みフォルダーと共用ライブラリが中心で、インデックス・送信アプリ・エディション別ロールを自分で構成できる場合。

基準ごとの詳しい説明と出典
新しいスマホ写真をどう入れる？
Immich · セルフホスト
専用モバイルアプリで送るアルバムを選択。バックグラウンド実行はOSや設定に左右されます。
PhotoPrism · セルフホスト
公式文書はPhotoSyncなどWebDAV送信アプリを案内。送信アプリの設定・機能・購入条件を別途確認します。

家族に一つのアプリの流れを案内したいならImmichから。既存のWebDAV送信が機能していれば、替える理由を先に確認します。

1 ↗2 ↗3 ↗

整理済みフォルダーは？
Immich · セルフホスト
外部ライブラリをスキャンできます。外でファイルを移した際、Immich内で追加したメタデータの保持に制約があります。
PhotoPrism · セルフホスト
originalsを直接インデックスすれば名前・フォルダーを保持。importは整理方法が異なるので区別が必要です。

フォルダーを編集し続けるなら、「外部フォルダー対応」より移動後のアルバム・説明の保持が判断基準です。

1 ↗2 ↗3 ↗

家族ごとに資料が分かれる？
Immich · セルフホスト
各利用者に自分のライブラリがあり、アルバムなどで共有します。実際のアカウント別アクセスは確認が必要です。
PhotoPrism · セルフホスト
公式ロール表の通常userはライブラリ全体を編集可能。Community・Essentials・Plusで提供ロールも異なります。

複数アカウントと個人別の非公開保管庫は別の要件です。家族別の分離が必須なら、ここを先に確認します。

1 ↗2 ↗3 ↗4 ↗5 ↗6 ↗

故障後、誰が何を復元する？
Immich · セルフホスト
原本の写真・動画とDBの両方が必要。DBの自動ダンプに写真ファイルは含まれません。
PhotoPrism · セルフホスト
最低限、原本とインデックスDBをバックアップ。公式文書は設定などを含むstorageも推奨します。

どちらも一度のインストールで運用責任は終わりません。別のバックアップの費用・時間を含めて比較します。

1 ↗2 ↗3 ↗

導入前に確認する3つ

インストール前に確認しておくと、無駄足を減らせます。チェックはこの画面でのみ表示されます。

  • 合わないときは 即時送信が必須で満たせなければ、主な写真保管先への切り替えは保留します。

  • 合わないときは 検索品質や機器が足りなければ、モデル・機器の調整費用まで含めて判断します。

  • 合わないときは 確認前に既存の原本やサービス上のコピーを消さないことが切り替えの条件です。

ギット飯が想定した例と根拠

想定：家族3人がそれぞれのスマホ写真を集め、一部のアルバムだけ共有したい。既存の写真サービスは当面残します。Dockerサーバーの担当者が1人いて、原本とDBを別の場所に保存する予算があります。

  • 家族3人の写真をアカウント別に分け、選んだアルバムだけを共有します。
  • 既存サービスを残して小さなコピーで検討し、サーバーの担当者がいます。
  • 保存装置・電力・別のバックアップ・運用時間に費用をかけられます。月の総費用はまだ計算していません。

Immichの公式コード・資料は2026年10月19日にv3.3.3のタグのコミット（d2dac658）に固定して再確認し、PhotoPrismの資料は2026年10月15日に確認した版に基づきます。図はギット飯が制作し、実際の接続・設置・投稿・復元は検証していません。

使いどころがわかる解説

家族の写真を、自分のサーバーへ

スマホのアルバムを送り、写真を探し、必要なアルバムだけ共有。原本とDBの別のバックアップまで、手描き動画で確認します。

01 · 役割を分ける

任せる部分と、自分で担う部分

Immich に任せる

  • ウェブ・アプリのライブラリとアルバム・検索・共有
  • 選んだモバイルアルバムのアップロード機能

自分たちで準備・運用する

  • サーバー・ディスク・接続経路・更新の担当者
  • 家族別のアカウント、共有範囲、送信状態の確認
  • 原本とDBの別のバックアップ、復元手順と確認

インストールできることより、家族が使い続け、誰かが復旧できることが選ぶ基準です。

公式資料 1 ↗公式資料 2 ↗公式資料 3 ↗公式資料 4 ↗公式資料 5 ↗公式資料 6 ↗公式資料 7 ↗公式資料 8 ↗公式資料 9 ↗公式資料 10 ↗公式資料 11 ↗公式資料 12 ↗
さらに詳しく：原作の読み方と確認事項

動画の流れを自分の状況に当てはめます。任せることと準備することを分け、導入前の確認へ進みます。以下は公式資料に基づく解釈で、実行テストの結果ではありません。

02 · 読むだけで終わらせない

全体を移す前に「使い続けられ、復元できるか」を確認します。

以下は自分の条件に照らして確認するための手順です。ギット飯による実行結果ではありません。

  1. 二つのアカウントと小さなコピーのアルバムを用意し、送信・検索・共有を確認します。

    残すもの各自が見る資料、共有する資料、送信の確認方法が明確になります。

  2. 担当者と、原本・DBのコピーを別の試験環境へ復元する手順を確認します。

    残すもの誰が、どの資料を、どこから戻すかを説明できます。

次へ進める条件

家族の利用手順とアクセス範囲が合い、容量・運用費用・復元手順を確認できたら段階的に進めます。

立ち止まる条件

検索・送信が期待に届かない、または復旧担当者とコピーがなければ既存の方法を維持します。

判断の根拠と確認項目を詳しく読む

スマホから送るアルバムを選ぶ

公式資料で確認
選択したモバイルアルバムの写真・動画を送ります。除外アルバムやWi-Fi条件も設定できます。
ギット飯の解釈
最初は小さなコピーのアルバムで範囲を決め、実際の送信状態を確認します。
導入前の判断
権限、バッテリー、通信設定を確認します。iOSのバックグラウンド実行時刻はOSが決めます。
根拠資料 1 ↗根拠資料 2 ↗根拠資料 3 ↗

各自で保存し、必要なアルバムだけ共有

公式資料で確認
利用者ごとにライブラリがあり、アルバムやリンクで共有できます。同じサーバーを使うだけで全写真が公開されるわけではありません。
ギット飯の解釈
旅行写真の一部を一緒に見つつ、個人の写真は別に管理したい家族に合います。
導入前の判断
2アカウントで実際のアクセス範囲を確認します。検索結果も自分の写真と検索語で確かめます。
根拠資料 1 ↗根拠資料 2 ↗根拠資料 3 ↗

原本とデータベースを両方保存する

公式資料で確認
DBにはパスとメタデータがあります。DBの自動ダンプに写真・動画原本は含まれず、両方の確保が必要です。
ギット飯の解釈
スマホから送信できても、サーバー故障に備えたバックアップが済んだとは限りません。
導入前の判断
別の保存先へコピーし、独立した試験環境で復元手順を確かめます。切り替え確認が済むまで既存原本を残します。
根拠資料 1 ↗根拠資料 2 ↗根拠資料 3 ↗

向いている場面

  • スマホ写真を利用者別に集め、必要なアルバムだけ共有したい家族
  • サーバー運用と別のバックアップの担当者がいる個人・家庭

別の選択肢も比べたい場面

  • 設置後の管理・復旧を全く担当したくない場合
  • 今の写真サービスに不足がなく、移行する明確な理由もない場合

試す前に確認すること

  • 選んだアルバムと実際の送信完了をそれぞれ確認しましたか？
  • 別の家族アカウントから非公開写真が見えないことを確認しましたか？
  • 運用サーバーとは別の場所に原本・DBのコピーがあり、復元方法も確認しましたか？

選んだ理由：アップロードできることと、故障後に復旧できることは別です。送る範囲・家族との共有・バックアップの責任を3枚の図で整理します。

出典と確認範囲

公式資料とコードをもとに、ギット飯が説明図と動画を制作しました。実機を操作した録画や、新しく動作・導入効果を測定した記録ではありません。

作者
Immich and contributors
確認日
2026-10-19
ライセンス
AGPL-3.0 ↗
GitHub ↗公式ドキュメント ↗参照した版 · d2dac65 ↗

ギット飯は GitHub のオープンソース情報を日本語でまとめてお届けするサービスです。掲載しているリポジトリ情報・AI 要約は原著作者の公開資料にもとづくもので、各著作物の権利は原著作者に帰属します。