一人のAIではなく、役割分担するAIへ
現実の仕事は、一つの大きなタスクを複数の小タスクに分けて進めた方が速く、質も安定します。Hermes Agent は delegate_task によってこの考え方を実装しています。
親エージェントが子エージェントへ仕事を振り、それぞれが独立した文脈とツールで作業したあと、要約だけを持ち帰る構造です。
Subagent の価値はコンテキスト汚染を防ぐこと
子エージェントは完全に独立した会話で動くため、親の履歴に引きずられません。これにより、複雑なコードベースや長い会話の中でも、特定の目的へ集中しやすくなります。
大規模タスクを親一人で抱え込まずに済むのが大きな利点です。
execute_code との使い分け
判断や探索が必要な仕事には delegation、機械的なデータ処理や複数ツールの単純パイプラインには execute_code が向いています。
この使い分けにより、Hermes は“考えるAI”と“処理するAI”を同居させています。
研究・開発・運用での意味
調査、修正、要約、検証を分担できることは、Hermes Agent が小規模なチームのように働けることを意味します。
個人秘書を超え、複数の専門補助役に分割できる点が、今後の agentic 運用で重要になります。
delegate_task と execute_code の役割の違い
Hermes Agent で並列的に仕事をこなす中核手段は、delegate_task と execute_code の二つです。名前は似ていますが、得意とする仕事の性質がはっきりと違います。delegate_task は「判断が必要な仕事」に使います。たとえば、あるファイル群を読み込んで要約する、バグの原因を推測する、仕様書から実装方針を抽出する、といった文脈理解と推論を伴う作業です。親エージェントはタスク説明と必要な制約だけを渡し、子エージェントがそれを受け取って独立した頭で考え、最後に結論だけ戻してきます。
一方、execute_code は「手続きが明確な仕事」に使います。ログファイルから特定のパターンを抽出する、CSVを集計する、APIレスポンスを整形する、バッチで複数URLを叩く、といった機械的な処理です。ここでは推論よりも、決められた処理を確実に流すことが求められます。判断を挟むと遅くなるし、場合によってはブレてしまいます。だからこそ execute_code は決め打ちの処理系として切り出されているのです。
この役割分担を理解しておくと、日々の運用で「どちらのツールを呼ぶべきか」に迷わなくなります。目安としては、作業の途中で自然言語で説明したくなる場面が出てくるなら delegate_task、コードで書き切れるなら execute_code と覚えておけば大きく外しません。
運用事例: リサーチ業界での並列調査
あるマーケットリサーチ会社では、業界動向レポートを毎週複数本まとめる業務がありました。これまでは一人の担当者が複数のニュースサイトや統計データを順番に当たっていて、一本仕上げるのに半日以上かかっていたそうです。Hermes Agent を導入してからは、親エージェントが「この業界の直近一週間の主要トピックを三本抽出して要約する」という大タスクを受けると、delegate_task で三つの子エージェントに分岐し、それぞれが別々のソースを並行して読み込むようになりました。
結果として、一本あたりの作業時間が三分の一以下になり、担当者は最終的なトーンチェックと編集に集中できるようになったそうです。ここで重要なのは、子エージェントが親の履歴に引きずられないため、トピックごとの視点が混ざらず、それぞれ独立した結論になったことでした。
お金の作り方を学ぶオンライン講座【Finorie｜フィノリー】
運用事例: 開発現場でのコードレビュー分散
ソフトウェア開発の現場でも並列処理の恩恵は大きいです。ある SaaS 企業のチームでは、プルリクエスト一件につき「セキュリティ観点」「パフォーマンス観点」「読みやすさ観点」「テスト網羅観点」の四つのレビューを別々の Subagent に割り当てる運用にしました。それぞれの子エージェントには SOUL.md 相当のレビュー方針と、対象ファイルの範囲だけが渡されます。
これによって、一人のレビュアーがすべての観点を同時に抱えなくて済むようになり、見落としが減りました。さらに、四つの独立した視点からのコメントが並列に返ってくるので、PR の議論が早く収束するようになったと聞きました。人間のレビュアーは「AI が上げてきた論点をどう採用するか」だけを決めればよくなったわけです。
運用事例: 運用オペレーションでのログ解析
インフラ運用では、障害時に複数のログソースを一気に当たる必要があります。ある運用チームでは、アラート発報をトリガーに Hermes Agent が起動し、delegate_task で「アプリケーションログ解析」「データベースログ解析」「ネットワーク機器ログ解析」を三並列で走らせる仕組みを組みました。親エージェントはそれぞれの子から要約と疑わしい事象の候補を受け取り、最後に総合判断を一枚のレポートにまとめます。
以前は人間が順番にコンソールへ入ってログを見ていたため、発見までに十数分かかっていたのが、数分以内に「怪しい箇所の候補」が出るようになりました。もちろん最終判断は人間が行いますが、取っ掛かりが自動化されている効果は大きいです。
設定例: delegate_task の基本コマンド
実際にどのような指示で Subagent を呼び出すのか、代表的な例を挙げておきます。Hermes Agent の CLI からは、タスクの内容と担当する Subagent を指定して投げるだけで動き出します。
# 単一タスクを子エージェントに委譲
hermes delegate --task "docs/ 配下の全 README を読み、共通の注意書きを抽出" \
--subagent explorer \
--timeout 600
# 複数タスクを並列に投げる
hermes delegate-batch --file tasks.yml --max-parallel 3tasks.yml の内容は次のようにシンプルな構造で書けます。各タスクに対して担当エージェントと成果物フォーマットを指定できるため、何が返ってくるかが事前にわかる状態を作れます。
tasks:
- id: security-review
subagent: reviewer
prompt: "src/auth 配下をセキュリティ観点でレビューし、リスク一覧を返す"
output: markdown
- id: perf-review
subagent: reviewer
prompt: "src/api のエンドポイントで N+1 が疑われる箇所を列挙する"
output: markdown
- id: test-coverage
subagent: tester
prompt: "tests/ の網羅率が低いモジュールを三つ挙げる"
output: json設定例: execute_code での機械処理
対して、execute_code は推論を挟まない軽量な処理に向いています。以下はログから特定のエラーコードを集計する例です。推論が不要なので子エージェントを立ち上げるよりずっと軽く、速く結果が返ります。
# 集計スクリプトを生成し、即実行して結果を返す
hermes exec --language python --input logs/app.log <<'PY'
import re, collections, sys
pattern = re.compile(r"ERROR\s+\[(\w+)\]")
counter = collections.Counter()
for line in sys.stdin:
m = pattern.search(line)
if m:
counter[m.group(1)] += 1
for code, n in counter.most_common(10):
print(f"{code}\t{n}")
PYこのような処理を delegate_task でやらせると、毎回「どう集計するのがよいか」を判断してから書き始めるため、かえって遅くなりがちです。処理の形が決まっているときは、素直に execute_code を使うのがよい選択です。
delegate_task と execute_code の比較表
両者の違いを一目で見比べられるように、運用観点での比較をまとめます。導入前にこの表を見ながら、どちらをどの用途に割り当てるかを決めておくと迷いません。
| 観点 | delegate_task | execute_code |
|-------------------|----------------------------|----------------------------|
| 得意な仕事 | 判断・探索・要約 | 機械処理・集計・変換 |
| 実行単位 | 独立した Subagent | 短命のコード実行 |
| 文脈の持ち込み | 親の履歴に汚染されない | 入力データのみ |
| レスポンス速度 | 中〜遅(推論あり) | 速い(推論なし) |
| コスト | 相対的に高い | 低い |
| 向かない用途 | 単純な四則演算や集計 | 曖昧な自然言語の解釈 |
| 代表的な利用場面 | 調査、レビュー、要約 | ログ集計、CSV変換、API整形 |「推論の要・不要」を最初に見極めるのがコツです。そこを間違えなければ、並列処理の恩恵を最大限に引き出せます。
導入ステップのチェックリスト
並列エージェントを現場に入れるとき、最初からフル活用を狙うとたいてい失敗します。順を追って慣れていくと安定します。下のチェックリストは、僕が関わった複数の導入案件から共通する流れを抜き出したものです。
[ ] 1. 現在の業務を「判断」と「作業」に分類する
[ ] 2. 分類結果に基づいて Subagent の役割候補を 3 つまで書き出す
[ ] 3. 最初は single delegate で試す(並列は一旦封印)
[ ] 4. 出力品質が安定したら delegate-batch を 2 並列で試す
[ ] 5. 並列数を 3〜5 に増やし、タイムアウトと最大トークンを調整
[ ] 6. execute_code で置き換えられる delegate を見つけ、移行する
[ ] 7. 親エージェントのプロンプトに「統合方針」を書き込む
[ ] 8. ログを取り、どの Subagent がどれだけ呼ばれたか可視化する
[ ] 9. 月次で役割定義を棚卸しする特に 7 番目の「統合方針」は見落とされがちで、そこが曖昧だと、子エージェントが良い答えを返してきても、親がうまく束ねられずに最終成果がぼやけてしまいます。
僕の体験談: 最初は並列化で失敗しました
正直に書いておくと、僕も最初は「並列にすれば速くなる」という単純な期待で使い始めて、派手に失敗しました。当時は調査タスクを八並列で投げて、それぞれに「このディレクトリを全部読んで要約して」と雑に指示していたのです。結果は散々で、戻ってきた八つの要約は観点がバラバラで、統合するのに人間側の方が時間を食うという本末転倒な状況になりました。
そこで気づいたのは、並列処理で速くなるのは「独立して判断できるタスク」だけだということ。依存関係がある仕事を無理に並列化すると、統合コストが跳ね上がって逆効果になる、と。
その失敗から、僕は子エージェントに渡す指示を三つのパートに固定しました。第一に「対象範囲」、第二に「抽出したい観点」、第三に「出力フォーマット」です。これを徹底してからは、並列で戻ってくる答えの粒度がそろうようになり、統合作業が一気に楽になりました。今では、いきなり並列に投げるのではなく、まず一件だけ走らせて指示の明確さを検証してから、本番で並列化するようにしています。
もう一つ気づいたのは、並列数は多ければ良いというものではない、ということです。API のレート制限や、親エージェントのトークン上限との兼ね合いを考えると、現実的には三〜五並列が多くのケースで最適でした。十並列、二十並列を試したこともありますが、一つでもタイムアウトすると全体が遅くなるため、安定性を取って抑えめに運用するのが結果的に速いのです。
ベストプラクティスと注意点
運用で身につけた注意点を、共有できる形にまとめておきます。どれも「やってから気づく」種類のものなので、導入前に目を通しておくと遠回りを避けられるはずです。
第一に、Subagent には「結論だけ戻す」ことを徹底させます。途中経過をすべて親に戻してしまうと、せっかく独立した文脈で作業させた意味が薄れ、親のコンテキストが膨れ上がって判断力が落ちます。出力フォーマットを事前に決めて、余計な情報が入らないようにすることが大切です。
第二に、execute_code に渡す入力データのサイズを意識します。巨大な JSON を丸ごと渡すと、実行時間もコストも膨らみます。まずサンプリングしてから必要な範囲だけ渡す、という一段階を挟む癖をつけると安定します。
第三に、親エージェントのプロンプトに「統合時のルール」を必ず入れておくことです。子エージェントが返してきた結果をどういう優先順位で並べるか、矛盾があったときにどちらを採用するか、そういう方針がないと最終出力がぼやけます。人間のチームでも、リーダーが判断基準を持っていないと議論がまとまらないのと同じです。
第四に、失敗時のフォールバックを決めておくことです。Subagent のうち一つがタイムアウトしたときに、全体を止めるのか、その子だけスキップして続行するのか、親にどう報告するのか。ここを決めておかないと、本番で障害が起きたときに不安定な挙動になります。
よくある質問
Q. delegate_task で子エージェントが無限ループに陥ることはありますか?
A. タイムアウトと最大ステップ数を設定していない場合は起こり得ます。Hermes Agent では子エージェントごとに個別の上限を設定できるので、必ず timeout と max_steps を明示してください。経験上、調査タスクなら 10 分、レビュータスクなら 5 分、集計タスクなら 2 分くらいが現実的な上限です。
Q. 子エージェントが親に返してくる内容が毎回揺れるのですが、どう安定させれば?
A. 出力フォーマットを強制するのが一番効きます。Markdown の見出しレベルや、JSON のスキーマを事前に提示して、そこから逸脱した場合は再生成させるように指示を入れておくと揺らぎが激減します。フォーマットの曖昧さが揺らぎの最大要因です。
Q. 並列数を増やしたら全体が逆に遅くなりました。なぜ?
A. 典型的には三つの原因があります。第一に API レート制限、第二にネットワーク帯域、第三にタイムアウトの伝搬です。特に三番目は見落とされがちで、一つの子がタイムアウトすると親が待ち続けてしまい、結果として全体が最悪ケースに引っ張られます。最大並列数を控えめにし、タイムアウト値を現実的に設定し直すことで改善することが多いです。
Q. delegate_task と execute_code はどう切り替えれば?
A. 「この処理はコードで書き切れるか?」と自分に問うてみてください。書き切れるなら execute_code、自然言語で説明したくなる判断が混ざるなら delegate_task、という判別が実務上もっとも分かりやすいです。
Q. 子エージェント同士で通信させたいのですが可能ですか?
A. 現時点の Hermes Agent では、子同士の直接通信は推奨されていません。必要な情報の受け渡しは親エージェントを経由するのが基本です。これは設計上の選択で、子同士を直接つなぐと依存関係が複雑化し、障害時の切り分けが難しくなるためです。どうしても必要な場合は、親エージェントに中継ロジックを書き込むのが良い方法です。