最近、AIを使って複数のプロジェクトを並行して開発している。Claude CodeやCodexに実装を頼み、仕上がるのを待つ間に別のプロジェクトへ移る。そちらでもAIに実装を頼んで、また次のプロジェクトへ。僕はさしずめ、いくつものプロセスを捌くスケジューラである。
プロジェクトが1つしかないときでも、事情はあまり変わらない。git worktreeで作業ツリーを分け、同じリポジトリの中で別々のタスクを並行してAIに任せているからだ。結局のところ、僕が並べているのはプロジェクトというより、タスクなのである。
実際、コードを書く時間は大幅に減った。数時間がかりだった実装が、お茶を淹れている間に片づくことも珍しくない。ひと昔前の僕が聞いたら、腰を抜かすに違いない。
ところが、最近どうにも腑に落ちないことがある。コードを書くのは圧倒的に楽になったはずなのに、なぜか以前より疲れるのだ。
むろん、単純に作業量が増えているだけかもしれない。調子に乗ってプロセスを増やしたのは、ほかでもない僕自身だ。とはいえ、複数のAIを回しながら開発していると、それだけでは片づかない妙な疲れ方をしている気がする。
シングルコアの頭
たとえば、あるプロジェクトでは認証まわりを実装していて、別のプロジェクトではデータベースをいじっている。さらに別のプロジェクトでは、UIを直している。同じリポジトリの中でも、worktreeごとに別の機能が同時に進んでいる。それぞれのAIに指示さえ出しておけば、開発は同時に進む。ここまではいい感じだ。
問題は、AIが実装を終えたあとにやってくる。今度は僕が、その中身を検めなければならない。認証まわりのコードを読むには、そのプロジェクトの認証フローや設計を思い出す必要がある。データベースの変更を見るなら、既存のテーブル構造と影響範囲を頭に載せ直さなければならない。
AIは、それぞれのプロジェクトの文脈を律儀に抱えたまま作業してくれる。しかし、僕の頭はそうはいかない。AIが何台並ぼうと、レビューする側はシングルコアのままなのだ。タスクを移るたびにコンテキストスイッチが起き、新しいタスクの文脈を一から載せ直す羽目になる。
さっきまで何を考えていたんだっけ。そう独りごちながら、コードや会話の履歴を読み返すこともしばしばある。これが、存外に堪えるのだ。
うろ覚えの1冊
そういえば、似たような話をどこかで読んだ覚えがある。ヨハン・ハリの『奪われた集中力』だ。スマートフォンやSNS、現代の働き方が、人間の集中力をいかに蝕んでいるかを扱った本だったと記憶している。
その中に、作業を切り替えるだけでも認知的なコストがかかる、という話があった気がする。たしか、メールやスマートフォンの通知に反応するたびに集中が途切れ、元の作業に戻るにも時間がかかる、といった内容だった。……と書いてはみたものの、正直なところ自信はない。
なにせ記憶が曖昧なので、関連する研究をAIに調べてもらった(集中力の本の内容を、集中力を奪っている当のAIに訊くのも妙な話だが)。すると、どうやら「タスクスイッチング・コスト」という概念があるらしい。人間が異なるタスクを切り替えるときには、画面や作業を変えるだけでなく、認知的な負荷が発生するというものだ。
さらに面白い研究が見つかった。2009年にSophie Leroyが発表した「Why is it so hard to do my work? The challenge of attention residue when switching between work tasks」という論文である。終わっていない作業から別の作業に切り替えると、前の作業に注意が残り、次の作業のパフォーマンスが落ちる。この現象を「注意残留(Attention Residue)」と呼ぶそうだ。
身につまされる話である。1つのタスクについて考えているところに、別のAIから実装完了の知らせが届く。そちらのコードを読んでいると、また別のAIから確認を求められる。画面の上では作業を切り替えていても、頭の中ではまだ前のタスクのことを考え続けているのかもしれない。
先ほどの比喩で言えば、切り替えたつもりで、前のプロセスがまだ裏で居座っているわけだ。もちろん、この研究はAIコーディングを対象にしたものではない。それでも、僕が感じている疲れの正体を探る手がかりにはなりそうなのだ。
通知を自給自足する
もう1つ面白かったのが、2015年に発表されたスマートフォンの通知に関する研究だ。スマートフォンを実際に操作しなくても、通知が届くだけで、注意力を要する作業の成績が悪化することが確かめられている。触らなくても駄目らしい。
そう考えると、AIコーディングエージェントは、新手の通知の発生源になっているのかもしれない。「実装が完了しました」「テストが失敗しました」「確認してください」。こうした知らせが届くたびに、いまやっている作業から注意がそれる。
しかも厄介なことに、メールやSlackと違って、この通知は自分でいくらでも増やせてしまう。AIに仕事を任せている間、手持ち無沙汰でいるのはもったいない気がする。だから別のAIにも仕事を頼む。すると案の定、そのAIからも確認を求められるようになる。
効率化しているつもりで、自分の集中力を奪う仕組みをせっせと拵えている。通知の自給自足である。我ながら、勤勉な方向に間違えたものだ。
書く代わりに判断する
そもそも、AIで開発の何が変わったのだろうか。以前は、機能を作るために自分でコードを書いていた。設計を考え、書いて、動かして、直す。時間はかかるが、その間はおおむね1つの問題と向き合い続けていた。
翻って今は、自分でコードを書く時間がめっきり短くなった。その代わりに、AIへの指示、実装内容の確認、設計上の判断、修正の依頼といった作業が増えている。しかも、それを複数のタスクで並行してこなしている。
考えてみれば当たり前の話で、減ったのはコードを書く時間であって、考える必要がなくなったわけではない。むしろ、AIが矢継ぎ早に実装を進めてくれるぶん、人間が判断を迫られる回数は増えているのかもしれない。手を動かす仕事が、判断を下す仕事に置き換わったのである。
とりわけ気になるのは、AIがコードを生成する速度と、人間がそれを理解して判断する速度が、必ずしも釣り合わないことだ。AIが短時間で大量のコードを書いてくれても、それを読み解くには相応の時間がかかる。そこに複数タスクの切り替えまで加われば、骨が折れるのも道理なのだ。
こうなると、いわゆる地頭の良さが露骨に効いてくるように思う。いくつもの文脈を頭に載せたまま、AIの書いたコードを読み、すぐに判断を下す。これはもう、手の速さではなく頭の回転の勝負だ。以前なら、手を動かす時間が長いぶん、凡庸な頭でも粘り腰でなんとか帳尻を合わせられた。ところが、書く工程をAIが肩代わりした途端、残ったのは判断の速さと正確さだけで、ごまかしが利かない。
白状すると、僕は地頭がいいほうではない。切り替えのたびに前の文脈を取りこぼし、同じコードを何度も読み返している。AIという強力な道具が誰にでも配られた結果、かえって人間の側の能力差が目立つようになったのではないか。少なくとも僕には、そんな気がしてくる。だとしたら、なんとも皮肉な話である。
効率化の、その先
誤解のないように書いておくと、AIで複数のプロジェクトを進められるようになったこと自体は、甚だありがたい。以前なら時間が足りずに諦めていたアイデアも、形にできるようになった。個人開発に限った話ではない。本業のほうでも、数年前の感覚からすればありえない速度で開発が進んでいる。現に作れるものは増えているし、生産性が上がっている実感もある。
効率化そのものには、たしかに成功したのだ。AIが実装している間に別のタスクを進めれば、待ち時間は消え、手が止まることもない。問題は、それが最適解かどうかである。切り替えのたびに認知的なコストを払っているのなら、この効率化には見えない代償がついて回る。速くはなった。では、どう回すのがいちばんいいのか。
最適解の候補は、いくつか思いつく。まず、1つのタスクに腰を据えて、まとまった単位で進めることだ。プロジェクトを1つに絞るだけでは足りない。worktreeでタスクを並べていれば、切り替えは同じリポジトリの中でも起きるからだ。あるいは、AIは並列に回しつつ、結果を検める時間だけをまとめて取るだけでも違うのかもしれない。プロセスを減らすか、レビューの時間をまとめて割り当てるか、である。
待ち時間の使い道を変える手もある。AIが実装している間に、別のタスクのコードを読むのではなく、いま任せている機能の次の仕様を詰める。あるいは、ユーザーにヒアリングをして、そもそも何を作るべきかを確かめる。どちらもAIにまるごと任せるのは難しく、しかも頭の中の文脈を入れ替えずに済む仕事だ。手が空いたからといって、別のプロセスを立ち上げる必要はないのである。
どれが最適解なのかは、正直なところまだよく解らない。案外、タスクの大きさや、その日の頭の調子で変わるものなのかもしれない。そもそも、AIを使った並列開発と認知的な負荷の関係を正面から調べた研究がどの程度あるのかも、気になっている。
ついでに白状しておくと、この記事も、裏でAIに実装とテストを走らせている待ち時間に書いている。仕様を詰めるでもなく、ヒアリングをするでもなく、である。書いている間も、頭の片隅ではテストが通ったかどうかがずっと気になっている。注意残留の、生きた標本というわけだ。
頭は並列にならない
AIのおかげで、コードを書くのは間違いなく楽になった。1人で複数のプロジェクトを回すことも、以前よりずっと現実的になっている。
でも、人間の頭まで並列処理できるようになったわけではない。AIがいくら速くコードを書いても、それを理解して判断するのは、結局のところ僕自身だ。これからのAI開発では、コードを速く書くことよりも、自分の集中力をどう守るかのほうが、よほど大事になってくるのかもしれない。
と、殊勝なことを書きながら、今日も僕は複数のAIに実装を頼んでいる。ターミナルのタブは、まだ増え続けている。
参考資料
- ヨハン・ハリ『奪われた集中力』福井昌子訳(作品社、2025年)
- Leroy, S. (2009). Why is it so hard to do my work? The challenge of attention residue when switching between work tasks
- Stothart, C., Mitchum, A., & Yehnert, C. (2015). The attentional cost of receiving a cell phone notification