OpenClawとは何か――チャットで話しかけるとPCが実際に動くAIエージェント基盤
結論から言うと、OpenClawはサーバー上で常時稼働させるAIエージェントの「ゲートウェイ(中枢)」です。TelegramやDiscordといった日常のチャット経由で話しかけると、あらかじめ登録しておいたPC(OpenClaw用語でいうノード)の上で、ファイルの検索・整理、コマンドの実行、定型作業などをエージェントが実際に手を動かして行ってくれます。返答だけが返ってくるAIチャットとの一番の違いは「自分のPCの状態を読み、変更できる」点です。
なぜこれが便利なのか。普段使いのAIに「この前書きかけのメモ、デスクトップにあるやつの続きをまとめて」と頼んでも、AIにはあなたのデスクトップが見えません。OpenClawは操作を任されたPCの上でシェルやファイルシステムを扱えるため、この種の依頼が完結します。しかもゲートウェイをVPSに置けば、依頼の受け口が24時間生きていて、出先のスマホからでも自宅PCに指示を出せます。
構成の自由度も大きいです。OpenClaw本体はモデルに依存しない作りで、設定ファイルで利用するLLMプロバイダを差し替えられます。わが家では月額数百円のVPS1台でゲートウェイを動かし、操作対象のPCは自宅のUbuntuデスクトップとMacという構成にしました。
具体例を1つ。出張先のホテルで「昨日の夜に回したエンコードのログ、Ubuntuの方のホーム以下で探いて失敗してたら再実行して」とTelegramに送ると、数分で該当ログの抜粋と再実行の結果が返ってきました。SSHクライアントを開いてIPアドレスを思い出す必要も、鍵を持ち歩く必要もありません。この体験が本連載の主題です。
なぜゲートウェイをVPSに置くのか――常時稼働と役割分担の理由
結論はシンプルで、OpenClawの心臓部であるゲートウェイは「いつでも起きていて、どこからでもアクセスできる場所」に置くのが最も効果的であり、その条件を月数百円で満たしてくれるのがVPSです。操作される側のノードPCは自宅に置いたままで構いません。
[画像挿入:全体のアーキテクチャとデータの流れが分かる図]
理由を掘り下げます。自宅のデスクトップPCにゲートウェイを置く場合、(1)PCがスリープすると指示を受けられない、(2)外出先からアクセスするにはポート開放やDDNSの工夫が要る、(3)PCを買い替えるたびに引っ越し作業が発生する、という3つの障害があります。VPSならこの3つが一気に解消します。ゲートウェイはVPS側で眠らず、ノードPCとは必要なときだけ接続を張ればよい。スマホとノードPCの間に「いつも稼働している中継点」ができるイメージです。
セキュリティ面でも利点があります。ゲートウェイとノードが分離しているため、チャットとの窓口となるポートはVPS側に一本化でき、ノード側には外向きの待ち受けポートを一切作らずに済みます。ノードからゲートウェイへ能動的に接続しに行く方向の通信になるため、自宅回線に到達可能な入口をさらす必要がありません。
VPSへのインストール手順――Node.jsの準備から初回起動まで
手順の全体像は「①Node.jsを入れる ②npmでopenclawをインストール ③オンボーディングで初期設定 ④systemdに登録して常時起動」の4ステップです。OSはUbuntu 24.04 LTSを想定し、手元の環境では全体で30分程度で完了しました。
まず前提の準備です。OpenClawはNode.js製なので、Node.js 22系(LTS)とnpmを入れます。加えて、ufwを使っている場合はSSH以外の穴を開けない状態を保っておくことをおすすめします(後述のとおり、ゲートウェイの管理ポートは直接公開しない構成にするため)。
# Node.js 22(LTS)をインストール
sudo apt-get update
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt-get install -y nodejs
node -v # v22.x.x と表示されればOK
# OpenClaw本体をグローバルインストール
npm install -g openclaw@latest
openclaw --version
次にオンボーディングです。`openclaw onboard` を実行すると対話形式のウィザードが始まり、利用するLLMプロバイダとAPIキー、接続するチャットチャンネル(Telegramのbotトークンなど)を順に聞かれます。迷うのはチャンネル選択くらいで、他は案内に従うだけで設定ファイルが書き込まれます。セットアップ内容は後から設定ファイルを直接編集して変更できるため、完璧を目指さずまず一通り進めるのがコツです。
ゲートウェイのセキュリティ固め――トークン認証・ポート・systemdサービス化
結論から言うと、公開サーバーでエージェントを動かす際の基本は「①長いトークンで認証する ②管理ポートはlocalhostなど限定された経路からだけ触る ③プロセスはsystemdに任せて落ちても自動復旧する」の3点です。OpenClawにPC操作を任せる以上、ここは手を抜かないのが鉄則です。
[画像挿入:通信経路とセキュリティ層の構成が分かる図]
通信経路の設計です。OpenClawの管理画面やAPI向けポートを直接0.0.0.0で公開するのではなく、リッスンをローカルに限定したうえで、リバースプロキシ(Caddyやnginx)でTLSを終端して外に出す構成が定石です。Caddyならドメインを指定するだけで証明書の取得と更新まで自動なので、初めてでも扱いやすいでしょう。エージェントへの認証はゲートウェイが発行する長めのトークン(JWT)を使い、短い推測可能な文字列は避けます。
# トークンを発行(表示された文字列を安全に保管)
openclaw gateway --token
# Caddyでリバースプロキシを設定する例(Caddyfile)
# gateway.example.com {
# reverse_proxy 127.0.0.1:18789
# }
続いてsystemdユーザーサービス化です。わが家ではゲートウェイをsystemdのユーザーサービスとして登録し、ログアウト後も動き続けるようlingerを有効化して運用しています。ユニットファイルはごくシンプルで、次のとおりです(ExecStartのパスは `which openclaw` の結果に合わせてください)。
# ~/.config/systemd/user/openclaw.service
[Unit]
Description=OpenClaw Gateway
After=network-online.target
[Service]
ExecStart=/usr/bin/openclaw gateway
Restart=on-failure
RestartSec=5
[Install]
WantedBy=default.target
# ユーザーサービスを有効化し、ログアウト後も稼働させる
systemctl --user daemon-reload
systemctl --user enable --now openclaw
sudo loginctl enable-linger $USER
# 動作とログの確認
systemctl --user status openclaw
journalctl --user -u openclaw -f
最後に運用ルールを1つだけ。トークンはノードを増やすたびに使い回さず、用途ごとに発行して、漏れたときにそのトークンだけ無効化できる状態を作っておくと安心です。
動作確認――最初の指示をチャットから投げてみる
セットアップが終わったら、実際に軽い指示を出して応答を見ましょう。Telegramにbotを招待して「VPSの稼働時間と今の时刻を教えて」のように送ると、エージェントがゲートウェイ上でコマンドを実行し、結果を自然文で返してくれます。この往復が一度確認できれば、経路は正しく通っています。
応答が返ってこない場合は、切り分けは2段階です。まず `journalctl --user -u openclaw -f` でゲートウェイのログを見ながら指示を送り、到達しているかを確認します。ゲートウェイに到達しているのに応答しない場合はLLMプロバイダのAPIキー側、そもそも到達しない場合はチャンネル連携(botトークンやWebhook)側を疑います。実際、わが家でも最初はチャット連携の設定漏れで沈黙していましたが、ログを見れば原因は一目で分かりました。
前編のまとめ――次回はUbuntu PCとMacをノードに登録する
この回で、VPS上にOpenClawのゲートウェイを立て、トークン認証とsystemdで安全に常時稼働させるまでが完成しました。要点は「ゲートウェイはVPS・操作されるPCはノード」という役割分担、そして「公開ポートは最小化し、認証はトークンで」の2点です。
後編ではいよいよ本題のノード登録に進みます。Ubuntu PCとMacをゲートウェイにつないでリモートから操作する手順、実際に運用して便利だった具体例、そして同じ「AIにPCを任せる」手法のHermesエージェントとの比較――特に「他のPCをノードとして使えるか」という観点では執筆時点でOpenClawが有利である理由――を整理します。