Hermes Agentは$5 VPSで十分？安全なホスティング方法

Hermes Agent とは

Hermes Agent は Nous Research が開発し、2026 年 2 月にリリースしたセルフホスト型 AI エージェントです。自分のサーバーで実行すると、プロジェクトに関する永続メモリを保持し、作業中に再利用可能なスキルを自ら作成し、Telegram や Discord などのチャットアプリから利用できます。モデルに依存しないため、任意の言語モデルを指定できます。$5 VPS、Docker、または SSH 経由で実行できるほど軽量です。モデルは別の場所で動作し、ループ、ツール、メモリは自分のサーバーで動作するという分離により、Hermes はモデルではなく エージェントハーネスとして機能します。そのため、小規模なサーバーで十分です。

エージェントの価値は、ユーザーに代わって処理を実行できる点にあります。同時に、そのため慎重にセットアップする必要があります。記憶し、学習し、タスクを実行するエージェントは、サーバーに実際にアクセスできる常駐プロセスです。このガイドでは、安全な方法でインストールします。ここで行うハードニングは、OpenClaw を安全に実行する場合にも適用できます。

1 コマンドでインストールする方法と、先に内容を読む理由

Hermes は 1 コマンドでインストールできます。

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

これは便利ですが、注意すべきパターンでもあります。インターネットからスクリプトを直接 shell にパイプすると、そのスクリプトに含まれる処理が、実行したユーザーの権限でそのまま実行されます。実運用のサーバーで実行する前に、まずスクリプトをダウンロードして内容を確認し、root ではなく専用ユーザーとして実行してください。

curl -fsSL https://hermes-agent.nousresearch.com/install.sh -o hermes-install.sh
less hermes-install.sh

これは、Hermes だけを特別に信用しないという話ではありません。どの curl | bash install でも、気付かないうちに環境内の最も弱い部分になることを防ぐ習慣です。

権限のないユーザーで実行する

Hermes は専用の system account として実行し、root では実行しないでください。これにより、バグや不正な指示があっても、マシンの他の部分に到達できないようにします。ログインシェルを持たないユーザーを作成します。

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

Hermes を /opt/hermes にインストールし、そのアカウントを所有者にします。公式インストーラーは実行したユーザー向けにインストールするため、ダウンロードしたスクリプトは hermes ユーザーとして、たとえば sudo -u hermes bash hermes-install.sh のように実行します。これにより、ファイルは自分のホームディレクトリではなく、そのアカウントのホームディレクトリに配置されます。この考え方は、権限のないユーザーとしてサービスを実行する場合と同じです。エージェントを実行するアカウントが、エージェントによる被害の上限を決めます。ただし、OS アカウントだけで判断することはできません。エージェント自身の設定によって、事前確認なしで実行できる操作の範囲も決まるためです。エージェントを直接操作できないサーバー上で実行する場合は、Claude Code の権限モードが問題になるのもこのためです。最終的に、そのサーバーを自分以外のユーザーも利用する必要がある場合は、OneCLI によって、エージェントごとに 1 アカウントを割り当てる考え方をチーム全体に広げられます。各ユーザーに専用のサンドボックス化されたエージェントを用意し、モデルの key は 1 つの gateway に集約するため、各自が key をコピーする必要もありません。

ファイアウォールでサーバーを保護し、Secret を隔離する

Hermes はモデルと接続先のチャットアプリに接続して処理するため、インターネットからの受信接続を受け付ける必要はありません。サーバーの前段にデフォルト拒否のファイアウォールを設定します。

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

IPv6 ファイアウォールの抜けに注意してください。IPv4 だけを対象にしたルールセットでは、サービスが IPv6 経由で公開されたままになる可能性があります。エージェントがホームネットワーク内にしか存在しない NAS やローカルデータベースなどへ接続する必要がある場合は、サブネットルーターでそのネットワークを tailnet に広告することで、開放した受信ポートではなく送信接続経由で到達できます。モデル API key とチャットトークンは、hermes ユーザーだけが読み取れるファイル（mode 600）に保存し、コマンドラインに貼り付けないでください。コマンドラインに記述すると、shell の履歴に残ります。このような secrets file は、self-hosted password manager の背後にある admin token と同じく、小さいながら価値の高い標的です。Vaultwarden の hardening 手順の考え方も同じです。ほかのすべてを解除できる 1 つのファイルを保護し、そのバックアップも同じように厳重に保護してください。ファイル権限で防げるのはそのマシン上のほかのユーザーまでであり、その下にある provider までは防げません。エージェントが保持する key がこの判断を変えるほど機密性の高いものであれば、暗号化メモリと attestationによって、ホスティング会社が RAM から読み出せるかどうかが決まります。

Hermes を強化した systemd サービスとして実行する

systemd unit を使用すると、ログアウト後や再起動後も Hermes を実行し続けられます。クラッシュした場合は再起動できます。また、アクセス可能な対象を制限するカーネルレベルのサンドボックスを追加できます。侵害が発生しても影響範囲を限定できるよう、NoNewPrivileges、ProtectSystem=strict、PrivateTmp、ProtectHome を有効にします。

ここで強化した unit を生成し、/etc/systemd/system/hermes.service にコピーします。この unit は、チャットアプリに接続する長時間実行プロセスである hermes gateway を起動します。サービスを有効化する前に、インストール後に hermes --help を実行し、お使いのバージョンでそのコマンドとバイナリのパスを確認してください。

各ディレクティブと daemon-reload、enable --now の手順については、プログラムを systemd サービスとして実行するで説明しています。

sudo systemctl daemon-reload
sudo systemctl enable --now hermes

同じパターンを別のエージェントで構成した例として、systemd で dsh をヘッドレス実行する方法では、Restart ルールと、サービスが夜間に停止したときに初回対応で必要になる journalctl コマンドについて詳しく説明しています。さらに、朝まで待って停止を知る必要はありません。OnFailure= unit で 自分の ntfy server にアラートを送信するようにすれば、Hermes が再起動を諦めた瞬間にスマートフォンへ通知できます。

ネイティブインストールではなく、systemd でコンテナを監視する場合は、固定したコンテナとして KiroCrew を稼働させるを参照してください。イメージのバージョンを固定したまま、同じく再起動後も稼働する構成にできます。

周辺を含めてサーバーを強化する

最後に、外部からの入口を強化します。VPS の SSH を強化するの手順と同じように、SSH を鍵認証のみに変更し、root ログインを無効にします。これにより、サーバーを管理するアカウントを推測されにくくなります。永続的なメモリを保持するエージェントは保護する価値があります。最も簡単な対策は、そのエージェントが動作するサーバーに誰もログインできないようにすることです。

サーバー自体を保護したら、次に追加する機能として多くの人が選ぶのが Web 検索です。エージェントから自分の SearXNG インスタンスを利用する構成にすると、検索クエリを自分のサーバー内で処理できます。ただし、誰も検証していないページをエージェントに読み込ませることになります。通常、サーバー上で動作するエージェントは Hermes だけではありません。そこでも Claude Code を動かすなら、2 つのセッションで直接作業を引き渡すことができます。引き渡しのたびに自分を経由する必要はありません。次に追加するエージェントがチャットアプリではなくコードを読むものなら、同じサーバー上で open-kritt のセキュリティスキャンを実行する構成も同様です。固定したリリース、専用アカウント、そして開放ポートではなく SSH トンネル経由でアクセスする Web UI を用意します。

パッケージ化されたエージェントを実行するより、その仕組みを理解したい場合は、VPS 上で独自の AI エージェントを構築する手順で、構成を段階的に確認できます。そのガイドに登場する用語がまだ難しい場合は、AI エージェントを学ぶための段階的な道筋を参照してください。エージェントのループ、ツール、メモリ、安全性を、相互の依存関係に沿った順序で学べます。そのため、Hermes が代わりに行う選択も、魔法のようには見えなくなります。

FAQ

安価な VPS で Hermes Agent を実行できますか？

はい。Hermes は小規模なサーバーで動作するよう設計されており、個人用の常時稼働エージェントなら $5 VPS で十分です。重いトラフィックを処理するのではなく、言語モデルやチャットアプリケーションに接続するため、必要なリソースは少量です。専用ユーザー、ファイアウォール、systemd サービスを設定すれば、小規模な VPS でも問題なく運用できます。自宅にすでにマシンがある場合は、まずハードウェア費用と電気代を月額料金と比較してください。自宅の Proxmox マシンとレンタル VPS では、それぞれ優れている点が異なります。

1 行のインストールスクリプトを実行しても安全ですか？

curl | bash のインストールは便利ですが、安全のため、実行前にスクリプトをダウンロードして内容を確認し、root ではなく専用ユーザーで実行してください。そうすれば、どのプロジェクトのパイプ経由インストーラーであっても、そのアカウントに許可された操作を超えることはできません。これは Hermes 固有の話ではなく、この形式のインストール全般に適用できる基本的な対策です。

root なしで Hermes を実行するにはどうすればよいですか？

ログインシェルを持たない専用の system ユーザーを作成し、/opt/hermes のようにそのユーザーが所有するディレクトリへ Hermes をインストールして、そのアカウントでサービスを実行します。エージェントが侵害された場合でも、そのアカウントからアクセスできる範囲に被害を限定できます。

ログアウト後も Hermes を実行し続けるにはどうすればよいですか？

systemd サービスとして実行します。unit ファイルを使用すると、ブート時に Hermes を起動し、クラッシュ時に再起動し、SSH セッション終了後も実行し続けられます。また、systemd のサンドボックス機能により、プロセスがアクセスできる対象を制限できます。上記のツールで強化済みの unit を生成し、systemctl enable --now hermes で有効化してください。

Hermes Agent には GPU が必要ですか？

いいえ。Hermes は言語モデルそのものではなくエージェントランタイムであるため、CPU のみの小規模な VPS でも問題なく動作します。負荷の高い計算は、通常は接続先のホスト型 API など、モデルが実行される場所で行われます。同じマシンでモデルもセルフホストする場合は、Hermes 自体ではなくモデルに必要な性能を基準にマシンを選定してください。CPU のみでモデルをホストする場合は、Ollama ガイド の数値を適用できます。