はじめに
最近、Claude Codeを使い始めました。
社内の強強エンジニアがtmuxで画面をバキバキに割って開発している姿に憧れ、「よっしゃ、自分もAIエージェントを並列で回して爆速開発だ！」と意気込んでみたんです。
でも、やり進めるうちに「なんかこれ、逆に効率悪くない……？」と気づき始めました。
結論から言うと、僕は「並列」と「分断」を履き違えていたんです。
めちゃくちゃ恥ずかしい失敗談ですが、tmuxの「本当の良さ」とSubagentsの使い分けが見えてきたので共有します。
恥ずかしい失敗：4ペイン同時に「Enter」を迫られる地獄
僕がやったのは、tmuxでターミナルを4分割し、それぞれのペインで別々の機能をClaude Codeに実装させるというスタイルでした。
見た目は最強にカッコいい。でも現実はこうでした。
- 4つのペインから一斉に「実行していい？」と聞かれる。 聖徳太子じゃないんだから、4つの思考プロセスを同時に追うのは脳が焼き切れます。
- トークン消費量が意外と伸びない。 「あれ、これ指示出しと状況把握に時間取られすぎて、自分で書いた方が早くね？」という本末転倒な状態に。
最大の原因は、セッションが分断されていることでした。
セッション分断のデメリット：コンテキストの再構築
個別のペインで動かすと、Claude Code同士が連携してくれません。
- 「さっき右の画面でやったリファクタリング、こっちにも反映して」が通じない。
- Markdownファイルを読み込ませて状況を同期させる指示だけで、無駄なターンとトークンを消費する。
同じプロジェクト内なら、「内容をわかっているメンバー（Subagents）」に任せたほうが、コンテキストが繋がっていて圧倒的にスムーズだったんです。
逆に「tmuxでの分断」が輝く瞬間
じゃあ、強強エンジニアがなぜ画面を割るのか。失敗してようやく、**「分断することのメリット」**も見えてきました。
1. ドメインが完全に分かれている時
例えば「フロントエンド」と「バックエンド」のように、コンテキストを混ぜる必要がない（あるいは混ぜるとノイズになる）場合は、セッションを分けるのが正解です。
- メリット: 互いの変更を気にせず、独立したログを確認できる。
2. 環境や依存関係が異なる時
別のリポジトリ、あるいはDBのマイグレーション待ちなど、実行環境をクリーンに保ちたい時はtmuxでの分割が最強です。
結論：AI時代の「並列」の考え方
今回の僕の学びをまとめるとこうなります。
| 手法 | 向いているケース | 脳の状態 |
|---|---|---|
| Subagents | 同一プロジェクト内の機能実装。 文脈を共有したい時。 | **「一人の超優秀な脳」**が手足を増やして動く感覚。 |
| tmux分割 | 異なるドメイン・リポジトリ。 文脈を切り離したい時。 | **「独立した別々の脳」**がそれぞれの領域で動く感覚。 |
内容をわかっているメンバーが一気に動いてくれる感覚は、やっぱり同一セッション内のSubagentsならではの強みでした。
あとがき
いやー、本当に恥ずかしいっす。「4画面でEnter連打してる俺、エンジニアっぽくて最高！」って酔いしれてたあの時の自分を殴りたい。
「強強の人の真似」を形だけで終わらせず、その裏にある**「なぜ今セッションを分けているのか？」**という意図まで汲み取れるようになりたいですね。皆さんも、tmuxを割る前に「今、文脈（コンテキスト）は繋がってるか？」を自分に問いかけてみてください。マジで。