サブエージェントと委譲 — 並列化とゼロコンテキスト RPC

これは何か

Hermes のエージェントは、会話の途中で自分自身に似た子エージェントを何体でも呼び出せる。これを担うのが delegate_task という組み込みツールで、これ自体はユーザーがコマンドとして打つものではなく、エージェントが状況に応じて自分の判断で呼び出す。子エージェントは AIAgent のインスタンスとして隔離されたコンテキストで起動され、親と同じツールセットを引き継ぎつつ、独自のターミナルセッションを持つ。子が何をしたかの詳細は親の会話には流れ込まず、最終的な要約だけが戻ってくる。

もうひとつ、性質の異なる委譲手段が execute_code である。こちらは新しい推論主体を作るのではなく、エージェント自身が書いた Python スクリプトを子プロセスとして実行し、スクリプトからツールを呼び戻すための仕組みだ。両者は「コンテキストを圧迫せずに多くの作業をこなす」という同じ問題を、まったく違うやり方で解いている。

ユーザー側から直接触れる入口は主に 2 つある。ひとつは会話の中で「これは別のサブエージェントに任せて」のように明示的に頼む自然言語の指示（もっとも、公式ドキュメントも明言するとおり、エージェントはタスクの複雑さを見てほぼ自動的に委譲を判断するので、明示的に頼む必要は必ずしもない）。もうひとつは、直前の会話が生んだ成果物をレビューさせる /review スラッシュコマンドで、これは対話 CLI・TUI・Desktop・全ゲートウェイプラットフォームで使える。細かな挙動の調整は ~/.hermes/config.yaml の delegation セクションで行う。~/.hermes/ 配下の全体像は 第 2 章 を参照してほしい。

いつ使うのか

典型的な使いどころは次の 4 つである。

• 途中経過まで含めて親の会話に流し込むとコンテキストを圧迫する大きな作業（複数ファイルにまたがるリファクタ、深い調査など）を切り出したい → delegate_task（単発）
• 互いに独立した複数の調べ物・作業を同時に進めたい（トピック A・B・C を並行調査するなど）→ delegate_task（バッチ）
• 「ファイルを探す → 読む → 加工する → 出力する」のような機械的な多段処理を、途中結果をコンテキストに残さず 1 ターンで済ませたい → execute_code
• 直前にできあがった PR・diff・ドキュメントを、別の視点でレビューしてほしい → /review

delegate_task と execute_code は名前こそ似た文脈で語られるが、中身は「推論するかどうか」で根本的に違う。迷ったらこの表で選ぶ。

判断に迷ったときの目安はこうだ。「その場で状況を見て次の一手を決める必要がある」なら delegate_task、「手順そのものは決まっていて、ただ繰り返すだけ」なら execute_code。なお、定型の作業手順自体を再利用したいだけなら、そもそもエージェントを増やす必要はなく スキル（第 6 章）の出番であり、セッションを閉じても生き残る自動実行を組みたいなら cron スケジューラ（第 8 章）の役割になる。この章では、あくまで「今の会話の中で」作業を並列化・委譲する仕組みに絞る。

delegate_task の基本と「サブエージェントは何も知らない」

delegate_task は goal（達成してほしいこと）と context（そのために必要な背景情報）を渡して子エージェントを起動する。単発なら次のように呼ばれる。

delegate_task(
    goal="Debug why tests fail",
    context="Error: assertion in test_foo.py line 42"
)

ここで初心者がもっとも誤解しやすいのが、子エージェントに「何が引き継がれるか」である。公式ドキュメントは次のように明記している。

つまり「あのエラーを直しておいて」のような曖昧な goal だけを渡すと、子エージェントは「あのエラー」が何かを知る手段を持たない。ファイルパス・エラーメッセージ・プロジェクトの前提など、子エージェントが必要とする情報は親が context に全部書き切る必要がある。例外は 1 つだけあり、親が解決済みのワークスペースディレクトリを持っている場合、そのワークスペースのプロジェクト規約ファイル（.hermes.md → AGENTS.md チェーン → CLAUDE.md → .cursorrules の優先順位、人格定義の SOUL.md は対象外）は全サブエージェントの system prompt に自動で埋め込まれる。つまりリポジトリの規約を守らせたいだけなら、それは自動で伝わる。

バッチモードの並列実行と execute_code による RPC

バッチモード（並列実行）

goal / context のペアを tasks 配列で複数渡すと、それぞれ独立した子エージェントとして並列に実行される。

delegate_task(tasks=[
    {"goal": "Research topic A", "context": "..."},
    {"goal": "Research topic B", "context": "..."},
    {"goal": "Fix the build", "context": "..."}
])

既定の最大並列数は 3 で、delegation.max_concurrent_children（または環境変数 DELEGATION_MAX_CONCURRENT_CHILDREN）で変更でき、上限は無い。内部では ThreadPoolExecutor が設定した並列数をワーカー数として使う。対話 CLI ではツリービュー表示で各子の進行がリアルタイムに流れ、結果は完了した順ではなく、渡した tasks の並び順にソートされて返ってくる。

execute_code との RPC

execute_code は、エージェントが from hermes_tools import ... という書き出しで Python スクリプトを書き、それを子プロセスとして実行させるツールである。流れは次のとおりだ。

1. エージェントが hermes_tools をインポートする Python スクリプトを書く
2. Hermes が RPC スタブ関数を持つ hermes_tools.py を生成する
3. Hermes が Unix ドメインソケットを開き、RPC リスナースレッドを起動する
4. スクリプトは子プロセスとして実行され、ツール呼び出しはソケット越しに Hermes 側へ飛ぶ
5. print() の出力だけが LLM に返り、途中のツール結果はコンテキストウィンドウに一切入らない

from hermes_tools import web_search, web_extract

results = web_search("Python 3.13 features", limit=5)
for r in results["data"]["web"]:
    content = web_extract([r["url"]])
    # ... フィルタして加工 ...
print(summary)

スクリプト内から呼べるツールは web_search / web_extract / read_file / write_file / search_files / patch / terminal（フォアグラウンドのみ）の 7 種類に限られる。Windows では AF_UNIX が不安定なためループバック TCP ソケットにフォールバックし、Docker・SSH・Modal のようなリモートバックエンドではファイルベースの RPC トランスポートに切り替わる（バックエンド側に Python 3 が必要）。3 回以上のツール呼び出しをループや条件分岐で組み合わせる場面が、このツールの主戦場だと考えるとよい。

ブロックされるツール・ネスト・タイムアウト・ワークツリー隔離

ブロックされるツールと role="orchestrator"

子エージェントは親と同じツールセットを引き継ぐが、無制限ではない。既定の role="leaf"（葉）の子エージェントでは、次のツールがブロックされる。

• delegate_task — さらに孫エージェントを作れない（既定）
• clarify — ユーザーに聞き返せない
• memory — 共有の永続メモリへの書き込みができない
• send_message — 他プラットフォームへの副作用を起こせない
• cronjob — 親の名前で新しいスケジュールを組めない

一方 execute_code はどちらの役割でも保持される。機械的な処理は子エージェントの中でも続けられるようにする、という設計である。

既定の flat delegation（親 → 子までで、子はさらに委任できない）を破りたいときは、role="orchestrator" を指定する。

delegate_task(
    goal="Survey three code review approaches and recommend one",
    role="orchestrator",
    context="..."
)

ただし role="orchestrator" を指定しただけでは孫エージェントは作れない。ネストの深さは delegation.max_spawn_depth（既定 1 = flat）で管理されており、2 に上げて初めて orchestrator の子が孫（leaf）を持てるようになる。3 以上でさらに深いツリーも組めるが上限は無い。delegation.orchestrator_enabled: false にすると、role の指定に関わらず全ての子が強制的に leaf になる。

タイムアウトとワークツリー隔離

子エージェントには既定でハードなウォールクロックタイムアウトが無い。以前のバージョンには 300 秒・600 秒といった固定の打ち切りがあったが、深いコードレビューや大規模な調査のように、着実に進んでいても 10 分以上かかる子を誤って殺してしまう問題があったため撤廃された。完全に止まってしまった子はハートビート監視で検知される。コスト管理のために上限を設けたい場合は、delegation.child_timeout_seconds（既定 0 = 無効）にオプトインで正の値を設定する。

もうひとつの安全策がワークツリー隔離である。既定では、複数の子エージェントは親と同じ作業ディレクトリを共有するため、並列で同じリポジトリを編集すると衝突しうる。delegation.worktree_isolation: true にすると、各子は現在の HEAD から分岐した専用の git worktree（<repo>/.worktrees/subagent-<id>、ブランチ名 hermes-subagent/subagent-<id>）の中で作業するようになり、親のチェックアウトは触られない。子が完了すると結果にはコミット数や変更の有無が付き、親はブランチごとに git log や git merge でレビュー・統合できる。この機能は git 管理下かつローカルターミナルバックエンド限定で、git 管理外のディレクトリや Docker・SSH 等のリモートバックエンドではエラーにはならず、静かに既定の共有ワークスペース動作へ切り替わる。

設定例と /review コマンド

委譲まわりの設定は ~/.hermes/config.yaml の delegation セクションに集約されている。

delegation:
  max_iterations: 50        # 子1体あたりの最大ターン数（既定: 50）
  # max_concurrent_children: 3
  # worktree_isolation: false
  # max_spawn_depth: 1
  # orchestrator_enabled: true
  model: "google/gemini-3-flash-preview"   # 子エージェント用のモデル上書き
  provider: "openrouter"

# 直接エンドポイントを指定する場合
delegation:
  model: "qwen2.5-coder"
  base_url: "http://localhost:1234/v1"
  api_key: "local-key"

delegation.model / delegation.provider を省略すると、子エージェントは親と同じモデル・プロバイダを引き継ぐ。よくある構成は「計画は高性能なフロンティアモデル、実行は安価なモデル」という役割分担だ。タスクを的確な粒度に分解するには高い判断力が要るが、ゴールと文脈が揃った後の実行そのものはそこまで要求が高くない。しかも並列バッチの子エージェントは、1 回のランで消費するトークンの大半を占めることが多い。そのため親のモデルはフロンティアモデルのまま、delegation.model だけ安価なモデルに固定すると、計画の質を落とさずに支出を抑えやすい。

成果物のレビューには /review を使う。これは独立したフル権限のバックグラウンドサブエージェントを起動し、直前の会話が生み出した PR・diff・コード・ドキュメントを実際に開いて調べさせるコマンドで、対話 CLI・TUI・Desktop・全ゲートウェイプラットフォームで動作する。

/review                       # 直前の成果物をレビュー
/review focus on security     # 追加の指示を添える

典型的な流れは、メインのエージェントが PR を作成し、その直後に /review を打つというものだ。レビュー用のサブエージェントは delegate_task と同じバックグラウンド委譲の仕組みに乗るため、抜粋だけを読んで判断するのではなく、実際に diff を開きコードを実行して調べる。レビューが終わると、その結果は通常のバックグラウンドサブエージェント完了と同じ経路でメインのエージェントに戻り、指摘への対応を続けられる。

/review

/review focus on security

つまずきポイント

理解度チェック

まとめ

• delegate_task は隔離コンテキストの子エージェントを起動する。子は親の会話を一切知らないため、goal と context に必要な情報をすべて書き切る必要がある
• tasks 配列によるバッチモードは既定で最大 3 並列。子が増えるほど短時間で終わる一方、API 呼び出しとトークン消費もほぼ並列に増える
• execute_code は推論を伴わない Python スクリプト実行で、Unix ドメインソケット越しの RPC で 7 種類のツールを呼べる。返るのは print() 出力だけ
• role="orchestrator" と max_spawn_depth でネストを許可できるが、深さは並列数の掛け算でコストに直結する。worktree_isolation は git かつローカルバックエンド限定で並列編集の衝突を避けられる
• 次の第 10 章では、これらの子エージェントが実際にコマンドを実行する場である 7 種類のターミナルバックエンドを扱う

参考リンク

• features/delegation.md（公式ドキュメント原文）
• features/code-execution.md（execute_code の詳細）
• configuration.md（設定キー一覧）
• README.md
• Hermes Agent 公式ドキュメント