スキルはAIの手順書である
Hermes Agent におけるスキルは、単なるテンプレートではなく、ある作業をうまく進めるための再利用可能な手順知識です。
GitHub運用、MCP設定、画像生成、特定サービスの定型業務などをスキル化することで、毎回ゼロから考える必要がなくなります。
自分でスキルを作るAI
Hermes Agent は、人間がスキルを与えるだけでなく、エージェント自身が skill_manage を通じてスキルを作成・更新できます。
複雑な作業をやりきった後、その成功手順を保存して次回以降に再利用できるため、“同じ失敗を繰り返しにくいAI”になります。
Progressive Disclosure による軽量運用
スキルシステムは、一覧だけ、本文、参照ファイルという段階読み込みを採用しています。必要な情報だけを読むため、多数のスキルがあってもコンテキストを浪費しません。
多機能化と推論効率を両立する重要な仕組みです。
Skills Hub と共有知識の広がり
Hermes Agent のスキルはローカルに閉じません。Skills Hub や external skill directories によって、コミュニティスキルや組織内共有スキルを読み込めます。
本体の機能だけでなく、どんなスキル資産を持つかが Hermes の実力を左右するようになります。
運用事例: 受託開発チームの納品チェックスキル化
ある受託開発のチームでは、これまで納品前に担当者ごとにバラバラだった最終確認作業を、Hermes Agent のスキルに落とし込むことで標準化しました。リンク切れの確認、アクセシビリティの項目チェック、ビルド後のサイズ確認、ステージングURLの疎通など、人によって抜けが出やすい工程をひとつのスキルに集約しています。
- 課題: レビュー品質が担当者によって大きくばらつき、差し戻しや顧客からの指摘が月に数件発生していた。
- 解決策: 納品チェック手順を skill_manage で「deliverable-review」というスキルとして登録し、納品前に必ず Hermes に依頼する運用へ移行。
- 成果: 手順の抜けが目に見えて減り、熟練メンバーの暗黙知が新人にもそのまま渡せる状態になった。スキル更新によって気づきが即座に全員へ波及する体制ができた。
興味深いのは、スキル化したあとに「このチェック項目はもう古いですね」という議論がチーム内で自然に起きるようになったことです。スキルはドキュメントと違って毎回使われるため、現実に合わないと感じたらすぐに改善しようという空気が生まれます。
運用事例: マーケティング担当のリサーチ型スキル
マーケティング領域では、競合調査や業界トレンドの収集といったリサーチ業務が頻繁に発生します。あるBtoB SaaS の担当者は、Hermes のスキルとして「競合リサーチの型」を作り、対象企業名を入れるだけでヒアリング観点・公開情報の一次整理・差別化仮説までを一定の粒度で出せるようにしました。
- 課題: 毎回プロンプトを組み直していて、出力粒度が安定せず、資料作成の時間が読めなかった。
- 解決策: 過去にうまくいったリサーチ手順をスキル化し、入力だけを可変にする設計に変更。
- 成果: リサーチ所要時間が半分以下になり、出力のフォーマットが揃ったことで資料化の工数も削減。
スキルはプロンプト集ではなく、「いつ、どの情報を、どの順で拾うか」という段取りそのものを保存できる点が大きな違いです。
スキル定義の記述例
Hermes のスキルは、メタデータと本文、必要ならば参照ファイルに分かれています。以下は、Markdown 形式で記述する場合の簡易的なイメージです。
---
name: deliverable-review
description: 納品前チェックを標準化するスキル
triggers:
- 納品前チェック
- デリバリーレビュー
inputs:
- project_dir
- staging_url
---
# Deliverable Review Skill
1. project_dir のビルド出力を確認する
2. staging_url の疎通と主要導線をチェックする
3. 画像の alt、meta、sitemap.xml の整合を確認する
4. 指摘事項を Markdown でまとめ、担当者へ渡すこのように、スキルは「何を入力すれば、どんな手順で、どんな出力を返すのか」をひとつのドキュメントで宣言できます。呼び出し側はスキル名を指定するだけで、Hermes がその手順に沿って動いてくれます。
CLI からのスキル管理コマンド
CLI からは、skill_manage を通じてスキルの登録・更新・一覧表示が行えます。ふだんの運用で触る頻度の高いコマンドは次の通りです。
# 新しいスキルを追加する
hermes skill add ./skills/deliverable-review.md
# スキル一覧を確認する
hermes skill list --scope local
# スキルの本文を開いて編集する
hermes skill edit deliverable-review
# 組織の Skills Hub と同期する
hermes skill sync --remote org-hubスキルの所在を local / team / hub と分けておくと、個人用のメモと組織共通の正式版が混ざらず、運用が整理されます。
Progressive Disclosure の内部動作
スキルが増えても推論コストが膨らまないのは、Hermes が必要なときだけ本文や参照ファイルを読み込む仕組みを持っているからです。流れをざっくり書くと次のようになります。
1. エージェントはまずスキル一覧(メタデータのみ)を読む
2. 依頼内容にマッチしそうなスキルを選ぶ
3. 選んだスキルの本文を読み込む
4. さらに細部が必要なら参照ファイルを取りにいくこの段階的な読み込みによって、100個以上のスキルがあっても、毎回の会話で読むのは必要な分だけに抑えられます。スキル資産を育てながらも、動作は軽いまま保てるという設計思想です。
スキル設計のベストプラクティス
スキルは作るほどに効いてきますが、やみくもに増やすと逆にノイズになります。実際に運用するうえで、次のような指針を守ると扱いやすくなります。
- ひとつのスキルはひとつの目的に絞る。複数タスクを混ぜない。
- スキル名は動詞+対象で命名する(例: review-deliverable、summarize-weekly-metrics)。
- description は検索されることを前提に、具体的なキーワードを入れる。
- 参照ファイルはスキル本文より大きくなりそうな情報に限定する。
- 失敗したときの挙動(どこで止まるか、どう通知するか)も本文に書いておく。
特に命名はあとから効いてきます。半年後の自分が一覧から探せる名前になっているか、というのが良いチェックポイントです。
よくある質問
Q. スキルはどこに保存されますか?
A. ローカル環境のスキルディレクトリに Markdown として保存されます。チームで共有する場合は Git リポジトリや Skills Hub 経由で配布することが多いです。秘匿情報はスキル本文に書かず、参照ファイルや環境変数に分けておくのが安全です。
Q. スキルとプロンプトテンプレートは何が違いますか?
A. プロンプトテンプレートは文字列の雛形ですが、スキルは「いつ呼ばれるか」「どの道具を使うか」「どんな手順か」まで含んだ実行可能な知識単位です。エージェント自身が必要なスキルを選んで呼び出せる点が決定的に異なります。
Q. スキルのバージョン管理はどうすればよいですか?
A. Skills ディレクトリを Git 管理するのが基本です。チーム運用では、main にマージされたものを正式版、個人ブランチで育てているものを実験版として分ける運用がうまくいきます。
Q. スキルはどのくらいの粒度で作ればいいですか?
A. 「一度覚えた段取りをまた書くのが面倒だ」と感じた瞬間がスキル化のサインです。最初は雑なメモでも構いません。使いながら磨くのが一番長続きします。
Q. スキルが多すぎて選ばれないことはありませんか?
A. Progressive Disclosure により選定段階ではメタデータしか読まれないため、数が多いこと自体は問題になりません。ただし description が曖昧だと選ばれにくくなるので、description だけは丁寧に書く価値があります。
僕の体験談
実は最初に Hermes のスキルを導入したとき、僕は完璧な手順書を書こうとして、いきなり数千字の巨大なスキルを作ってしまいました。結果として、自分でも中身を把握しきれず、どの状況で呼び出すべきかがわからなくなってしまったんです。Hermes も「このスキルは該当しそうだが自信がない」という動きになり、思ったほど再利用されませんでした。
失敗から学んだのは、スキルは最初から完璧を目指さなくていいということ。小さく作って、使いながら育てるほうが、はるかに生きた知識になる。
そこで方針を切り替え、まずは「5行で書ける雑なスキル」を10個つくるところから再スタートしました。毎週の KPI まとめ、ブログ記事の事実確認、画像生成の設定テンプレなど、生活のなかで何度もやっている作業を片っ端からスキル化していきました。不思議なもので、粒度が小さいほど組み合わせが効いてきて、気づけば Hermes がひとりで複数のスキルを連鎖させて段取りをこなすようになっていました。
今では、新しい作業を頼むときは最初から「これはあとでスキル化するぞ」という気持ちで会話しています。うまくいった手順を振り返って skill_manage で保存しておくだけで、次回から自分も Hermes もラクができる。この小さな積み重ねが、時間が経つほどに効いてくるのを肌で感じています。
スキル導入ステップのチェックリスト
これからスキルを育てていくチームのために、最初の一ヶ月で押さえておきたいステップを並べました。上から順に進めれば、無理なくスキル運用が回り始めるはずです。
- ステップ1: チームで「よく発生するがフォーマットが決まっている作業」を5つ挙げる。
- ステップ2: そのうち一番単純なものから、雑でいいのでスキル化してみる。
- ステップ3: 実際に1週間、そのスキルを呼び出して使い、違和感がある部分を書き換える。
- ステップ4: 使える手応えが出てきたら、他のメンバーにも共有して同じ作業を任せてみる。
- ステップ5: 月末にスキル一覧を振り返り、呼ばれていないスキルを削除または統合する。
- ステップ6: 四半期ごとに Skills Hub と同期し、組織標準として残すものを選ぶ。
大事なのは、最初から網羅しようとしないことです。毎日触る作業から1つずつスキル化していけば、三ヶ月後にはチーム全体の動きが目に見えて軽くなります。
注意点と落とし穴
便利な反面、スキル運用にはいくつか気をつけるべきポイントもあります。現場で遭遇しがちな落とし穴を整理しておきます。
- 秘匿情報をスキル本文に直接書かない。Skills Hub に同期したときに事故になりやすい。
- 古くなったスキルを放置しない。呼ばれないスキルほど、description が現実と合わなくなっている。
- スキルが多すぎると感じたら、小さいスキルを束ねた「複合スキル」を作って交通整理する。
- ログを残す。スキルがどのくらい呼ばれているかを可視化すると、不要なスキルが見えてくる。
- 同名のスキルを複数スコープで重ねない。どちらが呼ばれるのか混乱のもとになる。
スキルはチームの資産ですが、放置すると負債にもなります。四半期に一度、棚卸しをする時間を取るだけで、運用はずいぶん健やかに保てます。