Hermes Agent が 3 月 12 日に一般公開されたとき、リリースには 70 を超える内蔵スキルが詰め込まれていた。ジャンルも 15 種類以上にまたがる。それから四週間後、コミュニティ製スキルのマーケットプレイスが agentskills.io に立ち上がり、さらに数百のスキルが並んだ。この記事は、その背景で何が起きていたのか——そして、自分では一生スキルを書かない人にとっても、Hermes のスキル設計を押さえておく価値がある理由についての話だ。
スキルとは結局なんなのか
ほとんどの AI エージェント・フレームワークでは、「ツール」とは開発者が import 時にエージェントに登録する Python 関数のことだ。関数にデコレータを付けて、docstring を書いて、どこかの tools 配列に放り込む。エージェントが必要になると、フレームワークがその説明を prompt に注入して、モデルのツール呼び出し出力をパースする。
Hermes のスキルはそれとは違う。マニフェスト（skill.yaml）、実行スクリプトや Python エントリポイント一式、前提条件の記述、そして起動ポリシー——これらをひとつにまとめた宣言的なバンドルだ。Hermes は起動時にスキルディレクトリを歩き、すべてのマニフェストを読み、前提条件がこのマシン上で本当に揃っているかどうかを見て、このセッションで使えるスキルを決める。環境変数、PATH 上の実行ファイル、設定ファイルのエントリ、プラットフォーム固有の機能、そういった要素を全部見にいく。
ffmpeg を必要とするスキルは、ffmpeg が入っていないマシンではエージェントの目にすら映らない。Telegram のボットトークンを必要とするスキルは、Telegram につながったセッションでしか起動しない。エージェントの prompt に乗っているのは、その瞬間に本当に使えるスキルだけだ。
小さな設計判断に見える。だがこれこそが、公開初日に 70 個のスキルを抱えたエージェントが prompt を溶かさずに出荷できた理由そのものだ。
Skills Hub は何をする場所か
v0.2.0 以降、Hermes には Skills Hub というものが最初からくっついてくる。このインストールで使えるスキル一覧をメタデータ・出所情報・条件付き起動ロジックごと保持するローカルインデックスだ。hermes skills list で何が入っているかを見て、hermes skills enable <name> や hermes skills disable <name> でオン／オフを切り替え、hermes skills info <name> でマニフェストと出所と具体的な前提条件を確認できる。
この Hub はコミュニティスキルの受け口でもある。スキル作者はマニフェストと実装パッケージを公開し、Hermes のユーザーはコマンド一発でインストールする。Hub はそれに対して、内蔵スキルとまったく同じやり方で前提条件のチェックと起動ルールの判定をかける。「公式」と「コミュニティ」の間に特別なレールはない——どっちも同じスキルだ。
公開から四週間後、この Hub には対外的な顔ができた。それが agentskills.io だ。コミュニティ製スキルのウェブディレクトリで、検索、カテゴリ、人気指標、そして標準化されたインストールコマンドが揃っている。エージェント能力版の npm や pip と考えていい。ただしもっとスコープは狭くて、スキルひとつはひとつのことをやることになっていて、Hermes が安全に使うためのマニフェストが必ず付いてくる。
なぜエコシステムが急速に育ったのか
ゼロから数百のコミュニティスキルまで四週間というのは、短い。そこにはアーキテクチャ上のいくつかの決断が効いている。
マニフェストがインターフェースそのもの。 スキル作者はマニフェストさえ正しく書けばいい。前提条件、説明、入力スキーマ、起動条件——全部 skill.yaml に書く。実装のレイヤーは Python でもシェルスクリプトでも実行バイナリでも、マニフェストから指せるものなら何でも構わない。貢献者は Hermes 専用の SDK をわざわざ学ばなくても、役に立つスキルを書ける。やることは、このツールが何をするのかを YAML ファイルに記述すること——しかもその YAML のフォーマットは、内蔵スキルがとっくに使っているものだ。
前提条件はドキュメントではなく構造に書かれている。 スキルが ffmpeg を必要とするなら、マニフェストにそう書くしかない。そして Hermes が代わりにチェックしてくれる。依存が足りないまま実行時にこっそり失敗するスキルを掴まされる心配はない——Hub が何が足りないのか教えてくれて、そもそも起動を拒む。つまり作者は前提を置けるし、ユーザーはその前提を信じられる。
起動は条件付き。 スキルは「Telegram でだけ起動する」「ある環境変数が立っているときだけ起動する」「ある特定のファイルがあるときだけ起動する」「特定の作業ディレクトリでだけ起動する」と宣言できる。エージェントが見る prompt はその瞬間の状況に合わせて仕立てられている。100 個のスキルを入れていても、あるセッションではエージェントがそのうち 90 個を見ないまま終わる、ということが普通に起きる。結果として prompt は膨張しない。
既定でサンドボックスに優しい。 コードを実行するスキルは、Hermes にもともと備わっているサンドボックス層——v0.2.0 リリースで入った git worktree の隔離と、ファイルシステムのチェックポイントの仕組みの上で動く。暴走したコミュニティスキルがあなたのコードやファイルを本当に壊すことはできない。サンドボックスはエージェント側に焼き込まれているのであって、個別のスキルに押し付けられているのではないからだ。これで、新しいものを入れるときの信頼コストが一気に下がる。
コミュニティスキルは大体どんな形をしているか
最初の四週間のコミュニティスキルは、だいたいいくつかの実用パターンに収まる。
- •既存 CLI ツールのラッパー。 誰かが
ffmpeg、pandoc、imagemagickあたりを取ってきて、よく使う操作——動画を切る、ドキュメントを変換する、画像をリサイズする——を薄く露出させるスキルを書く。作るコストが安くて、しかもすぐに役に立つ。 - •個人サービスとの統合。 ユーザー自身の Notion、Obsidian の vault、Home Assistant、RSS リーダー、Pocket アカウント、個人の家計簿アプリと話すスキル。たいていはマニフェストに加えて 200 行未満の Python で収まっている。
- •特定ワークフロー向けの小回りの利く道具。 研究者向けの論文読みスキル、エンジニアリングリード向けの git log 要約スキル、家で料理する人向けの献立ジェネレーター、テーブルトーク RPG のグループ向けのダンジョンマスター補助スキル。
- •モデル固有のシム。 プロバイダ特有の機能（プロンプトキャッシュのヘッダ、推論バジェット、fine-tuning 用のフック）を、カスタムクライアントコードを書かなくても済むように、正式なエージェントツールとして包み直したスキル。
単体で見ると、どれもキラー機能とは言いがたい。ただ全部を合わせると、「Nous Research が作った何か」だった Hermes が「ひとつのコミュニティ」に感じられるようになった境目が、ここだった。
面白い副作用
agentskills.io のコミュニティスキルが 100 個を超えた日、このプロジェクトには微妙な変化が起きた。Hermes Agent が何であるかを、機能一覧を並べることでは説明できなくなっていたのだ。機能セットは輪郭を失っていた。代わりに説明できるのは、そのかたちだ——唯一のエージェントが、好きなチャットプラットフォームと話せて、必要に応じてスキルを引き込み、それらを全部まとめて統一された安全モデルの下で動かす。
これはもう機能リストではなく、プラットフォームだ。スキルのエコシステムが、その中に含まれるどの個別機能よりも重要な理由もここにある。