【ITニュース解説】Five Parallel Coding Agents Won't Make You 5x Faster. You Are the Queue

近年、AIコーディングエージェントの進化により、複数のAIを同時に動かしてプログラミング作業を効率化するというアイデアが現実味を帯びてきた。まるで複数の同僚に指示を出すように、同時にいくつかのタスクをAIエージェントに任せられるようになった。しかし、実際に五つのAIエージェントを並行して動かしたとしても、開発者の作業速度が五倍になるわけではないという現実がある。この効率化の限界は、AIエージェントの性能ではなく、開発者自身がボトルネック、つまり作業の「待ち行列（キュー）」になってしまうことに原因がある。

例えば、朝九時に五つのAIエージェントにそれぞれ異なるタスクを与えたとしよう。四十分後には、二つのエージェントは作業を終えてレビュー待ちの状態になっているかもしれない。一方で、一つはエラーで停止し、別の一つはデータベーススキーマに関する質問を投げかけたきり、それ以降何の進捗もないかもしれない。残る一つはまだ作業中である。この状況で、データベースの質問をした四つ目のエージェントは、あなたがその質問に気づくまで三十分以上も無為に待っていたことになる。これはあなたが文字を打つ速さの問題ではなく、五つの異なる作業状況を同時に確認できる目と注意力が一つしかないから起きる現象だ。

多くのツールがAIエージェントの起動を容易にした。複数のエージェントを並行して実行する機能も搭載され、あたかも多くの作業を同時に進められるかのように見える。しかし、AIエージェントが生成したコードの差分を読み解き、レビューする速度は決して上がらない。この限界について、技術者のサイモン・ウィルソンも「すべての自然なボトルネックは、結果をレビューする私の速さである」と指摘している。彼自身も複数のエージェントを動かすが、その目的は低負荷な調査作業や概念実証などを並行して進めることであり、重要な変更をレビューし統合する作業は一度に一つしかできないと明確に述べている。

つまり、五つのエージェントは確かに五人の「作業員」をあなたに与えるが、五人の「レビュー担当者」や「質問応答者」を与えてくれるわけではない。それらはすべてあなた一人に集約される。すべてのAIエージェントは、「作業」→「質問や許可要求でブロックされる」→「あなたを待つ」→「再び作業」という同じサイクルを繰り返す。あなたが質問に答えるのを待っている間、エージェントは何もせず、時間だけが過ぎていく。

この状況は「待ち行列理論」によってうまく説明できる。一つは「リトルの法則」で、安定したシステム内の平均的なアイテム数（ここでは、あなたからの回答を待っているアイドル状態のエージェントの数）は、そのアイテムがシステムに到着する頻度（エージェントが質問を投げる頻度）と、システムに滞在する平均時間（あなたが回答するまでの待ち時間）を掛け合わせたものだと言っている。エージェントの数を増やせば、質問の頻度は当然上がる。もしあなたが質問に答える速さが変わらなければ、より多くのエージェントが同時にアイドル状態になることになり、全体の効率は上がらない。

もう一つは「キングマンの公式」で、単一のサーバー（この場合はあなた）で構成される待ち行列システムでの待ち時間を推定する。この公式の最初の要素はサーバーの忙しさを示す数値で、サーバーの忙しさが50%のときは1だが、80%では4、90%では9と急増する。つまり、あなたが忙しくなるにつれて、待ち時間は最初は緩やかに、しかしある点を境に急激に伸びる。さらに、五つのエージェントがほぼ同時に起動されれば、最初の意思決定ポイントも集中しやすく、質問が一箇所に固まる傾向があるため、待ち時間はさらに長くなる。これは単純なモデルではあるが、五つ目のエージェントを追加するコストは、二つ目のエージェントを追加するよりもはるかに大きな待ち時間コストを伴うことを示唆している。

質問に答えるという行為自体も単純な固定コストではない。一つ一つの質問に答えるたびに、あなたは「そのエージェントが何をしていたか」を思い出す必要がある。これは「コンテキストスイッチ」と呼ばれ、プログラマーにとっては大きな負担となる。研究によると、プログラマーが中断されたタスクに戻る際、コード内の他の場所をナビゲートして状況を再構築するのにかなりの時間を要することが示されている。複数のエージェントを扱う場合、あなたは一日中このコンテキストスイッチを繰り返すことになる。前のエージェントの質問は数十分前に考えていたデータベーススキーマのことであり、次のエージェントからの差分は今週開いていないモジュールに関するものかもしれない。その都度、状況を思い出し、集中力を再構築するコストを支払うことになる。

さらに、頻繁な中断は精神的な負担も増大させる。中断された作業は、通常よりも早く完了する傾向があるものの、その代償として、より高いストレス、フラストレーション、時間的プレッシャー、そして労力を感じることが研究で示されている。AIエージェントとのやり取りにおいても、この「早く作業する」という傾向は、レビューを急いだり、許可プロンプトをろくに読まずに承認したり、コードの差分を半分しか読まずにマージしたりといった行動につながる可能性がある。結果として、待ち行列は短くなるかもしれないが、その代償は開発者のストレスやレビュー品質の低下という形で現れる。

これらの問題に対処するためには、いくつかの対策が考えられる。まず、あなたがレビューできる量に合わせて、稼働させるエージェントの数を制限することだ。マシンやツールが許す最大数ではなく、あなた自身が処理できる上限を見極める必要がある。もし、サイモン・ウィルソンが言うように「一度に一つの重要な変更しかレビューできない」のであれば、コードを生成させるエージェントは一つか二つに限定し、あとは一時間ほど放置しても問題ない調査タスクなどに割り当てるべきだ。それ以外のタスクは待機キューに入れ、スロットが空き次第開始する。

次に、作業を終えて完了したエージェントのレビューよりも、質問や許可待ちでブロックされているエージェントの処理を優先すべきである。完了したエージェントの作業はディスクに保存されており、数分待たされても何も失わない。しかし、ブロックされたエージェントは待っている間、何もできない。だから、まずはブロックされたエージェントの質問に答え、コマンドを承認または拒否し、その後で完了した作業のレビューに取り掛かるのが効率的だ。さらに、ブロックされているエージェントの中でも、最も長く待っているものを優先的に処理することで、全体の待ち時間を最小限に抑えることができる。

通知機能は、この原則に反する傾向がある。通知は直近に発生した事象に対して発せられるため、最後に通知を発したエージェントに注意が向きがちで、数十分前に質問を投げかけたエージェントのことは見過ごされやすい。だからこそ、自分がレビューできる数に稼働中のエージェント数を制限し、最も長く待たされているエージェントから対応するというルールを意識することが重要となる。

これらの課題に対処するためのツールも存在する。筆者が開発するHermes IDEは、各エージェントのステータス（作業中、承認待ち、質問あり、完了、エラー、アイドル）を明確に表示し、あなたからの入力を待っているエージェントの数を集計する「アテンションインボックス」のような機能を提供する。そして、特定のショートカットキーを押すことで、最も長く待っているエージェントのターミナルに直接ジャンプし、そこで質問に答えられるようになっている。これにより、複数のエージェントからの入力を効率的に管理し、待ち時間を減らす助けとなる。

結局のところ、本当に何人のエージェントを効率的にレビューできるのかは、あなた自身の能力による。過去一週間の作業を振り返り、作業時間よりもブロックされて待っていたエージェントが何体いたかを数えてみれば、それがあなたの実際の限界を教えてくれるだろう。この知見はAIエージェントの運用だけでなく、あなたが構築するシステムにおけるキューイング、並列処理、イベント駆動型アーキテクチャといった設計パターンにも通じる重要な教訓となる。