別の CLI にタスクを渡したいのに、渡す先がない

この段階でできたのは tmux-relayです。使える tmux pane にコマンドを送り、task、role、完了シグナル、結果を読み取る経路を残します。tmux pane は「マウスで切り替えて見るウィンドウ」から「プログラムから呼び出せる worker」になりました。前の記事で名前をまだ付けていなかった dispatcher が、これです。

自分で書くことになったのは、利用枠がしょっちゅう底をついていたからです。主に使っていたのは Claude Code で、複数社のモデルを契約し、いくつかの API も使っていましたが、それでも足りませんでした。当時、最初に思ったのはもっと強いモデルに替えることではなく、「なぜこうした雑務がメイン agent の context を占めるのか」でした。当時の context window は 20 万 token で、1M が使えるようになったのは後のことです。大量の grep 結果をメイン agent に一字一句読ませるのは無駄が大きすぎました。

Claude Code が sub-agent を出した頃、「仕事を外に渡す」ことが初めて具体的になりました。ただ、sub-agent は Claude 内部の worker であり、Codex やほかの CLI には送れません。ひととおり探しても、そのまま使える方法は見つかりませんでした。CLI をまたいでタスクを振るには、実際に動いている terminal にタスクを届け、完了したかどうかと結果の場所を知る仕組みがまず必要でした。

worker は動くようになったが、互いに話せない

この段階で補ったのは session-channel（前の記事でも書いたものです）。pane 同士がこれを通じて直接やり取りでき、毎回同じ会話に伝言を戻す必要がなくなりました。

tmux-relay タスクを振れるようになると、すぐ次の問題が出てきました。ある agent が仕事を終えても、別の agent に伝える場所がありません。Claude の Team Agent は同じモデルの内部でしかメッセージを渡せず、Codex が終えた仕事を Claude 側で受け取れませんでした。

手元のマシンは忙しいのに、ほかの 2 台は空いている

この段階で補ったのは fleetで、マシンの能力に応じてタスクを振り分けます。GPU を積んだ Windows には TTS や ASR のような学習・推論の仕事を任せ、古い Intel MacBook には軽いタスクだけを渡し、普段の主力は Mac mini M4 に残します。

タスクの割り振りと pane 間通信が動くようになってから、次に詰まったのはモデルではなくマシンでした。手元のマシンが agent を動かして熱くなっている間、ほかの 2 台はほとんどの時間空いていました。当時見た複数 agent 用ツールの多くは、同じマシンで動かすことを前提にしていました。

worker の定義は fleet を補ってようやく揃いました。最初は tmux 内の別の pane だと思っていましたが、別のモデルや session、さらには別のマシンにもなり得ると分かりました。ここでいう worker は、前の記事の「安いモデルを動かす層」より広い意味で使っています。

同じタスクでも、CLI ごとに起動方法が違う

この段階で補ったのは cli-rosettaです。各 CLI の違いを一つの宣言的な registry にまとめ、2026 年 8 月までに 10 種類を登録しました。Claude Code、Codex、Copilot、Antigravity、Qwen Code、Kimi Code、OpenCode、Hermes、Pi、Grok です。

worker の種類が揃うと、面倒は別の方向に移りました。タスクは送れるのに、同じ仕事を Codex と Copilot に渡す場合では、headless の起動方法、モデルの指定方法、使えるツールがすべて違います。実行先を替えるたびに、ドキュメントを読み直す必要がありました。

cli-rosetta この registry は後に plugin としてまとめ、Codex CLI の plugin 仕様に合わせて形式を埋めました。求められる metadata は自分がもともと考えていたものよりずっと充実していて、表示名、分類、機能一覧、ユーザー向けの既定の prompt まで書く必要があります。つまり「これは結局何ができるのか」をはっきり説明せざるを得ません。書き終えると、同じ skill と command を Claude Code と Antigravity にもインストールできました。ここまでの段階で初めて自分で形式を発明せず、他人が決めた仕様に従いました。思った以上に手間が省けました。

同じ種類のタスクが繰り返され、そのたびに手作業で組み立てる

この段階で補ったのは agentctlです。一回限りの目標と再実行できるフローを分け、checkpoint、予算上限、権限ゲート、独立した judge を加えました。独立した judge は、「本人が終わったと言った」だけを検証の根拠にしないためです。

タスクを振る回数が増えると、同じ種類の仕事が繰り返し現れ、そのたびに手作業でフローを組むのは割に合わなくなりました。この部分を補った頃は workflow という概念が議論され始めたばかりで、そのまま使えるものは見つかりませんでした。

最近の行き詰まりでは、先に既存のものが見つかった

この段階では自分で作りませんでした。2026 年 8 月に調べたときには、前の 4 回より既存のツールが増え、自分が補っていたものより包括的に解決していました。そこでアイデアを借り、今あるものに取り込むことにしました。

Claude Squad tmux session と git worktree で複数のタスクを分離し、TUI でまとめて管理・切り替えできます。Herdr 複数の coding agent を実際の terminal pane に置き、前景の process や画面内容など複数のシグナルから blocked、working、done、idle を判定します。Orca worktree、agent terminal、diff、browser をすべて同じ task の中に収め、完全な Agent Development Environment にしています。Claude 公式も 2026 年にクラウドの remote モードを出し、仕事を先方のマシンで直接動かせるようにしました。

タスクを分離したい、状態を見えるようにしたい、パソコンから離れても再接続したい。Claude Squad、Herdr、Orca は、これらをすでに解決しています。agent の使い方にはもともと限られたパターンしかないので、詰まる場所も似てきます。今回は運よく、詰まったときには誰かがすでに作り終えていました。既存のツールを見つけてから問うべきことは、「どこをそのまま使えるか」だけになりました。汎用的な terminal の分離、pane の状態検出、遠隔からの再接続は、自分で書き直すより他人の成果を使うほうが割に合います。一方、自分の仕事の進め方に密着したルール、つまりタスクを異なるモデルにどう振り分けるか、CLI 間で意味をどう揃えるか、長いタスクをどう検証して再開するかについては、まだぴったり合うものを見つけられていないので、当面は自分のものを残します。

タスクの割り振りについては、もう一度詳しく調べました。2026 年 8 月に GitHub で検索すると、名前に agentmux を含む repo は 50 以上、 amux を含むものは 80 以上ありましたが、互いに無関係です。その中で thevibeworks/amux の README には動機が書かれていました。claude -p が追加課金に変わったため、実際の tmux session で対話型 TUI を動かし、使用量を元のサブスクリプション枠内に収めるというものです。この記事の冒頭で詰まったのと同じ問題でした。実際に開いたもののうち、タスクの割り振り、task の記録、完了の検出、結果の読み取りがすべて揃うものは、いずれもスターが数十個以下で、半年以上更新のないものも複数ありました。この分野で本当にスターの多いものは、実は別のことをしています。prompt で動く agent が自分でキーボードを操作するものもあれば、逆に AI が画面を見ながら人間に指示するものもあります。

だから今回は、一式を作り直さず、アイデアを借りました

私は tmux-webui に二つのものを補いました。着想元はそれぞれ Herdr と Orca です。Herdr からはツリー状の pane 状態を借り、workspace、tab、pane の階層を並べて、誰が作業中で、誰が人の確認を待ち、誰が完了したかを、個別に開かず一目で分かるようにしました。Orca からは dash window を借り、agent deck と session log を同じ画面に置いて、タブを切り替えずに済むようにしました。tmux-webui もともとの役割は一つだけです。tmux pane をブラウザに持ち込み、ホストの前にいなくても元の端末画面を見られるようにすることでした。

Orca と違うのは、どの方法を選んだかです。Orca は完全な開発環境を作り、それを使うことは作業インターフェースを替えることを意味します。一方、tmux-webui は別種の画面を作らず、deck と log を追加の一覧レイヤーとしています。中に入れば、元の pane で実際に動いているものがそのまま見えます。どちらも成り立つ選択で、違いは端末を預けたいかどうかです。

operonlab にあるこれらの tmux ツールは、どれも計画して作ったものではありません。具体的な不便にぶつかるたびに補ったものです。底をつく利用枠からは tmux-llm-usageが生まれ、つかみきれない agent の状態からは tmux-agent-statusが生まれ、再起動後に会話が切れることからは tmux-agent-resumeが生まれ、一つのプロジェクトで大量のウィンドウを開くことからは tmux-workdeskが生まれ、ホストの前にいないと pane が見えないことからは tmux-webui。operonlab にある tmux- で始まる公開プロジェクトは、この記事を書いた 2026 年 8 月時点で 13 個、 session-channel を加えると 14 個です。

場面を変えると、同じ議論は nginx をめぐって起きています

私の判断基準には、そこで一つ加わりました。本当に優れているかどうかであって、新しいかどうかではありません。これは「I Replaced Nginx With Caddy… And I'm Never Going Back」という動画の下にあったコメントから来ています。

そのコメントの「20 年続いていることは短所ではなく長所だ」という言葉は、私が tmux で向き合っている問題と同じ形をしています。tmux も 20 年近く続き、インターフェースは古く、設定は読みにくい。それでも send-keys や capture-pane といった基本機能は何年も変わっていません。変わらないからこそ、その上に積み重ねたものを何度も直さずに済みます。新しい ADE は worktree、terminal、diff、browser を同じ画面に集め、体験はずっと良くなります。その代わり、作業インターフェース全体がその製品のライフサイクルに結びつきます。

年数そのものは中立です。同じ 20 年でも、設定ファイルを誰も触れず、遠回りな workaround が何層にも積み重なり、後から来た人には理由が分からないという重荷になることもあります。逆に、落とし穴が洗い出され、コードが何度も review されてきた資産にもなります。その年月が蓄積に使われたか、負債を背負うことに使われたかが違いです。

harness を替えることは、モデルを替えるだけではない

出力の品質を決めるのは、モデル自体だけではありません。Wisely Chen の記事では、この差が数値で示されています。同じ Kimi K3 モデルでも、公式 harness の KCode では 59.6%、オープンソースの Maka に替えると 69.7% に達します。harness はモデルの外側の器ではなく、実際の性能を左右する変数です。

Pi と Claude Code は、ちょうど異なる二つの方向です。Claude Code はモデルと harness が一体で、すぐに使えます。Pi は provider とモデルを替えられ、柔軟な一方で自分で組み立てる必要があります。

ここまでの段階で補ったものは、「harness は変数である」という話を一歩広げたものです。モデルが一つなら、harness がその働き方を決めます。モデルが増えれば、仕事をどう分け、どう受け渡し、どう検証するかを決めるものも必要です。モデルごとに得意なことは違います。機械的な一括変更なら安いモデルに任せれば十分です。さらに前の記事で、仕事を計画、worker、検証の 3 層に分けて異なるモデルで動かしたのが、この考えの最初の形です。

自分で補った部分の請求書は、少し遅れて届く

先に代償を話します。そうしないと、この記事は自作を勧めているように読めてしまいます。自分で補った部分の保守費用は、少し遅れてやってきます。上流の CLI が flag を一つ変えるたびに、 cli-rosetta の registry を確認して直さなければなりません。Claude Code の TUI が更新されれば、tmux-webui agent が作業中か、人の対応を待っているかを判定するルールが誤るかもしれません。これらのツールには互換性を見守るコミュニティがなく、壊れたら自分で直すしかありません。使い続けるほど、保守にかける労力は当初の開発費用を上回っていきます。

だから状況が変われば、結論もまったく変わり得ます。agent を一つか二つしか使わず、タスクを別のマシンに振り分ける必要もないなら、Claude Squad や Orca のような成熟したツールをそのまま選ぶほうが、自分で一式を組み立てるよりずっと割に合います。そうしたツールには保守する人がいますが、自分で補った部分にはいません。

自分で作ることになったのは、詰まった箇所がそれだけ痛く、しかも当時使えるものが見つからなかったからです。今はコミュニティに答えが増えています。自分で補わずに済む段階は、一つでも減らしたいと思います。

まず自分の状況を測り、それから作るか決める

以下の二つの判定ツールは、自分で入力して初めて結果が出ます。一つ目は症状からどの段階で詰まっているかを特定し、二つ目は公開された実測の二つの基準点を使って、今回のタスクを振り分ける価値があるかを見積もります。計算はどちらもブラウザ内で行い、データはどこにも送られません。

あわせて読む