Daintree: Claude、Codex、Gemini を 1 つの Git worktree 指揮台に寄せる

最近のローカル開発環境は、だんだん小さな運用卓のようになってきています。

1 つの repository で front-end、back-end、test、dev server を同時に動かす;
その横で Claude Code、Codex、Gemini CLI のような agent を複数走らせる;
agent ごとに branch や worktree を分けたくなる;
それでも人間は review、context 補足、詰まりの回収を続けないといけない。

問題は、多くの tool がその一部分しか面倒を見ないことです。

terminal は「まだ動いている」ことは見せてくれるが、agent 群の統制まではしない;
worktree tool は分離に強いが、agent 状態や project switching までは統合しない;
一部の agent UI は chat entry point に近く、ローカル実行状態の control plane にはなっていない。

今日メモしておきたい daintreehq/daintree は、まさにそこを狙っています。

GitHub API、repository README、latest release page を 2026-06-29 時点で確認すると、この repository は 43 stars、6 forks、作成日は 2025-11-28、直近の公開 push は 2026-06-29 です。主言語は TypeScript、project site は daintree.org。最新 stable release は v0.20.0 で、公開日は 2026-06-28 です。README と source tree 内の package.json は、どちらも現在 Apache-2.0 を示しています。

Project overview

項目	内容
Repository	daintreehq/daintree
位置づけ	AI coding agents 向け delegation environment
Stars	43
Forks	6
主言語	TypeScript
主要形態	Electron desktop app
作成日	2025-11-28
直近の公開 push	2026-06-29
Latest version	v0.20.0
Release date	2026-06-28
対応 platform	macOS、Windows、Linux

これは「単体 agent の実行」より「agent 群の現場管理」を主題にしている

README では Daintree を、AI coding agents の habitat と表現しています。

この言い方はかなり正確だと思います。Daintree が解こうとしているのは、「もう 1 つ agent を起動する方法」ではなく、次のような運用上の現実だからです。

複数 agent のうち、どれが詰まっているのか;
どの agent がどの worktree を担当しているのか;
どの branch に commit や PR の気配があるのか;
どの session に人間の一言が必要で、どれは放置してよいのか;
project を切り替えても前の agent 群を秩序あるまま保てるのか。

多くの tool は「今、自分は 1 つの agent と向き合う」という前提ですが、Daintree は最初から「複数 agent を同時に管理する」前提で組まれています。

ここはかなり大きな違いです。

Git worktree は補助機能ではなく、並列運用モデルの骨格

README で繰り返し出てくるのが、複数 agent を別々の git worktrees に配置する、という考え方です。

これはとても重要です。

今の AI coding workflow で起きがちな問題は、model の能力不足よりも、作業場が相互汚染しやすいことだからです。

ある agent は API を触る;
別の agent は大きめの refactor を試す;
もう 1 つは実験的な案を走らせる;
人間は安定した workspace で最終 review をしたい。

これらを同じ directory に押し込むと、衝突はかなり起きやすいです。

Daintree は新しい VCS を作るのではなく、既に開発者が理解している git worktree を土台にして、その上に

可視化された worktree dashboard;
worktree ごとの agent session;
project switching と状態監視;
terminal、context、notification、action の接続;

を積んでいます。

その意味でこれは、単なる AI IDE というより worktree-native な multi-agent control console と見た方がしっくりきます。

実務的に効くのは、「broadcast、observe、take over」を 1 周つないでいること

Daintree の面白さは、agent をたくさん開けること自体より、並列協業で散らかりやすい一連の操作をまとめている点です。

README に挙がっている主軸は次の通りです。

Fleet Broadcasting: 1 つの prompt を複数 agent に同時送信する;
Worktree Dashboard: 各 branch / worktree の状態を一望する;
Context Injection: 必要な file や構造化 context を特定 agent に届ける;
Notification Center: 待機中か完了済みかを整理する;
MCP Server: agent から Daintree actions を直接呼ぶ。

ここで価値があるのは、人間を loop の外へ追い出すことではなく、人間が低価値な切り替え作業を繰り返さなくてよくすることです。

例えば、

同じ課題を 4 つの agent に投げて解法比較する;
どの agent が waiting で、どれが finished なのかをすぐ把握する;
大きな context を手作業で貼らずに、必要な相手へだけ送る;
action system 経由で、agent 側に一部の操作を任せる;

といった流れが自然になります。

これは「terminal tab を大量に開いて記憶で回す」状態より 1 段上です。

Daintree Assistant は新モデルではなく、既存 CLI 群の統率レイヤー

README にある Daintree Assistant の説明も重要です。

これは専用モデルを新たに抱え込む発想ではありません。むしろ明確に、

既に持っている agent CLI の上で動く;
Claude Code、Gemini CLI、Codex、GitHub Copilot CLI などに対応する;
worktree をまたいで新しい agent terminal を起こせる;
prompt 配信、進捗監視、context 注入、git 操作を扱える;

という書き方になっています。

要するに Daintree は、あなたが既に使っている agent を置き換えたいのではなく、それらの上に乗る macro-orchestration layer になろうとしているわけです。

この判断はかなり現実的です。

今足りないのは「もう 1 つ賢い agent」より、既にある agent workflow を編成し直す control surface であることが多いからです。

MCP と plugin system を安定面へ押し出しているのが、UI 以上に重要

トップ画面だけ見ると、Daintree は「複数 agent をきれいに並べる desktop shell」に見えるかもしれません。

ただ、最新の v0.20.0 の release notes を見ると、焦点はそこだけではありません。

特に目立つのは次の部分です。

plugin system が 1.0 contract に近づいている;
plugin が views、mcpServers、起動可能な agents を提供できる;
MCP surface が terminal status、screenshot、worktree resource lifecycle、write operations などで拡張されている;
project switching と terminal rendering の性能・信頼性が大きく改善されている;
per-terminal hibernation をやめて、background agent terminal の連続性を優先している。

これは、Daintree が単なる GUI で終わる気はなく、拡張可能な agent 作業環境の基盤 へ寄せていることを示しています。

plugin と MCP の面が安定すれば、将来の伸びしろは公式機能だけでなく、外部から何を差し込めるかにも広がります。

これは UI の派手さより本質的です。

普通の terminal aggregator と違うのは、扱う状態の意味が強いこと

README と release notes を読む限り、Daintree は terminal multiplexer をそのまま置き換えたいわけではありません。

従来の multi-terminal tool が強いのは、

layout;
session 保存;
split view;
keyboard shortcut による移動;

といった領域です。

一方 Daintree が扱っているのは、もう少し上位の状態意味です。

その terminal は agent なのか;
その agent はどの worktree に属するのか;
今は working か waiting か completed か;
MCP action に人間の承認が必要か;
project switching 後に何を保持すべきか。

つまり依存先は terminal でも、管理対象は単なる文字列出力ではなく agent orchestration metadata に近いです。

project switching と terminal recovery に大きく投資しているのは、痛点を正しく掴んでいる証拠

v0.20.0 の release notes では、

cold switch / warm switch;
view cache と host pool;
hidden terminal の描画;
alt-screen TUI の崩れ;
background agent の出力と復帰;

にかなり多くの行数が割かれています。

地味ですが、ここはむしろ信用材料です。

複数 agent、複数 worktree、複数 project を本気で回し始めると、一番つらいのは「機能不足」よりも、

全体が重くなる;
切り替えが固まる;
terminal 描画が崩れる;
background session が信用できなくなる;
画面上の状態表示が実態を反映しなくなる;

という種類の問題だからです。

作者が切り替え、復元、描画、waiting 状態のような地味な箇所に大きく手を入れているのは、この tool が既に実運用の摩擦に向き合っていることを示しています。

向いている人

Daintree は次のような人に向いていそうです。

複数の AI coding agent を日常的に使っている人;
複数 branch や worktree を並列で回す人;
複数 agent の成果を比較しながら review したい人;
ローカル agent workflow を観測可能な system に整理したい人;
MCP、plugin、automation の接続面に興味がある人。

特に、

Claude が実装;
Codex が patch と refactor;
Gemini が別視点の確認;
人間が review、merge、方向修正;

という形で仕事を分け始めているなら、Daintree の問題設定はかなり刺さるはずです。

もちろん境界もある

ただし Daintree も万能ではありません。

現在の README と公開情報から見る限り、これは主に

ローカル優先の desktop orchestration environment;
個人または小規模 team 向けの agent collaboration console;
git worktree と agent CLI を軸にした control surface;

です。

つまり、

cloud-hosted な agent platform;
汎用 remote cluster orchestrator;
production deployment platform;
Git や IDE そのものを完全に置き換える単独入口;

ではありません。

また、stars 数はまだ大きくなく、更新頻度は高いです。これはたいてい、

発想と進化速度が高い;
そのぶん interface や workflow も変わりやすい;

という両面を意味します。

完全に枯れた enterprise tool を求めるなら慎重に見るべきですが、次世代のローカル agent workspace を追いたいなら、むしろ今が一番面白い段階だと思います。

まとめ

daintreehq/daintree の面白さは、Claude、Codex、Gemini を同居させられること自体ではありません。

本質的なのは、今の AI coding 現場についてかなり正しい前提を置いていることです。

multi-agent 並列は珍しくなくなる;
worktree 分離はますます重要になる;
人間の review と調整は依然として中心に残る;
本当の摩擦は switching、observation、takeover、recovery にある。

Daintree は、その摩擦を worktree-native な desktop control plane に集約しようとしています。

たまに 1 つ agent を開くだけなら少し重いかもしれませんが、既に複数 agent、複数 branch、複数 project をさばき始めている人には、かなり真剣に追う価値のある project です。