AI coding agent が強くなると、別の問題が目立ち始める。人は一つの editor でコードを書くだけではなく、いくつもの terminal、branch、worktree の進捗を見るようになる。ある Claude Code は UI を直し、Codex は test を追加し、Gemini CLI は docs を調べ、別の shell agent は review をしている。遅くなる原因は model の能力だけではない。どの agent がどこで何をしていて、どれが止まっているのかを一目で見づらいことだ。

今日見ておきたい h0x91b/dev-3.0 は、この摩擦をかなり正面から扱っている。README では “Mission control for the One Person Studio” と位置づけられている。IDE でも team 向け project management SaaS でもなく、個人 developer が複数の AI coding agent を同時に走らせるための cockpit だ。各 task は Kanban card、git worktree、tmux session、terminal を持つ。人間は task を切り、状態を見て、focus を切り替える。agent は隔離された環境でコードを動かす。

GitHub repository page、README、Releases、LICENSE、package.json、agent-support-matrix.md、公開 git history を 2026-07-29 時点で確認すると、h0x91b/dev-3.0 は 230 stars、23 forks。GitHub page の embedded data では repository created time は 2026-02-18 12:21:07 UTC。candidate discovery 時点の GitHub data では latest push は 2026-07-29 09:14:33 UTC。現在の default branch main の HEAD は 0e7d41e、commit time は 2026-07-29 09:14:31 UTC。主要言語は TypeScript、license は Apache-2.0。最新 GitHub Release は v1.40.0、published time は 2026-07-24 18:05:53 UTC。root package.json の version も 1.40.0 で、Bun、Electrobun、Vite、React、Tailwind が使われている。

プロジェクト概要

項目内容
リポジトリh0x91b/dev-3.0
位置づけ個人 developer 向けの multi AI coding agent cockpit
Stars230
Forks23
主要言語TypeScript
ライセンスApache-2.0
GitHub 作成時刻2026-02-18 12:21:07 UTC
最新 push2026-07-29 09:14:33 UTC
現在の default branch commit0e7d41e、2026-07-29 09:14:31 UTC
最新 GitHub Releasev1.40.0、2026-07-24 18:05:53 UTC
Version1.40.0
キーワードKanban、git worktree、tmux、CLI agents、remote browser mode、code review

解いているのは「agent が増えた後の見通し」

README の problem statement はわかりやすい。5 個以上の AI agent を別々の terminal、repo、branch で走らせると、context switching が遅くなり、状態を見失い、複数 agent が同じ repo を触って merge conflict を増やす。dev-3.0 の答えは、agent を新しい editor に閉じ込めることではなく、task ごとに隔離された作業環境を作ることだ。

ここが重要だ。多くの AI IDE は「人間は editor の中心にいて、agent は横にいる assistant」という前提を持つ。dev-3.0 はもう少し違う。「agent は複数 lane で走り、人間には dispatch panel が必要」という前提に近い。task card が Kanban board に入り、自動的に git worktree と tmux session を持つ。card から terminal preview、attention alert、現在の stage を見られるので、terminal tab を行き来しながら「あの task は終わったのか」と推測しなくてよい。

だから README は “not an IDE” を強調する。コードは VS Code や Cursor で開けばよい。dev-3.0 は editor を支配しようとしていない。気にしているのは、agent 実行の外側にある task、worktree、terminal、state、review、remote access だ。Codex や Claude Code にまとまった変更を任せる人にとっては、この外側の構造こそ日常の痛点になりやすい。

git worktree が並行作業の単位になる

multi-agent workflow で怖いのは、複数 agent が同じ checkout 内で互いの変更を踏むことだ。dev-3.0 は task card と git worktree を結びつけ、branch、dependency directory、dev server、terminal process を分ける。README には Copy-on-Write clone paths もあり、node_modules、.venv、build のような重い directory を worktree に素早く複製し、隔離の startup cost を抑えようとしている。

具体的には、一つの agent に bug fix、別の agent に test、三つ目の agent に review を任せるような場面で使いやすい。それぞれが独立 worktree を持ち、最後に人間が card ごとの diff と terminal state を見て、どれを review に進めるか決める。merge が常に簡単になるわけではないが、少なくとも複数 agent が同じ working directory を同時に壊す状況は避けやすい。

tmux は terminal session を持続可能な実行面にする。dev-3.0 は一つの task 内で複数 agent を並べて走らせることもでき、card hover で live terminal preview も見られる。CLI agent にとっては、terminal を開いて「どれが何をしていたか」を覚えておくよりずっと扱いやすい。

Codex、Claude Code、ほかの CLI agent を区別して扱う

agent-support-matrix.md には、Claude Code、Cursor Agent、Codex、Gemini CLI、OpenCode が並んでいる。session resume、permission mode、model selection、status hooks、skill injection などは agent ごとに違う。この matrix があること自体、dev-3.0 が単に README に “any agent” と書いているだけではなく、CLI agent 間の差を実装上の問題として扱っていることを示している。

Codex については、session id と tmux pane の記録を使って targeted recovery を行い、hooks で status transition を管理する説明がある。Claude Code についても status hooks、skill injection、rate-limit tracking が扱われている。全部の機能を使わなくても、この方向性は大事だ。multi-agent cockpit で難しいのは shell command を起動することではなく、「この shell はどの card、どの worktree、どの agent session に属するか」を長く追跡することだからだ。

README の install path も実務寄りだ。macOS では Homebrew cask、Linux では headless use を中心に dev3 remote で server 上に起動し、browser から full UI を開く。agent-driven install の text もあり、Claude Code、Codex、Gemini CLI などにインストール手順を処理させる形も想定されている。Windows は現在 roadmap なので、ここは platform boundary として見る必要がある。

Review も同じ cockpit に寄せる

feature list で見逃しにくいが、重要なのは PR review mode と built-in code review だ。remote branch を checkout し、task を review context に切り替え、syntax highlight 付き inline diff viewer、line-range comments、review を agent に戻す入口を提供する。

これは agent-heavy workflow と相性がいい。agent に code を書かせるのは前半で、後半は人間がいかに早く「方向がずれていないか」を判断するかだ。従来は PR を開き、diff を見て、terminal に戻って agent に再指示する。dev-3.0 はこれを task card の近くに寄せる。card で terminal を見て、diff に comment を残し、その feedback を agent に戻す。GitHub PR の代替ではなく、local orchestration の loop を短くするものだ。

もう一つ面白いのが bug hunters だ。branch diff に対して read-only agent を複数並行で走らせる。いかにも AI 時代の機能に見えるが、裏側の意味は単純だ。agent による確認も並行化するなら、task boundary と output archive が明確でなければ、ただ chat transcript が増えるだけになる。

Remote mode は便利だが、境界は理解したい

Linux での推奨 path は dev3 remote だ。remote dev machine や cloud VM 上で headless server を起動し、browser から UI を開く。README では access URL と QR を出し、Cloudflare quick tunnel も使えると説明している。local-only にしたい場合は --no-tunnel を渡す。remote machine で agent process、repo、worktree、dev server を動かし、人間は browser を control surface にする。この形は、server 上で agent を走らせる人にはかなり自然だ。

ただし注意も必要だ。coding agent と terminal を操作できる remote UI は、実質的には development machine の control plane に近い。README には token rotation や trusted device の説明があるが、production repository に使う前には、port、tunnel、SSH forward、machine permission、agent credentials の分離を確認すべきだ。dev-3.0 が目指しているのは個人速度の改善であり、enterprise access governance を代わりに完成させることではない。

注意点

第一に、project はまだ若い。2026-02-18 に作られ、stars は小規模の範囲にある。最近の commit は非常に多いが、大規模に検証済みの infrastructure と見る段階ではない。

第二に、理想的な user は狭い。README 自身も、editor に留まって code と Git を手で扱いたいなら agent IDE、SSO や seats や audit が必要な team platform なら team orchestrator を選ぶべきだと書いている。dev-3.0 は、一人が複数 agent を同時に開き、自分で dispatch する場面に向いている。

第三に、platform boundary がある。主な path は macOS と Linux で、Windows は roadmap だ。Linux の Homebrew install では root で走らせない注意もあり、server setup では最初に運用形を決める必要がある。

第四に、cockpit は engineering judgment の代替ではない。worktree、tmux、Kanban は混乱を減らすが、agent が書いた code はやはり build、test、review が必要だ。dev-3.0 が改善するのは並行管理であって、結果の正しさを自動保証するものではない。

まとめ

h0x91b/dev-3.0 が面白いのは、AI coding の bottleneck が「agent にどう書かせるか」から「人間が複数 agent の注意をどう管理するか」に移りつつあることを認めている点だ。もう一つの editor を作るのではなく、Kanban、git worktree、tmux、remote browser UI、review entry を一つの dispatch surface にまとめている。

たまに一つの Codex や Claude Code session を開くだけなら、dev-3.0 は重く感じるかもしれない。だが、すでに複数 agent、複数 branch、複数 remote task を同時に走らせていて、どの terminal が何をしているか忘れがちなら、観察リストに入れる価値がある。agent を賢くする tool というより、人間が並行中の agent に飲まれないための tool だ。