鍵やローカルファイルを晒さずに OpenClaw をプライベート VPS で動かす方法

OpenClaw を安全に動かすにはどうすればよいか

OpenClaw を現実的に安全に動かす一番よい方法は、日常使いのノート PC ではなくプライベート VPS に載せ、API キーをサーバー側の環境変数で管理し、受信アクセスを絞り、エージェントが触れるファイル・ツール・チャネルを必要最小限にすることです。こうしておくと、スキル、MCP サーバー、プロンプトインジェクション、メッセージ連携のどれかが想定外に振る舞っても、被害範囲をかなり狭められます。

OpenClaw は、セルフホスト型でマルチチャネルな AI エージェント運用に向いた設計です。その柔軟さこそ魅力ですが、同時に「どこで動かすか」が利便性ではなくセキュリティ上の判断になります。

なぜノート PC で直接動かさない方がよいのか

個人の MacBook やデスクトップで OpenClaw を動かすと、試すだけなら早いです。ただし、高信頼の人間用データと高権限のエージェント実行系が同じ OS 上に混ざります。

典型的なローカル運用リスク:

• 個人 SSH キーが同じ端末にある
• ブラウザセッションや保存 Cookie が OS ユーザーから見える
• Downloads、Desktop、Documents、ソースリポジトリに意図せず届く
• 仕事用と私用のチャネル連携が混ざる
• 追加ツールやコミュニティスキルを急いで入れると分離が弱くなる

デモならローカルでも構いませんが、継続運用ならプライベート VPS の方がきれいです。

より安全な OpenClaw アーキテクチャとは

専用ホスト、分離した秘密情報、狭いネットワーク公開を基本にします。

レイヤー	推奨	なぜ重要か
Compute	専用 VPS またはプライベート VM	エージェントを普段使いの端末から切り離すため
Secrets	環境変数またはシークレットマネージャー	リポジトリにキーを書かないため
Network	SSH 以外は既定で閉じる	公開面を最小限にするため
Storage	専用作業ディレクトリだけを使う	触ってよい範囲を明確にするため
Integrations	必要なチャネルとツールだけ接続	不正プロンプト時の影響範囲を縮めるため
Models	Gateway または固定 provider 設定経由	監査とキー更新を簡単にするため

Your Phone / Slack / Telegram
            |
            v
        OpenClaw
            |
            v
   Private VPS or VM boundary
            |
   +--------+--------+
   |                 |
   v                 v
Allowed tools     Model gateway
and MCP servers   or provider APIs

Step 1: まずはまっさらなプライベートサーバーを用意する

OpenClaw 専用の Linux VPS を新規に用意します。個人バックアップや別の本番アプリ、社内 DB と雑に同居させない方が安全です。

最低ライン:

• 新規の Ubuntu か Debian
• 非 root の管理ユーザーを 1 人作る
• SSH 鍵認証のみ
• Firewall を有効化
• セキュリティ更新を自動化

adduser claw
usermod -aG sudo claw

mkdir -p /home/claw/.ssh
chmod 700 /home/claw/.ssh

ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw enable

GetClaw のような専用 AI ホストを使う場合は、もともと AI 用に専有された基盤なのでこの初期整備が少し楽になります。

Step 2: OpenClaw は専用ディレクトリに入れる

ホームディレクトリ配下に雑然と置かず、専用パスへ隔離します。

sudo mkdir -p /opt/openclaw
sudo chown claw:claw /opt/openclaw

cd /opt/openclaw
git clone https://github.com/openclaw/openclaw.git .

自律型エージェントは、ログ、ツール、一時ファイル、メモリをすぐ増やします。木を一本にまとめておくと監査もバックアップも楽です。

Step 3: API キーをリポジトリに置かない

API キー、Bot トークン、Webhook シークレット、セッショントークンを Git 管理下の .env サンプルに混ぜないでください。サーバー側で保管して実行時に読む形にします。

sudo mkdir -p /etc/openclaw
sudo chmod 700 /etc/openclaw

sudo tee /etc/openclaw/openclaw.env >/dev/null <<'EOF'
OPENAI_API_KEY=replace_me
ANTHROPIC_API_KEY=replace_me
SLACK_BOT_TOKEN=replace_me
TELEGRAM_BOT_TOKEN=replace_me
EOF

sudo chmod 600 /etc/openclaw/openclaw.env
sudo chown root:root /etc/openclaw/openclaw.env

最低限これくらいは必要です。既存のシークレットマネージャーがあるなら、もちろんそちらの方が良いです。

Step 4: エージェントが触れる範囲を絞る

OpenClaw はマシン全体を触れなくても役に立ちます。用途ごとに明示的な作業ディレクトリを作り、そこだけに触らせます。

mkdir -p /opt/openclaw/workspace
mkdir -p /opt/openclaw/logs
mkdir -p /opt/openclaw/data

逆に、次のものは極力見せない方が安全です。

• 個人ホームディレクトリ
• 不要な共有ドライブ
• 本番用 SSH キー
• ブラウザプロフィール
• パスワード管理データのエクスポート

届くものが少ないほど、事故は小さくなります。

Step 5: 本当に必要なチャネルだけつなぐ

OpenClaw は Slack、Telegram、WhatsApp、Discord など多くのチャネルに対応できます。だからといって初日から全部つなぐ必要はありません。

安全寄りの順序:

1. まず社内チャネル 1 つから始める
2. プロンプト、権限、ログを確認する
3. 2 つ目のチャネルは安定してから追加する
4. 外部公開チャネルは最後に回す

入り口を増やしすぎないことが、最初の安全策です。

Step 6: MCP サーバーとコミュニティスキルを信頼境界として扱う

MCP は便利ですが、同時に 被害範囲 を広げやすい場所でもあります。

有効化前に確認すること:

• どのコマンドや API を呼べるか
• 読み取り専用か書き込み可能か
• どの資格情報を持つか
• 公開インターネットへ出られるか
• 意図しないローカルファイルへ届かないか

2026 年時点では、MCP の安全性は完全に「導入の仕方」に依存します。まず読み取り専用から始め、必要が証明されたものだけ拡張するのが無難です。

Step 7: process manager の背後で動かす

ターミナルタブにぶら下げたままにせず、サービスとして管理します。

[Unit]
Description=OpenClaw
After=network.target

[Service]
User=claw
WorkingDirectory=/opt/openclaw
EnvironmentFile=/etc/openclaw/openclaw.env
ExecStart=/usr/bin/npm run start
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable openclaw
sudo systemctl start openclaw
sudo systemctl status openclaw

これで、閉じ忘れたターミナルに運用を依存しなくて済みます。

Step 8: 複数プロバイダーを使うなら Gateway を入れる

複数のモデル事業者を使うなら、秘密情報とプロバイダー固有設定を各所に散らさず、専用 Gateway で吸収する方がきれいです。

Gateway を入れる利点:

• キーのローテーション
• 利用状況の追跡
• プロバイダー間フェイルオーバー
• リクエスト形式の統一
• 監査境界の明確化

実運用前チェックリスト

• OpenClaw が専用 VPS / VM で動いている
• SSH は鍵認証のみ
• Firewall は既定で受信拒否
• 秘密情報はリポジトリ外にある
• エージェントのアクセス範囲が専用ディレクトリに限定されている
• 接続チャネルは必要最小限
• MCP は可能な限り読み取り専用から始めている
• ログを中央で確認できる
• モデルアクセスは制御された 1 経路に集約されている
• バックアップ対象に不要な秘密情報を混ぜていない

自前サーバーではなく GetClaw を使うべき場面

自己管理の自由は欲しいが、一般的なサーバー初期構築に時間をかけたくないなら、私有 AI ホストを使う方が速いです。

GetClaw が向くのは次のようなケースです。

• 共有ホストではなく専用 AI 基盤が欲しい
• OpenClaw、MCP、ローカルモデルを root 権限で扱いたい
• 同じ環境にマルチモデル Gateway も置きたい
• 個人端末よりきれいなセキュリティ境界が必要

結論

OpenClaw が強力なのは、ツール、チャネル、モデルをまたいで動けるからです。だからこそ、日常の鍵やファイルやブラウザセッションを持った端末に気軽に置くべきではありません。

安全な基本形は単純です。プライベート VPS でホストし、秘密情報はサーバー側に置き、ファイルアクセスを絞り、連携を限定し、MCP やスキルを信頼判断として扱うこと。それだけで、セルフホストの利点を維持しながら、端末を最弱リンクにしにくくなります。

専用環境から始めたいなら、GetClaw のプライベート AI クラウド と マルチモデル Gateway を組み合わせるのが分かりやすい出発点です。

FAQ

OpenClaw はノート PC より VPS の方が安全ですか？

多くの場合は安全です。プライベート VPS の方が、影響範囲、ネットワーク制御、秘密情報の整理がしやすくなります。

完全セルフホストと管理付き環境のどちらを選ぶべきですか？

境界と制御を重視するならセルフホストです。手間を減らしたいなら、私有環境を管理してくれるサービスが向いています。

一番大きな OpenClaw のセキュリティミスは何ですか？

普段使っている端末上で、SSH キー、ブラウザセッション、個人ファイル、広いローカル権限と同居させることです。

出典とメモ

• OpenClaw はメッセージチャネルと私有ワークフローをつなぐセルフホスト型エージェントとして位置付けられています。
• 本記事のリスク整理は、2026 年の MCP、ブラウザツール、チャネル統合を含むエージェント運用を前提にしています。
• 関連記事: OpenClaw の紹介、MCP セキュリティ、Public AI API・BYOK・Self-Hosted Models