hermes-agent：GitHub 67,000 Starの「自己成長型AIエージェント」の技術的仕組み

はじめに

2026年4月現在、GitHub Trendingで圧倒的な存在感を放っているリポジトリがあります。Nous Researchが開発したhermes-agentです。2026年2月の本格公開から2ヶ月で累計67,000 Starを超える急成長を見せており、2026年4月時点では67,400 Star以上を記録しています。2026年4月8日にはv0.8.0（v2026.4.8）がリリースされ、209件のPRがマージされた大型アップデートが投入されたばかりです。

hermes-agentが注目される最大の理由は「自己成長型（Self-Improving）」という設計思想にあります。実行結果から学習し、スキルとして蓄積し、次回以降の実行精度を自律的に向上させる。さらに対話を経るたびに「ユーザー自身のモデル」を内部で更新し続けます。従来の「ステートレスなAIエージェント」とは根本的に異なるアプローチです。

この記事では、hermes-agentの背景、4層の自己改善メカニズム、Honchoによるユーザーモデリング、他OSSエージェントとの違いまでを掘り下げます。

Nous Researchとは何者か

hermes-agentを語る上で、開発元であるNous Researchの理解は欠かせません。ブランド抜きでリポジトリだけ見ると、この急成長の理由を見誤ります。

Nous Researchは、オープンソースLLMのファインチューニングで2年以上の実績を持つAI研究組織です。代表作のHermesモデルシリーズはLlama・Mistral系のベースモデルを独自の合成データで調整したもので、OSSコミュニティのリファレンスモデルとして広く使われています。

• Hermes 2：Llama 2 / Mistral ベースの初期世代。指示追従で定評を得る
• Hermes 3：Llama 3.1（8B / 70B / 405B）をファインチューニング。内部モノローグ、XMLタグによる構造化出力、Mermaid図生成、ステップ付き推論を備えた「ステアラブルなモデル」
• Hermes 4：Hermes 3 の50倍のトークン量で訓練したハイブリッド推論モデル。数学・科学での推論、スキーマ準拠の出力、創造的執筆を大幅に改善

ポイントは、Hermes 3 以降「ニュートラルアライメント」と呼ぶ設計を採っていることです。ベースモデルに強い安全ポリシーを上書きするのではなく、ユーザーのシステムプロンプトに忠実に従う。この「モデルを道具として扱える」思想が、そのままhermes-agentにも継承されています。

商業部門のNous Research Inc.はVCから資金調達を受けつつ、コア技術をMITライセンスで公開するハイブリッド形態です。「自社でベースモデルを訓練しているチームが、そのモデルを最大限活かせるエージェントを自作した」という背景が、他のOSSエージェントにはない説得力を生んでいます。

爆発的な成長曲線

hermes-agentの成長は単なる一時的なバズを超えています。

• 2025年7月：初期コミット開始
• 2026年2月：v0.6系として本格公開
• 2026年2〜3月：急速にStarを積み上げ、1ヶ月で約30,000 Starに到達
• 2026年4月8日：v0.8.0リリース。209 PRマージ、82 Issueクローズ

v0.8.0の変更点だけでも、リモートバックエンドでの execute_code、Browser Use / Firecrawl統合、xAIプロンプトキャッシュ対応、Supermemoryサポート、バックグラウンドジョブの完了通知、MCP OAuth 2.1対応が揃っています。週単位でIssueもPRも消化しており、開発が実態を伴っている点で他のOSSエージェントと一線を画します。

なぜ今「自己成長型」が注目されるのか。2025年後半から「AIエージェントはステートレスすぎる」という不満が顕在化していました。毎回ゼロからコンテキストを構築し、前回の解法も再利用できず、ユーザーの好みもセッションをまたがない。モデル性能向上の鈍化とコスト上昇が重なり、「もっと賢いモデル」ではなく「エージェント側の学習構造」で差別化する流れが生まれました。superpowers（TDD駆動）、agent-lightning（強化学習）、hermes-agent（自己改善）の同時台頭はこの構図の現れです。

「自己成長型」とは何か、なぜ機能するのか

「自己成長型」は曖昧に使われがちなので、hermes-agentにおける定義を明確にします。

ここで言う自己成長型とは、エージェント自身が実行結果を評価し、再利用可能な手続き知識（スキル）を生成・改善し、長期記憶に書き戻すループを、ユーザーの明示的な指示なしに回し続ける設計を指します。使い手は普段通りタスクを頼むだけで、裏側でエージェントが自分を磨きます。

このループが機能する理由は3つです。

1. 粒度が手続き（Procedural）：単なる事実メモではなく「次にやるときの手順」として記録されるため、読み込んだ瞬間に行動に直結する
2. 評価が定期的に走る：15ツールコールごと、および5ツールコール以上を要した複雑タスク完了後に自己評価チェックポイントが起動し、「保存する価値があるか」を判定する
3. スキルが差分更新される：類似の既存スキルがあれば、新規作成せず既存ファイルにパッチを当てる。スキルが無数に量産される問題を避けている

「長文メモリを全部プロンプトに詰める」発想ではなく、レベル別ロード（後述）で必要なスキルだけ必要なタイミングで読み込みます。これが実用性の要です。

4層構造の自己改善メカニズム

hermes-agentの核心は、4層構造の学習ループにあります。

1. タスク実行フェーズ

ストリーミング出力に対応した標準的なエージェントループでタスクを処理します。40以上のビルトインツールを組み合わせながら目的を達成する挙動は一般的なエージェントと大きく変わりません。違いは「実行中に自分の行動を詳細に記録している」点で、ツールコール履歴・成功失敗・出力は後段の評価フェーズで使える形で保持されます。

2. 振り返りフェーズ（Skill Generation）

複雑なタスク完了後、エージェントは自動的に「スキルドキュメント」を生成します。生成されるMarkdownは次の構成です。

• タスクの文脈と目的
• 実行された手順（ツールコールの要約）
• 効果的だった解決アプローチ
• 発生した落とし穴と回避策
• 次回類似タスクでの検証ステップ

生成されたスキルは ~/.hermes/skills/ にMarkdownファイルとして保存されます。これは手続き的記憶（Procedural Memory）と呼ばれる設計で、事実ではなく「方法」を記憶します。エピソード記憶（いつ何があったか）とは意図的に別ストアに分離されており、混ぜると再利用可能な手順の検索精度が落ちるという設計判断です。

3. スキル改善フェーズ（Self-Refinement）

保存されたスキルは静的ではありません。15ツールコールごとの自己評価チェックポイントで「前回と同じ失敗をしていないか」「前回より良い手順があるか」を判定し、既存スキルにパッチを当てます。

姉妹プロジェクトとしてhermes-agent-self-evolutionが存在します。これはICLR 2026 Oral採択の研究成果で、DSPyとGEPA（Generalized Execution-trace-based Prompt Adaptation）を用いて実行トレースから「なぜ失敗したか」の理由まで分析し、プロンプト・スキル・コードを進化させます。v0.8.0ではこのメカニズムでGPT / Codex系ツール呼び出しの失敗モード5種を自動発見・パッチし、OpenAIモデル利用時の信頼性を大幅に改善したと報告されています。エージェントがエージェント自身のバグを見つけて直す、という構図です。

4. 記憶の永続化と検索

記憶システムは3層で構成されています。

レイヤー	役割	実体
Layer 1: 凍結システムプロンプト	毎セッションに必ず注入される基礎情報	MEMORY.md / USER.md
Layer 2: エピソード記憶（Skills）	過去の経験から抽出された手続き知識	~/.hermes/skills/*.md
Layer 3: セッション履歴	過去の全会話の全文検索インデックス	SQLite FTS5

MEMORY.md は環境情報・学習済み知見、USER.md はユーザーの好み・作業スタイルを保持します。どちらもテキストなので、ユーザーがエディタで直接書き換えることもエージェントが更新することもできます。

Layer 2のスキルは3段階でロードされます。

• Level 0：スキル名と説明だけ（40以上のスキルでも合計約3Kトークン）
• Level 1：特定のSKILL.md本文をオンデマンドで読む
• Level 2：スキル内の参照ファイル（補助ドキュメントやサンプル）を必要に応じて読む

普段はインデックスだけ見て、関連しそうなときだけ中身を展開する。人間の本棚に近い構造です。この階層化があるから、スキルが増えてもコンテキストは膨れません。Layer 3はSQLite FTS5による全文検索で、v0.7.0で記憶バックエンドがプラガブル化され、v0.8.0ではSupermemoryサポートも追加されました。

さらに「ナッジ機能」が特徴的です。エージェント自身が「この情報は保持すべき」と判断するとユーザーに永続化を提案します。受動的な記録ではなく能動的な知識管理を行う設計です。

Honchoによるユーザーモデリング

記憶レイヤーとは別に、もう一段深い仕組みとしてHonchoが統合されています。plastic-labsが開発しているAIネイティブメモリライブラリで、hermes-agentの公式メモリプロバイダーの一つです。

Honchoの中核は「弁証法的（Dialectic）推論」です。各会話の終了後、Honchoは会話内容を分析し、ユーザーの好み・習慣・目標についての「結論」を導き出します。

• この人は冗長な説明を嫌い、結論ファーストの返答を好む
• コードレビュー依頼時は「なぜ」の説明より「どこを直すか」の具体を優先する
• Next.jsよりSvelteKitを好む傾向がある

これらの結論は蓄積されていき、次回以降の会話で参照されます。重要なのは、ユーザーが明示的に「私はこういう人間です」と宣言しなくても、会話を重ねるだけでモデルが構築されていく点です。単なるキーバリューストアではなく、ユーザー自身の推論パターンをモデリングすることを目指しています。

実装上は honcho_context, honcho_search, honcho_conclude の3ツールをエージェントから呼び出せる形になっており、毎ターン必要な分だけ動的にコンテキストを引き出します。システムプロンプトを肥大化させずにユーザー理解だけを深められるのが強みです。同じユーザーに複数のHermesインスタンスが接続している場合でも、Honchoは「ピアプロファイル」を別々に維持できます。仕事用と個人用の顔を混ぜずに扱えるわけです。

マルチLLM対応アーキテクチャ

hermes-agentは特定のLLMに依存しません。hermes model コマンドでプロバイダー切り替え、/model スラッシュコマンドでセッション途中のライブ切替もできます（v0.8.0から全プラットフォームで対応）。

対応プロバイダーはNous Portal（MiMo v2 Proが無料）、OpenRouter（200以上のモデル）、OpenAI、z.ai / GLM、Kimi / Moonshot、MiniMax、Google AI Studio（v0.8.0でネイティブ対応）、カスタムエンドポイントです。

設計上の重要なポイントは、スキルも記憶もすべてLLMから独立したMarkdown / SQLiteとして保存されるため、モデルを切り替えても蓄積された知識は失われない点です。これにより「軽い雑談はローカルLLM、ルーチンは安いGLM系、難しい推論だけHermes 4やGPT-5」といったコスト最適化が同じ記憶の上で透過的にできます。特定ベンダーに縛られたマネージドサービスでは真似できない構造です。

superpowersとの関係と違い

2025年後半から2026年にかけて、OSSエージェントフレームワークの三大プロジェクトが急成長しました。

プロジェクト	Star数	公開時期	核心思想
superpowers	約148,000	2025年10月	TDD駆動の規律あるコーディング
hermes-agent	約67,000	2025年7月（本格公開2026年2月）	自己改善する記憶とスキル
agent-lightning (MS)	約16,000	2025年6月	強化学習によるエージェント訓練

superpowersは「コーディングエージェントの品質保証」に特化しています。TDDを強制し、テスト前にコードを書くと自動削除するという厳格な設計で、85〜95%のテストカバレッジを達成できるとされます。

一方、hermes-agentは「記憶と自己改善」に賭けています。コーディングに限らず、メッセージング・スケジューリング・リサーチなど汎用的な用途をカバーします。両者の違いは「学習の主体が違う」と言い換えられます。superpowersではユーザーとコードベースが学習の主体で、エージェントは規律の執行者。hermes-agentではエージェント自身が学習の主体で、使われるほどスキルとユーザーモデルが育ちます。

競合ではなく補完の関係です。厳格な品質保証が必要なコーディング領域ではsuperpowers、ユーザー作業を長期的に肩代わりする汎用アシスタントとしてはhermes-agent、という使い分けが現実的で、両方を並行運用している開発者もすでに少なくありません。

Claude Managed Agentsとの比較

2026年4月8日、AnthropicはClaude Managed Agentsのパブリックベータを開始しました。OSSエージェント vs マネージドサービスの選択指針として比較します。

観点	hermes-agent	Claude Managed Agents
運用形態	セルフホスト（MIT）	Anthropicマネージド
モデル選択	任意（200+モデル）	Claudeのみ
料金	インフラ費 + LLM API費	トークン費 + $0.08/セッション時間
自己改善	スキル自動生成・改善	なし（研究プレビュー段階）
セキュリティ	自己責任	サンドボックス環境提供
データ管理	完全にローカル	Anthropicインフラ上

hermes-agentの優位点はモデル非依存・自己改善機能・データの完全な自己管理。Claude Managed Agentsはインフラ構築不要で即座にセキュアなサンドボックス環境を使える強みがあります。機密データを扱う企業やモデル選択の自由度を重視するチームにはhermes-agent、インフラ運用を最小化したいチームにはClaude Managed Agentsが適します。両者はゼロサムではなく、「開発者向けはhermes、本番顧客向けはClaude Managed」と使い分けるのも妥当です。

なお、OpenClawとの関係も触れておくと、hermes-agentはOpenClawの設計思想を継承し記憶と自己改善を強化した後継として位置付けられています。自動移行ツール hermes claw migrate が用意されており、OpenClawのユーザーベースをそのまま取り込む設計です。

インストールと動作手順

環境構築は1コマンドで完了します。前提条件はLinux / macOS / WSL2 / Android（Termux）、Python 3.11以上、uvです。

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

このスクリプトはuvのインストール、hermes-agent本体のインストール、~/.hermes/ の初期化まで一気に行います。

hermes setup    # セットアップウィザード起動
hermes model    # LLMプロバイダー選択
hermes tools    # ツールの有効化・無効化

hermes setup はプロバイダー選択、APIキー登録、USER.md への基本情報書き込み、有効化するツールの選択を対話的に進めます。OpenRouterを選べばAPIキー1本で200以上のモデルが使えます。

基本操作

hermes                    # TUI起動（マルチライン編集、コマンド補完対応）
/model openrouter:claude  # モデル切り替え
/skills                   # 蓄積されたスキル一覧
/compress                 # コンテキスト圧縮
/new                      # 新規会話開始

設定ファイルの構造

セットアップ後、~/.hermes/ 以下は次のようになります。

~/.hermes/
├── config.yaml        # プロバイダー・ツール・メッセージング設定
├── MEMORY.md          # システム状態・環境情報
├── USER.md            # ユーザー情報・好み
├── skills/            # 自動生成されるスキル集
├── sessions.db        # SQLite FTS5セッション履歴
└── logs/              # 実行ログ

config.yaml の中身は以下のようなイメージです。

model:
  provider: openrouter
  default: anthropic/claude-sonnet-4.5
  fallback: z-ai/glm-4.6

memory:
  backend: builtin
  honcho:
    enabled: true
    api_key: ${HONCHO_API_KEY}

tools:
  filesystem: true
  shell: true
  browser_use: true

messaging:
  telegram: ${TELEGRAM_TOKEN}
  discord: ${DISCORD_TOKEN}

providerを切り替えてもmemoryとtoolsはそのまま引き継がれるため、新しいモデルを試しても記憶はリセットされません。

Telegram・Discord・Slack・WhatsApp・Signal・Email・Matrix・Mattermostへの同時接続、ローカル / Docker / SSH / Daytona / Modal / Singularityといった実行バックエンドの切り替えも同じ設定ファイルから制御できます。月額$5のVPSでcronスケジューリングによる無人運用も可能な軽量さです。

1日、1週間、1ヶ月でどう変わるか

自己成長型という言葉はピンと来にくいので、使い始めのタイムラインを具体的に想像してみます。

1日目。他のエージェントとほとんど変わりません。USER.md と MEMORY.md くらいしか持たないので、質問のたびに背景を説明する必要があります。ただしこの日、エージェントは既に自己評価を回していて、複雑だったタスクは skills/ 配下に最初のスキルを生成しています。ユーザーは気づかなくていい、ここが設計の妙です。

1週間目。スキルが10〜30本蓄積されます。「Issueを読み取ってPR下書きを作る」「エラーログから原因箇所を特定する」といった頻出パターンがスキル化され、次回同じ類のタスクで「前回はこの手順で成功した」という知識がプロンプトに動的注入されます。体感は「いちいち指示しなくても先回りしてくれる」。同時にHonchoが蓄えたユーザー結論も増えてきて、「PR説明は日本語で」「コード例はTypeScriptで」など言わなくても通じるようになります。

1ヶ月目。スキルは数十〜100本超、sessions.db には数百セッションが蓄積されます。エージェントは「ワークスタイルを知っている秘書」に変わります。過去の類似ケースを自力で検索して持ってくるので判断の質が明らかに上がります。ただし誤ったスキルやユーザー結論が蓄積されることもあるため、月に一度 /skills でメンテナンスは必要です。完全自動ではなく、ここに少しだけ人間の編集が残ります。

なぜ短期間で爆発的に支持されたのか

hermes-agentの急成長には複数の構造的要因があります。

1. ステートレスへの不満の蓄積：「使うほど賢くなる」という約束が長年の不満に直接応えました。コピーが強いだけでなく実装が約束を果たしている点が拡散につながりました
2. Nous Researchのブランド力：Hermesモデルシリーズで培った信頼が期待値を高めました。「LLMを知り尽くしたチームが作るエージェント」という説得力は無名の開発者では出せません
3. OpenClawからの移行パス：自動移行ツールで既存ユーザーベースを丸ごと取り込みました。移行コストの低さが初動を支えました
4. モデル非依存の設計：コスト意識の高い開発者に刺さりました。高価なモデルと安価なモデルを用途に応じて使い分けられます
5. OSSエージェント需要の爆発：「自分でホストできるAIエージェント」への需要が確実に存在することを、superpowersとhermes-agentのStar数が示しています

まとめ

hermes-agentの技術的な新しさは、「タスク実行 → 振り返り → スキル獲得 → 次回活用」という閉ループを、エージェント自身が自律的に回す設計にあります。記憶はMarkdownとSQLiteという軽量な形式で永続化され、Honchoによってユーザー自身の推論パターンまでモデリングされます。これらはLLMから独立しているため、賢いモデルが出るたびに乗り換えても蓄積された知識は失われません。

OSSエージェントフレームワークの競争は激化していますが、hermes-agentは「自己改善」という明確な差別化軸を持ち、Nous Researchのモデル訓練知見に裏打ちされた設計で独自のポジションを築いています。superpowersが「コードの規律」を担保するのに対し、hermes-agentは「エージェント自身の成長」を担保する。この役割分担がOSSエージェント界隈の新しい地図を描き始めています。

最初の1週間は変化が地味ですが、1ヶ月後に振り返ると「もう手放せない」状態になっていることが多い、というのが既存ユーザーの共通した感想です。まずは hermes setup で触ってみることをお勧めします。

参考リンク

• NousResearch/hermes-agent - GitHub
• NousResearch/hermes-agent-self-evolution - GitHub
• Hermes Agent公式ドキュメント
• Hermes Agent v0.8.0 Release Notes
• Honcho Memory - Hermes Agent Docs
• Memory Systems - hermes-agent DeepWiki
• plastic-labs/honcho - GitHub
• Hermes 3 Technical Report - arXiv
• Hermes 4 - Nous Research
• Claude Managed Agents overview - Anthropic
• Hermes Agent v0.7.0 Deep Dive - DEV Community
• Persistent AI Agents Compared - The New Stack
• Superpowers Skills Framework - byteiota