firstmateはエージェントをどう束ねるか：可視セッションとGitワークツリーの境界

firstmateはアプリではなくディストロ

firstmateは、モデル、ハーネス、スキル、MCPサーバー、CLIのいずれでもなく、エージェントディストロだとREADMEで説明されています。指示、スキル、ツール、ポリシー、状態の規約を持つ移植可能なディレクトリで、汎用のターミナルコーディングエージェントを、特定の運用を担うエージェントへ変える考え方です。インストーラーはなく、リポジトリをcloneしたものがディストロになります。

AGENTS.md、同梱されたfirstmateのスキル、ターミナルエージェントが従えるヘルパースクリプトを読み、対応ハーネスをその中で起動すると、一等航海士役のエージェントが立ち上がります。利用者は一つの相手と話し、実際の作業はクルーへ分配されます。この構造を理解せずに単独のCLIとして扱うと、状態の保存場所、監督の責任、変更の承認経路を取り違えやすくなります。

一つの窓口と見えるクルー

firstmateの基本形は、利用者がfirst mateとだけ対話し、first mateが作業を派遣、監督、必要な判断のエスカレーション、結果の報告を行う形です。各クルーは自分の可視セッションで動き、READMEはtmuxウィンドウ、実験的なherdrやzellijのタブ、cmuxワークスペース、Orcaターミナルを挙げています。利用者が作業の様子を見たり、必要な時に端末へ入力したりできます。

この可視性は、ブラックボックスを消すというより、観察できる場所を決める機能です。どのセッションがどのタスクを担当し、どのリポジトリを読み、どの結果を返したかを記録する必要があります。firstmateが一等航海士として報告しても、最終成果を確認する責任まで自動で移るわけではありません。調査レポートとコード変更を分け、利用者が確認する地点を残しておくことが重要です。

worktreeとタスク形態で衝突を減らす

READMEでは、各タスクをtreehouseが提供するクリーンなGit worktreeで実行し、backend=orcaの場合はOrca管理のworktreeを使うと説明されています。同じリポジトリで複数作業を並行しても、作業場所を分けることで変更の衝突を抑える設計です。成果の確認後に、設定された権限でPR、ローカルマージ、または報告書へつなげます。

タスクはshipとscoutの二つの形に分かれます。shipは承認された変更を納品し、scoutは受け入れ条件が独立調査を必要とする時に、単独の調査レポートを残します。調査と実装を初めから分ければ、まだ変更を認めていない段階でコードを触るリスクを下げられます。実際に何を変更してよいか、どこで人が承認するか、成果物がどのブランチへ入るかはプロジェクト設定で確認してください。

納品モードは権限の決定材料になる

firstmateは、プロジェクトごとにno-mistakes、direct-PR、local-onlyの納品モードを選び、任意で+yoloのマージ自律フラグを付けられるとREADMEに記載されています。名前から役割の違いは読み取れますが、README本文だけでは各モードの厳密な挙動を全て確定できず、詳細はdocs/architecture.mdへ委ねられています。

導入時は、モード名を安全保証として解釈しないことが大切です。最初は変更を外部へ出さないlocal-onlyの範囲で、作業ツリー、レビュー、報告の流れを確認します。direct-PRを使う場合は、PR作成が許可される条件と人のレビュー地点を定め、+yoloを付ける場合は自動マージの対象と戻し方を明示してください。設定したモード、実際に行われた操作、承認者を同じ記録へ残せば、想定と動作の差を追いやすくなります。

監督はイベントで起こす設計

READMEは、bashのwatcherが艦隊を監視し、対応が必要になった時だけfirst mateを起こす仕組みを、イベント駆動でトークンを消費しない監督と説明しています。検証済みの主要ハーネスにはターン終了時のバックストップがあり、作業中なのに監督が生きていない状態で盲目的に停止することを防ぐ、または後続処理を行うとされています。

状態はディスクとアクティブなセッションバックエンドに保存され、セッションを終了した後に次のセッションが調整を続ける構成です。これは再起動後の復帰経路を持つという設計説明で、無停止や成果の完全性を保証するものではありません。watcherが動いているか、対象タスクが終了したか、停止後にどの記録から復帰したかを利用者が確認できるようにします。監督が働かない時に変更作業を止める判断も、プロジェクト側で決めておく必要があります。

ハーネスとsecondmateを段階的に選ぶ

Quick Startの要件には、検証済みの主要エージェントハーネスとしてClaude Code、Grok、Pi、pi-signed、Codex、OpenCodeが挙げられています。GitとGitHub CLIを用意し、gh auth loginで認証し、選択したランタイムバックエンドのCLIと依存関係をそろえます。tmuxが参照デフォルトで、Claude Code、Grok、Piが同等の共同一次推奨、CodexとOpenCodeも検証済みだがハーネス固有の監督上の差があるとREADMEは説明しています。

大きな作業群では、永続的なsecondmateを選び、隔離されたfirstmateホームで動かす構成もあります。同じマシン、またはSSHで到達できる別ホストに、固有のFM_HOME、状態、プロジェクト、セッションロックを置けます。READMEは保護された更新と復旧を掲げ、到達できないリモートを勝手にローカルへ置き換えないと説明しています。まず一つのハーネスと一つの作業で挙動を確認し、リモート状態を増やすのは復旧手順を説明できてからにしてください。

RelayとMITライセンスの境界

オプションのRelayは、ローカルの.envペアリングトークンで有効にすると、XやDiscordの公開メンションへ返答し、チャットと同じライフサイクルで可逆的な依頼を処理します。READMEは、作業開始を認識し、真の節目と最終結果について7日以内に最大3件の公開安全なフォローアップを投稿できると説明しています。dry-runでは実際に投稿する予定の返答や却下をローカルへ記録できます。公開先、トークン、投稿内容の承認を先に分けるべきです。

素材取得時点では、既定ブランチはmain、アーカイブ状態はfalse、ライセンス識別子はMIT、4,279 stars、1,422 forks、791 open issuesと記録されています。MITの利用、変更、再配布の条件はLICENSE本文で確認できますが、保証、サポート、セキュリティ態勢、本番準備を約束するものではありません。firstmateを採用するなら、内蔵スキル、納品モード、監督、公開連携のどこまでを使うかを明示し、変更を伴う操作には人の承認を残してください。

編集部の結論

firstmateは、複数のコーディングエージェントへ仕事を分配しながら、利用者の窓口を一つに保ちたいチーム向けのエージェントディストロです。クリーンなGit worktree、可視セッション、shipとscoutのタスク形態、プロジェクトごとの納品モードを組み合わせますが、これは導入しただけで作業品質や安全性が保証される仕組みではありません。まずは許可された小さな調査をlocal-onlyで試し、どのハーネス、権限、セッション、マージ経路を使ったかを記録してから変更納品へ進んでください。

公式情報源

1. Official README
2. Project repository