技術ブログ

Hermes Agentの「手足」はどう作るか｜Tool・MCP・Plugin・Computer Useの選び方

約7分で読めます
#Hermes Agent#AIエージェント#MCP#Computer Use

「Hermes に手足を付けたい」と考えたとき、私はいきなり画面操作を選ばない。対象に API や CLI があるなら、まずそちらを探す。座標を押すより、名前の付いた関数を呼ぶ方が壊れにくいからだ。

Hermes Agent には、外部へ働きかける経路が複数ある。標準 Tool、MCP、Plugin、Computer Use だ。似て見えるが、保守する人と安全境界が違う。

迷ったら安定した経路から選ぶ

私が使う優先順は次の通りだ。

  1. Hermes の標準 Tool
  2. 対象サービスの公式 API や CLI を扱う MCP
  3. 自分で保守する Plugin
  4. API がない画面だけ Computer Use

上ほど常に優秀という意味ではない。操作対象の状態を機械で確認しやすい順だ。

例えば、GitHub Issue を作るなら画面の「New issue」を押す必要はない。API やgh CLI なら、作成後の Issue 番号と URL を返せる。失敗時には HTTP status や exit code も残る。

一方、古い業務アプリや OS 設定には API がない。その穴を Computer Use が埋める。

標準Toolは最初に確認する

Hermes は Web 検索、ブラウザ、ターミナル、ファイル編集、記憶、cron、サブエージェントなどの Tool を標準で持つ。利用可能な Toolset は次のコマンドで確認できる。

hermes tools

必要な機能がすでにあるなら、新しい接続を増やさない方がよい。設定点、資格情報、更新作業を減らせる。

ターミナルも実行先を選べる。ローカルのほか、Docker、SSH、Modal、Daytona などを使える。私は、信頼できるリポジトリの作業は local、未知のコードは Docker か別ホストという形で境界を変える。

terminal:
  backend: docker
  docker_image: python:3.11-slim

Tool を持つことと、ホスト全体へ触れさせることは別だ。便利な手ほど、届く範囲を狭くしたい。

MCPは既存サービスへの接続に向く

MCP は、Hermes の外にある Tool server を接続する仕組みだ。GitHub、データベース、社内 API、ファイルシステムなど、既存の MCP server がある場面に合う。

Hermes は local stdio と remote HTTP の両方を扱う。カタログから導入する場合は、次の流れになる。

hermes mcp catalog
hermes mcp install <name>
hermes mcp configure <name>

ここで大切なのは、server 単位で全 Tool を開けないことだ。閲覧、作成、更新、削除が同じ server に並んでいても、日常処理に削除が必要とは限らない。tools.includeで必要な関数だけを見せる。

mcp_servers:
  issue_tracker:
    command: npx
    args:
      - -y
      - example-mcp-server
    tools:
      include:
        - list_issues
        - get_issue
        - create_issue

MCP server は、Hermes とは別のコードとして動く。カタログ掲載だけで無条件に信用せず、source、install command、transport、要求される環境変数を読む。外部コードを入れる判断は、Tool 名の便利さより重い。

Pluginは自分の運用ルールをコードにする

既存 MCP がない小さな処理なら、Plugin が扱いやすい。~/.hermes/plugins/に manifest と Python code を置き、JSON Schema で引数を定義する。

Plugin は Tool を増やすだけではない。tool call 後の hook、CLI command、slash command、gateway platform も追加できる。複数機能を 1 つの運用としてまとめたいときに向く。

~/.hermes/plugins/my-plugin/
├── plugin.yaml
├── __init__.py
├── schemas.py
└── tools.py

私は、Plugin handler の返り値に最低でも次を入れたい。

  • success
  • 変更対象の ID
  • 実行結果を確認できる URL やパス
  • 失敗理由

「処理しました」という自然文だけでは、親エージェントが再検証できない。機械で読める結果を返すと、cron にも組み込みやすい。

プロジェクト直下の.hermes/plugins/は、信頼したリポジトリだけで有効にする。リポジトリを開いただけで Python code が動く設計にはしない。

Computer Useは最後の1メートルを埋める

Hermes の Computer Use は、macOS、Windows、Linux の画面を操作する。アクセシビリティ tree から要素を読み、click、type、scroll などを実行する。背景操作に対応し、人間の実 Cursor を動かさない。

導入状況は次のコマンドで確認できる。

hermes computer-use status
hermes computer-use doctor

画面操作が必要なのは、API がない native app、OS の設定画面、古い管理画面などだ。ただし、見た目は変わる。button label も layout も更新される。そのため、座標を固定するより、毎回 accessibility tree を読み、操作後に再取得して結果を確認する。

ログイン済み browser profile や決済画面を動かす場合は、便利さより事故範囲を考える。--yoloは承認を外す。公式資料も、prompt injection や意図しない入力を防ぐ機能ではないと明記している。私は、無人の GUI 操作には専用 account か disposable VM を使う。

「動いた」ではなく結果を読む

手足を増やすほど、完了判定が重要になる。

メール送信なら message ID、Drive への保存なら file ID、Issue 作成なら Issue URL を読み返す。画面操作なら、操作後の window state を再取得する。ファイル生成なら schema 検証と build を通す。

失敗時の扱いも先に決める。再試行してよい読み取りと、二重実行が困る送金や投稿は分ける。同じ「Tool call」でも性質は異なる。何度呼んでも結果が変わらない処理もあれば、呼ぶたびに副作用が増える処理もある。

私にとって Hermes の手足は、操作できる機能の数ではない。結果を識別でき、権限を狭められ、失敗しても止められる経路だ。まず API、なければ MCP や Plugin、それでも届かない場所だけ Computer Use。この順番なら、自動化を増やしても人間が状況を追える。

参考資料

この記事をシェア
hibana
この記事を書いた人
hibana

技術ブログを運営しています。日々の学びや発見を発信中。

関連記事