Synology NASでDockerセットアップ：Container Managerの使い方

DS923+やDS1522+といったRyzen搭載モデルにメモリを32GBまで増設し、単なるファイルサーバーではなく「高性能な自宅サーバー」として運用したいユーザーは多いはずです。しかし、いざDockerを導入しようとしても、コンテナのライフサイクル管理やボリュームマッピング、ネットワーク設定といった概念が壁となり、設定ミスでデータが消失したり、ポート競合で起動しなかったりするトラブルが絶えません。

SynologyのDSM（DiskStation Manager）で提供される「Container Manager」は、GUIベースで直感的にコンテナを操作できる強力なツールですが、その真価を発揮させるにはdocker-compose（プロジェクト機能）の活用や、適切な権限設定の知識が不可欠です。

本ガイドを通じて、Container Managerを用いた効率的なコンテナ展開の手順を習得し、Home AssistantやAdGuard Homeといったセルフホストアプリを安定して動作させる環境を構築しましょう。

Container Managerの構造とDockerエコシステムの統合

Synology NASにおけるDocker環境は、DSM 7.2以降「Container Manager」へと名称変更され、単なるコンテナ実行環境から、オーケストレーションに近い管理機能へと進化しました。従来のDockerパッケージでは、GUI上での単発コンテナ作成が中心でしたが、Container Managerでは「プロジェクト」機能が実装され、docker-compose.yaml形式の定義ファイルを直接扱うことが可能です。これにより、データベース（MariaDB 11.x等）とアプリケーション（Nextcloud等）をセットでデプロイし、ネットワーク的に独立したスタックとして管理できるため、運用の再現性が飛躍的に向上しています。

技術的な核心は、Synology独自のストレージレイヤーとDockerのボリュームマウントの統合にあります。コンテナ内のデータは揮発性であるため、/volume1/docker/ などの共有フォルダにデータを永続化させますが、ここで重要なのがファイルシステム（Btrfs vs ext4）の選択です。Btrfsを採用することで、コンテナ設定やデータディレクトリに対して「Snapshot Replication」を適用でき、設定ミスによる破壊的な変更が発生しても、数秒前、あるいは数時間前の状態にロールバックすることが可能です。これは、自作サーバーでの手動バックアップに比べ、運用コストを劇的に下げることができます。

また、Container ManagerはSynologyの「リバースプロキシ」機能と密接に連携します。通常、Dockerコンテナは 8080番や 9000番といった非標準ポートで動作しますが、DSMの「コントロールパネル」→「ログインポータル」→「詳細設定」からリバースプロキシを設定することで、https://app.example.com のようなFQDNでコンテナへアクセスさせることが可能です。この際、Synologyが提供するLet's Encryptの自動更新証明書を適用できるため、個別のコンテナ側で証明書管理を行う手間が省けます。

以下に、Synologyにおける仮想化・コンテナ化技術の役割分担をまとめます。

導入ハードウェアの選定基準とリソース設計

Container Managerを快適に動作させるためには、CPUアーキテクチャとメモリ容量の選定が決定的な要因となります。Synology NASにはARMベースのJシリーズ/Valueシリーズと、Intel/AMDベースのPlus(+)シリーズ/xsシリーズが存在しますが、Docker運用においてはx86-64アーキテクチャ（Intel/AMD）搭載モデルが必須と言っても過言ではありません。多くのDockerイメージは amd64 向けにビルドされており、ARM（arm64）対応のイメージは限られているため、導入後に「イメージが見つからない」という状況を避ける必要があります。

特に注目すべきはメモリ（RAM）です。DSM自体が一定のリソースを消費し、さらにコンテナを増やすたびにメモリ消費量が増加します。例えば、Home AssistantやPlex、Giteaなどを同時に動かす場合、標準の4GBではスワップが発生し、I/O待ちによるシステム全体のレスポンス低下（レイテンシの増大）を招きます。DS923+やDS1522+のようなモデルでは、空きスロットに Synology純正のD4EC01600 (16GB) やサードパーティ製の互換メモリを追加し、合計16GB〜32GBまで拡張することを強く推奨します。

ストレージ面では、コンテナの構成ファイルやデータベースのインデックスファイルが頻繁に読み書きされるため、HDD（5,400rpm〜7,200rpm）への配置はパフォーマンスのボトルネックになります。2026年現在の最適構成は、NVMe M.2 SSDを「ストレージプール」として構成し、そこに /docker フォルダを配置することです。これにより、コンテナの起動速度が数秒単位で短縮され、データベースのクエリ応答速度（msec）が劇的に改善されます。

以下に、Docker運用を想定した推奨モデルとスペック構成例を示します。

実装時のハマりどころとトラブルシューティング

Container Managerの導入において、最も多くのユーザーが直面するのが「権限（Permissions）」の問題です。Dockerコンテナ内のプロセスは、デフォルトでは root ユーザーで動作しようとしますが、Synologyの共有フォルダ上のファイルはDSMのユーザー権限で管理されています。ここで不一致が起きると、コンテナが起動しても設定ファイルに書き込みができず、Permission Denied エラーで即座に停止（Exited）します。

この問題を解決する標準的な手法が、環境変数 PUID（User ID）と PGID（Group ID）の指定です。SSHでNASにログインし、id コマンドを実行して、コンテナ用ユーザーの数値を（例: PUID=1026, PGID=100）を確認し、これをコンテナ設定の環境変数に追加します。これにより、コンテナ内のプロセスがNAS上の特定のユーザーとして振る舞い、ファイル所有権の整合性が保たれます。

次に注意すべきはネットワークモードの選択です。Container Managerでは主に以下の3種類が選択可能ですが、用途を間違えると通信不能に陥ります。

• Bridge（ブリッジ）: 仮想ネットワークを構築し、NASのIPアドレスを共有してポートをマッピングする。最も安全だが、ポート重複に注意が必要。
• Host（ホスト）: NASの物理ネットワークに直接紐付ける。ポート指定が不要で高速だが、NAS側で既に使用されているポート（例: 5000, 5001）と衝突するとコンテナが起動しない。
• Macvlan: コンテナにNASとは別の独立したIPアドレスを割り当てる。ネットワーク的に独立させたい場合に有効だが、ルーター側のDHCP設定やサブネットの知識が必要。

また、DSMのアップデートに伴い、Dockerの内部パスや権限設定がリセットされる事例が稀に報告されています。これを防ぐためには、GUIでの設定に頼りすぎず、上述の「プロジェクト（docker-compose）」機能を利用してYAMLファイルで構成をコード化しておくことが重要です。

【チェックリスト：起動しない時の確認事項】

• PUID / PGID は正しく設定されているか？
• マウントパス（例: /volume1/docker/app）は実際に存在し、権限が付与されているか？
• ポート番号が他のサービス（DSM本体や他コンテナ）と重複していないか？
• イメージのタグが latest になっており、意図しないメジャーアップデートで破壊されていないか？（バージョン固定を推奨）

パフォーマンス最適化と運用コストの最小化

Docker環境を構築した後に直面するのが、リソースの枯渇です。特にメモリリークを起こしやすいアプリケーションや、バックグラウンドで激しくI/Oを発生させるツールを導入すると、NAS全体の動作が重くなります。Container Managerでは、コンテナごとに「メモリ制限」を設定することが可能です。例えば、軽量なツールには 256MB、中規模なアプリには 1GB と上限を設けることで、単一のコンテナがメモリを食いつぶしてDSMがハングアップする（OOM Killerの作動）リスクを回避できます。

ストレージI/Oの最適化については、NVMe SSDキャッシュの活用ではなく、「NVMeストレージプール」への配置を優先してください。キャッシュ（読み込み専用/読み書き両用）はランダムアクセスを高速化しますが、Dockerのコンテナレイヤーや書き込み負荷の高いDBログなどは、直接SSDプールに配置したほうがレイテンシが低く、安定したスループット（MB/s）を得られます。特にSynology純正の SNV3410 シリーズなどのエンタープライズ向けSSDを利用することで、TBW（総書き込み容量）の高い運用が可能です。

また、運用の自動化とバックアップ戦略も不可欠です。Dockerコンテナのデータ実体は /volume1/docker フォルダに集約されているため、ここを「Hyper Backup」の対象に含めることで、外部NASやクラウドストレージ（S3等）へ定期的にバックアップすることが可能です。設定ファイル（YAML）をGitHubなどのプライベートリポジトリで管理し、データのみをHyper Backupで保護する構成が、2026年時点でのベストプラクティスと言えます。

以下に、リソース最適化のための設定指針をまとめます。

Docker運用におけるSynology NASモデルと環境の徹底比較

Synology NASでDocker（Container Manager）を運用する場合、OSであるDSM（DiskStation Manager）の操作性は極めて高いものの、ハードウェアリソースがボトルネックになります。特にコンテナ数が増え、データベース（PostgreSQL, MariaDB）や監視ツール（Prometheus, Grafana）を同時に稼働させると、メモリ消費量とディスクI/Oが急激に増大します。

まずは、2026年現在の現行ラインナップから、Docker運用に適したモデルのスペックを比較します。特にCPUのアーキテクチャ（AMD Ryzen vs Intel）と、メモリの拡張性が運用の分かれ道となります。

Docker対応主要モデルのスペック比較

AMD Ryzen搭載モデルはマルチスレッド性能に優れ、コンテナの並行処理に適していますが、Intelモデル（特にXSシリーズ）はエンタープライズ向け機能とメモリ最大容量で圧倒的なアドバンテージを持ちます。

次に、管理手法の比較です。Synology純正の「Container Manager」はGUIで完結するため導入障壁が低いですが、上級者はPortainerを別途導入して詳細なネットワーク制御やスタック管理を行う傾向にあります。また、自作NAS派が選ぶTrueNAS Scaleとの思想の違いを明確にします。

コンテナ管理プラットフォームの機能比較

SynologyのContainer Managerは、2024年以降のアップデートでdocker-compose相当の「プロジェクト」機能が強化されましたが、ネットワークの柔軟性や詳細なログ監視においては、依然としてPortainerを併用するのが業界標準となっています。

Docker運用において最も重要なのがメモリ容量です。コンテナ自体は軽量ですが、Javaベースのアプリ（例：Nextcloud, GitLab）や監視系ツールを動かすと、1つあたり1〜2GBのメモリを容易に消費します。メモリ不足になるとスワップが発生し、ストレージへの書き込み負荷が増大してシステム全体のレスポンスが低下します。

メモリ容量別・運用可能コンテナ数の目安

Synology NASの多くは非公式ながらサードパーティ製メモリ（Crucial等）での増設が可能ですが、ECCメモリを要求するモデルでは互換性チェックが必須です。特にDS1823xs+以上のモデルでは、メモリ増設がパフォーマンス向上に直結します。

また、コンテナのデータ保存先（ボリューム）に何を採用するかで、データベースのクエリ速度やアプリケーションの起動速度が劇的に変わります。HDD上のBtrfsボリュームでは、ランダムアクセス性能（IOPS）が低いため、コンテナ運用には不向きです。

ストレージ・バックエンドの性能比較

Dockerの /var/lib/docker やマウントするデータディレクトリをNVMe SSD（ストレージプールとして構成）に配置することで、例えばWordPressの管理画面のレスポンスや、データベースのインデックス作成時間が数分の一に短縮されます。

最後に、外部公開やAPI連携を行う際にボトルネックとなるネットワークインターフェースの選択肢についてです。2026年時点では、2.5GbEが標準となりつつありますが、コンテナ経由で大量のデータを転送する場合（例：バックアップツールやメディアサーバー）は10GbEの導入が不可欠です。

ネットワークインターフェースの帯域・用途比較

Synologyのモデルによっては、オプションのネットワークカード（E10G21-F2等）を追加することで10GbE化が可能です。コンテナベースのサービスを社内や家庭内で展開し、複数ユーザーが同時にアクセスさせる場合は、ネットワーク帯域の確保がユーザー体験に直結します。

よくある質問

Q1. Dockerを快適に動かすためのメモリ増設費用はどのくらいかかりますか？

モデルによって異なりますが、例えば DS923+ 等の増設可能モデルで、純正の DDR4 ECC メモリ 16GB を追加する場合、概ね 20,000円〜30,000円程度の予算が必要です。Container Manager で複数のコンテナを起動すると、OS だけで 2GB 以上、コンテナごとに数百MB〜数GBを消費するため、標準の 4GB では不足しがちです。合計 20GB 程度まで増設することで、メモリ不足によるコンテナの強制終了（OOM Kill）を回避でき、運用の安定性が飛躍的に向上します。

Q2. 24時間コンテナを稼働させた場合の電気代への影響は？

コンテナの数と負荷によりますが、DS224+ のような 2ベイモデルでアイドル時の消費電力が約 15W、高負荷時に 30W 程度と想定すると、月間の電気代増加分は数百円程度に収まることが一般的です。ただし、Home Assistant や Plex などのリソース消費が激しいアプリを常時稼働させ、CPU 使用率を 50% 以上に維持する場合、消費電力は上昇します。省電力設定で HDD のスリープを有効にしても、Docker コンテナが動作している間はディスクがアクセスされ続けるため、スリープは機能しない点に注意してください。

Q3. Synology 純正の Container Manager と Portainer どちらを使うべきですか？

基本的には Container Manager で十分ですが、より高度な管理を求めるなら Portainer の導入を推奨します。Container Manager は GUI で直感的に操作でき、Docker Compose V2 ベースのプロジェクト管理が可能ですが、Portainer はスタックの高度な編集や、詳細なログ監視、ネットワークの可視化に優れています。特に 10 個以上のコンテナを運用する場合、Portainer を導入して一元管理することで、管理コストを大幅に削減できます。まずは純正版を使い、機能不足を感じてから Portainer を導入するのが定石です。

Q4. Docker 運用に最適な Synology NAS の選び方は？

CPU に AMD Ryzen R1600 などを搭載した「Plus シリーズ」を強く推奨します。例えば DS1522+ は 5 ベイの拡張性と高い処理能力を備えており、多くのコンテナを同時に動かす環境に適しています。一方で、J シリーズなどのエントリーモデルは CPU 性能が低く、メモリ増設ができないモデルが多いため、Docker の運用には向きません。コンテナを主体に運用する場合、最低でも 4GB 以上のメモリを搭載し、NVMe SSD キャッシュ（例：SNV3400 シリーズ）を導入して I/O 速度を底上げした構成を選んでください。

Q5. ARM 搭載モデルでも Docker は動作しますか？

動作しますが、利用可能なイメージが大幅に制限されます。DS223j などの ARM 搭載モデルでは、x86_64 アーキテクチャ向けのイメージは動作せず、arm64 または armhf 対応のイメージのみが動作します。多くの主要アプリはマルチプラットフォーム対応していますが、一部の専門的なツールや古いレガシーアプリは x86 専用である場合が多く、インストール時に「イメージが見つからない」エラーが発生します。Docker を本格的に活用したい場合は、Intel または AMD CPU 搭載モデルを選択してください。

Q6. 10GbE ネットワークカードを導入すると Docker のパフォーマンスは上がりますか？

コンテナ内部の処理速度は上がりませんが、データの転送速度は劇的に向上します。E10G22-T1-S1 などの 10GbE NIC を導入し、NAS 内部の Docker コンテナ（例：Nextcloud や Samba 等）で大容量ファイルを扱う場合、1GbE の上限である 125MB/s を超え、理論上最大 1.25GB/s の帯域を利用可能です。特に NVMe SSD をストレージプールとして構成し、Docker のボリュームをそこに配置していれば、ネットワークがボトルネックにならず、高速なファイルアクセスを実現できます。

Q7. コンテナが頻繁に再起動したり、停止したりする原因は何ですか？

最も多い原因はメモリ不足（Out of Memory）です。特に 4GB メモリのモデルで、メモリ制限を設定せずに複数のコンテナを起動すると、システム全体のメモリを使い切り、カーネルによってプロセスが強制終了されます。各コンテナの「設定」からメモリ制限を 512MB や 1GB などに具体的に割り当て、合計が物理メモリの 80% を超えないように調整してください。また、ログファイルが肥大化してディスク容量を圧迫し、書き込み不能に陥っているケースもあるため、ログの最大サイズを 10MB 程度に制限することを推奨します。

Q8. 共有フォルダをマウントした際、権限エラーで書き込みできないのはなぜですか？

Docker コンテナ内のユーザー ID (UID) と、Synology DSM 上のユーザー ID が一致していないためです。多くのセルフホストアプリ（LinuxServer.io 製など）では、環境変数 PUID と PGID を指定します。DSM の SSH ターミナルで id コマンドを叩き、ユーザー ID（例：1026）を確認し、それをコンテナ設定に反映させてください。これにより、NAS 上の /volume1/docker/appdata などのディレクトリに対して、コンテナ内のプロセスが正しく読み書き権限を持つようになります。

Q9. Synology NAS 上の Docker で LLM（大規模言語モデル）は動作しますか？

動作はしますが、CPU 処理のみとなるため非常に低速です。例えば Ollama などのコンテナを導入し、Llama 3 (8B) などの軽量モデルを動かした場合、推論速度は数トークン/秒に留まります。Synology NAS は GPU パススルーを公式にサポートしていないため、NVIDIA T4 等の外部 GPU を組み込んで加速させることは不可能です。実用的な速度を求める場合は、Docker 経由で外部の GPU サーバーに API リクエストを送る構成にするか、CPU 負荷を許容して小規模なモデルを利用してください。

Q10. 将来的に Docker から仮想マシン（VMM）へ移行すべきタイミングは？

コンテナでは解決できない「カーネルレベルのカスタマイズ」が必要になった時が移行タイミングです。Docker はホストのカーネルを共有するため軽量ですが、独自の OS 設定や特定のドライバ導入が必要なソフトは動作しません。例えば、完全な Windows 環境や、特定の Linux ディストリビューションでのみ動作する商用ソフトを動かしたい場合は、Virtual Machine Manager (VMM) を利用してください。ただし、VMM は 1 つの VM で 2GB〜4GB 以上のメモリを専有するため、メモリを 32GB 以上に増設した環境での運用が必須となります。

まとめ

Synology NASの「Container Manager」を活用することで、複雑なコマンドライン操作を介さず、GUIベースで高度なコンテナ環境を構築・運用することが可能です。本記事の要点は以下の通りです。

• Container Managerの「プロジェクト」機能により、YAML形式のdocker-compose設定を直接管理できる
• データの永続化には、/volume1/docker 以下の共有フォルダを適切にマウントすることが不可欠である
• DS923+やDS1522+などのPlusシリーズで運用する場合、メモリを16GB〜32GBへ増設することで、多数のコンテナ同時起動時のスワップ発生を抑制できる
• ネットワーク設定における「Bridge」と「Host」の使い分けが、ポート競合の回避と通信効率の最適化の鍵となる
• DSMの「逆プロキシ」設定を併用することで、外部からHTTPS経由で各コンテナへドメイン名を用いてアクセス可能になる
• リポジトリからの最新イメージ取得と、定期的なコンテナ更新により、セキュリティパッチを適用し続けることが重要である

まずは、Home AssistantやNextcloudといった定番のセルフホストアプリを1つ導入し、ボリュームマウントとネットワーク設定の挙動を確認してみてください。環境が安定したら、docker-composeを用いた複数サービスの連携構築に挑戦することをおすすめします。