自宅のMac miniでOpenClawを動かし始めたものの、ターミナルを閉じるとAIエージェントが止まり、再起動後には設定や接続状態の確認が必要になる。この段階で「OpenClaw Mac mini デプロイ」を調べると、原生インストールとDockerの説明が別々に見つかり、どちらを選べば長く安定して使えるのか判断しにくくなります。
OpenClawは、ファイル操作、コマンド実行、外部サービスとの接続などを継続的に扱うため、単に起動できるかだけでなく、権限、保存領域、更新方法、障害時の復旧まで設計する必要があります。本記事では、Mac miniを常駐AI Agentのホストにする場合の選択基準と、2つの構成を実際に組み立てる流れを整理します。
Mac miniとOpenClawの相性
OpenClawをMac miniに置くと、ノートPCを閉じている時間でもGatewayを稼働させ、ローカルファイルや作業ディレクトリに継続してアクセスできます。チャット経由で指示を受ける運用では、毎回アプリを起動するより、常時接続できる専用ホストの方が管理しやすくなります。
Mac miniが向いている理由は、次の3点です。
- macOS固有の権限やローカルアプリと連携しやすい
- 低消費電力の専用機として長時間稼働させやすい
- SSH、VNC、Tailscaleなど複数の接続方法を選べる
ただし、常駐運用には見落としやすい制約があります。まず、Agentに広いファイル権限を与えると、誤操作時の影響範囲も広がります。次に、APIキーや認証情報を設定ファイルと同じ場所に置くと、バックアップやログ収集時に秘密情報が流出する可能性があります。さらに、macOSのアップデート、Docker Desktopの停止、ネットワーク変更によって、再起動後にGatewayだけがオフラインになることもあります。
OpenClawの公式インストールでは、Node.js 22.22.3以上などの要件が示されています。原生環境では、Node.jsのバージョンとグローバルパスを最初に確認してください。(docs.openclaw.ai)
OpenClaw 原生インストールかDockerか
「OpenClaw 原生インストールか Docker」で迷った場合、判断軸は処理速度だけではありません。macOSのファイルや権限を頻繁に扱うなら原生版、環境を分離して再構築しやすくしたいならDockerが基本です。
原生インストールの特徴
原生版はmacOS上にOpenClawとNode.jsを直接配置します。ファイルアクセスやmacOSの権限設定が自然で、GUIアプリやローカルの開発ツールと連携する場合に扱いやすい構成です。一方で、Node.js、npm、Homebrew、環境変数など、ホスト側の状態に依存します。
アップデート後に依存関係が変わった場合、以前の状態へ戻すには手動の切り戻しが必要です。個人の検証環境には向きますが、複数人が同じ手順で再現する場合は記録を残してください。
Dockerの特徴
Dockerでは、OpenClawのGatewayをコンテナとして動かします。ホストのNode.js環境から切り離せるため、バージョン違いによる衝突を抑えられます。Composeファイルと設定ディレクトリを保存しておけば、コンテナを作り直す運用にも移行しやすくなります。
ただし、DockerはmacOSのファイル、Keychain、Bonjour、ホスト側のローカルサービスに直接アクセスする構成ではありません。公式ドキュメントでも、コンテナ内にはHomebrewがなく、依存ツールが必要なスキルは追加設定が必要と説明されています。Docker Composeでは、設定、ワークスペース、認証プロファイルをホスト側へマウントして永続化します。(docs.openclaw.ai)
| 判断項目 | 原生インストール | Docker Compose |
|---|---|---|
| 初回構築 | コマンドが少なく始めやすい | Docker DesktopとComposeが必要 |
| macOS権限 | ファイルやGUI連携が自然 | マウントと権限調整が必要 |
| 環境分離 | ホスト環境に依存 | Node.js環境を分離しやすい |
| データ保存 | ホスト上の設定を直接管理 | ボリュームまたはバインドマウントが必須 |
| 更新・ロールバック | 手動で戻す場面がある | イメージタグを固定しやすい |
| 再構築 | 手順書への依存が大きい | Composeと保存領域で再現しやすい |
| 長期運用 | macOS連携重視の個人向け | チーム運用、検証、分離重視向け |
原生版の構築手順
OpenClaw Mac mini デプロイを原生環境で始める場合は、次の順番で作業します。公式のOpenClawインストール手順も、作業前に確認しておくと安全です。
-
専用ユーザーと作業ディレクトリを準備します。
Agentに個人データ全体を見せないため、専用のmacOSユーザー、または専用ワークスペースを用意します。 -
Node.jsとパスを確認します。
bash node -v npm prefix -g echo "$PATH" -
公式インストーラーを実行します。
bash curl -fsSL https://openclaw.ai/install.sh | bash -
状態と設定を確認します。
bash openclaw --version openclaw doctor openclaw gateway status -
オンボーディングと常駐サービスを設定します。
bash openclaw onboard --install-daemon
macOSではLaunchAgentが使われるため、ターミナルを閉じてもGatewayを継続できます。公式手順では、openclaw gateway installによる導入も案内されています。(docs.openclaw.ai) -
ローカル接続を確認します。
Web UIは通常、http://localhost:18789またはhttp://127.0.0.1:18789で確認します。開けない場合は、まずプロセス、ポート、ログの順に調べてください。
注意：APIキーをシェル履歴、公開リポジトリ、共有バックアップへ保存しないでください。設定ファイルをコピーする場合は、秘密情報を除外してから移行します。
Docker Composeの構築手順
OpenClaw Docker デプロイ教程を探している場合でも、非公式イメージを無作為に使うのではなく、公式ドキュメントと公式レジストリのタグを基準にしてください。Docker DesktopとDocker Compose v2が必要で、公式ドキュメントではイメージ構築時に少なくとも2GBのRAMが必要なケースが示されています。(docs.openclaw.ai)
-
Docker Desktopを起動し、バージョンを確認します。
bash docker --version docker compose version -
OpenClawのソースを取得します。
bash git clone https://github.com/openclaw/openclaw.git cd openclaw -
公式セットアップスクリプトを実行します。
bash ./scripts/docker/setup.sh -
設定とワークスペースの保存先を確認します。
/home/node/.openclaw、/home/node/.openclaw/workspace、認証プロファイル用ディレクトリが、ホスト側の保存先へマウントされているかを確認します。コンテナを削除しても、この保存先が残っていれば設定を復元できます。 -
Composeを起動し、状態を確認します。
bash docker compose up -d docker compose ps docker compose logs -f openclaw-gateway -
Web UIとヘルスチェックを確認します。
bash curl http://127.0.0.1:18789/healthz
Compose構成では、Gatewayポートとして18789が使われ、restart: unless-stoppedによる再起動設定が利用されます。(github.com)
コンテナ構成では、ホストのlocalhostとコンテナ内のlocalhostが同じ意味になりません。ホスト側のサービスへ接続する場合は、Docker Desktopのネットワーク設定やhost.docker.internalの利用を検討します。
自動起動と安全な遠隔接続
OpenClaw 開機自啟設定では、原生版ならLaunchAgent、DockerならComposeの自動再起動を優先します。PM2はNode.jsプロセス管理に慣れているチームには便利ですが、macOSのログイン状態や権限、別の常駐管理機構と二重化しないようにしてください。
遠隔接続では、Gatewayをいきなり全インターネットへ公開しないことが重要です。まずlocalhostバインドで動作確認し、必要な場合だけTailscaleのTailnet経由に切り替えます。OpenClawの公式FAQでも、Tailnetバインドや認証トークンを使った接続方法が案内されています。(docs.openclaw.ai)
- 管理画面を公開IPへ直接バインドしない
- トークンまたはパスワード認証を有効にする
- Tailscale側の端末認証を確認する
- SSH鍵を使い、パスワードログインを必要以上に開けない
- Agent用の作業ディレクトリと個人ファイルを分離する
- 定期的に設定、ワークスペース、認証情報のバックアップを検証する
経験上、接続できないときに最初からポートを外部公開するのは危険です。
openclaw gateway status、docker compose ps、ローカルのヘルスチェックを順番に確認してから、遠隔アクセスの設定へ進めてください。
よくある障害と復旧手順
サービスが起動しない場合
原生版ではNode.jsのバージョン、PATH、LaunchAgentの状態を確認します。Dockerではイメージ構築時のメモリ不足、ポート競合、権限不整合が代表的です。
Web UIが開かない場合
まず18789番ポートを別プロセスが使っていないか調べます。次にGatewayがlocalhostだけで待ち受けているのか、コンテナ内部だけで待ち受けているのかを確認します。ブラウザーの問題と決めつけず、curlやログで切り分けます。
再起動後にAgentがオフラインになる場合
原生版はLaunchAgentが登録されているか、DockerはDocker Desktopの自動起動とComposeの再起動ポリシーが有効かを見ます。Mac mini自体の再起動後にログインが必要な設定になっていないかも確認してください。
コンテナを作り直したらデータが消えた場合
設定ディレクトリを名前付きボリュームまたはバインドマウントにしていなかった可能性があります。コンテナの内部だけに保存したデータは、コンテナ削除時に失われるため、保存先を先に固定してください。
本番運用の選択基準
個人でmacOSのファイルやGUIアプリを多用するなら、原生版から始める方がトラブルを減らせます。反対に、小規模チームで同じ環境を再現したい場合、検証版と本番版を分けたい場合、更新前にイメージを固定したい場合はDockerが有力です。
迷う場合は、最初に原生版でAgentの権限と作業フローを確認し、運用が固まった段階でDockerへ移行する方法もあります。ただし、macOSのKeychain、GUI操作、ホスト側のローカルサービスを多用するなら、無理にコンテナ化しない方が保守しやすいケースがあります。
ローカルMacとクラウドMacの判断
自宅のMac miniを使う構成には、購入費、設置場所、停電対策、回線、リモート接続の管理という負担があります。さらに、チームで共有する場合は、誰がOS更新を行うか、故障時にどの設定を復旧するかを決めなければなりません。
短期検証や遠隔チームでの常駐運用なら、SpinMacのクラウドMac構成ページで、利用地域と期間を先に確認できます。SpinMacでは専用のMac mini M4をSSHやVNCで利用でき、標準構成は10コアCPU、16GBメモリ、256GB SSD、1Gbps専用帯域です。(spinmac.com)
料金や期間を比較するときは、単価だけでなく、初期設定時間、故障時の交換、固定IP、遠隔接続、データ消去の運用まで含めて判断してください。SpinMacの料金ページでは、日額、週額、月額、四半期の選択肢と、SSD拡張やTB5接続のオプションを確認できます。(spinmac.com)
OpenClaw クラウドMacデプロイへ移行する場合は、次の順序が安全です。
- 現在の設定、ワークスペース、秘密情報を棚卸しする
- APIキーを新しい環境へ直接コピーせず、必要なら再発行する
- SSHまたはVNCで接続し、macOSとDockerの状態を確認する
- 原生版またはDocker Composeのどちらで構築するか決める
- localhost、認証、Tailscale、常駐設定を順番に確認する
- Agentのファイル権限とログ保存を最小限に設定する
- 再起動テストとバックアップからの復元テストを行う
自宅のWindows環境や共有VPSで長期運用する方法もありますが、macOS固有の権限、GUI連携、Apple Silicon向けの作業を重視するなら、互換レイヤーや仮想化の追加管理が負担になります。常時稼働する専用Macをすぐに用意したい場合は、SpinMacのクラウドMacサービスを候補に入れ、必要な期間と接続方式を確認してから構築を始めると、購入前の検証コストを抑えやすくなります。