🐳 導入ガイド · 2026

Hermes Agent Docker: 2026 年の完全な導入ガイド

2026 年に Docker を使用して Hermes Agent をデプロイするための完全なガイド。Mode 1 と Mode 2、本番環境の Compose セットアップ、Windows/WSL2 の注意事項、ARM64 サポート、Telegram ボットの統合、および完全なトラブルシューティング リファレンスをカバーしています。

📅 更新日: 2026 年 4 月⏱ 14 分で読めます✍️EasyClaw編集部
  • X(Twitter) icon
  • Facebook icon
  • LinkedIn icon
  • Copy link icon

Hermes Agent とは何か、そしてそれを実行するには Docker が最適な理由

Hermes Agent は、学習ループが組み込まれた、Nous Research の自律型 AI エージェントです。実行するたびに新しく開始されるステートレス エージェントとは異なり、Hermes は永続的なスキル ライブラリを構築します。完了した各タスクは再利用可能なスキルとなり、時間の経過とともにエージェントの能力が目に見えて向上します。

Hermes ベアメタルの実行は機能しますが、実際の問題が発生します。

  • スキルの状態と会話履歴は単一マシンのファイルシステムに関連付けられます
  • VPS の再構築全体で環境を再現するには手動作業が必要です
  • No プロセスの分離は、暴走したサブプロセスがホストに影響を与える可能性があることを意味します

Docker は 3 つすべてを解決します。コンテナーを適切に構成すると、移植性、分離性が得られ、適切なボリューム戦略を使用すると、イメージの更新後も持続する永続的な学習状態が得られます。

2 つの Docker モードの説明 — 始める前に選択してください

ほとんどのガイドはこの決定を完全にスキップし、docker run にジャンプします。やめてください。 2 つのモードには、セキュリティと運用プロファイルが大幅に異なります。

Mode 1: エルメス インサイド コンテナ Mode 2: ターミナル サンドボックスとしての Docker
何がどこで走るのか Hermes + its runtime live inside the container Hermes はホスト上で実行されます。 Docker はターミナル タスク用に使い捨てのサンドボックス コンテナを作成します
Isolation Hermes itself は分離されています Only the output of terminal tasks は分離されています
State management Volumes handle everything Host filesystem holds Hermes state
Recommended 用 VPS production, team deployments Local dev, quick experimentation
DOCKER_HOST needed No Yes (sibling container setup)

Rule of thumb: VPS にデプロイしている場合、または再現可能な運用環境が必要な場合は、モード 1 を使用してください。Hermes をローカルで実行していて、コード実行のために Docker サンドボックスをスピンアップしたい場合は、モード 2 を使用してください。

Mode 1 — コンテナ内で走るエルメス

ヘルメスとそのすべての依存関係はイメージ内に存在します。名前付きボリュームを介して状態を管理します。コンテナーの再起動ポリシーにより、コンテナーは再起動後も存続します。これが最も一般的な生産パターンです。

  • ホストから完全に分離 - マシンへの誤った書き込みはありません
  • 完全な携帯性。同じ構成ファイルを使用してどこにでも再デプロイ
  • ネイティブで実行するよりもオーバーヘッドがわずかに高い

モード 2 — ターミナル バックエンド サンドボックスとしての Docker

ここで、Hermes はホスト上 (またはコンテナー内) で直接実行され、Docker デーモンを呼び出して、シェル実行用の一時的なコンテナーをスピンアップします。 DOCKER_HOST を設定して構成すると、Hermes がデーモンにアクセスできるようになります。

export DOCKER_HOST=unix:///var/run/docker.sock   # Linux
export DOCKER_HOST=tcp://host.docker.internal:2375  # Windows/Mac (Docker Desktop)

セキュリティ上の注意: コンテナー内に Docker ソケットをマウントすると、ホストへの root に近いアクセスが許可されます。これは、コンテナーのワークロードを完全に信頼できる環境でのみ実行してください。

前提条件と環境セットアップ

イメージを取得する前に、次のことを確認してください。

  • Docker Engine 24+ または Docker Desktop 4.26+
  • 準備ができている LLM API キー: OpenAI (OPENAI_API_KEY)、Anthropic (ANTHROPIC_API_KEY)、またはローカル Ollama エンドポイント
  • ポート 443 でのアウトバウンド インターネット アクセス (LLM API 呼び出し用)
  • 少なくとも 2 GB RAM コンテナに割り当てられます (Ollama を利用したセットアップには 4 GB を推奨)

Windows 固有のセットアップ (Docker デスクトップ + WSL2)

Windows は、ほとんどの Docker デプロイメントが静かに壊れる場所です。以下に注意してください。

ボリュームパスの変換

Windows 上の Docker Desktop は、WSL2 を通じてパスを変換します。構成ファイル内で Linux 形式のパスを使用します。volumes: 定義を構成する場合は、Windows 形式のパス (C:\Users\...) を避けてください。

# Correct — Docker Desktop translates this automatically
volumes:
  - hermes_data:/root/.hermes

ソケットと名前付きパイプの比較

Windows では、Docker は Unix ソケットではなく名前付きパイプを公開します。 Mode 2 の場合、次のように設定します。

DOCKER_HOST=npipe:////./pipe/docker_engine

WSL2のメモリ制限

Windows 上の Docker Desktop では、デフォルトで WSL2 がホスト RAM の 50% に設定されます。 Hermes の動作が遅いと感じた場合は、Windows ユーザー プロファイルに .wslconfig を追加します。

[wsl2]
memory=4GB
processors=2

クイック スタート — 5 分で Docker を使用して Herme エージェントを実行する

公式イメージを取得し、セットアップ ウィザードを実行します。

# Pull the latest image
docker pull nousresearch/hermes-agent:latest

# Run with a persistent volume for state
docker run -it \
  -v hermes_home:/root/.hermes \
  -e OPENAI_API_KEY=your_key_here \
  nousresearch/hermes-agent:latest

セットアップウィザード 最初の実行時に起動します。次のことを求めるプロンプトが表示されます。

  1. LLM プロバイダー (OpenAI、Anthropic、Ollama、またはカスタム エンドポイント) を選択します。
  2. API キーまたはエンドポイント URL を入力してください
  3. ターミナル バックエンド (ネイティブまたは Docker サンドボックス) を構成する

完了したら、セッションが機能していることを確認します。

> hello

Hermes は応答し、スキル ライブラリが初期化されていることを確認する必要があります。新しいコンテナに skill store empty が表示されている場合、それは想定内です。使用することでスキルが蓄積されます。

Docker Compose を使用した本番環境へのデプロイメント

裸の docker run コマンドはテストに機能します。永続的なものについては、Compose を使用します。

version: "3.9"

services:
  hermes:
    image: nousresearch/hermes-agent:latest
    container_name: hermes-agent
    restart: unless-stopped
    stdin_open: true
    tty: true

    environment:
      # Use environment secrets — never hardcode keys in compose files
      OPENAI_API_KEY: ${OPENAI_API_KEY}
      ANTHROPIC_API_KEY: ${ANTHROPIC_API_KEY}
      HERMES_LOG_LEVEL: info

    volumes:
      - hermes_home:/root/.hermes         # Config + conversation history
      - hermes_skills:/root/.hermes/skills # Skill store — see next section

    deploy:
      resources:
        limits:
          memory: 2G
          cpus: "1.5"

    healthcheck:
      test: ["CMD", "hermes", "--health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 15s

    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

volumes:
  hermes_home:
  hermes_skills:

API キーを .env ファイルに保存します (バージョン管理には決してコミットしません)。

OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...

コンテナの再構築後も Herme のスキルを維持する

これは、生産上最も見落とされている懸念事項です。エルメスストアは、一般的な構成とは別にスキルを学習しました。これらのパスを明示的にマウントします。

パス 含まれています 持続しなければなりませんか?
/root/.hermes Config, session history Yes
/root/.hermes/スキル Learned skill library Critical
/root/.hermes/memory Long-term memory store Yes

イメージを更新するとき:

docker compose pull
docker compose up -d   # Named volumes persist automatically

高度なトポロジ — ホスト-Docker (兄弟コンテナ) セットアップ

このアーキテクチャは、Hermes で兄弟コンテナを調整してコードを分離して実行する場合 (たとえば、ユーザーが送信したコードを安全に実行する場合) に使用されます。

┌─────────────────────────────────┐
│         Docker Host             │
│                                 │
│  ┌──────────────┐               │
│  │ hermes-agent │◄──socket──────┤── /var/run/docker.sock
│  │  container   │               │
│  └──────┬───────┘               │
│         │ docker run (sibling)  │
│  ┌──────▼───────┐               │
│  │  sandbox-1   │  (ephemeral)  │
│  └──────────────┘               │
└─────────────────────────────────┘

このトポロジの構成を作成します。

services:
  hermes:
    image: nousresearch/hermes-agent:latest
    restart: unless-stopped
    environment:
      OPENAI_API_KEY: ${OPENAI_API_KEY}
      DOCKER_HOST: unix:///var/run/docker.sock
      HERMES_TERMINAL_BACKEND: docker
    volumes:
      - hermes_home:/root/.hermes
      - /var/run/docker.sock:/var/run/docker.sock  # Socket mount
    group_add:
      - "999"   # docker group GID — adjust to match your host

本番環境のセキュリティに関する注意事項:

  • Docker ソケット プロキシ (Tecnativa/docker-socket-proxy など) を使用してソケット アクセスを制限し、Hermes が実行できる API 呼び出しを制限します
  • マルチテナント環境では Docker ソケットを公開しないでください
  • より強力なホスト分離が必要な場合は、Docker デーモンに userns-remap を設定します。

Telegram ボット経由でエルメスを Claude に接続する

No の書面によるガイドでは現在これについて説明していますが、ビデオ形式でのみ示されています。これが完全なセットアップです。

Step 1: Telegram ボットを作成する

Telegram で @BotFather と会話します。

/newbot
→ Name: Hermes Agent
→ Username: your_hermes_bot
→ Save the token: 123456:ABC-DEF...

ステップ 2: Claude OAuth トークンを取得する

Anthropic コンソールで、claude-3-5-sonnet または claude-opus-4 スコープの API キーを生成します。 ANTHROPIC_API_KEY として設定します。

Step 3: Telegram 設定を構成ファイルに追加します

environment:
  ANTHROPIC_API_KEY: ${ANTHROPIC_API_KEY}
  HERMES_LLM_PROVIDER: anthropic
  HERMES_TELEGRAM_TOKEN: ${TELEGRAM_BOT_TOKEN}
  HERMES_TELEGRAM_ALLOWED_USERS: "your_telegram_user_id"

ステップ 4: Telegram ユーザー ID を見つける

Telegram のメッセージ @userinfobot — 数値のユーザー ID が返信されます。

Step 5: ボットを開始します

docker compose up -d

Telegram でボットにメッセージを送信します。 Hermes は Claude バックエンドを通じて応答します。 HERMES_TELEGRAM_ALLOWED_USERS 制限により、自分のアカウントのみがエージェントと対話できるようになります。

マルチアーキテクチャ導入 (ARM64 / Oracle 無料利用枠 / Raspberry Pi)

nousresearch/hermes-agent イメージはマルチ アーキテクチャ マニフェストとして出荷されます。 ARM64 がサポートされています - ARM ホスト上で明示的にプルします。

# Oracle Free Tier (Ampere A1) or Raspberry Pi 4/5
docker pull --platform linux/arm64 nousresearch/hermes-agent:latest

# Verify the architecture
docker inspect nousresearch/hermes-agent:latest | grep Architecture

Oracle Always Free Tier は、2026 年の Herme にとって最適なゼロコスト ホスティング オプションです。Ampere A1 インスタンスは、4 つの ARM64 コアと 24 GB RAM を提供します。これは、リモート LLM プロバイダーを使用した永続的な Herme の展開には十分以上です。

ARM 固有の既知の問題:

  • 一部の Ollama モデルの量子化 (Q8) は、ARM では実行速度が遅くなります。ローカル推論には Q4_K_M を優先します
  • exec format error を押した場合は、--platform linux/arm64 フラグを使用していることを確認してください
  • Apple Silicon 上の Docker デスクトップは ARM をネイティブに処理します - プラットフォーム フラグは必要ありません

複雑なエージェントのワークフローを管理していますか? EasyClaw をカバーしていますか

Docker で Hermes Agent を実行するのは強力なセットアップですが、複数の AI エージェントを調整し、スキル パイプラインを管理し、複雑なワークフロー全体で永続メモリを維持することが、ほとんどのチームが壁にぶつかります。 EasyClaw は、まさにこれを目的として構築されたデスクトップ ネイティブ AI エージェント プラットフォームです。つまり、インフラストラクチャに悩まされることなく、実稼働グレードのマルチエージェント調整を行うことができます。

  • マルチエージェント パイプラインのビジュアル オーケストレーション - YAML ラングリングなし
  • セッションを存続する永続的なメモリとスキル ライブラリ
  • 完全にお使いのマシン上で動作します - クラウドロックインやデータ漏洩はありません
  • Telegram、Slack、カスタム Webhook とのネイティブ統合
  • 組み込みのスケジューリング、モニタリング、ログ検査
EasyClawを無料でお試しください→

一般的なHermes Agent Docker障害のトラブルシューティング

発生する可能性が最も高い障害の参照表:

失敗 症状 診断 修理
Image pull error manifest unknown docker pull nousresearch/hermes-agent:latest は失敗します 現在有効なタグの場合は Check Docker Hub。 --platform linux/amd64 を試してください
Volume permission denied /root/.hermes でコンテナーが権限エラーで終了します docker run --rm -v hermes_home:/data busybox ls -la /data docker volume rm hermes_home を実行して再作成するか、busybox init コンテナを介して chown で修正します
LLM auth failure ログ内の401 Unauthorized docker logs hermes-agent | grep -i auth Verify API key が .env に正しく設定されています。先頭/末尾のスペースをチェックする
セットアップ ウィザードがハングする Wizard prompts but accepts no input 該当なし -it フラグが docker run に設定されていることを確認します。作成には stdin_open: true + tty: true が必要です
LLM unreachable Connection refused から Ollama またはローカル エンドポイントへ docker exec hermes-agent curl http://host.docker.internal:11434 localhost の代わりに host.docker.internal を使用してください。必要に応じて --add-host を追加します
Skills not persisting Skill library empty after rebuild docker volume ls — ボリュームが存在することを確認します hermes_skills ボリュームに名前が付けられていることを確認し (バインド マウントではない)、作成ファイルがそのボリュームを参照していることを確認します。
ARM exec フォーマットエラー exec /usr/local/bin/hermes: exec format error docker inspect image | grep Architecture --platform linux/arm64 で再プルします
Socket permission denied permission denied /var/run/docker.sock ホスト上の ls -la /var/run/docker.sock Compose の group_add 経由でコンテナ ユーザーを Docker グループに追加する

よくある質問

質問: 私のHermesスキルはdocker compose pull && up -dでも存続しますか?

A: Yes — スキルが名前付きボリューム (バインド マウントや匿名ボリュームではない) に保存されている限り。このガイドの構成セットアップでは、名前付きボリュームとして hermes_skills を使用します。これは、Docker がイメージ更新時に自動的に保存します。

質問: 同じホスト上で複数の Herme インスタンスを実行できますか?

A: はい。各インスタンスに個別の container_name を与え、個別の名前付きボリュームを与えます。また、公開されたポート上で競合しないことを確認する必要もあります。各インスタンスは、独自の独立したスキル ライブラリを蓄積します。

質問: Hermes Agent は Docker 内の Ollama 経由でローカル LLM をサポートしますか?

A: はい。 Ollama を同じ構成スタック内の別のサービスとして実行し、Hermes を http://ollama:11434 に指定します (Docker の内部 DNS を使用)。コンテナ内から localhost を指すことは避けてください。ホスト側 Ollama にはサービス名または host.docker.internal を使用してください。

質問: Docker ソケットを Hermise コンテナにマウントしても安全ですか?

A: ソケット マウントにより、ホストに対するルートに近い権限がコンテナに付与されます。すべてのワークロードを制御するシングルユーザー VPS では許容されます。共有環境またはマルチテナント環境では、ソケット プロキシ (Tecnativa/docker-socket-proxy など) を使用して、Hermes が必要とする API 呼び出しのみをホワイトリストに登録します。

質問: 実稼働環境の Herme 展開の最小サーバー仕様はどれくらいですか?

A: リモート LLM プロバイダー (OpenAI/Anthropic) を使用すると、1 つの vCPU と 2 GB RAM が機能します。セルフホスト型 Ollama バックエンドの場合、少なくとも 8 GB の RAM と適度に最新の CPU が必要です。 Oracle の Ampere A1 無料枠 (4 コア、24 GB) は、両方のシナリオをゼロコストで快適にカバーします。

質問: ヘルメスが学んだスキルと記憶をバックアップするにはどうすればよいですか?

A: docker run --rm -v hermes_skills:/data -v $(pwd):/backup busybox tar czf /backup/hermes-skills-backup.tar.gz /data を使用してください。イメージを更新する前に、ホスト上でスケジュールされた cron ジョブとしてこれを実行し、自動バックアップを実行します。

最終的な考え: チェックリストと次のステップ

学習ループは、Hermes を Docker で実行した他のエージェントと区別するものです。上記の設定により、ループが実際に実行されることが保証されます 蓄積する — リセットではありません — アップデートを出荷するたびに。

デプロイメントを本番対応と呼ぶ前に、次のことを確認してください。

  • hermes_homehermes_skills の両方に対して作成された名前付きボリューム
  • API キーは .env に保存され、Compose にハードコーディングされていません
  • restart: unless-stopped ポリシーがアクティブです
  • ヘルスチェックに合格しました: docker inspect hermes-agent --format='{{.State.Health.Status}}'
  • ログローテーションの構成 (max-sizemax-file)
  • メモリの枯渇を防ぐために設定されたリソース制限
  • セットアップ ウィザードが完了し、最初のチャット セッションが検証されました
  • (Mode 2 の場合) Docker ソケットのマウントが確認され、ソケット プロキシが考慮されます

値をすぐに取得するための次のステップ:

  1. いくつかの実際のタスク (ファイルの要約、コード レビュー、Web 調査) を実行して、スキル ライブラリをシードします。
  2. 10 ~ 15 のタスクの後、hermes skills list を実行して学習内容を確認します。
  3. カスタム スキル テンプレートとメモリ調整をカバーするエージェント構成ドキュメントについては、Nous Research GitHub を参照してください。
  4. Oracle 無料利用枠を利用している場合は、学習した状態を維持しながらダウンタ​​イムなしでイメージを更新できるように cron ベースの docker compose pull && docker compose up -d をセットアップします。