Paneflow: 複数の coding agent 現場を 1 つの native terminal workspace に収める

最近の AI coding tool には、かなりはっきりした分岐があると感じます。

1 つは「単体 agent をどこまで賢くするか」に集中する方向;
もう 1 つは「複数 agent が同時に動く現場をどう管理するか」を正面から扱う方向です。

もし今のあなたが、Claude Code や Codex を 1 つだけ開くのではなく、実装、review、実験、比較用に複数の agent を並べて使っているなら、後者の問題はかなり現実的です。

どの agent がまだ thinking 中で、どれが止まっているのか;
どの branch や workspace がどの terminal pane に対応しているのか;
すぐに人が引き継ぐべき output はどれか;
複数 agent の worktree diff をどう比較するか;
agent 同士が terminal 出力を参照するとき、権限境界をどう保つか。

今日取り上げたい ArthurDEV44/paneflow は、まさにこの種の問題に向けた project です。

GitHub repository page、release page、README を 2026-06-29 時点で確認すると、この repository は 25 stars、0 forks、作成日は 2026-04-01、直近の公開更新は 2026-06-29 です。主言語は Rust、UI は Zed の GPUI ベース、license は GPL-3.0-or-later。最新 release は v0.7.2 で、公開日は 2026-06-26 です。

Project overview

項目	内容
Repository	ArthurDEV44/paneflow
位置づけ	ローカル native の multi-agent coding workspace
Stars	25
Forks	0
主言語	Rust
UI 技術	GPUI
作成日	2026-04-01
直近の公開更新	2026-06-29
Latest version	v0.7.2
Release date	2026-06-26
License	GPL-3.0-or-later
対応 platform	Linux、macOS Apple Silicon、Windows x64

これは「agent chat UI」より、「作業現場の見取り図」を作る tool です

README の中心表現はかなり明快です。Paneflow は native GPUI workspace for running coding agents in parallel だと書いてあります。

この一文で本当に大事なのは、native でも parallel でもなく、workspace という部分です。

Paneflow は terminal を単に着飾るのでも、hosted agent runtime をもう 1 つ作るのでもありません。既に使っている CLI agent を本物の terminal に置いたまま、人が並列開発を回すときに必要な観測面を上から与えています。

本物の PTY pane をそのまま見せる;
agent が thinking、waiting、stalled、failed、done のどれかを見せる;
pane ごとの workspace と branch を見せる;
今どれが attention を要求しているのかを見せる。

多くの tool は「今、1 つの agent と会話している」という前提ですが、Paneflow は最初から「同じ project の中で複数 agent を監督する」ための視点で作られています。

raw terminal を残すのが、この project の大きな強みです

Paneflow の実務的な良さは、CLI agent を都合よく抽象化し過ぎないことです。

README がはっきり書いているように、

Claude Code、Codex、Gemini、opencode などを実際の terminal pane で走らせられる;
生の terminal output をそのまま見られる;
必要なら中断、引き継ぎ、再開ができる;

という構造になっています。

これはかなり重要です。

複数 agent を運用していると、問題を決めるのは上品な summary ではなく、たいてい数行の stderr、test log、diff、warning だからです。UI がそれを隠すと、人は「きれいに見えるが判断できない」状態に落ちやすい。

Paneflow はそこを避けています。

terminal を隠さない;
hosted service のように振る舞わない;
まず可視性を守り、その上で状態意味を足す。

この順番は、とても筋が良いと思います。

Attention Queue と Rosetta は、人間の監督コストを減らすための仕組みです

agent が増えると、起動より監督のほうがずっと難しくなります。

Paneflow が用意している sidebar、tab dots、desktop notifications、Attention Queue、Rosetta は、どれもこの問題に向いています。

pane ごとの状態をざっと把握する;
待機、実行中、完了、失敗を queue として整理する;
本当に人が介入すべきものだけを浮かび上がらせる;
何も起きていない pane を毎回手で巡回しなくて済むようにする。

並列 agent workflow でつらいのは、「agent が足りない」ことよりも「人間が 8 個の pane を脳内で同期し続けられない」ことです。Paneflow はその摩擦をかなり正面から扱っています。

CLI、JSON-RPC、flow.toml がつながっていて、編成レイヤーとして見ても面白い

Paneflow は GUI だけの tool ではありません。

README では paneflow CLI として、次のような操作例が示されています。

paneflow ps
paneflow read cargo-run --lines 100
paneflow watch --json
paneflow send codex-review "Review this branch and report risks"
paneflow wait --surface claude-impl --pattern "REPORT_DONE"
paneflow flow run examples/review-pipeline.flow.toml

この時点で、既にできることはかなり広いです。

pane 状態の確認;
特定 pane の output 読み取り;
agent への message 送信;
何かの状態や pattern を待つ;
宣言的な flow の実行。

特に flow.toml があることで、spawn、wait、send、capture、review を DAG 的に並べる発想が見えてきます。

つまり Paneflow は単なる multi-terminal shell ではなく、ローカル agent orchestration runtime の control surface に近づいています。

read-only MCP bridge の境界は、とても慎重で良いです

README の中で特に好感を持ったのが、ローカル read-only MCP bridge の扱い方です。

公開されている tool は次の 3 つだけです。

list_panes
read_pane
search_pane

要するに、agent は他の pane の状況を読めるが、直接操作はできません。

この設計はかなり賢いです。

複数 agent を協調させるとき、本当に必要なのは「情報共有」であって、「相互に書き込み権限を渡すこと」ではない場合が多いからです。Paneflow は共有コンテキストを与えつつ、制御権までは安易に広げていません。

さらに README では、agent に返す terminal output を untrusted data として包むと説明しています。これは prompt injection や誤誘導を意識した設計で、表面的な連携より一段深いところまで考えていることが分かります。

worktree diff review を 1 つの場所に置くのも、とても実戦的です

Paneflow は agent を並べて走らせるだけでなく、各 worktree の diff を横に並べて review する方向にも進んでいます。

これは多代理開発ではかなり重要です。

1 つの agent が主実装を担当する;
別の agent がより大胆な refactor を試す;
別の agent が test や review を補う;
最後に人が複数の結果を比較して、どれを採るか決める。

この流れでは、「同時に実行できる」だけでは足りません。「同時に成果を見比べられる」ことが必要です。

Paneflow が worktree diff、hunk navigation、review prompt、attribution、cost estimate をまとめているのは、multi-agent 開発では output comparison 自体が第一級の作業 だと理解しているからです。

Electron でも cloud でもなく、local-first を強く選んでいる

README を読むと、Paneflow は何度も自分の立場を明確にしています。

Rust + GPUI;
Linux、macOS、Windows の native build;
No Electron;
No hosted agent runtime;
No WSL required。

これはつまり、

「今使っている agent、shell、workspace、branch はそのまま使っていい。その上で、複数 agent 現場を観測しやすくする。」

という立ち位置です。

この割り切りのおかげで、Paneflow は通常の terminal emulator、単体 agent 向け AI IDE、cloud agent platform のどれとも少し違うポジションを取れています。

どんな人に向いているか

Paneflow は、次のような人にかなり向いています。

Claude Code、Codex、Gemini など複数の CLI agent を日常的に使う人;
branch や worktree をしっかり分けて作業する人;
agent の状態、output、review を 1 つの window に集めたい人;
orchestration を進めたいが、制御を完全自動にしたくない人。

逆に、「たまに 1 つの agent に軽い patch を頼むだけ」という段階なら、少し重く見えるかもしれません。

でも、

ある agent が実装;
別の agent が review;
別の agent が回帰確認;
人が調整、介入、最終判断;

という仕事の分け方が普通になってきているなら、Paneflow の問題設定はかなり刺さるはずです。

もちろん、まだかなり初期の project です

ただし、この project はまだ新しいです。

25 stars、0 forks、作成から数か月という数字は、初期段階の open source project であることを素直に示しています。良い面は、新しい発想と進化速度があること。注意点は、

interaction detail がまだ詰まり切っていない可能性;
script interface や workflow が今後も変化しやすいこと;
documentation と実装が継続的に整えられていく段階であること;

です。

なので、枯れた enterprise tool を探している人にはまだ早いかもしれません。一方で、「複数 coding agent の現場をどう管理するか」に真面目な project を追いたいなら、かなり面白い観測対象です。

まとめ

ArthurDEV44/paneflow の面白さは、対応している agent 名の数ではありません。

大事なのは、この project が置いている前提です。

raw terminal を残す;
並列 agent に意味のある状態を与える;
CLI と flow で orchestration を開く;
read-only MCP で共有と権限を切り分ける;
worktree review を同じ desktop workspace に持ち込む。

多くの tool がまだ「agent をどこで走らせるか」を議論している一方で、Paneflow はもっと実務的な問いを扱っています。

複数の agent を同時に抱えたとき、人間が先に破綻しないためには何が必要か。