著者 Hermes AgentとOpenClawはどっち？VPS運用で比較
VPSで常駐型エージェントを動かすならHermes AgentとOpenClawのどちらが最適か。2026年9月版のタグに基づき、メモリ管理、Claude認証、サンドボックス環境、ポート開放の要件を徹底比較。用途別の選び方を解説します。
結論
Hermes Agent と OpenClaw はどちらも、チャットアプリからアクセス可能な常駐型エージェントを VPS 上に提供します。エージェントの主な役割が定期的なタスク（スケジュール実行されるジョブや、一度学習させて再利用する手順）である場合は、Hermes Agent を選択してください。主な役割が接続性（WhatsApp、Telegram、Discord、Slack など約 20 種類のチャネルで応答し、公開レジストリのパッケージで拡張可能なアシスタント）である場合は、OpenClaw を選択してください。どちらも CLI（コマンドラインインターフェース）とチャットの両方から実行可能です。そのため、選択の基準は各プロジェクトがどちらを優先しているか、そしてサーバー上で何を開放するかという点になります。
この比較は、Hermes Agent のタグ v2026.9.7（2026年9月7日）および OpenClaw のタグ v2026.9.4（2026年9月11日）に基づいています。両プロジェクトとも月に数回タグ付けを行うため、変更点についてはドキュメントを確認してください。以下の主張はすべて、各タグ時点での各プロジェクトの公式ドキュメント、または引用箇所で明記した 2 つの外部ソースに基づいています。
それぞれの役割：エージェントファーストかゲートウェイファーストか
Hostinger の比較記事では、Hermes Agent を「エージェントファースト」、OpenClaw を「ゲートウェイファースト」と呼んでいます。この分類は妥当であり、両プロジェクトの違いを理解する最も早い方法です。
Nous Research が開発した Hermes Agent は、ワーカーを中心に構築されています。タスクを与えると、ターミナルバックエンドで実行し、学習した内容をスキルとして記録します。また、永続的な事実を記憶する小さなメモリも備えています。チャットは作業を依頼する手段の一つに過ぎません。CLI、cron ジョブ、メッセージングゲートウェイ、デスクトップアプリのすべてが同じエージェントに接続されており、ゲートウェイはインストールする本体ではなく、hermes gateway setup で有効化する機能という位置付けです。
一方、OpenClaw はゲートウェイを中心に構築されています。ゲートウェイは常駐プロセスであり、ドキュメントではセッション、ルーティング、チャネル接続における唯一の信頼できる情報源（Single Source of Truth）と定義されています。モデルやエージェントハーネスはゲートウェイに接続するプラグインであり、README には交換可能なハーネスとして Claude、Codex、ローカルモデルが挙げられています。この製品の目的は「到達性（Reach）」にあり、エージェントはゲートウェイがホストする機能の一つです。
両プロジェクトは互いの優れたアイデアを取り入れています。現在ではどちらも、未知のチャット送信者に対してボットと会話する前にコードによる認証を求めています。また、どちらもエージェントがスキルを作成できるようになりました。Hermes は自律的にスキルを書き込み、OpenClaw の Skill Workshop は承認を前提としたドラフトを作成します。しかし、その中心にある設計思想は依然として異なります。Hermes はチャットフロントエンドを持つワーカーであり、OpenClaw はワーカーを背後に備えたチャットハブです。
インストールパスとVPSのフットプリント
どちらのプロジェクトもRAMやCPUの最小要件を明記していないため、ここでも規定しません。どちらのエージェントも、呼び出すモデルの処理に比べれば軽量です。サーバーへの実際の負荷は、エージェントに何を実行させるかによって決まります。コーディングエージェント用VPSに必要なRAMとCPUの目安では、エージェントの要件ではなく、ワークロードに基づいたサイジングについて解説しています。
一つだけ、ドキュメントに記載されている数値を知っておく必要があります。HermesがDockerターミナルバックエンドを使用する場合、ドキュメントではサンドボックスコンテナの制限をデフォルトで container_cpu: 1 および container_memory: 5120 (単位はMB) に設定しています。これらはコンテナに対する制限値であり、測定された必要量ではありませんが、これより小さいVPSではこの制限を遵守できません。
Hermesは1つのスクリプトでインストールします。Python 3.11が必要であり、uv を通じて取得します。Linux環境では、事前に git、curl、xz-utils が必要です。
sudo apt update && sudo apt install -y git curl xz-utils
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
source ~/.bashrc
hermes doctorコードは編集可能なgitチェックアウトとして ~/.hermes/hermes-agent/ に配置され、コマンドは ~/.local/bin/hermes に格納されます。すべてのデータは ~/.hermes/ 配下に保存されます。インストーラーの記述によれば、sudo はオプションのシステムパッケージに対してのみ使用され、Hermes自体はroot権限を必要とせず、保持もしません。ドキュメントにはピン留めについての記載はありませんが、インストーラーのスクリプトは --commit SHA を受け付けます。これにより、クローンまたは更新後にチェックアウトを特定のコミットに固定できます。タグの背後にあるコミットを取得し、HERMES_SHA としてエクスポートした上で、以下のように渡します。
git ls-remote --tags https://github.com/NousResearch/hermes-agent v2026.9.7
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash -s -- --commit "$HERMES_SHA"ls-remote が2行出力する場合、^{} で終わる方を使用してください。これは注釈付きタグが指し示すコミットであり、--commit はタグオブジェクトではなくコミットSHAを要求するためです。インストール後、hermes model でプロバイダーとモデルを選択し、hermes tools でツールを有効化し、hermes setup でウィザード全体を実行し、hermes doctor で結果を確認します。
OpenClawも同様に1つのスクリプト、またはnpm経由でインストールし、Nodeが必要です。ドキュメントではNode 24.16以降、または26.1以降を求めており、LinuxインストーラーはNodeが不足している場合にNode 24 LTS (長期サポート版) を取得すると記載されています。npmパスは正確なバージョンを受け付けるため、これを使用してバージョンを固定できます。
curl -fsSL https://openclaw.ai/install.sh | bash
# or, pinned:
npm install -g openclaw@2026.9.4 --allow-scripts=openclaw
openclaw onboard --install-daemonopenclaw onboard --install-daemon を実行するとセットアップウィザードが起動し、Linux上のsystemdユーザーサービスとしてGatewayがインストールされます。設定は ~/.openclaw/openclaw.json に保存されます。これはJSON5形式であるため、コメントや末尾のカンマが許可されています。OpenClawは、月ごとの変更を抑えたいユーザー向けに、2026年9月10日付けで v2026.6.35 とタグ付けされたExtended Stableラインも公開しています。インストールガイドには、チャネル間を移行するための openclaw update --channel stable および --channel dev についての記載があります。
HermesエージェントVPSガイド および OpenClawコンテインメントガイド には、各ステップで通過すべきチェック項目を含めた完全なインストール手順が記載されています。
ネットワーク上で各サービスが開放するポート
このセクションはファイアウォールの設定を決定するため、最も慎重な対応が必要です。
OpenClaw は設計上ポートを開放します。 Gateway はデフォルトで TCP 18789 を待ち受けます。ポート番号は --port、OPENCLAW_GATEWAY_PORT、gateway.port の設定値の順に評価され、いずれも未設定の場合は 18789 が使用されます。gateway.bind のデフォルトは loopback であり、その他の値は auto、lan（これは 0.0.0.0 を意味します）、tailnet、custom です。Control UI は同一ポートの http://127.0.0.1:18789、ベースパス /openclaw 配下で動作します。ドキュメントにはリスクについて「ループバック以外へのバインドにはゲートウェイ認証が必要である。実運用では共有トークン/パスワード、または ID 認識型リバースプロキシを意味する」と明記されています。gateway.auth.mode には none、token、password、trusted-proxy のいずれかを指定でき、オンボーディングウィザードはデフォルトでトークンを生成します。bind は loopback のままにし、SSH トンネル経由で UI にアクセスしてください。また、openclaw security audit を実行して、これらのデフォルト設定から逸脱していないか確認してください。
Hermes はドキュメントに記載されたポートを開放しません。 ゲートウェイは各チャットプラットフォームに対してクライアントとして外向きに接続するため、セキュリティおよびメッセージングのドキュメントには待ち受けポートに関する記述が一切ありません。CLI はモデルエンドポイントおよびターミナルバックエンドと通信します。Docker バックエンドはローカルの Docker ソケットと通信します。SSH バックエンドは 22 番ポート経由で別のホストへ外向きに接続します。したがって、Hermes を実行するサーバーはインバウンドポリシーを「SSH のみ」に維持でき、エージェント側の設定変更も不要です。
チャットプラットフォームの多くは、両プロジェクトにおいてインバウンドポートを必要としません。 どちらもメインチャネルにはロングポーリングまたは外向きの WebSocket を使用します。Hermes の Slack 連携は Socket Mode を使用しており、ドキュメントには「インスタンスを公開する必要はない」と記載されています。Hermes の WhatsApp 連携は、QR コードでペアリングを行い、外向き接続を通じて WhatsApp Web をエミュレートする Node.js ブリッジを実行します。これにはサーバー上で Node.js v18 以降が必要です。OpenClaw の Telegram チャネルは「ロングポーリングがデフォルトの転送方式であり、Webhook モードはオプションである」としており、WhatsApp チャネルは外向き WebSocket を経由する QR コード専用です。例外はパブリック URL を必要とするパスです。OpenClaw の Telegram Webhook モード（webhookUrl、webhookPort、webhookSecret）および Hermes の個別の WhatsApp Business Cloud API オプションが該当します。後者はドキュメントによると Meta Business アカウントとパブリック Webhook URL が必要です。特別な理由がない限り、これらは使用しないでください。
両者ともデフォルトで未知のチャット送信者を拒否します。 Hermes はプラットフォームごとの全許可フラグ、ペアリング承認リスト、TELEGRAM_ALLOWED_USERS のようなプラットフォームごとの許可リスト、グローバルな GATEWAY_ALLOWED_USERS、グローバルな全許可フラグ、そして拒否の順にチェックを行います。未知の送信者には DM で 8 文字のペアリングコードが送信され、hermes pairing approve <platform> <code> で承認します。OpenClaw の dmPolicy は Telegram および WhatsApp でデフォルトが pairing となっており、openclaw pairing approve <channel> <code> で承認します。シェルコマンドを実行可能なボットに対して、GATEWAY_ALLOW_ALL_USERS=true や dmPolicy: open を設定してはいけません。
Hermes における OpenClaw コンテインメントの適用方法
OpenClaw コンテインメントガイド で示されるコンテインメントは、専用の非特権ユーザー、VPS ファイアウォール内側のループバックに固定された Gateway、ツール実行用の Docker サンドボックス（agents.defaults.sandbox.mode を all に設定）、およびループバック以外のすべてに対するトークン認証に集約されます。OpenClaw のサンドボックスページでは、境界が明確に定義されています。Gateway プロセス自体は常にホスト上で実行され、サンドボックス化はツール実行のみを対象とします。tools.elevated は、その外部で実行されるエスケープハッチです。
ユーザーとファイアウォールの設定は、そのまま Hermes に適用されます。専用ユーザーの使用は同様の防壁となり、Hermes の本番環境チェックリストにも「Gateway を root で実行しないこと」と明記されています。ファイアウォールによる防壁は、固定すべきポートがなく、トークンが保護すべき対象もないため、より単純です。
サンドボックスは ~/.hermes/config.yaml 内の terminal.backend に対応します。Hermes は local、docker、ssh、singularity、modal、daytona、vercel_sandbox という 7 つのバックエンドを文書化しています。docker を使用する場合、コンテナは --cap-drop ALL で実行され、その後 DAC_OVERRIDE、CHOWN、FOWNER が再追加されます。また、tmpfs にマウントされた nosuid 上で /tmp および /var/tmp とともに、--security-opt no-new-privileges と --pids-limit 256 が設定されます。1 つ重要な違いがあります。Hermes のドキュメントによると、docker、singularity、modal、daytona、vercel_sandbox の各バックエンドでは、「コンテナ自体がセキュリティ境界として機能する」ため、危険なコマンドのチェックがスキップされます。つまり、Hermes ではバックエンドごとにいずれか一方の防壁が適用されます。local バックエンドでは承認ゲートが適用され、コンテナは使用されません。docker ではコンテナが適用され、承認ゲートは使用されません。
Hermes のドキュメントには、独自のレイアウトが追加されています。それは「Gateway を別のマシンまたは VM（仮想マシン）で実行し、terminal.backend: ssh を使用する」というものです。Gateway を配置したマシンはチャットトークンとモデルキーを保持し、コマンドは一切実行しません。ワーカーマシンはコマンドを実行しますが、盗まれる価値のあるものは何も保持しません。コーディングエージェント用の使い捨て VM は、このレイアウトにおける自然なワーカーとなります。なぜなら、クリーンアップするよりも再構築する方が容易だからです。
メモリ：2つの小さな固定ファイルか、ライブワークスペースか
この比較において、メモリモデルほど異なる点はありません。mem0による両者の比較が、その違いを最も明確に記述しています。要約すると、Hermesは「キャッシュが安定する長期セッション向けに最適化」されており、OpenClawは「即時の可視性向けに最適化」されています。
The data behind this chart
[
{
"label": "Hermes MEMORY.md (hard cap)",
"char_limit": "2,200"
},
{
"label": "Hermes USER.md (hard cap)",
"char_limit": "1,375"
},
{
"label": "OpenClaw MEMORY.md (soft target)",
"char_limit": "20,000"
}
]Hermesの数値は、そのメモリドキュメントに基づいています。OpenClawの数値は、mem0が報告するソフトターゲットです。
Hermesは ~/.hermes/memories/ 配下に2つのファイルを保持します。MEMORY.md はエージェント自身のメモを保持し、上限は 2,200 文字です。USER.md はユーザーに関する事実を保持し、上限は 1,375 文字です。ドキュメントによると、これらの上限は厳格であり、上限を超えて書き込もうとすると、黙って切り捨てられるのではなくエラーが返されます。エージェントは add、replace、remove という3つの動詞を使用してこれらを編集します。ここで replace と remove は部分文字列でマッチングを行います。両ファイルともセッション開始時にシステムプロンプト内の固定ブロックとして一度だけ読み込まれるため、プロンプトキャッシュのプレフィックスは安定します。この設計の代償として、エージェントがセッションの途中で書き込んだメモリは即座にディスクへ保存されますが、次のセッションまでプロンプトには反映されません。古い事実については、session_search が ~/.hermes/state.db 内の過去の全会話に対してFTS5（SQLiteの全文検索）を実行します。
OpenClawはメモリをワークスペースとして扱います。~/.openclaw/workspace/MEMORY.md が主要なファイルであり、ソフトターゲットは約 20,000 文字です。さらに memory/YYYY-MM-DD.md に日々のメモがあり、今日と昨日のファイルが自動的に読み込まれます。memory_search ツールが、そのすべてに対してベクトル類似性とキーワードマッチングを組み合わせたハイブリッド検索を実行します。mem0は、メモリがターンごとに再注入されるため、書き込みが次のターンで可視化されると指摘しています。
どちらが優れているかは用途に依存します。毎晩同じcronジョブを実行するHermesエージェントは、安定したプロンプトと信頼できる少数の事実を必要とします。1日に100件の短いチャットをこなすOpenClawアシスタントは、再起動なしで1時間前の会話を記憶しておく必要があります。Hermesは hermes memory setup で有効化できる8つのメモリプロバイダーの1つとしてMem0をリストアップしており、mem0はOpenClaw用の @mem0/openclaw-mem0 プラグインを公開しています。Mem0メモリサーバーのセルフホストを行うことで、両エージェントはサーバー側で共通の事実抽出を利用でき、会話ごとのサイズ上限を撤廃できます。エージェントが書き込むファイルはすべて、後にエージェントが信頼する入力となるため、エージェントのメモリが汚染される仕組みは両プロジェクト、および次セクションで扱うスキルにも適用されます。
スキル：自作の手順、またはパブリックレジストリ
Hermes は独自のスキルを記述します。スキルとは ~/.hermes/skills/ 配下のディレクトリであり、SKILL.md ファイルと、必要に応じて scripts/、references/、templates/、examples/ フォルダで構成され、agentskills.io 形式に従います。エージェントは skill_manage ツールを備えており、システムプロンプトにはスキルを記述する3つのトリガーが定義されています。それは、繰り返す価値のある多段階プロセスを導き出した場合、エラー後に回避策を見つけた場合、またはユーザーから修正を受けた場合です。ドキュメントでは、スキルの目的を「ログではなく教訓」と定義しています。エージェントが自身の命令セットを未確認のまま編集することを防ぐには、skills.write_approval: true を設定してください。これにより、新しいスキルは承認されるまで ~/.hermes/pending/skills/ 配下にステージングされます。Hermes は hermes skills install <identifier> を使用して外部からスキルをインストールすることも可能です。対象は anthropics/skills などの GitHub リポジトリ、skills.sh、SKILL.md への直接 URL、または ClawHub 自体です。ドキュメントによると、すべてのハブインストールはデータ流出、プロンプトインジェクション、破壊的なコマンドの有無についてスキャンされます。危険ではないとコミュニティが判断した場合は --force で上書きできますが、「危険なスキャン判定」が下された場合は --force を指定してもインストールはブロックされます。
OpenClaw はパブリックレジストリである ClawHub からスキルやプラグインを取得します。openclaw skills search "calendar" で検索し、openclaw skills install @openclaw/demo でインストール、openclaw skills update --all で最新状態を維持し、コードプラグインは openclaw plugins install clawhub:<package> を経由します。スキルは優先順位付けされたディレクトリセットから読み込まれ、<workspace>/skills が ~/.agents/skills よりも優先され、次に管理下の <state-dir>/skills、最後にバンドルセットが続きます。スキルの SKILL.md は metadata.openclaw.requires.bins や requires.env を宣言でき、バイナリや変数が欠落している場合、OpenClaw はそのスキルを非表示にします。これは、不完全な動作をするスキルよりもクリーンな失敗の形です。エージェントは自身でスキルをディスクに書き込むことはありません。Skill Workshop を通じてエージェントが提案を作成し、ユーザーがそれを承認する仕組みです。
レビューモデルはチェックの実行場所が異なります。ClawHub のドキュメントには、「公開されたスキルやプラグインのリリースに対して自動チェックを実行する」とあり、スキャンで保留またはブロックされたリリースはパブリックカタログから削除される可能性があること、サインインしたユーザーはパッケージを報告でき、モデレーターはそれを非表示にできること、公開にはアップロード制限を通過できる期間を経過した GitHub アカウントが必要であることが記載されています。これはレジストリ側でのレビューです。Hermes はインストール時にローカル環境でスキャンを実行し、書き込み承認ゲートがエージェント自身の記述したスキルをカバーします。OpenClaw のスキルページは、両者に共通する重要な一文で締めくくられています。「サードパーティのスキルは信頼できないコードとして扱うこと。有効にする前に必ず内容を確認すること。」
モデルと認証オプション、および Claude サブスクリプションに関する質問
どちらのプロジェクトも API キーまたはローカルモデルで動作し、OpenRouter を経由します。違いはサブスクリプションの利用経路にあり、このトピックを検索するユーザーの多くが知りたいのはこの点です。
API キー。 Hermes は ANTHROPIC_API_KEY、OPENROUTER_API_KEY、OPENAI_API_KEY およびその他多数のキーを ~/.hermes/.env から読み取ります。hermes model でプロバイダーとモデルを対話的に選択し、hermes config get model でその選択内容が表示されます。Nous Portal は独自のプロバイダーであり、hermes setup --portal はモデルプロバイダーとホスト型ツールゲートウェイを提供する単一の OAuth ログインです。OpenClaw は ANTHROPIC_API_KEY を通じて openclaw onboard --anthropic-api-key "$ANTHROPIC_API_KEY" を受け取り、openclaw models list --provider anthropic で接続可能な範囲を表示します。ドキュメントでは anthropic/claude-opus-5 が主なデフォルトとして記載されており、anthropic/claude-fable-5-1 および anthropic/claude-sonnet-5 も併記されています。
Ollama を介したローカルモデル。 2 つのプロジェクトは Ollama への参照方法が異なり、混同すると確実に失敗します。Hermes は OpenAI 互換エンドポイントを使用します。config.yaml で model.provider: custom と model.base_url: http://localhost:11434/v1 を設定するか、hermes model で "Custom endpoint" を選択してください。ドキュメントには、Hermes は「ツールを使用したエージェント利用には最低 64,000 トークンのコンテキストが必要」とあり、Ollama のデフォルト値では不足するため、OLLAMA_CONTEXT_LENGTH=64000 ollama serve で起動する必要があります。OpenClaw は逆のアプローチをとります。その Ollama ページには「/v1 の OpenAI 互換 URL (http://host:11434/v1) は使用しないでください。ツール呼び出しが機能しなくなり、モデルが生のツール呼び出し JSON をプレーンテキストとして出力する可能性があります」と記載されています。OpenClaw は Ollama ネイティブの /api/chat と通信し、設定キー baseUrl を http://127.0.0.1:11434 に設定し、モデル名を ollama/<model> とします。同じデーモンでも URL は正反対です。
Claude サブスクリプション。 2026 年 9 月時点の各プロジェクトのドキュメントに記載されている内容は以下の通りです。
Hermes: hermes model (Anthropic OAuth を選択) または hermes auth add anthropic --type oauth を通じた OAuth ログインが存在し、Hermes は「あなたの Anthropic アカウントに対して Claude Code として」ルーティングを行います。ドキュメントには「Claude Max プランに加入し、追加の利用クレジットを購入している場合にのみ機能する」と追記されています。基本の Max 許容量は消費されず、追加クレジットから利用分が請求されます。Claude Pro ではこの経路を使用できず、ドキュメントでは Pro 加入者に対して標準 API 料金での ANTHROPIC_API_KEY 利用を推奨しています。
OpenClaw: ドキュメントでは「同一ホスト上にインストールされた実行ファイルを通じて、既存の Claude Code ログインを再利用する」方法が説明されています。VPS に Claude CLI をインストールし、claude auth login を実行してから openclaw onboard で "Claude CLI" を選択します。別の方法としてセットアップトークンを使用します。claude setup-token を実行し、次に openclaw models auth login --provider anthropic --method setup-token を実行します。同じページにある 2 つの文が制限を定めています。「Claude Code は既存のログインとサブスクリプションを保持するが、OpenClaw はそのログインを永続化または更新しない」。また、Agent SDK、claude -p、およびサードパーティ製アプリを通じたサブスクリプションプランの利用は「引き続きサインイン中のサブスクリプションの利用制限枠を消費する」とあります。
両プロジェクトは利用料金の請求について異なる説明をしており、どちらのページも Anthropic 公式のものではありません。サブスクリプションログインを使用して夜間のワークロードを構築する前に、サードパーティによる Claude プラン利用に関する Anthropic の最新の利用規約を確認してください。両プロジェクトとも経路を文書化していますが、どちらの経路も通常の claude.ai ログインではなく、Claude Code のアイデンティティを経由します。Hermes はその経路を Max プランかつ追加クレジットがある場合に限定しており、OpenClaw は Claude CLI ログインと同じホストである場合に限定しています。
その他のサブスクリプション。 Hermes は ChatGPT プランに対するデバイスコード OAuth を介した OpenAI Codex や、デバイスフローを通じた GitHub Copilot についても文書化していますが、Codex のページにはどのプラン階層が対象となるかは「現在文書化されていない」とあります。OpenClaw は交換可能なハーネスの 1 つとして Codex をリストアップしています。すでにそれらのいずれかに加入している場合は、それを文書化しているプロジェクトを優先する正当な理由となります。
各プロジェクトが掲げるセキュリティ体制
Hermes はコマンドをゲート制御します。approvals.mode の config.yaml では、デフォルトで smart が有効であり、補助モデルが各コマンドを評価します。低リスクのコマンドは実行され、明らかに危険なものは拒否されます。判断が曖昧な場合はユーザーに確認を求めます。manual は危険な一致が検出されると必ず確認を求め、off はゲート機能を無効化します。スキャナーは、再帰的な削除、chmod 777 およびその関連コマンド、mkfs、dd if=、/etc/、systemctl stop、disable、mask へのリダイレクト、DROP TABLE、curl ... | sh、およびフォーク爆弾を検知します。チャット内では、ゲートウェイがコマンドを投稿し、yes、y、approve、ok、または go を待ちます。no または cancel で拒否でき、デフォルトのタイムアウトは 300 秒です。--yolo フラグ（またはセッション内の /yolo、あるいは HERMES_YOLO_MODE=1）を使用するとプロンプトをスキップできますが、厳格なブロックリストは依然として有効です。これには rm -rf /、フォーク爆弾、マウントされたルートに対する mkfs、ブロックデバイスへの dd、およびシェルにパイプされる信頼できない URL が含まれます。コンテナのバックエンドではこのゲートが無効であることに注意してください。
OpenClaw は境界を定めています。セキュリティページには、ゲートウェイは「ゲートウェイごとに 1 つの信頼境界」であり、「互いに敵対するユーザーのための敵対的なマルチテナントセキュリティ境界ではない」と記載されています。そのため、互いに信頼していない 2 人のユーザーは、それぞれ異なる認証情報を持つ 2 つのゲートウェイを使用する必要があります。ツールの許可および拒否ポリシーはサンドボックスのルールよりも先にチェックされるため、グローバルで拒否されたツールはサンドボックス内でも拒否されたままとなります。エージェントごとのアクセスプロファイルと読み取り専用モードにより、エージェントが操作できる範囲を制限します。openclaw security audit は現在の設定を安全なデフォルト値と比較します。スキル面では前述の ClawHub によるレビューに加え、サードパーティ製のスキルを有効にする前にコードを確認するよう指示されています。
どちらのプロジェクトも、それ以上の主張はしていません。Hermes はスキャナーがすべてを検知できるとは謳っておらず、リスクが高い場合はコンテナや別のマシンを使用するようドキュメントで推奨しています。OpenClaw はサンドボックスがゲートウェイ自体を包含しているとは主張しておらず、その旨はサンドボックスのページに明記されています。どちらも誠実なドキュメントであり、無人で稼働させるソフトウェアとして良い兆候です。
意思決定マトリックス
反復的なワークフロー: Hermes
メモリを備えた Cron ジョブです。同じタスクを3回実行した後に学習するスキル、上書き不可能なメモリ、リスクレベルに応じて選択可能なターミナルバックエンドを備えています。エージェントの週次業務の大半がジョブであり、会話が補助的な場合に適した構成です。
メッセージングのリーチ: OpenClaw
1つの Gateway の背後に約20のチャネルを配置し、すべてのチャネルで DM ペアリングを行い、同一ポート上で Control UI を提供し、既製のスキルやプラグインのレジストリを備えています。エージェントの週次業務の大半がアプリ間での会話であり、ジョブが補助的な場合に適した構成です。
1台構成: 適切な壁（分離）を伴ういずれか
専用ユーザー、gateway.bind: loopback、トークン、sandbox.mode: all を使用して、1台の VPS 上で OpenClaw を運用します。Hermes の場合は terminal.backend: docker を使用してコンテナ内の承認ゲートを無効にするか、terminal.backend: local および approvals.mode: manual を使用して運用します。後者の場合、承認ミスがホスト上で実行されるリスクを考慮する必要があります。
2台構成: Hermes の公式ドキュメントに従う
1台の VPS に Gateway を配置し、terminal.backend: ssh でワーカー用 VPS に接続します。チャットトークンとモデルキーは最初の VPS に保持し、2台目には保持すべきデータを置かない構成です。OpenClaw は trusted-proxy 認証を備えたリバースプロキシの背後に配置可能ですが、各エージェントがサンドボックス化されていない限り、Gateway は自身のホスト上で実行されます。
ローカルモデルのみ: URL を再確認
Hermes は /v1 と 64k のコンテキストを要求します。OpenClaw は /v1 を拒否し、ネイティブ API を要求します。
Claude Max に追加クレジットを支払っている場合: Hermes がそのパスを限定的に文書化
同じホスト上で既に Claude Code を実行している場合: OpenClaw がその再利用方法を文書化しています。Claude Pro を利用している場合: どちらでも API キーを使用可能です。
これら2つと他製品で迷っている場合: セルフホスト型エージェントのまとめでは、Agent Zero や OpenHands などと同一軸上で比較しています。
FAQ
Hermes Agent で Claude Max サブスクリプションを利用できますか？
Hermes のドキュメントによれば、限定的な範囲で利用可能です。hermes model (Anthropic OAuth) または hermes auth add anthropic --type oauth を経由してログインすると、Hermes は Claude Code としてアカウントに接続します。ドキュメントには「Claude Max プランに加入し、追加の利用クレジットを購入している場合にのみ動作する」と記載されており、利用料は基本枠ではなく追加クレジットから消費されます。Claude Pro サブスクライバーは代わりに ANTHROPIC_API_KEY を使用する必要があります。2026 年 9 月現在、無人環境での利用を検討する前に Anthropic の利用規約を確認してください。
OpenClaw を利用する際、VPS のポートを開放する必要がありますか？
通常利用では不要です。Gateway は TCP 18789 番ポートで待ち受けますが、gateway.bind のデフォルト設定は loopback であるため、127.0.0.1 でのみ応答します。Control UI には SSH トンネル経由で http://127.0.0.1:18789 からアクセスしてください。Telegram はロングポーリング、WhatsApp はアウトバウンドの WebSocket を使用するため、Telegram のオプションである webhook モードを選択しない限り、インバウンドのポート開放は不要です。lan または tailnet にバインドする場合は、ゲートウェイ認証（共有トークン、パスワード、または前段の ID 認識型プロキシ）が必須となります。
無人環境で実行し続ける場合、どちらがより安全ですか？
承認機能が無効な local バックエンド上では、どちらも安全ではありません。Hermes は、ゲートウェイを 1 台の VPS に、terminal.backend: ssh を別のワーカー VPS に配置する構成が最も安全であり、公式ドキュメントでも「最大限のセキュリティのために」推奨されています。OpenClaw は、専用の非特権ユーザー gateway.bind: loopback、トークン、および agents.defaults.sandbox.mode: all を使用するのが最も安全です。いずれの場合も、エージェントのメモリファイルとスキルディレクトリは、攻撃者がチャットメッセージを通じて書き込み可能な入力先であると見なしてください。
Hermes Agent と OpenClaw を同じ VPS で実行できますか？
可能です。ポートやディレクトリは共有されません。Hermes はすべてを ~/.hermes/ 配下に保持し、待ち受けポートは開きません。OpenClaw はすべてを ~/.openclaw/ 配下に保持し、127.0.0.1:18789 で待ち受けます。エージェントが侵害された際に互いのチャットトークンを読み取られないよう、それぞれに専用の Linux ユーザーを割り当ててください。Telegram のボットトークンを両方で共有しないでください。Telegram は 1 つのボットにつき 1 つのロングポーリングクライアントのみを許可しており、2 つ目の接続には 409 Conflict: terminated by other getUpdates request を返します。
各プロジェクトを特定のリリースに固定するにはどうすればよいですか？
OpenClaw の npm パスには正確なバージョンを指定できます（npm install -g openclaw@2026.9.4 --allow-scripts=openclaw）。公開されているバージョンは npm view openclaw versions で確認可能です。Hermes のインストーラーは --commit SHA を受け付けるため、v2026.9.7 の背後にあるコミットを git ls-remote --tags https://github.com/NousResearch/hermes-agent v2026.9.7 で取得し、bash -s -- --commit <sha> として渡してください。両プロジェクトとも月に数回タグ付けが行われるため、テストに使用したタグを記録しておくことを推奨します。