この記事の実施記録（2026年5月）: Claude Codeのターミナルを3つ同時稼働させると認知負荷の限界に達することを体験から発見した。2つなら交互リズムが作れるが、3つで「常に全方向に備える」状態になる。HBR 2026年2月号論文との照合で見えてきた「コストの非対称性」と、オーケストレーターアーキテクチャでも解決しきれない「割り込み問題」を記録する。
SNSを眺めていると、画面いっぱいにターミナルを並べた写真が流れてくる。10個、15個。整然と並んだウィンドウ。「AIを使いこなしている人」という印象を受ける。
あれを見て、最初は「すごい」と思っていた。
実際に試してみるまでは。
3つで脳が限界になる：認知負荷の閾値とは
Claude Codeでマルチエージェント運用をしている。writer（記事執筆）・reviewer（ファクトチェック）・secretary（タスク管理）といった役割を複数のターミナルに分けて並行稼働させる体制だ。
ある日、記事執筆・スクリプト修正・Issue整理という3種類のタスクを同時進行させようとして、3つのターミナルを開いた。
3つ目を立ち上げた瞬間から、何かがおかしくなった。
各ターミナルが次々と応答を返してくる。どれも「ユーザーの判断を求めている」。応答の順番はランダムで、どのウィンドウで何が起きているか、常に注意を向け続けなければならない。気づいたら、自分がずっと「待ち受け」状態にいた。
閾値を整理するとこうなる。
- 2つ：「1つ答えたら次」というリズムが自然に生まれる。見通しが持てる
- 3つ：つらくなり始める（閾値）
- 4つ：応答ペースに確実に追いつかなくなる
「慣れれば解決する話では？」という疑問が来るかもしれない。続けてみた結論を先に言う。慣れの問題ではなかった。
2つのターミナルでは、自然に交互のターン制が生まれる。片方が処理している間に、もう片方に指示を出す。ABのリズムが作れる。ところが3つになると、このターン制が崩れる。ABCのどれが次に返ってくるか分からないので、「常に全方向に備え続ける」状態になる。
この「全方向に備え続けるコスト」が積み重なって、脳が詰まっていく。数を増やすほど悪化する構造だ。「もう1つ増やせばいい」は解決策にならない。4つは3つより確実につらかった。
人間のワーキングメモリには、一度に保持できるコンテキストの上限がある（認知科学では一般に3〜4チャンクと言われる）。この限界を超えると、コンテキスト切り替えのたびに「このターミナルは何を扱っているんだっけ」という引き出しコストが毎回かかるようになる。これは脳の構造的な制約であり、練習で消えるコストではない。
HBR論文が言えなかった「コストの非対称性」
2026年2月、Harvard Business Reviewに「AI Doesn't Reduce Work—It Intensifies It」という論文が掲載された。著者はUC Berkeley HaasのAruna RanganathanとXingqi Maggie Yeで、200人規模の米国テック企業での8か月間エスノグラフィー調査（40名対象）に基づく（UC Berkeley Haasニュースリリース・The Register等複数の二次ソースで確認済み）。（参照: https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies-it）
論文の主張は明快だ。AIは業務量を減らすのではなく、業務の強度（intensity）を上げる。論文の要旨によれば、その形態として3つが挙げられている。
- タスクの拡張（AIが完成させた成果物をさらに修正・拡張する作業が生まれる）
- 仕事と非仕事の境界が消える
- マルチタスクが増加する
さらに自己強化サイクルがある。AIで速くこなせる→期待が上がる→依存が深まる→担当範囲が広がる→さらに速くこなす必要が生まれる。
これを読んで「そうだ」と思った。同時に、何かが抜けているとも感じた。
論文の主語は「AI」だ。マルチタスクを増やすのは「AIの導入」という視点で書かれている。
だが私が体験したのは違う構造だった。
コンテキストスイッチのコストは、すべて人間側にかかる。
AIは並行で走り続けられる。疲れない。コンテキストを切り替えてもコストはゼロだ。マルチターミナルで複数エージェントを動かすとき、切り替えコストを負担しているのは人間だけで、AIには一切かからない。
論文は「AIがマルチタスクを増やす」と語る。私の体験が指しているのは「そのコストを全部人間が払う」という一段深い非対称性だ。
問題は「数」ではなく「コンテキストの異質さ」
3ターミナルの体験から考え続けて、ある仮説に至った。
つらさの原因は「数」ではなく「コンテキストの異質さ」だ。
実は、3つのターミナルが苦しくない状況もある。
reviewer・reader・SEOレビューという3つのエージェントを1つの記事に対して同時稼働させるとき、それほどつらくない。なぜなら3つのコンテキストが「同じ記事A」という共通の土台を持っているからだ。切り替えても基盤となる文脈は変わらない。これを「同質並走」と呼ぶことにする。
一方、記事執筆・スクリプト修正・Issue整理の3並走はつらい。コンテキストが完全に異なる。切り替えるたびに頭の中を全部入れ替えなければならない。これが「異質並走」だ。
| 並走の種類 | スイッチコスト | 例 |
|---|---|---|
| 同質並走 | 低い | 同一記事に対してwriter・reviewer・SEOを同時稼働 |
| 異質並走 | 高い | 記事執筆・スクリプト修正・Issue整理を同時稼働 |
現実のマルチエージェント運用はほぼすべて「異質並走」になる。記事を書きながら、発生したバグを直して、タスクを整理する。これが実態だ。
だから「数が増えるほど悪化する」。同質なら3つでも大丈夫だが、異質なら2つでも重い。数だけ見ていると、本当の問題が見えない。
オーケストレーターで軽減できること、できないこと
ではどうするか。アーキテクチャを変えることが一つの答えだ。
Anthropicは「Building Effective Agents」の中でオーケストレーター-ワーカーパターンを推奨している。中央のオーケストレーターが仕事を分解し、複数のワーカーに振り分け、結果を統合する構造だ。（参照: https://www.anthropic.com/research/building-effective-agents）
「COO（オーケストレーター）がいればいいというのはClaude Code課金ユーザーだけの話では？」という疑問もあるかもしれない。しかしこの原則はどのマルチエージェント環境でも同じだ。ChatGPT複数タブを自分で管理するより、プロジェクト機能でコンテキストをまとめる方が楽なのと同じ理屈。特定のツールの話ではなく、マルチエージェントをどう設計するかのアーキテクチャの話だ。
オーケストレーターが存在することで、人間への入出力が1本に束ねられる。
reviewer・reader・SEOレビューの3エージェントを同時稼働させているとき、人間（私）がやることは「1つの依頼を出す」だけだ。3つのターミナルを監視するのではなく、オーケストレーターに「記事をレビューして」と伝える。オーケストレーターが3人に振り分け、結果を集約して「まとめてここです」と返してくれる。コンテキストスイッチが発生しない。
これで問題は解決したか。実は、解決しきれていない問題が残る。
「待つ」か「忘れる」か：残る割り込み問題
エージェントをバックグラウンドで動かしながら別の作業をすればいい——そう考えるかもしれない。同期（ターミナルを見ながら待つ）が辛いなら、非同期で動かせばいい、と。
試してみた。バックグラウンドで3つのエージェントを走らせて、その間に別の記事の構成を考え始めた。
やはり問題が生じた。
完了通知が来た瞬間、さっきまで考えていた記事の構成が中断される。エージェントの結果を確認しようとすると、「あれ、どこまで考えてたっけ」というコンテキスト取り戻しコストが発生する。さらに、エージェントが話の途中に割り込んでくるので、今していた思考も途切れる。
人間同士の会話なら「ちょっと待って」が言える。AIの完了通知には、割り込みを止める手段がない。
同期（ターミナルを見て待つ）の問題：AIのペースに引きずられる。
非同期（バックグラウンドで動かす）の問題：戻ってきたときのコンテキスト取り戻しコスト＋話の途中への割り込み。
どちらにも人間側のコストがある。「待つ」か「忘れる」かのトレードオフだ。
オーケストレーターで認知負荷を下げる工夫はできる。だがAIの非同期処理が生む「割り込み問題」は、現時点では根本的な解決策がない。
HBR論文の著者たちは「AIプラクティス」として意図的な一時停止・作業のシーケンシング・人間的なグラウンディング（固定点を作る）を推奨している。確かにそうだと思う。ただし「完全な解決策がある」とは言っていない点が正直で好感が持てた。
今できる最小の対策は「並走数を2つに抑え、かつ同質なタスクに絞る」ことだ。完璧ではないが、体験上これが最もコスト感を抑えられる運用だった。
「じゃあHuman in the loopをやめればいい」という話にはならない。AIの判断を人間が確認・修正する工程は、品質と信頼のために必要だ。Anthropicも設計原則の核心として位置づけている。
だから逃げ場がない。AIも外せないし、人間も外せない。「Human in the loopのコスト」は誰も語らない。 「なぜ必要か」は語られる。「それが人間に何を強いているか」は語られない。HBR論文でさえ、「Human in the loopという構造そのものがコストを生む」とは言っていない。
よくある誤解：画面いっぱいのターミナルは何を意味するか
最初の話に戻る。
あのSNSのスクリーンショット、10個以上のターミナルが並んでいる写真の裏に何があるか。おそらく「管理している感の演出」という側面がある。実態は「並走させて、結果だけ拾う」使い方であって、「10個を全部リアルタイムに追っている」ではない。
それ自体は合理的な使い方かもしれない。でも「10個を管理している」という語り方は正確ではない。
問題は、そういう絵が「マルチエージェント活用の理想像」として流通してしまうことだ。それを見た人が「自分も全部のやり取りを追いながら並走させなければ」と思ったら、確実に消耗する。
限界はどこか、並走させると何が起きるかを言語化している人が少ないのが、今のマルチAI活用のフロンティアだと感じている。
ここで一つ、皮肉な事実がある。Claude Codeは2026年5月から5時間のレート制限を緩和した。「並走の障壁が除去された」とポジティブに語られている。
でも私は複雑な気持ちになった。AIの制限は、人間の休憩時間だったのかもしれない。 制限に引っかかれば強制的に止まれた。「APIが止まったから仕方ない」という言い訳で離席できた。制限緩和でその言い訳が消えた。Human in the loopが必要なのに、loopが止まらなくなった。
制限緩和を喜んでいる自分と、休めなくなったと気づいた自分が、同時にいる。
「3つで脳が限界になった」という体験を言語化するのは、「すごい」話ではない。でも「この体験から何が見えるか」を言語化することで、設計の問題が見えてくる。
並走の限界は「数」ではなく「アーキテクチャ」の問題だった。
そしてそれは、AIの問題ではなく、人間の認知の問題でもあった。
参考
- Ranganathan, A. & Ye, X.M. (2026). "AI Doesn't Reduce Work—It Intensifies It." Harvard Business Review, 2026年2月9日. https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies-it
- Anthropic. "Building effective agents." (2024年12月19日). https://www.anthropic.com/research/building-effective-agents
関連書籍（Amazon）
Claude Codeのマルチエージェント活用の背景にある設計思想をより深く知りたい方に。
この記事は はてなブログ からのクロスポストです。