セルフホスト写真管理にImmichが選ばれる理由と競合OSSとの違い

「Google Photos の無料枠が終了して以降、家族写真や仕事の写真をどこに置けばよいか決めかねている」「セルフホストの写真管理 OSS を触り始めたいが、Immich と PhotoPrism のどちらを選べばよいか判断できない」——このような検討の入り口に立つ方は少なくありません。写真管理 OSS はここ数年で急速に増え、それぞれ得意領域が異なるため、公式ドキュメントを一通り読んでも比較検討の軸が定まりにくいのが実情です。

とくに Immich は、GitHub リポジトリで 10 万を超えるスターを獲得し、Google Photos 代替の第一候補として名前が挙がる機会が増えました。一方で、開発が非常に活発なぶん、機能差やアーキテクチャの前提条件を短時間で把握するのが難しく、「そもそも自分の環境に合うのか」「PhotoPrism など他の OSS ではだめなのか」といった疑問が残りがちです。

本記事では、Immich の公式ドキュメント・README・GitHub リポジトリの情報をもとに、Immich というプロジェクトの位置づけ、主要機能、アーキテクチャと必要環境、そして PhotoPrism・LibrePhotos との違いを整理します。動作検証やインストール手順の紹介は行わず、あくまでドキュメントベースで「初見のエンジニアが採用可否を判断するための情報」に絞って解説します。

読み終えたときに、「自分の運用要件では Immich を第一候補にしてよいか」「PhotoPrism など別の選択肢に切り替えるべきか」を、根拠のある形で判断できる状態を目指します。

Immich とは — セルフホスト写真管理 OSS の概要

Immich は、自分のサーバーやホームラボで写真・動画を管理するためのセルフホスト OSS です。公式リポジトリでは「High performance self-hosted photo and video management solution.」（高性能なセルフホスト写真・動画管理ソリューション）と説明されており、モバイルアプリからの自動バックアップ、機械学習を活用した検索、共有機能などを備えています。位置づけとしては、クラウドサービス「Google Photos」の体験をセルフホスト環境で再現することを目指したプロジェクトです。

なお本記事では動作検証やインストール作業は行わず、公式サイト・公式ドキュメント・GitHub リポジトリの情報のみに基づいて解説します。実運用にあたっては、記事末尾に掲載する公式リソースを直接確認してください。

プロジェクトの位置づけと運営体制

Immich は個人の開発者から始まったプロジェクトですが、現在は非営利団体 FUTO のバックアップ体制のもとで開発が続けられています。プロジェクトの目的や成り立ちは公式サイトで確認できます。

Google Photos は無制限の無料バックアップ枠を終了しており、家庭内の写真アーカイブや業務で扱う写真データの保管先を見直したい層は増加しています。Immich は「クラウドサービスに近い UX を、データを自分の手元に置いたまま実現する」という点で、こうしたニーズに対する現実的な選択肢の 1 つとして注目されています。

一方で、公式 README の冒頭には「Immich は活発に開発中のソフトウェアであり、大切な写真・動画は 3-2-1 バックアップ戦略に沿って別途バックアップを取ること」という趣旨の注意書きが掲げられています。プロダクションで扱う写真データを Immich だけに預けないという運用前提は、採用検討時点で押さえておく必要があります。

リポジトリ基本情報（スター数・言語・ライセンス・最終更新日）

GitHub の公式リポジトリ から取得した基本情報は次のとおりです（数値は本記事執筆時点の値で、今後変動します）。

スター数が 10 万を超え、フォーク数も 6,000 台と、セルフホスト写真管理 OSS の中では突出した規模です。archived が false かつ fork が false であることから、本記事執筆時点で本家リポジトリがアーカイブされておらず、他リポジトリのフォークでもない、独立した現行プロジェクトであることが確認できます。最終 push が本記事執筆時点で 2026-07-10 と非常に新しく、コミット頻度も高い状態が続いています。長期採用の観点では、この開発活動の継続性は判断材料になります。

Immich が解決する課題

セルフホスト写真管理 OSS を検討する動機は、主に次のような課題に集約されます。Immich の位置づけをつかむために、まず「なぜセルフホストが選ばれるのか」を整理しておきます。

1. クラウド写真サービスのコストと制約

Google Photos の無料無制限バックアップは既に終了しており、Google One などの有料プランに移行するか、他サービスに切り替える必要があります。iCloud なども写真容量に応じて月額課金が発生する構造のため、写真・動画が増えるほど固定費が積み上がります。長期保管の写真を継続的にクラウドに預け続けるコスト構造は、家族数や年数を掛け合わせると無視できない金額になります。

2. プライバシー・データ主権の懸念

家族写真、子どもの写真、業務で扱う機密性の高い写真などをサードパーティのクラウドサービスに常時アップロードすることに抵抗を感じる層が増えています。企業のインフラ担当者にとっては、顧客案件の写真データをオンプレミス環境で完結させたいという要件そのものが発注条件になるケースもあります。

3. 写真専用機能が汎用ストレージでは不足する

「単にストレージに置くだけ」であれば Nextcloud や自前のオブジェクトストレージで代替できます。しかし、顔認識・意味検索（自然言語での写真検索）・タイムライン UI・地図表示・モバイルからの自動バックアップといった「写真アプリ」らしい体験は、汎用ストレージだけでは実現できません。Immich はこの部分を専用機能として提供します。

Immich は、これら 3 つの課題に対して「クラウド写真サービスに近い UX をセルフホストで実現する」というアプローチで応えます。データを手元に置いたまま、Google Photos に近い操作感で写真ライブラリを扱えることが、Immich が選ばれる中心的な理由です。

Immich の主要機能を機能カテゴリ別に整理する

Immich の機能一覧は README と公式ドキュメントに詳細に記載されています。ここでは、採用検討時に確認したい主要機能をカテゴリ別に整理します。

自動バックアップとマルチデバイス対応

Immich の存在感を最も特徴づけているのが、モバイルアプリからの自動バックアップです。iOS / Android のネイティブアプリが提供されており、アプリ起動時のフォアグラウンドバックアップとバックグラウンドバックアップに対応します。バックアップ対象のアルバムを選択できるため、カメラロール全体ではなく特定のアルバムのみを Immich に送るといった運用も可能です。

対応するメディア形式も広く、RAW フォーマット、LivePhoto、MotionPhoto、360 度画像に対応しており、モバイルで撮影した多様な素材をそのまま Immich 側で扱えます。既にアップロード済みの写真の重複防止機能も備わっているため、複数デバイスからの同一写真の重複登録も抑制されます。CLI ツールも提供されており、既存の大量ライブラリをバッチアップロードする経路も用意されています。

機械学習を活用した検索

Immich は 2 種類の機械学習機能を提供します。

1 つ目は CLIP モデルを用いた自然言語検索（Smart Search）です。「beach sunset」「dog playing」といった英語のフレーズで、対応する写真を意味的に検索できます。2 つ目は顔認識とクラスタリングによる人物別グループ化で、写真ライブラリに登場する人物を自動的にグループ化して、後から名前を付ける形で管理できます。

これらの ML 機能は既定で有効ですが、公式ドキュメントによればハードウェアアクセラレーション機能は「experimental（実験的）」と位置付けられています。プロダクション相当の負荷で使う場合は、この点を運用要件と照らして判断する必要があります。

共有機能とマルチユーザー

Immich は個人利用だけでなく、家族や小規模チームでの共有利用を想定した機能も揃っています。アルバムと共有アルバム、パートナー共有（配偶者やパートナーとライブラリをシェアする機能）、URL 経由での公開共有、マルチユーザー対応、OAuth ログイン、API キー発行（Web のみ）などが提供されます。マルチユーザーやパートナー共有が OSS の範囲で完全に利用できる点は、後述する類似 OSS との比較でも重要なポイントになります。

メタデータと地図

写真の EXIF 情報表示、位置情報を用いたグローバルマップ、「N 年前の今日」を振り返る Memories 機能などが提供されます。写真のライフサイクル管理という観点では、アーカイブ・お気に入り・フォルダビュー・タグ（Web のみ）・Stacked Photos（HDR や連写を 1 枚として扱う機能）も揃っており、単なる保存領域ではなく「写真アプリ」として日常的に閲覧・整理する用途に耐える構成になっています。

Immich のアーキテクチャと必要環境

採用検討で必ず論点になるのが、自環境で動かせるかどうかです。ここでは Immich の構成要素と、公式が示すインストール要件を整理します。

構成要素とデータフロー

Immich は複数のコンテナで構成されるアプリケーションです。公式の概要ドキュメントによれば、主な構成要素は次のとおりです。

• Web アプリケーション（ブラウザから利用する UI）
• iOS / Android モバイルアプリ（自動バックアップと閲覧のフロント）
• CLI（バッチアップロード用途）
• ジョブキュー処理（アップロード・メタデータ抽出・機械学習推論）
• PostgreSQL データベース

これらを Docker Compose で束ねて動作させるのが標準的な構成です。実装言語は TypeScript が中心となっており、Node.js ベースのバックエンドが動作します。

必要ハードウェア・OS 要件

公式ドキュメントに記載された要件のうち、採用判断に直結する項目を抜粋します。

Windows についても WSL2 経由で動作させることは可能ですが、データベースのストレージには EXT2/3/4・ZFS・APFS のいずれかが必要で、NTFS / FAT32 は不可という制約があります。Windows Server や、既存 NAS の SMB マウント上に PostgreSQL データを置く構成は避ける必要があります。

インストール方式の選択肢

公式ドキュメントでは、次のインストール方法がサポートまたは案内されています。

• Docker Compose（推奨）
• Kubernetes
• Portainer
• Unraid
• ワンクリッククラウドサービス
• TrueNAS、Synology などのコミュニティサポートプラットフォーム
• インストールスクリプト（実験的）

自宅 NAS 上で運用する場合は Docker Compose か、Unraid / TrueNAS / Synology のコミュニティパッケージが現実的な選択肢です。クラスタ運用が必要なチームは Kubernetes 対応が用意されている点も評価できます。

機械学習のハードウェアアクセラレーション対応

Immich の ML 処理は CPU でも動作しますが、写真ライブラリが大きい場合はハードウェアアクセラレーションを検討することになります。公式ドキュメントによれば、対応バックエンドは次のとおりです。

• ARM NN（Mali GPU）
• CUDA（NVIDIA GPU、Compute Capability 5.2 以上）
• ROCm（AMD GPU）
• OpenVINO（Intel GPU: Iris Xe、Arc）
• RKNN（Rockchip SoC: RK3566、RK3568、RK3576、RK3588）

公式ドキュメントでは、CUDA が最も信頼性の高いバックエンドとして位置付けられています。5 種類のバックエンドをカバーしている点は、自宅サーバーや小規模事業所で入手可能な GPU をそのまま活用できる幅広さにつながります。ただし、既述のとおり ML アクセラレーションは公式に experimental と明記されているため、業務用途で採用する場合はワークロードに応じた検証を別途行う前提で扱うのが安全です。

類似 OSS との違い — PhotoPrism・LibrePhotos との比較

Immich を採用検討する際に、必ず名前が挙がる類似 OSS が PhotoPrism と LibrePhotos です。公式にも比較ページが用意されていますが、ここでは初見のエンジニアが選定判断に使いやすい形で違いを整理します。

PhotoPrism との比較

PhotoPrism は Go 実装のセルフホスト写真管理 OSS で、AI を活用した検索やタグ付け機能を備えています。写真の「アーカイブ」用途に強いのが特徴で、既存のフォルダ階層をそのまま扱える設計になっています。NAS 上に既にフォルダで整理してある写真ライブラリをそのままインデックスする、といった使い方に向いています。

Immich との主な違いを整理すると次のようになります。

「スマホから自動バックアップされる Google Photos 代替が欲しい」なら Immich、「NAS 上の既存フォルダ構造をそのままインデックスして省リソースで運用したい」なら PhotoPrism、という切り分けが判断軸になります。

LibrePhotos との比較

LibrePhotos は Python（Django）実装の写真管理 OSS で、顔認識・オブジェクト検出・セマンティック検索・逆ジオコーディング・イベントベースのアルバム生成といった機械学習系の機能に強みがあります。ライセンスは MIT で、AGPL-3.0 の Immich よりも自由度の高い条件です。

社内システムに組み込んで改変版を配布する可能性がある場合は、AGPL-3.0（Immich）の条件が受け入れられるかを確認する必要があります。改変版を公開する義務が受け入れられない構成では、MIT ライセンスの LibrePhotos が候補になります。逆に、モバイルからの自動バックアップとコミュニティ規模を重視するなら Immich が優位です。

比較サマリ表

3 つの OSS を意思決定用に俯瞰した比較表を掲載します。

なお、Nextcloud を既に運用している環境では、写真管理プラグインである「Nextcloud Memories」も候補に挙がります。ただし、これは Nextcloud 本体の性能・機能に依存する追加アプリであり、写真管理専用 OSS ではありません。写真管理を専用機能として深く使いたい場合、Immich や PhotoPrism などの専用 OSS が候補として優先されやすい構図です。

Immich を採用する際に確認すべき観点

意思決定を確度高く進めるために、実運用に入る前に確認しておきたい観点を整理します。

AGPL-3.0 ライセンスの意味

Immich のライセンスは AGPL-3.0 です。改変版を第三者（ネットワーク越しの利用も含む）に提供する場合、改変後のソースコードを公開する義務が発生します。社内利用のみであれば実務上の影響は小さいものの、SaaS 型で顧客に提供する構成や、改変を加えて配布する構成では、コンプライアンス上の判断が必要です。

開発活動の健全性

スター数 107,147、フォーク数 6,151、最終 push が 2026-07-10 と非常に活発です。archived や fork のフラグはいずれも false で、独立したアクティブなプロジェクトであることが確認できます。運営体制も FUTO のバックアップがあり、個人開発の依存度が高いプロジェクトと比べれば長期採用のリスクは相対的に低いといえます。今後の方向性は公式ロードマップで公開されているため、機能要件が計画済みかどうかを事前に確認できます。

3-2-1 バックアップ戦略の徹底

前述のとおり、README 冒頭で「Immich だけに写真を預けず、別途バックアップを取る」ことが明記されています。ソフトウェアの成熟度に関係なく、写真は失うと取り返しがつかないデータのため、Immich を運用する場合でも別ストレージへの定期バックアップは前提として設計する必要があります。

機械学習アクセラレーションが実験的である点

CUDA / ROCm / OpenVINO などのハードウェアアクセラレーションは公式に experimental と位置付けられています。CPU 単体でも ML 機能自体は動作しますが、大規模ライブラリで人物クラスタリングや Smart Search を多用する場合、GPU 前提の設計になりやすい点は要件定義の段階で織り込んでおくと安全です。

Windows でのファイルシステム制約

Windows 環境で運用する場合、WSL2 上に構築すること、PostgreSQL のデータ領域は EXT4 系や ZFS を割り当てることが求められます。Windows ホストで NTFS のディレクトリを直接データベースに割り当てる運用はサポート外である点に注意が必要です。

どのような組織・個人に向くか

家庭内で家族写真を長期保管したい個人ユーザー、社内向けに機密性の高い写真データ基盤をオンプレで構築したい情報システム部門、案件で写真データを扱う受託開発会社の SRE / インフラ担当などが典型的なユースケースです。逆に、既存の NAS 上のフォルダ構造をそのまま維持したいアーカイブ用途では PhotoPrism 側が向くケースがあります。

まとめ

Immich は、セルフホスト環境で Google Photos に近い体験を提供することを目指した写真・動画管理 OSS です。GitHub スター 107,147・フォーク 6,151 という圧倒的な OSS 規模、活発な開発活動、ネイティブモバイルアプリの完成度、CLIP と顔認識を組み合わせた検索、そして 5 種類のハードウェアアクセラレーションバックエンドという特徴を持ちます。

意思決定の観点で整理すると、次のように選定軸が定まります。

• モバイルからの自動バックアップとクラウドサービスに近い UX を重視するなら、Immich が第一候補になります。
• NAS 上の既存フォルダ構造をそのままインデックスして、より軽量に運用したいなら PhotoPrism が候補です。
• ライセンス上の自由度（改変版の再配布）を優先するなら MIT の LibrePhotos が候補になります。

いずれの選択でも、写真データは 3-2-1 バックアップ戦略に沿って別途バックアップを取る前提での運用が公式に推奨されている点は共通です。実際の導入にあたっては、公式サイト・公式ドキュメント・GitHub リポジトリ を直接参照し、自組織の要件と照らして最終判断を行うことをおすすめします。