Hermes Agent Skills 自作ガイド｜SKILL.md 構造と自動生成のコツ【2026年版】

株式会社Fyveでは、Hermes Agent を中小企業の現場業務に組み込む案件が増えるにつれて、「公式スキルだけでは届かない部分を Skills として自作する」フェーズに入っています。Hermes Agent の Skills は、再利用可能なタスク単位を Markdown ファイル一枚で定義できる仕組みで、設計次第でエージェントの賢さと再現性が大きく変わります。

この記事では、私たちが社内および顧客環境で Hermes Agent の Skills を運用してきた経験をもとに、SKILL.md の構造、自己進化メカニズム、skill bundles の運用、Curator との関係、アンチパターン、そして「自分の業務を1スキル化する」最小ワークフローまでをまとめます。X 上で @akshay_pachaar が「self-evolving skills は most powerful feature」「skill bundles は most underrated feature」と評したのも、実際に運用してみると納得感があります。

Hermes Agent における Skills とは何か

Skills は Hermes Agent が「特定のタスクをどう進めるか」を記述した、再利用可能な Markdown ファイルです。プロンプトのように毎回貼り直す必要がなく、エージェントが必要なタイミングで自動的にロードします。プロンプトテンプレートと違うのは、Hermes 側が「いつ」「どのスキルを」呼び出すかを判断する点です。私たちの観測では、1業務 = 1スキルに切り出した案件ほど、運用後の事故率が低くなる傾向があります。

Skills が向くタスクの典型

• 毎週・毎月発生する定型作業（日報集計、議事録整形、請求書作成補助）
• 外部 API への問い合わせや特定 SaaS のスクレイピング
• ドメイン固有のフォーマット変換（社内テンプレ準拠の議事録など）
• 判断基準が明文化されているチェック作業（コードレビュー、契約書一次チェック）

逆に、毎回判断軸が変わるブレインストーミングや、自由記述の創作タスクは、Skills 化のメリットが薄くなります。

SKILL.md の標準構造

SKILL.md は YAML frontmatter + 本文の Markdown という構造を取ります。私たちが運用しているテンプレートはおおむね次の形です。

---
name: weekly-report-aggregator
version: 1.2.0
description: 週次の業務日報を Slack から集約し、決まったフォーマットで整形する
trigger:
  - "週報まとめ"
  - "weekly report"
  - "日報集計して"
inputs:
  - channel_id
  - period_start
  - period_end
outputs:
  - markdown_report
requires:
  tools:
    - slack_search
    - text_format
  permissions:
    - read:slack_messages
constraints:
  - 個人名は匿名化する（イニシャル化）
  - 出力は 1500 文字以内
  - 推測ではなく原文を引用する
---

## 手順

1. `slack_search` で対象期間・チャンネルのメッセージを取得する
2. 各日報を「業務」「進捗」「課題」「翌週」の 4 軸に分類する
3. テンプレートに沿って Markdown に整形する
4. 個人名はイニシャル化し、原文の数値はそのまま残す

## テンプレート

```
# 週次レポート ({period_start} - {period_end})

## ハイライト
- ...

## 課題
- ...

## 翌週アクション
- ...
```

## 例外処理

- メッセージが 0 件のときは「対象期間に投稿がありません」と返す
- API レート制限時は 30 秒待機して 1 回だけリトライする

各セクションの役割

• frontmatter: メタ情報。Hermes はここを読んで「呼び出すかどうか」を判断する。description と trigger の語彙がトリガーの精度を決める
• 手順: ステップを番号付きで明示する。曖昧な「いい感じに」は禁物
• テンプレート: 出力形式を固定する。これがあるとブレが激減する
• 例外処理: 想定外時の挙動を明示する。実運用での事故を防ぐ最大要因

公式スキルと自己生成スキルの違い

Hermes Agent には標準で複数の公式スキルが同梱されます。X 上で @theo が「100+ skills pre-enabled」を巡って議論したように、初期搭載数の妥当性は意見が分かれるところです。私たちの結論はシンプルで、公式スキルはあくまで「型を学ぶ教材」として扱い、本番運用は自社スキルで置き換えていく方針です。

自己進化（self-evolving）のメカニズム

Hermes Agent の Skills は、呼び出されるたびに「どんな入力で」「どう成功・失敗したか」を学習し、自動的に SKILL.md の補助メモを更新します。これが self-evolving と呼ばれる挙動です。私たちが運用していて分かったのは、自動更新を「全肯定」してはいけないということ。Hermes は誤った成功体験も学ぶため、週次でレビューする運用が必須です。

自己進化を健全に保つ運用

1. SKILL.md の末尾に ## learned_notes セクションを置き、自動追記を1か所に閉じ込める
2. 週1回、人間が learned_notes をレビューし、本体ステップに昇格 or 削除する
3. バージョンを上げたタイミングで learned_notes をリセットする

skill bundles の使い方

skill bundles は、関連する複数のスキルを1つのクラスタとしてまとめる仕組みです。@akshay_pachaar が「most underrated feature」と評した通り、運用が一段落するとここが効いてきます。

---
bundle: client-ops
skills:
  - weekly-report-aggregator
  - meeting-notes-formatter
  - invoice-draft-generator
  - contract-first-pass-review
shared_context:
  - クライアントは中小企業（10〜50名規模）
  - 出力は常に Markdown
  - 数値は推測せず原文引用
---

shared_context をバンドル側で持たせると、各スキルから重複した制約を消せます。私たちは「クライアント別バンドル」「業務領域別バンドル」の2軸で運用しており、新しいクライアントを迎えるときはバンドル単位でクローンしてカスタマイズしています。

Hermes Curator との関係

Hermes Curator は、肥大化したスキル群を自動的に剪定するエージェントです。詳しくはHermes Curator と Skill Bloat の管理ガイドでまとめていますが、Skills 設計時点で Curator フレンドリーにしておくと運用負荷が下がります。

• description と trigger を具体的に書く（曖昧だと Curator が「重複」と判定しやすい）
• 1スキル1責務を徹底する（Curator は巨大スキルを優先的に剪定候補にする）
• 使用頻度メタを定期的に確認し、3か月触られていないスキルは自分で archived にする

自作スキルの典型例 4本

1. メール下書きスキル

受信メールを分類し、社内ルールに沿った下書きを返すスキル。trigger には「返信案」「ドラフト書いて」を入れ、社内のメール文化（敬語の硬さ、署名の有無）を constraints に書き込みます。

2. 日報集計スキル

上の SKILL.md 例で示したもの。Slack や Notion を読みに行き、固定フォーマットで整形します。Hermes Agent Hooks ガイドで紹介している post_run フックと組み合わせると、自動投稿まで完結できます。

3. Web スクレイピングスキル

競合サイトのプレスリリースを定期巡回し、差分を Markdown で返すスキル。constraints に「robots.txt を尊重する」「アクセス間隔は 5 秒以上」を明記しておくのが必須です。

4. 議事録整形スキル

音声起こしの生テキストを、決定事項・宿題・参加者発言の3軸で整形します。テンプレを完全固定するのが品質安定のコツです。

アンチパターン

巨大スキル

1つの SKILL.md にあれもこれも詰め込むと、Hermes がトリガーを誤判定しやすくなり、Curator の剪定候補にもなります。「説明文を1文で書ける単位」に分割するのが目安です。

重複スキル

「議事録整形」と「会議メモ整理」のように、本質的に同じ仕事のスキルが2本あると、どちらが呼ばれるかが不安定になります。新規作成前に既存スキル一覧の grep を習慣にすると防げます。

環境依存の禁則

特定マシンのローカルパスや、開発者個人の API キーを SKILL.md に直書きしてしまうケースをよく見ます。環境依存値は必ず inputs か外部設定に追い出してください。

セキュリティ視点：skill bloat 攻撃への備え

Skills は強力な反面、第三者が悪意あるスキルを混入させると、エージェントが意図せずそれを呼び出すリスクがあります。これは「skill bloat 攻撃」と呼ばれる新興の攻撃面で、私たちは次の3点を必ず設計時に組み込んでいます。

1. Skills の追加は Git 経由のみとし、PR レビューを必須化する
2. 外部由来のスキルは別ディレクトリに隔離し、信頼境界を明示する
3. requires.permissions を必ず宣言し、最小権限で動かす

記憶層側の防御はHermes Agent 3層メモリアーキテクチャ解説でも触れていますが、Skills 層は「実行される処理そのもの」なので、より厳格な管理が求められます。

自分の業務を1スキル化する最小ワークフロー

1. 直近1か月で3回以上繰り返した業務を1つ選ぶ
2. その業務を「入力」「手順」「出力テンプレ」「例外時の挙動」の4要素で言語化する
3. SKILL.md にコピペし、trigger を実際の自分の依頼語彙で書く
4. 1週間運用し、learned_notes と実出力を眺めて手順を調整する
5. 類似スキルが2本そろった時点で bundle に昇格する

このサイクルを回すと、概ね2か月で「自分専用エージェント」と呼べる粒度に育ちます。私たちはこのプロセスを顧客との顧問契約の中で並走支援していますが、ポイントは最初の1本を「派手すぎないが毎週使う業務」で始めることです。

まとめ

• SKILL.md は YAML frontmatter + 手順 + テンプレ + 例外処理の4ブロックで構成する
• 自己進化は learned_notes に閉じ込め、週次レビューで本体に昇格させる
• skill bundles で shared_context を引き上げ、重複制約を削る
• Curator フレンドリーに書くと運用負荷が劇的に下がる
• Skills は実行される処理そのものなので、PR レビューと最小権限が必須

私たちの経験上、Skills を3〜5本そろえて初めて Hermes Agent は「便利な道具」から「業務の一部」に変わります。最初の1本を、来週繰り返す業務から切り出してみてください。