Hermes AgentのTool Searchを試す｜31個の追加ツールを必要な時だけ読む

2026年9月10日

約16分で読めます

私の Hermes Agent には、Search Console 関連だけで 25 個のツールがあります。画像生成や X 検索なども含めると、このセッションで確認できた追加ツールは 31 個でした。

これらを使うのは、必要になった時だけです。それでも全ツールの JSON Schema を毎回モデルへ渡せば、会話を始める前から入力が膨らみます。かといって、使わないツールを無効にすると、必要な場面で仕事を完遂できません。

Hermes Agent の Tool Search は、この二択を避けます。MCP とプラグインのツールを一覧から消さず、詳しい引数定義だけを必要になるまで遅らせます。今回は Search Console の実データ取得まで進め、検索、定義取得、実行の境界を確かめました。

前回完了時から今回完了後まで

前回の「Hermes Agentのプロンプト量を測る」では、hermes prompt-sizeで固定部分を byte 単位に分けました。今回は、測定後に取れる選択肢を 1 つ増やします。

時点	状態
前回完了時	system prompt と tool schema の固定量を測れます
今回開始時	ツールを残したまま schema を減らす流れが未確認です
今回完了後	31個の追加ツールから必要な定義だけを読み、実ツールを呼べます

Tool Search がすでに有効で、tool_describeから実ツールを呼ぶ流れを確認済みなら、「小さい構成では off も選べる」まで飛ばせます。

なぜツールを削る前に遅延するのか

ツールには、名前や短い説明と、引数を定める JSON Schema があります。能力の所在を知るだけなら、最初から全引数を読む必要はありません。

一方、実行時には正確な引数名と型が必要です。Search Console の検索実績を読む場合も、対象プロパティ、期間、dimension などを正しく渡す必要があります。

Tool Search は、能力の発見と実行定義を分けます。

[モデルから見える短いツール一覧]
                 │
                 ▼
       [必要な能力を選ぶ]
                 │
                 ├── 名前が不明 ── tool_search
                 │
                 └── 名前が既知
                         │
                         ▼
                   tool_describe
                   引数定義を取得
                         │
                         ▼
                     tool_call
                   実ツールへ転送

この形なら、ツールの入口は見えたままです。詳しい schema だけを遅らせるため、能力を削らずに固定部分を抑えられます。

用語を揃える

用語	この回での意味
core tool	`terminal`や`read_file`など、Hermes本体が常時直接見せるツールです
deferred tool	schemaの提示を実行直前まで遅らせるMCPまたはプラグインのツールです
Tool Search	deferred toolを検索、定義取得、実行する仕組みです
bridge tool	`tool_search`、`tool_describe`、`tool_call`の3つです
tool schema	ツール名、引数名、型、必須項目などのJSON定義です
catalog	現在のセッションに許可されたdeferred toolの索引です
listing	tool名と短い説明をまとめた、モデル向けの一覧です
cold tool	その会話でまだschemaを取得していないツールです
progressive disclosure	最初は索引だけを示し、必要な詳細を後から読む方式です

core tool は遅延対象になりません。公式仕様では、terminal、read_file、write_file、web_searchなどは直接読み込まれます。対象は MCP と non-core plugin tools です。

現在の設定と固定量を読む

検証した実機は Hermes Agent v0.21.0 です。最初に version と Tool Search の設定を読みます。

hermes --version
hermes config get tools.tool_search.enabled
hermes config get tools.tool_search.listing

2026 年 9 月 10 日の実機では、主要部分が次の値でした。

Hermes Agent v0.21.0 (2026.8.31) · upstream baf7ceea
auto
auto

enabled: autoは、現行仕様ではonと同じ動きです。MCP または non-core plugin のツールが 1 つ以上あると、bridge は有効になります。将来の版で意味が変わる可能性もあります。利用時点の公式文書も確認します。

続いて、固定部分を JSON で保存します。

hermes prompt-size --json > prompt-size-tool-search.json
jq '{platform, model, system_prompt, tools}' \
  prompt-size-tool-search.json

今回の実測値です。

{
  "platform": "cli",
  "model": "gpt-5.6-sol",
  "system_prompt": {
    "chars": 26485,
    "bytes": 28237
  },
  "tools": {
    "count": 20,
    "json_bytes": 35444
  }
}

この数値は、導入した MCP、プラグイン、profile、platform で変わります。記事の値へ合わせるのではなく、自分の環境で変更前後を同じ条件にそろえます。

すでに現在値を保存している場合、この測定は飛ばせます。ただし、比較前の JSON がないまま設定だけを変えると、差を後から確かめられません。

31個の追加ツールがどう見えたか

今回の cron セッションでは、遅延対象として 31 個の追加ツールが表示されました。内訳は次の通りです。

提供元	ツール数	例
Search Console	25	検索実績、index確認、sitemap操作
Computer Use	1	desktop操作
Image generation	1	画像生成と編集
セッション search	1	過去セッション検索
Terminal process	1	background process管理
Todo	1	作業項目管理
X search	1	Xの投稿とthread検索

これは全 Hermes 環境の固定値ではありません。catalog は、そのセッションへ実際に許可された toolset の範囲で作られます。権限のないツールを、bridge 経由で新しく発見する仕組みではありません。

私はこの一覧を「使える能力の目次」として見ます。たとえば Search Console の分析が必要なら、25 個の schema をすべて読む前に、analytics 用の名前を探せます。

検索、定義取得、実行を分ける

bridge の 3 段階は、シェルの subcommand ではありません。Hermes との会話中に、モデルが tool call として使います。

名前が分からない場合は、用途を短い語で検索します。

tool_search
  queries:
    - Search Console analytics query

候補名が分かったら、実行前に schema を読みます。

tool_describe
  names:
    - mcp__search_console__analytics_query

今回取得した schema には、siteUrlが必須と表示されました。ほかにstartDate、endDate、dimensions、filters、rowLimit、engineがありました。

その後、実ツールを呼びます。

tool_call
  name: mcp__search_console__analytics_query
  arguments:
    siteUrl: sc-domain:hibanas.net
    startDate: 2026-08-13
    endDate: 2026-09-09
    dimensions:
      - query
    rowLimit: 100
    engine: google

実行結果では、hermes agent cronが 1 impression、平均掲載順位 10 でした。Tool Search と直接一致する query は、上位 100 件にありませんでした。

大切なのは、tool_callという外箱だけで承認を済ませないことです。Hermes は bridge を外し、実際のツール名に対して hook、guardrail、approval を適用します。今回も、呼び出し先は Search Console の analytics tool です。

listingの量は段階的に縮む

Tool Search は、遅延対象が増えても名前まで直ちに隠しません。公式仕様では、catalog の大きさに応じて表示を 3 段階に変えます。

tier	条件	モデルから見える内容
0	遅延対象がありません	bridgeを使わず、全ツールを直接表示します
1	listingが予算内です	bridgeと、名前や短い説明の一覧を表示します
2	名前だけでも予算を超えます	bridgeと、提供元ごとの短い要約を表示します

listing の予算は、次の小さい方です。

threshold_pct × context length
listing_max_tokens

デフォルト値はthreshold_pct: 5、listing_max_tokens: 4000です。検索結果のデフォルト上限は 5 件、要求できる上限は 25 件です。

一覧に正確なツール名が見えていれば、tool_searchを飛ばしてtool_describeへ進めます。今回の Search Console 検査も、既知一覧から正確な名前を選びました。

小さい構成ではoffも選べる

MCP やプラグインが数個だけなら、常時 schema を見せる方が単純な場合もあります。cold tool の定義取得には、少なくとも追加の round trip が必要だからです。

現在値を確認してから、常時表示へ切り替えます。

hermes config get tools.tool_search.enabled
hermes config set tools.tool_search.enabled off
hermes config get tools.tool_search.enabled

最後の確認で期待する値は次の通りです。

off

検証後にデフォルトの動きへ戻す場合は、次の順で進めます。

hermes config set tools.tool_search.enabled auto
hermes config get tools.tool_search.enabled

期待する確認値です。

auto

config.yamlを直接編集しません。hermes config setを使えば、設定の階層と値を CLI 側で扱えます。

設定を変えた会話の途中で、そのまま比較を続けるのも避けます。toolset の変更は prompt cache を無効にします。新しいセッションを始めるか、gateway 運用なら保守時間に再起動し、同じ platform で再測定します。

小さい toolset で追加 round trip を避けたい場合、この章だけ試せます。多数の MCP を常用しているなら、autoのまま先へ進む方が安全です。

遅延しても消えない費用を知る

Tool Search は、あらゆる場面で通信量を減らす魔法ではありません。固定部分と実行時の費用を交換します。

cold tool では、schema を得るためにtool_describeが増えます。名前が一覧にない場合は、その前にtool_searchも必要です。

取得した schema は会話履歴へ入ります。ただし、system prompt の cache prefix には入りません。同じ会話で再利用できても、最初から固定部分として cache される形とは違います。

また、provider から見えるのは汎用的なtool_call.argumentsです。Hermes は実ツールの引数をローカルで整形し、検証してから転送します。それでも外部参照を含む不正な schema などは、実ツールや MCP server 側の検証が必要です。

私は、次の基準で選びます。

状況	選択
多数のMCPを接続し、毎回使うのは一部です	`auto`で遅延します
数個の小さなtoolsetを毎回使います	`off`との実測比較を検討します
能力自体を許可したくありません	Tool Searchではなくtoolset権限を見直します
会話途中でtool構成を変えたいです	新しいセッションへ分けます

Tool Search は、権限制御の代わりではありません。catalog へ入る前の許可範囲が、最初の境界です。

変更前後を同じ条件で確かめる

比較は、次の順に固定します。

hermes --versionで導入版を記録します。
profile と platform をそろえます。
hermes prompt-size --jsonで変更前を保存します。
enabledとlistingの現在値を読みます。
必要な場合だけoffまたはautoへ変更します。
新しいセッションまたは再起動後に同じ条件で測定します。
固定量だけでなく、目的の実ツールを呼べるか確認します。

最後の確認を省くと、数値だけ小さくても完遂性が落ちた状態を見逃します。今回の合格条件は、Search Console の schema を取得でき、指定期間の analytics query を実行できることでした。

出力 JSON はローカル環境の情報を含む場合があります。そのまま公開せず、必要な項目だけをjqで抜きます。

よくあるエラー

表示・症状	主な原因	対応
`tool_search`で候補が出ません	検索語がcatalog内の名前や説明と合っていません	サービス名と用途を分け、別の短い語で検索します
必要なツールがcatalogにありません	そのセッションへtoolsetが許可されていません	Tool Searchではなく、platformのtoolset設定を確認します
`tool_describe`がunknown nameを返します	候補名を省略または書き換えました	検索結果の識別子をそのまま使います
`tool_call`で必須引数エラーになります	schema確認前に実行しました	`tool_describe`を先に呼び、必須項目と型を確認します
`hermes tool_search`が見つかりません	bridgeをシェルsubcommandとして実行しています	Hermesとの会話内toolとして使います
`enabled`を変えても現在の会話が変わりません	tool配列は会話開始時のcacheと関係します	新しいセッションで再検証します
設定変更後にgatewayとCLIが違います	常駐processが古い構成を保持しています	保守時間にgatewayを再起動し、両方のversionを確認します
`off`にすると固定schemaが増えました	遅延対象を常時表示へ戻しました	小さいtoolset以外は`auto`へ戻して比較します
schemaを遅延したのに応答回数が増えました	cold toolの定義取得が加わりました	固定量とround tripの両方を測ります
bridge経由なら承認不要だと思いました	bridgeと実ツールの境界を混同しています	実ツール名へ適用されるapprovalを確認します

私は能力を捨てずに詳細を遅らせる

今回の環境では、31 個の追加ツールが catalog にありました。その中から Search Console の analytics tool だけを定義取得し、実データを読めました。

常時表示する schema と、必要時に読む schema を分ければ、能力を残したまま固定部分を見直せます。ただし、cold tool の round trip や cache の違いは残ります。少数のツールならoffも選択肢です。

私は、数値を減らすためにツールを消しません。まず能力の目次を残し、詳しい引数を遅らせます。そして最後に、目的の仕事を完遂できるか実ツールで確かめます。

一次情報

出典	確認した内容
Hermes Agent Tool Search	遅延対象、3つのbridge、tier、設定値、cacheと検証の制約
Hermes Agent CLI Commands Reference	`hermes config`と`hermes prompt-size`の位置付け
NousResearch/hermes-agent	公式source repositoryとTool Search実装の確認先

実機検査は Hermes Agent v0.21.0、CLI platform、gpt-5.6-solで行いました。接続する MCP、プラグイン、profile により結果は変わります。

※2026 年 8 月 13 日から 9 月 9 日までの GSC 上位 100 query には、Tool Search と直接一致する語はありませんでした。hermes agent cronは 1 impression、平均掲載順位 10 でした。「AI エージェント / Hermes Agent」の関心テーマを起点に、ツールの能力を残して schema だけを遅らせる実務を選んでいます。

この記事を書いた人

hibana

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