firstmateの使い方——話しかけるのは1体だけ、作るのは別々の作業場にいる船員たち
AIエージェントを3体並べたら、3つの画面を自分が見張る羽目になった。
これ、ありませんか？
firstmateは、その「見張る人」を1体に減らすためのオープンソースです。今月2,049スター増（GitHub Trending月間・2026年9月2日取得）。作者はkunchenguid氏、ライセンスはMIT。
READMEの一言に、この道具の性格が出ています。Talk to one agent. Ship with a crew. 1体に話しかけて、船員たちに作らせる。
この記事では、firstmateの使い方を「何者か・入れ方・話しかけ方・止め方」の順で書きます。うちではまだ本番に入れていないので、READMEと設計文書から読めることと、うちならこう試すという提案を分けて書きます。
出典はGitHub kunchenguid/firstmateのREADMEと、同リポジトリのdocs/architecture.md。2026年9月10日に本文を確認しました。
firstmateは何者か——モデルでもCLIでもなく「配布物」
READMEは、最初に「何ではないか」を書いています。
firstmateはモデルでも、ハーネスでも、CLIツールでもない。指示書・スキル・道具・方針・状態の置き方をまとめた、持ち運べるフォルダだと。
つまり、Claude CodeやCodexのような「動かす側」は別にある。firstmateは、その上に載せる役割分担の台本です。
台本の登場人物は3つ。あなたが船長。あなたが話しかける相手が一等航海士（first mate）。実際に作業するのが船員（crewmate）。
READMEの流れはこうです。船長は一等航海士とだけ話す。一等航海士が依頼を船員に振り分け、船員はそれぞれ別のセッションと別のgit worktreeで動く。できあがったPRや、承認済みのローカルマージ、調査報告が、一等航海士から船長に戻ってくる。
firstmateの使い方で、先に知る2つの仕組み
入れる前に、2つだけ仕組みを知っておくと迷いません。
1つ目、作業場が別々であること。
READMEは「使い捨ての作業ツリー」と呼び、船員ごとにきれいなgit worktreeを用意して、並列作業の衝突を防ぐ、と書いています。設計文書にはさらに強い言い方があります。船員は、あなたのプロジェクトの本体を意図的には触らない。
冒頭の「3体が同じファイルを取り合う」は、ここで構造的に消えます。
2つ目、見張りがトークンを使わないこと。
設計文書によると、見張り役はbin/fm-watch.shというbashのスクリプトで、船員たちの様子に「眠って」いて、何か対応が要るときだけ一等航海士を起こす。AIをずっと回して監視するのではなく、bashが分類して、必要な時だけAIに渡す。
いや、AIが見張ったほうが賢いでしょ？
そう思うんですが、見張りは1日中動くので、AIにやらせると費用が止まりません。ここをbashにしたのが、この設計のいちばん現実的なところだと私は思います。個人的には、複数エージェントの道具を選ぶ基準はここに置きたい。
STEP1: 入れ方は3コマンド——前提は3つ
READMEの手順です。
前提が3つ。検証済みのハーネスが1つ（Claude Code、Codex、Cursor Agent CLI、Pi、Grok、OpenCodeなど）。GitとGitHub CLIで、gh auth login を済ませていること。tmux（既定。herdr、zellijなどは実験的）。
入れるのは、これだけ。
gh auth login
git clone https://github.com/kunchenguid/firstmate
cd firstmateあとは、そのフォルダで自分のハーネスを起動します。Claude Codeなら claude。
READMEの例は、話しかけ方まで書いてあります。
「ahoy! GitHubのプロジェクトxyzを見て、不安定なログインのテストを直して、ダークモードを足して」
すると一等航海士が、隔離された作業者を2つ立てる。数分後、「PRができました、船長」と、URLと危険度とCIの結果が返ってくる。「merge it」と言えば、マージまで進む。
STEP2: 依頼には2種類ある——shipとscout
ここは、使い始めてから効くところです。
READMEと設計文書は、依頼を2種類に分けています。
shipは、変更を届ける依頼。プロジェクトごとに3つのモードがあり、no-mistakes は検証の工程を全部通す、direct-PR は検証を省いてPRを開く、local-only は承認されるまで手元に留める。いずれにも +yolo を付けられます。
scoutは、調べるだけの依頼。設計文書には、調査報告を data/<id>/report.md に残し、決してpushしないとあります。
で、大事なのは、この2つとモードは受付の時点で明示されること。設計文書は「作業者が届け方の厳しさを推測することはない」と書いています。
うちなら、最初の1週間は全部scoutで試します。私の意見では、ここを飛ばすと「AIが勝手にpushした」という最初の事故が起きやすい。pushしない依頼だけで、振り分けと報告の形に慣れる。shipは、報告の中身を信用できてから。
STEP3: 止め方と残し方——状態はディスクにある
最後に、止めるとき。
READMEは「再起動に強い」と書いています。すべての状態はディスクとセッション側にある。だから、一等航海士のセッションを閉じても、船員の作業や記録は消えない。
組み込みのスキルが5つあります。/afk は離席モード、/ahoy は経過の要約、/bearings は艦隊の状態のまとめ、/updatefirstmate は更新、そして /stow がセッションで得た知識をディスクへ書き出す。
設計文書によると、/stow は船長の好みを data/captain.md、艦隊の注意点を data/learnings.md へ振り分けます。意図的にリセットする前に呼ぶもの、と。
つまり、止め方は「閉じる」ではなく「/stow してから閉じる」。ここを飛ばすと、会話の中にしか無かった学びが消えます。
firstmateの使い方を、一言で
話しかけるのは一等航海士1体。船員は別々のworktreeで動き、本体は触らない。見張りはbashで、必要な時だけAIを起こす。依頼はscoutから始めて、shipはあとで。閉じる前に /stow。
今日、5分でできること。
gh auth status を打って、GitHub CLIの認証が生きているか見てください。生きていれば、前提の3つのうち1つは済んでいます。残りはtmuxと、いつも使っているハーネス。それがそろった日に、cloneして ahoy と言ってみる。
▶ 関連記事: oMLXの使い方——Macの中でモデルを常駐させて、続きの会話を計算し直さない
▶ 関連記事: RustDeskの使い方を、自分のサーバーで完結させるまで——hbbsとhbbrが何をしているか
OSSを実務で活用するための6大特典
OSSの選び方や、AIエージェントを複数動かすときの分け方を整理したい方へ。活用を進めるための6大特典をご案内しています。
