tmux は生き残るが、見える形は消える
tmux は消えない。ただし、人間がペインを直接見て操作する形は後景に退く。Claude Code と Codex が、共通の tmux や herdr 基盤上で差し替え可能な実行エンジンになる未来を考える。
1. 主張
私は、ターミナルは生き残ると思っている。ただし、人間が今と同じ見方でターミナルを見続けるとは思っていない。
これは、「ターミナル」を「自分の手で直接操作するもの」と捉える場合にだけ矛盾して聞こえる。エージェントを使った作業では、ターミナルはプロセスの入れ物であり、永続する作業台であり、復旧のために戻れる場所になりつつある。これらの役割は残る。変わるのは、それを誰が操作するかである。
短く言えば、こうだ。
tmux は生き残るが、見える形は消える。
見える形とは、私がペインを眺め、どのエージェントが詰まっているかを覚え、どのペインが返事すべきかを判断し、次の経路選択コマンドを打つ部分だ。そこはすでに、人間が担当するには細かすぎる仕事になっている。永続する形とは、ターミナルプロセスが動き続け、セッションに再接続でき、出力を検査でき、エージェントが普通の開発環境の中で実作業を進められる部分だ。
その永続する形は消えない。むしろ、より多くの仕事がそこへ移っていく。問題は、人間がその層に座り続けるべきかどうかだ。
前の記事では、なぜ複数エージェントなのか を扱った。ここでは一段下がって、複数エージェントを載せる実行基盤を見る。続く記事では、エージェントを使った作業の背後にある二つの状態機械 と、個人用コンピューターの中の会社 を扱う。
また、それは目の前のノート PC に置かれている必要もない。tmux が価値を持つのは、個人の機械、自宅サーバー、遠隔ホストのどれでも動かせて、机、ノート PC、スマートフォンの間を移動してもセッションが安定した作業場所として残るからだ。この可搬性があるから、見えているペインの並びは後景に退ける。保存すべき対象は、今触っている画面ではなく、エージェントが使い続けられるセッション付きの実行基盤である。
2. Claude Code と Codex の位置づけ
Claude Code と Codex は、今でもターミナルを入口にしたツールとして表に出ている。現時点ではそれが自然だ。リポジトリ、シェル、テスト、エディタの習慣、ローカルの認証情報はすでにそこにある。だから、ターミナルは最も抵抗の少ない入口になる。
だが、Claude Code と Codex を並べて使うと、別の方向が見えてくる。人間が欲しいのは二つのターミナル製品ではない。各段階に最も合う実装担当へ、できるだけ少ない手順でアクセスすることだ。
私の予測では、両方のツールを本気で使う人は、それらを別々の作業場所として扱わなくなる。tmux、herdr、あるいは同じように永続する基盤の上に、両方を載せるようになる。すると Claude Code と Codex は、その基盤の背後にある、相互に差し替え可能な実行エンジンになる。振る舞いの個性は残る。ある瞬間には片方のほうが向いているかもしれない。だが、作業台は今どちらが動かしているかに依存すべきではない。これは経済面と運用面の保険でもある。価格、契約条件、トークン予算、利用制限、可用性、モデル適性は、ある瞬間に最適なエンジンを変える。
この予測が合っているなら、人間に見える面は、より単純な形へ畳まれ始める。
- 意図と状態を伝えるチャット
- 素早く委任するための音声入力
- レビューのためのファイルビューアと差分表示
- 成果物が視覚的な場合の画像とスクリーンショット
- 遠隔承認のためのブラウザとスマートフォン画面
エージェント CLI は下に残ってよい。各 CLI の強み、ローカル状態、認証、モデル固有の挙動も残せる。しかし人間向けの層は、「どの CLI に入力しているか」ではなく、「自分がどの判断を下す必要があるか」になる。
その世界では、Claude Code と Codex はターミナルタブを奪い合う二つのアプリというより、ローカルな組織の中にある二つの部署に近い。見るべき対象は、今どの部署が稼働しているかではなく共通基盤になる。
3. herdr が示す方向
だから herdr は興味深い。ターミナルを消すのではなく、ターミナルの役目を変える。ホームページでは、自分自身をエージェント多重化器と説明している。群れ全体のための一つのターミナルであり、コーディングエージェントが実際のターミナルで動き、ノート PC を閉じた後もサーバー上で生き続ける、というものだ。概念ドキュメント でも同じ点を構造的に説明している。作業空間はタブとペインを含み、ペインは実際のターミナルであり、エージェントは blocked、working、done、idle、unknown などの実行時状態を持つ、認識されたプロセスである。
これは、単にきれいなターミナル画面というだけではない。注意の単位を変える。
従来の tmux は、ウィンドウとペインを管理するよう私に求める。herdr は、作業空間、エージェント、状態を管理するよう求める。セッション状態ドキュメント は、生きたままの切り離し、スナップショット復元、ペイン履歴の再生、エージェントセッションの復元、生きたままの引き継ぎを分けている。この区別は装飾ではない。エージェントを使った作業は、値を返して終わる単一コマンドではない。状態、出力、文脈、復旧経路を持つ、長く走るプロセスだからである。
主張は「herdr が tmux を置き換える」ではない。あるユーザーにとってそうなるかもしれないし、ならないかもしれない。より強い兆候は、ターミナル多重化がエージェント運用を中心に再定義されつつあることだ。残す対象は、単なるペイン配置ではなく、復旧可能な状態を持つエージェント群になる。
これにより、エージェントのブランドの役割も変わる。作業空間、ペイン、セッション、引き継ぎ、成果物がモデルクライアントの外側で安定しているなら、Claude Code から Codex へ切り替えることは、オフィス全体を移すより実装担当を割り当て直すことに近い。継続性は基盤に属し、単一 CLI には属さない。実用上の利点は、コスト、利用枠、障害、適性に応じて担当エンジンを変えても、作業状態を作り直さなくて済むことだ。
ターミナルは基盤として残る。見える対象はエージェントになる。
4. postman が示すもう一つの面
ローカル側の対応物が tmux-a2a-postman である。herdr とは逆の姿勢を取る面がある。ターミナル作業空間になろうとはしていない。tmux ペインの周囲にある薄い調整層として残る。
README はその形を素直に説明している。役割と引き継ぎの辺は postman.md に置かれる。デーモンは一致する tmux ペインタイトルの間でローカルメールを配送する。システムは受信箱、既読、dead-letter という配送不能レーン、返信必須、journal という履歴台帳、projection という状態投影、ペイン状態を見える状態に保つ。postman は境界に慎重である。完全なエージェント実行基盤ではなく、広い作業エンジンでもなく、tmux やエージェント CLI の代替でもない。
その境界がツールを有用にしている。tmux はターミナルプロセスを所有し続ける。postman は、それらのプロセスの周囲にある責務台帳を所有する。誰が何を依頼したか、どの返信がまだ必須か、どの依頼が満たされたか、どの作業がレビューや承認に依存して詰まっているか、という台帳だ。メッセージの通り道ではあるが、価値があるのは、あるペインのターミナル履歴を越えて残る責任状態である。
人間向けダッシュボードは表面である。運用担当が読むべきなのは、その下にある状態だ。メッセージが配送された。返信が必須である。待機中の依頼がある。依頼が満たされた。メッセージが dead-letter に入った。これらはターミナル履歴から感じ取る雰囲気ではない。配送の事実である。
これも同じ予測の別の形だ。tmux は生き残るが、人間が見えるペインの並びを記憶で操作する必要はなくなるべきだ。
5. スマートフォンが本当のインターフェース試験である
この予測を試すいちばん簡単な方法は、机から離れることだ。机が必要なままなら、ターミナルはまだ背景に退いていない。
エージェントを使った作業がなおノート PC を開き、正しいターミナルウィンドウを探し、ペインを検査し、正しいプロセスに入力することを必要とするなら、ターミナルはまだ利用者向けインターフェースである。スマートフォンから承認、振り分け、確認できるなら、ターミナルはインフラになっている。
だから私は、エージェントターミナルをめぐるスマートフォンと非公開ネットワークの実験に注意している。
herdr の公式ドキュメントは、ローカル利用と SSH 経由の遠隔接続を強調している。遠隔アクセスドキュメント は、バックグラウンドサーバー、ローカルクライアント、SSH 経由の遠隔接続、直接のターミナル接続、読み取り専用のターミナル観察者を説明している。socket API は、スクリプトやエージェントが必要とする制御面を示している。作業空間の作成と注目先の変更、タブとペインの管理、出力の読み取り、入力の送信、エージェントの起動、状態待ち、イベント購読である。
私が確認できる範囲では、Telegram 対応は herdr の中核契約というより、herdr の周辺にすでに現れている。herdr-remote は、herdr エージェントのスマートフォン、メニューバー、Telegram 監視と承認をうたっている。ccgram は、Claude Code、Codex CLI、Gemini CLI、tmux、herdr のための Telegram 連携役と説明している。この区別で根拠の範囲が保たれる。公式の中核はターミナル作業空間と API であり、周辺ツールはすでにスマートフォンと Telegram の面へ手を伸ばしている。
Tailscale も、現在の私の根拠では似ている。隣接するローカル道具では強く確認できる。markdown-remote-viewer には、Tailnet 越しに Markdown を配信する明示的な --tailscale モードがある。herdr 自体について、私が確認した公式の遠隔利用の筋道は SSH 経由の接続であり、Tailscale への直接対応ではない。ただし方向は同じだ。非公開ネットワークからの到達性とスマートフォンで読めるレビュー面は、ターミナルをバックエンドに変える。
永続する論点は、特定のネットワーク製品ではない。場所からの独立性である。実行基盤がサーバー上で動き、SSH や非公開ネットワークから到達できるなら、作業自体を動かさずに、ほぼどこからでも確認と承認ができる。tmux は長い間その性質を持っていた。herdr も、ターミナル作業空間をクライアントが接続できるサーバー支えのものとして扱うことで、同じ道をたどっている。
スマートフォンに装飾された操縦席は要らない。必要なのは小さな判断の集合である。
6. AI サブスクリプションは自分の作業環境を動かす
この未来には、魅力的なクラウド完結版がある。すべてのエージェントがベンダー管理の遠隔作業空間で動き、手元の機械は薄いブラウザタブになる、という形だ。到達性の問題は解ける。ただし、個人の作業を個人の作業にしている状態から、作業台が離れすぎる危うさもある。
それは多くのチームにとって有用だろう。しかし、それが全体像ではない。個人の作業では、強い対抗原則が残ると私は見ている。
AI サブスクリプションは、利用者自身の作業台を動かすべきだ。
より正確には、個人自身の運用環境に対して動くべきである。それはノート PC、デスクトップ、自宅サーバー、本人が管理する遠隔マシンのどれでもよい。理由はローカルマシンへの郷愁ではない。状態である。この組織的な角度は 「個人用コンピューターの中の会社」 で広げている。ここでの短い版は、作業台はユーザー自身のファイル、認証情報、プロジェクトのチェックアウト、作業習慣の近くに残るべきだ、ということだ。
おそらく形は混合型になる。モデルは遠隔にあるかもしれない。作業台はローカル、または本人が管理する場所に残る。対話の層はブラウザ、スマートフォン、テキスト、画像、音声になる。非公開ネットワークは、作業台をベンダー管理にせず到達可能にできる。ターミナルは実行基盤として残る。
7. 価値を失うもの
このモデルでは、視覚的な装飾が担う価値は小さくなる。
設計にはまだ役目がある。価値を失うのは、装飾された操作盤である。人間がもう機械を直接運転していないなら、あらゆる配管や歯車を見せる美しいダッシュボードは希少なものではない。
希少なものは、正しいエスカレーションである。
- 何が私の判断を必要としているか
- 何が終わったか
- 何が失敗したか
- どの根拠を確認すべきか
- 何をシステムが私なしで安全に判断できるか
その表示は、作業を生かし続けるターミナルに似ている必要はない。スマートフォンのレビュー画面、遠隔ブラウザ画面、小さな判断用の受信箱は、同じ tmux セッションの上に座り、今確認すべき引き継ぎだけを見せられる。機械室には到達可能なままでよい。だが標準面は判断の境界になる。何が変わったか、何に承認が必要か、どの成果物を確認すべきか、である。
誰かがプロセスを動かし続ける必要があるので、ターミナルは生き残る。
その誰かがますます AI エージェントになるので、見えるターミナルは消えていく。