ターミナルが多すぎる：コーディングエージェントを手動で実行する本当のコスト

最初はターミナル1つとClaude Codeから始める。そこに2つ目のタスクが舞い込み、2つ目のターミナルを開いてCodexを走らせる。フロントエンドの修正は3つ目へ。気づけば3つのウィンドウをAlt+Tabで行き来しながら、どれが自分の対応待ちなのか、どれが10分前に質問してきたのか、そして自分が残り2つに注意力を燃やしている間、どれが静かに終わって遊んでいるのかを思い出そうとしている。何かが炎上しているわけではない。ただ、エージェント間で作業を振り分ける役目を自分が担ってしまったのであり、その仕事はどのエージェントよりもスケールしない。

コストなのはターミナルではない。あなた自身だ。エージェントを手作業で動かすと、次に何をするかというあらゆる判断が1か所、つまりあなたの頭の中に集まる。どのエージェントに次のタスクを渡すか、直前の差分は安全か、別のウィンドウを読んでいる間に何が失敗したか。この調整はれっきとした仕事で、しかも無給であり、追加するエージェントの数よりも速く膨らんでいく。

本記事では、コーディングエージェントを手作業で動かすことに実際いくらかかるのか、その請求書が複利で効き始めるまでどこに隠れているのか、そしてそのほとんどを取り除くワークフローを解説する。Sharklyはエージェントの上に乗る管理レイヤーだ。使い慣れたClaude CodeやCodex、その他のランタイムはそのままに、Sharklyがタスク、分離、レビューを、ターミナルの壁越しではなく1つの共有された場所で保持する。

TL;DR

コーディングエージェントを手作業で動かすのは、どのツールも料金を取らないため無料に見える。本当のコストはあなたの注意力だ。エージェント間のルーターになり、各エージェントが何をしているかの記憶になり、すべてのウィンドウに追いつかなければならない唯一のレビュアーになる。このコストはエージェントが2、3台なら小さいままだが、5台を超えると複利的に膨らんでいく。手作業を続けてもいいし、既存のエージェントをSharklyのようなタスクレイヤー経由で動かしてもいい。タスクレイヤーは作業を割り当て、各実行を分離し、すべての結果をレビュー用のタスクへと返してくれる。

問題はターミナルではない、あなた自身だ

覚えておく価値のある定義がある。ターミナルはエージェントが動く場所であり、タスクはそれが取り組む作業だ。エージェントを手作業で管理すると、この2つをつなぐものはあなた以外に何もない。ターミナルは出力を表示するだけだ。タスクが何だったのか、終わったのかどうか、次に何をするかを誰が決めるのかは知らない。それらすべてを、1つのウィンドウごとに記憶から補っている。

だからこそ「ターミナルが多すぎる」は病巣ではなく症状なのだ。tmuxで1つのエージェントを5つのペインに分割しても、調整が減るわけではなく、配置が変わるだけだ。どのペインがどのタスクを担当し、どれが実行中で、どれが終わって人間の確認を必要としているかを、依然として自分が把握している。その地図はどこにも共有されていないので、その場を離れた瞬間に古くなり、チームメイトが必要とした瞬間には存在しない。

エージェントを手作業で動かすことの実際のコスト

請求書は注意力で支払われ、注意力には測定可能な価格がある。無関係なタスク間を切り替えるとき、人は即座に元に戻れるわけではない。Gloria Markらによる中断された知識労働に関する研究（CHI 2008で発表）では、中断されたタスクに戻るまでに平均20分以上かかることがわかっている。アメリカ心理学会によるタスク切り替え研究のまとめでは、タスク間の移動による生産性の損失は最大40%に達するとしている。エージェントが終わるたびに別のウィンドウへ向き直るたびに、何らかの形でこの税を払っているのだ。

エージェントを手作業で動かすと、この切り替えがメインループになる。コストが積み上がるのはここだ：

これらはいずれもクラッシュとして現れない。現れるのは、忙しかったのにマージされたPRが8本ではなく3本だったという1日であり、ここが問題だと指摘できる単一の瞬間は存在しない。

障害モードは複合するまで見えない

エージェントが2台なら、地図全体を作業記憶に保持でき、コストはほぼゼロだ。これははっきり言っておく価値がある。多くのアドバイスが問題を過大に語るところだからだ。1台か2台のエージェントを1つのマシンで動かし、次を始める前にそれぞれをレビューするなら、管理レイヤーはまだ必要ない。可動部分はゼロに保とう。

方程式が変わるのは、作業が時間的または状態的に重なったときだ。同じチェックアウトで3台のエージェントを走らせると、同じリポジトリで複数のコーディングエージェントを動かすときに扱う分離の問題にぶつかる。2台のエージェントが同じファイルに触れ、片方がもう片方を静かに上書きしてしまう。これをタスクごとのworktreeで解決する、つまりコーディングエージェントのworktreeの規律を守ると、マージの問題を帳簿付けの問題と交換することになる。どのディレクトリがどのタスクに対応するのか、どれが削除しても安全か、どれを人間がレビュー中か、という問題だ。それをさらに多くのターミナルで解決しようとすると、ウィンドウが増えただけで元の場所に戻ってしまう。

最後のコストは静かなものだ。すべての実行がプライベートなターミナルで起きると、終わった作業の行き先はあなたの注意力しかない。レビューがボトルネックになる。エージェントが働くのを見ていた唯一の人物であり、その差分が良いかどうかを言える唯一の人物だからだ。並列エージェントは、その出力のレビューが1人の人間で直列化するなら助けにならない。これが最高のコーディングエージェントよりも、それをどう管理するかの方が重要である理由で説明されている罠だ。モデルは速くなったのに、レビューキューは速くならなかった。

管理レイヤーが取り除くもの

タスクボードは、あなたが手作業でやっていた部分、つまりエージェントと作業をつなぐ結合組織であることを取り除く。Sharklyでは、タスクが実行を所有する単位だ。タスクをエージェントに割り当てると、Sharklyは接続されたコンピューター上にそのための分離されたworktreeを用意し、そこでエージェントセッションを実行し、差分、ログ、あらゆるブロッカーをそのタスクに返す。頭の中に保持していたルーティング、分離、記録が、タスクのプロパティになるのだ。

これにより分業がすっきりと保たれる。エージェントは調査、実行、テスト、報告を行い、人間は方向性を示し、権限を与え、結果を受け入れる。SharklyはClaude CodeやCodex、あるいは既に使っているランタイムの代替ではない。実行するのはそれらだ。Sharklyはそれらの周囲に、共有されたタスク、接続されたコンピューター、レビューレイヤーを追加する。そうすることで、コンテキスト、進捗、ブロッカー、結果、人間のレビューが、自分しか見られない5つのセッションに散らばるのではなく、リクエストからリリースまで見える状態に保たれる。複数の実行を同時に監視する必要があるとき、まさにそのためにエージェントダッシュボードがあるし、チームがもう1つのターミナルではなくClaude CodeとCodexの上のレイヤーを欲しがるようになる理由でもある。

既に複数のエージェントを動かしているなら、それがSharklyの想定するワークフローだ。ターミナル間で手作業のルーティングを続けてもいいし、既存のコーディングエージェントをSharkly経由で動かして、地図をボードに任せてもいい。

手作業で問題ない場合と、そうでない場合

正直な判断基準は短い：

• エージェントを手作業で動かすべきときは、1台か2台で、1つのマシン上にあり、次を始める前にそれぞれをレビューする場合。どんなツールでも、そのオーバーヘッドはまだ見合わない。
• タスクレイヤーへ移るべきときは、3台目のエージェントが動き始めたとき、作業が複数のリポジトリにまたがるとき、あるいは自分以外の誰かが何が動いているかを見る必要があるとき。調整コストが1人の頭に収まらなくなるのは、まさにこの時点だ。

シグナルはターミナルの数ではない。「あれ、これどのウィンドウだったっけ？」と自分に問いかけていることに気づいた瞬間だ。その問いは調整税が1つの文として現れたものであり、タスクボードが終わらせるために存在するのと同じエージェントの混沌だ。

FAQ

tmuxやターミナルマルチプレクサーで十分ではないか？ ウィンドウを整理してくれるだけで、調整を取り除くわけではない。どのペインがどのタスクを担当し、何が終わり、誰がレビューするかは、依然として自分が把握している。マルチプレクサーが解決するのは画面の領域だ。エージェントを手作業で動かすコストはピクセルではなく注意力だ。

手作業で何台のエージェントまでなら負担なく動かせるか？ 多くの人は1台か2台なら問題なく、3〜5台あたりから負担を感じ始める。特に複数のリポジトリにまたがる場合はそうだ。正確な数は、各タスクの実行時間と必要なレビューの量による。見分け方は、実際のレビューよりもルーティングやウィンドウの読み返しに1日の多くを費やすようになったときだ。

タスクボードはエージェントを速くするのか？ いいえ、Sharklyもそうは主張していない。エージェントは同じ速度で動く。変わるのはあなたのオーバーヘッドだ。ルーティング、分離、レビューが頭の中から離れ、作業が見えてレビュー可能なタスクへと返ってくるようになる。

セッションをまたいでコンテキストを保つには？ プライベートなターミナルは閉じた瞬間にそれを失う。実行をタスクに紐づければ、目標、差分、議論が一緒に保たれる。これはセッションをまたいだコンテキスト維持の問題を、記憶ではなく記録のレベルで解決したものだ。

この方法でClaude CodeとCodexを併用できるか？ はい。Sharklyはツールの周囲の作業を管理するのであって、ツールを置き換えるものではない。パターンについてはClaude CodeとCodexを1つのコードベースで一緒に動かす方法を参照してほしい。