Paneflow vs tmux
tmux はターミナルの内部で動作し、SSH 切断後もセッションを生かし続けます。Paneflow はそれ自体がターミナルです - GPU ネイティブで設定不要、ローカルのコーディングエージェント向けに作られています。ローカルのエージェントワークスペースには Paneflow を、SSH のデタッチ/再アタッチとヘッドレスマシンには tmux を使ってください。
プレフィックスなし、設定なし
Cmd/Ctrl+Shift+D で分割し、Alt+Arrow でフォーカスを移し、マウスでコピーします。Ctrl+B のコードも、メンテナンスすべき .tmux.conf もありません。
エージェントを並列実行し、どれが待っているか把握
16 のワンクリックランチャー (Claude Code、Codex、OpenCode など)、それぞれが専用のペインで、すべて同時に動きます。ライブのサイドバーが、どのエージェントが考え中か、どれがあなたの入力を待っているか、どれが完了したかを表示します。tmux にエージェントという概念はありません。
GPUネイティブのレンダリング
Zed のエンジン上で、低レイテンシの GPU レンダリングとなめらかなスクロールバックを実現します。tmux はレンダリングを、動作するターミナル任せにします。
両者の比較
tmux が最も強い領域（SSH、小さなフットプリント）と、Paneflow が最も強い領域（GPU レンダリング、エージェント UX）。
| Paneflow | tmux | |
|---|---|---|
| 学習コスト | 直接のコード、マウス、設定不要 | Ctrl+B プレフィックス + .tmux.conf |
| コーディングエージェント | ファーストクラスのペイン + MCP サーバー | 任意のバイナリとして起動 |
| レンダリング | GPU ネイティブ、低レイテンシのスクロールバック | ホストのターミナルに委譲 |
| ブランチ / 開発サーバーの認識 | ビルトイン | 自分でスクリプトを書く |
| SSH / リモートセッション | なし | あり（キラー機能） |
| ヘッドレス / GUI なし | なし | あり（任意の TTY） |
| スクリプティングの範囲 | JSON-RPC + 読み取り専用 MCP ペインツール | 深い CLI/control mode、hooks、formats |
| ライセンス / パッケージサイズ | GPL-3.0-or-later、リリース成果物は約 14-19 MB | ISC、小さなパッケージ（ソース tarball 約 0.75 MB） |
バージョン： Paneflow v0.3.8（2026年6月）。tmux 3.6b（2026年5月）。どちらも無料： Paneflow は GPL-3.0-or-later、tmux は ISC。
あなたに合うのはどちら？
ローカルでのエージェント作業には Paneflow、日々の作業がリモートまたはヘッドレスなら tmux を使ってください。
Paneflowを選ぶべき場合
- -ローカルで作業し、GPU レンダリングのスクロール、マウスで選択できるテキスト、ターミナルの中にターミナルを入れる構成ではなく 1 つのデスクトップワークスペースが欲しい場合
- -CLI コーディングエージェント（Claude Code、Codex、OpenCode）を実行し、専用ペイン、ブランチを意識したワークスペース、そしてそれらが読める MCP サーバーが欲しい場合
- -学習コストをゼロにしたい場合 - プレフィックスキーなし、コードの語彙なし、.tmux.confなし
- -開発サーバーのポート検出、セッション復元、そしてカスタムDSLの代わりにJSON設定が欲しい場合
tmuxを選ぶべき場合
- -リモートサーバーへSSHし、切断を生き延びるセッションが必要な場合（tmux本来のキラー機能）
- -ヘッドレスサーバー、コンテナ、Raspberry Pi で作業し、グラフィカルなデスクトップアプリが合わない場合
- -capture-pane、pipe-pane、send-keys、hooks、formats、control mode でターミナルを深く自動化している場合
- -すでに Ctrl+B に対する何年もの筋肉記憶と、鍛え上げられた .tmux.conf がある場合
tmuxが依然として勝つとき
率直な決定的要因です。以下のいずれかが日々のワークフローなら、tmux のほうが優れています：
- 1.SSH とリモートサーバー。 tmux のデタッチ/再アタッチは切断を生き延びます。Paneflow にはリモートセッションのサポートがなく、直近のロードマップにもありません。
- 2.ヘッドレスまたは組み込みシステム。 Paneflow は GPU とグラフィカルなセッションを必要とします。tmux は任意の TTY で動作します: Raspberry Pi、Docker、KVM コンソール、シリアルポート。
- 3.高度なターミナル自動化。 tmux には capture-pane、send-keys、pipe-pane などのコマンドに加え、hooks、formats、control mode があります。Paneflow の JSON-RPC/MCP 面はワークスペースとエージェント制御に焦点を絞っています。
- 4.最大限の移植性、または最小のフットプリント。 tmux は小さく、OpenBSD、FreeBSD、NetBSD、Linux、macOS、Solaris の TTY で動作します。Paneflow は現在 Linux と macOS 向けの GPU デスクトップアプリです（Windows リリースは進行中）。
よくある質問
Paneflow はローカル開発で tmux を置き換えられますか？
はい。Linux または macOS でのローカルなエージェント中心の開発なら置き換えられます。ただし SSH のデタッチ/再アタッチの直接的な代替ではありません。その用途では tmux を使い続けてください。
なぜPaneflowはtmuxのようにSSHセッションをサポートしないのですか？
アーキテクチャが異なるためです。tmuxはクライアントの切断より長く生き続けるサーバープロセスです - だからこそアタッチとデタッチが機能します。PaneflowはGUIアプリで、レンダリング面とターミナルの状態が同一プロセスです。tmux式のリモートセッションには、別個のサーバープロセスとワイヤープロトコルが必要になります - 現在のロードマップにはありません。
Paneflowで自分の.tmux.confを使えますか？
直接の移植はできません。Paneflowは異なるスキーマのJSON設定（paneflow.json）を使います。キーバインドの考え方は似ています（アクション名 + ショートカット）が、ほとんどのtmuxオプションには対応物がありません - Paneflowはターミナルの上で動作するマルチプレクサではないためです。スキーマリファレンスを参照してください。
tmuxで問題ないのに、なぜ乗り換えるのですか？
tmux で問題ないなら、tmux にとどまってください。Paneflow は、作業がローカルの CLI コーディングエージェントへと移り、GUI の使いやすさが重要になり始めた開発者のために存在します: ブランチバッジ、開発サーバーのステータス、マウスで選択できる diff、ホイールでスクロールできるスクロールバック、そしてエージェントが MCP 経由で検査できるペイン。これらのエージェントとローカルで作業しないなら、その乗り換えは混乱に見合いません。
Paneflow は tmux のように実行中プロセスを保持しますか？
いいえ。Paneflow はシェルの周囲のワークスペースを復元します: ペイン、レイアウト、作業ディレクトリ、カスタム名、スクロールバック。アプリを終了した後にシェルプロセスを生かし続けるわけではないため、長時間のビルドは終了時に止まります。tmux のプロセス永続化は、別個のサーバーとデタッチ/再アタッチモデルによるものです。
次のステップ
Paneflowを試す準備はできましたか？ 最新リリースをダウンロードするか、はじめにガイドを読んでください。tmuxに興味がありますか？ tmuxのGitHubリポジトリと man tmux は、2007 年以来の正典となるリファレンスです。