同梱のプラグイン

Hermes には、リポジトリと一緒に配られる小さなプラグインの一式が入っています。置き場所は <repo>/plugins/<name>/ で、~/.hermes/plugins/ に自分で入れたプラグインと並んで自動的に読み込まれます。フック、ツール、スラッシュコマンドという仕組みは他社製のプラグインとまったく同じで、違いは Hermes 本体の中で手入れされている点だけです。

プラグインの仕組み全体は プラグイン のページを、自分で書きたいときは Hermes プラグインを作る を見てください。

見つけ方の仕組み

PluginManager は次の4か所を、この順番で調べます。

1. 同梱 — <repo>/plugins/<name>/（このページで説明しているもの）
2. 利用者 — ~/.hermes/plugins/<name>/
3. プロジェクト — ./.hermes/plugins/<name>/（HERMES_ENABLE_PROJECT_PLUGINS=1 が必要）
4. pip のエントリーポイント — hermes_agent.plugins

名前がぶつかったときは後から見つかったほうが勝ちます。つまり disk-cleanup という名前の利用者プラグインを置けば、同梱のものが差し替わります。

plugins/memory/ と plugins/context_engine/ は、同梱の探索対象からわざと外してあります。記憶の提供元と文脈エンジンは1つだけ選ぶ形の仕組みで、設定の hermes memory setup や context.engine から選ぶため、これらのディレクトリは別の経路で見つけられます。

同梱プラグインは自分で有効にする

同梱プラグインは無効の状態で配られます。探索では見つかるので hermes plugins list や対話的な hermes plugins の画面には出てきますが、自分ではっきり有効にするまでは1つも読み込まれません。

hermes plugins enable disk-cleanup

~/.hermes/config.yaml から指定することもできます。

plugins:
  enabled:
    - disk-cleanup

これは自分で入れたプラグインとまったく同じ仕組みです。同梱プラグインが勝手に有効になることはありません。新しく入れたときも、すでに使っている環境を新しい Hermes に上げたときもです。いつでも自分の意思で有効にします。

同梱プラグインをまた止めたいときはこうします。

hermes plugins disable disk-cleanup
# or: remove it from plugins.enabled in config.yaml

現在同梱されているもの

リポジトリの plugins/ には次の同梱プラグインが入っています。どれも自分で有効にする形なので、hermes plugins enable <name> で使えるようにしてください。

記憶の提供元（plugins/memory/*）と文脈エンジン（plugins/context_engine/*）は 記憶の提供元 に別立てで載せてあります。前者は hermes memory、後者は hermes plugins から扱います。ここから先は、長く動き続けるフック型の2つについて、プラグインごとに詳しく見ていきます。

disk-cleanup

セッション中にできたその場限りのファイル — 試し書きのスクリプト、一時的な出力、定期実行のログ、古くなった chrome のプロファイル — を自動で覚えておき、消してくれます。エージェントが「片づけのツールを呼ぶ」ことを覚えておかなくても済みます。

動き方:

消す条件:

スラッシュコマンド — /disk-cleanup は CLI とゲートウェイのどちらのセッションでも使えます。

/disk-cleanup status                     # breakdown + top-10 largest
/disk-cleanup dry-run                    # preview without deleting
/disk-cleanup quick                      # run safe cleanup now
/disk-cleanup deep                       # quick + list items needing confirmation
/disk-cleanup track <path> <category>    # manual tracking
/disk-cleanup forget <path>              # stop tracking (does not delete)

状態 — すべて $HERMES_HOME/disk-cleanup/ の下にあります。

安全のために — 片づけが手をつけるのは HERMES_HOME か /tmp/hermes-* の下だけです。Windows のマウント先（/mnt/c/...）は受け付けません。よく知られた最上位の状態ディレクトリ（logs/、memories/、sessions/、cron/、cache/、skills/、plugins/、そして disk-cleanup/ 自身）は、たとえ空でも消しません。入れたばかりの環境が最初のセッションの終わりに中身をさらわれることはありません。利用者のプロジェクトの木（workspace/、projects/、plans/、home/）は、そもそも記録も一掃もまったく行いません。プロジェクトの中にある test_*.py や tmp_* というファイルは、一時的な残骸ではなくソースコードだからです。kanban/（タスクの添付ファイルと作業場所）も同じく記録しません。また cache/ のような守られた最上位の下にある、記録済みの*ディレクトリ*そのものが消されることはなく、古くなって消えていくのはその中のファイルだけです。

有効にする: hermes plugins enable disk-cleanup（hermes plugins の画面でチェックを入れても構いません）。

また止める: hermes plugins disable disk-cleanup。

security-guidance

ファイルの書き込みに対して、型の照合で素早くセキュリティの注意を出します。エージェントの write_file／patch／skill_manage が運ぶ中身に、危ないと分かっているコードの型 — pickle.load、SafeLoader なしの yaml.load、eval(、os.system、subprocess(..., shell=True)、JavaScript の child_process.exec、React の dangerouslySetInnerHTML、生の .innerHTML =／.outerHTML =／document.write、Node の crypto.createCipher、AES の ECB モード、TLS の検証を切っているもの、XXE を招きやすい xml.etree／minidom の解析器、SRI のない <script src="//..." >、weights_only=True のない torch.load、GitHub Actions の ${{ github.event.* }} の差し込み — が含まれていると、ツールの結果に ⚠️ Security guidance の一節を書き足します。

ファイル自体は書き込まれます。モデルは次のターンでツールのメッセージとしてその警告を読み、コードを直すか、その書き方がこの場面では安全である理由を書き残すかを選べます。型の照合はどうしても見当違いの警告が出ることがあり、だからこそ既定は「止める」ではなく「知らせる」になっています。

守備範囲: 全25ルール。安全でない復元、コマンドの差し込み、XSS の出口、暗号の落とし穴、XXE、供給網（SRI）、CI/CD のワークフローへの差し込みをまかないます。型のデータは Anthropic の claude-plugins-official を Apache-2.0 のまま丸ごと取り込んだもので、出どころの表示はプラグインの LICENSE と NOTICE を見てください。

動き方の切り替え:

有効にする: hermes plugins enable security-guidance（hermes plugins の画面でチェックを入れても構いません）。

また止める: hermes plugins disable security-guidance。

まだできないこと: 元になった Anthropic のプラグインには、さらに2つの層があります。ファイルに触れたエージェントのターンごとに差分を LLM が見直す層と、コミットの時点でファイルをまたいでデータの流れを追う層です。どちらもまだ移していません。エージェント自身は delegate_task を使って、必要なときにその見直しを走らせられます。

Langfuse（プラグインカタログへ移動）

Langfuse でのトレース記録は、Hermes に同梱されなくなりました。いまは公式の langfuse カタログプラグインとして提供されています。フック、HERMES_LANGFUSE_* の環境変数、記録のモードはこれまでと同じです。

hermes plugins install langfuse

observability/langfuse を有効にしていたプロファイルには、hermes update を実行したとき （または更新後に初めて起動したとき）にこのプラグインが自動でインストールされて有効になり、 同じ Langfuse のプロジェクトへ引き続きトレースが送られます。設定、細かな調整、記録のモードは プラグインの README で説明されています。

NeMo Relay の本体組み込み（移行にあたって）

NeMo Relay は、もう Hermes に同梱されるプラグインではありません。hermes plugins enable observability/nemo_relay は実行しないでください。Relay のセッション、ターン、LLM、ツールの流れは Hermes 本体が受け持つようになりました。

Relay の中間処理や書き出しは、Relay の標準的な plugins.toml で設定します。Hermes は Relay の利用者ごとの設定（~/.config/nemo-relay/plugins.toml）を読み、続いて端末全体のシステム設定（/etc/nemo-relay/plugins.toml、Windows では %ProgramData%\nemo-relay\plugins.toml）を読みます。Hermes を立ち上げる前に HERMES_NEMO_RELAY_PLUGINS_TOML を設定するのは、利用者ごとの設定の代わりに特定のファイルを使いたいときだけです。その場合もシステム設定のほうが優先されます。この決まりは、その Hermes のプロセスが抱えるすべてのプロファイルに一括で効きます。どのファイルが使われているかは hermes doctor で確かめられます。ATOF、ATIF、OpenTelemetry の選び方は NeMo Relay observability configuration を見てください。

以前の HERMES_NEMO_RELAY_ATOF_* と HERMES_NEMO_RELAY_ATIF_* の設定では、もう書き出しの設定はできません。HERMES_NEMO_RELAY_PLUGINS_TOML が設定されていないとき、残っている古い変数についてゲートウェイが警告し、hermes doctor も知らせます。これとは関係なく、Relay の利用者ごとの設定やシステム設定で見つかった書き出しはそのまま効きます。

自動の移行。 hermes update（または hermes migrate relay、すべてのプロファイルのホームを対象にするなら hermes migrate relay --all-profiles）は、以前の変数を <hermes home>/relay-plugins.toml に変換し、そのプロファイルの .env に HERMES_NEMO_RELAY_PLUGINS_TOML を設定し、以前の行をコメントにします（消すものはありません）。ゲートウェイを多重化している場合は、プロファイルのホームごとに自分のファイルが作られます。作られるファイルは、書き込む前に Relay で検証されます。出来上がる形は次のとおりです（書き出し先の種類を示す type = "file" に注意してください。これが無い書き出し先は拒否されます）:

version = 1

[[components]]
kind = "observability"
enabled = true

[components.config]
version = 4
enable_full_payloads = false

[components.config.atof]
enabled = true

[[components.config.atof.sinks]]
type = "file"
output_directory = "/home/you/.hermes/telemetry/nemo-relay/atof"
filename = "hermes-atof.jsonl"
mode = "append"

[components.config.atif]
enabled = true
agent_name = "Hermes Agent"
model_name = "unknown"
output_directory = "/home/you/.hermes/telemetry/nemo-relay/atif"
filename_template = "trajectory-{session_id}.json"

[components.config.opentelemetry]
enabled = false
endpoints = []

[components.config.policy]
unknown_component = "warn"
unknown_field = "warn"
unsupported_value = "error"

そのあと .env に HERMES_NEMO_RELAY_PLUGINS_TOML=/home/you/.hermes/relay-plugins.toml を足し、ゲートウェイを再起動します。

セッションの区間を区切る（ずっと続くセッション向け）

Relay は、区間の範囲が閉じたときにそれを書き出します。ゲートウェイのセッションはずっと続くことがあり、ターンごとの区間は普通に書き出されても、セッションの区間だけが何日も開いたままになりがちです。区切りの設定を使うと、ターンの切れ目でセッションの範囲だけを入れ替えられます。

gateway:
  telemetry:
    session_segments:
      on_compaction: false  # rotate after context compaction
      max_turns: 0          # 0 = unlimited; N = turns per segment

どちらの既定値でも、セッションの範囲はまるごと1つのままです。入れ替わった区間は同じ session_id を保ったまま、hermes.session.segment と hermes.session.segment_reason（compaction か max_turns）が加わります。

google_meet

エージェントが Google Meet の通話に参加し、書き起こし、話に加わる ためのものです。会議の内容を書き留め、終わったあとにやり取りをまとめ、気になった点を追いかけ、さらに望むなら TTS で通話に声を返すこともできます。

加わるもの:

• ブラウザの自動操作で Meet の URL に入る、画面を持たない仮想の参加者
• 設定された音声認識の提供元による、会議の音声のその場での書き起こし
• 通話に入り、書き起こしを随時取り出し、聞いた内容をもとに動くための meet_join／meet_status／meet_transcript／meet_leave／meet_say の道具立て
• 会議のあとに残る成果物（書き起こし、状態）。~/.hermes/workspace/meetings/<meeting_id>/ に保存されます

設定:

hermes plugins enable google_meet
hermes meet setup   # preflight: playwright, chromium, auth file
hermes meet auth    # opens a browser to sign into Google and saves session state —
                    # needs a Google account with Meet access. Host approval may be
                    # required if the meeting enforces "only invited participants can join".

チャットからはこう頼みます。

> 「meet.google.com/abc-defg-hij に入って内容を書き留めておいて。終わったら、やることの一覧を付けてまとめを送って。」

エージェントは会議への参加を始め、通話が進むあいだ書き起こしを自分の文脈へ取り込み続け、会議が終わったとき（あるいは止めるように言われたとき）に整ったまとめを作ります。

リアルタイムのやり方（mode='realtime'）は、音まわりでは話す専門です。 ボットの返事は OpenAI Realtime が声にして、仮想のマイクから通話へ流します。ただしボットが*聞いている*のは今までどおり字幕の流れで、会議の音そのものではありません。通話の音が Realtime のセッションへ送られることはありません。meet_status は micState を返します（unmuted、入室のあとに自分でミュートを解除する必要があった場合は unmuted_clicked、Meet の切り替えが見つからなかった場合は unknown）。声を出さないボットの原因を、ここから切り分けられます。

どんなときに使うか: 参加できなかった人のために、定例の進捗確認を書き起こしてまとめておきたいとき。聞き取り調査のように、整った記録がほしいとき。そのほか Fireflies や Otter、Grain を使うことになりそうな場面です。AI に聞かれたくない場では、有効にしないでください。

止める: hermes plugins disable google_meet。保存された書き起こしは、自分で消すまで ~/.hermes/workspace/meetings/ に残ります。

hermes-achievements

Steam 風の実績タブをダッシュボードに足します。実際の Hermes のセッション履歴から作られる、段位付きの収集バッジが60種類以上あります。ツールの連携技、デバッグの型、勢いに乗ったコーディングの連続記録、スキルや記憶の使い方、モデルや提供元の幅広さ、生活のくせ（週末や夜のセッション）まで。もとは @PCinkusz さんが外部のプラグインとして作ったもので、Hermes の機能の変化と足並みをそろえるために本体へ取り込まれました。

動き方:

• ダッシュボードの裏側で ~/.hermes/state.db のセッション履歴をすべて調べます
• セッションごとの集計は (started_at, last_active) の指紋で覚えておくので、次に調べるときは新しいものと変わったものだけを見直します
• 初めての集計は裏の処理として走ります。セッションが何千件ある場合でも、ダッシュボードがそれを待って止まることはありません
• 解放した記録は $HERMES_HOME/plugins/hermes-achievements/state.json に残ります

段位の進み方: Copper → Silver → Gold → Diamond → Olympian。それぞれのカードには「What counts」という欄があり、何を数えているのかがそのまま書いてあります。

実績の状態:

API — 経路は /api/plugins/hermes-achievements/ の下にあります。

状態のファイル — $HERMES_HOME/plugins/hermes-achievements/ の下にあります。

速さについて:

• 8,000 件ほどのセッションを初めて調べると数分かかります。ダッシュボードへの最初の要求で裏の処理として走り、画面は待機中の表示を出しながら /scan-status を見に行きます。
• 初回の集計中も途中経過が出ます — 250 件ほど進むごとに途中までの結果が公開されるので、画面を更新するたびに解放済みのバッジが増えていきます。何分もゼロを眺めることはありません。
• 2回目以降は、started_at と last_active の指紋が控えと一致するセッションの集計を使い回すので、履歴が大きくても数秒で終わります。
• 手元に持っている結果の有効期間は120秒です。過ぎていても古い結果をすぐ返し、裏で新しくします。期限が切れたというだけで待たされることはありません。

有効にする: 何もしません。hermes-achievements はダッシュボードだけのプラグインで、節目のフックもモデルから見えるツールも持ちません。hermes dashboard を最初に立ち上げたときに、自分でタブとして登録します。plugins.enabled の設定が効くのは節目やツールを持つプラグインだけで、ダッシュボードのプラグインは dashboard/manifest.json だけを頼りに見つけられます。

使わないようにする: plugins/hermes-achievements/dashboard/manifest.json を消すか名前を変えるか、~/.hermes/plugins/hermes-achievements/ に同じ名前でダッシュボードを持たない利用者プラグインを置いて上書きしてください。$HERMES_HOME/plugins/hermes-achievements/ の状態のファイルは残るので、入れ直せば解放の記録もそのままです。

同梱プラグインを足すには

同梱プラグインの書き方は、ほかの Hermes プラグインとまったく同じです — Hermes プラグインを作る を見てください。違うのは次の点だけです。

• 置き場所が ~/.hermes/plugins/<name>/ ではなく <repo>/plugins/<name>/ になる
• hermes plugins list では、出どころが bundled と表示される
• 同じ名前の利用者プラグインがあれば、そちらが同梱のものより優先される

同梱にふさわしいのは、こんなプラグインです。

• 追加の依存がない（あっても、宣言済みの追加パッケージ all にすでに含まれている）
• そのふるまいが多くの人の役に立ち、止めたい人だけが止める形になっている
• エージェントがいちいち呼ぶことを覚えておかないといけない処理を、節目のフックに任せられる
• モデルから見えるツールを増やさずに、本体の機能を補える

反対に、同梱にせず自分で入れてもらうべきものもあります。API キーが要る他社サービスとの連携、限られた場面でしか使わない流れ、依存が大きく膨らむもの、そして既定のままでエージェントのふるまいを大きく変えてしまうものです。