Hermes Agent のマルチエージェント看板ボードと SOUL.md を試してみる

〜 CLI操作・SOUL.md・AIプロンプト・実践ユースケースのまとめ〜

Hermes Agent のマルチエージェント看板ボード

Hermes Agent（Nous Research）に追加された看板ボード（Kanban System）と SOUL.md を使ったマルチエージェント連携を試してみました。

従来の LLM エージェントって、チャットセッションを閉じたり CLI を終了するとタスクの状態を忘れてしまいがちですよね。Hermes Agent の看板機能は SQLite データベース (~/.hermes/kanban.db) でタスクを永続管理できるため、セッションを跨いで非同期にタスクを引き継げるのがかなり便利です。

今回は、CLI コマンド操作から SOUL.md の役割分担、実際のプロンプト例やユースケースまでを個人メモ兼ねてまとめておきます。

1. Hermes Agent の看板ボード（Kanban）とは？

看板ボードは、タスクを triage, todo, ready, running などの状態で管理する仕組みです。

試してみて良かったポイント

セッション超えのタスク保持: CLI を閉じたりPCを再起動しても、SQLite にタスク状態や実行履歴がしっかり残るのが嬉しいところです。
自動タスクディスパッチ: バックグラウンドで動く hermes gateway 内の Task Dispatcher がタスク状態を常時監視し、実行可能になったタスクを各エージェントへ自動割り振りしてくれます。
エージェント間のハンドオフ（引き継ぎ）: タスク同士の親子関係（依存関係）を設定しておくことで、「設計エージェント」→「実装エージェント」→「レビューエージェント」といった流れを人間が介入せずに自動でバトンタッチできます。

2. Hermes 運用でよく使う専門用語メモ

AIに「看板ボードを使ってタスクを管理して」と指示を出したり、設定ファイルを書く際によく使う用語の一覧です。

専門用語	英語表記	メモ・解説
看板ボード	Kanban Board	タスクを状態（triage, todo, ready 等）で管理する SQLite データベース。
タスクディスパッチャー	Task Dispatcher	`ready` になったタスクを検知し、アサイニーへ自動で処理を開始させる監視機構。
アサイニー（担当）	Assignee / Profile	タスクを実行するエージェント名（例: `planner`, `coder`, `reviewer`）。
ハンドオフ（引き継ぎ）	Handoff	完了したタスクの成果物を次のタスクへ渡し、別エージェントへバトンタッチすること。
タスクグラフ / 依存関係	Task Graph / Dependency	タスク同士の先行・後続関係。「親タスク」が完了するまで「子タスク」は待機します。
ヒューマンインザループ	Human-in-the-Loop (HITL)	高リスク操作や人間の承認が必要な場合に、タスクを `blocked` にして一時停止する仕組み。
SOUL（ペルソナ）	SOUL (`SOUL.md`)	エージェントの人格、役割、思考様式を定義するファイル。
AGENTS (`AGENTS.md`)	AGENTS Rule	特定プロジェクト固有の開発ルールやビルドコマンドを定義するルールファイル。
システムプロンプト Slot #1	System Prompt Slot #1	Hermes で最も優先度が高いペルソナ注入位置。`SOUL.md` はここに展開されます。
冪等性（べきとうせい）	Idempotency	何度実行しても同じ結果が得られる状態。

3. SOUL.md でエージェントの役割を分ける

3.1 `SOUL.md` の役割と位置づけ

SOUL.md はエージェントの**アイデンティティ（役割・行動原則）**を決めるファイルです。通常 ~/.hermes/SOUL.md（またはプロファイルごとのディレクトリルート）に配置され、システムプロンプトの最優先枠（Slot #1）に挿入されます。

SOUL.md: 「誰として振る舞うか」（役割、思考スタイル、回答の方針）
AGENTS.md: 「このプロジェクトで何に従うか」（リポジトリ固有の規約や手順）

3.2 役割別 SOUL.md の設計パターン例

マルチエージェントで動かす場合、担当プロファイルごとに SOUL.md を作成して役割を明確にしておくとスムーズです。

① Planner（設計エージェント）用 `SOUL.md`

1
2
3
4
5
6
7
8


# SOUL: System Planner

あなたは全体の設計とタスク分解を担当するアーキテクトエージェントです。

## 行動原則
- 大規模なゴールは細かなサブタスク（子タスク）に分解し、看板ボード（Kanban）に登録してください。
- 各サブタスクには適切な依存関係（link）とアサイニー（coder, reviewerなど）を設定してください。
- 自身で実装コードを書くのではなく、正確な要件定義とタスク定義に集中してください。

② Coder（実装エージェント）用 `SOUL.md`

1
2
3
4
5
6
7
8


# SOUL: Software Engineer

あなたは高品質なコードを記述する実装スペシャリストエージェントです。

## 行動原則
- 自分にアサインされた `ready` 状態の看板タスクのみを実行します。
- コード変更を行った後は、必ずビルド・テストを実行して検証してください。
- 完了したら成果物の要約（summary）と共にタスクを `complete` に変更し、レビューエージェントへバトンタッチしてください。

③ Reviewer（コードレビューエージェント）用 `SOUL.md`

1
2
3
4
5
6
7


# SOUL: Code Reviewer & Quality Gatekeeper

あなたはセキュリティ、設計、パフォーマンスの観点からコードを評価する品質管理エージェントです。

## 行動原則
- 厳格かつ建設的にコード差分を審査します。
- 判定が「合格」の場合はタスクを完了とし、修正が必要な場合は理由を明確にしたコメントを残してタスクを `blocked` に変更してください。

4. タスクの状態遷移（ステートマシン）

看板ボード内のタスクは、以下の 7 つの状態を遷移します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


stateDiagram-v2
    [*] --> triage: 作成(未決定)
    [*] --> todo: 作成(アサイン済)
    triage --> todo: 分類完了
    todo --> ready: 依存関係解決
    ready --> running: ディスパッチ開始
    running --> blocked: 人間承認待ち/ブロック
    blocked --> ready: ブロック解除
    running --> done: タスク完了
    done --> archived: アーカイブ

それぞれの状態の意味は以下の通りです。

triage: 作成直後で分類・アサイン待ちの状態。
todo: アサイニーが決まり、実行を待っている状態。
ready: 依存する親タスクが完了し、いつでも実行できる状態。
running: ディスパッチャーによってエージェントが現在処理中の状態。
blocked: エラーや人間の承認待ち（HITL）でストップしている状態。
done: 成果物が確認され、完了報告がなされた状態。
archived: 完了して保管された状態。

5. よく使う CLI コマンドと内蔵ツール

5.1 CLI コマンド（手動操作用）

ターミナルから手動で看板を操作する時によく使うコマンドです。

コマンド	説明・実行例
`hermes kanban init`	看板DB (`~/.hermes/kanban.db`) を初期化。
`hermes kanban create "<goal>"`	新しいタスクを作成（`--assignee coder` で担当指定）。
`hermes kanban list`	タスク一覧を表示（`--status ready` 等で絞り込み）。
`hermes kanban show <ID>`	タスクの詳しい説明や変更履歴、コメントを確認。
`hermes kanban link <parent> <child>`	依存関係を設定（parentが終わるまでchildは実行待機）。
`hermes kanban complete <ID>`	タスクを完了にする（`--summary` で結果を残す）。
`hermes kanban block <ID>`	タスクを一時停止状態にする。
`hermes kanban unblock <ID>`	ブロックを解除して `ready` に戻す。
`hermes kanban comment <ID> "<msg>"`	進捗やメモコメントを追加。
`hermes kanban dispatch`	手動でディスパッチャーを動かして ready タスクを開始。

5.2 エージェント用内蔵ツール（`kanban_*`）

AIエージェント自身が会話中や自律動作中に呼び出すツール群です。

kanban_create: 新しいサブタスクを動的に追加
kanban_show: タスクの要件と親タスクの成果物を確認
kanban_complete: 成果物を要約して完了報告し、次のタスクを ready に進める
kanban_block: エラーや人間確認が必要な場合にタスクをストップ
kanban_comment: 試行錯誤のメモや調査結果を記録

6. 実際に動かしてみたユースケース

パイプライン1：設計 → 実装 → レビューの自動リレー

「ユーザーログインの JWT 対応」という大まかな要求を投入。
Planner がタスクを 2 つ作成：
- タスク #101: JWT 認証の実装（assignee: coder）
- タスク #102: JWT のコードレビュー（assignee: reviewer）
- hermes kanban link 101 102 で依存関係を設定。
Coder が #101 を実行してコードを書き、テストを通したら kanban_complete を呼び出す。
#101 が完了すると、自動的に #102 が ready に遷移。
Reviewer が #102 を受け取って差分をチェックし、問題なければ全タスク完了！

パイプライン2：本番操作前の人間承認（Human-in-the-Loop）

本番 DB のマイグレーションなど、失敗が許されないタスクでは kanban_block が活躍します。

エージェントがマイグレーション準備を実行。
破壊的変更を検知したら、自律的に kanban_block(reason="本番DB変更のため承認待ち") を呼んでストップ。
ユーザーが CLI で内容を確認し、問題なければ hermes kanban unblock で再開させる。

7. 看板操作を指示するプロンプト例

AIエージェントに看板ボードを使わせる際、こんな感じで指示を書いておくとスムーズに動いてくれます。

タスク分解と登録を指示するプロンプト

1
2
3
4
5
6
7
8
9


【指示】
以下の要件を分析し、看板ボード（Kanban）を使ってタスクを分解・登録してください。

要件: "WebAPIにレートリミット（1分間に100リクエスト）機能を実装する"

手順:
1. 設計タスク、実装タスク、テスト作成タスクに分解してください。
2. アサイニー（assignee）として `architect`, `coder`, `tester` を割り当ててください。
3. 先行タスクが完了するまで後続が動かないよう、link 機能で依存関係を正しく繋いでください。

8. まとめと個人的な運用メモ

hermes gateway はバックグラウンド常時起動がおすすめ 自動ディスパッチの恩恵を受けるために、launchd や systemd で常駐させておくとラクです。
SOUL.md（性格・役割）と AGENTS.md（プロジェクト固有ルール）を分けるとスッキリする 共通のペルソナと個別のリポジトリ規約を分けて管理できるので保守がしやすい印象です。
タスクの循環依存に注意 お互いが待機状態になるデッドロックを作らないよう、Planner のプロンプトで注意書きを入れておくと安心です。

エージェントに勝手にタスクを進めさせたり、途中経過を DB で追えるのはかなり快適なので、今後のマルチエージェント開発で積極的に活用していこうと思います！