- Claude Code、OpenAI Codex、Cursor などのエージェント型CLIツールが主流として定着するにつれ、複数のAIエージェントを同時に実行して並列で作業する**「並列コーディングエージェント」**の活用が増加
- 多くのエンジニアがこれによって生産性を高めており、単純な開発を超えてリサーチ・保守・指示ベースの作業などにも適用可能
- しかし、コードレビューの速度がボトルネックになったり、**集中の流れ(flow)**が途切れたりするという懸念も存在
- 熟練した開発者ほど、マルチタスクとコードレビューを並行する能力のおかげで、並列エージェント活用に慣れている傾向がある
- 並列エージェント作業では、テスト、小さな作業単位、リファクタリング、コードレビューといった基本的なエンジニアリング慣行が、信頼性と品質維持の中核要素
並列AIエージェントの拡大と開発スタイルの変化
- Claude Code、OpenAI Codex、Cursor などのエージェント型CLIツールが主流化する中で、エンジニアが複数のエージェントを同時に実行して並列に作業を進めるトレンドが見られる
- Anthropicのエンジニア Sid Bidasaria は対談の中で、複数のエージェントを動かして生産性を高めたと述べた
- AIエンジニアリングの専門家 Simon Willison は「並列コーディングエージェントのライフスタイルを受け入れる」という記事で次のように説明
- 当初はAI生成コードのレビューがボトルネックになるとして懐疑的だったが、ここ数週間で自然に並列エージェントを使い始めた
- 一度にレビューして適用できる重要な変更は1つだけだが、認知負荷を大きく増やさずに並列で着手できる作業が増えている
- 並列エージェントの活用はリサーチ、保守作業、指示ベースの作業で特に有用
従来のソフトウェアエンジニアリング慣行への影響
- 並列エージェント作業は、数十年にわたるソフトウェアエンジニアリング慣行を覆す可能性がある
- 一度に1つの問題に集中する「シングルスレッド」な同僚より、複数のエージェントを同時に動かすエンジニアのほうが生産的であるなら十分にあり得る
- AI以前の時代のエンジニアリングでは、フロー(flow、没入)状態の維持が中核だった
- 構成要素の理解 → ソリューションの構築・検証と反復 → プルリクエストの提出、またはマージとデプロイ
- この過程の中断は没入を妨げ、再突入に時間がかかる。そのため多くの開発者は集中時間の確保を重視してきた
- しかし、これはすべての高生産性エンジニアに当てはまるわけではなく、一部のエンジニアはマルチタスクやコンテキストスイッチに長けている
- マネージャー時代に知っていた最も生産的なエンジニアは、頻繁にコンテキストを切り替えながら複数の作業を同時に処理していた
- 1日の流れ：コードレビュー → コーディング作業 → スタンドアップ → コーディング
（実際にはコードレビュー依頼、支援要請、管理者からの質問など継続的な割り込みが発生）
シニアエンジニアと並列エージェントの適合性
- シニア以上のエンジニアは並列AIエージェント作業に自然に適応する可能性がある
- チームメンバーの並列ワークフローを頭の中で維持できる
- 2〜5個のワークストリームにまたがってコードレビューを行う
- 集中が継続的に途切れる状況でも前進する割り込み対応能力を身につけている
- 同僚への指示能力があり、委任や緊急作業の説明もできる
- 文章力も備えており、コードレビュー、RFC文書、チケット作成、同僚の作業への批評など効果的な書面コミュニケーションが可能
- AIエージェントを活用すれば、生産性向上を望むエンジニアが、優れた技術リーダーに必要な資質を身につけられる可能性がある
- これまで並列エージェントをうまく使っている人の多くは、主にシニア以上のエンジニアに見られる
- ただし、Flaskの作者 Armin Ronacher は、以前ほど並列エージェントを使わなくなったと述べている
並列エージェント作業の未来と不確実性
- いまやすべての開発者がコーディングエージェントで並列作業を始められる新しい時代に入った
- これが実際にエンジニアの生産性を高めるのか、それとも単に生産的だと感じさせるだけなのかは不確実
- 一度に1つずつ集中するエンジニアのほうが、時間の経過とともにより信頼できるソフトウェアを生み出す可能性があり、
- 並列エージェント作業がより多くの問題や手戻りにつながって、利点を打ち消す可能性もある
- それでも、より多くの開発者が並列エージェントを試すと予想される
AIエージェント作業におけるソフトウェアエンジニアリングの基本の重要性
- AIエージェントを使う場合でも、ソフトウェアエンジニアリングの基礎知識は重要
- テスト：すべてのサイドプロジェクトにユニットテストを適用（検証なしに自分の作業を信頼しない）
- 小規模で説明的な作業：小さな範囲の作業を説明し、例を示す
- リファクタリング：3〜4回目の作業ごとに、エージェントが書いたコードのリファクタリングを指示（メソッド抽出、新しいクラスへの移動など）
- レビュー：エージェントの作業を追跡する
- 小規模な作業は自分で実施：IDEを開いたままにして、数行の変更は自分で行い、コードベースの認識を維持する
- 他のエンジニアも同様の経験を語っている：エージェントにすべてのテストを通過するよう「強制」するエンジニアリング慣行が、より良い結果につながる
- AIエージェントは非決定的で、ある程度信頼しにくいため、こうした慣行によってはるかに信頼性の高い実践的アプローチが可能になる
7件のコメント
Armin Ronacher が言及したように、レビュアーの認知負荷がボトルネックだと思います。すでにコーディングやほかの作業で忙しい場合は、適用できないということですよね。むしろ、予想外の品質低下や検収時間の増加など、逆効果になる可能性もあると思います。
開発者にとって、AI 活用と生産性向上という名目でマルチタスクが一般化してしまうのではないかと懸念しています
fe、be、data みたいに3つのエージェントまではいけるけど、それ以上は頭がついていかないです T_T
AIのおかげでADHDはもうニューノーマルですか？ 病院に行かなくてもいいですか？
疲れない同僚レビュアーだと思って、ひたすら殺したり生かしたりしながら複数使ってます（笑）
> マネージャー時代に知っていた最も生産的なエンジニアは、コンテキストスイッチを多く行いながら複数の作業を同時に処理していた
> 集中が継続的に妨げられる状況でも前進を生み出す、割り込み処理能力を身につけていた
vs
> コンテキスト切り替えを減らし、1つの仕事を終えてから次へ進み、記憶は外部ツールに記録すること
> 頻繁な文脈切り替え（context switching）は前頭前野・頭頂葉の制御負荷を増加させる
> - https://ja.news.hada.io/topic?id=24026
個人的には、マルチタスクは毎回やりたくなるのですが、あまりに疲れるので警戒するようになりました。
無理なく続けられるシンプルな方法が良い気がします.
人間の脳は並列じゃないのに（笑）。どうせ最終的なレビューは順番にやるなら、並列化にそこまで大きな意味はないでしょう。
開発チームのメンバーではなくPMだと考えて並列で進めると、だいたいうまく合っていました。