ストレージブレイン：
Synology NAS OpenClawセットアップ
/** データが存在する場所にインテリジェンスをもたらす。 */
4ベイ以上のSynology（DS923+またはDS1522+）をお持ちなら、常時稼働のAMD Ryzenサーバーがあります。NAS上でOpenClawを直接実行することで、ローカルボリュームマウント経由でPDFや文書を読む際のレイテンシーがゼロになります。
1. 必須のRAMアップグレード
ほとんどのSynology NASは4GBまたは8GBのECC RAMで出荷されており、DSM自体を動かすのがやっとです。続ける前にRAMをアップグレードしてください。
- 互換性のあるアンバッファードECC DDR4 SODIMM RAM（例：Crucial製2×16GB）を購入。
- NASの電源を切り、ドライブトレイを取り外して新しいメモリを取り付ける。
- 起動してDSMのコントロールパネル→情報センターで新しい32GBを確認。
2. Container Managerのセットアップ
- DSMでパッケージセンターを開く。
- Container Manager（旧Docker）を検索してインストール。
- /volume1/docker内にopenclaw という名前のサブフォルダを作成。
- opneclawの中にdataとollama_models の2つのサブフォルダを作成。
3. Composeプロジェクトをデプロイ
Container ManagerでOpenClawとOllamaを管理する新しいプロジェクトを定義します。
Synologyファイアウォールについて
ルーターのポートフォワーディングでポート3000を直接インターネットに公開しないでください。OpenClawへのリモートアクセスには必ず深く認証されたリバースプロキシ（Cloudflare Zero Trust TunnelsまたはTailscale）を使用してください。
何よりも先に機種を確認する
Synologyは単一のプラットフォームではありません。エントリー向けARM機とx86のPlusシリーズの差は、「素直にできる」と「できない」の差であり、設定では埋められません。
| 機種 | Container Manager | 本記事にとっての意味 |
|---|---|---|
| x86_64（Plus、XS、多くのDS-x20+以降） | 利用可 | composeが使えます。本記事はそのまま適用できます。 |
| 新しめのDSM上の一部ARMv8機種 | 利用可 | 動作しますが低消費電力CPUです。ゲートウェイのみを動かし、モデルは別に置く想定にしてください。 |
| 旧来のエントリーARM機（Jシリーズなど） | 利用不可 | Container Managerを導入できません。本ページの内容は役に立ちません。末尾の代替案を参照してください。 |
Synologyはこの点を時間とともに変えてきました。以前はコンテナを動かせなかったARMv8機種の一部が、現行DSMでは動くようになっています。フォーラムで見つけた互換性リスト（この表も含めて）を信じるのではなく、実機のパッケージセンターで確認してください。
そのハードウェアが実際に何を提供できるか把握する
NASはディスクからバイトを動かすために作られており、計算をするためではありません。対応するx86機であってもCPUは低TDPの製品で、DSM自身のインデックス作成やスナップショット、既に動かしている他のものと共有されます。前提を置く前に、実際に空いている分を確認してください。
# SSH into the NAS and find out what you are actually working with:
uname -m # x86_64 → Container Manager is available
# aarch64 → depends on the model; check Package Center
nproc # how many cores you have to share
free -h # how much RAM is left after DSM takes its shareDSMと既存コンテナの後で `free -h` の空きがほとんどないなら、そこに言語モデルを足しても良い結果にはなりません。ゲートウェイ自体は軽量ですが、ローカルモデルはそうではありません。
# Package Center → search "Container Manager" # If it does not appear, your unit cannot run it. Stop here and # read the alternative at the bottom of this page.
これは二択の答えであり、プロジェクトの残り全体を決めます。実機のパッケージセンターで確認するのが唯一確実な方法です。
composeの書き方と、静かに失敗するCPU制限
コンテナが「動く」か「半分だけ動く」かを分ける詳細が2つあります。どちらもSynology固有で、OpenClawのドキュメントからは読み取れません。
services:
openclaw:
image: ghcr.io/openclaw/openclaw:latest
restart: unless-stopped
volumes:
# Mount state as a DIRECTORY. Never as a single file.
- /volume1/docker/openclaw:/home/node/.openclaw
- /volume1/docker/openclaw/workspace:/home/node/.openclaw/workspace
ports:
# Bound to loopback: reach it over the NAS's own VPN or an SSH
# tunnel, never by opening 18789 on the router.
- "127.0.0.1:18789:18789"ドキュメントは、ゲートウェイの状態を単一ファイルではなくディレクトリとしてマウントするよう明示しています。ポートについては、NASは家庭内で唯一すでにポート転送が設定されている機器であることが多く、だからこそエージェントのエンドポイントを軽率に公開すべきでない場所です。
# This will NOT work on a Synology kernel: # # deploy: # resources: # limits: # cpus: "1.5" # # You get: "NanoCPUs can not be set, as your kernel does not support # CPU CFS scheduler or the cgroup is not mounted" # # Use Container Manager's CPU priority (low/mid/high) instead. # It is a priority, not a cap — a busy container will still take # whatever is idle.
SynologyのカーネルにはCPU CFSスケジューラのcgroupが組み込まれていないため、composeの標準的なCPU制限構文は明確なエラーで失敗します。代替はContainer ManagerのCPU優先度設定ですが、これは上限ではなくスケジューリングのヒントです。忙しいコンテナは空き容量を消費し続けます。
NASがホストとして不適切な場合
- ✗モデルもNAS上で動かしたい場合。メモリに実際の余裕がある高性能x86機でない限り、別の場所で動くモデルを参照させてください。
- ✗Container Managerを導入できない機種の場合。ゲートウェイはRaspberry Piやミニ PCで動かし、NASの共有をSMBでマウントさせます。ストレージの利点を保ちつつ、プラットフォームと戦わずに済みます。
- ✗そのNASをバックアップに使っており、触られたくない場合。バックアップ先への書き込み権限を持つエージェントは、挙動が良くても構造として不適切です。
- ✗DSMに影響しないようCPUを制限するつもりだった場合。その制御は期待する形では存在しないため、コンテナがNAS本来の仕事と競合することを前提に見込んでおいてください。