Hermes Curatorとは｜skill bloat自動剪定
Hermes Agent を数週間から数ヶ月運用していると、~/.hermes/skills/ 配下に自分でも記憶していない skill が溢れていく現象に必ず突き当たります。自己改善ループで Hermes 自身が生成した skill が、不要になっても消されず、似たような skill が増え続け、結果として AI エージェント全体の挙動が読めなくなる——これがコミュニティで「skill bloat」と呼ばれている問題です。
2026年4月、Nous Research の Teknium は、この skill bloat に対する公式対処として「Hermes Curator」をリリースしました。本記事では、長期運用視点で Hermes Curator の役割・動作・セキュリティ上の重要性・運用ベストプラクティスを整理します。
Hermes Curator とは — Skill 自己改善ループの「剪定係」
Hermes Curator は、Hermes Agent が自己改善ループで生成・蓄積した skill 群を、自動で監査・統合・剪定する内蔵システムです。2026年4月、Nous Research の Teknium が v0.11.0 周辺のリリースサイクルで公式アナウンスしました。
Hermes Agent の最大の特徴のひとつは「育つ」設計です。エージェントが日々のタスクを通じて学んだ手順を、再利用可能な skill として ~/.hermes/skills/ に永続保存し続けます。Skill は SKILL.md（マークダウン形式のプロンプトと手順記述）として保存され、次回以降のセッションで自動的に読み込まれます。
この仕組みは強力である一方、「削除する仕組み」がなければ無限に積み上がるという構造的弱点を抱えていました。Hermes Curator は、この空白を埋めるために導入された、いわば「skill 棚卸し係」です。
Hermes 4（モデル）と Hermes Agent（エージェント）は別物
本題に入る前にひとつ整理しておきたいのは、日本語圏で混同されがちな「Hermes」の用語問題です。
- Hermes 4: Nous Research が提供するオープンウェイトの LLM 本体（2025年8月公開、14B / 70B / 405B）
- Hermes Agent: 上記とは別の自律エージェントランタイム（2026年2月公開、Python 88% / MIT ライセンス）
Hermes Curator は後者の Hermes Agentに組み込まれた機能で、Hermes 4（モデル）とは直接の関係はありません。検索時もこの2つは別個に扱う必要があります。
Skill bloat とは何か — 自己改善ループの宿痾
Skill bloat は、Hermes Agent のような自己改善型エージェントを長期運用したときに必ず発生する、構造的な肥大化問題です。具体的には次のような現象を指します。
1. 似たような skill が重複生成される
たとえば「Twitter 投稿の下書きを作る」という skill が、最初の月に1つ生成されたあと、「X のスレッドを書く」「ツイートを推敲する」「X 投稿を改善する」と、似て非なる skill が次々と派生していきます。Hermes Agent は自分で skill を生成するため、既存の skill を再利用するか新規生成するかの判断が常に正確なわけではありません。
2. 一度使ったが二度と使わない skill が永続化する
「ある特定の API レスポンスを整形する skill」など、その時のタスクのために生成されたが汎用性が低い skill が、~/.hermes/skills/ 配下に残り続けます。手動で消さない限り永遠に居続けるため、SKILL.md ファイルの数が単調増加します。
3. 古くなった skill が現役の skill と矛盾する
2ヶ月前に生成された「メール送信時は必ず Gmail API を叩く」という skill と、最新の「メール送信時は SES 経由で送る」という skill が同居していると、Hermes は文脈次第でどちらを使うか揺らぎます。これは挙動の再現性を著しく損ないます。
4. プロンプトインジェクションが「居座る」
後述しますが、公式セキュリティ監査では SKILL.md の永続化は "persistent prompt injection vectors"（永続的なプロンプトインジェクションの侵入経路）と明記されています。一度悪意ある skill が紛れ込むと、それを削除する仕組みがなければずっと残り続けます。
Hermes Agent の公式 FAQ には、自己改善ループの限界として次のような一文が掲載されています。
「あなたが正解を判定できないドメインでは、agent は間違った方向に速くなる」
これは「自己改善が常に正しい方向に進むとは限らない」という、極めて重要な警告です。Hermes Curator は、人間が監視できる範囲を超えて自己改善が暴走することへの、構造的なブレーキでもあります。
Hermes Curator の動作 — 自動統合・剪定・監査
Hermes Curator は、主に3つの動作で skill bloat に対処します。
1. 自動統合（Merge）
類似度の高い複数の skill を、ひとつの skill にまとめる動作です。前述の「Twitter 投稿の下書きを作る」「X のスレッドを書く」「ツイートを推敲する」のような重複は、統合候補としてピックアップされ、ひとつの汎用 skill に再構成されます。
統合の際は、各 skill の利用履歴・成功率・直近の使用日時が参照され、最も実績のあるバージョンを基準に統合されます。
2. 自動剪定（Prune）
長期間使われていない skill、または使用された結果として失敗率が高かった skill は、剪定の対象になります。剪定は「即時削除」ではなく、まずアーカイブ領域に移されることが多く、誤って消した skill を取り戻す余地が残されています。
3. 監査ログ出力
どの skill が統合・剪定されたかは、ログとして出力されます。これは運用者が「自分が知らない間に skill が消えていた」状況を避けるためで、長期運用での挙動の追跡可能性を担保します。
なぜ skill bloat はセキュリティ問題なのか
Hermes Curator がリリースされた背景には、コミュニティが認識した skill bloat のセキュリティ上の重大性があります。Hermes Agent のセキュリティ監査（公式 Issue #7826）を読み込んだうえで、この点は特に強調しておきたいと考えています。
Critical 4 件のうち1つが skill 永続化問題
公式の Hermes Agent セキュリティ監査（Issue #7826）では、Critical（致命的）4件 / High（高優先度）9件の脆弱性が指摘されています。そのうち C4 として明記されているのが次の項目です。
- 内容: Hermes が自己改善で生成した SKILL.md が
~/.hermes/skills/に永続保存される - 分類: "persistent prompt injection vectors"（永続的なプロンプトインジェクションの侵入経路）
- 影響: 一度プロンプトインジェクションを受けると、その悪意ある skill が永続化される。過去のセッションで仕込まれた攻撃が、新しいセッションでも発火し続ける
「skill が増える」は「攻撃面が広がる」と同義
SKILL.md は単なるメモではなく、Hermes Agent が次回以降のセッションで自動的に読み込んで実行ロジックに組み込むプロンプトです。つまり、skill ファイルが増えるということは、次のセッションで Hermes が参照するプロンプトが増えることと同義です。
この中に1つでも悪意あるプロンプトが紛れ込めば、Hermes は新しいセッションで「正規の手順」としてそのプロンプトを実行します。Hermes Curator は、この攻撃面の単調増加を防ぐ「衛生管理機能」として位置づけることができます。
監査 #7826 の他の Critical との関係
セキュリティ監査では skill 永続化以外にも、ターミナルツールの regex バイパス（C1）、ファイル読み取りの deny list 不在（C2）、Docker / Singularity / Modal / Daytona 環境での承認チェック全スキップ（C3）など、深刻な指摘が並んでいます。
Hermes Curator が直接対処できるのは C4 のみですが、「攻撃を受けたあとに、その影響をどれだけ短時間で除去できるか」という観点では、Curator の有無が事後復旧の速度を大きく左右します。
Hermes Agent と他のエージェントの設計思想の違いについては、別記事で詳しくまとめています。
運用ベストプラクティス — Curator を信頼しきらない
Hermes Curator は強力な機能ですが、Curator 単体に依存することは推奨されません。Hermes Agent の長期運用を検証するなかで見えてきた、現時点での運用ベストプラクティスを整理します。
1. 定期的な手動 skill 監査を仕組み化する
少なくとも月次で ~/.hermes/skills/ 配下を目視確認することを推奨します。チェックポイントは次の通りです。
- 身に覚えのない skill が生成されていないか
- SKILL.md の中身に、自分が指示していないはずの外部ドメイン・コマンド・認証情報の言及がないか
- 過去30日間使用されていない skill のリスト
- 類似名・類似機能の skill が重複していないか
監査作業自体を Hermes Agent に依頼するのは循環参照的に危険なので、別環境のエージェントや手動の ls ・ grep で行うのが安全です。
2. Hermes Curator の動作ログを必ず確認する
Curator が「自動的に統合・剪定した skill」のログを、運用者は必ず目を通すべきです。Curator が誤って重要な skill を統合・剪定していないか、または逆に、本来剪定すべき不審な skill を見逃していないかを確認します。
3. Skill 命名規約を運用者側で先に定める
Curator が類似 skill を統合する際の判断材料として、skill 名は重要なメタデータです。あらかじめ命名規約を定めておくと、Curator の挙動も安定しやすくなります。
たとえば次のようなルール設計が考えられます。
{ドメイン}-{動詞}-{対象}の3要素で構成する（例:social-draft-tweet、email-summarize-inbox）- ハイフン区切り、英小文字のみ
- 固有名詞（特定の API 名・サービス名）を skill 名に含めない（API が変わったときに skill 名が陳腐化するため）
- 使い捨てを意図した skill は
tmp-プレフィックスを付け、Curator の剪定対象としてマーク
命名規約自体を SKILL.md の冒頭にコメントとして書いておくと、Hermes Agent が次の skill を生成するときも参考にしやすくなります。
4. 物理的な権限分離を併用する
Hermes Curator は ~/.hermes/skills/ 配下の管理を改善するものですが、そもそも skill が攻撃面になり得るという根本問題は残ります。業務利用の Hermes Agent を運用する場合、次の多層防御を推奨します。
- 外側: 既存のメインマシンと分離した専用マシン（Mac mini や VPS）で Hermes を動かす。本番認証情報・既存メディアの管理画面は同一マシンに置かない
- 中間: Docker コンテナで Hermes を隔離し、local backend は使わない（監査 C3 への対処）
- 内側:
HERMES_WRITE_SAFE_ROOT環境変数で書き込み許可ディレクトリを明示する - 監査: Hermes Curator のログと月次の手動 skill 監査
Curator は「監査」層に位置する機能であり、外側・中間・内側の防御を置き換えるものではありません。
Hermes Curator を活かす長期運用設計
Hermes Curator が単なる削除ツールにとどまらない理由は、「Hermes Agent を半年以上運用する前提の設計」を初めて公式が明示した点にあります。現場で見えてくるのは、次の3つのフェーズです。
フェーズ1: 構築期（運用1〜2ヶ月）
Hermes Agent を導入し、最初の skill 群が生成される期間です。この時期は skill 数がまだ少ないため、Curator の出番はほとんどありません。むしろ、運用者自身が skill の生成パターンを観察し、命名規約や禁則事項を整備するフェーズです。
フェーズ2: 蓄積期（運用3〜6ヶ月）
Skill 数が急増し、重複や陳腐化が顕在化する期間です。Hermes Curator の真価が発揮されるのはこのフェーズで、月次から週次で Curator が走り、統合・剪定のログが運用者に届く設計が望ましくなります。
フェーズ3: スケール期(運用6ヶ月以降)
Skill 数が数百規模に達し、Curator なしでは人手での管理が事実上不可能になる期間です。この段階では、Curator のログ自体を別のダッシュボードで可視化したり、Curator が剪定対象として挙げた skill を運用者がレビューする仕組みが必要になります。
導入時に検討すべき判断ポイント
Hermes Curator を含む Hermes Agent のスキルシステムは強力ですが、すべての業務に向いているわけではありません。導入相談を受ける際に、必ず確認する判断ポイントを整理しておきます。
Hermes Agent 自体が向くケース
- 24時間常駐させたい業務がある（SNS 監視、メール一次対応、定期レポート生成など）
- 複数のワークフローを同時並行で回したい
- プッシュ通知ベースの受信処理（Telegram / Discord / Slack）が必要
- 長期間にわたり、エージェントに「業務文脈」を蓄積させたい
逆に Claude Code 等で十分なケース
- セッション単位の作業が中心で、永続記憶を必要としない
- 業務時間内の対話的な利用がメインで、24時間稼働を必要としない
- セキュリティ・コンプライアンス要件が厳しく、エージェントの自己改善ループ自体が許容できない
後者の場合、Hermes Curator も含めた Hermes Agent の運用負荷は、得られる便益に対して過剰になりがちです。「Hermes Agent が必須かどうか」を率直に伝えることを大切にしています。
Hermes Agent そのものの実務活用については、別記事で実例とあわせて紹介しています。
まとめ — Curator は「設計が成熟した証拠」
Hermes Curator は、Hermes Agent が「ローンチして終わり」ではなく、「長期運用される前提のプロダクト」に進化していることを示すマイルストーンです。自己改善ループという強力な機能を持つ以上、その副作用としての skill bloat は避けられず、Curator はその不可避な副作用に対する公式の回答です。
運用観点で押さえておきたいポイントを再掲します。
- Hermes Curator は2026年4月リリースで、Hermes Agent の自動統合・剪定・監査機能を担う
- Skill bloat は単なる「ファイルが増える問題」ではなく、公式セキュリティ監査で"persistent prompt injection vectors"として Critical 指定されている
- Curator は便利だが、Curator 単体に依存せず、命名規約・定期監査・物理分離と組み合わせる多層防御が前提
- 公式 FAQ「あなたが正解を判定できないドメインでは、agent は間違った方向に速くなる」は、運用者が監視できない領域に自己改善ループを回すことへの根本的な警告
- Hermes Agent 自体の導入判断は、24時間常駐や永続記憶が業務要件として明確にある場合に限ることを推奨
株式会社Fyveでは、Hermes Agent を含む AI エージェントの長期運用について、設計から監査・運用ルール整備まで実務支援を行っています。skill bloat への具体的な対処や、社内環境に合わせた多層防御設計をお考えの場合は、ご相談ください。
Hermes Agent を本気で活用するなら
「Hermes Agent を自分で使いこなしたい」「自社の業務に組み込みたい」
— そんな方は、まず初回無料相談でお話ししてみませんか。