Hermes Agentのマルチエージェント実行を整理する ― delegate_task / Kanban / Kanban Swarm / goal の使い分け

Last updated at 2026-10-08Posted at 2026-10-08

はじめに

Nous Research の Hermes Agent には、エージェントへ仕事を任せる仕組みが複数あります。

delegate_task（サブエージェント委譲）
Kanban（マルチエージェントボード）
Kanban Swarm（hermes kanban swarm）
/goal と Kanban の goal card

名前だけを見ると、どれも「エージェントに仕事を任せる機能」に見えます。管理する対象や結果の戻り方、再起動への強さは同じではありません。

この記事では、これらを 「仕事をどこに置き、どのように結果を受け取るか」 という切り口で整理します。

※本記事は個人の整理メモです。
※2026年10月6日時点の公式ドキュメントと、公式GitHubリポジトリのコミット f16cbcd を確認しています。ドキュメントとCLI実装の一部に差があったため、該当箇所は本文で補足します。利用時は手元のバージョンと --help も確認してください。
※本記事の図解は公開情報をもとに筆者が独自に作成したものであり、Nous Research 公式の資料ではありません。

先に全体像

方式	一言でいうと	永続性・再開性	実行主体	向いている場面
`delegate_task`	元の会話へ結果を返す、一時的なサブエージェント委譲	実行中の子は再起動後に再開しない。完了済み・未配送の結果には限定的な耐再起動性がある	匿名のサブエージェント	同じ会話で結果を使う、比較的短い補助タスク
Kanban	SQLite-backedの永続作業キュー＋状態管理	カード、コメント、イベント、実行履歴を永続化し、再ディスパッチできる	名前付きプロファイルのOSプロセス	人の介入、複数ロール、再実行、監査証跡が必要な仕事
Kanban Swarm	Kanbanに定型の依存グラフを作るヘルパー	Kanbanと同じ	名前付きプロファイル	並列作業 → 検証 → 統合の形が決まっている仕事
`/goal`	1体のエージェントをjudge判定まで継続させるループ	セッション単位でgoal stateを保存（`/resume` で復元可）。独立した作業キューではない	1体のエージェント	マルチエージェント分解は不要だが、完了条件まで反復したい仕事

ざっくり分けると、結果を元の会話へ戻す補助作業は delegate_task、仕事そのものをボードへ載せるなら Kanban、その定番構成が Swarm です。/goal は、1体のエージェントを継続させる仕組みとして分けて考えます。

1. `delegate_task` ― 独立した子へ仕事を渡し、結果を会話へ戻す

親の会話履歴は自動では引き継がれない

delegate_task は、独立したコンテキストを持つサブエージェントへタスクを渡すツールです。子は専用のターミナルセッションを持ち、親で有効なツールセットを継承します。呼び出し時に子ごとのツールセットを指定・拡張することはできず、権限を変えたい場合は親側のツール設定を事前に変更します（leafでブロックされるツールは後述）。親へ返るのは最終サマリーで、子の途中経過がそのまま親のコンテキストを埋めるわけではありません。

一方、親の会話履歴も子へ自動継承されません。子には専用のsystem promptが組み立てられ、親のtoolsetも継承されますが、会話上の前提は goal と context へ明示する必要があります。

例外として、親にワークスペースがある場合は、AGENTS.md・CLAUDE.md などのプロジェクトコンテキストファイルが子のsystem promptにも埋め込まれます。リポジトリの規約までは書き直さなくて構いません。

# 悪い例: 子には「さっきのエラー」が分からない
delegate_task(goal="さっきのエラーを直す")

# 良い例: 対象、症状、直近の変更を渡す
delegate_task(
    goal="tests/test_api.py の失敗原因を特定し、修正案をまとめる",
    context=(
        "pytestでtest_create_userが422を返して失敗している。"
        "直近でschema.pyの必須項目を変更した。"
        "変更候補、影響範囲、確認すべきテストを報告する。"
    ),
)

子が単独でも判断できる依頼文を書くことが、結果の品質に効きます。

現行版のトップレベル呼び出しはバックグラウンド実行

delegate_task は、結果が元の会話へ戻る点では関数呼び出しに近い仕組みです。2026年10月時点のDelegationドキュメントでは、トップレベルの呼び出しは原則バックグラウンドで実行され、handleが先に返ります。完了結果は後続メッセージとして配送されます。

一方、orchestrator役のサブエージェントが、自分の子の結果を統合する場合は同期的に待ちます。

また、one-shot CLI や cron のように、後から結果を受け取れないセッションでは、子の終了を待ち、そのツール呼び出しの中で結果が返ります。トップレベルであっても、常に非同期になるわけではありません。

なお、hermes chat -q / --oneshot のセッションでは、生成できるサブエージェントの総数が delegation.oneshot_max_children（既定2）で制限されます。

Kanbanドキュメント内の比較表には「親は子が戻るまでblockする」という説明も残っており、公式ページ間で記述が一致していません。本記事では、Delegation専用ページと現行実装に合わせて整理しています。

バッチの既定同時実行上限は10

複数タスクは tasks=[...] でまとめて渡せます。

delegate_task(tasks=[
    {
        "goal": "公式ドキュメントの仕様を確認する",
        "context": "対象URLと確認項目を列挙し、根拠URL付きで返す",
    },
    {
        "goal": "公式GitHubの実装を確認する",
        "context": "CLI引数と既定値に絞り、ファイルと行を示す",
    },
    {
        "goal": "既存記事との重複を確認する",
        "context": "タイトルだけでなく、読者の疑問と章構成も比較する",
    },
])

2026年10月時点の既定上限は10タスクです。delegation.max_concurrent_children または DELEGATION_MAX_CONCURRENT_CHILDREN で変更できます。上限を超えたbatchは自動で間引かれず、エラーになります。

leafとorchestratorでは再委譲の可否が違う

デフォルトの子は leaf です。leafでは、次のツールがブロックされます。

delegate_task
clarify
memory
send_message
cronjob_manage（cronjobツール）

※公式ドキュメントでは cronjob と表記されていますが、確認したコミットの実装でブロック対象になっているツール名は cronjob_manage です。

※上記は本記事で確認したコミット f16cbcd 時点の実装です。現行の公式ドキュメントでは start_chat もブロック対象に含まれており、その後のmainブランチの実装でも追加されています。

execute_code はleafでも利用できます。

role="orchestrator" を指定した子は、設定上許可されていれば delegate_task を保持します。ここで注意したいのが、delegation.max_spawn_depth の既定値が1であることです。この値は親から子までのflat delegationを意味するため、既定設定のままではorchestrator childから孫を作れません。孫を許可するには2以上へ変更する必要があります。

# ~/.hermes/config.yaml の例
delegation:
  orchestrator_enabled: true
  max_spawn_depth: 2

入れ子を深くすると、子の数、実行時間、コスト、検証範囲が増えます。必要な階層だけを許可する方が管理しやすいです。

実行結果は親側でも確認する

サブエージェントから返るのは自己申告を含む最終サマリーです。「修正した」「テストが通った」と書かれていても、外部への書き込み、ファイル作成、テスト結果などは親側で確認した方が安全です。

また、delegate_task はKanbanのようなdurable jobではありません。実行中にowner processが失われた子は再開されません。完了済みで会話へ未配送の結果は state.db に保持され、再起動後に配送される場合があります。

2. Kanban ― 仕事を永続ボードへ載せる

カードと履歴をSQLiteへ残す

Kanbanは、複数プロファイルが同じ作業を引き継ぐための永続的なタスクボードです。

default board: ~/.hermes/kanban.db
named board: ~/.hermes/kanban/boards/<slug>/kanban.db

named boardでは、DBだけでなくworkspaceとlogもボード単位で分離されます。

カードを実行するワーカーは、名前付きプロファイルから起動される独立したOSプロセスです。ボードを巡回するdispatcherは、依存関係が解けたカードの昇格、カードのclaim、担当プロファイルの起動、停止したワーカーの回収などを担います。

kanban.dispatch_interval_seconds の既定値は60秒で、gateway内でdispatcherを動かす設定も既定で有効です。

状態は一直線ではない

主要な状態は次のとおりです。

triage --(仕様化・分解)----------> todo または ready
todo --(依存先が完了)-----------> ready
ready --(dispatcherがclaim)-----> running
running ------------------------> done
running ------------------------> review --(承認)--> done
running / review ---------------> blocked
blocked --(unblock)-------------> ready / todo / review
done ---------------------------> archived

これは代表経路であり、すべての遷移を表す厳密な状態遷移図ではありません。依存関係によって running から todo へ戻る場合や、レビュー差し戻しで実装側へ戻る場合もあります。現行実装にはworkflow用の scheduled 状態もあります（公式ドキュメントでは主に scheduled_at フィールドとして説明されています）。

unblock後の戻り先は、親カードが未完了なら todo、レビュー起点の作業なら review、それ以外は ready です。

人間はCLI、ワーカーは `kanban_*` ツールを使う

人間やスクリプトは hermes kanban ... CLIやdashboardからボードを操作できます。一方、dispatcherが起動したワーカーは、カードのライフサイクルを kanban_* ツールで更新します。

kanban_show()
# ターミナルやファイルツールで作業
kanban_heartbeat(note="調査対象8件のうち4件を確認")
kanban_complete(
    summary="公式DocsとCLI実装の差分を3件確認",
    metadata={"checked_files": ["delegation.md", "kanban_parser.py"]},
)

この方式なら、シェルのクォートへ依存せず、エラーも構造化データとして扱えます。

「どのプロファイルもどのカードも自由に書き換えられる」と考えるのは広すぎます。実際には、次の境界があります。

通常の対話プロファイルでKanbanツールを使うには、toolsetの有効化が必要
workerのライフサイクル操作は、原則として自分のカードへscopeされる
named boardのworkerは別boardを参照しない
delegate_task で起動した子には、Kanbanのclaim所有権を引き継がせない

Kanbanは階層的な戻り値だけに閉じず、権限を持つプロファイルや人間が、同じboard上のカード、コメント、handoffを参照できる協調方式と捉えるのがよさそうです。

Triageの自動分解

kanban.auto_decompose は既定で true です。dispatcherはTriageカードを補助LLMへ渡し、利用可能なプロファイルとdescriptionを使ってタスクグラフを作ります。2026年10月時点では、1 tickあたりの既定処理数は3件です。

すべてのカードを必ずfan-outするわけではありません。分解が不要と判断された場合は、1枚のカードを仕様化して昇格させる処理へfallbackします。また、補助モデルまたはfallback先のmain modelが利用できる設定も必要です。

手動で管理したい場合はauto decompositionを無効にできます。この設定で止まるのは組み込みdecomposerであり、権限を持つプロファイルによる kanban_create まで禁止するものではありません。

オーケストレーターは分解と接続に集中する

Kanbanでは、オーケストレーターがすべてを自分で処理するより、カードを分解して依存関係を作り、担当へ渡す構成が向いています。

kanban_create(title="北米の事例を調べる", assignee="researcher-a")  # → t_r1
kanban_create(title="欧州の事例を調べる", assignee="researcher-b")  # → t_r2
kanban_create(
    title="調査結果をまとめる",
    assignee="writer",
    parents=["t_r1", "t_r2"],
)
kanban_complete(summary="調査2件と統合1件へ分解")

最後のカードは、親カードが完了してから ready へ進みます。この依存関係が、単発のサブエージェント委譲との大きな違いです。

3. Kanban Swarm ― 定番グラフを一度に作る

Kanban Swarmは、Kanban上に次の依存グラフをまとめて作るヘルパーです。

[root / blackboard]（完了済みの共有コンテキスト）
        │
   ┌────┼────┐
[worker][worker][worker]  ← 並列実行
   └────┼────┘
     [verifier]           ← 全worker完了後
        │
   [synthesizer]          ← 検証後に統合

2026年10月時点のCLI実装では、workerを --worker PROFILE:TITLE[:SKILL,SKILL] の形式で繰り返し指定します。

hermes kanban swarm "マルチリージョンのフェイルオーバー計画を設計する" \
  --worker "researcher:障害シナリオと既存事例を調査する" \
  --worker "architect:候補アーキテクチャを設計する" \
  --worker "sre:運用・切替・復旧手順を検討する" \
  --verifier reviewer \
  --synthesizer writer

公式Kanbanページには --workers researcher,architect,sre という例も残っていますが、確認したコミットのCLI parserは --worker を受け付けます。実行時は hermes kanban swarm --help で手元の構文を確認してください。

共有コンテキストはroot cardのコメントへ構造化JSONとして保存されます。グラフ全体は同じtransactionで作られ、接続途中のカード群がdispatcherに見えないようにコミットされます。

Swarmは別の実行エンジンではありません。作成後は通常のKanbanカードとしてdispatchされます。毎回 kanban_create と parents で「並列作業 → 検証 → 統合」を手組みしなくてよい点が役割です。

番外：`/goal` と Kanbanのgoal card

`/goal` は1体のエージェントを継続させる

/goal は、1体のエージェントがLLM judgeから完了判定を得るまで、同じ目標へ取り組み続けるループです。複数エージェントへの分解機能ではありません。

goalの状態はセッションの SessionDB.state_meta に保存されるため、/resume でセッションを再開すればactive・pausedなどの状態ごと復元されます。ただし、Kanbanのように別プロセスへ引き継いだり、ボード上で共有したりする仕組みではありません。

Kanbanのgoal cardは同じloop engineを使う

Kanbanカードへ --goal を付けると、そのカードのworkerはgoal loopで実行されます。

hermes kanban create "ドキュメントサイトをフランス語へ翻訳する" \
  --body "受け入れ条件: 全ページ翻訳済み、英語が残っていない、リンクが有効" \
  --assignee linguist \
  --goal

通常のカードは原則1 turnで完了またはblockを報告します。goal cardでは、各turnの後にjudgeがtitleとbodyを受け入れ条件として確認します。未完了なら同じworker sessionで続行し、ターン上限（既定20、--goal-max-turns で変更可能）へ達した場合や達成不能と判断された場合はカードをblockします。

チャットの /goal とKanbanのgoal cardは、状態を共有しません。チャットでgoalを設定してもカードは作られず、goal cardの進行状況が /goal status に現れるわけでもありません。

なお、judge API自体が認証エラーやtimeoutで利用できない場合、Kanbanの完了handoffはfail-openで許可されます。goal modeは、LLM judgeによる継続支援と考える方が安全です。

使い分けを順番に決める

Q1. 1体のエージェントに、完了条件まで反復してほしいだけか？
    → Yes: /goal

Q2. 独立した子へ補助作業を渡し、結果を同じ会話へ戻したいか？
    → Yes: delegate_task
       複数ならbatch、入れ子が必要なら設定済みのorchestrator

Q3. 再起動、人のコメント、承認、別ロールへの引き継ぎ、
    後から追える履歴が必要か？
    → Yes: Kanban

Q4. Kanban上で「並列作業 → 検証 → 統合」の型を作りたいか？
    → Yes: Kanban Swarm

これらは排他的ではありません。delegation toolが有効なKanban workerは、カード内の補助作業を delegate_task へ渡せます。

そこから起動した子には、Kanban tool schemaやclaim所有権が引き継がれません。子は結果をworkerへ返し、カードの完了、block、commentは元のworkerが行います。

コストは「高性能な司令塔＋安価なworker」が常に正解とは限らない

公式ドキュメントでは、分解を担当するorchestratorに高性能モデル、反復量の多いworkerに比較的安価なモデルを割り当てる構成が推奨例として紹介されています。Kanbanはプロファイル単位でモデルを変えられるため、この分け方を作りやすいです。

実際の費用はworker数、再試行、goal judge、decomposer、verifier、provider単価などで変わります。常にこの構成が最安とは限りません。まず小さなタスクでtoken使用量と成果物の品質を見てから、役割ごとのモデルを調整する方が現実的です。

まとめ

delegate_task は、独立コンテキストのサブエージェントへ作業を渡し、結果を元の会話へ返す仕組み
現行版のトップレベル呼び出しは原則バックグラウンドで動き、batchの既定同時実行上限は10
role="orchestrator" で孫を作るには、既定値1の max_spawn_depth を2以上へ変更する必要がある
Kanbanは、カードと履歴をSQLiteへ残し、名前付きプロファイルをdispatcherが起動する作業キュー
Kanban Swarmは、parallel workers → verifier → synthesizerの依存グラフをまとめて作るKanbanのヘルパー
/goal は単一エージェントの継続ループで、Kanbanのgoal cardはloop engineだけを共有する
Kanban workerは内部でdelegationを使えるが、delegated childはカードを更新できない

一言でまとめるなら、会話へ結果を戻すなら delegate_task、仕事をボードへ残すなら Kanban、定型グラフを作るなら Swarm と整理すると迷いにくそうです。

参考（公式情報）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up