ノード登録の仕組み――トークンでPCを安全にゲートウェイへつなぐ
結論から言うと、ノード登録は「ゲートウェイが発行したトークンをPC側で使ってペアリングし、以後はPCからゲートウェイへ常時接続を保つ」という仕組みです。イメージとしては、SSH接続の鍵の受け渡しと管理をOpenClawが引き受けてくれるのに近い。しかも接続方向はノードからゲートウェイへの一方向なので、ノード側のPCに着信ポートを開ける必要がありません。
[画像挿入:ノード登録から常時接続までの流れが分かる図]
順序立てると、①VPS側でゲートウェイがノード用のトークンを発行する ②対象PCにOpenClawをインストールし、ゲートウェイのURLとトークンを指定して登録コマンドを実行する ③以後、そのPCは信頼されたノードとしてゲートウェイに自動接続する、の3ステップです。チャットで指示を出すと、ゲートウェイ上のエージェントが「この指示はどのノードで何をすべきか」を判断し、該当ノードでコマンドを実行して結果を受け取ります。
心得が1つ。ノードにするということは、そのPC上でのコマンド実行をエージェントに認めるということです。まずはよく知っているPC、失っても困るデータが無いPCから始めて、動きを日志で確認する習慣をつけるのが安全です。
Ubuntu PCをノードに登録する手順
結論、Ubuntu側の作業は「Node.jsを入れてopenclawをインストールし、ゲートウェイのURLとトークンを指定して登録する」だけで、新規のPCなら10分もかかりません。
# Ubuntu側: Node.js 22(LTS)とOpenClawのインストール
sudo apt-get update
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt-get install -y nodejs
npm install -g openclaw@latest
# ゲートウェイのURLと発行したトークンで登録
openclaw onboard --gateway wss://gateway.example.com --token <発行したトークン>
コマンド体系はバージョンで細かく変わる可能性があるため、実行前に `openclaw nodes --help` を一度確認してから進めるのが確実です。わが家の環境では、登録直後に `openclaw nodes list` 系の操作でPC名と接続状態を一覧でき、ノード側の設定ファイルにゲートウェイ情報が書き込まれていました。
登録できたら動作確認です。チャットから「ubuntu-desktop のホスト名と稼働時間を教えて」と送ってみてください。エージェントがノードを指定してコマンドを実行し、結果が返ってくればノード運用の完成です。
最後に見落としがちなのが電源管理です。Ubuntuデスクトップは既定でスリープに入ることがあり、スリープ中のノードには指示が届きません。常時操作したいPCなら「設定→電源管理」で自動サスペンドを無効化するか、指示が来る時間帯だけ起きていればよい運用に割り切るか、方針を決めておきましょう。
Macをノードにする手順と、macOS特有の権限の調整
結論、Macも基本の流れはUbuntuと同じ「Node.js→openclaw→トークンで登録」です。違いが現れるのは主に権限と自動起動の部分で、そこだけmacOS流の調整が必要になります。
# Mac側: HomebrewでNode.jsとOpenClawを導入
brew install node@22
npm install -g openclaw@latest
# ゲートウェイへ登録(Ubuntuと同じ要領)
openclaw onboard --gateway wss://gateway.example.com --token <発行したトークン>
権限まわりの要点は2つです。1つは、ノードとしての作業範囲にデスクトップや書類フォルダを含めたい場合、ターミナル.appに「フルディスクアクセス」の権限が必要になることがある点。もう1つは自動起動で、再起動後もゲートウェイへつながるよう、ログイン項目への登録かlaunchd経由の起動を設定しておくと安心です。
電源管理もUbuntuと同じく重要です。Macは蓋を閉じるとスリープするため、クラムシェル運用か、電源設定でスリープを緩和するか、`caffeinate` を併用するなどの方針を決めておきます。わが家ではMacは「在宅時に頼みたい作業専用」と割り切り、常時接続はUbuntu機に任せる構成に落ち着きました。
実際に便利だった使い方――運用して残った3つの具体例
結論、構築から数週間運用して手放せなくなったのは「①出先からの自宅PCへのファイル操作 ②夜間バッチの状況確認と再実行 ③同じ指示の複数台への一括反映」の3つでした。どれも地味ですが、従来はSSHとメモした手順書で行っていた作業がチャット一言になる価値は大きいです。
1つ目の具体例です。出張先で「先週撮影した動画の元データ、Ubuntu機の/videos を圧縮してクラウドに置いて」と頼んだところ、アーカイブ作成と転送まで完走し、完了通知だけが届きました。IPアドレスも鍵も知らないスマホ一枚で完結するのは、SSHに比べて心理的な壁がかなり低いです。
2つ目は夜間バッチです。深夜に回しているエンコードや同期ジョブのログを朝の電車の中で確認し、失敗していれば原因の log の抜粋を抽出させてから再実行を依頼する、という運用にしています。失敗に気づくのが夕方から朝に早まるだけで、やり直しのロスが目に見えて減りました。
3つ目は複数台への一括指示です。「全ノードでシステムアップデートを確認して、保留があれば報告して」といった指示を1回の出力で済ませられるのが、ゲートウェイ・ノード構成ならではの強みです。台数が増えても指示側の手間はほぼゼロのままです。
Hermesエージェントとの比較――「他のPCをノードにする」観点でOpenClawが有利な理由
結論から言うと、「1つのAIから複数のPCを操作したい」という本連載の目的に対して、執筆時点ではOpenClawが明確に有利です。Hermes系のエージェント実装は、動かしている1台のマシンの中でタスクを完結させる設計が中心で、他のPCをノードとして登録して操作するための土持ち(ゲートウェイ・ノード間の認証、常時接続、ノード一覧の管理)が、私が確認した限りでは整備されていません。
[画像挿入:OpenClawとHermesエージェントの構成違いが分かる比較図]
[画像挿入:両者の評価軸別の違いが分かる図]
[画像挿入:OpenClawとHermesエージェントの構成比較図]
構成の違いを図で対比すると分かりやすいのですが、OpenClawが「中央のゲートウェイから複数PCへ放射状に伸びる分散型」なのに対し、Hermesエージェントは「1台のPC内で完結する箱型」です。箱型は構成が単純で見通しが良い半面、操作できる範囲がその1台に限定されます。スマホから自宅の別PCを動かしたい、複数台に一括指示したい、といった要求には、自前でSSHやAPIを組み合わせる工夫が必要になります。
公平のためにHermes側の強みも書いておきます。オープンウェイトのHermes系モデルをローカルで動かせるため、データを外部APIに送らずに済むプライバシー面の優位さと、推論コストを従量課金から自前GPUの固定費に変えられる点は魅力的です。1台のLinuxマシン上で完結するタスクが主戦場なら、十分に有力な選択肢です。
ただし比較の軸を「他のPCをノードとして使えるか」に置くなら、執筆時点ではOpenClawを選ぶ理由が明確です。両者は今後の開発で立場が変わる可能性も十分あるので、導入の判断材料として最新の公式ドキュメントを確認することをおすすめします。
まとめ――向く人・向かない人と、始める前のチェックリスト
2回にわたって、VPS上のOpenClawゲートウェイを中核に、Ubuntu PCとMacをノードとして操作する構成を組み上げてきました。「複数PCをノードに使う」という観点でHermesエージェントよりOpenClawが有利である理由も、構成の違いという形で整理できたはずです。
この構成が向くのは、複数台のPCを日常的に使っていて外出先からも触りたい人、CLIやSSHに抵抗がなく自宅サーバー的な運用を楽しめる人です。逆に、操作対象が1台だけならゲートウェイ構築は過剰ですし、面倒な運用を一切背負いたくない人にはマネージドなAIサービスの方が合うでしょう。
最後に、始める前のチェックリストです。(1) 月数百円のVPSを用意できるか (2) ドメインを1つ取得してTLS終端のリバースプロキシを組めるか (3) ゲートウェイのトークンを安全に管理する運用を守れるか (4) ノードにするPCのスリープ方針を決めたか (5) まずは重要データの無いPCから試す覚悟があるか。この5つを満たせるなら、初日のうちに「スマホから自宅のMacに指示が出る”体験までたどり着けるはずです。