Hermes Agent の使い方 — インストールから「自己進化」の実際まで

短い答え：Hermes Agent は実在する製品で、たしかに他とはっきり違う点が1つあります。ただし「これが違う」と紹介されている当のものは、その点ではありません。いま検索して出てくる記事の多くは、DSPy と GEPA でエージェントが自分を進化させる、と書いています。その仕組みは別のリポジトリにあり、フェーズ1しか実装されておらず、6週間動きがありません。出荷されている本体には入っていません。

実際に動いているものはもっと地味で、そのぶん説明する価値があります。このページはそれと、インストールと初回起動——実際に手が止まる場所——に重心を置いています。

Hermes Agent とは — まず名前の整理から

Nous Research が公開している Python 製のエージェントです。MIT ライセンス。形は4つあります。

• CLI — hermes
• TUI — hermes --tui（HERMES_TUI=1 と同じ。display.interface の設定より常に優先されます）
• ゲートウェイのデーモン — hermes gateway。Telegram、Discord、Slack、WhatsApp、Signal など
• デスクトップアプリ — macOS と Windows 向けのインストーラー

Claude Code や Codex と比べたときの違いは、性能ではなく置き場所です。README の表現がそのまま設計思想になっています。

"It's not tied to your laptop — talk to it from Telegram while it works on a cloud VM."

実行環境も選べます。README は「Seven terminal backends — local, Docker, SSH, Singularity, Modal, Daytona, and Vercel Sandbox」——6種類と紹介している記事をよく見かけますが、7種類です。加えてセッションをまたいで残るメモリと、内蔵の cron スケジューラがあります。

「DSPy/GEPA で自己進化する」はこの製品の話ではありません

DSPy と GEPA を使う仕組みは実在します。ただし置き場所が違います。NousResearch/hermes-agent-self-evolution という別リポジトリで、2026年3月9日作成、スター 4,871、最終プッシュは2026年6月17日——2026年7月31日時点で6週間、動いていません。

中身も「エージェントが自分で進化する」ものではありません。hermes-agent を外側から最適化するパイプラインです。スキルを読み、eval データセットを生成し、GEPA が実行トレースをもとに候補を作り、制約ゲートを通した最良の変種で hermes-agent に対して Pull Request を出す——という流れです。1回 $2〜10、GPU は不要とされています。

実装状況は README の表がそのまま答えです。Phase 1（SKILL.md ファイル）だけが ✅ Implementedで、Phase 2（ツール説明文）から Phase 5（継続的改善ループ）までは 🔲 Planned。

一方、hermes-agent 本体の pyproject.toml、README、スキル関連のドキュメントには、DSPy も GEPA も出てきません。「出荷されている Hermes が GEPA で自分を進化させている」という説明は誤りです。いま curl | bash で入るものに、その機構は入っていません。

実際に起きていること — エージェントが SKILL.md を書く

では本体は何をしているのか。skill_manage というツールで、自分のスキルファイルを自分で書き換えています。進化的探索ではなく、ファイル書き込みです。地味ですが、実際に効くのはこちらで、しかも既定で有効です。

アクションは create / edit / patch / delete / write_file / remove_file。書き先は ~/.hermes/skills/ で、成果物は SKILL.md というただの Markdown です。公式ドキュメントの既定値の説明はこうです。

"By default the agent writes skills freely — including from the background self-improvement review that runs after a turn."

後半が要点です。あなたが見ているターンの中だけでなく、ターンが終わったあとに走るバックグラウンドのレビューからも書き込まれます。気づかないうちにファイルが増えているのは、壊れているのではなく仕様です。

目を通してから通したい場合は、承認ゲートを有効にします。

skills:
  write_approval: true   # false = 自由に書く（既定） | true = 承認が要る

true にすると、すべての書き込みがコミットではなくステージングされます。前景のターンから来たものも、バックグラウンドのレビューから来たものも同じ扱いです。置き場所は ~/.hermes/pending/skills/ で、再起動しても残ります。

/skills pending        # 保留中の書き込みを一覧（1行の要約つき）
/skills diff <id>      # 完全な unified diff
/skills approve <id>   # 適用（'all' も可）
/skills reject <id>    # 破棄（'all' も可）
/skills approval on    # ゲートの ON/OFF を切り替えて保存

メモリ側にも同じ仕組みがあり、キーは memory.write_approval です。

もう1つ。skills.external_dirs で外部のスキルディレクトリを読み込ませている場合、そこは書き込み保護の境界ではありません。Hermes のプロセスに書き込み権限があれば、そのディレクトリのファイルも書き換わります。チームで共有しているスキルを読み取り専用にしたいなら、ファイルシステムのパーミッションで守ってください。

インストール

公式のクイックスタートをそのまま引用します。Linux / macOS / WSL2 / Termux。

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

終わったらシェルを読み直します。

source ~/.bashrc    # reload shell (or: source ~/.zshrc)
hermes              # start chatting!

Windows はネイティブ対応で、PowerShell から。

iex (irm https://hermes-agent.nousresearch.com/install.ps1)

前提条件は Git だけです（Windows 以外）。Linux では curl と xz-utils も必要で、デスクトップアプリを使うなら g++（Debian/Ubuntu なら build-essential）が要ります。それ以外——uv、Python 3.11、Node.js v22、ripgrep、ffmpeg——はインストーラーが揃えます。Windows では可搬版の Git Bash（MinGit、約45MB）も %LOCALAPPDATA%\hermes\git に展開され、システムの Git には触りません。管理者権限も不要です。

Python のバージョン条件には食い違いがあります。pyproject.toml は requires-python = ">=3.11,<3.14"、つまり 3.11・3.12・3.13 に限定しています。一方 FAQ は「Python 3.11 or newer」としか書いておらず、上限に触れていません。手元を 3.14 に上げている環境から手動で入れると合いません。インストーラーに任せれば uv 経由で専用の Python を持ってきます。

置き場所は実行ユーザーによって変わります。

サービス用の非 sudo ユーザーで動かす場合、~/.local/bin が PATH に入っていないことがよくあります。hermes: command not found の大半はこれです。ブラウザ自動化が不要なら、Playwright の重い手順は bash -s -- --skip-browser で飛ばせます。

何か様子がおかしいときは、まず hermes doctor です。OpenClaw から移ってくる場合は hermes claw migrate という専用コマンドがあります。

初回起動とプロバイダ選択

入れただけでは何も話しません。プロバイダを選ぶところまでが実質のインストールです。ここで止まる人がいちばん多いところでもあります。

hermes model

対話的に選べます。そしてAPI キーを1つも用意せずに始められる経路があります——Nous Portal の OAuth ログインです。

hermes setup --portal

これ1つでログイン、プロバイダ設定、Tool Gateway（ウェブ検索、画像生成、TTS、クラウドブラウザ）の有効化まで済みます。ドキュメントの表現は「free OAuth login, no API keys」。手持ちのキーがない状態から最短で動かすならこれです。

なお、この経路の宣伝文句にある「300+ models」はベンダーの自己申告で、公開されたモデルカタログはありません（2026年7月31日確認）。Nous Portal 限定の数字でもあります。そのまま事実として引き写さないほうがいいです。もちろん OpenRouter、Anthropic、OpenAI Codex、Fireworks、Z.AI、Kimi/Moonshot などに自分のキーで繋げますし、Ollama・vLLM・llama.cpp などの自前エンドポイントも「Custom endpoint」として一級市民です。

hermes setup には3つのモードがあり、3つめは知っておく価値があります。Quick Setup（上記の OAuth）、Full Setup（全部自分で通す）、そして Blank Slate。Blank Slate はすべて off から始めます——残るのはプロバイダとモデル、File Operations、Terminal だけで、ウェブもブラウザもコード実行もメモリも cron もスキルも MCP も無効です。

効くのは、platform_toolsets.cli と agent.disabled_toolsets を設定ファイルに明示的に書き出す点です。選ばなかったものは hermes update のあとでも読み込まれません。あとから hermes tools で足せます。何を動かしているか把握したうえで使いたいなら、ここから始めるのが確実です。

公式クイックスタートの原則も引いておきます——「普通のチャットが1往復できないうちは、機能を足さない」。ゲートウェイも cron もスキルも音声も、素のチャットが通ってからです。

コンテキスト 64,000 トークンの下限

ローカルモデルで動かそうとした人が最初にぶつかる壁です。原文を引きます。

"Hermes Agent requires at least 64,000 tokens of context for agent use with tools. Smaller windows are rejected at startup because the system prompt, tool schemas, and working conversation state need enough room for reliable multi-step workflows."

足りないモデルは起動時に弾かれます。実行中に劣化するのではなく、そもそも立ち上がりません。そして Ollama の既定値は、これをほぼ確実に下回ります。ドキュメントによると VRAM 24GB 未満で 4,096 トークン、24〜48GB で 32,768 トークン、48GB 以上で 256,000 トークンです。つまり普通の作業マシンでは初期状態が 4,096 です。

直し方は3つあり、どれか1つでかまいません。

# サーバー全体（推奨）
OLLAMA_CONTEXT_LENGTH=64000 ollama serve

# systemd 管理なら
sudo systemctl edit ollama.service
# Environment="OLLAMA_CONTEXT_LENGTH=64000" を追加し、daemon-reload して再起動

# モデルに焼き込む
echo -e "FROM qwen2.5-coder:32b \n PARAMETER num_ctx 64000" > Modelfile
ollama create qwen2.5-coder-64k -f Modelfile

OpenAI 互換の API（/v1/chat/completions）経由ではコンテキスト長を指定できません。サーバー側か Modelfile でしか設定できず、ドキュメント自身が「Ollama を連携するときの混乱の原因の第1位」と書いています。設定できたかどうかは ollama ps で確認します。

llama.cpp なら -c 64000 を明示します。近年のビルドは既定が 0（GGUF の学習時コンテキストを読む）なので、128k 級のモデルでは KV キャッシュの確保で OOM になります。並列スロットも注意が必要で、-c 64000 -np 4 だと1スロット16k しかなく、下限を割ります。

設定ファイルの置き場所

優先順位は CLI フラグ > config.yaml > .env > 既定値。どちらに書けばいいか迷ったら hermes config set を使えば適切なほうに振り分けられます。設定の変更は mtime を見ているため即座に効き、セッションの再起動は要りません。

セキュリティの初期値

ここは正確に書きます。既定の local バックエンドは、隔離なしであなたのホスト上をそのまま走ります。公式のバックエンド比較表の記載がそのもので、分離欄は "None — runs on host" です。

つまり防御線はサンドボックスではなく承認です。3層あります。

1. approvals.mode: smart（既定）。危険パターンに一致したコマンドを補助 LLM が判定します。低リスクなものはそのコマンド限りで自動承認、明確に危険なものは自動拒否、判断のつかないものだけ人間に上がります。応答待ちは 300 秒で、時間切れは拒否（fail-closed）。cron が無人で危険コマンドに当たったときの挙動は cron_mode で、既定は deny です。

2. ハードライン・ブロックリスト。rm -rf /、fork bomb、マウント済みルートへの mkfs、ブロックデバイスへの dd、rootfs 直下での pipe-to-shell。承認レイヤーが見る前に落ちます。

3. --yolo がその他全部を無効化します。hermes --yolo、セッション中の /yolo、環境変数 HERMES_YOLO_MODE=1 の3通りで入ります。CLI でもゲートウェイセッションでも使えます。便利ですが、上の1層目を丸ごと外す操作だと理解して使ってください。

Docker バックエンドはコンテナ側を固めます（capability を全 drop、no-new-privileges、必要な最小限だけ cap-add）。ただしコンテナ系・リモート系の5バックエンドは、危険コマンドの承認自体をスキップします——コンテナが境界だという設計だからです。Docker にすれば安全になるのではなく、境界が移ると理解するのが正確です。terminal.docker_forward_env に GITHUB_TOKEN のような値を渡していれば、コンテナ内のコードはそれを読めます。

ドキュメントが自分の限界を書いている部分は、引用する価値があります。

"Deny rules are a guardrail against an honest-but-wrong agent… They are not a sandbox against a deliberately adversarial process — for that, use an isolated backend (Docker, Modal) or an egress-restricted environment."

守れるのは「善意だが間違えるエージェント」までで、敵対的なプロセスではない、と明言しています。

いま入れるべきか

この項目を書いている記事をあまり見かけないので、数字をそのまま置きます。最新は v0.19.1（タグ v2026.7.30、2026年7月30日公開）。最初のタグが2026年3月12日で、そこから4か月半で23リリース、週〜隔週のペースです。そして v0.19.0 以降の10日間を、開発元自身のリリースノートがこう記述しています。

"Since v2026.7.20 (v0.19.0, July 20): ~2,789 commits · ~4,748 files changed · ~442,000 insertions · ~392,300 deletions on main. This window is dominated by bug-fix and salvage waves across the gateway, voice subsystem, desktop app, and installer…"

10日で約2,789コミット、そして削除が約392,300行——挿入の約442,000行とほぼ同じ規模です。機能が積み上がっている形ではなく、書いては直している形です。開発元がその期間を「bug-fix and salvage waves に支配されていた」と表現しているのも、そのままの意味に取っていいと思います。

規模も書いておきます。2026年7月31日時点でスター 222,996、フォーク 42,863、オープンな issue が 26,035件。最後の数字は読み方に影響します。この規模になると、個別の issue に付いたリアクション数を深刻度の指標として使えません。反応が少ないから軽いとも、多いから重大とも言えない状態です。

実務的な結論としては、個人の作業マシンで、壊れても困らない範囲なら十分使えます。置き場所を選べる設計と、メッセンジャーから触れる形は、ほかであまり見ないものです。一方でチームの本番運用に置くなら、週単位で作り替わっているものの上に乗るという判断になります。その場合はバージョンを固定し、更新のたびに config.yaml と有効なツールセットを確認するのが現実的です。

そして、この種の製品についてバージョンを指定した手順書は数週間で腐ります。このページも含めてです。読んでいる時点で v0.19.1 から何本かリリースが進んでいるなら、まず公式ドキュメントを開いてください。

出典

本ページの内容はすべて Hermes Agent の公式ドキュメント、GitHub リポジトリ、リリースノートから取得し、2026年7月31日に v0.19.1 基準で確認しました。バージョン、スター数、issue 数はその日の値です。公式ソース間で食い違う箇所（Python の上限バージョンなど）は、片方を選ばずそのまま食い違いとして記載しています。

• github.com/NousResearch/hermes-agent（README、pyproject.toml）
• docs — getting-started/installation
• docs — getting-started/quickstart
• docs — integrations/providers
• docs — user-guide/features/skills
• docs — user-guide/security
• github.com/NousResearch/hermes-agent/releases
• github.com/NousResearch/hermes-agent-self-evolution

Nous Research および Hermes Agent プロジェクトとは無関係です。誤りや古くなった箇所があれば お知らせください。修正します。