---
license: "MIT. Translation of the Hermes Agent documentation, Copyright (c) 2025 Nous Research. See https://wiki.winsmux.dev/hermes/licenses.txt"
title: "プラグインカタログ"
description: "審査済みのプラグインをワンクリックで入れて、Hermes に新しい力を足す"
upstream_path: user-guide/features/plugin-catalog.md
upstream_blob: 71d4c915d684fb7841758692ea454df9a66777db
sources:
  - https://hermes-agent.nousresearch.com/docs/user-guide/features/plugin-catalog
---

# プラグインカタログ {#plugin-catalog}

プラグインカタログは、人の目で審査された Hermes プラグインをまとめたディレクトリです。
コマンド1つ、名前を指定するだけで導入できます。

```bash
hermes plugins install <name>
```

見て選びたいときは **[/docs/plugins](https://hermes-agent.nousresearch.com/plugins)** を開いてください。
カテゴリ（メモリ、デスクトップ、プラットフォーム、Web とブラウザ、ツール、音声、自動化、
モデル）ごとに棚が分かれていて、検索、ティア絞り込み（公式 / 認証済み / コミュニティ）、機能チップ、
そして各項目のコピーできるインストールコマンドが並びます。

カード（クリックできます）ごとに専用ページ `/docs/plugins/<name>` もあります。
説明の全文と注意書き、固定されたコミット、ツール・フック・環境変数、デスクトップ用の
インストールボタンと CLI コマンド、スクリーンショット（ある場合）と審査時のコミットの README、
さらに **この作者の他の作品** の棚が載ります。作者ごとのページ `/docs/plugins/by/<maintainer>` には、
その人がカタログで保守しているものがすべて並びます。どちらも同じカタログファイルからビルド時に
生成されるので、ページが変わるのは PR がマージされたときだけです。

カタログは既存の[プラグインの仕組み](/hermes/docs/user-guide/features/plugins/)を置き換えるものではなく、補うものです。
カタログから入れたものも中身はふつうのプラグインで、カタログは見つけやすさと審査の層を
その上に足しているだけです。

デスクトップのオンボーディング中には、セットアップガイドが承認カードを通じてカタログのプラグインやスキルを
勧めることもあります。各行は Install をクリックしたときにだけ `default` プロファイルに入り、
このページで説明しているのと同じ審査済みのコミットが使われます。

## 項目の中身 {#whats-in-an-entry}

カタログの各項目は、hermes-agent リポジトリの
[`plugin-catalog/`](https://github.com/NousResearch/hermes-agent/tree/main/plugin-catalog)
ディレクトリに置かれた小さな YAML ファイルで、次の内容を宣言します。

| 項目 | 意味 |
|---|---|
| `name` | `hermes plugins install` に渡すカタログ上のキー |
| `description` | カードとインストール時の確認に表示する1行の説明。審査担当からの開示事項もここに含めます |
| `repo` | そのプラグインの公開 git リポジトリ |
| `sha` | 審査された**正確な 40 桁の 16 進コミット**。インストールはブランチの先端ではなくこの固定値をチェックアウトします |
| `subdir` | モノレポの場合に、リポジトリ内のプラグインの場所を示すパス。`[A-Za-z0-9._/-]+` に合うふつうの相対パスにします（`..`、`.`、空の区切り、絶対パスやバックスラッシュの形は不可）（任意。既定はリポジトリの最上位） |
| `tier` | `official`（NousResearch が保守）、`verified`（統合する製品を持つ信頼できる企業から提供されたものだと Nous チームが確認済み）、または `community`。`official` と `verified` を設定できるのは Nous のメンテナーだけです |
| `category` | 並ぶ棚。`desktop`（既定）、`memory`、`platform`、`web`、`tools`、`voice`、`automation`、`models`、`general` |
| `maintainer` | そのプラグインの持ち主 |
| `capabilities` | 宣言されたツール、フック、ミドルウェア、必要な環境変数 |
| `requires_hermes` | 必要な Hermes の最低バージョン。たとえば `>=0.19`（任意） |
| `platforms` | OS の制限。空ならすべて（任意） |
| `title` | カードに表示する人向けの名前。たとえば `NVIDIA App`（任意。省略時は `name`） |
| `onboarding` | `true` にすると、デスクトップのオンボーディングカードで、ホスト型コネクタの隣にこのプラグインを並べます。対象は項目に書かれたプラットフォームです。選別されるのは公式の項目だけです（任意、既定は `false`） |
| `docs_url` | 外部ドキュメントへのリンク（任意） |
| `known_issues` | インストール時の確認に表示する短い注意書き。たとえば対応していないインストール方法など。知らせるためのもので、インストールを止めることはありません（任意） |
| `version` | 固定した sha に付ける読みやすいラベル。たとえば `"1.4.0"`。CLI、カタログのカード、デスクトップの **Update to** ボタンでは `1.4.0 @ abcd1234` と表示されます（任意、見た目だけ） |
| `image` | カタログのカードとプラグインページの見出しに使うバナー画像。2:1 で表示されます（1200×600 が使いやすく、他の比率は中央で切り取られます）。`raw.githubusercontent.com`、`github.com`、`*.githubusercontent.com` 上の `https` URL を指定します（任意）。審査の下で中身が変わらないよう、その項目のコミットに固定してください（`raw.githubusercontent.com/owner/repo/<sha>/...`） |
| `screenshots` | プラグインページにギャラリーとして並ぶ画像、最大6枚。ホストの条件は `image` と同じです（任意）。これもコミットに固定してください |
| `readme` | プラグインページは既定でリポジトリの README を表示します（まず項目の `subdir`、無ければリポジトリのルート）。取得はドキュメントのビルド時に**固定されたコミットから**行われ、ブランチからは取りません。つまり審査した人が読んだ README がそのまま出て、固定が動いたときだけ変わります。隠したいときは `false` にします。GitHub と GitLab のリポジトリに対応（任意、既定は `true`） |

## 信頼の考え方 {#trust-model}

カタログは、自分が何を入れようとしているのかがはっきり分かるように作られています。

- **人がマージして初めて載る。** どの項目も（固定値の更新も）保守担当がレビューした
  プルリクエストを通って入ります。自動で入るものはありません。
- **SHA での正確な固定。** 項目が固定するのはブランチではなく特定のコミットです。プラグインの
  作者がリポジトリに新しいコードを push しても、カタログが入れるものは**変わりません**。
  固定を更新するには、もう一度レビュー付きの PR が要ります。
- **載せるときに走査し、入れるときは信頼する。** 受け入れ時の CI は、インストーラーが走らせるのと
  同じセキュリティスキャナーを実行します（`hermes plugins validate` には `security scan` の
  チェックが含まれます）。`dangerous` と判定されればその項目は落ち、`caution` の指摘は
  審査する人に一覧で示されます。審査した人がそれを見ているので、固定された SHA をそのまま
  チェックアウトするカタログ経由のインストールは `caution` について改めて尋ねません。
  `dangerous` は変わらず止めますし、生の URL から入れたものや別のリビジョンで入れたものには
  通常どおり確認が出ます。
- **デスクトップのプラグインはアプリと同じ権限で動く。審査が境界線です。**
  プラグインの `desktop/plugin.js` はデスクトップアプリ自身の中、アプリのコードと同じ領域で
  評価されます。サンドボックスは無く、アプリにできることは何でもできます（ゲートウェイの RPC、
  `window.hermesDesktop` ブリッジの全機能、他のプラグインの保存領域）。守ってくれるのは
  上に書いた信頼の考え方です。人が固定されたコミットそのものを読み、インストールされるのは
  そのコミットである、という点。加えて仕掛けが2つあります。受け入れ時の `desktop surface`
  lint がプラグイン SDK の外へ出る分かりやすい手口を拒みます（組み込みのプロトタイプへの
  パッチ、`eval`、`@hermes/plugin-sdk`/`react` 以外の読み込み、リモートのスクリプトの取り込み）。
  そしてアプリのローダーが読み込み時にも SDK 以外の import をもう一度拒みます。lint は `<script` を含む正規表現
  （リテラル、または `.replace()`/`.split()`/`.match()` にそのまま渡すか `.test()`/`.exec()` で使う
  `new RegExp(...)` のパターン文字列）を、注入ではなく本来の役目どおりの無害化処理として扱います。
  一方、DOM に書き込まれる `<script` の文字列は、`new RegExp(...).source` から組み立てたものも含めて、
  引き続き不合格になります。この lint は
  審査の助けであって保証ではないと考えてください。デスクトップ側にも Python 側と同じ目を
  向けてください。
- **Hermes を実行時に書き換えない。** 載っているプラグインは、公開された接点（フック、
  ミドルウェア、プロバイダーのプロファイル、デスクトップ SDK のスロット）を通して Hermes を拡張し、
  コアの関数・メソッド・デスクトップの UI をその場で置き換えることはしません。2 つのプラグインが同じ
  継ぎ目を書き換えると互いに壊し合い、コアのリリース1つで両方が壊れることもあるからです。審査の
  `no core override` チェックは、Hermes のモジュール・クラス・その表を実行時に差し替える Python を拒み、
  `desktop surface` の lint は、アプリ自身のマークアップを探してコアの UI の見た目を変えたり、隠したり、
  クリックしたり、書き換えたりする `desktop/plugin.js` のコードを拒みます。
- **機能の宣言。** 各項目は、そのプラグインが提供するツール・フック・ミドルウェアと、必要な
  環境変数（API キーなど）を最初に明示します。入れる前に影響範囲を判断できます。
- **削除リスト。** カタログから取り下げられたプラグイン（たとえばセキュリティ上の問題が
  あった場合）は、理由と日付を添えて `plugin-catalog/removed.yaml` に載ります。照合は名前か
  リポジトリの同一性で行われ、同じリポジトリの `git@`、`ssh://`、`http://`、`www.` といった
  書き方はすべて一致します。インストーラーは削除リストにあるものを入れませんし、入れた*あとで*
  リストに載ったプラグインは更新が止まり、有効にできなくなり、読み込み時にも拒まれます
  （`hermes plugins remove <name>` で外すか、承知の上で使い続けるなら `--allow-removed` を付けて
  入れ直します）。
- **入れることと有効にすることは別。** カタログのプラグインを入れるとディスクに置かれますが、
  他のプラグインと同じで、読み込まれるには有効にする操作が別に要ります。
  [プラグイン → 有効化と無効化](/hermes/docs/user-guide/features/plugins/)を参照してください。

:::warning カタログの審査はその時点の審査です
カタログに項目があるということは、固定されたコミットを人が見て、機能の宣言が確認され、
そのリポジトリが応募の水準を満たした、ということです。セキュリティ監査ではありませんし、
同じリポジトリの他のコミットについては何も言っていません。認証情報を預けるものは、
自分でコードを確認してください。
:::

## カタログから入れる {#installing-from-the-catalog}

```bash
# Install a reviewed catalog entry by name (checks out the pinned SHA)
hermes plugins install <name>

# Then enable it, as with any plugin
hermes plugins enable <name>
```

インストール時の確認画面には、クローンが始まる前に、その項目の機能のまとめ（宣言された
ツール、フック、必要な環境変数）が表示されます。端末ではそのあと「Enable now?」と聞かれるので、
「はい」と答えれば上の 2 つのコマンドが 1 回で済みます（スクリプトでは `--enable` / `--no-enable` で
この問いに答えられます）。

カタログ上の名前と、プラグイン自身のマニフェスト上の名前は違うことがあります。そのあとの
コマンド（`enable`、`disable`、`show`、`capabilities`、`update`、`remove`）は、どちらの名前でも
受け付けます。カタログ上の名前は、Hermes が項目をクローンしたときに書いたインストール記録を通して
解決されます。プラグイン自身のリポにあるファイルを通すことはありません。たとえば
`touchdesigner` の項目（twozero の MCP サーバーと `touchdesigner-mcp` スキルをまとめた
可搬型の Agent Plugins v1 パッケージ）は `td` として入ります。生成される MCP のツール名が
プロバイダーの関数名の長さ制限に収まるよう、短くしてあります。

```bash
hermes plugins install touchdesigner
hermes plugins enable touchdesigner   # same as: hermes plugins enable td
```

Desktop アプリでは、エージェント側と Desktop 側（`desktop/plugin.js`）の両方を持つパッケージは
1 行にまとまり、それぞれの側に 1 つずつ切り替えスイッチが付きます。パッケージをオンにすると
（インストール画面からインストールするとオンになります。行の **Agent** スイッチでもオンにできます）、
Desktop 側も一緒にオンになります。ただし、その側を自分でオフにしていた場合は別です。オフにする操作は
側ごとのままです。Desktop 側はすべてのプロファイルで共有されているからです。

可搬型のパッケージは stdio の MCP サーバーを同梱することもできます。`snyk` の項目は
Snyk CLI（`npx -y snyk@<version> mcp`）を固定し、`snyk-security-scan` スキルを同梱しているので、
1回入れるだけで Hermes がコード・依存関係・コンテナ・IaC の走査と、その使い方の手順まで
手に入れます。この項目はカタログ上の名前とマニフェストの名前が一致します。

```bash
hermes plugins install snyk
hermes plugins enable snyk
```

### カタログから入れたものを更新する {#updating-a-catalog-install}

`hermes plugins update <name>` は、カタログから入れたものに対して `git pull` を走らせることは
ありません。手元の固定値と現在のカタログの固定値を比べて、カタログ側が（レビュー付きの PR で）
動いていたら、新しい SHA を準備して依存関係を検証してから、それを公開します。有効・無効の状態はそのまま引き継がれ、
プラグインのリポジトリが管理していないファイル（`.example` から作った `config.yaml`、データ
ファイル、`.env`）も残ります。
こうした管理外のファイルの中にシンボリックリンクがあっても、新しいコードの側へたどることはありません。
更新は公開の手前で止まってそのリンクの名前を示すので、それぞれを通常のファイルに置き換えてください。
依存関係やキャッシュのディレクトリ（`.venv/`、`venv/`、`node_modules/`、ツールのキャッシュ）は、
リンクも含めて一切引き継がれません。更新後のプラグインが依存関係を作り直します。
モノレポやサブディレクトリから入れたものは手元に Git のチェックアウトを持たないので、
更新では、新しいリビジョンに含まれないユーザー状態のファイルを残します。プラグインのコードと
動きを決める部分はリビジョンの持ち物なので、古いインストールから復活させることはありません。
対象はソースファイル（Python、`.mjs`/`.cjs`/`.jsx`/`.tsx` を含む JavaScript/TypeScript、
シェル、Ruby、Perl、PHP）、最上位の `dashboard/`、`desktop/`、`skills/`、
`sidecar/`、`node_modules/` ディレクトリ、プラグインのマニフェスト、`mcp.json`、
依存関係のメタデータ（`pyproject.toml`、`package.json`、ロックファイル）です。ユーザー状態の
パスが新しいツリーのファイルやディレクトリの配置とぶつかる場合、更新は公開の手前で止まるので、
入っているコピーも、ユーザーのデータもそのまま残ります。
*管理下の*ファイルに加えた変更は新しいコードへは持ち越されません。
写しが `~/.hermes/plugins-backup/<name>-<sha>/` に保存され、更新時に警告が出ます。
新しい固定値でプラグインのマニフェスト名が変わっていた場合は、古いディレクトリが削除され、
有効フラグは新しい名前へ移ります。`hermes plugins list` はカタログから入れたものを
`catalog:<tier>@<sha>` と表示するので、出どころがひと目で分かります。

有効なプラグインについては、新しいコードで入れ替える前に PM が依存関係を検証します。バージョン、走査、
依存関係、公開のどこかで失敗した場合は、動いているコードと依存関係の選択がそのまま残ります。
無効にしてあるプラグインは無効のままです。
出どころはインストーラーが `~/.hermes/plugins/.install-metadata.json` に記録します。
プラグイン自身のツリーの外なので、審査済みのカタログ経由に見せかけるファイルをリポジトリ側が
同梱することはできません。（プラグインのディレクトリにある `.hermes-catalog.json` は便宜上の
写しにすぎません。）カタログの項目を `--ref <sha>` を付けて入れた場合は、実際にチェックアウト
した SHA が記録されるので、`list`、デスクトップのプラグインタブ、`update` のいずれもが
「審査された固定値から外れている」と報告します。
カスタムの Git プラグインは、記録された Git やフィードの更新方針を保ちつつ、
同じ PM の検証と公開の流れを通ります。

### カタログに無い名前 {#names-not-in-the-catalog}

カタログの項目でない名前をそのまま渡すとエラーになります。審査を経ていない名前の索引が
別にある、ということはありません。そういうプラグインは `owner/repo` か Git の URL で入れるか
（独自の入手元。下記参照）、カタログへ応募してください。

### 最新の取り込み {#live-refresh}

ドキュメントのビルドは、カタログを1つの JSON 文書として公開します
（`https://hermes-agent.nousresearch.com/docs/api/plugin-catalog.json`）。
`search`/`install`/`update` は6時間に1回までの頻度でこれを取得し、`~/.hermes/cache/` に
キャッシュします。そのため、新しい項目や削除は Hermes を更新しなくても手元に届きます。
オフラインのときはキャッシュした写しが24時間まで使われ、その後は手元のチェックアウトに
同梱された写しが引き継ぎます（取得の失敗は1分間覚えられるので、`plugins list` と
ダッシュボードのプラグインページで発生する接続待ちは、入れたプラグインの数だけではなく
最大でも1回分です）。キャッシュした文書と手元のチェックアウトで項目の固定値が食い違う場合は、
新しいほうが勝ちます。文書が公開されたあとにカタログがコミットされたチェックアウト
（`hermes update` した直後など）は、キャッシュにある古いほうではなく自分の固定値を入れます。
ツリー内のリストと公開リストの削除は、キャッシュの新しさに関わらず、常にどちらも適用されます。

### 独自の git URL は別物 {#custom-git-urls-are-different}

`hermes plugins install <git-url>` はどのリポジトリに対しても従来どおり使えますが、
カタログは完全に迂回されます。

- **審査なし** — 審査された固定値ではなく、ブランチの先端にあるものがそのまま入ります。
- **警告の帯**が表示され、そのコードが未検証であることを知らせます。
- 削除リストは変わらず参照されます（問題が分かっているリポジトリは URL でも拒まれます）。

git URL の経路は自分のプラグインや、すでに信頼しているリポジトリに使ってください。
見つけるための場所としてはカタログを使ってください。

## カタログへプラグインを応募する {#submitting-a-plugin-to-the-catalog}

応募は、`plugin-catalog/<name>.yaml` を1つ追加するプルリクエストです。
完全なガイドラインは
**[プラグインカタログへの応募](/hermes/docs/developer-guide/plugins/catalog-submission/)** にあります。
応募前に確認すること、PR とレビューの進み方、受け入れの規則のすべて、
固定値の更新・掲載の取り下げ・削除の扱いが書かれています。このページは
[plugin-catalog の README](https://github.com/NousResearch/hermes-agent/tree/main/plugin-catalog)
にある正式な規則を写したものです。

要点だけ言うと、載っているプラグインは、持ち主が応募したもの（または保守担当が審査した一斉調査で
追加したもの）で、公開リポジトリにあり、正確なコミットに固定され、カタログの CI で
`hermes plugins validate` を通り、自分で自分を更新しません。そして Hermes を拡張するのは公開された
フックとデスクトップ SDK を通してだけで、コアのコードやデスクトップの UI を実行時に書き換えることはしません。

## 関連 {#see-also}

- [プラグイン](/hermes/docs/user-guide/features/plugins/) — プラグインの仕組みそのもの。マニフェストの形式、有効化、
  設定
- [組み込みプラグイン](/hermes/docs/user-guide/features/built-in-plugins/) — Hermes に同梱されているプラグイン
- [Hermes プラグインを作る](/hermes/docs/developer-guide/plugins/) — 自分で書く
- [プラグインカタログのページ](https://hermes-agent.nousresearch.com/plugins) — 一覧を見て選ぶ
- [プラグインカタログへの応募](/hermes/docs/developer-guide/plugins/catalog-submission/) — 受け入れの規則と応募のガイド