AIエージェントをTDD規律で統率する「SwarmForge」の仕組み

複数のAIコーディングエージェントを同時に走らせてみたものの、成果が噛み合わずレビューと手戻りばかりが増えた、という状況は珍しくありません。片方が書いたコードを片方が書き換える、テストの粒度が役割ごとにばらばらになる、どのブランチの成果を取り込むのか人間が毎回判断する、といった具合です。

やりにくさの正体は「並列に走らせる手段」が足りないことではありません。git worktree と tmux を組み合わせれば作業領域の隔離自体はできます。足りないのは、複数エージェントのオーケストレーション、つまり誰がどの順番で引き継ぐのか・どの品質基準を満たしたら完了なのかという順序と規律の管理を、人間以外に委ねられる仕組みです。隔離できても規律が決まらなければ、エージェントの数を増やすほど人間のレビュー負荷が増えていきます。

SwarmForge（GitHub 上のリポジトリは unclebob/swarm-forge）は、この後者に踏み込む協調ツールです。役割の順序・受信モード・成果の伝播方向を設定ファイルの行として宣言し、TDD やミューテーションテストといった品質規律を「憲章（constitution）」と呼ばれるテキスト群としてエージェントに読み込ませます。規律がリポジトリ内のファイルとして固定されるため、人がその都度指示し直す必要が減る構造になっています。

本記事では、公式 README・ハンドオフプロトコル文書・six-pack ブランチ README・共有エンジニアリング憲章といった一次情報と、gh api で取得したリポジトリメタデータをもとに、SwarmForge の構成要素と導入判断のポイントを整理します。あわせて、main ブランチをクローンしても製品としては動かないという、初見でつまずきやすい構造も先に押さえておきます。

なお本記事はインストール・実行・環境構築を伴わないドキュメントベースの整理であり、動作検証に基づく推奨ではありません。記載した数値は 2026 年 10 月 4 日時点で GitHub API から取得した値です。

複数のAIエージェントを並列実行しても噛み合わない理由

AIエージェントの並列実行ツールが解決する範囲と、解決しない範囲は明確に分かれます。整理すると、前者は「並列実行の基盤」（同時に走らせるための隔離）、後者は「オーケストレーション」（順序と規律の管理）という2つの層に分けられます。

解決する範囲は「作業領域の隔離」です。git worktree で作業ディレクトリを分け、tmux のセッションやペインでプロセスを分ければ、エージェント同士が同じファイルを同時に書き換える事故は避けられます。ターミナル UI を備えたツールであれば、どのエージェントが何をしているかの可視化もここに含まれます。

一方で、隔離しただけでは次の3つが未解決のまま残ります。

1. 引き継ぎの順序: 仕様策定の成果を誰が受け取り、その実装結果を誰がレビューするのか。順序が決まっていなければ、エージェントの成果は並列に積み上がるだけで合流しません。
2. 品質基準: どのテストを書くか、カバレッジやミューテーションスコアをどう測るか。役割ごとに基準が違えば、下流の役割が上流の成果を信頼できません。
3. 完了条件: 何を満たせば「このタスクは終わった」と言えるのか。曖昧なままだと、最終的な合否判断がすべて人間に戻ってきます。

この3つを人間が毎回埋めている限り、エージェントを増やしても運用コストは下がりません。並列実行の基盤そのものを比較したい場合は、ターミナル上での並列管理を主眼に置いた複数のAIエージェントをターミナルで並列管理するOSS「herdr」の仕組みや、Claude向けマルチエージェント基盤にRufloが選ばれる理由と類似OSSとの違いも判断材料になります。

SwarmForge が扱うのは、隔離の上に載る「順序と規律」の層、すなわち複数エージェントのオーケストレーションです。具体的には、swarmforge/swarmforge.conf という設定ファイルで役割とパイプラインを宣言し、永続ハンドオフという仕組みで成果をコミット単位で引き継ぎ、憲章テキストで品質基準を固定します。この3つが本記事で順に見ていく中身であり、同時に導入判断の分かれ目にもなります。

SwarmForgeとは｜tmuxとgit worktreeで役割を隔離するAIエージェント協調ツール

まず、AIエージェントのオーケストレーションツールとしての SwarmForge の位置づけを、公式ドキュメントが示す設計の要点とリポジトリの基本情報から押さえます。

公式に示されている設計の要点

main ブランチの README は、SwarmForge の動作を次のように説明しています。隔離された git worktree と tmux セッションで AI エージェントを協調させ、エージェント同士は「コミット済みの成果」を永続ハンドオフ（durable handoff）を通じて交換します。オペレーターはローカルのダッシュボードを使い、作業の開始・エージェントの確認・承認ゲートの処理・確認事項への回答・swarm の停止を行います。

ここで重要なのは、エージェント間でやり取りされるのがチャットのメッセージではなくコミット済みの成果だという点です。成果が git の履歴として残るため、どの時点の何を引き継いだのかが後から追跡できます。

リポジトリの基本情報は次のとおりです（GitHub API から 2026 年 10 月 4 日に取得）。

主要言語が Clojure と判定されていますが、README の前提ツールとランタイム構成を読むと、実体は Babashka（bb）スクリプトと zsh スクリプトの組み合わせです。重量級のフレームワークではなく、シェルと tmux と git という既存のツールを土台にした構成になっています。

アーカイブ済みリポジトリやフォーク版ではなく、本家のアクティブなリポジトリである点は、評価対象として扱う前提条件として確認しておきたいところです。最終 push は 2026 年 9 月 7 日で、記事公開時点から見て直近の更新があります。

前提ツールと対応バックエンド

README の「Prerequisites」に挙げられている前提は次の5点です。

• zsh
• git
• tmux
• Babashka（bb）— Babashka 公式サイト
• 少なくとも1つのエージェントバックエンドが構成済みであること（grok / codex / claude / copilot のいずれか）

対応バックエンドが4種に限定されている点は、選定時に確認が必要です。社内で標準化しているエージェント CLI がこの4種に含まれないなら、設定ファイルの <backend> トークンに書く対象がありません。逆に言えば、対象を絞ることで役割ごとのバックエンド割り当てを単純化している構成です。

また前提に zsh と tmux が入るため、実行環境はローカルの Unix 系シェル環境が想定されています。Windows 環境での利用を前提にする場合は、この時点で別の検討が必要になります。

先に知っておきたい2つの注意点

ここで、評価を始める前に把握しておきたい点が2つあります。

1つはライセンスが未設定であることです。GitHub API の license フィールドは null で、README にもライセンスの記載がありません。ライセンスが明示されていないソフトウェアは、既定では著作権者の許諾なく再配布・改変できません。社内のプロジェクトに組み込む形で使う性質のツールであることを考えると、業務利用の可否は作者への確認を経て判断する必要があります。スター数が4千近いこととライセンスの明示は別問題であり、ここは組織のコンプライアンス要件に直結します。

2つめは、README の最上部に掲示されている注意書きです。「Do not spend any money on a bankrbot SWARM token.」という一文が、赤字・太字・下線付きで冒頭に置かれています。プロジェクト名に便乗した暗号資産トークンと本 OSS は無関係である、という趣旨の警告です。「SWARM」という名前で検索して暗号資産関連の情報に行き着いた場合は、別物として切り分けてください。

mainブランチは動かない｜packとforgeの違いとget-swarm-forge

SwarmForge を初見で評価するときに最もつまずきやすいのが、リポジトリの構造です。README には次のように明記されています。

This repository's master branch is named main. It is the landing page, installer source, shared runtime, and shared engineering law. It is not itself a runnable SwarmForge product.

出典: main ブランチ README

main はランディングページであり、インストーラのソースであり、共有ランタイムであり、共有のエンジニアリング法です。ただし、それ自体は実行可能な SwarmForge 製品ではない、という宣言です。つまり git clone して ./swarm を探すという一般的な評価手順が、この構造では成立しません。製品は別のブランチとして提供され、get-swarm-forge というヘルパー経由でインストールします。

製品はブランチで配られる

README の「Products」表で示されている製品は5種類です。

あわせて README は、squad / sprint-module-squad / adversaries の3ブランチは独立した実験的ワークフローであり get-swarm-forge の製品ではない、と明記しています。また simple-windows タグはダッシュボード導入前の main スナップショットで、歴史的なものであり製品ではありません。リポジトリのブランチ一覧を眺めて「どれを使えばいいのか」と迷った場合は、この区別が判断基準になります。

ヘルパー自体の取得手順は README に次のコマンドで示されています。

mkdir -p ~/cmds
curl -L -o ~/cmds/get-swarm-forge \
  https://raw.githubusercontent.com/unclebob/swarm-forge/main/get-swarm-forge
chmod +x ~/cmds/get-swarm-forge

出典: main ブランチ README「Install the helper」（スクリプト本体は get-swarm-forge）

README は、~/cmds を PATH に追加し、ヘルパーが更新されたら再取得するよう案内しています。そしてヘルパーが唯一サポートされるエントリポイントである理由として、複数のブランチからファイルを合成するからだと説明しています。手動でブランチをチェックアウトして組み合わせる運用は想定されていません。

製品の利用例も README に示されています。

get-swarm-forge six-pack
./swarm

出典: main ブランチ README「Use a product」

pack と forge の違い

製品の形態は2つに分かれます。

• pack: 既存のプロジェクトに組み込む形態です。ソフトウェアリポジトリの中でインストールし、./swarm を実行するとそのプロジェクトに設定された役割群が起動します。
• forge: 空のホストディレクトリにインストールする形態です。./swarm でフォージのダッシュボードとホスト lieutenant が起動し、オペレーターが projects/ 配下にプロジェクトを作成または開いた時点でプロジェクトの swarm が起動します。

既存の1リポジトリに対して役割分担を導入したいなら pack、複数プロジェクトを横断して管理したいなら forge、という使い分けになります。

合成の内訳と共有3記事の固定

pack をインストールするとき、ヘルパーは2つのブランチをダウンロードします。README が示す内訳は次のとおりです。

main
  swarmforge/scripts/                    shared runtime and dashboard
  swarmforge/constitution/articles/      shared engineering, workflow, handoffs

<pack branch>
  swarm                                  launcher
  swarmforge/swarmforge.conf             roles, agents, and worktrees
  swarmforge/constitution.prompt         constitution entry point
  swarmforge/constitution/articles/      pack-local additions
  swarmforge/roles/                       role ownership

出典: main ブランチ README「Composition」

この合成には設計上の意図が明示されています。共有記事名 engineering.prompt / workflow.prompt / handoffs.prompt は常に main 由来で、pack 側は project.prompt や local-*.prompt といった別名のファイルで特殊化します。README はこの予約について「pack が共通法を黙って差し替えることはできない（a pack cannot silently replace common law）」と説明しています。共通の品質規律を製品ブランチ側で上書きできない構造にすることで、どの製品を選んでも土台のルールが揃うようにしているわけです。

forge をインストールする場合は、指定した forge ブランチがホストランタイム・lieutenant・ダッシュボードを供給します。project-manager は3つの pack ブランチを packs/ 配下にダウンロードし、lieutenant は単一のテンプレートを .swarmforge/project-pack/ 配下に持ちます。

swarmforge.confが決めるパイプライン｜役割・バックエンド・伝播方向

SwarmForge の宣言的な部分の中核が、プロジェクトごとに置かれる swarmforge/swarmforge.conf です。

1行の文法と各トークンの意味

固定 pack の場合、コメント以外の各行は次の形を取ります。

window[-invisible] <role> <backend> <worktree> [task|batch] [forward-only|back-one|back-all] [backend arguments...]

出典: main ブランチ README「Configuration contract」

README が挙げている各トークンの意味は次のとおりです。

• ファイルの行順が既定の前方パイプラインになります。パイプラインの順序を別のファイルで定義するのではなく、設定ファイルの並び順そのものが順序です。
• ちょうど1つの役割が master worktree を使う必要があります。この master は「プロジェクトのメインチェックアウト（現在のブランチ）」を指すセンチネルであり、git のブランチ名として master が必要という意味ではありません。他の名前は .worktrees/<name> のチェックアウトになります。
• window は端末サーフェスを開きます。window-invisible は tmux 内でのみ動作し、必要なときにダッシュボードから開きます。
• 受信モードの既定は task です。batch を指定すると、互換性のあるキュー済みハンドオフ群をまとめて受け取れます。
• 伝播の既定は forward-only です。back-one / back-all は下流の作業後に、先行する役割へマージ専用のコピーを配ります。
• バックエンドは codex / grok / claude / copilot が対象で、残りのトークンはそのバックエンドへ渡されます。

forge ホストの場合は、代わりに Lieutenant <backend> [backend arguments...] という形を使います。なお README は、ブランチごとに独自の制御プレーン向けに文法を拡張する場合があり（lieutenant は型付きの card ルートを追加、squad 系ブランチは swarmforge/squad.conf を追加）、その拡張については選択したブランチの README とパーサが権威であると明記しています。設定の書き方を調べるときは、main の README ではなく使う製品ブランチ側のドキュメントを見るのが正解です。

six-packの6役割と伝播方向

具体例として、six-pack ブランチの README が示す既定の役割構成を見ると、設定で何をどこまで宣言できるかが分かります。

出典: six-pack ブランチ README（hardender は公式リポジトリ上の表記のまま記載しています）

仕様策定と実装は task モードで1件ずつ受け取り、下流の4つの品質役割は batch モードでまとめて受け取る構成です。cleaner は back-one で直前の役割へ、architect と QA は back-all で先行する全役割へマージ専用コピーを戻します。整理やアーキテクチャ調整の結果が上流に反映される経路が、設定の1トークンで決まっているわけです。また同 README は、Codex を使う2つの役割に --yolo が渡されることにも触れています。行末の追加トークンがバックエンドへそのまま渡る文法が、ここで具体化されています。

ただし six-pack の README 自身が、現在のバックエンド割り当てとトポロジーについてはブランチの設定ファイルが権威であると述べています。上の表は既定値の目安として読み、実際の値はインストールした swarmforge.conf で確認する扱いになります。

ランタイムが起動時に行うこと

README の「Runtime components and generated state」によると、合成されたランタイムは起動時に次の処理を順に行います。設定を検証し、必要なら git を初期化し、役割ごとの worktree を作成し、管理対象の SwarmForge ファイルをそこへミラーし、隔離された tmux セッションを作成し、ハンドオフデーモンとローカルダッシュボードを起動し、設定された各エージェントバックエンドを起動します。

生成される状態は2つのディレクトリに分かれます。トランスポートとプロセスの状態は .swarmforge/ 配下（役割とセッションのマップ、tmux ソケット、ハンドオフの inbox と outbox、ボードデータ、承認、確認事項、デーモンの状態、ダッシュボードの状態）、役割ごとのチェックアウトは .worktrees/ 配下です。

README は .swarmforge/ について「製品のソースではなく、エージェントはヘルパーコマンドの代わりにこれを直接編集してはならない」と明記しています。状態の書き換えはヘルパースクリプト経由に限る、という境界が設計として引かれています。

永続ハンドオフの仕組み｜ファイルの置き場所がキュー状態になる設計

役割間の引き継ぎを担うのが永続ハンドオフです。仕様はハンドオフプロトコル文書にまとまっています。なおこの文書は「Handoff Daemon Proposal」という見出しで、should を使った規範的な記述で書かれています。README からは「メッセージ形式・監査・配送・リトライ・マージ・ライフサイクルの詳細」の参照先として案内されており、実装の設計根拠を読む位置づけの文書です。

デーモンが配送しtmuxは通知のみに使う

この文書が掲げるゴールは、エージェントによる tmux ソケットへの直接アクセスを、デーモンが所有するファイルトランスポートに置き換えることです。エージェントは tmux コマンドを送らず、ソケットのパーミッションを管理せず、独自のログブックも持ちません。エージェントがするのは「小さく検証済みのハンドオフ要求」を作ることだけで、配送は永続的な inbox ファイルを通じてデーモンが行い、tmux 経由で送られるのは起床通知だけです。

swarm の起動スクリプトが tmux セッションと並行してハンドオフデーモンを起動します。デーモンは tmux ソケットへの直接アクセスを持ち、各エージェントの worktree を監視します。送信用のハンドオフファイルが現れると、デーモンは配送先を検証し、各受信者の inbox へコピーし、受信者それぞれに汎用の起床メッセージを tmux で送り、元のファイルを sent または failed へ移します。

tmux を「通知路」に限定し、実際のデータ経路をファイルに寄せた設計です。プロセスが落ちても、キューの内容はファイルとして残ります。

ファイル名とヘッダーの役割分担

各エージェントの worktree が所有するディレクトリ構造は次のとおりです。

.swarmforge/handoffs/
  outbox/
    tmp/
  sent/
  failed/
  inbox/
    new/
    in_process/
    completed/

出典: ハンドオフプロトコル文書「Directory Layout」

デーモンが outbox/ を消費し、エージェントはヘルパースクリプト経由で inbox/new/ を消費します。文書は「受信 inbox がタスクキューである」と述べ、キューの状態はファイルの置き場所で表現され、監査タイムスタンプはハンドオフファイルのヘッダーに保存されると明記しています。sent / failed / in_process / completed の4ディレクトリが、監査トレイルと再起動時の状態を提供します。

ファイル名のフォーマットは、優先度・タイムスタンプ・シーケンスの順にソートされる形です。

<priority>_<timestamp>_<sequence>_from_<sender>_to_<recipient-list>.handoff

出典: ハンドオフプロトコル文書「Filename Format」

文書に挙げられている例は次のものです。

00_20260615T140531Z_000042_from_architect_to_coder_cleaner_QA.handoff

出典: ハンドオフプロトコル文書「Filename Format」

優先度は 00 から 99 までの2桁で、小さい番号が先に処理されます。タイムスタンプは UTC の YYYYMMDDTHHMMSSZ 形式、シーケンスは worktree ごとのカウンタで、同じ秒に作られたハンドオフの同着を解消します。受信者は監査のためファイル名に残ります。

ここで運用上重要なのは、スクリプトが権威として参照するメタデータはファイルヘッダーであり、ファイル名ではないという規定です。ファイル名は人間が監査トレイルを読むための可読性のために構造化されており、処理の正当性はヘッダー側が担保します。文書は、監査ファイル名の受信者リストを読みやすく保つために、起動時検証でアンダースコアを含む役割名を拒否すべきだとも述べています。役割名の命名規則がファイル名フォーマットの制約から導かれている例です。

taskとbatch・forward-onlyとback-all

受信モードと伝播についても、同文書が設定ファイルとの対応を説明しています。受信モードを省略した場合は task、受信モードの後ろの伝播トークンを省略した場合は forward-only が既定です。back-one と back-all は先行するウィンドウへマージ専用のコピーをキューしますが、カード自体は移動しません。ボード上のタスクの所在と、マージ用コピーの配布は別物として扱われています。

実装の観点で押さえておきたいのは、ランチャーが正規化した受信モードと伝播を .swarmforge/roles.tsv に書き出し、エージェント向けの受信ヘルパーは swarmforge.conf を再パースせずにこのランタイムファイルを読む、という点です。設定の解釈は起動時に一度だけ行われ、実行中のスクリプトは正規化済みの値を参照します。

batch の使いどころとして文書が挙げているのは、等優先のキュー済みハンドオフを1単位として消費すべき役割です。具体例として six-pack の cleaner / architect / hardender / QA、four-pack の architect が名指しされています。先ほどの役割表の batch 指定と対応しています。

エージェント側の操作は3つのヘルパースクリプトに集約されています。README によれば、コミット済みの成果を送るのが swarm_handoff.sh、受理するのが ready_for_next.sh、現在のアイテムを完了するのが done_with_current.sh です。

constitutionが課す規律｜TDD・mutation・CRAP・DRYの実体

「規律を課すツール」という説明は、それだけでは抽象論です。SwarmForge の場合、何が規律なのかは共有憲章のテキストに書かれており、一次情報で確認できます。

エージェントが起動時に読むもの

README は、インストーラが「指示をデータとして合成する」のであり、製品ごとのルールをランチャーに焼き込むわけではないと説明しています。通常の pack エージェントは、swarmforge/constitution.prompt を読み、それが名指すものを再帰的に読み、次に swarmforge/roles/<role>.prompt を読む、という指示付きで起動します。

main が所有する共有3記事の責務は次のとおりです。

役割プロンプトは、この法の内側で所有権を分割します。README の表現では「その役割が変更してよいもの、検証しなければならないもの、他の役割に委ねるもの、次のハンドオフの宛先」を定義します。設定された全役割に対応するプロンプトが存在しなければなりません。例外は forge の lieutenant で、共有の swarmforge/roles/lieutenant.prompt が明示的にプロジェクトのエンジニアリング憲章の外側に置きます。

six-pack の場合、プロジェクトのエージェントは役割プロンプトの前に6記事すべてを読みます。main 由来の3記事に加えて、six-pack ブランチが持つ project.prompt（6役割の形・ローカル状態の置き場所・ハンドオフ様式・所有境界の宣言）、local-engineering.prompt（specifier 以外にユニットと受入挙動の検証を要求し、最終品質役割に property テストの実行を要求）、local-workflow.prompt（QA のマージ専用終端ハンドバックを、パイプラインを再起動せずに先行役割が処理する方法を定義）の3記事です。constitution.prompt が指示のエントリポイントであり、記事より優先されます。

TDD を前提にエージェントの品質を管理する考え方自体は、他のツールやスキル集でも扱われています。たとえばAIコーディングエージェントをTDDで品質管理するagent-skillsは、単一エージェントのスキル定義としてこの方向に踏み込んでいる例です。SwarmForge の特徴は、同じ規律を複数役割の協調パイプラインに対して固定している点にあります。

言語ごとに固定されたツールチェーン

共有 engineering.prompt の「Startup Tools」は、起動時に対象言語の CRAP・ミューテーション・DRY ツールを github.com/unclebob/... のリポジトリから最新版で直接調達して実行可能にするよう定めています。キャッシュ済み・vendored・プリインストール済みのコピーに頼らない、という指定です。

言語別のツールは次のように指定されています。

この表は、導入判断において見逃せない制約です。憲章が前提にしているのは Go・Clojure・Java の3言語で、TypeScript や Python を主戦場にしているチームの場合、この品質ツール群はそのまま適用できません。「品質規律を固定できる」という利点は、固定されている規律が自社の言語に用意されている場合に限って享受できます。

言語デフォルトについても具体的な指定があります。Clojure では可能なら Babashka を優先し、Clojure および Babashka では clojure.test ではなく Speclj の spec を書くことが求められます。Java ではテスト実行に Maven を使わず、専用のテストランナーを用意することが指定されています。テスティングフレームワークの選択まで憲章で決まっている点は、既存のテスト資産を持つプロジェクトに組み込む際の摩擦になり得ます。

設計とテスト容易性についても規定があります。小さくレビュー可能な単位で作業する、現在の挙動を支える最も単純な設計を好む、GUI や外部デバイス依存など自動テストに適さないモジュールをテスト可能なモジュールから分離してテスト可能なコードを最大化する、といった内容です。加えて、IO 近傍のモジュールがドメイン判断を再実装することを「依存方向が内向きであっても欠陥」と明記しています。受入テストには Gherkin を用い、unclebob/Acceptance-Pipeline-Specification を使うことが指定されています。

検証とガードレール

同記事の「Verification」は、検証の実行方法まで踏み込んでいます。要求されているのは次の5点です。

• 憲章ツールは1つずつ実行し、CRAP・DRY・カバレッジ・言語ミューテーション・Gherkin ミューテーション・structure-check を同時に走らせないこと
• worker の上限を --max-workers 4 または --workers 4 に収めること
• 関数のミューテーションはソースマニフェストに対する差分で行い、--mutate-all を渡さないこと
• Gherkin のミューテーションは --level hard の差分で行い、--level full を渡さないこと
• ハンドオフの前にプロジェクトのローカル検証コマンドを実行すること

「Guardrails」には、規律を骨抜きにする行為の禁止が並びます。自作の bb crap / bb coverage / bb mutation-count を憲章ツールの代用にしないこと、ミューテーションおよび Gherkin 受入ミューテーションのマニフェストを手で編集しないこと、無関係なローカル変更や生成物をコミットしないことが明記されています。

エージェントは指示が曖昧だと近道を取りがちですが、その近道を具体的に名指しして禁じる形になっています。なお main の README には、憲章そのものの扱いについても「プロンプトの文面を自動テストで固定するな。観測可能なランタイム挙動をテストせよ」という方針が書かれています。

類似OSSとの違い｜claude-squad・vibe-kanban・emdashと比べた選定軸

複数エージェントを扱う OSS は増えており、「隔離できる」という説明だけでは差が見えません。AIエージェントのオーケストレーションを担うツールとして代表的な3つと並べて比較します。

3つの類似OSSの位置づけ

スター数・ライセンス・最終 push はいずれも 2026 年 10 月 4 日に GitHub API から取得した値です。

claude-squad は、tmux ペインと git worktree で複数エージェントを隔離するという点で、基盤の選択が SwarmForge に最も近いツールです。ただし提供価値はターミナル UI による並列セッション管理であり、役割分担・ハンドオフ順序・エンジニアリング規律の強制は含みません。

vibe-kanban は、各タスクに専用の git worktree・ブランチ・ターミナル・開発サーバを与え、カンバン UI でタスクを人が割り当てる構成です。人間がボードを回す前提のワークフローであり、エージェント間の自動ハンドオフチェーンとは設計の出発点が違います。

emdash は、多数のプロバイダを1つの UI で並列に走らせることを主眼に置いた GUI 型の環境です。対応プロバイダの幅が広い一方、品質ゲートの標準化は範囲外です。

観点別の比較表

どれを選ぶかの判断軸

4つを「隔離できるか」で比べると似て見えますが、実際の選定軸は「役割の順序と品質基準を誰が保証するか」です。整理すると次の3分岐になります。

1. 人がボードを回して配分を判断したい — vibe-kanban や emdash のように、人間が割り当てる前提の UI を持つツールが向きます。進捗の可視性を重視するチームの選択です。
2. ターミナル上で素早く並列に動かしたい — claude-squad のように、隔離と切り替えに機能を絞ったツールが軽量です。並列実行の仕組み自体を比較する場合は、AIコーディングエージェントの並列実行にOrcaが選ばれる理由も比較対象になります。
3. 規律をリポジトリ内のテキストとして固定したい — SwarmForge が狙っているのはここです。順序を swarmforge.conf の行順で、品質基準を憲章記事で宣言するため、人が毎回指示しなくても同じルールが適用されます。

ただし3番目の利点は、憲章が前提にする言語とツールチェーンが自社に合う場合に成立します。合わない場合は、憲章を自前で書き換える作業が実質的な導入コストになります。ライセンスが未設定である点も、この層の判断に直接影響します。

導入前に確認したい判断ポイント

ここまでの内容を、導入判断のチェックリストとして整理します。

1. ライセンスが未設定である（license: null）。README にもライセンス記載がありません。ライセンスが明示されていないため、既定では著作権者の許諾なく再配布・改変できない状態です。社内プロジェクトに組み込む使い方をするツールである以上、業務利用の前に作者への確認が必要です。
2. 前提ツールと対応バックエンドが自社環境と合うか。zsh / git / tmux / Babashka が必要で、エージェントバックエンドは grok / codex / claude / copilot の4種に限られます。標準化しているエージェント CLI がこの範囲に入るかを先に確認してください。
3. 憲章の言語前提と自社の技術スタックが合うか。共有 engineering.prompt が品質ツールを指定しているのは Go・Clojure・Java の3言語です。Clojure では Speclj、Java では専用テストランナーといったテスト方針まで規定されています。主言語が範囲外の場合、憲章の書き換えコストを見積もる必要があります。
4. main は製品ではないため、評価には get-swarm-forge 経由のインストールが必要です。クローンして起動するという手順を前提に工数を見積もると、実態と合いません。
5. 活動状況は、スター 3,949・フォーク 396・最終 push 2026 年 9 月 7 日です。アーカイブされておらず、他リポジトリのフォークでもありません。
6. 権威あるドキュメントは製品ブランチ側にあります。main の README は共通の枠組みを説明するもので、現在のバックエンド割り当てとトポロジーについては選択したブランチの設定ファイルと README が権威である、と README 自身が述べています。設定を調べるときの参照先を間違えないようにしてください。

重ねて記しますが、本記事は公式ドキュメントと GitHub API のメタデータに基づく整理であり、インストールや実行を伴う動作検証に基づく推奨ではありません。実際の挙動は選択した製品ブランチのバージョンと実行環境に依存します。

まとめ

SwarmForge の位置づけを3点で整理します。

正体: 複数の AI エージェントを git worktree と tmux セッションで隔離し、役割の順序・受信モード・伝播方向を swarmforge/swarmforge.conf の行として宣言し、品質規律を憲章テキストとして固定するオーケストレーションツールです。成果のやり取りはコミット単位の永続ハンドオフで行われ、キューの状態はファイルの置き場所で表現されます。

最大の落とし穴: main ブランチは実行可能な製品ではありません。製品はブランチとして配られ、get-swarm-forge ヘルパーが複数ブランチからファイルを合成します。この構造を知らずに評価を始めると、入口で止まります。

最大の判断材料: ライセンスが未設定である点と、憲章の品質ツールが Go・Clojure・Java 前提である点です。この2つは「規律を固定できる」という利点を享受できるかどうかを分けます。

次に確認すべきは、使う予定の製品ブランチ（two-pack / four-pack / six-pack / project-manager / lieutenant）の README と、そのブランチの swarmforge/swarmforge.conf です。役割の割り当てとトポロジーの権威はそちら側にあります。あわせて共有 engineering.prompt を読み、自社のテスト方針と矛盾しないかを照合すると、導入可否の判断がつけやすくなります。

関連情報

AI エージェントを前提にした開発プロセスの設計や、既存プロジェクトへの導入可否の整理をご検討中の方は、お問い合わせフォームからご相談いただけます。要件が固まる前の段階からご相談を承っています。

AI エージェントを活用した開発に携わる案件をお探しのエンジニアの方は、Workee で案件を探すからサービス内容をご覧いただけます。

参考リンク

• unclebob/swarm-forge（リポジトリ）
• main ブランチ README
• six-pack ブランチ README
• ハンドオフプロトコル文書
• 共有エンジニアリング憲章 engineering.prompt
• インストーラ get-swarm-forge
• Babashka 公式サイト