はじめに
AIエージェントが別のエージェントに仕事を任せること自体は、珍しい仕組みではなくなりました。
それでも、Nous ResearchのHermes Agentには、複数のエージェントで仕事を管理するKanban（Multi-Agent Board）という仕組みが組み込まれています。
最初は「エージェント同士でタスクを委譲すれば十分では？」「GitHub IssuesやProjectsで代用できないの？」と思いました。
そこで、設計RFC（Issue #16102）、初期PR（#16100）、採用されたPR（#17805）を読み、なぜKanban方式が必要になったのかという経緯に絞って整理しました。
確認範囲：2026年10月10日時点のコミット
f925b01を実装・仕様の基準とし、RFCとPRは設計経緯の資料として参照しています。この記事は実装の全機能や操作手順を紹介するものではありません。
先に結論を書くと、Kanbanを採用した理由は、カードを並べて進捗を可視化することだけではありません。エージェントの会話や実行プロセスが終わっても、仕事の状態と引き継ぎを残せるようにするためだと理解しました。
1. delegate_taskだけでは何が足りなかったのか
Hermes Agentには、エージェントが別のエージェントに処理を任せるdelegate_taskがあります。提案当時のPR #16100のMotivation では、これを「fork → join型の同期的な関数呼び出しで、匿名のサブエージェントを使い、再開や人間の介入を想定しない仕組み」と位置づけていました。短い推論を委譲して結果を受け取る用途には適していても、当時ユーザーが求めていた仕事の形とは異なる、という問題意識です。
なお、これは2026年4月の提案時点での説明です。その後のdelegate_taskにはバックグラウンド実行や完了結果の配信機構も加わっています。ただし、提案の背景にあった長期的な仕事とは、管理したい対象が異なります。
PRには、NousのDiscord設計スレッドで要望されたワークロードとして、次の例が挙げられています。
- リサーチのトリアージ：複数の調査担当、分析担当、執筆担当が並列・段階的に作業し、曖昧な点は人間が判断する
- 定期的なワークフロー：日次のAI資金調達ブリーフなどを継続作成し、Obsidianの保管庫に蓄積する
-
デジタルツイン：
inbox-triageやops-reviewなど、名前と永続メモリを持つプロファイルが週単位で活動する - エンジニアリングパイプライン：タスク分割、並列worktreeでの実装、レビュー、修正、PR作成へ進む
- フリート運用：1つの専門プロファイルが、多数のアカウントなどを個別の作業領域で管理する
ここで必要なのは、単に子エージェントを呼び出す機能ではなく、仕事そのものの状態を共有し続ける仕組みです。
図1：単発の委譲と、長期的な仕事の引き継ぎの違い（概念図）
RFCでは両者を区別する問いとして、*「その引き継ぎは、1回のAPIループより長く残り、他者から見える必要があるか」*という基準が示されています（Issue #16102）。
補足すると、これはdelegate_taskに永続化の仕組みがまったくないという意味ではありません。完了結果の再配信と、途中で終了した仕事を共有状態に基づいて再実行・引き継ぐことは区別して考える必要があります。
2. RFCはどこから着想を得たのか
Kanbanの構想は、2026年4月26日に公開されたIssue #16102で確認できます。
この設計は、単に一般的なKanbanボードをAIエージェント向けに作り直したものではありません。RFCでは、既存のエージェント関連システムを参考に、異なる要素を取り入れた経緯が説明されています。
| 参照先 | RFCでの位置づけ |
|---|---|
| Cline Kanban | ボード、タスク間の関係、一時的なworktree |
| Paperclip | 原子的なタスク取得、継続的なエージェントの識別 |
| NanoClaw Agent Swarms | 反面教師：プロセス内サブエージェントはSDKのライフサイクルに左右されるため、採用しない |
| Google Gemini Enterprise Agent Designer / CLI Subagents | 持ち運べるサブエージェント定義や名前による委譲の発想 |
また、初期PRではMulticaを参考に、実行時間の上限、ハートビート、担当候補の列挙、イベント名の整理が加えられています（PR #16100）。
ここから読み取れるのは、見た目のボードを作ることよりも、誰が仕事を受け持ち、失敗や中断をどう検知し、次の担当へどう渡すかを重視していたという点です。
3. 中心となった設計：状態と実行を切り離す
初期設計で重要なのは、タスクの情報をSQLiteに保存し、担当エージェントを独立したOSプロセスとして動かすという考え方です。これはNanoClawのプロセス内サブエージェント構成を反面教師にした判断です。
大まかには、次の3つに役割を分けられます。
- 状態の保存：タスク、担当、依存関係、コメント、実行履歴をSQLiteに残す
- 実行の調整：Dispatcherが実行できるタスクを取得（claim）し、担当を起動する
- 作業の実施：担当プロファイルのワーカーが実際の処理を行い、結果や引き継ぎ情報を記録する
図2：Kanbanの考え方を単純化した概念図。複数ワーカーの並行起動を示すもので、各タスクの依存順序まで表しているわけではありません。
たとえば調査ワーカーの処理が終わっても、タスクの状態や結果はデータベースに残ります。その情報をもとに、別のワーカーや人間が状況を確認できます。
つまり、「タスクの寿命」と「一度のエージェント実行の寿命」を分けるという設計です。
これにより、ひとつの会話やプロセスだけを仕事の記録場所にしなくても済むようになります。ただし、タスクの状態が残ることと、実行途中の処理や一時ファイルがそのまま復元されることは同義ではありません。
4. 設計はそのまま実装されたわけではない
RFCとPRを追うと、実行管理の仕組みだけでなく、仕事の履歴をどう残すかというデータモデルもレビューによって改善されたことが分かります。
レビューで加わった実行履歴と引き継ぎ
2026年4月27日、Issue #16102のレビューで、vulcan-artivusは初期データモデルの限界を指摘しました。1つのタスクに担当者・ステータス・ワークスペースをそれぞれ1つ持たせる方式は、同種の作業を大量に処理するフリート運用には向いています。一方で、同じ成果物をPM → エンジニア → レビューワーのように複数の役割が順番に扱い、修正のために前の担当へ戻る作業では、誰が何を行ったかの履歴や成果物の共有が難しくなります。
これを受けて、開発側のteknium1は、次の要素をv1に取り込みました。
-
task_runsテーブル：タスクを実行するたびに1行を記録し、再試行や担当ごとの作業履歴を追えるようにする -
構造化された引き継ぎ：各実行の
summary（要約）とmetadata（変更ファイル、検証結果など）を残し、後続タスクや再試行の文脈に渡す - 実行単位のイベント記録：どの試行で完了・失敗・中断が起きたかを対応づける
一方、作業段階ごとの遷移を定義するワークフローテンプレートの本格的な仕組みはv2へ先送りされました。つまり、最初から複雑なワークフローエンジンを組み込むのではなく、後から拡張できる形で、まず履歴と引き継ぎに必要なデータをv1へ加えたわけです。
これは、本記事の主題である「仕事を引き継げる状態として残す」という設計判断が、外部レビューを通じて具体化された例だと感じました。
Dispatcherの変遷
図3：Dispatcher方式の変遷（設計・PR履歴を要約）
cronからdaemonへ
初期RFCでは、cronを使ってDispatcherを定期起動する構想でした。しかし、hermes cronは定期実行のたびにLLMプロンプトを実行してトークンを消費するうえ、cronジョブではDispatcherに必要な協調処理を扱えないという問題がありました。このため、長時間動作するdaemon方式へ変更されました（Issue #16102）。
daemonからGateway統合へ
その後、PRの更新過程でDispatcherはGatewayへ組み込まれました。確認基準の公式ドキュメントでも、通常構成はGateway内でDispatcherを動かす方式です。
重要なのは、Kanbanという考え方を維持したまま、運用上の負担を減らす方向に実行基盤が変化したことです。
「自動化しない」初期方針にも変化があった
初期RFCでは、自動アサインや自動ルーティングをv1の中心機能にしない方針が示されていました。一方、基準コミットの実装では、triage状態のタスクを自動的に分解し、プロファイルの説明などを参考に子タスクへ割り当てる仕組みが用意されています。
これは、初期の設計意図と、その後に追加された機能を区別して読む必要がある例です。
5. PRの経緯も少し複雑だった
導入の履歴として押さえておきたいのが、PRの関係です。
- Issue #16102：Kanbanの設計に関するRFC・レビュー依頼
- PR #16100：初期の大きな実装・レビューの場。未マージのままクローズ
- PR #17805：初期PRの内容を取り込み直し、2026年4月30日（UTC）にマージ
したがって、RFCや初期PRの議論は「なぜそう設計したか」を読む資料、マージ後のドキュメントやソースコードは「実際にどのようになったか」を確かめる資料と分けるのが適切です。
6. GitHub Projectsで代用できないのか
最初の疑問に戻ると、GitHub IssuesやProjectsでも、進捗や担当者、コメントを共有することはできます。外部のワーカーやGitHub Actionsと組み合わせれば、似た運用を構築することも可能です。
ただ、両者が最初から担う範囲は少し異なります。
| Hermes Kanban | GitHub Issues / Projects | |
|---|---|---|
| 主な役割 | エージェントの仕事と実行状態を管理 | チームの課題・進捗・レビューを共有 |
| 実行の調整 | Dispatcherによるタスク取得・起動 | Actionsなど別の実行基盤との組み合わせ |
| 状態の標準的な置き場所 | ローカルのSQLite | GitHub上のデータ |
これは、GitHubで同等の仕組みを実現できないという意味ではありません。Hermes側にワーカーの実行管理まで含めた仕組みを持たせるか、GitHubと外部の実行基盤を組み合わせるかの違いです。
設計の経緯を理解するうえでは、Hermes Kanbanが「一般的なプロジェクト管理UI」よりも、「エージェント間の仕事の引き継ぎと実行管理」に重点を置いている点が重要だと思います。
まとめ
Hermes AgentにKanban方式が導入された経緯を追うと、次の4点が見えてきます。
-
delegate_taskのような単発の委譲だけでは、担当交代や人間の介入をまたぐ仕事の共有状態を表現しにくい - そこで、タスクをSQLiteに保存し、実行するワーカーとは独立して管理する設計が採用された
- レビューを通じて、実行ごとの履歴と構造化された引き継ぎがv1に追加された
- 実行基盤はcronからdaemon、Gateway統合へと変化し、後から自動分解などの機能も加わった
Kanbanという名称からはボードの見た目を想像しがちですが、今回の資料からは、「仕事を会話の外に残し、別の担当が引き継げる状態にする」ための設計であることが分かりました。
この観点は、Hermes Agentに限らず、複数のAIエージェントで長い作業を扱う仕組みを考える際にも参考になりそうです。