はじめに:リリース直後から話題沸騰の自律エージェント Hermes Agent
Nous Research が 2026 年 2 月 26 日 に公開した Hermes Agent は、リリース直後から開発者コミュニティで急速に存在感を増しているプロダクトです。話題性を示すわかりやすい指標として、
GitHub スター数で Anthropic の Claude Code リポジトリを上回った 。(とはいえClaude Code の GitHub リポジトリにはソースコード自体は公開されていないので、その点はご愛嬌です)
Happy to announce that Hermes Agent's repo just surpassed Anthropic's Claude Code repo pic.twitter.com/glH9AoL236
— Teknium 🪽 (@Teknium) April 27, 2026
OpenRouter の Top Apps ランキングで OpenClaw に次ぐ 2 位に躍り出ている(2026年5月)

といった具体的な数字が挙がっており、「またコーディングエージェントか」と片付けられない注目度になっています。一言で説明するなら 「ターミナルで動く OpenClaw 的なもの」 という印象に近く、Claude Code 経験者であれば互換性のあるコマンドが多くすんなり入れます。公式ドキュメントは Hermes をこう定義しています。
IDE(統合開発環境)に縛られたコーディング支援ツールでもなければ、単一のAPIをチャットボット形式にしただけのものでもありません。(中略)実行時間が長くなるほど、自律的に能力を高めていくエージェントなのです。
要するに「IDE に縛られたコパイロットでも、特定 API のチャットラッパーでもなく、長く使うほど賢くなる自律エージェント」を名乗っているわけです。Claude Code や Cursor のようなコーディング特化ツールに慣れた目で見ると、最初は「またエージェント系か」と思うかもしれません。しかし実際に触ってみると、「過去の会話を引き出して動く」という体験は、従来のチャットエージェントとは別物で、新たな可能性を感じさせます。
本記事では、話題性だけでは分かりにくいHermesの本質を、導入手順、メモリの挙動、Claude Code / Codexとのオーケストレーション、常駐ルーチン化の実例から整理していきます。
従来のコーディングエージェントの限界
ほとんどの既存ツールには、次の 3 つの不満が共通しています。
IDE / チャット UI に縛られる:CLI でログインしたターミナルや特定の IDE 拡張からしか動かない。
セッションごとにコンテキストがリセット:前回うまく行った手順を、次のセッションで毎回作り直す羽目になる。
蓄積したノウハウが再利用できない:自分の業務に特化したプロンプトや手順を、ツールが「学習」してくれない。
Hermes Agent はこの 3 つに対して、「CLI 操作または Gateway 経由で Telegram / Discord からも操作可能な実行系」「セッションを越えて成長する Memory」「バンドル済み Skills による外部エージェントの束ね」という形で答えを返してきます。要するに いかにして、過去のセッション中のコンテキストを有効活用するか に振り切った設計です。
ただし、その分 設定の選択肢が非常に多いため、思い通りの環境を整えるまでに時間と手間がかかり、現状では必ずしも万人向けではない と感じるプロダクトでもあります。本記事では「どんな人に刺さるか」も含めて整理していきます。
読み始める前に:セキュリティ上の注意
導入手順に入る前に、Hermes Agent の セキュリティ上の前提 を一度共有しておきます。Hermes Agent を導入する際は 「自分の PC(あるいは VPS)操作に関する権限を全て渡す」 くらいの覚悟で臨んだほうがよいプロダクトです。Hermes は思想・設計として 必要以上にユーザーにパーミッションを求めない方向で作られており、確認ダイアログを挟むのは Dangerous Command 検出時など限られたケースに留まります。裏を返すと、ファイル操作・コマンド実行・外部 API 呼び出しの大部分は ユーザーに逐一確認せず、エージェントの判断で実行されていく ということです。
そのため、Hermes に渡す環境は使い捨ての VPS や、業務環境とは隔離されたサンドボックス にすることを強く推奨します。少なくとも、業務データや個人の重要ファイルが置かれているマシンに直接インストールするのは避けたほうが無難です。
さらに踏み込んで言うと、ターミナル上のエラーメッセージの意味が読み取れない方や、AI が裏側で何をしているかを自分でイメージできない方は、現時点では利用を控えることをおすすめします。動作の意味を解釈できないままパーミッションを渡し続けると、思わぬファイル削除・課金・情報漏洩に繋がるリスクがあるため、まずは Claude Code のように 確認ダイアログが多めのツール で慣れてから、Hermes に進むのが安全な順序です。
導入手順/モデル選定/ツール設定
1. インストール
macOS / Linux であれば公式が提供するインストールスクリプトを実行するだけです。スクリプト側で uv / Python 3.11 / Node.js 22 LTS / Playwright(Chromium) などをまとめて入れてくれるので、事前に手動で揃える必要はほぼありません。ただし以下は事前に用意しておくとスムーズです。
sudo 権限のあるユーザー:Playwright のブラウザ依存ライブラリを apt から入れる際に sudo が要求されます。
`git` と `curl`:リポジトリのクローンとスクリプト取得で使われます(多くの環境では既に入っています)。
空きディスク 2GB 程度:Node.js / Playwright Chromium / Python 仮想環境の合算でそれなりに使います。
(任意)ripgrep / ffmpeg:未インストールでもスクリプトが入れてくれますが、apt からは事前導入も可能です。
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bashWindows は WSL2 環境での利用が推奨されています。インストール後、`hermes --version` でバージョン表示できれば成功です。
依存関係チェックの後、初期セットアップ方法の選択肢が表示されます。
How would you like to set up Hermes?
↑↓ navigate ENTER/SPACE select ESC cancel
→ (●) Quick setup — provider, model & messaging (recommended)
(○) Full setup — configure everythingここでは Quick setup を選び、まずは動かしてしまうのがおすすめです。詳細な設定は後からでも調整できます。
もし本格的に使いたい場合であれば、おすすめは VPS(Linux)への導入 です。Hermes は cron による定期実行や Gateway 経由のチャット操作で「PC が起動していない時間帯」にも非同期で作業を進めてくれるため、ローカルマシンの電源状態を意識せずに済むのは大きなメリットになります。
一方で Mac のローカルにインストールする場合 は、ローカルに置いてあるドキュメントやファイルをそのままコンテキストとして渡しやすいというメリットがあります。Mac 専用のツール(ネイティブアプリ連携など)にもアクセスできるため、両者は一長一短です。まずは挙動を試したいというフェーズでも、macOS / Windows のローカル環境で動かしてみるのが手軽でおすすめです。
なお、こちらの記事では VPS 環境を前提 に解説していきます。
2. Provider を選ぶ
Hermes は単一モデルにロックインされておらず、Quick setup の途中で provider を選ぶと以下のようなメニューが出てきます。
Select provider:
↑↓ navigate ENTER/SPACE select ESC cancel
(●) Nous Portal (Nous Research subscription)
(○) OpenRouter (100+ models, pay-per-use)
(○) LM Studio (local desktop app with built-in model server)
(○) Anthropic (Claude models — API key or Claude Code)
(○) OpenAI Codex
(○) Google AI Studio (Gemini models — native Gemini API)
〜(省略:DeepSeek / xAI / Z.AI / MiniMax / Alibaba DashScope / AWS Bedrock / Azure Foundry など多数)〜
→ (○) Kimi Coding Plan (api.kimi.com) & Moonshot API
(○) Kimi / Moonshot China (Moonshot CN direct API)
(○) StepFun Step Plan (agent/coding models via Step Plan API)
〜(省略)〜
(○) Custom endpoint (enter URL manually)
(○) Configure auxiliary models...
(○) Leave unchangedこのように 30 種類以上の provider が並びますが、ここ最近のフラグシップモデルであれば、全く動いてくれないということはほぼない という印象です。今回の検証では Kimi Coding Plan を選択しました。コーディング用途で安定して走らせやすく、料金面でも扱いやすいプランです。ChatGPT Plus 以上を契約している場合は OpenAI Codex を選ぶのもおすすめで、追加課金なしで Codex モデルを使えるのが利点です。
ただし、Anthropic を選ぶ場合は注意が必要 です。Anthropic のサブスクリプションを契約していればそのアカウントで認証は通りますが、実際に消費されるのはサブスクの利用範囲ではなく、追加の API 利用料として別途課金される 形になります。「Claude Pro / Max を契約しているから無料で使えるはず」と思って繋ぐと想定外の請求が発生する可能性があるため、Anthropic を選ぶ場合はこの点を理解した上で利用してください。
加えて忘れがちですが、Hermes には バンドルスキル として `claude-code` / `codex` / `opencode` が同梱されています[^3]。それぞれ事前に認証を通しておけば、Hermes から Claude Code や Codex CLI をサブエージェント的に呼び出す 使い方ができます。「メインは Hermes、コーディングだけ Claude Code に任せる」というハイブリッド運用がそのまま実現できる点は意外と強力です。
provider の次は Gateway(メッセージングプラットフォーム連携) の設定に進みます。後からでも `hermes setup gateway` でいつでも設定できるため、ここでは Skip を選んで先に進めて問題ありません。
Connect a messaging platform? (Telegram, Discord, etc.)
↑↓ navigate ENTER/SPACE select ESC cancel
(●) Set up messaging now (recommended)
→ (○) Skip — set up later with 'hermes setup gateway'セットアップが完了すると、現時点で利用可能なツール一覧(Tool Availability Summary)が表示されます。
◆ Tool Availability Summary
7/11 tool categories available:
✓ Vision (image analysis)
✗ Mixture of Agents (missing OPENROUTER_API_KEY)
✗ Web Search & Extract (missing EXA_API_KEY, PARALLEL_API_KEY, FIRECRAWL_API_KEY/FIRECRAWL_API_URL, or TAVILY_API_KEY)
✓ Browser Automation (Local browser)
✓ Image Generation (OpenAI (Codex auth))
✓ Text-to-Speech (Edge TTS)
✗ RL Training (Tinker) (missing TINKER_API_KEY)
✗ Skills Hub (GitHub) (missing GITHUB_TOKEN)
✓ Terminal/Commands
✓ Task Planning (todo)
✓ Skills (view, create, edit)`✓` が付いている項目はすぐに使え、`✗` の項目は対応する API キーや認証情報を後から登録すれば有効化されます。今回は Kimi Coding Plan を provider に選んだ状態で、初期から複数のツール群が利用可能になっています。Web 検索系(Exa / Firecrawl / Tavily)や Skills Hub(GitHub)は実運用で効いてくる場面が多いので、必要になったタイミングで追加していくのがおすすめです。
最後に以下の表示が出るので、そのまま Enter を押して chat を起動しましょう。
🚀 Ready to go!
hermes Start chatting
hermes gateway Start messaging gateway
hermes doctor Check for issues
Launch hermes chat now? [Y/n]:Enter を押すと、以下のような Hermes Agent の CUI 起動画面が表示されます。

左側に `HERMES-AGENT` のロゴ、中央に Available Tools と Available Skills の一覧(今回の例では 17 tools / 85 skills)が並びます。下部のステータスバー(`kimi-k2.6 | ctx --`)から provider・モデル・コンテキスト状況を常時確認できる構成です。ここからチャット入力を始めれば、Hermes Agent との対話がスタートします。
3. 事前設定:Web データ取得用に Firecrawl の API キーを入れておく
先ほどの Tool Availability Summary で `Web Search & Extract` が `✗` になっていたとおり、Hermes は Web 検索・スクレイピング系のツールを動かすために、外部サービスの API キーを別途登録する 設計になっています。Exa / Parallel / Firecrawl / Tavily のいずれかを入れれば有効化されますが、ここでは Firecrawl を入れておくことをおすすめします。後ほど紹介するサンプルや業務自動化の活用事例で、Web ページの取得・要約・スクレイピングを多用するためです。
手順は次のとおりです。
1.Firecrawl のサインアップページ でアカウントを作成し、ダッシュボードから API キー(`fc-` で始まる文字列)を発行します。無料枠でも本記事のサンプル程度なら十分動作します。
2.Hermes が読み込む環境変数ファイル `~/.hermes/.env` にキーを書き込みます。
# 既存のコメント行を有効化するか、新規に追記
echo 'FIRECRAWL_API_KEY=fc-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' >> ~/.hermes/.env3.反映確認のために Hermes を再起動し、`Web Search & Extract` が `✓` に変わっていれば設定完了です。
hermes doctor # ツール有効化状況を一覧で確認できます触ってみる:「覚えてと言わなくても、環境を覚えていく」を体感する
ここまでで Hermes と対話する準備が整ったので、Claude Code との違いがもっとも分かりやすい機能を最初の 1 サンプルとして動かしてみます。それは 「ユーザーがメモリ操作を一度も明示的に指示していないのに、エージェントが実作業の副産物として環境情報や前提条件を `MEMORY.md` に書き残し、次セッションで踏まえてくる」 という挙動です。
Hermes は起動時に `~/.hermes/memories/USER.md`(ユーザープロフィール)と `~/.hermes/memories/MEMORY.md`(エージェント側の習慣・学習事項)の 2 ファイルを system prompt に取り込みます。

つまり「対話を始める前から、エージェントは前回までに学んだユーザー像と運用ルールを把持した状態」でセッションが立ち上がります。明示的な「ロード」操作は不要です。
このサンプルでは 明示的に「覚えて」とは一度も言いません。普通に作業を頼むだけです。
ステップ ①:環境点検タスク + 開発スタックの好みをついでに伝える
`hermes` を起動して、以下のプロンプトを実行します。点検依頼に「自分の開発スタックの好み」をひと言添えるだけで、その他に特別な指示はしません。
> このサーバーをこれから自分のメイン開発環境として使っていきたい。
その前提として、まず基本情報を一通り調査して、
今後の開発で標準として扱えるよう整理してほしい。
見ておいてほしいのは、
- OS / カーネル / シェル
- 主要 runtime(Node・Python・Go)のバージョン
- ディスク使用状況
- Docker と git の有無
気になる点があれば教えて。
あわせて、自分が Web アプリを書くときの好みは
React Router v7 + SQLite。今後この環境で何か作るときは
このスタックを前提にしてほしい。Hermes は terminal ツールを使い、必要なコマンドを自分で組み立てて並列に走らせます。実際のセッションでは次のような呼び出しが流れていきます。
┊ 💻 $ uname -a && cat /etc/os-release
┊ 💻 $ echo $SHELL && $SHELL --version | head -1
┊ 💻 $ node --version; npm --version; python3 --version; go version
┊ 💻 $ df -h
┊ 💻 $ docker --version; docker compose version; git --version
┊ 💻 $ which docker; systemctl is-active docker; which sqlite3
┊ 💻 $ free -h && nproc
┊ 💻 $ lsb_release -a; cat /proc/version
┊ 🧠 memory +user: "User's preferred web stack: React Router v7 + SQLite.
Assume this stack for future web app development on this server."
┊ 🧠 memory +memory: "Main dev server: Ubuntu 25.04 (Plucky Puffin), kernel 6.14.0-37,
x86_64. Bash 5.2.37. Node v22.22.2, npm 10.9.7, Python 3.13.3,
Go not installed. Git 2.48.1. Docker not installed. SQLite3 CLI
not installed. 4 vCPU, ~6GB RAM, 2GB swap (mostly used).
Disk: 145GB total, 53GB used, 92GB free."ここで注目してほしいのは 末尾の 2 行です。terminal でコマンドを叩いている最中に、Hermes が `memory` ツールを 2 回呼び出しています。1 つは preference として `+user:`(USER.md 側)に「Web スタックの好み」を、もう 1 つは environment fact として `+memory:`(MEMORY.md 側)に「このサーバーのスペック一式」を、それぞれ自分の判断で書き分けています。ユーザーは一度も「覚えて」と頼んでいません。
そして Hermes が会話側に返してきた応答が以下です。
サーバーの基本情報をまとめました。
=== OS / カーネル / シェル ===
OS : Ubuntu 25.04 (Plucky Puffin)
Kernel : Linux 6.14.0-37-generic (x86_64)
Shell : /bin/bash (GNU bash 5.2.37)
=== 主要 Runtime ===
Node.js : v22.22.2 (npm 10.9.7)
Python : 3.13.3
Go : 未インストール
=== リソース ===
CPU : 4 コア
Memory : 5.8 GB (used 2.8 GB, available ~3.0 GB)
Swap : 2.0 GB (used 1.7 GB — ほぼ枯渇気味)
Disk (/) : 145 GB total / 53 GB used / 92 GB free (37%)
/tmp : tmpfs 2.9 GB (1.1 GB 使用中)
=== ツール ===
Git : 2.48.1 ○
Docker : 未インストール ✕
SQLite3 : CLI 未インストール ✕
=== 気になる点 ===
1. Swap が 2GB 中 1.7GB 使用中。メモリ圧迫が見える。
今後メモリを食う作業(ビルド、コンテナ起動など)をするなら、
スワップ増設または zram 設定の見直しを推奨。
2. Docker が入っていない。
コンテナ開発が必要なら後でインストールする必要あり。
3. SQLite3 CLI がない。
データベース直接確認する機会が多いなら sqlite3 パッケージの
インストールを推奨。
=== 開発スタック(保存済み) ===
Web アプリ: React Router v7 + SQLite を標準前提とします。
今後この環境で何か作るときはこのスタックで進めます。応答自体は「点検レポート + 気になる点 3 つ + 受け取った開発スタックの確認」というシンプルな整理ですが、その裏で memory への自動保存が完了している のがポイントです。ユーザー視点では「サーバーの状態を見てもらいつつ、好きなスタックを口頭で伝えただけ」ですが、Hermes 側は次セッションのための前提を勝手に積み上げ終えています。
ステップ ②:MEMORY.md と USER.md を覗いてみる
`/exit` した後、念のため `~/.hermes/memories/` の中身を `cat` で確認してみます。
$ cat ~/.hermes/memories/MEMORY.md
Main dev server: Ubuntu 25.04 (Plucky Puffin), kernel 6.14.0-37-generic, x86_64.
Bash 5.2.37. Node v22.22.2, npm 10.9.7, Python 3.13.3, Go not installed.
Git 2.48.1 installed. Docker not installed. SQLite3 CLI not installed.
4 vCPU, ~6GB RAM, 2GB swap (mostly used).
Disk: 145GB total, 53GB used, 92GB free on /dev/vda1.
/tmp is tmpfs using 1.1GB/2.9GB.
$ cat ~/.hermes/memories/USER.md
User's preferred web stack: React Router v7 + SQLite.
Assume this stack for future web app development on this server.Hermes が自分の判断で、environment fact は `MEMORY.md` 側に、preference は `USER.md` 側に書き分けています。こちらは一度も「覚えて」と頼んでいません。次のセッションが立ち上がるとき、この 2 ファイルがそのまま system prompt に注入されます。
ステップ ③:別セッションで TODO アプリの最小構成を頼む
ここがハイライトです。`/exit` してターミナルを閉じても構いません。改めて `hermes` を起動して、前回の文脈をひと言も渡さずこう聞いてみます。スタック指定もしません。
> このサーバーで動く自分用の小さな TODO アプリを作りたい。
実装は Claude Code に任せて、コードレビューは Codex で回す
ような分担で進めたい。こちらが渡したのは「TODO アプリを作りたい」「実装は Claude Code、レビューは Codex」という分担だけで、スタック指定も環境前提も一切伝えていません。それでも Hermes は次のように切り出してきます。
TODO アプリを React Router v7 + SQLite で作り、
Claude Code に実装、Codex にレビューを回す流れにしましょう。ここでスタック指定をしていないのに `React Router v7 + SQLite` が出てくるのは、前ステップで `USER.md` に保存した preference を起動時に system prompt から読み出しているからです。続けて、Hermes は手なりで `claude-code` と `codex` のスキルを照会します。
┊ 📚 skill claude-code
┊ 📚 skill codex`claude-code` と `codex` は Hermes にバンドル済みのデフォルトスキルで、認証さえ通っていれば外部 CLI をサブエージェント的に呼び出せます。(すでにClaude CodeとCodexの認証が済んでるものとします)これがあるから、Hermes は実装とレビューをそれぞれ別の CLI に投げる段取りを自分で組めます。
実装フェーズでは Claude Code を `print mode` (`-p`) で叩き、要件を 1 ショットで投げています。
┊ 💻 $ claude -p 'Create a small TODO app using React Router v7 ...
Features: list todos, add todo, toggle complete, delete todo ...'
--allowedTools 'Read,Write,Bash' --max-turns 25 --output-format jsonClaude Code が一通りファイルを書き終えたら、Hermes は `npm run build` で動作確認し、続けて Codex にコードレビューを依頼します。
┊ 💻 $ codex exec 'Review this React Router v7 + SQLite TODO app codebase.
Check for: SQL injection / XSS / CSRF, RR v7 best practices,
better-sqlite3 best practices, type safety, a11y, error handling.'Codex は High / Medium / Low 区分で 10 件ほど指摘を返し、Hermes はそれを受けて自分で `patch` ツールを使い、修正していきます。ユーザーから追加の指示は出していません。

つまり Hermes は、メモリで前提を引き継ぎ、バンドル済みスキルで他のエージェントに作業を流すというオーケストレーションを、最低限のセットアップで成立させられます。
これは Claude Code とは何が違うのか
Claude Code でも、ユーザーが `CLAUDE.md` に「Python 3.11 が入っている、Docker daemon は止めている、ディスクは…」と書いておけば同じ前提で答えてくれます。違うのは 「誰がそれを書くのか」 です。

つまり Hermes では 「普段の作業を頼んでいるだけで、エージェントが勝手に自分用のメモを取り続けている」 という状態が成立します。`CLAUDE.md` 相当の前提資料をユーザーが書く側にまわらなくていい、というのが体験としての差です。preference 系(`USER.md` 側)も同じ仕組みで、何度か作業を頼んでいると応答スタイルや言語の好みが少しずつ蓄積されていきます。
この「勝手に育つメモリ」がこの後紹介する Skills(手続き的記憶)や Cron(時間軸での自律実行)と組み合わさることで、Hermes 全体の自律性が立ち上がっていきます。
メモリの仕組みを整理する:USER.md / MEMORY.md / state.db / External Provider
ここまで触れてきたメモリは、実は 3 層で構成されています。それぞれ役割と寿命が違うので、表で整理します。

つまり `USER.md` / `MEMORY.md` は 常に system prompt にいる短期〜中期記憶、`state.db` は 必要なときだけ呼び出す長期アーカイブ、という分担です。`USER.md` と `MEMORY.md` の文字数上限が小さいのは意図的で、毎セッション固定コストとしてプロンプトに乗るため、肥大化させずに重要事項だけ残す設計になっています。
そしてこれらの外側に、もう 1 段の選択肢として External Memory Providers が用意されています。Honcho・OpenViking・Mem0・Hindsight・Holographic・RetainDB・ByteRover・Supermemory の 8 種類がバンドル済みで、`hermes memory setup` でいずれか 1 つだけ 有効化できます。これらは `USER.md` / `MEMORY.md` を置き換えるものではなく、横に並走するレイヤー として機能し、知識グラフ・セマンティック検索・自動ファクト抽出などを追加します。文字数制約のある built-in メモリでは収まりきらない、より深いユーザーモデリングや横断的な知識管理が必要になったときに足す、という位置付けです。


