Hermes Agent マルチエージェント編成完全ガイド｜Kanban × Orchestrator-Worker パターン【2026年版】

Hermes Agent でマルチエージェント編成を組みたいエンジニアが、海外ブログを読み漁って情報を寄せ集めている、という相談が私たちのもとに増えています。v0.12 で Kanban が入り、v0.13 で multi-agent オプションが入った直後から、X 上で Nous Research や @Teknium、@gkisokay、@currypurin など複数のアカウントが事例を出し始めたためです。

株式会社Fyveでは、自社の業務自動化と複数のクライアント案件で Hermes Agent のマルチエージェント構成を実運用しています。本記事ではその経験をベースに、Kanban / Orchestrator-Worker / Hierarchical / Parallel という4つの主要パターンを、いつ使い、いつ使うべきでないかまで含めて整理します。Claude Code の Sub-agents との違いも最後に触れます。

マルチエージェント編成とは何か

マルチエージェント編成とは、Hermes Agent のインスタンスを複数立ち上げて、それぞれに役割を持たせ、並列または階層的にタスクを処理させる設計のことです。1つのエージェントに全工程を任せる「シングルエージェント」と対比される概念です。

私たちが実務で使うようになった理由はシンプルで、1つの長いセッションにすべてを詰め込むとコンテキストが破綻し、判断の質が落ちるからです。プランナー、コーダー、レビュアーをそれぞれ別のエージェントに切り出すと、各エージェントは自分の関心領域にだけ集中でき、結果として全体の精度が上がります。

v0.12 Kanban と v0.13 multi-agent の違い

Kanban は「誰が何をやるか」を事前に決めず、空いているエージェントが空いているカードを取る方式です。一方 v0.13 の multi-agent は、上位の orchestrator が「これは coder、これは reviewer」と振り分けます。後者の方が制御しやすく、前者の方が並列度を上げやすい、という性格の違いがあります。

4つの主要パターン

1. Orchestrator-Worker（planner → coder → reviewer）

もっとも標準的で、私たちが最初に推奨するパターンです。orchestrator が要件を planner エージェントに渡し、planner が出した計画を coder エージェントに渡し、出力を reviewer エージェントが検証する、という直列の流れになります。

# hermes.config.yaml（v0.13 multi-agent 構成例）
agents:
  orchestrator:
    role: dispatcher
    model: hermes-3-large
  planner:
    role: worker
    skills: [requirement-analysis, task-breakdown]
  coder:
    role: worker
    skills: [implementation, refactoring]
  reviewer:
    role: worker
    skills: [code-review, security-audit]
pipeline:
  - orchestrator -> planner
  - planner -> coder
  - coder -> reviewer
  - reviewer -> orchestrator

@gkisokay 氏が公開した planner/coder/QA の3並列パイプラインがこのパターンの代表例で、私たちのクライアント案件でもベースとして採用しています。詳細は@gkisokay の3並列マルチエージェントパイプライン解説を参照してください。

2. Hierarchical（上位エージェントがサブエージェントを呼ぶ）

大きなタスクを上位エージェントが受け取り、サブエージェントを動的に生成・呼び出して結果を集約するパターンです。Orchestrator-Worker が静的なパイプラインなのに対し、Hierarchical は動的にサブエージェントの構成が変わるという特徴があります。

私たちが実装したケースでは、「リポジトリ全体のリファクタリング」というタスクに対し、上位エージェントがディレクトリ単位でサブエージェントを起動し、各サブエージェントが配下のファイル群を担当する、という構成にしました。ディレクトリ数で並列度が決まるため、リポジトリの構造に応じてスケールします。

3. Parallel（同一タスクを複数エージェントで分割）

同種のタスクを単純に N 分割して N 個のエージェントで並列処理するパターンです。@Teknium 氏が v0.13 リリース直後に公開した「12並列でのドッグフーディング」がこの形に近く、12個のエージェントが同時に Hermes Agent 自身の機能テストを回していました。詳細は@Teknium の12並列ドッグフーディング事例に整理しています。

私たちの社内では、SEO記事の構成案を5並列で生成し、最終的に人間が1つを選ぶ「アイデア発散用途」で使っています。タスクが独立していて結果のマージが不要なケースでは、Parallel がもっともコスト効率が良いです。

4. Kanban（タスクキューを共有）

v0.12 で追加された Kanban ボードを使い、タスクをカードとして登録、複数のエージェントが空いているカードを取り合うプル型パターンです。エージェント側の処理時間にばらつきがある場合に、自然な負荷分散が効きます。

# Kanban カード定義例（v0.12 形式）
board: feature-batch-2026-06
columns:
  - todo
  - in-progress
  - review
  - done
cards:
  - id: HM-101
    title: "Refactor auth module"
    skills_required: [typescript, security]
    estimated_minutes: 30
  - id: HM-102
    title: "Update README"
    skills_required: [docs]
    estimated_minutes: 10

エージェントは自分のスキルセットと一致するカードを todo から取り、in-progress を経て done に動かします。複数の異種タスクを長時間流し続けるバッチ処理に向いています。

通信機構の選択肢

マルチエージェント編成では、エージェント間でどう状態を共有するかが性能と安定性を大きく左右します。私たちが採用している3つの手段を整理します。

私たちは小規模ならファイル共有、5並列を超えるなら Redis Streams、業務基幹に組み込むなら Message queue、という基準で使い分けています。

設計上の3つの罠

罠1: コスト爆発

並列度を N に上げると、単純計算で API コストも N 倍になります。さらに orchestrator がコンテキストを各 worker に渡し直す設計だと、コンテキストの重複送信でコストが N×M に膨らみます。私たちは月次のコスト上限をオーケストレータ側に持たせ、上限到達時は自動的に並列度を落とすロジックを必ず入れています。

罠2: 無限ループ

reviewer が coder に「やり直し」を返し、coder が修正して再度 reviewer に渡す、というループが終わらなくなるケースがあります。最大ループ回数とエスカレーション先（人間または上位エージェント）を必ず設計に入れてください。

罠3: 結果の整合性

Parallel パターンで N 並列に同じ問題を解かせると、N 個の異なる解が返ってきます。マージ戦略（多数決、スコアリング、人間レビュー）を決めずに走らせると「動くけど意味のない出力」が量産されます。

いつ使うべきか / いつ使うべきでないか

私たちの感覚値として、シングルエージェントで30分以内に終わるタスクは、マルチエージェント化のオーバーヘッドが上回ることが多いです。マルチエージェントは「並列度で時間を稼ぐ」か「役割分担で精度を稼ぐ」か、どちらかの目的が明確なときだけ採用してください。

Claude Code Sub-agents との違い

Claude Code には Sub-agents という仕組みがあり、メインのセッションから子エージェントを呼び出して特定タスクを任せられます。Hermes Agent のマルチエージェント構成と似ていますが、設計思想が異なります。

「人間が監督しながら作業を進める」なら Claude Code Sub-agents、「監督なしで長時間動く本番ワークロード」なら Hermes Agent の multi-agent、というのが私たちの選び分けです。本番運用の前提となる Docker 構成はHermes Agent 本番運用 Docker ガイドにまとめています。

まとめ

Hermes Agent のマルチエージェント編成は、v0.12 の Kanban、v0.13 の multi-agent オプションが出てから一気に実用段階に入りました。Orchestrator-Worker、Hierarchical、Parallel、Kanban の4パターンと、ファイル / Message queue / Redis Streams の通信機構を組み合わせれば、ほとんどの本番ユースケースをカバーできます。

株式会社Fyveでは、コスト上限・無限ループ防止・マージ戦略の3点を必ず設計に入れることを標準にしています。マルチエージェントは強力ですが、設計を雑にやると一晩でコストが10倍に膨らむ世界です。最初は3並列の Orchestrator-Worker から始め、計測しながら拡張していく進め方を推奨します。