Hermes Agentのサブエージェント設計｜親と子でモデルを使い分ける

14 Aug, 2026

約5分で読めます

3 件の調査を 1 体に順番で頼むと、会話は長くなる。途中の検索結果まで親の文脈に入り、最後の判断に不要な情報も残る。私は、独立した調査は子に渡し、親には結論だけを戻す形が扱いやすいと感じている。

Hermes Agent のdelegate_taskは、子エージェントを別の会話として起動する。子は独自のターミナルセッションを持ち、最後の要約だけを親へ返す。標準の同時実行数は 3 だ。

子は親の会話を使うべきではない言葉なので修正してください

サブエージェントを使うとき、最初につまずくのは文脈の断絶だ。子は親の会話履歴、過去の tool call、直前のエラーを使うべきではない言葉なので修正してください。goalとcontextに書いた内容だけで動く。

悪い依頼は短すぎる。

エラーを直して

これでは、対象ファイルもエラー文も分からない。良い依頼には、作業場所、症状、制約、完了条件を入れる。

/home/user/app の src/auth.py を修正する。
Python 3.11で、47行目にNoneTypeの例外が出る。
pytest tests/auth を実行し、変更ファイルと結果を報告する。

私は、子への依頼を小さな issue として書く。背景を 1 段落、作業範囲を数行、検証コマンドを 1 つ。この形なら、モデルが変わっても結果の比較がしやすい。

同時に走らせやすいのは、互いの結果を待たない仕事だ。

一方で、同じファイルを 3 体に直させると競合しやすい。先に設計を決める必要がある作業も、無理に分けない。並列化は速度を上げるが、統合の費用も増やす。

Hermes では、標準で最大 3 体の子を並列実行できる。上限はdelegation.max_concurrent_childrenで変えられる。ただし、数を増やせば API の rate limit とローカル資源への負荷も増える。

モデルを分けると、費用の形が変わる。親には計画と最終判断が得意なモデルを置く。子には、検索や定型レビューを速く処理できるモデルを置く。

model:
  default: your-frontier-model

delegation:
  provider: openrouter
  model: your-inexpensive-model
  max_concurrent_children: 3

この構成では、親が課題を切り、子が独立して調べる。親は 3 つの要約を読み、矛盾を解く。全工程を高価なモデルで回すより、判断が必要な場所に予算を寄せられる。

ただし、安いモデルに何でも渡す設計は危ない。認証、権限、公開操作の判断は親に残したい。子には読み取り中心の調査や、検証方法が明確な修正を任せる。

子から親に戻るのは最終報告だ。そこで「問題ありませんでした」だけを返されると検証できない。依頼時に、証拠の形式まで指定する。

コード作業なら、次を求める。

調査なら、一次情報の URL、公開日、該当箇所を求める。親は要約を信じ切らず、公開や merge の前に重要な結果を読み直す。

子の文脈を隔離する利点は大きい。ただし、隔離は正しさを保証しない。情報量を減らして判断しやすくする仕組みと考えるのがよい。

複数の子が同じ worktree を触ると、変更が混ざる。Hermes にはdelegation.worktree_isolationがあり、子ごとに Git worktree を用意できる。

delegation:
  worktree_isolation: true

独立した機能やレビュー修正を並列で進める場合に向く。それでも、最後の merge とテストは親側で行う。別々に成功した変更も、組み合わせると型や依存関係の衝突が起きる。

ファイルを書かない調査なら、worktree 分離は不要だ。目的に応じて隔離の費用を払う。

長い委譲は、完了を待つだけでは運用しにくい。Hermes では/agentsで実行中の子と tool call 数を確認できる。live transcript も残るため、同じ検索を繰り返していないか追える。

上限時間や最大反復数も決める。完了条件のない調査は、子が情報を集め続けやすい。私は「公式資料を最大 5 件」「比較表を埋めたら終了」のように出口を書く。

サブエージェントは人数を増やす機能ではない。文脈を分け、判断の場所を限定する機能だ。親と子の責任を言葉にできる仕事ほど、並列化の効果が出る。

この記事を書いた人

hibana

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