2026年 OpenClaw インストール経路はどう選ぶ？公式 install.sh・npm・Docker Compose の比較意思決定＋ヘッドレス Mac の SSH トラブルシュート

TL;DR — 最初にレーンを決める

専用サーバー用途の Mac へのデフォルト推奨：上流の想定に一番近いのは 公式 install.sh から入るルートです。「自分のノートでは動いた」系のギャップを減らしやすいです。

npm を選ぶ条件： Node バージョンを素早く切り替えたい、ユーザー単位で隔離したい、ホスト側で nvm／fnm を標準化している、といった場合。

Docker Compose を選ぶ条件： スタックの再現性、影響範囲の制御、他コンテナと同居させたい——が優先で、macOS 上のボリューム・権限・ネットワークという「もう一段の運用コスト」を許容できる場合。

リモート mini で長期運用する前提なら、再起動やキューとインストール選択の関係は OpenClaw ＋ SSH での無人自動実行 もあわせて読むと整理しやすいです。

「インストール経路」とは何を指すか

2026 年時点では、多くのチームが次の 4 つをセットで決めています。

• 配布チャネル： シェルブートストラップ（install.sh）、パッケージマネージャ（npm）、イメージ（docker compose）。
• 所有権： システム全体か単一 macOS ユーザーか——SSH と launchd ジョブで効いてきます。
• 状態の置き場： 設定・資格情報・キャッシュ・ログをどこに置くか（ホーム、/usr/local、名前付きボリュームなど）。
• アップグレードの物語： ワンコマンド更新、semver 固定、イメージダイジェスト固定のどれで回すか。

ここがズレると「ターミナルでは動くのに SSH だと動かない」——特に非対話シェルでは典型の原因になります。

選択肢 A — 公式 install.sh

利点

• メンテナ側が最も検証しやすい経路に近く、ドキュメント外の角が少なめ。
• 新規の Mac mini ビルドノードのように、パスと前提を一気に揃えやすい。
• 運用引き継ぎが簡潔：「公式インストーラ実行 → 自社設定レイヤを当てる」で済みやすい。

トレードオフ

• 組織端末では昇格権限や手動承認が必要になることがある。
• Node／npm のパッチまでピン留めしたい場合は、自前のガードレールが別途欲しくなる。

選択肢 B — npm（グローバル／プロジェクトスコープ）

利点

• nvm などで Node を管理していると、前進・ロールバックが速い。
• 同一 Mac 上の別ユーザーでバージョンを分けやすいマルチテナント向き。
• 他の JS CLI と同じ運用パターンに乗せられる。

トレードオフ

• SSH セッションが GUI のターミナルと別プロファイルを読むと、別の Node に乗りやすい。
• グローバルインストールはドリフトしがち。サポートする Node LTS と lockfile を文書化する。

選択肢 C — Docker Compose

利点

• ステージングと本番相当の mini でも同じ compose で再現しやすい。
• リソース上限やネットワーク方針をファーストクラスで扱える——ビルドや他エージェントと同居するときに有効。
• IaC とダイジェスト固定のイメージ運用と相性が良い。

トレードオフ

• macOS のファイル権限とボリュームマウントは初回だけでなくリストア時も要検証。
• Docker Desktop／Colima など、別デーモンのパッチサイクルが増える。

意思決定マトリクス（クイック）

ヘッドレスなリモート Mac ＋ SSH のトラブルシュート

OpenClaw 本体の不具合と決めつける前に、次を順に潰してください。ヘッドレス CI ラボ全般の落とし穴は SSH 経由リモート Mac mini のヘッドレス実践ガイド でも触れています。

• リモートログイン： 対象ユーザーで SSH が有効か、ローカル専用アカウントと混同していないか。
• 非対話 PATH： GUI ターミナルと ssh user@host 'which node' で which node／which docker を突き合わせ、~/.zprofile、~/.zshenv、または launchd の EnvironmentVariables で揃える。
• セッション種別： バックグラウンドエージェントはログインコンソールや Launch Agent の設計が要る場合があり、純 SSH では GUI のキーチェーンと同じ挙動にならない。
• スリープ／Power Nap： 無人ホストではスリープ無効化。pmset が SLA と一致しているか。
• フルディスクアクセス／TCC： Desktop 等に触れるツールは、SSH から起動したバイナリに承認が無いことがある。プライバシー設定を確認。
• Docker コンテキスト： SSH 越しの CLI が、手元と同じエンジンを指しているか（docker context ls）。
• ファイアウォール・Tailscale／VPN： 受信ルール、サブネット、スプリット DNS。古い経路が「ダウン」の誤認になりがち。
• ディスク／inode： compose ログやモデルキャッシュで小型 SSD が静かに満杯になる。
• 時刻ずれ： TLS が謎失敗しがち。NTP を有効にする。

このスタックに macOS と Mac mini が向く理由

OpenClaw 型の自動化は、権限が読みやすい本物の Unix ホスト、予測しやすい消費電力、そして SSH・コンテナ・開発ツールチェーンへの第一級サポートがあると楽になります。Mac mini M4 は Apple Silicon の性能に加え、待機電力がおおよそ 4W 級に抑えやすく、夜間もファン音や熱スロットリングを気にしにくいエージェント用ホストになります。Gatekeeper、SIP、FileVault といった枠組みと、クロス OS ワークステーションで起きがちな「環境の二重化」を避けられる点も、ヘッドレス障害の切り分けを短くします。

同じインストール経路を数ヶ月「地味に」維持したいなら、都度作り直す VM より専用ベアメタルの方が、ドライバ驚きやディスク／秘密の所在が明瞭で、小規模チームの運用負荷も下がりやすいです。

上記のガイドを、常時オン前提の静かな筐体に載せたい場合は、SSHMac の Mac mini プランで構成を確認できます。