Hermes Agent ガイド：あなたと共に成長するオープンソース AI Agent

Hermes の公式サイトでは、このプロダクトを意図的に鋭い表現で説明しています。それは、 決して IDE に紐付いたコーディング用コパイロットではなく、 また 特定のプロバイダーに依存した単なるチャットボットのラッパーでもありません。そのコンセプトは、マシンにインストールし、好みのモデルスタックに接続し、CLI やメッセージングアプリから対話しながら、同じ環境で継続的に動作し続ける永続的なエージェントです。これは、ほとんどのオープンソースエージェントプロジェクトが試みているものよりも野心的なプロダクト定義です。

1. なぜ重要なのか

Hermesが重要な理由は、エージェントツールにおける最大の不満の一つを解消しているからです。 ステートレス性（statelessness）。ほとんどのAIコーディングツールは、1つのセッション、1つのエディタ、1つのプロンプト、1つのプロバイダー、そして1つのマシンに限定された用途には適しています。Hermesは異なる前提に基づいて構築されています。真に有用なエージェントとは、存続し続け、実用的な知識を蓄積し、複数のインターフェースからアクセスできるものであるという考え方です。

だからこそ、リリースの際のフレーミングが共感を呼びました。Nous Research'sの公式Xでの発表では、Hermesを“あなたと共に成長するオープンソースエージェント”と紹介しており、公式ドキュメントでも同じテーゼが繰り返されています。永続的なメモリ、再利用可能なスキル、スケジュールされたジョブ、リモート実行、そしてメッセージングの継続性は、後付けの追加機能ではなく、コアとなる価値提案なのです。

2. Hermesの正体

以下の GitHub repo および official websiteによれば、HermesはNous Researchによって構築されたMITライセンスのエージェントフレームワークであり、ローカル、VPS、またはコンテナ化されたクラウドベースの実行環境で動作させることができます。

クイックスタートガイドでは、もう一つの重要な点が指摘されています。それは、Hermesが model-agnosticであるということです。ドキュメントに記載されているサポート対象プロバイダーのリストは、Nous Portal、OpenAI Codex、Anthropic、OpenRouter、DeepSeek、GitHub Copilot、OAuth経由の Gemini、カスタムのOpenAI互換エンドポイントなど多岐にわたります。プロバイダーの切り替えは、プロダクトのフォークではなく、単なる設定（configuration）として扱われます。

また、アーキテクチャとして大規模コンテキストモデルを強く志向しています。クイックスタートでは、Hermesが少なくとも64Kのコンテキストウィンドウを必要とすると警告しています。これは、マルチステップのツール呼び出しワークフロー、永続的なコンテキスト、および単純なオートコンプリート型のエージェントよりも長いタスクの射

これがメンタルモデルの大きな転換点です。Hermesは単なるツールのチャットUIではありません。それは、 エージェントのためのステートフルなランタイム であり、たまたまインターフェースとしてチャットを公開しているに過ぎません。

3. 仕組み

公式のアーキテクチャドキュメントは、この点において非常に透明性が高いです。Hermesは複数のエントリポイントを、共有された AIAgent コアへとルーティングします。CLI、gateway、ACP、バッチランナー、APIサーバーのすべてが同じオーケストレーションループに供給されます。そのループが、プロンプト構築、プロバイダー解決、ツールディスパッチ、圧縮、および永続化を調整します。

アーキテクチャのページは、なぜHermesが多くの競合よりも広範に感じられるのかも示しています。プロンプトの組み立ては、単なるシステムプロンプトの文字列ではありません。パーソナリティファイル、メモリファイル、スキル、次のようなプロジェクトコンテキストファイル AGENTS.md、モデル固有の指示、およびツール使用のガイダンスなどをレイヤー化します。セッションデータはFTS5を備えたSQLiteに保存され、gatewayセッションとエージェントの状態は各サーフェス間で追跡されます。

セキュリティモデルも同様に明快です。ドキュメントでは、危険なコマンドの承認、コンテナの分離、MCP サブプロセスの認証情報フィルタリング、プロンプトインジェクション対策のコンテキストファイルスキャン、検証済みの作業ディレクトリパラメータなどを含む、7層の多層防御アプローチについて説明されています。これにより Hermes が万全になるわけではありませんが、プロジェクトがオペレーターのリスクについて真剣に検討していることを示しています。

4. スキルシステムこそが真の差別化要因

Hermes にプロダクトの他の部分を納得させるような機能が一つあるとすれば、それはスキルシステムです。公式ドキュメントでは、スキルを「トークンの使用量を最小限に抑えるために、段階的開示パターンを通じてロードされるオンデマンドのナレッジドキュメント」と定義しています。これは、Hermes がすべての手順知識を一度にプロンプトに詰め込まないように努めていることを、洗練された言い方で表現したものです。

スキルは以下に格納されます： ~/.hermes/skills/これらはバンドル、ハブからのインストール、またはエージェントによる作成が可能で、インストールされたすべてのスキルはスラッシュコマンドとして利用可能になります。ドキュメントでは、以下のような例が示されています。 /github-pr-workflow、 /plan、および CLI を介した直接の検索・インストールコマンド。

# Browse and install skills
hermes skills search kubernetes
hermes skills search react --source skills-sh
hermes skills install openai/skills/k8s

# Or use the slash command inside Hermes
/skills

段階的開示モデルこそが、システムを肥大化させることなくエレガントに保っている要因です。Hermes はまず軽量なスキルのメタデータのみをロードし、その後に完全な情報を展開します。 SKILL.md 実際にスキルが必要になった時にのみ読み込み、タスクで要求された場合にのみ詳細なリファレンスファイルをロードします。これは、優れたエージェントツールチェーンが、プロンプトの肥大化による停滞を感じさせず、高速に動作するための設計パターンと同じです。

Hermesはまた、スキルを単発の呼び出し以上のものへと進化させています。cronのドキュメントには、プロンプトが実行される前に1つ以上のスキルをアタッチできるジョブが示されています。これにより、スケジュールされたタスクは、巨大なインライン命令の塊に頼るのではなく、構造化されたワークフローを継承できるようになります。

# Conceptually, Hermes cron jobs can attach skills
hermes cron edit <job_id> --skill blogwatcher --skill find-nearby

# Or you can ask naturally:
"Every morning at 9am, check Hacker News for AI news and send me a summary on Telegram."

5. メモリと検索：強力なアイデアと境界のある設計

Hermes' のメモリシステムは、マーケティング用語としての「メモリ」が通常意味するものよりも、より規律に基づいています。ドキュメントでは、境界が定められた2つのファイルについて説明されています。 MEMORY.md と USER.md、これらには明示的な文字数制限があります。セッション開始時にフリーズされたスナップショットとしてプロンプトに注入されるため、Hermesは自身のプレフィックスを常に書き換えることなく、永続的な事実を保持できます。

この設計が重要なのは、メモリを以下のように扱っているからです。 curated state（精査された状態）、無制限のゴミ捨て場としてではなく。Hermesはプロジェクトの事実、ユーザーの好み、学習した有用な手順を記憶しますが、より深い履歴の想起には、依然として別のセッションストレージとセッション検索に依存しています。アーキテクチャドキュメントには、セッションの永続化がFTS5とリネージトラッキングを備えたSQLiteで行われることが明記されています。

6. はじめかた

公式のクイックスタートは非常にシンプルです。Hermesをインストールし、プロバイダーを選択し、TUIまたはCLIを起動します。その後、ローカル実行にするか、より安全なリモート/コンテナバックエンドにするかを決定します。ほとんどの人にとって、最初のステップは意図的に「退屈」であるべきです。まずは単一のセッションを動作させ、その後にゲートウェイ、スキル、MCP、cronを重ねていくのが良いでしょう。

# Install Hermes Agent
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

# Configure provider and tools
hermes setup

# Start Hermes
hermes --tui

実験ではなく実務でHermesを使用したい場合、次のステップはより安全なターミナル実行環境を整えることです。

# Safer execution backends from the docs
hermes config set terminal.backend docker
hermes config set terminal.backend ssh

# Optional: connect messaging platforms
hermes gateway setup

クイックスタートには最小限のMCPの例も含まれています。これこそが、Hermesを閉鎖的なツールの孤島よりも便利なものにしている要素です。

mcp_servers:
  github:
    command: npx
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "ghp_xxx"

セットアップに関する2つの注意点を明確にしておく必要があります。第一に、公式ドキュメントは依然としてWindowsユーザーにWSL2の使用を案内しています。第二に、課題トラッカーを見ると、インストールや環境管理に関するバグが依然として頻繁に発生していることがわかります。そのため、インストーラーは成熟したエンタープライズ向けパッケージではなく、変化の激しいインフラストラクチャとして扱うべきです。

7. 実践的な例

例1：デフォルトでローカルバックエンド上でリスクのある作業を実行しない

悪い例： Hermesをローカルにインストールし、ターミナルバックエンドをオンにしたままにする ローカルそして、実際のワークステーションに対して広範なシェルコマンドの実行を許可し始める。

良い例： 最初にDockerまたはSSHに切り替え、危険なコマンドの承認を有効にしたままにし、ローカルバックエンドを本番用ではなく利便性のためのオプションとして扱う。

例2：すべてのワークフローを1つの巨大なプロンプトに詰め込まない

悪い例： すべてのタスクが膨大なコンテキストから始まるようになるまで、恒久的な指示を追加し続ける。

良い例： install or create skills for recurring workflows, then let Hermes load them on demand or attach them to cron jobs. This is exactly what the skills system was designed to solve.

例3：メモリを知識の完全性と混同しない

悪い例： Hermesのメモリが、エージェントがシステムのあらゆる詳細を永続的に理解したことを意味すると想定する。

良い例： 安定した事実や設定にはメモリを、履歴にはセッション検索を、より深い信頼できる情報源の取得にはMCPや外部ツールを使用する。その階層化されたモデルの方が、実際のHermesの構造に近い。

8. コミュニティの反応

Hermesに対する広範な反応は、単なるハイプに留まらないという点で興味深いものです。それは、オペレーターによる純粋な興奮、セルフホスト型のエージェントスタックに対する明らかな好奇心、そして実際のワークロード下で製品がその約束を果たせるのかという健全な懐疑心が入り混じったものです。

肯定的な側面として、Nous Researchによるパブリックローンのメッセージは“grows with you”というナラティブを強く打ち出しており、同様の説明がドキュメントやサードパーティの投稿でも繰り返されています。TentenによるLinkedInの投稿でも、メモリとマシンアクセスに関する同様のフレーミングがほぼそのまま引用されており、製品のストーリーがGitHubネイティブな層を超えていかにスムーズに浸透しているかを示しています。

Redditは、この分かれた反応をより率直に捉えていました。ローンチに関する最初のLocalLLaMAスレッドでは、あるコメント主がHermesにメッセージングアカウントを付与するというアイデアに対し、ぶっきらぼうにこう返しました。

“マシンにインストールして、メッセージングアカウントを渡す”……はいはい、そうですね。

その懐疑心は不合理なものではありません。Hermesは、自動化、認証情報、長時間実行プロセス、そしてツールの実行に対する信頼を求めているからです。しかし、同じスレッドのすぐ次のコメントは、否定的というよりは実践的なものでした。

“これをRender + Supabaseで使うつもりだ。”

これがおそらく、現在のHermesを取り巻く状況を最も正確に要約したものでしょう。ピッチを聞いてすぐに安全性を心配する人もいれば、同じピッチを聞いてデプロイ先を計画し始める人もいるのです。

イシュートラッカーは、これがアグレッシブで動きの速いインフラプロジェクトであることを裏付けています。最近のイシューには以下のようなものがあります。 エージェントが自身の実行環境のvirtualenvを破壊した、インストールフローの停止、 container/systemdのgateway-installの不一致。これらはいずれもHermesの価値を損なうものではありません。単に、このリポジトリが実際の導入に向けた圧力と、オペレーターにとってのfootgunsを同時に抱えていることを意味しています。

9. 結論：Hermes Agentは使う価値があるか？

以下のような場合に適しています：

• エディタ内だけでなく、VPSやコンテナ、あるいはリモートマシン上で動作するエージェントを求めている場合。
• スキル、MCP、cron、および検索可能なセッション履歴から構築される、永続的なワークフローを重視する場合。
• バックエンド、認証情報、安全境界、失敗モードなど、オペレーターのような思考に慣れている場合。

以下のような場合は見送るべきです：

• 最小限のセットアップと少ない構成要素で、洗練されたコーディング用Copilotを主に求めている場合。
• ゲートウェイ、コンテナ、config、あるいはバックエンドの選択について考えたくない場合。
• 機能の幅広さや柔軟性よりも、成熟したパッケージングや摩擦の少ない本番環境での安定性を必要とする場合。

10. より大きな展望

Hermesが重要なのは、単なる一つのリポジトリに留まらず、エージェントソフトウェアの異なるモデルを提示しているからです。勝者となるエージェントは、最も派手なチャットUXを持つものではないかもしれません。むしろ、明示的な状態、再利用可能な手順、検索可能な履歴、複数の実行環境、そしてコンテキストスイッチを跨いでも維持されるインターフェースを備えた、インフラのように振る舞うものである可能性があります。

だからこそ、Hermesはオープンスキル、MCPサーバー、マルチエージェントオーケストレーションといった議論に自然に馴染むのです。Hermesはこれらを孤立した機能としてではなく、構成可能なビルディングブロックとして扱っています。もし、これまでの私たちの ポータブルなスキル、カスタムMCPツール、および マルチエージェント・オーケストレーション、Hermesは異端児というよりも、高密度な収束点のように見えます。

Hermes自体が主要なオープンソース・エージェント・ランタイムになるかどうかは、まだ未知数です。しかし、プロダクトの方向性はすでに明確です。人々が実際に使い続けるエージェントとは、十分な記憶力を持ち、適切に権限を委譲でき、十分に安全に動作し、そして実際の業務が行われるあらゆる場所で利用可能なものです。

11. よくある質問

12. すべての情報源 & リンク

一次情報源

• Hermes Agent GitHub リポジトリ
• Hermes Agent 公式ウェブサイト
• 公式ドキュメント・ホーム
• クイックスタート
• アーキテクチャ
• セキュリティ

ドキュメント

• スキル・システム
• 永続メモリ
• スケジュール済みタスク (Cron)
• ツール & ツールセット
• 設定

コミュニティ

• X上のNous Research
• Reddit: r/LocalLLaMAのローンチスレッド
• LinkedIn: Tentenの投稿
• GitHub issues

参照されているイシュースレッド

• エージェントが `uv venv` を実行することで、自身の実行環境（venv）を破壊する可能性がある
• インストールがブロックされました
• systemdを使用したコンテナ内へのGatewayインストール

ウェブソース

• Nous Research プロダクトページ
• BuildMVPFast による分析

内部リンク

• エージェントスキルの習得
• 独自の MCP サーバーを構築する
• エージェントオーケストレーションガイド
• Vibe Coding ガイド