「Hermes Kanbanとは何か」

Hermes Kanbanは、共有SQLiteバックエンドキューとWebダッシュボードを使用して、複数のHermesエージェントプロファイルを調整するための耐久性のあるタスクボードです。

Hermes Kanbanはセルフホスト型LLMとどのように連携するのか

Hermes Kanbanはタスクを中央ボードに格納し、ディスパッチャーデーモンが準備完了のタスクをアクティブな実行状態に昇進させることで、LLMに対して同時に何人のワーカーがアクセスするかを制御できます。

Hermes Kanbanがゲートウェイに過負荷を与えないようにするにはどうすればよいですか

ディスパッチャの設定で並行ワーカーの数を制限し、プロジェクトごとにタスクをグループ化するとともに、親子依存関係を活用して同時に実行されるタスクの数を最小限に抑えてください。

Hermesタスクをcronでバッチ処理するには

ゲートウェイでの自動ディスパッチを無効化し、代わりに cron ジョブを実行して、スケジュールされた時間に Hermes CLI コマンドを呼び出し、一定数以上のタスクをプロモートすることができます。

タスクの割り当てではなく、カンバンを使用すべきタイミングはいつですか

Hermes Kanbanは、タスクが単一の実行を越える長寿命のワークフロー、研究キュー、およびエンジニアリングバックログに使用します。ダッシュボードと永続的な履歴が必要な場合に適しています。

セルフホスト型LLMワークフローにおけるHermes AgentのKanban

セルフホスト型LLMにおけるHermes Kanbanの負荷を制御します。

Hermes Agentには、すべてのタスクを同時に実行させるとセルフホスト型のLLMゲートウェイを容易に飽和させてしまうような、カンバンスタイルのタスクボードが標準で付属しています。

Hermes Kanbanは ~/.hermes/kanban.db によって裏付けられる耐久性のあるマルチプロフィールボードです。各レーン（列）は作業のフェーズを表し、各カードは特定のHermesプロフィールによって引受（claim）できるタスクです。標準設定では、ディスパッチャーデーモンは ready（準備完了）状態のタスクの数に応じてエージェントを喜んで起動しますが、これはクラウドAPIには適していますが、小規模なセルフホスト型GPUクラスターでは危険です。

このスタックにご不明な点がございましたら、まず広範な Hermesのセットアップと運用ガイドおよび AI Systemsの柱を参照してください。

Hermes Kanban board with controlled workers

本記事では、以下の方法について説明します。

理解する：Hermes KanbanとディスパッチャーがLLMゲートウェイとどのように相互作用するか。
設定する：重いタスクに対する逐次実行または制限付き並行実行の設定。
バッチ処理する：cronを使用して作業をバッチ処理し、夜間ジョブが日中の対話型使用と衝突しないようにする。
監視・調整する：GPUが busy でありながら過負荷にならないようにシステムを監視および調整する。

Hermes Kanban とディスパッチャーの仕組み

高レベルな概要では、システムは以下の3つのレイヤーで構成されています。

ボード — タスク、列、関係、履歴を格納する耐久性のあるSQLiteデータベース。
ワーカー — タスクを処理するために孤立したワークスペースで起動できるHermesプロフィール。
ディスパッチャーデーモン — ボードを監視し、タスクを実行（runs）に昇格させる長寿命プロセス。

CLIまたはダッシュボードを使用してタスクを作成すると、通常は backlog または ready 列から開始されます。ディスパッチャーは定期的にフィルターに一致するタスクをスキャンし、アトミックにカードを引受（claim）し、適切なツールとメモリを持つ割り当てられたプロフィールを生成します。各ワーカーはその後、LLMゲートウェイまたはローカルランタイム（例：Ollama、vLLM、llama.cpp前面に配置されたOpenAI互換プロキシ）と通信します。これらのランタイム間のデプロイメント選択については、 2026年のLLMホスティング：ローカル、セルフホスト、クラウドインフラストラクチャの比較を参照してください。Ollama自体でのリクエストのファナウト（fan-out）を調整している場合、 Ollamaが並行リクエストを処理する方法と併用すると効果的です。

これ以外に何も行わずに50個の重い研究タスクを追加すると、ディスパッチャーはすべて50個を起動しようとし、ゲートウェイに同時リクエストを洪水のように送りつけます。単一のGPUまたはCPUバウンドノードでは、スループットではなく キューイング、スラッシング、タイムアウト が発生します。

戦略1 ディスパッチャーでの並行性を削減

最もシンプルな制御は、ディスパッチャーが並行して実行できるワーカー数を上限設定することです。 Hermesの設定では、通常、Kanbanディスパッチャーとワーカープールを制御するセクションが表示されます。

現在のHermesリリースでは、ディスパッチャーはデフォルトで hermes gateway start に組み込まれており、同じ引受と生成カーネルがここで並行性上限を強制します。しかし、ユーザーは制限のドリフトのように見える奇妙な挙動を報告しているため、制限自体を非難する前にランタイム条件を検証してください。

TOMLスタイルの設定を使用した最小限の例は以下のようになります。

[kanban.dispatcher]
enabled = true
poll_interval_seconds = 10
max_active_tasks = 3

[kanban.workers]
profile = "researcher"
max_parallel_per_profile = 2

お使いのバージョンで異なるキー名を使用している場合は、設定をマッピングする際に同じ意図を維持してください。コマンド名とオペレーターフローは Hermes Agent CLIチートシートで要約されています。

ボード全体のアクティブタスクの総数に対する1つの制限
プロフィールごとまたはワーカープールごとの並行性に対する1つの制限
オプションのディスパッチティック間隔

ドキュメントとコミュニティのスレッドからの既知の落とし穴：

同じ kanban.db でゲートウェイ組み込みディスパッチとレガシーな hermes kanban daemon --force の両方を実行しないでください。これにより、引受の競合（claim races）が発生します。
ゲートウェイがダウンしている場合、 ready タスクは全くディスパッチされず、ゲートウェイが復帰した時点でバーストするように見えます。
長いディスパッチ間隔は、引受が継続的ではなくティック単位で発生するため、不均一なスケジューリングのように感じられます。
古いKanbanビルドでは、追補パッチで修正された複数の実行状態と再引受のエッジケースがあり、バージョンによって挙動が異なる場合があります。

挙動が正しくないように見える場合の迅速な検証チェックリスト：

# 1) 正確に1つのディスパッチャーパスがアクティブであることを確認
pgrep -af "hermes gateway start|hermes kanban daemon"

# 2) ゲートウェイモードのディスパッチフラグを確認
rg "dispatch_in_gateway|dispatch_interval_seconds" ~/.hermes/config.yaml

# 3) キューの状態を確認
hermes kanban list --status ready
hermes kanban list --status active

重要な概念：

max_active_tasks は、同時に active 状態にあるKanbanカードの数を制限します。
max_parallel_per_profile は、多くのプロフィールを実行している場合でも、重いプロフィールが同時に実行される数は少ないことを保証します。
小規模なセルフホスト型クラスターでは、レイテンシを予測可能に保つために、通常は1から4の値を希望します。

HermesをLLMゲートウェイの近くに最初にデプロイする際は、保守的な設定から始めます。

max_active_tasks = 1 から始めます。
GPUおよびCPUの使用状況を確認します。
ハードウェアが明らかに未使用の場合のみ、2または3に増やします。

戦略2 厳密な逐次フローの依存関係をエンコードする

一部のワークフローは厳密に順番に実行されるべきです。例えば：

共有の中間アーティファクトを持つマルチステップデータパイプライン
マイグレーションまたはインフラストラクチャの変更
同じオブジェクトストアまたはデータベースに書き込むバッチジョブ

Hermes Kanbanはタスク間の親子依存関係をサポートしており、親カードが完了するまで子カードはディスパッチ可能になりません。

Hermes CLIの周りに小さなヘルパースクリプトを作成して、これをモデル化できます。

#!/usr/bin/env bash

set -euo pipefail

parent_id="$(hermes kanban add \
  --title 'Ingest customer logs for April' \
  --profile 'etl-worker' \
  --column backlog)"

hermes kanban add \
  --title 'Generate April anomaly report' \
  --profile 'analytics-worker' \
  --column backlog \
  --parent "${parent_id}"

hermes kanban add \
  --title 'Publish April summary to dashboard' \
  --profile 'reporting-worker' \
  --column backlog \
  --parent "${parent_id}"

適切なボードポリシーと低いディスパッチャー制限により、親タスクが最初に実行されます。親タスクが完了すると、子タスクは徐々に準備完了状態になり、ディスパッチャーは並行性上限を超えずに1つずつ引き取ります。

戦略3 自動ディスパッチを無効化し、cronを使用する

一部の環境では、重いワークロードに対して明示的な時間枠を好む場合があります。例えば、GPUがアイドル状態の午前0時以降に研究タスクやドキュメントの取り込みを実行したい場合があります。

このセットアップでcronと呼ぶスケジューリングのバリエーションは2つあります。

crontab を使用するLinuxホストcron。
Hermes設定内のHermes内部スケジューラcron式。

オプションA Linuxホストcron

このモデルでは、自動Kanbanディスパッチを無効化し、OSにラッパーสクリプトのスケジューリングを任せます。

例スクリプト：

#!/usr/bin/env bash

set -euo pipefail

MAX_TO_PROMOTE="${1:-3}"

ready_ids="$(hermes kanban list --column ready --limit "${MAX_TO_PROMOTE}" --quiet)"

if [ -z "${ready_ids}" ]; then
  exit 0
fi

for id in ${ready_ids}; do
  echo "Promoting task ${id} to active"
  hermes kanban promote --id "${id}" --column active
done

次に、ディスパッチャーまたはゲートウェイが実行されているホストにLinux cronエントリを追加します。

*/15 * * * * /opt/hermes/scripts/kanban-promote.sh 2 >> /var/log/hermes/kanban-cron.log 2>&1

これにより、 ready にドロップしたカードの数に関わらず、15分ごとに新しいタスクが2つ以上アクティブにならないことが保証されます。

オプションB Hermes内部cronスケジューラ

スケジューリングルールをHermes自体で保持したい場合は、Hermes設定でcron式を持つスケジュール済みジョブを定義し、そこで同じpromoteコマンドを呼び出します。

例パターン：

[kanban.dispatcher]
enabled = false

[[scheduler.jobs]]
name = "kanban-batch-promote"
cron = "*/15 * * * *"
command = "hermes kanban promote-batch --from ready --to active --max 2"
timezone = "Australia/Melbourne"

Hermesビルドがスケジューラ管理コマンドを公開している場合、設定ファイルをマニュアルで編集する代わりに、CLIから同じジョブを登録できます。

hermes scheduler jobs add \
  --name "kanban-batch-promote" \
  --cron "*/15 * * * *" \
  --timezone "Australia/Melbourne" \
  --command "hermes kanban promote-batch --from ready --to active --max 2"

hermes scheduler jobs list

インストールされているバージョンに hermes scheduler jobs ... がない場合は、上記の設定ベースの方法を引き続き使用し、その後Hermesをリロードまたは再起動して、スケジューラが新しいジョブを取得させます。

これを安全に使用する方法：

スケジューラジョブが唯一のプロモーターである場合は、 kanban.dispatcher.enabled = false に維持します。
1または2などの低い --max 値から始めます。
スケジューラログを通常のHermesログパイプラインに配置し、スキップまたは失敗したプロモーションが可視化されるようにします。

これにより、ホストレベルの crontab の代わりにHermes設定として管理されるLinux cronと同じバッチ処理動作が得られます。

戦略4 ゲートウェイごとにボードとプロフィールをセグメント化

複数のLLMバックエンドを運用している場合、例えば：

7Bインストラクトモデルを備えた小さなGPUノード
軽量分類用のCPUオンリーノード
重い推論用 별도의 高エンドボックス

ゲートウェイごとに異なるHermesプロフィールとボードを割り当てることで、競合を軽減できます。

典型的なパターン：

research-gpu、summarise-cpu、ops-gatewayなどのプロフィールを作成します。
各プロフィールに、専用のゲートウェイ用のベースURLとAPIキーを設定します。
各プロフィール用に別のKanbanレーン、または別のボードを作成します。

ディスパッチャー上限と組み合わせることで、1つのノイズの多いワークロードが他のワークロードを飢餓状態にすることなく、各ゲートウェイが独自のワーカーセットによって飽和される状態を維持します。

Hermes Kanban の監視と調整

どの戦略を選択しても、以下を監視する必要があります。

LLMゲートウェイメトリクス — リクエストレート、レイテンシ、エラーレート、トークンスループット。
ノードヘルス — GPU使用率、VRAM使用量、CPU負荷、RAM。
Hermesメトリクス — backlog、ready、active、doneにあるタスクの数。

プロダクションメトリクスのベースラインとダッシュボードについては、 PrometheusとGrafanaを使用したプロダクションでのLLM推論の監視および広範な LLMパフォーマンスハブを参照してください。

低並行性から始め、以下に注意しながら徐々に制限を引き上げます。

一定のスループットにおけるレイテンシの上昇
タイムアウトまたはレート制限エラーの増加
一部のタスクが非常に長い間アクティブのままになるロングテール

これらの症状が見えたら、すぐに以前の安定した設定に戻り、それをデフォルトとして維持してください。

Kanbanが適切なツールである場合

Hermes Kanbanは、以下の場合に真価を発揮します。

長寿命の研究またはエンジニアリングのバックログ
名前付きプロフィールによるマルチエージェントコラボレーション
リスタートやホストの再起動に耐える必要があるワークフロー
ダッシュボードを使用して作業をトリアージしたい人間

単発の実行でいくつかの一時ヘルパーを作成する必要があるだけなら、組み込みのdelegateタスクツールの方が通常シンプルです。ただし、履歴、ダッシュボード、およびセルフホスト型LLMへのエージェントの影響を厳密に制御する必要がある場合、Kanbanボードとディスパッチャーが適切な基盤となります。

いくつかの設定調整とオプションのcronベースのバッチ処理により、ゲートウェイとハードウェアを保護しながら、Hermes Kanbanをレスポンシブに保つことができます。