Hermes Agent 入門 — 初心者のためのハンズオンガイド｜2026-09 版
第 6 章

スキルシステム — 経験からスキルを自作するエージェント

組み込み 58 スキルの歩き方、SKILL.md 形式、自動スキル作成、Skills Hub からの導入

この章で分かること

これは何か

スキル（Skill）とは、エージェントが必要になったときだけ読み込む「オンデマンドの知識文書」である。前章の永続メモリが「セッションのたびに system prompt へ強制的に注ぎ込まれる短い事実」だったのに対し、スキルは「使う場面が来るまでは意識されず、必要になった瞬間だけ本文が読み込まれる長い手続き」という正反対の性質を持つ。公式ドキュメントも、メモリは常に文脈にあるべき小さな永続的事実を保存し、スキルは関係があるときだけ読み込まれるべき長い手続きを保存する分業だと言い切っている。「記憶＝事実」「スキル＝手続き」と対で覚えておくとよい。

スキルには次の経路から触れる。

2026-09 時点（v0.21.0）で、Hermes 本体に同梱される組み込みスキルは実測 58 個、任意で追加できる公式オプションスキル（optional-skills/）は実測 137 個ある。この数はバージョンが上がるたびに増減するので、正確な現在値を知りたければ後述の一覧コマンドで確認するのが確実である。

いつ使うのか

典型的な使いどころは次の 4 つである。

「事実を覚えさせたいのか、手続きを持たせたいのか、それとも過去の会話そのものを掘り起こしたいのか」で選ぶ仕組みが変わる。第 5 章の使い分け表に、本章で扱う仕組みを加えると次のようになる。

やりたいこと選ぶ仕組み
環境やユーザーについての短い事実を毎回説明したくない永続メモリ（第 5 章）
過去の具体的なやり取りを掘り起こしたいセッション検索（第 5 章）
定型の作業手順そのものを、その場限りでなく再利用したいスキル（自作 / 組み込み）
複数のスキルをいつも同じ組み合わせで呼びたいスキルバンドル
本や大量ドキュメントの要点を蒸留して持たせたい/learn によるナレッジベーススキル
すでに世の中に公開されている手順をそのまま取り込みたいSkills Hub からのインストール

迷ったときの原則はシンプルだ。「毎回文脈に乗っていてほしい短い事実」ならメモリ、「必要なときだけ読み込む長い手続き」ならスキル。手続きが複数の定型スキルの組み合わせとしてすでに存在するなら、それを束ねるバンドルを検討する。

スキルディレクトリの正典・探索順とプログレッシブディスクロージャ

~/.hermes/skills/ が全スキルの唯一の正本である。新規インストール時にはリポジトリからバンドル済みスキルがここへコピーされ、Skills Hub からのインストールもエージェントが自作したスキルも、すべて同じこの場所に置かれる。エージェントは任意のスキルを変更・削除できる。

~/.hermes/skills/
├── mlops/
│   ├── axolotl/
│   │   ├── SKILL.md       # 必須
│   │   ├── references/    # 追加ドキュメント
│   │   ├── templates/     # 出力フォーマット
│   │   ├── scripts/       # スキルから呼べる補助スクリプト
│   │   └── examples/      # 参照用の出力例
│   └── vllm/
│       └── SKILL.md
├── devops/deploy-k8s/     # エージェントが自作したスキル
├── .hub/                  # Skills Hub の状態（lock.json, quarantine/, audit.log）
└── .bundled_manifest      # バンドル済みスキルの同期記録

組み込み 58 個の内訳（カテゴリディレクトリ別、括弧内はスキル数）は次のとおり。apple（4：apple-notes、apple-reminders 等）、autonomous-ai-agents（6：claude-code、codex、computer-use 等）、creative（10：architecture-diagram、manim-video、p5js 等）、devops（1：sdlc-review）、email（2）、media（3）、note-taking（1：obsidian）、productivity（14：google-workspace、notion、pdf、xlsx 等）、research（4：arxiv、grounded-citations 等）、social-media（1）、software-development（12：github、test-driven-development、systematic-debugging 等）、web（1）。合計 58。

スキルを探しに行く順序は 3 段階で決まっており、同名のスキルがあれば手前が勝つ。

この探索順序と対になっているのが、スキル本文をいつ読み込むかを決めるプログレッシブディスクロージャ（段階的開示）である。

Level 0: skills_list()           → [{name, description, category}, ...]   (約3000トークン)
Level 1: skill_view(name)        → SKILL.md 全文 + メタデータ
Level 2: skill_view(name, path)  → 参照ファイル 1 本だけ

エージェントが常に手にしているのは Level 0 の一覧（名前・説明・カテゴリだけの軽い索引）だけで、実際にそのスキルが要ると判断したときに初めて Level 1 の本文を読み込み、さらに参照ファイルが要るときだけ Level 2 でその 1 本を読み込む。58 個のスキル本文をすべて常時保持したら大量のトークンを毎回消費することになるが、この段階的開示のおかげで、コストは実際に使った分だけで済む。

必要と判断したら さらに必要なら skills_list() (約3k tokens 常時) skill_view(name) (必要時のみ) skill_view(name, path) (参照ファイル1本) 一覧は常時、本文とファイルは使うときだけ読み込む
図 6-1　スキルは 3 段階で必要な分だけ読み込まれる（プログレッシブディスクロージャ）。一覧は常時、本文と参照ファイルは必要になった時だけロードする。

自動スキル作成 — skill_manage と /learn

skill_manage ツールは、エージェントにとっての「手続き記憶」である。会話の中で非自明なワークフローをやり遂げたとき——多段の手順を組み立てたとき、エラーや行き詰まりを経て動く経路を見つけたとき、ユーザーにやり方を訂正されたとき——system prompt はエージェントに、その手続きを skill_manage で記録するよう促す。次に同じ場面に出会ったときは、一から試行錯誤せずに保存済みのスキルを呼び出せる。

アクション用途主なパラメータ
create新規スキルを一から作るname、content（SKILL.md 全文）
patch部分修正（推奨）name、old_string、new_string
edit構造ごとの全面書き換えname、content（全文置換）
deleteスキルを丸ごと削除name
write_file補助ファイルの追加・更新name、file_path、file_content
remove_file補助ファイルの削除name、file_path

patch が推奨されるのは、変更差分だけがツール呼び出しに乗るためトークン効率が良いからで、SKILL.md 全文を送り直す edit より軽い。

この書き込みを人間の承認制にできるのが skills.write_approval である。既定は false（自由に書き込む）で、true にすると create / edit / patch / delete / write_file / remove_file のすべてが即座にはコミットされず、フォアグラウンドの会話中でもターン終了後のバックグラウンド自己改善レビュー由来でも一律で ~/.hermes/pending/skills/ にステージングされる。SKILL.md は差分をチャットに収めるには大きすぎるため、承認は常にこの経路を通る。

/skills pending             # ステージング中のスキル書き込み一覧
/skills diff <id>           # 差分全文（CLI かダッシュボード推奨）
/skills approve <id>        # 適用（'all' も可）
/skills reject <id>         # 破棄（'all' も可）
/skills approval on          # ゲートを有効化（'off' で無効化）

なお skills.guard_agent_created という別設定もあるが、これは危険パターンを検知するコンテンツスキャナであり、write_approval の承認ゲートとは独立に動く。両者は目的が違うので混同しないこと。

完遂後 保存完了 承認制なら保留 書き込み 反映 次回セッションで呼び出し 難しいタスクを完遂 (エラーや訂正も含む) skill_manage で保存 (create / patch) ターン終了 write_approval なら保留 (/skills pending) SKILL.md として保存 (次回 /skill-name で使える)
図 6-2　自動スキル作成のループ。難しいタスクを乗り越えるたびに skill_manage で手続きを保存し、次回は /skill-name で即座に呼び出せる。write_approval を有効にすると保存前に人間の承認を挟める。

/learn は、SKILL.md を手で書かずに、既に知っていることや資料の山を再利用可能なスキルへ変換する近道である。何を学ばせたいかを自由形式で指定するだけで、エージェントが手持ちのツールで材料を集め、既定の作法（説明文は 60 字以内、標準の節構成、Hermes のツールに基づく記述、存在しないコマンドを創作しない）に従って SKILL.md を執筆する。

# ローカルのSDKやドキュメントディレクトリ（read_file / search_filesで読む）
/learn the REST client in ~/projects/acme-sdk, focus on auth + pagination

# オンラインのドキュメントページ（web_extractで取得）
/learn https://docs.example.com/api/quickstart

# この会話で今しがた歩いた作業手順そのもの
/learn how I just deployed the staging server

# 書籍や論文集などの大きな資料
/learn ~/books/designing-data-intensive-applications.pdf

書籍・論文集・大規模ドキュメントのような大きな情報源は、1 ファイルに詰め込んだり損失の多い要約にしたりせず、ナレッジベーススキルとして保存される。核となる考え方と索引を持つ軽量な SKILL.md 本体に加え、章やトピックごとに蒸留したファイルを references/ 配下に置く構成である。参照ファイルは実際に質問で必要とされるまでコストがかからず、エージェントは skill_view で必要な分だけオンデマンドに読み込む——前節のプログレッシブディスクロージャの Level 2 がまさにこの用途である。蒸留する際は枠組み・定義・判断基準・アンチパターンといった構造を合成するのであって、原文の文章をそのまま複製することはない。同じ話題で /learn を再度実行すると、別スキルを新規作成するのではなく既存スキルに統合される。

/learn の裏側にモデル固有のツールは存在せず、標準的な作法に沿ったプロンプトを組み立ててエージェントに 1 ターンとして渡しているだけである。結果の保存には通常どおり skill_manage が使われるため、前述の write_approval ゲートが有効なら /learn が作ったスキルも承認待ちに回る。

Skills Hub — agentskills.io 互換のオープン標準から導入する

Hermes のスキルは agentskills.io が定めるオープン標準の SKILL.md 形式に準拠しており、README の Community 欄は「Skills Hub」という語をそのまま agentskills.io へリンクしている。実際のインストール機構はそれよりも広く、公式リポジトリ同梱分に加えて 8 種類のレジストリ・発見経路を横断的に扱う「ハブ」として実装されている。

hermes skills browse --source official              # 公式オプションスキルのみ閲覧
hermes skills inspect openai/skills/k8s              # インストール前プレビュー
hermes skills install official/security/1password    # 1コマンドでインストール
hermes skills check && hermes skills update          # 更新確認 → 差分だけ入れ直す
hermes skills uninstall k8s                          # 削除

すべてのハブインストールは、データ流出・プロンプトインジェクション・破壊的コマンド・サプライチェーン上の兆候などを検知する組み込みのセキュリティスキャナを通る。結果に応じて信頼レベルごとの扱いが変わる。

レベル該当ソース方針
builtinHermes 本体に同梱常に信頼される
officialoptional-skills/組み込み並みの信頼。サードパーティ警告なし
trustedopenai/skills、anthropics/skills、huggingface/skills、NVIDIA/skills 等community より緩やかな方針
communityskills.sh・well-known・カスタム GitHub リポジトリなどそれ以外全部注意・警告レベルの指摘は --force で上書き可。dangerous 判定は上書き不可

--force は「非危険」判定のポリシーブロックを上書きするためのフラグであり、dangerous という判定そのものは絶対に上書きできない。加えて、NVIDIA SkillEvaluator（PII 検出・Unicode 密輸検出・スクリプト lint・ライセンス確認）と NVIDIA SkillSpector（静的セキュリティスキャン）を任意で追加導入すれば、インストール確認前に file・line 付きの参考所見（advisory）が追加表示される。この 2 つはあくまで参考情報でありインストールをブロックしない。

1コマンドで スキャン実行 警告 or 通過 dangerousなら 検索・閲覧 (browse/search/inspect) install 実行 (セキュリティスキャン) 信頼レベルで判定 (builtin〜community) ~/.hermes/skills/ /skill-name で使える dangerous は不可 (--force でも通らない)
図 6-3　Skills Hub からのインストールは検索・プレビューのあとセキュリティスキャンと信頼レベル判定を経て ~/.hermes/skills/ に置かれる。危険と判定されたスキルは --force でも通過しない。

プロジェクトローカルスキルとスキルバンドル

リポジトリは自分専用のスキルを持てる。.git を含む最も近い祖先ディレクトリを起点に、<project-root>/.hermes/skills/（Hermes 独自）または <project-root>/.agents/skills/（他ツールとも共有できる規約）が探索される。ただしスキルはエージェントが従う手続き文書なので、クローンしただけの見知らぬリポジトリから自動で読み込まれることはない。初回はバナーで通知され、明示的な信頼操作が必要になる。

hermes skills trust             # 現在のリポジトリを信頼
hermes skills trust ~/myproject # パス指定でも可
hermes skills untrust           # 信頼を取り消す

信頼したリポジトリは skills.trusted_project_dirs に記録され、skills.project_discovery: false にすればこの機能自体を丸ごと止められる。信頼は一度きりの許可ではなく、git pull のたびに内容が変わり得ることを踏まえ、プロジェクトスキルは Skills Hub と同じセキュリティスキャナで毎回チェックされる。dangerous 判定が出たスキルは検疫（quarantine）扱いとなり、スキル索引にも skills_list にもスラッシュコマンドにも一切現れず、名前指定でも読み込みを拒否される。スキャン結果はコンテンツのハッシュ単位で ~/.hermes/cache/project_skill_scans/（リポジトリの外）にキャッシュされ、内容が変わったときだけ再スキャンされる。cron のような非対話的な実行環境は、対話 CLI での信頼判断をそのまま引き継ぐだけで、自分から確認や自動信頼はしない。

先に見た探索順序（project → local → external_dirs）どおり、プロジェクトスキルは同名のバンドル済みスキルや自作スキルより常に優先される——このホームグラウンドでだけ勝つ、という設計である。

スキルを個別に呼ぶ代わりに、先頭から最大 5 個までの /スキル名 を連ねて一度に読み込むこともできる（/ で始まらないトークンに達したところで解釈が止まるので、ファイルパスのような引数を誤って飲み込むことはない）。だが毎回同じ組み合わせを使うなら、そのたびに列挙するよりスキルバンドルにする方が短くて済む。

hermes bundles create backend-dev \
  --skill github-code-review \
  --skill test-driven-development \
  --skill github-pr-workflow \
  -d "バックエンド機能開発 — レビュー・テスト・PRワークフロー"

これで /backend-dev このauth周りのミドルウェアをリファクタして のように 1 コマンドで 3 つのスキルがまとめて読み込まれる。バンドルは ~/.hermes/skill-bundles/<slug>.yaml という小さな YAML ファイルで、中身はこうなっている。

name: backend-dev
description: バックエンド機能開発 — レビュー・テスト・PRワークフロー
skills:
  - github-code-review
  - test-driven-development
  - github-pr-workflow
instruction: |
  常に失敗するテストを先に書いてから実装すること。

バンドルはスキル名を並べただけの YAML エイリアスであり、スキル本体そのものを内包しているわけではない。 列挙された名前は ~/.hermes/skills/ か external_dirs に実在していなければならず、バンドルを作っても中身のスキルが自動でインストールされるわけではない。名前が同じバンドルとスキルが両方存在する場合はバンドルが勝ち、列挙されたスキルのうち存在しないものは致命的なエラーにはならず黙ってスキップされる。バンドルは対話 CLI・TUI・ダッシュボード・各メッセージングゲートウェイのすべてで同じように動き、system prompt を書き換えないため呼び出しのたびにプロンプトキャッシュを壊すこともない。

ハンズオン 6-1　組み込みスキルを一覧して、中身を 1 つ読む

  1. インストール済みスキルの一覧を確認する。
/skills list

組み込み 58 種とインストール済みハブスキルの名前・説明が一覧表示されるはずだ。

  1. 気になったスキルを 1 つ選び、中身をファイルとして直接確認する（例: axolotl スキル）。
cat ~/.hermes/skills/mlops/axolotl/SKILL.md

frontmatter（name / description / version 等）と、When to Use / Procedure / Pitfalls / Verification という節構成がそのまま生のテキストで見えるはずだ。エージェントの説明を介さずに、自分の目で手続きの中身を検証できる。

  1. 会話の中でそのスキルを実際に呼び出す。
/axolotl help me fine-tune Llama 3 on my dataset

今読んだ SKILL.md の内容（Level 1）が読み込まれた状態で、応答がその手続きに沿ったものになれば成功。

ハンズオン 6-2　Skills Hub から外部スキルを導入する

  1. サイトが公開する well-known エンドポイントを検索する（今回は Mintlify のドキュメントサイトを例にする）。
hermes skills search https://mintlify.com/docs --source well-known

ここから先は外部の公開エンドポイントへの接続が発生する。 Mintlify 側のサーバーへアクセスし、そこが配布する SKILL.md を自分のエージェントに組み込むことになる。組み込んだ内容はエージェントの文脈に読み込まれ実行され得るため、内蔵スキャナが通したからといって鵜呑みにせず、次の inspect のプレビューと SKILL.md の中身に目を通してから進める。

  1. インストール前に、来歴情報をプレビューで確認する。
hermes skills inspect well-known:https://mintlify.com/docs/.well-known/skills/mintlify

リポジトリ URL・週間インストール数・アップストリームの監査状況といったメタ情報が表示される。

  1. 内容に問題がなければ、セキュリティスキャンを通してインストールする。
hermes skills install well-known:https://mintlify.com/docs/.well-known/skills/mintlify

well-known ソースは信頼レベルが community のため、データ流出やプロンプトインジェクションの兆候がないかを検査した結果が表示されたうえでインストールされる。

  1. 試し終えたら後片付けとして削除する。
hermes skills list --source hub               # インストールされたスキル名を確認
hermes skills uninstall <確認したスキル名>

ハンズオン 6-3　/learn で会話からスキルを作らせて中身を確認する

  1. 言葉で説明した手順を /learn に渡す。
/learn filing an expense: open the portal, New > Expense, attach the receipt, submit

エージェントは、説明文 60 字以内・標準の節構成・存在しないコマンドを創作しないという作法に従って SKILL.md を書き上げ、skill_manage（create）で保存したと応答するはずだ。応答にはどの名前・カテゴリで保存したかが含まれる。

  1. 応答で示されたスキル名を使って、保存されたファイルを直接確認する。
cat ~/.hermes/skills/<カテゴリ>/<スキル名>/SKILL.md

When to Use / Procedure / Pitfalls / Verification の節が、こちらが実際に説明した手順どおりに書かれているか確認する。skills.write_approval を有効にしている場合は即座には保存されず /skills pending に積まれるので、そちらを確認して /skills approve <id> する。

  1. 次回から同じ手順をスラッシュコマンド 1 つで呼び出せることを確認する。
/<スキル名>

引数なしでスキル名だけ呼べば、エージェントが手続きを踏まえたうえで何を入力すればよいか聞き返してくる。

つまずきポイント

README の「40+ tools」をスキル数と読み違えない — README の比較表で Skills System の行のすぐ近くに「40+ tools, toolset system, terminal backends」という記述があるが、これは Tools & Toolsets というツール数のカタログについての説明であり、スキルの個数ではない。組み込みスキルの実測値は 58 個（2026-09 時点、v0.21.0）であり、バージョンが上がれば増減する。正確な現在値は /skills list で確認するのが確実。

スキルバンドルはスキル本体を持たない — バンドルはスキル名を列挙して 1 つのスラッシュコマンドにまとめる YAML エイリアスに過ぎない。バンドルを作っただけでは中のスキルはインストールされず、列挙したスキルが手元に無ければそのスキルだけが黙ってスキップされる（エラーにはならない）。バンドルを配る前に、依存するスキル自体を ~/.hermes/skills/ か external_dirs に用意しておく必要がある。

クローンしただけのリポジトリのスキルは自動で読み込まれない — プロジェクトローカルスキルは、初回はバナー通知だけで実行されず、hermes skills trust で明示的に信頼するまで有効にならない。信頼した後も安全というわけではなく、git pull のたびに内容が再スキャンされ、dangerous 判定が出れば検疫されてスキル索引から静かに消える。

--force はどんな警告も通すわけではない — --force が上書きできるのは「注意・警告」レベルのポリシーブロックだけで、dangerous という判定そのものは絶対に通らない。また skills.write_approval（人間の承認ゲート）と skills.guard_agent_created（危険パターンの内容スキャナ）は別物で独立に動くので、片方だけ設定して安心しないこと。

理解度チェック

Q1. Hermes の組み込みスキルは実測何個ですか。README の「40+」という数字と混同しやすい理由も含めて説明してください。

実測 58 個（2026-09 時点、v0.21.0）。README の比較表で Skills System の行の近くにある「40+ tools」は Tools & Toolsets という別カタログのツール数についての記述であり、位置が近いためスキル数と混同しやすい。

Q2. プログレッシブディスクロージャの Level 0・1・2 はそれぞれ何を返しますか。

Level 0 の skills_list() は名前・説明・カテゴリだけの軽い一覧（常時ロード）。Level 1 の skill_view(name) は SKILL.md の全文とメタデータ（必要時のみ）。Level 2 の skill_view(name, path) は特定の参照ファイル 1 本だけ（さらに必要な時のみ）を返す。

Q3. スキルの探索順序 project → local → external_dirs は、同名スキルがあった場合どれが優先されますか。

手前が優先される。プロジェクトローカルスキルが最優先で、同名の local や external_dirs のスキルより優先される。local と external_dirs が同名なら local が勝つ。

Q4. skill_manage の patch と edit の違いは何ですか。また skills.write_approval を有効にすると何が変わりますか。

patch は old_string/new_string による部分修正で差分だけを送るためトークン効率が良く推奨される。edit は SKILL.md 全文を置き換える構造的な書き換え。write_approval を true にすると、create/​edit/​patch/​delete/​write_file/​remove_file のすべてが即座にはコミットされず ~/.hermes/pending/skills/ にステージングされ、/skills pending・diff・approve・reject で人間が確認してから適用する。

Q5. スキルバンドルの YAML ファイルには何が書かれていて、何は書かれていませんか。

name・description・束ねるスキル名のリスト（skills）・任意の追加指示（instruction）が書かれる。スキル本体（SKILL.md の中身）は書かれておらず、バンドルは既存スキルへの参照を並べただけの YAML エイリアスである。

まとめ

参考リンク