AIエージェント「Hermes Agent」を Docker に閉じ込めて、Mac の Desktop アプリから安全に使う

2026年10月8日

ターミナルやブラウザを実際に操作してくれるオープンソースの AI エージェント「Hermes Agent」を試してみました。CLI・Desktop アプリ・チャット（Telegram や Slack）など、いろいろな入口から同じエージェントを使えるのが特徴です。

前回の記事で書いたように、AI社員の仕組みでは、AI に「見せる範囲」を仕組みで区切れなかったことが一番の反省でした。エージェントをコンテナに閉じ込めて動かすのは、その答えになりそうだと思ったのも、試してみた理由の1つです。

ただ、使い始める前にどうしても気になったことがあります。

「これ、Desktop アプリで動かしたら PC 全体を触れる状態になるのでは？」

調べた結果、エージェント本体を Docker コンテナに閉じ込め、Desktop アプリは「窓」として接続するだけの構成にしました。

この記事でわかること

AI エージェントを「PC 全体を触れる状態」にせずに動かす考え方
backend はコンテナ、UI は Mac の Desktop アプリ、という分離構成の作り方
Desktop アプリが勝手にローカル版をインストールしてしまう罠と回避策
ChatGPT Plus・Claude Pro などのサブスクのうち、何がエージェントの「頭脳」に使えるか

環境

項目	内容
マシン	iMac M3（メモリ 16GB）
Docker	Docker Desktop
Hermes（backend）	公式イメージ `v2026.9.24`
Hermes（Desktop）	同じタグから自前ビルド
LLM	ChatGPT Plus（Codex のサブスク）

Desktop アプリでも CLI でも、危険度は同じ

Desktop か CLI かは関係なく、「コマンドをどこで実行するか」で安全性が決まります。

Desktop アプリも CLI も、中身は同じ Python の backend が自分のユーザー権限で動いている
初期設定のまま Mac 上で動かすと、ターミナルツールは ~/.ssh や ~/.aws も読めてしまう
Hermes にも安全装置（危険なコマンドの承認、書き込み先の制限、拒否ルールなど）はあるが、公式ドキュメント自身が「OS レベルのサンドボックスではない」と明言している

つまり、本当に見える範囲を絞りたいなら、コンテナで隔離するしかないということです。

構成の選び方

Docker の使い方には2通りあります。

方式	内容	隔離の強さ
A. 本体ごとコンテナ	Hermes 全体をコンテナで動かし、Desktop アプリは URL と認証で接続するだけ	◎ マウントしたフォルダしか見えない
B. コマンド実行だけコンテナ	本体は Mac、コマンド実行だけ別コンテナ	○ 本体は Mac 上にいる
素のまま	Mac 上で直接動かす	△ ユーザー権限で全部見える

今回は A 方式にしました。理由は3つです。

隔離が一番強い
将来 VPS に移すときも構成がほぼ変わらない（変わるのは接続先の URL だけ）
常時稼働させてチャットで指示する、いわゆる「AI 社員」的な使い方の入口にもなる

今:   Mac の Desktop アプリ ──(localhost)──> Mac 上の Docker コンテナ
将来: Mac の Desktop アプリ ──(SSH/VPN)───> VPS 上の Docker コンテナ

コンテナから見える Mac のフォルダは、Hermes の設定・記憶を置く ~/.hermes と、作業用の ~/hermes-workspace の2つだけにしています。

構築する前に決めたこと

作業フォルダはどう渡す？

起動中のコンテナに後からマウントは足せません。頻繁に変えるなら、親フォルダを1つだけマウントしておき、その中に作業対象を置くのが楽です。

ここで1つ注意があります。~/hermes-workspace の中にシンボリックリンクや Finder のエイリアスを置いても、コンテナからは見えません。リンク先の Mac のパスがコンテナの中に存在しないからです。セキュリティ的にはむしろ正しい挙動です。

既存のプロジェクトを触らせたい場合は、向きを逆にすると解決します。

mv ~/dev/project-a ~/hermes-workspace/project-a      # 実体を workspace へ移す
ln -s ~/hermes-workspace/project-a ~/dev/project-a   # Mac 側はリンクで今まで通り使う

git 操作はどこまで任せる？

公式イメージには git と ssh クライアントが入っているので、編集と commit はそのままできる
~/.ssh は絶対にマウントしない。push させるなら、対象リポジトリ限定・期限付きのトークンを使う
運用としては 「エージェントは commit まで、push は人間」 にした

サブスクは「頭脳」に使える？

ここが一番勘違いしていたポイントでした。Hermes を動かすには、エージェントの「頭脳」になる LLM が必要です。手持ちのサブスクが使えるかはサービス次第でした。

サブスク	Hermes の頭脳にできるか
ChatGPT Plus（Codex）	✅ ChatGPT のアカウントでログインするだけ。API キーも Codex CLI も不要
Claude Max	△ ログインは可能だが、追加クレジットの購入が前提
Claude Pro	❌ 不可（API キーの従量課金なら可）

ただし Claude Pro も、「部下」としてなら活かせます。Hermes に同梱されているスキルで、Hermes がターミナルから Claude Code（claude -p）を呼び出す形です。

違いが出るのは技術的な理由ではなく、サービス提供側の方針です。OpenAI は ChatGPT のアカウントで Codex 向けモデルを使う仕組みを他のツールにも開いていて、Hermes はそれに乗っています。Anthropic の Pro / Max の枠は、Claude アプリや Claude Code など自社製品で使う前提です。

⚠️ ここは Hermes のドキュメントと私の理解に基づいています。各社の規約や提供方針は変わるので、実際に使う前に最新の利用規約を確認してください。

アップデートはどうする？

Hermes は毎日のように更新されるので、イメージのバージョンを固定（v2026.9.24）
週1回くらいタグを書き換えて docker compose pull && docker compose up -d
コンテナの中で更新コマンドは使わない（コンテナは使い捨ての前提）
リポジトリに入っている compose はソースからビルドする設定なので、運用には使わない

構築手順

1. docker-compose.yml を用意する

services:
  hermes:
    image: nousresearch/hermes-agent:v2026.9.24   # latest は使わず固定
    container_name: hermes
    restart: unless-stopped
    command: ["serve", "--host", "0.0.0.0", "--port", "9119"]
    environment:
      HERMES_UID: "501"   # Mac のユーザーに合わせる
      HERMES_GID: "20"
    volumes:
      - ~/.hermes:/opt/data
      - ~/hermes-workspace:/workspace
    ports:
      - "127.0.0.1:9119:9119"   # Mac の中からだけ接続できる
    shm_size: "1gb"             # ブラウザ自動化用
    mem_limit: 4g
    cpus: 2

ポイント

Desktop アプリが接続する先は hermes serve
コンテナの中では 0.0.0.0 で待ち受けるので、Hermes 側で認証が自動的に必須になる
Mac 側には 127.0.0.1 でだけ公開するので、外からは接続できない
HERMES_UID を Mac のユーザー ID に合わせておくと、ファイルの所有者がずれない

2. 認証と設定を書く

# ~/.hermes/.env（chmod 600）
HERMES_DASHBOARD_BASIC_AUTH_USERNAME=<ユーザー名>
HERMES_DASHBOARD_BASIC_AUTH_PASSWORD=<ランダムに生成>
HERMES_DASHBOARD_BASIC_AUTH_SECRET=<ランダムに生成>   # 再起動でログアウトされないように

# ~/.hermes/config.yaml
database:
  journal_mode: delete

2つ目の設定は macOS 特有の落とし穴への対策です。Docker Desktop のフォルダ共有の上では、SQLite の WAL モードが壊れることがあると公式ドキュメントに書かれています。新規作成なら Hermes が自動で回避しますが、念のため明示しました。

3. 起動して確認する

docker compose pull && docker compose up -d
curl -s http://127.0.0.1:9119/api/status   # auth_required: true になっていれば OK
docker exec hermes hermes doctor

ログに HERMES_BACKEND_READY が出れば backend の準備は完了です。ブラウザ自動化用の Chromium（Apple Silicon 用）も同梱されていました。

スペックの割り当て

項目	Docker Desktop 全体	Hermes コンテナの上限
メモリ	6GB	4GB
CPU	4〜6	2

公式の推奨はメモリ 2〜4GB・2コアです。ブラウザ自動化を使うなら多めにしておくと安心です。

ハマりポイント3つ

罠①：Docker Desktop の設定を変えたら、コンテナもイメージも消えた

CPU などのリソース設定を変えたところ、docker ps -a が空になり、イメージも消えていました。

通常、CPU やメモリの変更だけならコンテナは残るはずです。同時に Docker 内部の保存方式が切り替わったなどで、既存のものが見えなくなった可能性があります。

ただ、データは Mac 側の ~/.hermes にあるので無傷でした。docker compose up -d を打つだけで元に戻りました。

コンテナは使い捨て前提で設計しておくと、こういう事故が怖くなくなります。

罠②：Desktop アプリが `~/.hermes` に勝手にローカル版をインストールした

最初にダウンロードした Desktop アプリを起動したら、~/.hermes の中に合計 3GB 以上のファイル（ローカル版の Hermes 本体やツール類）が作られていました。

問題は、~/.hermes はコンテナにマウントしているのと同じフォルダだということです。2つの Hermes が同じデータを触る危険な状態になってしまいます（公式も「同じデータフォルダを2つのプロセスで使うな」と注意しています）。手動で削除しました。

罠③：ダウンロードした「Hermes.app」は、実はインストーラーだった

罠②の原因はこれでした。/Applications/Hermes.app の中身を調べると、12MB ほどのセットアップ用インストーラーでした。

ソースを ~/.hermes にダウンロードして、Desktop アプリをその場でビルドするもの
画面には「Install Hermes」しかなく、既存の backend に接続する道がない
公式サイトでは macOS 向けにこのセットアップ版しか見つからず、GitHub の Releases にも添付されていなかった

解決策は、backend と同じタグから Desktop アプリを自分でビルドすることでした。

# Node 22/24 が必要だった（手元の 23 は対象外）→ nvm で 24 を用意
brew install nvm
nvm install 24

# backend と同じタグを worktree で取り出す（main は触らない）
cd hermes-agent
git worktree add ../hermes-agent-desktop-v2026.9.24 v2026.9.24
cd ../hermes-agent-desktop-v2026.9.24
nvm use 24
npm ci

cd apps/desktop
CSC_IDENTITY_AUTO_DISCOVERY=false npm run pack   # 署名なしの .app を作る
ditto release/mac-arm64/Hermes.app /Applications/Hermes.app

できた .app は約 339MB で、中身は本物のアプリ
署名していないので、初回は Finder で右クリック →「開く」
アプリ内の自動更新は使えないので、backend のタグを上げるときに同じタグでビルドし直す

Desktop アプリから接続する

最初の画面で「Connect to existing Hermes」を選ぶ

右側の「Install Hermes locally」は選ばないように注意が必要です。画面の下に、ローカルのフォルダにインストールすると書かれています。

URL を入れてサインインする

URL は http://127.0.0.1:9119 です。認証方式は自動で判定され、ユーザー名とパスワードのサインイン画面が出ます。

画面の下に「PUBLIC BIND · AUTH REQUIRED」と出ているのが、認証が効いている証拠です。

「Test connection」→「Apply and reconnect」で接続は完了です。念のため、~/.hermes にローカル版が作られていないこと、Mac 側に Hermes の backend プロセスがいないことも確認しました。

LLM を ChatGPT Plus（Codex）にする

ここでも注意があります。「モデルをローカルで実行」は選ばないほうがよいです。backend がコンテナの中にいるので、GPU を使えないコンテナの中にモデルがダウンロードされてしまいます。

「その他のプロバイダー」を開いて ChatGPT or Codex Subscription を選び、ブラウザで ChatGPT にログインするだけで接続できます。API キーも Codex CLI も要りません。

使えるモデルはアカウントに応じて自動で取得され、Plus では14モデルが表示されました。デフォルトは gpt-6-luna で、あとからいつでも変更できます。

画面下に 127.0.0.1:9119・ゲートウェイ準備完了・クライアントとバックエンドのバージョンが表示されれば完成です。

今のところ、構築して接続したところまでで、本格的に何かを任せるのはこれからです。

ローカル LLM（Ollama）はどうする？

Dockerfile の変更は不要。LLM は Mac 側で動かす（Mac の Docker からは GPU が使えないため）
コンテナからは http://host.docker.internal:11434/v1 で Mac の Ollama に届くことを確認した
iMac M3 16GB（うち 6GB を Docker に割り当て）だと、実用は 7〜8B のモデルくらい
7B クラスは、エージェントの頭脳としては力不足（ツールを何度も呼ぶ処理で崩れやすい）。要約や分類などの補助向き

最終的な役割分担はこうしました。

役割	担当
Hermes の頭脳	Codex（ChatGPT Plus）
コーディングの実作業	Claude Code（Pro）を部下として呼ぶ（予定）
補助的な処理	Ollama のローカルモデル（予定）

`~/.hermes` のバックアップの考え方

~/.hermes には設定・記憶・スキルが育っていくので、バックアップしたくなります。ただし丸ごと GitHub に上げるのは NGです。

種類	例	GitHub（private）
設定	`config.yaml`	✅
育つ資産	記憶、スキル、定期ジョブ	✅
秘密情報	`.env`、認証情報	❌
会話履歴	`state.db`、セッション	❌ 秘密が混ざりうる・書き込み中だと壊れる