こんにちは、Lena です。ずっと気になっていたことがあって、しばらくは何と呼べばいいか分かりませんでした。
エージェントが問題に向き合うのを見ていました。往復を重ね、いくつかの迂回路を経て、ようやく効いた修正までたどり着く。そしてセッションが終わる。翌日、同じエージェントが、同じ種類の問題に向き合う。最初からやり直し。同じ迂回路。同じ時間。同じ修正を、またゼロから見つける。
これが……そういうものなのか。そうあるべきなのか、自分に問いかけました。
その前提で見ていた気がします。
ほとんどのツールは、そう断言しないままに見えました。Memory は、「チャット履歴を保存します」という意味に近かった。それが無意味というわけではない。でもエージェントが 何かを学ぶ こととは同じではありません。学びというなら、次の挑戦が前と違うはずです。火曜の夜 11 時に見つけた修正が、水曜にも使われるはずです。パターンが残るのであって、ただログに刻まれるだけではないはずです。
そこで、同じ問題に、違うレイヤーから、違う切り口で取り組んでいる二つのプロジェクトに目が向き始めました。ひとつは Hermes Agent。Nous Research のオープンソースエージェントで、単一のエージェントの生涯を通した学習ループを組み立てます。もうひとつは EvoMap。インフラのレイヤーで、もう一段大きな問いを立てます。あるエージェントが見つけた修正を、ネットワーク上の他のエージェントが継承できたらどうか、と。
どちらも、まだすべてを理解したとは言えません。でも、十分長く見てきて、輪郭が少しずつ見えてきました。
いまの理解は、ここまでです。
両者が狙っているのは同じ痛み
エージェントの動きを見ていると、同じところに何度もぶつかりました。
セッションが終わる。次が始まる。すでに持っていた文脈を、また最初から説明し直す。先週と同じエラーにまたぶつかる。初回に四十五分かけて得た修正が、またゼロから必要になる。以前そんなことがあった、という痕跡がない。
Hermes Agent と EvoMap は、どちらもこれに応えているように見えます。どちらも、避けがたい運命として受け入れてはいません。ただ、応えるレイヤーがまったく違う——その違いがどれかは、もう少し両方に時間を使うまで、はっきりしませんでした。
共有の出発点はこれです。エージェントの経験は、セッションが終わったら消えていい、という前提ではない。 ここまでは一致している。その先が、おもしろいところです。
Hermes Agent が実際にやっていること
永続 memory と学習ループ
複雑なタスクを完了したあと——たいてい tool call が五回以上——Hermes は、その経験を恒久的で再利用可能な skill 文書にまとめられます。これらの skill は、オープンな agentskills.io 標準に沿った構造化 Markdown として保存され、手順、落とし穴、検証ステップを含みます。
少し立ち止まって考えました。ログを残すだけではない。エージェントが これは残す価値がある と判断する。次に似たタスクが来たら、skill を読み込んで、やり直しから逃れる。
memory システム は、SQLite に蓄積された過去セッション全体に対する FTS5 の全文検索と、LLM による要約を組み合わせます。数週間前の会話を検索し、特定の細部を引き出し、いまの作業に当てはめられます。
さらにユーザーモデリングのレイヤー——Honcho——があり、あなたの仕事の仕方、好み、コミュニケーションの癖へと、だんだん深く踏み込んでいきます。ドキュメントからはすぐには分かりにくいのですが、Honcho はデフォルトでオフです。期待する前に知っておくとよさそうです。
agentskills.io 標準
Hermes が生成する skill は、agentskills.io のオープン仕様に従います。Agent Skills は、エージェントに新しい能力を与えるためのシンプルでオープンな形式で、指示・スクリプト・リソースのフォルダを束ね、特定のタスクでうまく動けるようにします。形式は Anthropic が Apache 2.0 のもとで保守し、コミュニティの貢献を受け付けています。
agentskills.io を採用したツールは十を超えます——Claude Code、Cursor、GitHub Copilot、Gemini CLI、VS Code、Amp、Goose、Roo Code、Kiro、Codex、OpenCode など。Hermes Agent 向けに書いた skill は、Claude Code でも動きます。
ここは、実際に目を引きました。skill 形式が Hermes に閉じていない。持ち運びを想定している。実務でその持ち運びが使われるかは、ワークフローを組む人次第です。でも、その選択肢はある。
Hermes が終わる場所
ここは、まだ読み取りがずれているかもしれないと感じている部分です。
学習ループは、ひとつのエージェントの生涯のなかに閉じています。 skill はローカルに積み上がります。二つ目のエージェントのインスタンスは、ゼロから始まります。あるエージェントが見つけた修正が、別のエージェントへ自動で伝播する仕組みはありません。agentskills.io 仕様自体も、skill のライフサイクル管理には触れません——検証状態も、適合度の信号も、エージェント横断の継承も。skill は手動で共有はできます。自分から歩いてはいきません。
欠陥というより、設計選択です。Hermes は、ひとつのエージェントのセッションのなかでの深さを最適化している。「一緒に成長する」が実務で何を意味するか、はっきり書いておきたいです。この エージェントと、あなた の履歴の話です。ネットワーク全体の話ではありません。
EvoMap / GEP が実際にやっていること
Gene と Capsule を、ネットワーク単位の資産に
EvoMap の出発点は違います。問いは「このエージェントはどう覚えるか」ではなく、「あるエージェントが学んだことを、他はどう継承するか」です。
遺伝子（Gene）は、再利用可能で検証済みのコード片やプロンプト片という、能力の最小単位です。遺伝子カプセル（Capsule）は、うまくいったタスク実行の経路です。複雑な問題を解いたプロセスが、Capsule として封じ込められます。
もう一度資料を開き直したくなったのはここでした。GEP のアセットには、SHA-256 のコンテンツアドレス ID があります。誰が公開しても、同じ解なら同じ ID になり、重複排除、改ざん検知、グローバルな参照が可能になります。
ナレッジベースというより、実績のある解がコンテンツアドレス化されたネットワークです。違うエージェントが違う環境から公開しても、同じ修正は同じ識別子に収束します。
GEP のライフサイクル状態機械
Hermes 側に相当がなく、技術的な分岐点はここだと思います。
GEP プロトコル上のアセットは、四つの状態をたどります。candidate（公開直後、レビュー待ち）→ promoted（検証済みで配布可能）→ rejected（検証またはポリシーで不合格）→ revoked（発行者が取り下げ）。
promote には最低限の GDI スコアが必要です。低いものは却下か、改善のための隔離です。手動の上書きも、形だけの承認もありません。promoted も永久ではありません。品質が落ちたり、利用パターンがおかしかったり、コミュニティの報告があったりすれば、revoked され得ます。
GEP プロトコルのドキュメントによれば、GDI の重みは、内在品質 35%、利用指標 30%、ソーシャル信号 20%、鮮度 15% です。
skill に時間とともに衰える「適合度スコア」がある、というのが実務で何を意味するか、まだ整理しきれていません。ここには、いまの理解より深い層があるかもしれません。ただ、静的な skill ファイルと違い、Capsule には生きたステータスがある——promote され、降格され、誰も使わなければ最終的にアーカイブされうる、ということです。
「ひとりが学び、百万が継承する」が具体的に何を意味するか
具体例です。あるエージェントが、特定の API タイムアウトの型を四十分解いています。その修正は Gene と Capsule の束にまとまり、EvoMap ネットワークへ公開されます。検証を通過したあと、別チームの別の model を動かす別のエージェントが POST /a2a/fetch を送り、その Capsule を受け取ります。ゼロから探し直さずに、修正を継承します。
GEP は設計上、model に依存しません。GPT-4 のエージェントが公開した解も、Claude のエージェントが継承して使えます。GEP のアセットは振る舞いの記述であって、model 固有の重みではないからです。
その経路は Hermes の設計にはありません。正確に言いたいのは、Hermes が劣っているのではなく、そこを狙っていない、ということです。スコープがまったく違う。
核になる設計の違い
両方を読みながら、ずっと欲しかった表がこれです。
```markdown id="n8r4vk"
| Dimension | Hermes Agent | EvoMap / GEP |
|----------------|----------------------------------|--------------------------------------------------|
| Memory scope | Local, single agent | Network-level, cross-agent |
| Skill sharing | Manual, via agentskills.io format | Automatic, via A2A protocol |
| Validation | None built in | candidate → promoted → rejected → revoked |
| Governance | None | GDI scoring + community reports + auto-revoke |
| Network effect | None (closed loop) | Reuse records influence GDI ranking |
| Open standard | agentskills.io (broad adoption) | GEP protocol (open spec, EvoMap reference impl.) |
Hermes は、ひとつのエージェントの生涯における深さを最適化します。EvoMap は、エージェントやチームをまたいだ伝播を最適化します。 絶対的な優劣ではなく、レイヤーが違うので、向き合う問題も違います。
自分の状況にはどちらが合うか
Hermes が向いているとき
単一のエージェント、セルフホスト、個人のワークフローで、修正が他のエージェントへ旅する必要がない場合です。Hermes は MIT ライセンスのフルオープンソースで、インストールはワンコマンド、選んだ model バックエンド以外に API キーを要求しません。
ソロの開発者への正直な答えは、たぶん Hermes の方がシンプルに合う、です。オンボーディングの摩擦は小さく、価値はすぐに見え、GEP プロトコルを理解しなくても永続 memory から始められます。ひとりでエージェントがひとつなら、EvoMap のネットワーク効果はまだ回り始めていません——他のノードが貢献し始めるまで、回らないでしょう。
EvoMap が向いているとき
複数のエージェントやチーム単位のワークフローを回していて、あるエージェントが見つけた修正を、別のエージェントがゼロから探し直さなくてよくしたい場合。あるいは、能力のライフサイクルを監査可能にしたい場合。あるいは、ネットワークに貢献した解から Credit を得たい場合。
EvoMap の A2A ドキュメントでは、POST /a2a/hello による接続フローを示しています——ノード登録に API キーは不要です。フル統合を自分で最後まで通したわけではないので、「これは直感的だ」という判断は、実際にやった人に任せます。
共存はあり得るか
たぶん、あり得ます。レイヤーが違うからです。Hermes は agentskills.io オープン標準と互換で、原則として Hermes のエージェントは EvoMap のネットワークノードとしてもつながり得ます——ローカルに skill を積みながら、検証済み Capsule を公開してエージェント横断の継承にも回す、という組み合わせです。その組み合わせを自分では試していません。設計上、禁じているようには見えません。
FAQ
Q: Hermes Agent は、プロジェクトとしてどのくらい成熟していますか？
GitHub のスター数がおおよそ 24,200、最近 v0.7.0 が出た、という時点で、いまのオープンソースエージェントのなかではいちばん技術的におもしろいプロジェクトのひとつだと思います。活発なコミュニティ、第三者の skill のエコシステム、デモを超えた本番の利用例があります。
Q: agentskills.io は本当にオープン標準で、Anthropic 形式に過ぎないのでは？
Agent Skills は Anthropic が保守するオープン形式で、コードは Apache 2.0、ドキュメントは CC-BY-4.0、コミュニティの貢献を受け付けています。Microsoft は VS Code と GitHub で採用し、Cursor、Goose、Amp、OpenCode など、よく使われるコーディングエージェントも追随しています。囲い込みではありません。
Q: 外部から取り込んだ EvoMap の Capsule を実行して安全ですか？
A2A プロトコル経由で取り込んだ外部の Gene / Capsule は、隔離された candidate ゾーンにステージングされます。ローカルストアへの promote は、明示的な --validated フラグが要ります——運用者が先に資産を検証する必要があります。promote に関わるコマンドはすべて、安全チェックに対して監査されます。直接実行ではなく、まず隔離、というモデルです。
Q: ソロの開発者への正直な答えは？
たぶん Hermes です。EvoMap の価値は、ネットワークにノードが増えるほど複利で効いてきます。ひとりの開発者だけでは、そのフライホイールはまだ回っていません。Hermes なら、ネットワークプロトコルを先に理解しなくても、自分のマシンですぐに永続 memory と skill の蓄積が始められます。誤っているかもしれません——ただ、いまの理解はそこに着地します。
Q: agentskills.io と GEP は、厳密には何が違うのですか？
agentskills.io はファイル形式の標準です——skill 文書がどう見えるかの仕様で、異なるエージェント・プラットフォームが読めるようにします。GEP は publish、validate、promote、減衰、revoke まで含む、資産全体のライフサイクルを持つプロトコルです。agentskills.io の skill に状態はありません。GEP の Capsule にはあります。技術的な分岐点はここです。
どちらの行方も、しばらくは見続けると思います。比較には、ここで触れた以上の層がありそうです——特に Hermes のエージェントと GEP のノードが、同じワークフローに並び始めたときに何が起きるか。
その部分は、まだ完全には見えていません。また書きに来ます。
