Brigade レビュー: 自分のマシンに置くマルチエージェント構成と Tideline メモリの設計

Brigade が埋めようとしている穴は「エージェント間の記憶の断絶」

多くのエージェントツールは、1 つのチャットセッションと 1 つのモデルを前提に組まれている。セッションをまたぐと文脈は消え、別のエージェントに仕事を渡すと、そのエージェントは前の会話を知らない。Brigade の README はこの点を「what one agent learns, the rest can use」と表現している。つまり、エージェントごとに記憶を分断せず、共有の長期メモリ Tideline に事実を蓄積し、そこから複数のエージェントが参照する構成を狙っている。対象読者は、自分のマシン上で複数のエージェントを協調させたい個人開発者や小規模チームである。README が繰り返し述べるのは、アカウント作成が不要で、SaaS が間に立たず、API キーは自分のマシンから出ないという点だ。クラウドのエージェントサービスに会話ログを預けたくないが、単一のローカル LLM ラッパーでは物足りない、という層に向けた設計だと読める。

org chart と Tideline: 何が共有され、何が分離されるのか

Brigade の中心にあるのは、エージェントを org chart に並べるという考え方だ。README によれば、エージェントはそれぞれ独立したワークスペースとクレデンシャルを持ち、ペルソナも別々で、相互に委譲 (delegate) できる。共有されるのは Tideline に蓄積された長期メモリで、README はこれを origin scoping、decay、hybrid (keyword + vector) recall を備えたエンジンと説明している。origin scoping は「どこで得た情報か」を記憶に紐づける仕組み、decay は古い記憶の重みを下げる仕組み、hybrid recall はキーワード検索とベクトル検索を組み合わせる仕組みだと読める。ここで注意したいのは、共有メモリと分離されたワークスペースが同時に存在する点だ。認証情報は分離されているのに、あるエージェントが学んだ事実は他のエージェントから参照できる。この非対称性は利便性の源であると同時に、記憶に何を書かせるかの統制が効かないと情報が広がりすぎるリスクにもなる。README はこの統制の詳細までは示していない。

インストールと最初の起動: install.sh が実際に何をするか

macOS と Linux では、README が次の 1 行を提示している。curl -fsSL https://brigade.spinabot.com/install.sh | sh を実行し、その後 brigade と打つ。README の記述では、このスクリプトは必要なら Node を導入し、sudo を要求しない。起動すると flicker-free なチャット TUI が立ち上がる。データは ~/.brigade/ ディレクトリにまとまり、README はこれを「you fully own」と表現している。ストレージは既定で小さな filesystem インストールで、自前の Convex データベースに切り替えることもできる。ここで確認できるのは、Brigade がブラウザも Electron も使わないターミナル前提のツールだという点だ。インストーラを curl でパイプする形式は一般的だが、スクリプトの中身を確認せずに実行する運用は避けたい。README にはインストーラの検証手順やチェックサムの記載はない。

API キーを持たない場合のログイン経路と、その依存関係

Brigade の README が強調する導入障壁の低さの一つが、API キーなしでも始められる点だ。Claude、ChatGPT、Copilot のサブスクリプションでサインインするか、すでに Claude Code や Codex CLI にログイン済みならそのログインを再利用できると書かれている。ブラウザを開かず、再認証も不要という説明だ。これはつまり、Brigade の認証経路が外部 CLI や各ベンダーのサブスクリプション認証に依存するということを意味する。ベンダー側が認証フローや利用規約を変更すれば、その経路は影響を受ける。README はこの依存関係のリスクには触れていない。API キーを直接渡す運用も当然できるが、その場合のキー保管の仕組みについて README は「your API keys stay on your own machine, never sent to a middleman」と述べるにとどまる。キーがどのファイルに、どの形式で保存されるかは記述からは確認できない。

brigade expose と bloody benchmark が示す公開前提の設計

Brigade には brigade expose というコマンドがあり、エージェントを外部から到達可能にする。README によれば、既定では Cloudflare を使い、bore、frp、sish といったオープンソースのリレーを自分で持ち込むこともできる。HTTPS はエッジで終端され、アカウント作成は不要で、秘密鍵が不可視の形で同乗し、部外者がアクセスすると 401 で弾かれるという説明だ。brigade expose stop で停止できる。もう一つの brigade bloody benchmark は、README の表現を借りれば「the one command that throws your crew to the wolves」で、エージェントを公開ネットワークに晒して耐性を見るという位置づけになっている。ここから読み取れるのは、Brigade がエージェントを外部に公開することを想定した作りだという点だ。ただし README は、公開したエージェントが何を実行できる状態になるのか、認可の範囲をどこで絞るのかを明示していない。公開前に何が露出するかを自分で確かめる必要がある。

ストレージモードの選択: filesystem と Convex で運用が変わる

Brigade は既定で filesystem ベースの小さなインストールとして動き、必要なら自前の Convex データベースに切り替えられる。README はこの 2 つを Storage modes: filesystem vs. Convex として節を分けている。filesystem モードの利点は、データが ~/.brigade/ 配下のファイルとして存在し、バックアップもコピーも通常のファイル操作で完結する点だ。Convex に切り替えると、複数エージェントからの同時アクセスや状態の一貫性をデータベース側で扱いやすくなる一方で、別途 Convex をホストして運用する責任が生じる。README には両モード間のデータ移行手順の記載が見当たらない。filesystem で始めて後から Convex へ移す場合、Tideline の記憶やエージェントのワークスペースをどう引き継ぐかは導入前に確認したい項目である。Raspberry Pi でもサーバーでも同じ crew が動くという記述はあるが、Convex を Pi 上で動かす際の要件は README からは読み取れない。

拡張の入口: MCP メモリサーバー、スキル、cron、チャネル

Brigade は単体のチャットツールではなく、拡張点を複数持つ。README が挙げるのは、スキルシステム、cron スケジューラ、サブエージェントの fan-out、MCP メモリサーバー、1,000 以上のアプリコネクタ、そして WhatsApp、Telegram、Slack、Discord、iMessage、BlueBubbles といったメッセージングチャネルだ。到達手段として watch、Meta のスマートグラス、Meta Quest も列挙されている。ここで判断材料として重要なのは、拡張点が多いほど設定ファイルとクレデンシャルの管理対象も増えるという当たり前の事実だ。エージェントごとに独立したワークスペースとクレデンシャルを持つ設計は分離の面では有利だが、その分だけ「どのエージェントにどのキーを渡したか」を追う必要がある。README は 1,000+ という接続先の数を示すが、個々のコネクタの成熟度やメンテナンス状況には触れていない。多数の連携先を抱えるプロジェクトでは、実際に使う数個に絞って検証するのが現実的だ。

向かないケースと、比較対象としての単一エージェント CLI

Brigade が適さない場面は明確にある。第一に、マネージドサービスの可用性保証や監査済みのコンプライアンス体制を前提とする業務システム。Brigade は自分でホストする前提で、README に SLA や認証の記載はない。第二に、単一のタスクを 1 つのモデルに投げるだけで足りる用途。org chart、Tideline、チャネル連携は、複数エージェントを協調させたいときに効く仕組みであり、そうでなければ設定対象が増えるだけになる。比較対象としては、Claude Code や Codex CLI のような単一エージェントのコーディング CLI が挙げられる。これらは 1 つのセッションと 1 つのワークスペースに閉じており、共有メモリも org chart も持たない。代わりに設定項目が少なく、認証も単純だ。Brigade は README にある通り、そうした CLI のログインを再利用できる。つまり両者は競合というより、単一エージェントで足りる作業と、複数エージェントに分けて記憶を共有させたい作業の間で使い分ける関係にある。

ライセンスとメンテナンス: MIT であることの意味と更新頻度

Brigade は MIT ライセンスで公開されている。MIT は商用利用を含めて比較的制約が少ないライセンスだが、無保証である点は変わらない。法的な判断はここでは扱わない。メンテナンス面では、リポジトリは archived ではなく、直近のリリースとして brigade-v1.37.1 (2026-09-09)、v1.37.0 (2026-09-02)、v1.36.1 (2026-08-31) が記録されている。約 1 週間から 2 週間の間隔でパッチとマイナーが続いており、活発に更新されていることが読み取れる。ただし更新頻度の高さは、設定ファイルや保存形式が変わりうることも意味する。~/.brigade/ 配下を自分で所有する設計だからこそ、アップグレード前にディレクトリごとバックアップを取る運用が現実的な防御になる。README には自動マイグレーションの有無や後方互換性のポリシーについての記載がない。バージョンを固定して運用したい場合は、npm の @spinabot/brigade のバージョンを明示的に指定し、更新を意図的に遅らせる判断もありうる。

編集部の結論

導入を検討すべきなのは、API キーや会話ログを外部 SaaS に預けず、自分のマシンかサーバー上で複数エージェントを動かしたい開発者である。特に、Claude Code や Codex CLI の既存ログインを再利用したい、あるいは Raspberry Pi のような小さなハードウェアで動かしたい場合に README の記述と噛み合う。逆に、マネージドな SLA やコンプライアンス認証を前提に業務システムへ組み込みたいチームには向かない。導入前に確認すべきは、~/.brigade/ のバックアップと移行の手順、filesystem から Convex へ切り替える際のデータ移行方法、そして brigade expose が既定で使う Cloudflare トンネルを自組織のポリシーが許容するかどうかである。

公式情報源

1. License: MIT
2. Project website
3. README
4. Releases
5. spinabot/brigade on GitHub