Show HNでPaneflowを公開する
コードエージェントを起動することは、もう特別なことではなくなりました。ターミナルを開き、コマンドを入力すると、Claude Code、Codex、OpenCode、または別のCLIが作業を始めます。
問題は、それを複数起動したときに始まります。
あるエージェントはバグを直しています。別のエージェントはリファクタリングを準備しています。さらに別のエージェントはdiffをレビューしています。その横で開発サーバーが動き、テストが通ったり落ちたりし、それぞれのターミナルが違う部分の状況を伝えています。ある時点で難しいのは、エージェントを起動することではなくなります。どのエージェントが何をしているのか、どれが入力待ちなのか、どれが完了したのか、どのブランチで作業しているのかを把握することです。
Paneflowは、まさにこの問題から生まれました。複数のコードエージェントを、1つのローカルワークスペースの中で見える、操作できる、理解できる状態に保つためのものです。
完全なデモは
YouTubeでも見られます。
ローンチスレッドはHacker Newsにあります: 
Show HN: Paneflow。
ターミナルだけでは足りないことがある
私はターミナルが好きです。tmux、Zellij、Ghostty、Kitty、WezTermはどれも優れたツールです。SSH越しやリモートマシンで作業するときは特にそうです。
ただし、同じプロジェクトで複数のローカルエージェントを動かすと、問題は変わります。ターミナルのグリッドはプロセスを表示します。しかし、どのエージェントが考えているのか、どれが承認待ちなのか、どれが面白いdiffを出したのか、どれが別のエージェントの作業をやり直しているのかまでは教えてくれません。
ウィンドウが増えるほど、プロジェクトの状態を頭の中で再構築することになります。ターミナルを移動し、スクロールバックを読み直し、正しいディレクトリを探し、現在のブランチを確認し、またdiffに戻ります。一度なら大きな問題ではありません。主な働き方になると、負担になります。
Paneflowはエディタを置き換えようとしているわけではありません。多くの開発者がsplit、ウィンドウ名、ブランチの命名規則、短期記憶で手作りしている調整レイヤーを置き換えます。
コマンドごとのペインではなく、タスクごとのワークスペース
Paneflowでは、ペインは今でも本物のターミナルです。Claude Code、Codex、OpenCode、Grok Builder、またはシェルで動く任意のCLIを実行できます。
違うのは、ターミナルの周りにあるものです。
1つのタスクには、エージェント、テスト、開発サーバー、gitブランチ、diff、過去のセッションが含まれることがあります。Paneflowはそれらを同じワークスペースにまとめ、コンテキストを切り替えるたびに探し直さなくてよいようにします。
作業を分離したいときは、各タスクを専用のgit worktreeで動かせます。Reviewビューはそのdiffを横並びに表示し、1つのworktreeを1列として扱います。ウィンドウ、ブランチ、エディタを切り替えずに、各エージェントが何を作ったのか確認できます。
この構成は、2つのエージェントがコードベースの近い場所を触っているときに特に役立ちます。出力を開いたままにし、変更を比較し、何を残し、何を直し、何を捨てるかを判断できます。
調整はCLIインターフェースを通る
Paneflowで最も重要な賭けは表示ではありません。調整です。
このレイヤーをPaneflow Conductorと呼んでいます。現時点では、エージェントに公開するものは意図的にCLIインターフェースとローカルソケットを通します。GUIは、あなたが監視し、読み、任意のペインを引き継ぐ場所として残ります。
paneflow psは、実行中のペインとエージェントを実際の状態とともに一覧表示します。paneflow watchは、ターミナルを繰り返しポーリングするのではなく、hooksとevent busから送られる変更をJSONLとしてストリームします。エージェントは何が動いているかを見て、イベントを待ち、別のペイン向けのpromptを準備し、最後の送信はあなたの承認に任せることができます。
デフォルトでは、Paneflowはpromptを事前入力し、Enterを押すのはあなたです。Auto-submitはありますが、opt-inです。この選択は意図的です。同じプロジェクト内で複数のエージェントが動けるなら、人間のコントロールは見える場所に残るべきです。
エージェントは制御せずに読める
もう1つ重要なのが、組み込みのMCPサーバーです。list_panes、read_pane、search_paneという3つの読み取り専用ツールを公開します。
実際には、あるペインのClaude Codeが、別のペインでCodexが出したテスト出力を読むことができます。エージェントは修正案を出す前に、隣のターミナルでエラーを検索できます。あるツールの出力を別のツールにコピー&ペーストする必要が減ります。
境界は厳格です。このブリッジはペインに書き込めず、あなたの代わりにエージェントを操作することもできません。ターミナル出力は信頼できないものとして扱われます。エージェントのtranscriptやリポジトリには、敵対的なテキストが含まれる可能性があるからです。Paneflowはコンテキスト共有をより明示的にしますが、すべてのターミナルを開いた実行面に変えるわけではありません。
私が重視しているのはこの境界です。エージェントが盲目的に作業しないだけのコンテキストを与えつつ、セッション全体を静かに支配する力は与えない。
なぜネイティブアプリなのか
PaneflowはRustで書かれ、Zedの背後にあるUIフレームワークであるGPUIを使っています。この選択は単純な制約から来ています。エージェントは長時間、時には並列で動きます。それらを入れる場所は軽く保つ必要があります。
すでに重いプロセスを実行しているターミナルを、さらにElectronアプリで包みたくありませんでした。また、自分の作業がLinuxとWindowsをまたぐのに、macOS専用のツールにもしたくありませんでした。現在、PaneflowはLinux、macOS Apple Silicon、Windows x64向けのbuildを提供しています。macOS IntelとWindows ARM64はまだ出荷していません。
結果としてできたのはIDEではありません。CLIエージェントをすでに使いこなしている開発者が、すべての調整を手作業で行わなくて済むようにする、ローカルでオープンソースのワークスペースです。
次のマルチエージェント作業でPaneflowを試す
たまに1つのエージェントを起動するだけなら、今のターミナルで十分かもしれません。
複数のエージェントを並列で動かし始めると、問いは変わります。状態を読みやすく保ち、ブランチを分け、diffをレビューでき、コンテキストを共有できるようにしながら、どうやって制御を失わずにいるのか。
Paneflowが解こうとしているのは、まさにその問題です。
Paneflowをダウンロードし、プロジェクトを開き、2つのペインで2つのエージェントを起動してみてください。そのワークスペースが、当たり前だと思い始めていた認知負荷を減らすかどうかを見てください。