🧬 エージェントが自らを進化させる時代へ ─ Hermes Agent Self-Evolution で学ぶ DSPy + GEPA による自己改善パイプライン

📖 はじめに

LLM エージェントを運用されている方なら、一度はこう感じたことがあるのではないでしょうか。

• 🤔「このスキル（SKILL.md）、なんとなく動くけど本当にベストな書き方なのか？」
• 😵‍💫「システムプロンプトを少し変えたら劇的に精度が上がった。でも、その『少し』を手で探すのが限界に来ている」
• 🧩「ツール記述を直すと別のタスクでエージェントが間違ったツールを選ぶようになる。全体最適の方法がわからない」

これらの悩みを、評価データセット + 進化的探索 + ガードレール という枠組みで自動化してしまおうというのが、本記事で紹介する NousResearch/hermes-agent-self-evolution です。

⚒ ひとことで言うと
「Hermes Agent というエージェントを、別プロセスの最適化パイプラインで 継続的に進化させる ための OSS」です。対象リポジトリには一切触らず、改善結果は PR として提出 されるため、人間のレビューを介して安全に取り込めます。

本記事では、リポジトリの README と PLAN.md を精読しながら、その思想・アーキテクチャ・使い方・ガードレール設計までを丁寧にひも解いていきます。エージェント開発に携わる方、あるいは自作エージェントを持っている方の設計ヒントになれば幸いです。

---

🌱 背景：なぜ「エージェントの自己改善」が難しいのか

手作業チューニングの限界

LLM エージェントは、次のような複数の要素が組み合わさって動作しています。

要素	役割	典型的なサイズ
🧾 システムプロンプト	エージェントの人格・方針・書式を規定する	数千〜数万トークン
📘 スキル（SKILL.md）	特定タスクの手順を宣言的に記述した指示書	1〜15 KB 程度
🔧 ツール記述	各ツールの description フィールド。選択の根拠になる	数百文字
🛠 ツール実装コード	実際にファイル操作や検索を行う Python 等の関数	数十〜数百行

どれか 1 つを調整しても、他の要素との相互作用が変わるため、経験豊富なエンジニアでも「試行錯誤で体感を頼りに調整する」以上のことは難しいのが現実です。

従来アプローチの課題

上の図が示すように、「なぜ失敗したか」を開発者の主観で推測するループに依存しているのが従来手法の本質的な課題です。失敗理由の特定には経験と時間が要り、改善の属人性が高くなります。

RL（強化学習）ではだめなのか？

「じゃあ RL で最適化すれば？」という発想は自然ですが、以下の理由でハードルが高い領域です。

• 🖥 GPU コスト：ファインチューニングは GPU クラスタが必要で、数万ドル規模になりがちです
• 📉 サンプル効率：RL は大量の試行を要求するため、API ベースのエージェントだと金額が跳ね上がります
• 🔒 ベースモデルの固定：商用 API モデル（Claude, GPT など）は重みを直接学習できません

そこで注目されているのが、「重みではなくテキスト（プロンプト・スキル・コード）を進化させる」 というアプローチです。これが本 OSS の出発点になります。

---

🧬 Hermes Agent Self-Evolution とは

プロジェクト概要

NousResearch/hermes-agent-self-evolution は、Nous Research が公開した MIT ライセンス の OSS で、説明文にはこう書かれています。

"Evolutionary self-improvement for Hermes Agent — optimize skills, prompts, and code using DSPy + GEPA"
（Hermes Agent のための進化的自己改善 ─ DSPy + GEPA を使ってスキル、プロンプト、コードを最適化する）

最大の特徴は 「GPU 学習なし」 という点です。すべてが API 呼び出しと、テキストの変異・評価・選択だけで完結するため、1 回の最適化ランは $2〜$10 程度で済むと README に明記されています。

位置づけ：hermes-agent の「外側」で動く

ポイントは、対象であるエージェント本体（hermes-agent）のリポジトリを 一切変更しない ことです。この OSS はスタンドアロンの最適化ツールとして動作し、改善結果は Git ブランチ + PR の形で対象リポジトリに提案されます。

✅ 設計上のメリット

• 対象エージェントに依存コードを注入しないので、本番稼働中のエージェントを壊すリスクがゼロ
• PR ベースなので 人間のレビューが必ず入る
• 改善ランの成否に関わらず、対象リポジトリは常にクリーンな状態

---

🔬 コア技術：DSPy + GEPA を理解する

本 OSS の心臓部は DSPy + GEPA という組み合わせです。それぞれ簡単に整理しておきましょう。

DSPy とは何か

DSPy は Stanford NLP が開発した、「LLM プログラムを宣言的に構築し、自動最適化する」 ためのフレームワークです。プロンプトを文字列として直接書く代わりに、Signature（入出力の型）と Module（推論の構造）で記述します。これにより、プロンプト本文や Few-shot 例が最適化可能なパラメータとして扱えるようになります。

GEPA とは何か

GEPA（Genetic-Pareto Prompt Evolution） は、DSPy に統合された比較的新しい最適化器で、ICLR 2026 Oral 採択の技術です。最大の差別化ポイントは以下です。

🧠 GEPA の本質的な強み
従来のプロンプト最適化器は「スコアが上がった／下がった」という結果だけを見ていました。GEPA は 実行トレース（agent trajectory） を読み、なぜ失敗したのかを言語的に理解した上で、ターゲットを絞った変異を提案します。

イメージとしては以下のようなサイクルです。

3 つの変異戦略（エンジン構成）

PLAN.md によると、本 OSS では 3 つの最適化エンジンが用途別に使い分けられます。

エンジン	何を最適化するか	ライセンス	本 OSS での役割
🧠 DSPy + GEPA	スキル、プロンプト、ツール記述	MIT	主力。Python ネイティブ統合
🧬 Darwinian Evolver	コードファイル、アルゴリズム	AGPL v3	コード進化用、外部 CLI 経由のみ
📐 DSPy MIPROv2	Few-shot 例、指示テキスト	MIT	GEPA のフォールバック

AGPL v3 である Darwinian Evolver は 外部 CLI としてのみ 呼び出すよう切り分けられており、本 OSS 本体のライセンス（MIT）を汚染しない設計になっています。このライセンス分離は、実務で OSS を採用する際に見逃せない配慮です。

---

🏗 最適化対象の 4 階層（Tier 1〜4）

PLAN.md では、改善対象を「価値」と「リスク」の 2 軸で 4 つの Tier に整理しています。下位 Tier ほどローリスク、上位ほどハイリターン・ハイリスクという階層構造です。

Tier 1 : スキルファイル（最高の ROI）

ターゲット：SKILL.md のような手順書形式のテキスト

なぜここから始めるのか

• スキルは純粋なテキストなので変異が容易
• 「このスキルに従って実行した結果、タスクが成功したか？」が直接測定できるため評価が素直
• 壊れても影響範囲がそのスキル内に閉じる

具体例（PLAN.md より）

github-code-review スキルを、既知のコードレビューのデータセットに対して評価し、
より良いレビューが出力されるよう GEPA で進化させる

Tier 2 : ツール記述（分類問題としての最適化）

ターゲット：各ツールの description フィールド

ツール選択は本質的に 分類問題 です。与えられたタスクに対して、エージェントが適切なツールを選べるかどうかが評価指標になります。

📌 例：search_files の description を進化させて、terminal(grep) ではなくこちらが選ばれる確率を上げる

Tier 3 : システムプロンプトの構成要素

ここから先は 高リターン・高リスク ゾーンです。システムプロンプトの品質はエージェントの挙動全体を左右するため、改善インパクトは非常に大きい一方で、プロンプトキャッシュを壊すリスクがあります。

⚠️ 注意ポイント
システムプロンプトはキャッシュ対象であることが多いため、会話の途中で書き換えないことが必須です。本 OSS は オフラインでのみ最適化し、新バージョンとしてデプロイする方針を取っています。

Tier 4 : ツール実装コードの進化

ターゲット：Python などで書かれたツール実装そのもの

手法：Darwinian Evolver の GitBasedOrganism を使い、コードを遺伝子のように進化させ、pytest と batch_runner で評価します。

🛑 最大のリスク
コード変更はアプリを壊します。そのため 強力なテストスイート がガードレール前提条件になります。テストが貧弱な領域では Tier 4 に手を出すべきではありません。

---

🔁 アーキテクチャ：最適化ループの全体像

PLAN.md では、6 ステップからなる最適化ループが定義されています。全体像を図にすると次の通りです。

ステップ詳解

1️⃣ ターゲット選択

最適化対象（スキル、プロンプト断片、ツール記述のいずれか）を 1 つ選び、その「現在版」をベースラインとしてロードします。

2️⃣ 評価データセット構築

これが実は最重要ステップです。評価が甘いと、どれだけ最適化器が優秀でも意味のない方向に進化します。

本 OSS では以下の 3 つのソースを使い分けられるようになっています。

• 📼 SessionDB マイニング：Hermes の hermes_state.py が保持する実セッションから抽出
• 🤖 合成生成：強力な LLM にスキルを読ませてテストケースを作らせる
• ✍️ ゴールデンセット：人間が手でキュレーションした高品質データ

3️⃣ DSPy Module としてラッピング

SKILL.md などの「テキスト」を、DSPy から最適化可能な Module に変換する層が evolution/skills/skill_module.py に実装されています。このラッパーの役割は以下の通りです。

# 概念コード（実装イメージ）
class SkillModule(dspy.Module):
    def __init__(self, skill_text: str):
        self.skill = skill_text  # ← これが最適化対象

    def forward(self, task):
        # スキルをシステムプロンプトとして注入し、タスクを実行
        return run_agent(system=self.skill, user=task)

4️⃣ 最適化器の実行

GEPA を主軸に、必要に応じて MIPROv2（ベイズ最適化ベース）や Darwinian Evolver が選ばれます。README のクイックスタートでは --iterations 10 がデフォルト例として示されており、5〜10 イテレーション程度で実行するのが典型のようです。

5️⃣ 評価・比較

単に「ベンチ上のスコアが上がった」だけでなく、以下を総合評価します。

指標	意味
✅ 精度	そもそもタスクが成功するか
💰 コスト	最適化版の 1 実行あたり API 課金
⏱ レイテンシ	応答時間の悪化がないか
📊 統計的有意性	スコア差が偶然でないか

6️⃣ デプロイ（承認付き）

ガードレールをすべて通過した最良バリアントのみが、Git ブランチにコミットされ PR 自動生成 まで走ります。ロールバックは単なる git revert で済むため、運用上のリスクも抑えられます。

---

🛡 ガードレール：安全に進化させるための 5 つの関門

自動進化は強力ですが、「強力すぎると何が起きるかわからない」ものの代表格です。本 OSS では以下の 5 段階ガードレール で安全性を担保しています。

それぞれの関門の意図

1. フルテスト通過：pytest tests/ -q が 100% グリーンであること。コード進化（Tier 4）の場合は死活的に重要です
2. サイズ上限：スキルは 15KB、ツール記述は 500 文字以内。肥大化してコンテキストを圧迫しない ための制約です
3. キャッシュ整合性：会話の途中で内容が変わってはいけない（プロンプトキャッシュが破壊される）
4. 意味保存：最適化の過程で本来の目的から逸脱する「スペック・ドリフト」を防ぐ
5. PR レビュー：直接コミットは絶対にしない。すべての変更は人間の承認を経る

🔒 このあたりは本番採用の必須条件
自動改善パイプラインを導入する際、「テスト」「サイズ」「レビュー」の 3 つは必ず自分の環境でも用意してください。これらが無い状態で自動進化を回すと、静かに劣化が蓄積して気付いた時には戻せない状態になります（本 OSS はそれを防ぐ構成を示してくれています）。

---

🚀 クイックスタート

README のクイックスタートをベースに、実行の流れを見ていきましょう。

インストール

# クローンして editable install
git clone https://github.com/NousResearch/hermes-agent-self-evolution.git
cd hermes-agent-self-evolution
pip install -e ".[dev]"

# 対象である hermes-agent リポジトリの場所を指定
export HERMES_AGENT_REPO=~/.hermes/hermes-agent

HERMES_AGENT_REPO は「どのエージェントを改善するのか」を指す環境変数です。エージェント本体には触れず、読み取り + PR 提出の起点としてだけ使われます。

スキルを進化させる（合成データ版）

python -m evolution.skills.evolve_skill \
    --skill github-code-review \
    --iterations 10 \
    --eval-source synthetic

• --skill：進化させたいスキル名（github-code-review など）
• --iterations：GEPA の世代数。README では 5〜10 が推奨
• --eval-source synthetic：評価データを強モデルで自動生成

実セッション履歴から学ばせる

python -m evolution.skills.evolve_skill \
    --skill github-code-review \
    --iterations 10 \
    --eval-source sessiondb

--eval-source sessiondb にすると、Claude Code・Copilot・Hermes などのセッション履歴から評価データを抽出します。実ユーザの失敗パターンを直接学習できるため、合成データよりも効果的であることが多いでしょう。

他フェーズの CLI

PLAN.md には、Phase 2〜4 用の CLI も構想として記載されています。

# Phase 2: ツール記述の最適化
python -m evolution.tools.evolve_tool_descriptions \
    --iterations 5 \
    --benchmark-gate tblite-fast

# Phase 3: システムプロンプトの一部を最適化
python -m evolution.prompts.evolve_prompt_section \
    --section MEMORY_GUIDANCE \
    --iterations 5

# Phase 4: ツール実装コードの進化（Darwinian Evolver CLI 経由）
python -m evolution.code.evolve_tool_code \
    --tool file_tools \
    --bug-issue 742 \
    --iterations 10

📝 現時点のステータス（2026 年 4 月時点の README より）

フェーズ	対象	状態
Phase 1	スキルファイル	✅ 実装済み
Phase 2	ツール記述	🔲 計画中
Phase 3	システムプロンプト	🔲 計画中
Phase 4	ツール実装コード	🔲 計画中
Phase 5	連続改善ループ	🔲 計画中

実利用できるのは現状 Phase 1（スキル進化）のみという点に注意してください。Phase 2 以降はロードマップとして設計意図が示されている段階です。

---

🗺 フェーズ別ロードマップ

PLAN.md は、単に「機能一覧」ではなく 段階的にリスクを上げていく進化戦略 を取っています。各フェーズ間には必ず Validation Gate（検証ゲート） が挟まり、「本当に改善したか？」を確認してから次に進みます。

各フェーズの Done 基準

Phase 1（スキル進化）の完了条件

PLAN.md には具体的な完了基準が明文化されています。

• ✅ 少なくとも 1 つのスキルが評価データセット上で 10% 以上の改善
• ✅ TBLite ベンチマークのスコアが 2% 以内 に収まる（退化していない）
• ✅ 進化版スキルの diff が 人間レビュアーにとって意味が通る
• ✅ パイプラインが 任意のスキルに再利用可能

「ベンチマークの非退化」という条件が含まれていることに注目してください。特定タスクで伸びても全体が劣化しては意味がないという、全体最適の視点が埋め込まれています。

Timeline Overview

Phase	内容	期間	ゲート条件
Phase 1	スキル進化	3-4 週	≥1 スキル改善、ベンチ退化なし
Phase 2	ツール記述	2-3 週	ツール選択精度向上
Phase 3	システムプロンプト	2-3 週	挙動テスト通過、ベンチ維持
Phase 4	コード進化	3-4 週	バグ修正、テスト通過、ベンチマーク維持
Phase 5	連続改善ループ	2 週	無人パイプライン稼働

合計で 13〜17 週間 が見込まれていますが、PLAN.md にはこう明記されています。

"No obligation to do all five.（すべてをやる義務はない）"

つまり、Phase 1 や 2 で十分な ROI が得られたらそこで止めてよい という姿勢です。過剰エンジニアリングを避ける思想が感じられます。

---

🧩 hermes-agent 側との統合点

本 OSS は hermes-agent の 既存インフラ を読み取り専用で活用します。どのコンポーネントが、どう使われるのかを整理しておきましょう。

hermes-agent のコンポーネント	本 OSS での役割
batch_runner.py	評価ハーネス。並列でエージェントを走らせる
agent/trajectory.py	実行トレース取得。GEPA のリフレクションに必須
hermes_state.py（SessionDB）	実セッション履歴 のマイニング元
skills/ ディレクトリ	主要な最適化ターゲット
tools/registry.py	ツール記述の取得元
agent/prompt_builder.py	システムプロンプト断片の取得元
tests/	ガードレール（テスト通過が必須）
Git 履歴	進化の系譜を記録、ロールバック基盤

このように、Hermes が既に持っているインフラを 「最適化のために転用する」 という筋の通った設計です。新規に評価基盤を構築する必要がなく、既存の batch_runner や tests がそのまま 進化のエンジン として働きます。

---

💡 他のエージェントへ応用するには

「これ自分の作ったエージェントにも応用できる？」と思われた方へ、移植の勘所を整理しておきます。

必要な前提条件

これらが揃っていない場合、まずは 評価基盤の整備 から始めることを強くお勧めします。「何が良いエージェントか」を測れないと、いくら進化させても方向がわかりません。

応用時の注意点

• 🔐 コスト管理を先に設計：進化ランは安いとはいえ $10 程度/回。自動で回すなら上限を設ける
• 🧪 評価データの質が肝：README が --eval-source sessiondb を推奨するのは「実データの方が強い」という経験則の反映
• 🎯 Tier 1 から始める：いきなりコード進化（Tier 4）を試さず、スキル進化で手応えを掴んでから上位 Tier へ

---

🤔 考察：何が本質的に新しいのか

この OSS が示す最大のメッセージは、「エージェント改善をソフトウェア工学に落とし込めるようになった」 という点です。

観点	従来	本 OSS の提案
改善の単位	人間の経験	評価データセット上のスコア
失敗の分析	主観的な原因推測	実行トレースのリフレクション
変更のデプロイ	手動編集 → 即反映	PR + テスト通過 + レビュー
ロールバック	難しい（記憶頼み）	git revert 一発
コスト感覚	測定しない	1 ラン $2〜$10

つまり、「プロンプトエンジニアリング」という 職人芸 の領域に、CI/CD・テスト・PR レビューといった エンジニアリングの規律 を持ち込んでいるのです。

限界と課題

もちろん万能ではありません。

• 📉 評価データセットが作れない領域では効かない：主観的な「会話の品質」などは自動評価が困難です
• 🌪 探索空間が広すぎる課題には不向き：まったくゼロからスキルを書き起こすような用途は想定外
• 💸 イテレーション数とコストのトレードオフ：5〜10 回で十分な改善が得られないと、無限に回すことはできません
• 🧬 Darwinian Evolver の AGPL ライセンス：Tier 4 を使う際は、商用クローズドソース製品への取り込み方に注意

---

🎯 まとめ

本記事では、Nous Research が公開した OSS hermes-agent-self-evolution を題材に、LLM エージェントの自己改善パイプラインの設計思想を詳しく見てきました。

要点を振り返ります。

• 🧬 GPU 学習なし・API のみで、スキル・プロンプト・ツール・コードを進化可能
• 🧠 DSPy + GEPA が「なぜ失敗したか」を実行トレースから読み解き、ターゲット変異を提案
• 🏗 4 Tier × 5 Phase で段階的にリスクを上げる設計（スキル → ツール記述 → プロンプト → コード）
• 🛡 5 つのガードレール（テスト、サイズ、キャッシュ整合性、意味保存、人間レビュー）
• 💰 1 ラン $2〜$10 という現実的なコスト感

現時点では Phase 1（スキル進化）のみが実装済みですが、思想とアーキテクチャは十分に流用可能です。自作エージェントに 進化的自己改善の発想 を持ち込む第一歩として、ぜひリポジトリを眺めてみてください。

💬 最後に
「エージェントが自らを改善する」というテーマは 2020 年代前半まで SF でした。しかし GEPA のような技術の登場で、これは ソフトウェア工学の地続きの話題 になりました。本 OSS はその転換点を象徴する存在の一つだと言えそうです。

---

📚 参考

• NousResearch/hermes-agent-self-evolution — 本記事で扱った OSS 本体
• NousResearch/hermes-agent — 最適化対象である Hermes Agent 本体
• DSPy — Stanford NLP の LLM プログラミングフレームワーク
• GEPA (Genetic-Pareto Prompt Evolution) — ICLR 2026 Oral 採択の進化的プロンプト最適化
• Darwinian Evolver — Git ベースのコード進化エンジン
• PLAN.md（上記リポジトリ内）— アーキテクチャとフェーズ設計の原文