← 기사 목록
日本語https://zenn.dev/topics/ai/feed

AIを5本同時に走らせても、俺の脳みそは1個しかない

추출된 키워드

30
AI並列開発·5認知科学·4Claude Code·4Codex·4ワーキングメモリ·4Attention Residue·4注意残余·4メンタルモデル·4コンテキストスイッチ·4直列切り替え·3skill化·3アンドン・コード·3マジカルナンバー7±2·3認知コスト·3報酬系領域·3前頭前野·3ショート動画·3スループット·2ディテクター·2ビジネスリフト·2Feature Retention·2Adoption Rate·2ペパボ·2setting.json·2EEG·2トヨタ·2Sophie Leroy·2Gloria Mark·2Cowan·2MRI·2

원문

11,767
AIを5本同時に走らせても、俺の脳みそは1個しかない

AIを5本同時に走らせても、俺の脳みそは1個しかない

こんにちは。脳みそが1個しかない者です。

美味しい味噌これは味噌です

最近、当たり前のように並列開発をするようになりました。皆さんもそうだと思います。cmuxや何なりでAIで5〜6本のタスクを同時に走らせて、サブエージェントも含めると10本以上が同時に動いているみたいな感じです。

燃やし切って退勤する頃には、今日自分が何をしたのか、コードの中身がどうなっているのか、よく思い出せない時もあります。記憶が薄い。

たまに思います。

これ仕事じゃなくてゲームとかYoutubeだったら、お母さんに怒られたんだろうね

人間は並列処理できない

これ、もう何十年も前から認知科学で言われていることなんですが、改めて言います。

人間の脳は並列処理ができません。

「いや、俺は音楽聴きながらコード書けるよ」という方、それは並列処理ではなく、脳が音楽を「BGM」として処理コストを限りなくゼロに近づけているだけです。2つの意識的なタスクを同時にやっているわけではありません。

実際にやっているのは高速な直列切り替えです。タスクAとタスクBを素早く行き来しているだけで、切り替えるたびに認知コスト(attention residue)が発生します。前のタスクの残像が次のタスクの判断力を汚染する、というやつです。

YouTubeショートやInstagramリールが脳に悪いと言われる理由もこれと同じ構造です。3秒ごとに完全に異なるコンテキストが流れ込んでくる。脳は切り替えのたびにコストを払い続け、結果として集中力の基礎体力が削られていく。

🧠 脳科学TMI:あなたの脳みそが思ったより残念な件

ここで、読者の皆さんの脳みそがいかに残念かを示す研究をいくつか紹介させてください。もちろん僕の脳みそも同じくらい残念です。

脳が保持できるのは「3〜5個」、しかも戻るのに「23分」

Miller(1956)の「マジカルナンバー7±2」は有名ですが、実はこれ、かなり盛られた数字です。Cowan(2001)が改めて検証したところ、リハーサル(頭の中で繰り返すこと)を防止した条件では、ワーキングメモリの実質的な容量は約3〜4チャンクでした [1]。しかもこれは「猫」「犬」「鳥」みたいな単純な単語の話です。「認証基盤のリファクタリングの設計方針」みたいな重いコンテキストを1チャンクに圧縮できる人がいたら、ぜひ脳を寄贈してほしい。

つまり、5〜6本のセッションを走らせた時点で、あなたの脳のスロットは物理的にオーバーフローしています。

そしてオーバーフローした脳は、簡単には元に戻りません。Gloria Mark博士の研究によると、一度中断された後に元のタスクへ完全に集中し直すまでに平均23分15秒かかるそうです [2]。Claude Codeのセッションが3本走っていて、それぞれ10分おきに通知が来るとしたら、あなたの脳は

一度も完全に集中しないまま1日が終わります

AIも実は大変じゃないかな?
AIも実は大変じゃないかな?

切り替えたつもりの脳は、まだ前のタスクにいる

Sophie Leroy(2009)が発見した「Attention Residue(注意残余)」という現象があります。タスクAからタスクBに移っても、認知リソースの一部がタスクAに居残り続けるというものです [3]

しかも厄介なことに、この残留効果は「一瞬で消える調整期間」ではありません。Leroyの実験では、パフォーマンスの低下が次のタスクの実行中ずっと持続しました。特にタスクAが未完了だったり、時間的プレッシャーがあった場合に強くなる。

Claude Codeのセッションなんて、ほぼ全部「未完了で途中経過」じゃないですか。残留効果マシマシです。

AI並列開発は「高級なショート動画」である

さて、ここで本題です。

Claude CodeやCodexで複数セッションを同時に走らせる開発スタイル。これ、認知科学的に見るとショート動画のスクロールと構造が同じなのではないか、という話です。

実際、2024〜2025年にかけてショート動画のヘビーユーザーの脳をEEGやMRIで調べた研究が複数出ています。前頭前野の実行機能に関わる脳波が有意に低かったり [4]、報酬系領域の灰白質体積が増加していたり

。報酬回路が即時フィードバックに最適化されてしまい、「時間をかけて集中する」能力が犠牲になっている可能性が示唆されています。

[5]

これ、AI並列開発でセッションの完了通知を次々チェックする行動と、構造的にどう違うんでしょうね。

セッション3本が走っている。1本目でエラーが出る。確認する。2本目から承認ダイアログが飛んでくる。対応する。3本目が完了した通知が来る。結果を見る。

コンテキストが違う3つのタスクを、通知が来るたびに行き来している。

「いや、実行はAIがやってるんだから、自分は監督してるだけでしょ」と思うかもしれません。しかし、各セッションのメンタルモデルは人間の頭の中で維持しないといけません。コードベースAの状態、Bの依存関係、Cの設計意図。切り替えるたびに、これらを脳内にロードし直す必要があります。

しかもタチが悪いことに、直接コーディングしていた頃はタイピングの遅さが天然のブレーキになっていました。書いている間は強制的に1つのコンテキストに留まる。ところがAIが実行を代行すると、そのブレーキが外れます。「待ってる間に別のセッション見よう」これがコンテキストスイッチを加速させるわけです。

つまりAI並列開発は、ショート動画よりも質が悪い可能性すらある。なぜなら切り替え先のコンテキストが圧倒的に重いから。猫の動画と料理動画の切り替えと、認証基盤のリファクタとフロントエンドのstate設計の切り替えでは、脳への負荷が比較になりません。

5セッション同時に走らせた3時間後の脳
5セッション同時に走らせた3時間後の脳

工場は意図的に生産量を落とす

ここで、工場の話をさせてください。

製造業では品質を維持するために意図的に生産量を制限するのは当たり前のことです。トヨタの「アンドン・コード」は有名ですよね。ラインで異常を検知したら、作業者が紐を引いてライン全体を止める。不良品を流すよりも、止めたほうが安い。

この考え方を、AI並列開発に当てはめてみます。

  • 工場= 人間(あなた)
  • 万能ロボット= AI(Claude Code、Codex等)
  • 製品= コード、PR、設計判断

万能ロボットがいくら優秀でも、良い指示と正確な判断がなければ良い製品は作れません。そして指示と判断を出すのは工場(人間)の仕事です。

生産ラインを5本同時に回したらどうなるか。ロボットは平気です。しかし工場の品質管理担当、つまりあなたの判断力が追いつかなくなる。結果として、5本分のアウトプットは出るけど、そのうち何本かに不良品が混じる。不良品の手戻りコスト(バグ修正、再レビュー、設計のやり直し)を足すと、最初から2本で丁寧にやったほうがトータルのスループットが高い、ということが起こり得ます。

工場が品質のために生産量を落とすように、我々も意図的にセッション数を制限すべきではないでしょうか。

僕のやり方:3〜4セッションまで、しかも条件付き

偉そうなことを書きましたが、僕自身の話をします。

僕はセッションを最大3〜4セッションに制限しています。理由は3つ。

  • ビジネスロジックが巨大で、AI以前に構築された部分も多いのでスタイルが変わってる
  • ロジックが普通に難しい
  • 僕の頭が悪い

3つ目が一番重要です。自分の認知容量の限界を正直に認めたうえで、システムで補っています。

参考画像:筆者のレントゲン
参考画像:筆者のレントゲン

原則1:セッション数ではなく「メンタルモデル数」を制限する

3セッション走らせていても、扱っているメンタルモデルが1〜2個なら、実質的なコンテキストスイッチのコストは低いです。

具体的には、関連するタスクを意図的に束ねて並列実行します。

  • バックエンドAPIと、そのAPIを使うフロントエンドを同時に走らせる
  • メイン開発2セッション+調査・テスト用1セッション

バックエンドAPIとフロントエンドを同時に走らせると、「このAPIのレスポンス構造」という1つの概念が両方のセッションで共有されます。コンテキストスイッチではなく、同じメンタルモデルの別の面を見ているだけ。工場の比喩で言えば、同じ部品の表と裏を同時に加工しているようなもので、まったく別の製品を2つ作っているのとは負荷が全然違います。

原則2:インタラプトを「事後対処」ではなく「事前設計」で消す

これはペパボのあたにさんの記事(「画面に張り付くをやめるためにやったこと」)でも触れられている話ですが、承認ダイアログやエラー通知はコンテキストスイッチのトリガーになります。

あと、当たり前なことですが、やっぱ基本が大事かという以下の設定を常に見直してます。

  • setting.jsonを自分の仕事スタイルに最適化させる
  • 作業キックオフ時に、例外的に必要な許可事項を先に予測して先行承認する(権限などの問題で限界はある)
  • 繰り返しパターンはskill化して、専用エージェントに権限ごと委譲する(大事)

あたにさんの記事が「承認ダイアログを減らそう」というツール側の解決に加えて「どんなインタラプトが来るかを予測して、作業設計の段階で潰す」という人間側の解決です。結果は同じだと思いますが、感覚は違うと思います。

原則3:「監視しない勇気」と「監視すべき判断」を区分する

これは前述のあたにさんの記事の結論とも一致しますが、全てを放置できるわけではありません。

放置していいもの:

  • 定型的なレビュー対応、テスト実行、lint修正
  • skill化されている作業フロー
  • 調査・リサーチ系タスク

張り付くべきもの:

  • アーキテクチャ選択、設計判断
  • 本番環境への操作
  • 初めて取り組む種類のタスク

大事なのは、「放置できるタスクの割合を増やす」ことではなく、「張り付くべきタスクに自分の認知リソースを集中させる」 ことです。

測定なき最適化は存在しない

ただし、ここまで書いておいてなんですが、正直に認めます。

これ全部、僕の感覚の話です。

工場には不良率の測定があります。データがあるから「ここで生産量を落とすべきだ」という判断ができる。でもAI並列開発には「セッション5個のときと2個のときで、バグ混入率にどれだけ差があるか」を測定する方法がまだ確立されていません。

速度を上げるなら、測定ループ(Adoption Rate、Feature Retention、ビジネスリフト)が追従しなければ意味がありません。これは並列数にも同じことが言えます。

「Nセッションが最適」と言いたいのではなく、自分の不良率を観察する習慣を持て、という話です。PRのリバート率、リリース後のバグ件数、レビューでの指摘密度、こういった指標を、並列数と照らし合わせて見る。すると「自分の工場の適正稼働率」が見えてくるはずです。

ちなみに、この半年間自分はrevert 0件でした。

最後に

子どもの頃、テレビ見ながらゲームしながら宿題をしていると、お母さんに怒られました。「一つのことに集中しなさい」って。

あれから何年も経って、大人になって、仕事でAIを5本同時に走らせています。お母さんが見たら多分また怒られます。

でも、もうお母さんに怒ってもらえる歳でもないので、自分で気をつけるしかありません。

AIがどれだけ賢くなっても、「これ本当に大丈夫?」と気づくのは人間の仕事です。コードの意図を理解し、設計の匂いを嗅ぎ、ユーザーへの影響を想像する。そのディテクターとしての役割は、AIの並列数が100本になっても変わらない。むしろ、AIが速くなるほど人間のその判断力の価値は上がっていく。

だからこそ、その判断力の原資である集中力を雑に消耗したくない。

結論は軽いですが、なんか頭がぼ〜とするときは1回休憩しましょう。
そして、1個ずつ倒しておくことも良いと思います。

参考文献