# OpenClaw のデプロイ方法：ローカルのソース導入と Docker はどう選ぶべきか

> Canonical: https://vxi.me/ja/posts/openclaw-docker-vs-source-deployment/
> Locale: ja-jp
> Published: 2026-03-27
> Updated: 2026-03-27
> Markdown: https://vxi.me/ja/posts/openclaw-docker-vs-source-deployment.md

OpenClaw をまず動かしたいだけなら、最初につまずきやすいのはインストールコマンドではなく、**最初にどの導入ルートを選ぶか**です。

自分の PC に入れるのか、クラウドサーバーへ置くのか。ソースから入れるのが一番正しいのか、それとも Docker の方が簡単なのか。選択肢だけを見ると複雑に見えますが、実際には「今すぐ使いたいのか」「自分で実装や運用まで管理したいのか」を先に決めればかなり整理できます。

OpenClaw の README と Docker ドキュメントを見直した結果、私はこの二つを分けて考えるようになりました。

**普通に使い始めたいなら CLI。サーバーで長期運用するなら Docker。ソース導入は実装まで触る人向け。**

## 手元の PC でまず試すなら CLI が一番軽い

公式 README の新規ユーザー向けルートは、Node 24、少なくとも Node 22.16+ の環境で CLI を入れて onboarding を進める形です。

```bash
npm install -g openclaw@latest
openclaw onboard --install-daemon
```

この流れは「開発環境を構築する」というより、「OpenClaw を使い始める」ための入口です。

CLI を入れ、onboarding に従って Gateway と初期設定を進めればよく、最初からプロジェクト全体の build 手順を理解する必要はありません。

一方、ソースから入れる場合は話が変わります。

公式の流れでは、リポジトリを clone し、`pnpm install`、`pnpm ui:build`、`pnpm build` を行い、その後 `pnpm openclaw onboard --install-daemon` や `pnpm gateway:watch` を使います。

つまり、ソース導入は「より完全なインストール方法」ではなく、**コードを読む、変更する、デバッグする、リポジトリの更新に追従する人向けの開発ルート**です。

普通に試したいだけなら、Node バージョン、依存関係、UI build、更新時の互換性まで自分で背負う必要はありません。

## Docker はインストール方法よりデプロイ方法に近い

Docker も、使えば必ず簡単になるわけではありません。

OpenClaw の公式 Docker ドキュメントでも Docker は optional とされています。ローカル PC で一度試したいだけなら、Docker Desktop / Docker Engine、Compose v2、ビルド用メモリなど別の前提が増えます。

公式ドキュメントでは、イメージビルド時に十分なメモリがないと `pnpm install` が落ちる可能性も案内されています。

そのため、自分の PC では CLI の方が低摩擦なことが多いです。

逆に、Linux サーバー上で Gateway を長期稼働させるなら Docker はかなり自然です。

- 実行環境をコンテナに閉じ込められる
- 別ホストへ移しやすい
- 再作成の手順を固定しやすい
- サーバー上の他サービスと分離しやすい

公式の Docker フローも単純な `docker run` 一行ではなく、リポジトリ直下のセットアップスクリプトを使う形です。

```bash
./scripts/docker/setup.sh
```

ローカルビルドを避けて事前ビルド済みイメージを使うなら、例えば次のようにします。

```bash
export OPENCLAW_IMAGE="ghcr.io/openclaw/openclaw:latest"
./scripts/docker/setup.sh
```

このセットアップがイメージ、onboarding、`.env`、Docker Compose の起動まで面倒を見ます。

ここからも、Docker が「OpenClaw を初めて触るための最小インストール」というより、**Gateway をサービスとして配置するための運用ルート**だと分かります。

## 私ならこう選ぶ

### 自分の PC で今日から使いたい

公式 CLI から始めます。

```bash
npm install -g openclaw@latest
openclaw onboard --install-daemon
```

最初からソースを clone する必要はありません。

### クラウドの Linux サーバーで常時動かしたい

Docker を優先して確認します。

サーバー上では、コンテナ化による再作成性や環境分離の利点が大きくなります。

ただし、Docker を選んでも運用がなくなるわけではありません。

- 永続データ
- ポート
- health check
- イメージ更新
- Gateway の公開範囲
- firewall

こうした部分は引き続き管理が必要です。

公式ドキュメントに `healthz`、`readyz`、`lan`、`loopback` などが出てくることからも、Docker ルートが運用者向けであることが分かります。

### コードを読みたい、改造したい

ソース導入を選びます。

この場合は build 手順まで含めて自分が管理することに意味があります。

透明性が高く、実装に近い一方、依存関係や開発スクリプトも日常の保守対象になります。

## よくある選び方の失敗

一つ目は、ソース導入を「一番正式なインストール方法」だと思ってしまうことです。

利用だけが目的なら、開発環境まで持つことで初期コストが増えます。

二つ目は、Docker を「必ず簡単になる方法」と考えることです。

特にローカル PC では、コンテナ環境そのものが追加のハードルになる場合があります。

三つ目は、Node のバージョンなどランタイム要件を軽く見ることです。

最初の前提がずれていると、その後のエラーがすべて派生問題になります。

最後に、サーバー上で動いた時点で終わりだと思わないことです。長期運用では、コンテナよりもデータと設定の復旧方法の方が重要になります。

OpenClaw をサーバーへ置くなら、バックアップの入口も最初から作っておいた方が楽です。[Docker Volume を GitHub に自動バックアップする構成](/ja/posts/docker-volume-backup-github-sync/) は、そのための軽量な一例です。

結局、OpenClaw には一つの正解ルートがあるのではなく、目的別に複数の入口があります。

**まず使うなら CLI、サーバーに置くなら Docker、実装を触るならソース。**

この三つを混ぜなければ、導入判断はかなり簡単になります。

## 関連資料

- [Docker Volume を GitHub に自動バックアップする：1Panel 向けの低コスト復旧構成](/ja/posts/docker-volume-backup-github-sync/)
- [デプロイのテーマページ](/ja/topics/deployment/)
- [OpenClaw 公式 README](https://github.com/openclaw/openclaw)
- [OpenClaw Getting Started](https://docs.openclaw.ai/start/getting-started)
- [OpenClaw Docker ドキュメント](https://docs.openclaw.ai/install/docker)