AIエージェント群を1体が統括するOSS「firstmate」の仕組み

コーディングエージェントを 1 本だけ走らせているとき、人間の仕事は「指示を出して結果をレビューする」ことです。ところが同時に 2 本、3 本と走らせ始めた瞬間、仕事の中身が入れ替わります。どのタブで何が止まっているのかを探し、同じ説明を別のセッションにコピペし、テストが落ちていたのはどのターミナルだったかを思い出す――つまり「タブのお手玉」が本業になってしまいます。

この摩擦は、エージェントの性能とはほとんど関係がありません。並列数が増えるほど、人間が「見守り」に使う時間が線形に増えていくという構造の問題です。git worktree でブランチを隔離し、tmux でペインを並べる手組みはすでに広く共有されていますが、それは隔離と可視化までの解決であって、「誰がいつどのセッションを覗くか」は人間に残ります。

firstmate は、この残りの部分に手を入れた OSS です。人間が複数のエージェントを並べて見るのではなく、1 体の「first mate（一等航海士）」役のエージェントにだけ話しかけ、その 1 体がクルー（自律エージェント群）を差配・統括するという階層型のモデルを採ります。リポジトリの説明文も「Talk to one agent. Ship with a crew.（1 体のエージェントに話し、クルーで出荷する）」という一文です。

本記事では、firstmate の位置づけと仕組み、導入にあたって決めるべきこと、類似 OSS との差分、そしてメンテナンス状況までを整理し、採用候補に残すか見送るかを判断できる材料を提示します。なお本記事は公式リポジトリ・公式ドキュメント・GitHub の公開情報を読み解いて整理したものであり、実行環境での動作確認の結果ではありません。

firstmateとは｜1体の窓口エージェントがクルーを動かすOSS

firstmate は、複数のコーディングエージェントを「クルー」として並列稼働させ、その監督を 1 体のエージェントに委任するための OSS です。中心にあるのは、1 体の first mate がクルー全体を統括し、人間はその 1 体とだけ会話するという構造です。ユーザーは「captain（船長）」として first mate に話しかけ、first mate が可視化されたセッション上にクルーメイトを立ち上げ、各々にクリーンな git worktree を与え、完了まで面倒を見て、最終的に PR・承認済みのローカルマージ・単独の調査レポートのいずれかを返してきます。

firstmateのリポジトリ基本情報

採用判断の出発点として、GitHub 上の属性を確認しておきます。

主要言語が Shell であることは、このプロジェクトの性格をよく表しています。監督ロジックの中核が Bash スクリプト群で構成されており、後述する「トークンを消費しない監督」も、この実装方針から導かれています。アーカイブされたリポジトリではなく、他リポジトリのフォークでもないため、本家として現在も開発が続いている状態です。ライセンスは MIT で、商用利用を含めた扱いやすさの面では制約が少ない部類に入ります。

「agent distro」という自己定義とcaptain・first mate・crewmateの役割

firstmate を理解するうえで最初の障壁になるのが、README の自己定義です。README は「firstmate is not a model, not a harness, not a skill, not an MCP server, and not a CLI. firstmate is an agent distro for running a crew of agents.」と述べ、モデルでもハーネスでもスキルでも MCP サーバーでも CLI でもないと、既存カテゴリをすべて否定したうえで「エージェントのクルーを動かすためのエージェントディストロ（agent distro）である」と位置づけています。

ここでいうエージェントディストロとは、指示・スキル・ツール・ポリシー・状態の規約をひとまとめにしたポータブルなディレクトリで、汎用のエージェントを特化型のエージェントに変える役割を持つもの、とされています。重要なのは、インストールするアプリケーションが存在しない点です。クローンしたリポジトリそのものが配布物であり、AGENTS.md・同梱スキル・ヘルパースクリプトの集合がそのまま「distro」になります。

そして、対応するエージェントハーネスをこのディレクトリの中で起動すると、その主セッションが「first mate」になり、ユーザーは「captain」になります。役割は 3 層です。

なお表記について補足すると、プロダクト名は小文字の firstmate で、半角スペースを挟んだ first mate は「一等航海士」という役割名を指します。README もこの 2 つを使い分けており、本記事でも同じ区別に従います。

firstmateが解決する課題｜並列エージェント運用の摩擦

firstmate の README は、機能紹介の前に課題設定から入ります。1 体のコーディングエージェントを動かすのは簡単だが、3 つのタスクを並列で進めようとするとタブのお手玉になる――セッションの世話をし、リポジトリ間でコンテキストをコピペし、どのターミナルでテストが落ちていたかを忘れる、という状況です。これを 3 つの摩擦に分解すると、firstmate がどこを引き受けるのかが見えてきます。

ここで線を引いておくべきなのは、3 番目の「隔離」だけが目的なら firstmate は必ずしも必要ないという点です。git worktree と tmux を組み合わせた並列エージェント運用は日本語圏でも手順が多数共有されており、並列数が 1〜2 本に収まっているなら、手組みのスクリプトで十分に機能します。また、1 つのエージェントセッション内でサブエージェントを並列に走らせるアプローチもあり、こちらは Claude Code SubAgentで並列処理を実装 で扱っています。

firstmate が引き受けるのは、むしろ 1 番目の「見守りの自動化」です。並列数が常時 3 本以上になり、人間が巡回役として張り付く時間がボトルネックになってきたとき、はじめて firstmate の設計が効いてきます。逆にいえば、並列数が少ないチームが導入しても、統括の委任による恩恵より Bash スクリプト群と設定項目の学習コストが先に来る可能性があります。

firstmateの仕組み｜クルー・worktree・監督の3層

ここからが firstmate の中核です。README の "How It Works" は、captain の要望が first mate に渡り、first mate が fm-task1..N という名前のクルーメイトを立ち上げ、各クルーメイトが専用の worktree で作業し、最終的に ship（PR やローカルマージ）または scout（調査レポート）として返ってくる、という流れを示しています。この流れを支えているのが、窓口・隔離・監督の 3 層です。

窓口となるfirst mateと自律実行するクルーメイト

firstmate の README が最初に挙げる機能は "One liaison"、つまり「窓口は 1 つ」です。captain が話す相手は first mate だけで、first mate がタスクの dispatch と監督を行い、本当に人間の判断が必要な事項だけをエスカレーションします。

この分担を支えているのが "Strict project boundary" という制約です。first mate は、明示的に認可された狭い操作を除き、プロジェクトに対して原則 read-only として扱われます。プロジェクトへの変更はすべてクルーメイトが、あらかじめ設定されたマージ権限の下で行います。つまり「指揮を執る側」と「手を動かす側」を権限レベルで分離しており、統括役の暴走がそのままリポジトリの変更にならないよう線が引かれています。

また、状態はすべてディスクとセッションバックエンドに保持される設計（README が "Restart-proof" と呼ぶ性質）になっており、セッションが落ちても次の起動時に再調整される前提が置かれています。長時間の並列運用を想定したときに効いてくる設計です。

使い捨てのgit worktreeによる作業隔離

各タスクは、クリーンな git worktree の中で実行されます。この worktree の管理には同じ作者による treehouse が使われ、backend=orca を選んだ場合は Orca が管理する worktree が割り当てられます。

worktree をタスク単位で使い捨てにする効果は明快です。同一リポジトリに対する複数の変更作業が、お互いのワーキングツリーを踏まないため、「エージェント A が編集中のファイルをエージェント B が書き換える」という事故が構造的に起きません。ブランチ名の既定プレフィックスは fm/ で、後述する設定で変更できます。

ここで押さえておきたいのは、treehouse が firstmate の競合ではなく構成要素だということです。treehouse 単体は worktree の作成・切り替えを扱う CLI であり、エージェントの管理は行いません。firstmate はその上に「誰にどの worktree を与え、どう監督するか」を載せた層だと捉えると、両者の関係が整理できます。

可視化されたセッションバックエンド

クルーメイトは、見える場所で動きます。各クルーメイトは自分の tmux ウィンドウ（または Herdr のタブ）で動作し、ユーザーはそのペインを覗いたり、直接キーを打ち込んだりできます。tmux がリファレンス実装であり既定のバックエンドで、Zellij のタブ・cmux のワークスペース・Orca のターミナルは実験的な位置づけです。

この「覗ける・介入できる」という性質は、監督を自動化するツールとしては重要な設計判断です。統括を委任しても、人間が最終的に中身を確認する経路が閉じていないため、エージェントの挙動がブラックボックス化しません。

なお、公式ドキュメントには docs/codex-app-backend.md というファイルがありますが、README によれば codex-app はまだランタイムバックエンドではなく、このドキュメントは Codex App との境界を扱うものです。バックエンドの選択肢として数えないよう注意が必要です。

ゼロトークンのイベント駆動監督

技術的にもっとも見どころがあるのが監督エンジンです。公式の docs/architecture.md によれば、bin/fm-watch.sh がゼロトークンの Bash watcher としてフリートの上でスリープし、検知した wake（起床イベント）を Bash で分類して、対応が必要なときにだけ first mate を起こします。LLM を常時走らせて監視するのではなく、分類までを Bash で済ませることでトークン消費を発生させないという割り切りです。

actionable と判定される wake の例としては、captain に関係するステータスシグナル、クルーが稼働中である肯定的な証拠を伴わないシグナル、PR マージのポーリング結果、一定時間を超えて停滞したペイン、外部待ちの宣言が長く残っているケース、heartbeat のバックストップなどが挙げられています。

このなかで設計上もっとも示唆的なのが、worktree への書き込みを「生きている証拠」として扱うという判定方法です。ペインが静止していても、その裏でクルーがソース → テスト → ドキュメントと書き進めていることはあります。ペインの静止や実行ステップだけを見ると「止まっている」と誤判定しかねないため、worktree 内の更新ファイルを稼働の証拠として用い、エスカレーションを遅らせます。書き込みの証拠が取れない場合（worktree 記録の欠落、撤去済みの worktree、ウォールクロック超過、walk の失敗）は、既存のエスカレーション予定を変更しません。つまり「証拠があれば待つ、なければ予定どおり起こす」という安全側の設計です。

安全性の線引きも明示されています。同ドキュメントは、機械的に保証できるのは「スクリプトが言葉を読まずに確認できること」だけだと述べ、レコードロック下のライブ HEAD でのマージ green、同期マージのみ、spend cap といった検証可能な条件を挙げています。そして、破壊的・不可逆・セキュリティ上重要な操作は、どのような指示があっても事前認可されないとしています。自律度を上げるツールとしては、この線引きが明文化されているかどうかが信頼性の判断材料になります。

firstmateの導入要件と運用設計で決める3つの軸

ここからは firstmate の使い方（起動手順）と、運用に乗せる前に決めておく設定の軸を整理します。firstmate はアプリをインストールしないため、「導入」はクローンして対応ハーネスをその中で起動するところまでです。README が示す起動手順は次の 3 行です。

gh auth login
git clone https://github.com/kunchenguid/firstmate
cd firstmate

出典: kunchenguid/firstmate の README

そして README には、起動後の対話がどう進むかの例も記載されています。

> ahoy! look at my github project xyz, then fix the flaky login test and add dark mode

# firstmate checks its toolchain (asking your consent before installing anything),
# clones the project under projects/ and spawns two isolated workers in the active backend.
# Minutes later:

  PR ready for review, captain: https://github.com/you/xyz/pull/42
  (fix flaky login test - risk: low - CI green)

> alright merge it

出典: kunchenguid/firstmate の README

自前のツールチェーンを点検し、不足があればユーザーの同意を取ってからインストールを提案する、プロジェクトを projects/ 配下にクローンする、アクティブなバックエンド上に隔離されたワーカーを 2 つ立ち上げる――という流れが、この短い例に凝縮されています。手順そのものは軽い一方で、運用に乗せる前に決めるべきことがいくつかあります。

前提条件と推奨ハーネス

必要なものは、対応するエージェントハーネスのいずれか、Git と認証済みの GitHub CLI（gh auth login）、そして選択したランタイムバックエンドの CLI と依存関係です。不足しているツールは first mate が検出し、ユーザーの承認を得てからインストールを提案します。

ハーネスの扱いは一様ではなく、README は以下のように差をつけています。

ここは採用判断に直結します。すでに Claude Code・Grok・Pi のいずれかを主軸にしているなら推奨構成に乗れますが、Cursor Agent CLI を headless で回す前提のワークフローだと、主セッションを対話的に保つ必要があるという制約が先に効いてきます。公式が「検証済み」と記載するハーネスであっても、監督の実装方式が異なる点は事前に確認しておく価値があります。

プロジェクトモードとタスクの2形態

firstmate は、プロジェクト単位で自律度を宣言させます。

タスクの形は 2 つに分かれます。ship タスクは認可された変更を届けるもの、scout タスクは変更を加えず単独の調査レポートを残すものです。この 2 分割があるため、「コードは触らせたくないが調査だけ並列でやらせたい」という使い方が明示的にサポートされます。既存コードベースの把握フェーズで並列調査を回したい場合には、この scout タスクが入り口になります。

FM_HOMEとsecondmateによる隔離

複数のインスタンスを同時に走らせたい場合は、FM_HOME の理解が必要です。公式の docs/configuration.md によれば、FM_HOME は 1 つの firstmate インスタンスの「operational home」を選ぶ環境変数です。リポジトリルートが共有コード（bin/）を持ち、operational home 側が private な state/ / data/ / config/ / projects/ を持つという役割分担になっています。FM_HOME が未設定の場合はほとんどのスクリプトがリポジトリルートを home として扱いますが、bin/fm-send.sh は FM_HOME の設定を必須とします。

また、バックエンドによって FM_HOME の意味が変わる点にも注意が必要です。Herdr ではワークスペースラベル、Zellij ではタブタイトルの home プレフィックス、cmux では既定の config パスとワークスペースタイトルのプレフィックスとして解釈され、Zellij と cmux には home ごとのコンテナ分割がありません。

この FM_HOME を独立させることで、"secondmate" と呼ばれる 2 体目以降の常駐インスタンスを立てられます。それぞれが独立した state・projects・セッションロックを持ち、ローカルでも SSH で到達できる別ホストでも運用できます。設定の軸は他にも、ランタイムバックエンド（config/backend / FM_BACKEND）、backlog バックエンド（.tasks.toml / config/backlog-backend）、captain preferences（data/captain.md）、起動時のメモリ予算、config/calm などがあり、索引から辿る構成になっています。

なお、X や Discord の公開メンションに応答する Relay 機能と voice relay は opt-in です。ローカルの .env にペアリングトークンを設定して有効化するまで動かず、dry-run プレビューも用意されています。既定の状態で外部に発信することはない設計なので、社内運用で外部連携を避けたい場合はこの機能を有効化しないという選択がそのまま成立します。

類似OSSとの違い｜claude-squad・vibe-kanbanとの比較

並列エージェント運用の OSS は複数あり、どれを選ぶかの判断には操作モデルの違いを押さえるのが近道です。2026年10月4日時点の GitHub 公開情報をもとに、代表的な 2 つと比較します。

差分の本質は、人間が複数エージェントを並べて見るのか、1 体のエージェントに統括を委任するのかという操作モデルの違いです。claude-squad は「並べて見る」を快適にする方向、vibe-kanban は「ボードで管理する」方向にそれぞれ最適化されており、firstmate は「見る役自体を自動化する」方向に進んでいます。どちらが優れているという話ではなく、ボトルネックがどこにあるかで選択が変わります。セッションの切り替えが面倒なら claude-squad、タスクの可視化と割り当てが課題なら vibe-kanban、巡回に人間が張り付いていることが課題なら firstmate、という対応で考えると判断しやすくなります。

ライセンスの違いは、社内利用の判断材料として見落とせません。firstmate は MIT、vibe-kanban は Apache-2.0 で、いずれも比較的制約が緩い部類です。一方 claude-squad は AGPL-3.0 で、ネットワーク越しにサービス提供する形態で改変版を使う場合はソース開示義務が関わってきます。社内ツールとしてそのまま使うだけなら問題になりにくいものの、自社プロダクトに組み込む構想があるなら事前の確認が必要です。

もう 1 つ、並列 worktree セッションのデスクトップアプリである stravu/crystal もかつて同じ領域にありましたが、2026年2月以降 push が止まり、説明文のとおり「Nimbalyst」へ移行しています。現役の比較対象としては claude-squad と vibe-kanban を見るのが妥当です。

このカテゴリ全体の俯瞰は、AIコーディングエージェントの並列実行にOrcaが選ばれる理由 と Multicaとは？OSSで注目されるAIエージェント管理プラットフォームを解説 でも扱っています。

firstmateのメンテナンス状況とライセンス

採用判断の最後のピースは、プロジェクトの健全性です。2026年10月4日時点の GitHub 公開情報から観測値を並べます。

公開から約 4 か月でスター 7,471、コントリビューター 91 名、マージ済み PR 871 件という数字は、開発が非常に活発であることを示しています。直近 30 日のコミットも 100 件を超えており、最終 push も記事執筆時点の直前です。

一方で、オープン PR が 1,492 件、オープン Issue が 573 件積み上がっている点も同時に観測されます。この 2 つの数字は矛盾するものではなく、「流入する提案の量がメンテナの処理能力を上回っている」という、注目度の高い若いプロジェクトでよく見られる状態です。採用時の実務的な含意は 2 つあります。第一に、自分が出した PR や Issue がすぐに取り込まれる前提は置きにくいこと。第二に、挙動の疑問点は Issue の検索よりも、Bash スクリプトとドキュメントを直接読んで解決する姿勢が求められることです。

tag release が 0 件という点は、一見すると不安材料に見えますが、設計との整合として理解できます。firstmate はインストールするアプリを持たず、クローンしたリポジトリ自体が配布物です。したがってバージョン番号付きのアーカイブを配る必要がなく、更新は組み込みスキルの /updatefirstmate が firstmate 本体と secondmate のガード付き更新・再起動として担います。バージョン固定して運用したい場合は、タグではなくコミットハッシュで管理する前提になります。

ドキュメント量については、公式リポジトリに docs/ 配下の多数のファイルと AGENTS.md・CONTRIBUTING.md が揃っており、情報が不足している状態ではありません。ただし docs/architecture.md は 1 文が長く、スクリプト名・環境変数名の列挙が多い構成で、読者層としては maintainer 寄りです。評価の良し悪しではなく、読み手の前提が違うという話で、初見のユーザーが全体像を掴むには README と各バックエンドのドキュメントから入るほうが負荷が軽くなります。この読み分けが必要になることは、学習コストとして見積もりに含めておくのが現実的です。

firstmateが向くチームと、見送ってよいチーム

ここまでの材料を、採用判断の選択肢に変換します。

向いているケース

• 同一リポジトリで常時 3 本以上の独立したタスクを並列で回したい。隔離だけでなく「巡回する人間」を減らしたい
• ターミナル中心のワークフローを崩したくない。ブラウザ UI やデスクトップアプリを新たに運用対象に加えたくない
• tmux の運用に慣れており、ペインを覗いて直接介入する操作が自然に行える
• PR が返ってくるまでの監督を人手から外し、判断が必要な場面だけに人間を呼び出す形にしたい
• 主軸のハーネスが Claude Code・Grok・Pi のいずれかで、推奨構成に素直に乗れる
• MIT ライセンスである必要がある（AGPL-3.0 のツールを採用しにくい事情がある）

見送ってよいケース

• 並列数が 1〜2 本に収まっており、git worktree の手組みで実務が成立している。統括を委任する恩恵より学習コストが大きい
• タスクの一覧性を重視し、UI ベースのボードでステータスを管理したい（この要求には vibe-kanban 系のほうが素直に応えます）
• Bash スクリプト群の挙動を追う余力がない。問題が起きたときに bin/ 配下を読む運用を許容できない
• 主軸のハーネスを headless で回す前提のワークフローがあり、主セッションを対話的に保つ制約が受け入れられない
• 既存ツールで並列運用が機能しており、置き換えの動機が「新しいから」以外に見つからない

採用候補に残す判断をした場合、次に読むべき公式ドキュメントは 3 点です。全体像の確認には README、監督契約と条件付き手順のルーティング索引としては AGENTS.md、既定バックエンドの具体的な挙動を押さえるには docs/tmux-backend.md が入り口になります。設定項目を一覧したい段階に進んだら、前述の docs/configuration.md を索引として使うと必要な設定に辿りやすくなります。

エージェントに自律的な運用を任せる設計思想そのものに関心がある場合は、Claude Codeを Plan→Work→Review で自律運用するOSS「claude-code-harnes… も隣接するテーマとして参考になります。

関連情報

AIエージェントを開発プロセスに組み込む設計や、既存の開発体制への導入をご検討中の方は、お問い合わせフォーム からご相談いただけます。要件が固まっていない構想段階からのご相談にも対応しています。

AIコーディングエージェントを活用した開発案件に関心のあるエンジニアの方は、Workee で案件を探す からご覧いただけます。