要約

Hermes Agentを個人のMacで安全に試すなら、Hermes本体をDockerコンテナ内に置き、Slack・Desktop・CLIはその同じバックエンドへ接続する構成が扱いやすい。

ポイントは、Hermes Desktopを「エージェント本体」ではなく「操作画面」として使うことだ。DesktopのRemote gatewayはDocker内Hermesへ接続するための入口であり、Slackのメッセージを受け取るMessaging Gatewayとは役割が異なる。

この記事では、ローカルPC上でHermesを隔離しながら、過去のナレッジを参照させ、成果物だけを書き込ませる構成を整理する。

タグ: Hermes Agent、AIエージェント、Docker、サンドボックス、Slack、Desktop、セキュリティ

なぜエージェントを隔離するのか

AIエージェントは、質問に文章で答えるだけではない。許可されたツールを使って、ファイルを読み、ブラウザを操作し、定期実行し、子エージェントへ仕事を分担できる。

便利である一方、ホストPC上で直接動かすと、次の情報や権限へ到達する可能性がある。

  • SSH鍵やクラウド認証情報
  • ブラウザのCookieやログイン済みセッション
  • 個人文書や既存リポジトリ
  • パスワードマネージャー
  • Dockerソケット
  • Webページに埋め込まれた悪意ある指示

そこで、Hermes本体をDockerコンテナ内で動かし、ホスト側から見せる情報を明示的に限定する。

全体構成

flowchart LR
    U["利用者"] --> D["Hermes Desktop<br>GUI"]
    U --> C["CLI<br>ターミナル"]
    U --> S["Slack"]

    D -->|"Remote gateway<br>localhost + 認証"| H["Docker内 Hermes Agent"]
    C -->|"docker compose exec"| H
    S -->|"Socket Mode"| G["Messaging Gateway"]
    G --> H

    H --> V["Hermes専用volume<br>設定・認証・セッション・Skills"]
    H --> R["ナレッジリポジトリ<br>読み取り専用"]
    H --> W["成果物inbox<br>読み書き可能"]
    H --> L["LLMプロバイダー"]
    H --> B["専用ブラウザ"]

中心にあるHermes Agentは一つだけだ。Desktop、CLI、Slackは、同じHermesへ指示を届ける異なる入口になる。

この形にすると、利用する画面が変わっても、モデル設定、Skills、Cron、セッション、成果物を同じ実行環境に集約できる。

「Remote gateway」とは何か

Hermes Desktopの設定画面には、Local gateway、Hermes Cloud、Remote gateway、Connect via SSHなどの選択肢がある。

今回使うRemote gatewayは、Desktopアプリが別の場所で動いているHermesバックエンドへ接続するモードだ。「別の場所」といっても、必ずしも別のPCとは限らない。Mac上のDockerコンテナも、Desktopアプリから見れば別の実行環境になる。

Hermes Desktop
    ↓ HTTP / WebSocket
http://127.0.0.1:9119
    ↓ Dockerのポート転送
Docker内のHermesバックエンド

Desktopは画面表示、入力、プレビューなどを担当する。ファイル操作、ブラウザ操作、LLM呼び出しなどの実処理はDocker側で行われる。

この「画面と実行環境の分離」が重要だ。DesktopをMacへ入れても、Remote gatewayへ接続している限り、エージェントの実行境界はDocker側に残る。

Slack Gatewayとの違い

Remote gatewayとSlack Gatewayは、名前が似ているが別物だ。

Slack Gatewayは、SlackからのDM、メンション、スレッドを受け取る常駐プロセスだ。一方、DesktopのRemote gatewayは、GUIから同じHermesを操作するための接続設定である。

両方を同じHermesホームと設定へ接続すれば、SlackとDesktopで同じSkillsやCronを利用できる。

Local gatewayを使わない理由

DesktopのLocal gatewayを選ぶと、DesktopがMac上でローカルHermesバックエンドを起動する。

それ自体が悪いわけではないが、Docker内Hermesをすでに運用している場合は、次のように環境が二重化しやすい。

Mac上のローカルHermes
Docker内のHermes

二重化すると、次の区別が分かりにくくなる。

  • どちらにモデル認証を設定したか
  • Skillsがどちらに保存されたか
  • Slackがどちらへ接続しているか
  • 成果物がどちらにあるか
  • どちらのエージェントがホストファイルへアクセスできるか

Dockerをセキュリティ境界として採用するなら、DesktopはRemote gatewayモードにし、Docker内Hermesを唯一のバックエンドにする方が明快だ。

ナレッジは読めるが、既存ファイルは変更させない

過去のナレッジをHermesに活用させるには、ナレッジリポジトリをコンテナへマウントする。

ただし、リポジトリ全体を書き込み可能にする必要はない。おすすめは、入力と出力を分ける構成だ。

volumes:
  # 既存ナレッジ全体は参照専用
  - /path/to/knowledge:/workspace/knowledge:ro

  # Hermesの成果物置き場だけ書き込み可能
  - /path/to/knowledge/inbox/hermes:/workspace/knowledge/inbox/hermes:rw

Hermesは過去の文書を横断して読み、新しいレポートや下書きを専用inboxへ保存できる。一方、既存ナレッジの直接編集や削除はOSレベルで拒否される。

成果物は人間または別のレビュー担当エージェントが確認してから、正式なディレクトリへ移動し、Gitへコミットする。

読み取り専用でも情報漏えいは防げない

読み取り専用マウントが防ぐのは、主に改ざんと削除だ。情報の読み出しと外部送信までは防がない。

Hermesにブラウザと外向き通信を許可している場合、悪意あるWebページから「ローカル文書の内容をフォームへ入力せよ」と誘導される可能性がある。

そのため、共有前に次を確認する。

  • APIキーやアクセストークンがないか
  • 秘密鍵がないか
  • パスワードや本番認証情報がないか
  • 署名付きURLが残っていないか
  • 顧客情報や公開不可の個人情報がないか

正規表現による秘密情報スキャンは有効だが、万能ではない。ナレッジ全体を渡す判断そのものが、一つのアクセス許可であることを理解しておく必要がある。

ツールは明示的な許可リストにする

プラットフォームごとの暗黙の既定値に頼らず、使うツールだけを明示する。

調査・ナレッジ作成を中心にするなら、最初は次の範囲が扱いやすい。

  • file: ナレッジ参照と成果物保存
  • skills: 定型手順の再利用
  • browser: 公開Webページの調査
  • cronjob: 読み取り中心の定期処理
  • delegation: 複数観点への調査分担

一方、次のツールは影響範囲が広いため、必要になるまで無効にする。

  • terminal
  • code_execution
  • computer_use

Skillの作成・変更も自動承認にはせず、書き込み時に人間が確認する。

Desktopバックエンドはlocalhost限定にする

同じMac上のDesktopからだけ接続するなら、Dockerのポート公開先をlocalhostへ限定する。

ports:
  - "127.0.0.1:9119:9119"

これにより、LAN上のほかの端末やインターネットから直接アクセスされない。さらにユーザー名・パスワード認証を必須にする。

外部ネットワーク → 接続不可
同じMac → 認証後に接続可能

将来、別PCやスマートフォンから接続したい場合は、ポートを直接インターネットへ公開せず、TailscaleなどのVPNを利用する。公開ネットワークから接続する場合は、単純な共有パスワードではなくOAuthなどを検討する。

パスワードマネージャーとの付き合い方

管理用パスワードを1Passwordなどへ保存するのはよい。ただし、Hermes自身にパスワードマネージャー全体へのアクセス権を与えるべきではない。

おすすめは次の分離だ。

  • 実パスワードはパスワードマネージャーへ保存
  • Hermes側にはパスワードのscryptハッシュだけを保存
  • Desktopのログイン時に人間がパスワードを入力
  • Hermesコンテナへopコマンドや1Passwordセッションを渡さない

Hermesにopを許可すると、Dashboard接続用パスワード以外の保管項目まで取得できる可能性がある。エージェントが必要とする最小の秘密だけを渡すことが重要だ。

インターフェースの使い分け

入口は複数でも、バックエンドは一つにする。これが運用を単純にする。

接続確認の方法

DesktopがDocker内Hermesへ接続できたら、最初に副作用のない質問を送る。

現在使用しているモデル名と、
アクセス可能なワークスペースのルートパスを教えてください。
ファイルの作成・変更はしないでください。

期待する結果は次の通り。

  • Docker側で設定したモデル名が返る
  • ナレッジのマウント先が見える
  • ホストOS固有のホームディレクトリは見えない
  • 許可していないTerminalやComputer Useを使わない

次に、既存ナレッジを一件読ませる。最後に、専用inboxへ小さなMarkdownを保存させ、ホスト側からファイルが作られたことを確認する。

まとめ

Hermes DesktopのRemote gatewayは、Desktopを別のHermes実行環境へ接続するための機能だ。Docker内Hermesへ接続すれば、使いやすいGUIを得ながら、エージェントの実行境界をコンテナ側へ残せる。

設計の要点は次の五つになる。

  1. Hermes本体はDocker内に一つだけ置く
  2. Desktop、Slack、CLIは同じHermesへ接続する
  3. ナレッジ全体は読み取り専用にする
  4. 成果物用inboxだけを書き込み可能にする
  5. ツール、ネットワーク、認証情報を最小権限にする

GUIの便利さとサンドボックスは両立できる。重要なのは「どの画面を使うか」ではなく、「エージェントの処理がどこで実行され、何が見えて、何を書き換えられるか」を明示することだ。

出典