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

また、運用の自動化とバックアップ戦略も不可欠です。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を用いた複数サービスの連携構築に挑戦することをおすすめします。