SSD Nodes Learn
ガイド Matt Connor著者 Matt Connor ・更新日 2026-07-24

OpenClawをVPSで安全に運用する方法

OpenClawはシェル操作やブラウジングを行うため、設定ミスは致命的なリスクになります。CVE-2026-32922のような脆弱性への対策として、unprivileged userの作成やfirewallの設定、systemdによる管理など、VPS上で安全に動作させるための具体的な手順を解説します。

OpenClawとは何か、そしてなぜ最初に要塞化(Harden)すべきなのか

OpenClawはセルフホスト型のAIエージェントです。自身のサーバーで実行し、大規模言語モデル(LLM)に接続することで、シェルコマンドの実行、ブラウザの制御、ファイルの読み書き、チャットアプリ経由のメッセージへの対応が可能になります。この広範な権限こそがツールの目的ですが、同時に最大の懸念事項でもあります。あらゆるコマンドを実行できるエージェントの安全性は、実行環境のセキュリティと、設定する制限に完全に依存します。

このガイドの前提となる事実が2つあります。第一に、OpenClawはユーザー自身によって要塞化されるように設計されています。そのセキュリティモデルは、ツールポリシーの厳格化、サンドボックス化、および慎重な権限設定の責任を、デフォルト設定ではなくオペレーターに課しています。第二に、このプロジェクトはすでに重大なセキュリティ事象を経験しています。2026年3月、4日間で9件のセキュリティ問題が公開されました。その中には、深刻度9.9/10の権限昇格の脆弱性(CVE-2026-32922)も含まれていました。これらの事実がOpenClawの使用を避けるべきであることを意味するわけではありません。単に、安易な設定で実行すべきではないという意味であり、本ガイドはそのための慎重な手順を示します。

良いニュースもあります。OpenClawはすでに1つの安全な選択をデフォルトで提供しています。すべての制御を行う単一のプロセスであるgatewayは、デフォルトでloopbackアドレスで待機するため、意図的に公開しない限りインターネットから到達されることはありません。以下の作業の大部分は、この状態を維持し、万が一問題が発生した場合の被害範囲(blast radius)を限定することに焦点を当てています。

OpenClaw専用の権限のないユーザーを作成する

エージェントをrootとして実行しないでください。OpenClawをrootで実行している際に、バグ、誤った指示、あるいは前述のようなCVEが発生した場合、被害に上限はなくなります。ログインシェルを持たず、sudo権限も持たない専用のシステムユーザーを作成し、そのユーザーとしてエージェントを実行してください。

sudo useradd --system --home /opt/openclaw --shell /usr/sbin/nologin openclaw

OpenClawが所有するすべての要素は /opt/openclaw の下に配置され、そのアカウントによって管理されます。これが最も重要なステップです。これは unprivileged userとしてサービスを実行する ことと同じ原則です。エージェントが実行されるアカウントが、そのエージェントが破壊できる範囲の限界となります。

OpenClawのインストール

OpenClawはnpmパッケージとして配布されています。サーバーにNode.jsがインストールされていない場合は、まずNode.jsをインストールしてください。パッケージをグローバルにインストールすると、すべてのユーザーのPATHに openclaw バイナリが追加されます。その後、一度限りのオンボーディングステップを実行します。

sudo npm install -g openclaw@latest
sudo -u openclaw openclaw onboard

オンボーディングを openclaw ユーザーとして実行すると、エージェントの設定はrootではなく、そのホームディレクトリである /opt/openclaw に保存されます。また、プロジェクトは1行で同様のインストールを行う curl -fsSL https://openclaw.ai/install.sh | bash インストーラーも提供しています。オンボーディング中に --install-daemon フラグは使用しないでください。これを使用するとOpenClaw自身のサービスが登録されますが、後述する構築するsystemdユニットの方がより厳格です。

Gatewayをloopbackに留め、ファイアウォールの背後に置く

gatewayはデフォルトで 127.0.0.1 にバインドします。そのままにしておいてください。そのポートをインターネットに公開する必要性はほとんどありません。公開してしまうと、ポートを見つけた者に、コマンドを実行し続けるプロセスへのリモートアクセス経路を与えることになります。

誤って何もかもが公開されないよう、サーバーの前にデフォルト拒否(default-deny)のファイアウォールを設置してください。

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

ここで避けるべき2つの罠があります。IPv4のみをカバーするファイアウォールは、IPv6では同じサービスが完全に公開されたままになる可能性があります。これは多くの人が陥る IPv6 firewall gap です。また、ノートPCからgatewayにアクセスする必要がある場合でも、ポートを開けないでください。VPNまたはSSHトンネル経由でアクセスし、エージェントがオープンなインターネットからの接続を待機しないようにしてください。

シークレットを隔離する

OpenClawは、接続する言語モデルのAPIキーを必要とします。そのキーは資金を消費させ、エージェントを通じてあなたの代理で行動する可能性があるため、パスワードと同様に扱ってください。ユニットファイルやリポジトリには書き込まないでください。OpenClawユーザーのみが読み取れるファイルに保存してください。

sudo install -o openclaw -g openclaw -m 600 /dev/null /opt/openclaw/openclaw.env
sudoedit /opt/openclaw/openclaw.env      # add ANTHROPIC_API_KEY=... or your model provider's key

systemdユニットは EnvironmentFile を使用してそのファイルをロードするため、キーがコマンドライン、ログ、またはシェルの履歴に残ることなくプロセスに渡されます。

強化されたsystemdサービスとして実行する

エージェントをsystemdの下で実行すると、自動再起動、journalctl によるクリーンなログ、そして最も重要な点として、プロセスが侵害された場合でも接触できる範囲を狭めるカーネルレベルのサンドボックスオプションを利用できます。エージェントにとって最も重要なオプションは、新しい権限の取得を防ぐ NoNewPrivileges、書き込みを許可した場所以外のファイルシステムを読み取り専用にする ProtectSystem=strict、隔離された一時ディレクトリのための PrivateTmp、およびホームディレクトリを読み取らせないための ProtectHome です。

ここで完全な要塞化済みユニットを生成し、/etc/systemd/system/openclaw.service にコピーしてください。

ToolGenerate a hardened systemd unit for the agent

このユニットは、エージェントを制御する長時間実行プロセスである openclaw gateway を起動します。もし which openclaw がサーバー上で異なるパスを示している場合は、ExecStart をそれに合わせて調整してください。これらのディレクティブ、および daemon-reloadenable --now の詳細な解説は running a program as a systemd service にあります。ユニットを貼り付けた後の短い手順は以下の通りです。

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw

フロントドアも要塞化する

エージェント用サーバーの安全性は、周囲のサーバーの安全性に依存します。仕上げとしてあと2つのレイヤーを追加します。VPSでのSSH要塞化 と同様に、SSHを鍵認証のみに設定し、rootログインを禁止してください。これにより、管理用アカウントがブルートフォース攻撃を受けるのを防ぎます。次に、公開ポートを叩くスキャナーを排除するために Fail2ban を追加してください。これらはOpenClawに直接干渉するものではありませんが、攻撃者がOpenClawに到達するために使用する経路を遮断します。

意図的にアップデートを継続する

2026年3月の脆弱性公開は、常に最新の状態を保つべきであることを明確に示しています。エージェントにおける権限昇格のバグは、通常のWebアプリよりもはるかに深刻です。なぜなら、エージェントはすでにコマンドを実行しているからです。プロジェクトのリリースを監視し、セキュリティアップデートを迅速に適用してください。OpenClawのアップグレードは、後回しにするものではなく、ルーチンメンテナンスとして扱ってください。

実際に何を要塞化しているのかを理解するには、OpenClawスタイルのエージェントのアーキテクチャ が構成要素を解説しており、VPSで独自のAIエージェントを構築する がエージェント全般の構成について説明しています。

FAQ

公開VPSでOpenClawを実行するのは安全ですか?

要塞化を行えば安全になり得ます。OpenClawは設計上強力です。シェルコマンドを実行しブラウザを制御するため、不注意な設定は非常に危険です。実際に重大なCVE(2026年3月のCVE-2026-32922)が発生しています。そのセキュリティモデルは、オペレーターが制限を追加することを前提としています。権限のないユーザーとして実行し、gatewayをloopbackに留め、デフォルト拒否のファイアウォールの背後に置き、APIキーを隔離し、強化されたsystemdサービスとして実行してください。

OpenClawのgatewayをインターネットに公開すべきですか?

いいえ。gatewayはデフォルトでloopbackにバインドされており、そのままにしておくべきです。gatewayはエージェントを制御する単一のプロセスであるため、公開されたgatewayは、コマンドを実行し続けるものへのリモートアクセス経路となります。リモートからアクセスする必要がある場合は、ポートを開けるのではなく、VPNまたはSSHトンネルを使用してください。

OpenClawはどのユーザーで実行すべきですか?

ログインシェルを持たず、sudo権限のない専用のシステムユーザーです。絶対にrootで実行しないでください。エージェントが侵害された場合、そのユーザーアカウントが被害の限界となります。そのため、そのアカウントは /opt/openclaw のようなディレクトリ内の自身のファイルのみを所有すべきであり、それ以外のものは所有すべきではありません。

OpenClawのAPIキーの安全性をどう保てばよいですか?

OpenClawユーザーのみが読み取り可能なファイル(モード600)に保存し、systemdの EnvironmentFile を使用してサービスにロードしてください。キーはユニットファイル、シェルの履歴、およびGitリポジトリには含めないでください。漏洩の疑いがある場合は、直ちにローテーションしてください。