Claude Code や Codex を 5〜6 個並べて動かしていると、どこかで必ず「これはしんどいな」という場面が来る。
面白いのは、いま何を使っているかで、しんどくなる場所が違うことだ。VS Code を使っている人はマシンのメモリが先に足りなくなるし、ターミナルを分割している人は「1 つ 1 つが小さすぎて読めない」で止まる。原因が違うので、やることも違う。
先日、実際に使ってくれている人たちに話を聞いて回った。インタビュー 4 人と、こちらが依頼していない自発的な記事が 2 本。そこで出てきた「困っていること」を、いま使っているツール別にまとめておく。
先に断っておくと、これは乗り換えを勧める記事ではない。実際、話を聞いた中に元のツールを完全に捨てた人はいなかった。役割が分かれただけだ。
誰が作っているか
この記事で扱う MulmoTerminal は、Singularity Society のチームで開発している OSS だ。中心にいるのは 中島聡（Microsoft で Windows 95 と Internet Explorer を手がけ、現在もシアトル在住）で、そこに私（isamu）を含む数人が加わっている。
自分たちが毎日困ったことを、その日のうちに直しながら作っている。この記事に出てくる困りごとのいくつかは、実際にユーザーから言われてそのまま直したものだ。MIT ライセンスで公開している。
VS Code + Claude Code 拡張
困ること: メモリが足りなくなる
一番多かったのがこれ。
エージェントを分けるためにウィンドウを分けると、1 体につきエディタ本体・言語サーバー・拡張機能・ファイルウォッチャーが一式増える。エージェントは 1 体増えるごとに 1 プロセスだが、IDE は 1 体増えるごとに一揃い増える。
64GB のマシンでもカクつく、という報告があった。実際に移った人の言葉:
メモリー圧迫しないの最高すぎる。64G の vaio 君がカクカクになっていたけど、今のところサクサク動いている。
こうすると楽になる
エージェントをサーバー側のプロセスにして、UI をブラウザのタブにする。これだけでメモリの増え方が変わる。ブラウザのタブは IDE のウィンドウよりはるかに軽い。
ただし VS Code をやめる必要はない
実際に移った人も「たまに VS Code、主にテキストエディタとして」と言っていた。
エージェントを並べて監督する場所と、コードをじっくり読み書きする場所。この 2 つは別の道具でいい。
Cursor
困ること: メモリ、そして過去のやり取りを探せない
Cursor から移ってきた人が挙げたのは 2 つだった。
- ウィンドウをたくさん開いてメモリが枯渇しがちだった
- 過去の AI とのやり取りを遡るのが辛かった
2 つ目は見落とされやすい。並べて動かしていると「これ、さっき何を頼んだんだっけ」がよく起きる。そのとき前のやり取りが見つからないと、もう一度説明し直すことになる。
こうすると楽になる
自分が出した最後の指示と、AI が今どこまで進んだかの要約を、画面の横に出しっぱなしにする。 過去のやり取りを探しに行かなくて済む。
そして補完とインライン編集については、Cursor のほうが快適だ。そこを置き換える話ではない。
移行コストの話
Cursor から移った人が挙げた決め手は、意外にもこれだった。
ClaudeCode の resume が引き継げた事
同じ人が「resume を使えないなら無理かなと思った」とも答えている。同じ 1 点が、最大の不安であり最大の決め手になっている。
claude --resume と同じ仕組みで、同じトランスクリプトを読む。いつも使っているディレクトリを開けば履歴はそこにある。移行作業は無い。
ターミナルを分割している人（tmux / iTerm）
困ること 1: どれがどれだか分からなくなる
分割そのものは簡単にできる。問題はその先だ。
別タブへの返信のつもりが、間違えて違うタブに入れてごちゃごちゃになる
これは注意力が足りないという話ではない。同じ見た目の画面が 6 枚あれば、「どれが何の作業か」を 6 つ、頭の中で覚えておくしかない。 画面を増やすほど、覚えておく量が増える。
困ること 2: 並べるほど、1 つ 1 つが読みにくくなる
もう 1 つ、記事を書いてくれた人の指摘が的確だった。
ターミナルを 6 分割すると、1 つ 1 つのペインが小さすぎる。4000 字の出力を読むのにスクロールとリサイズが必要になる
当たり前だが、画面の広さは決まっている。 6 分割すれば 1 つあたりは 6 分の 1 だ。つまり「たくさん並べる」と「1 つをちゃんと読む」は、そのままだと両立しない。だから多くの人は、1 つ増やすたびに読みにくさを黙って受け入れている。
こうすると楽になる
状態を色にする。 作業中／こちらを待っている／終わった。文字を読まずに、眺めるだけで分かるようにする。
そしてグリッドと拡大を行き来できるようにする。 全体を眺めて、1 体を大きくして読む。同じ人がこう書いていた。
「複数の AI エージェントを並列に走らせる」と「ひとつの出力を大きく読んで判断する」が、同時に実現できる
トレードオフだと思われていたものが、そうではなくなる。
なお、裏を tmux にしておけばセッションは死なない。ブラウザを閉じてもサーバーを再起動しても走り続ける。
Warp
そもそも用途が違う
Warp と比べられることがあるが、そもそも用途が違うというのが正直なところだ。
ターミナル単体の完成度は Warp のほうが上だ。補完、履歴、ブロック単位の編集、あのあたりは気持ちよく作られている。
Warp は「1 人がターミナルを快適に使う」ための道具だ。こちらは「複数のエージェントを並べて、どれが自分を待っているかを見る」ための道具になる。競合というより、やろうとしていることが別。
Claude Squad
目的は近い。違うのは見せ方
目的はほぼ同じだ。tmux と git worktree で複数のエージェントを回す、という発想も同じ。
違いは見え方にある。
| Claude Squad | MulmoTerminal | |
|---|---|---|
| UI | TUI（ターミナル内で完結） | ブラウザ |
| 見方 | 基本は 1 体ずつ | 複数のライブ画面を同時に |
| 状態 | 色で分かる | |
| 通知 | スマホに Push | |
| 必要なもの | ターミナルだけ | ブラウザが要る |
SSH 越しでも軽いのは Claude Squad の明確な強みだ。ターミナルから出たくないなら、そちらのほうが合う。
全体を一覧で見ながら進めたい人はこちら、という分かれ方だと思う。
Conductor / Crystal（Mac アプリ）
困ること: またウィンドウが増える
worktree を切ってエージェントを並べるデスクトップアプリがある。目的は近い。
diff のレビューは向こうのほうが作り込まれているし、ネイティブアプリなので操作も速い。
ただ 1 つ、構造的に違うところがある。デスクトップアプリなので、並べるとウィンドウが増える。
IDE から移ってきた人の理由が「ウィンドウが増えるとメモリが足りない」「どの画面も同じ見た目で見分けがつかない」だったので、そこは解かれないまま残る。
ブラウザのタブ 1 枚に全部入る、というのがこちらの立ち位置だ。スマホからも同じものが見える。
共通して出てきたこと
6 人分を並べてみると、困りごとは 3 つに集まっていた。
- メモリが足りなくなる ── エージェントを分けるためにウィンドウを分けると、マシンのほうが先に音を上げる
- どれがどれだか分からなくなる ── 同じ見た目の画面が増えるほど、覚えておくことが増える
- 並べるほど読みにくくなる ── 画面の広さは決まっているので、増やせば 1 つあたりは小さくなる
そして重要なのは、誰も「もっとたくさん回したい」とは言っていないことだった。全員が言っていたのは「いまの数を、楽に扱いたい」だ。
実際に動かしている数は 1〜6 個だった。ある人は 1〜3 個しか動かしていないのに VS Code をやめている。
つまり「たくさん動かすための道具」ではなく「動かしているものを見失わないための道具」だった。これが 6 人に聞いて一番はっきりしたことだ。
試し方
インストールは要らない。npx 1 行で立ち上がる。
npx mulmoterminal@latest
# → http://localhost:34567Node.js 22.9 以上と、claude か codex の CLI が PATH にあれば動く。ローカルで完結する（コードも API キーもどこにも送られない）。MIT。
合わなければ消すだけだ。既存のセッションは resume でそのまま引き継げるので、元に戻れなくなることもない。
そして、使ってみて不便なところがあったら教えてほしい。 この記事に出てくる困りごとのいくつかも、実際に言われてそのまま直したものだ。