Hermes Agentをサーバーで24時間稼働させる方法

ノートパソコンにHermes Agentをインストールすると、こんな疑問が浮かびます。ノートパソコンを閉じている間、誰がTelegramで返信し、朝のまとめを作るのでしょうか。自分のデスクでは、パソコンの電源が入っている間だけエージェントが動きます。ボットを常時オンラインにして、スケジュール済みのタスクを自動で実行するには、エージェントをサーバーに移す必要があります。

ここでは、一般的なLinuxサーバーにHermesをインストールし、ゲートウェイを常時稼働するサービスにして再起動後に自動で起動させる方法と、知らない人がターミナルに入れないようアクセスを制限する方法を説明します。このガイドは公式ドキュメントに基づいています。

Hermesをまだ一度もインストールしていない場合は、まずこのエージェントとは何か、インストール方法を紹介する別の概要ガイドをご覧ください。このガイドでは、すでに自分のマシンで動かしていることを前提に、サーバーへの移行だけを扱います。

Ailootの利用方法については、ドキュメントをご覧ください。

Hermes Agentをノートパソコンからサーバーに移す理由#

ノートパソコンでは、ふたが開いていて、あなたが近くにいる間だけHermesが動きます。ふたを閉じるとボットは応答しなくなり、朝のまとめも届きません。「メッセンジャーで人に返信し、スケジュールに沿って作業する」ようなタスクには困ります。

サーバーなら事情が違います。休止することがなく、ほかのものにも依存しません。同じHermesをインストールすれば、あなたがいなくても動きます。午前3時にTelegramで返信し、毎朝、指定したトピックのニュースを集め、実行の間もセッションを維持します。

エージェントに継続的なタスクを任せる場合、サーバーへの移行が役立ちます。自分やチームのボット、朝のまとめ、自動返信、定期的なドキュメント作業などが該当します。特定のプロジェクトでHermesを試し、そばで作業するだけなら、まだサーバーは必要ありません。手順がひとつ増えるだけです。

VPSにHermesをインストールする前に準備するもの#

インストール前に3つのものを準備します。

サーバー。 一般的なLinux VPSで十分です。ドキュメントにある第一級のサポート対象はLinuxとWSL2で、最新のUbuntuでテストされています。システムにglibc、systemd、一般的なディレクトリ構成があれば、Hermesは正しくインストールできます。以下の自動起動手順はすべてsystemdに依存します。systemdはUbuntuとDebianに標準で備わっています。

SSHアクセス。 SSHを使い、ターミナルからサーバーに接続します。マウスは使いません。以下のコマンドはすべて、このSSHセッションで実行します。vibe codingをしていて、まだターミナルに慣れていなくても心配はいりません。コマンドは数個だけで、それぞれをそのままコピーできます。

選択済みのモデル。 エージェントは自分で考えるのではなく、モデルを呼び出します。無人で動かすサーバーでは、モデルへのアクセスが期限切れにならないことが重要です。最も簡単なのは、hermes setup --portalを使ったNous Portalのサブスクリプションです。サインインにはOAuthを使い、トークンは自動更新されます。自分のAPIキーも使えますが、その場合はアカウントに残高があることを確認してください。残高がないヘッドレスエージェントは応答しなくなります。モデルには少なくとも64,000トークンのコンテキストウィンドウが必要です。そうでないとHermesはそのモデルでの起動を拒否します。リストにあるクラウドモデルはすべてこの要件を満たしています。

Hermes Agentをサーバーに1つのコマンドでインストールする方法#

サーバーへのインストールはノートパソコンの場合とほぼ同じですが、違いがひとつあります。サーバーでは通常、エージェントにブラウザーは不要です。ブラウザーの自動操作には大容量のChromiumも必要です。そのため、--skip-browserフラグを使います。

1. SSHでサーバーに接続する

   ssh root@your-server-address
   

   以降のコマンドはすべて、このセッション内でサーバー上に直接入力します。

2. ブラウザーなしでインストーラーを実行する

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

   スクリプトは必要な環境をダウンロードし、hermesコマンドをインストールします。--skip-browserフラグを付けると、ブラウザー自動操作のインストールを省きます。画面のないサーバーでは、容量を使うだけだからです。後からブラウザーが必要になった場合は、別途インストールできます。

3. シェルを再起動してモデルを選ぶ

   source ~/.bashrc
   hermes setup --portal
   

   1行目で新しいPATHを読み込み、hermesコマンドを見つけられるようにします。2行目でNous Portalのサインインが始まります。サインインを確定すると、個別のキーを用意しなくてもエージェントがモデルとサービスを利用できるようになります。

4. インストールを確認する

   hermes doctor
   

   このコマンドは、インストール済みのもの、不足しているもの、修正方法を表示します。緑色のマークがあれば、必要なものが揃っています。

ボットとスケジュールを追加する前に、まずサーバー上で直接、会話が問題なくできることを確認してください。hermesを実行し、答えを検証できる簡単なタスクを与えます。通常の会話が動作する前に機能を詰め込まないよう、ドキュメントも明示的に勧めています。妥当な助言です。

Hermesを24時間稼働させる方法#

ゲートウェイは、すべてのメッセンジャーとの接続を維持し、セッションを管理し、スケジュール済みタスクを実行する、単一のバックグラウンドHermesプロセスです。24時間稼働の仕組みはすべて、このゲートウェイを中心に動きます。このプロセスが自動で起動し、動作し続けるようにします。

まずゲートウェイを設定し、メッセンジャーに接続します。

hermes gateway setup

セットアップウィザードがプラットフォームの設定を案内し、ボットトークンとアクセスリストの入力を手伝います。Telegramの接続手順（BotFatherでボットを作成し、自分のIDを確認してトークンを入力する方法）は、メインのインストールガイドで説明しています。ここでは繰り返しません。

次に、よく忘れられる落とし穴があります。単にhermes gatewayを実行するだけでは、SSHセッションを開いている間しかプロセスは動きません。ターミナルを閉じるとゲートウェイも停止します。連続して稼働させるには、システムの管理下に置く必要があります。そのためのコマンドはひとつです。

hermes gateway install

これでゲートウェイがサービスとしてインストールされます。Linuxではユーザーsystemdサービス、macOSではlaunchdを使います。システムがプロセスを監視し、クラッシュした場合は再起動します。

サーバーでは、もう一方の方法を使うことが多いでしょう。ユーザーのサインイン前に、マシンの起動時に立ち上がるシステムサービスです。

sudo hermes gateway install --system

VPSで必要なのは、まさにこの方法です。サーバーが再起動すると、サービスが自動で起動し、ボットが再びオンラインになります。次の簡単なコマンドで管理できます。

hermes gateway start     # start
hermes gateway stop      # stop
hermes gateway status    # check status

システムサービスの場合は、これらのコマンドにsudoと--systemフラグを加えます。加えないと、起動時に立ち上がるサービスではなく、ユーザーサービスが対象になります。

sudo hermes gateway start --system
sudo hermes gateway stop --system
sudo hermes gateway status --system

lingerが必要な理由と、設定しない場合に起きること#

これは最もよくあるつまずきです。サービスをインストールしたのに、夜になるとボットが応答しなくなります。原因はLinuxのユーザーサービスの仕組みにあります。

ユーザーsystemdサービスは、通常、あなたのセッションに紐づいています。SSHで接続するとユーザーマネージャーが起動し、サービスが動きます。ログアウトすると、システムはそのユーザーを非アクティブとみなし、ゲートウェイを含むそのユーザーのサービスを停止します。サーバーへのログインとログアウトを繰り返す運用では、これでは問題です。SSHで接続している間しかボットがオンラインになりません。

lingerモードを使えば解決できます。ユーザーがログインしていないときも、システムがユーザーマネージャーを動作させ続けます。

sudo loginctl enable-linger username

このコマンドを実行すると、ユーザーサービスは単独で動き、ログインを待たずにサーバーの起動時に立ち上がります。lingerを設定しない場合は元の動作に戻ります。SSHを終了するとゲートウェイが停止し、起動時にも立ち上がりません。ドキュメントにも明記されています。

自動再起動付きでHermesをサーバー上のDockerで実行する方法#

Dockerも、エージェントをサーバーで稼働させ続ける方法のひとつです。コンテナに慣れている場合や、エージェントをメインシステムから隔離したい場合に便利です。docker run ... setupで一度設定し、その後、コンテナをバックグラウンドで起動します。

docker run -d \
  --name hermes \
  --restart unless-stopped \
  -v ~/.hermes:/opt/data \
  -p 8642:8642 \
  nousresearch/hermes-agent gateway run

24時間稼働に関わる行の役割は次のとおりです。

• -d — コンテナをバックグラウンドで動かし、ターミナルを開いたままにしません。
• --restart unless-stopped — サーバーの再起動後やクラッシュ後に、Dockerがコンテナを再び立ち上げます。手動で停止した場合に限り、再起動しません。
• -v ~/.hermes:/opt/data — 設定、キー、セッション、メモリをコンテナの外にあるサーバー上に保存するため、コンテナを作り直しても保持されます。

イメージにはもうひとつの保護機構があります。ゲートウェイプロセスはs6スーパーバイザーの管理下で動作します。ゲートウェイがクラッシュすると、コンテナ自体を失わずに数秒以内に再起動します。Dockerが外側からコンテナを動かし続け、s6が内部のプロセスを監視する二重の保護です。

Dockerで運用する場合の違いを覚えておいてください。hermes updateコマンドでは更新されません。Dockerで更新するには、新しいイメージに置き換えます。最新版をダウンロードし、コンテナを作り直してください。

すべてが動作し、再起動後も復旧することを確認する方法#

ユーザーサービスの場合、状態とログは次のように確認できます。

hermes gateway status
journalctl --user -u hermes-gateway -f

VPSで推奨するシステムサービスは、次の範囲を使います。

sudo hermes gateway status --system
sudo journalctl -u hermes-gateway -f

最初は選んだサービス、次はその範囲のログを確認します。これらのunit名は既定の~/.hermes用です。別のHermes homeでは接尾辞が付く場合があるため、statusに出る正確なunit名を使います。システム版のテスト中にユーザーunitを監視しないでください。Hermesのログは~/.hermes/logs/に保存され、秘密情報は自動的にマスキングされるため、サポートに送っても安全です。

次にサーバーを再起動し、エージェントが自動で復帰するか確認します。これがサーバーの重要なテストですが、忘れる人がよくいます。

sudo reboot

サーバーに再接続できたらSSHで入り、システム版はsudo hermes gateway status --systemとシステムjournal、linger付きユーザー版はhermes gateway statusとユーザーjournalを確認します。その後Telegramでボットへメッセージを送ります。あなたが何もしなくても返信があれば、自動起動は正しく設定されています。これこそが目的です。

会話が失われる心配はありません。Hermesはセッションをディスクに書き込むため、ゲートウェイの再起動後も保持されます。さらに、ゲートウェイが応答を送信中にクラッシュした場合、タスクをもう一度実行するのではなく、復旧後にその応答を配信します。24時間稼働するボットには重要な点です。予期しない再起動があっても、会話は途切れません。

サーバー上でターミナルにアクセスできるエージェントを保護する方法#

サーバー上のエージェントは、あなたの監視なしで動作する、ターミナルにアクセスできるプログラムです。まず次の3つの設定を確認してください。

ボットアクセスの制限。 初期設定では、ゲートウェイはアクセスリストに載った人、またはダイレクトメッセージでコードによるリンクを完了した人にだけ応答します。ターミナルにアクセスできるボットには適切な設定です。知らない人がボットにメッセージを送っても、何もできません。アクセスリストには数値IDを使います。たとえばTelegramの場合は次のとおりです。

TELEGRAM_ALLOWED_USERS=123456789,987654321

危険なコマンドの実行前に確認。 破壊的な操作をする前に、エージェントは許可を求めます。確認を無効にするYOLOモードがありますが、無人運転するサーバーでは有効にしないことをおすすめします。確認は、知識のないまま取り消せない操作が起きるのを防ぐためにあります。

完全隔離のためのサンドボックス。 エージェントがサーバーのメインシステムを物理的に見られないようにするには、コマンドをDockerコンテナ内で実行します。

hermes config set terminal.backend docker

これにより、エージェントがターミナルで行うすべての操作が隔離されたサンドボックス内で実行され、稼働中のサーバーには到達できなくなります。エージェントに自律的な操作を任せる場合に、妥当な保護策です。

ボットが応答しない、またはゲートウェイがクラッシュする場合#

ボットが応答しなくなったら、次の順に確認します。まず導入範囲を確認します。システム版はsudo hermes gateway status --systemとシステムjournal、ユーザー版はhermes gateway statusとユーザーjournalを使います。ゲートウェイが動いているのにメッセージが届かない場合、ほぼ必ずプラットフォームの設定に問題があります。ボットトークンが間違っているか、相手がアクセスリストに載っていません。同じHermes homeでhermes gateway setupを再実行し、システム版はhermes gateway status --system、ユーザー版はhermes gateway statusで対象を確認します。設定成功だけでは正しいゲートウェイの稼働は証明できません。

モデルが空の応答や不自然な応答を返す場合は、hermes modelで確認し、プロバイダーとサインイン状態を確かめます。「すべて壊れた」状態から復旧する一般的な手順は、hermes doctor、hermes model、hermes setupの後、システム版はhermes gateway status --system、ユーザー版はhermes gateway statusを確認します。

プロセス全体がクラッシュせずにフリーズする、まれながら厄介なケースについても説明します。systemdサービスにはウォッチドッグタイマーがあります。~/.hermes/config.yamlに次の行を追加し、サービスを再インストールします。

gateway:
  systemd_watchdog_seconds: 120

# 元の導入と同じHermes homeのVPSシステムサービス
sudo hermes gateway install --system --force
sudo hermes gateway status --system

ユーザー版なら、その範囲だけをhermes gateway install --forceで作り直し、hermes gateway statusを確認します。1つを選び、1ゲートウェイの修復のために両方を導入しないでください。

これでゲートウェイは定期的にシステムへ「動作中です」と通知し、通知が止まるとsystemdがプロセスを自動で再起動します。これはsystemdを使うLinux上でのみ機能し、プロセスがフリーズした場合に限られます。サーバーとメッセンジャーの間で通常のネットワーク障害が起きた場合には、ウォッチドッグタイマーは影響しません。

Hermes Agentをサーバーで使う際によくある質問#

Ailootを知ってください。