はじめに
AIエージェントを複数立ち上げて、並列で作業させる使い方が広がっています。「1人あたりのAI並列稼働数を増やそう」という発信も見かけるようになりました。
一方で、こんな経験はないでしょうか。
- 並列で回したのに、思ったほど速く終わらない
- 複数のAIの結果を見比べているうちに、頭が疲れ切ってしまう
- 1つのAIとじっくり詰めた方が、結局早く良いものができた
私はこの原因を、タスクの性質と進め方が合っていないことだと考えています。
タスクには、深掘りしていかないと進められない直列型と、ある程度定型化されていて並行して作業しやすい並列型があります。この記事では、2つの型の違いと見分け方、そして直列型を並列型に変えていく考え方を整理します。
タスクは2つの型に分かれる
直列型タスク：深掘りしないと進められない
やってみるまでゴールや手順が見えないタスクです。AIの回答を見て考え、次の問いを投げ、また考える。この往復を1本の流れで積み重ねていきます。
途中の結果によって次の一手が変わるため、作業を分割して同時に進めることができません。
並列型タスク：定型化されていて並行させやすい
ゴールと手順が事前に決まっているタスクです。必要な情報を渡せば、AIがほぼ自走して完了まで進められます。
他のタスクの結果に依存しないので、複数のAIに同時に投げて、あとで結果をまとめて回収できます。
比較表
| 観点 | 直列型 | 並列型 |
|---|---|---|
| 特徴 | 深掘りしながら進める | ある程度定型化されている |
| ゴール・手順 | やりながら見えてくる | 事前に決まっている |
| 途中結果の影響 | 次の一手が変わる | 次の一手は変わらない |
| AIとの関わり方 | 1つのAIと対話を重ねる | 複数のAIに投げて結果を回収する |
| 人間の役割 | 一緒に考える | 仕様を渡してレビューする |
| 例 | 設計、原因不明のバグ調査、企画、方針決め | 定型的な記事作成、テスト追加、警告の修正、調査の下調べ |
見分け方のチェックリスト
AIにタスクを投げる前に、次の5つを確認します。
- ゴールと完了条件を、事前に文章で書けるか
- 作業の手順を説明できるか
- 途中の結果によって、次の行動が変わらないか
- 成果物の良し悪しを判断する基準がはっきりしているか
- 他のタスクの結果を待たずに着手できるか
すべてYesなら並列型です。複数のAIに投げて大丈夫です。
1つでもNoがあれば、直列型の可能性が高いです。並列に投げる前に、まず1つのAIと深掘りして、Noの部分をYesに変えることを考えます。
たとえば「ログイン画面を改善して」は、ゴールも手順も曖昧なので直列型です。一方「パスワード入力欄に表示切り替えボタンを追加し、既存のテストが通ること」まで書ければ、並列型として投げられます。
直列型を並列にするとどうなるか
直列型のタスクを無理に分割して並列に投げると、むしろ遅く、品質も下がります。この傾向は、複数の調査や実践者の発信からも裏付けられています。
文脈が途切れ、判断が食い違う
Devinを開発するCognitionは、マルチエージェント構成への警鐘として「Flappy Birdのクローンを作る」例を挙げています。背景担当と鳥担当にタスクを分けると、互いの文脈がないため、マリオ風の背景と、ゲームに合わない鳥ができあがってしまう、という話です。（Cognition: Don't Build Multi-Agents）
直列型タスクでは、途中で下した小さな判断が後の作業すべてに影響します。分割すると、その判断がバラバラになります。
直列的なタスクでは性能が落ちる
Google Researchは、180通りのエージェント構成を比較した研究を発表しています。並列化しやすい財務分析タスクではマルチエージェント化で約81%改善した一方、順序立てた計画が必要なタスクでは最大70%悪化しました。（Google Research: Towards a science of scaling agent systems）
これはAI同士の協調の話ですが、人間がAIを並列で回す場合にも同じ構造が当てはまります。
人間の判断は並列化できない
Addy Osmaniは、エージェントを何体立ち上げても、方針を決めて結果を取り込む判断は自分という1つの直列処理を通るしかないと指摘し、これを「Orchestration Tax」と呼んでいます。アムダールの法則と同じで、全体の速度は直列部分で頭打ちになります。（Addy Osmani: The Orchestration Tax）
直列型タスクは、判断そのものが仕事の中心です。並列にしても判断の待ち行列が長くなるだけで、速くはなりません。
並列型をうまく回すコツ
並列型タスクは、投げる前の準備でほぼ結果が決まります。
タスク定義をしっかり書く
Simon Willisonは、どこからともなく届いたコードのレビューは大変だが、自分が書いた仕様から始まったコードならレビューはずっと楽だと書いています。（Simon Willison: Embracing the parallel coding agent lifestyle）
ゴール、完了条件、守るべきルールを最初に渡しておくと、AIの迷走が減り、レビューの負担も下がります。
作業場所を分ける
同じファイルやブランチを複数のAIが触ると、変更が衝突します。Git Worktreeなどで、タスクごとに作業場所を分けておきます。
並列数は自分がレビューできる数までにする
並列で回したタスクも、最後は人間がレビューします。レビューが追いつかない数を回しても、未確認の成果物が積み上がるだけです。忙しく感じることと、成果が出ていることは別物です。
直列型は深掘りすると並列型になる
ここまで直列型と並列型を分けてきましたが、この2つは固定されたものではありません。直列型のタスクも、深掘りを繰り返すうちに並列型へ変えられます。
定型化とは、直列型を並列型に変換すること
初めて取り組む作業は、ほぼ必ず直列型です。AIと対話しながら、何をゴールにするか、どの順番で進めるか、どこで失敗しやすいかを探っていきます。
同じ種類の作業を何度か深掘りすると、手順や判断基準が言語化されていきます。それをテンプレート、プロンプト、スキルなどの形で残せば、次からはチェックリストの5項目をすべてYesにできます。つまり並列型として投げられるようになります。
- 直列型として、AIと深掘りしながら進める
- うまくいった手順や判断基準を言語化する
- テンプレートやスキルとして残す
- 次からは並列型として、複数のAIに任せる
直列で型を作り、並列で回す
こう考えると、直列と並列はどちらかを選ぶものではありません。直列の深掘りで型を作り、型ができたものから並列に流していく。この循環が、AI活用の生産性を上げていく仕組みだと考えています。
逆に言えば、並列で回せるタスクが少ないと感じるなら、それはまだ型になっていない直列型タスクが多いということです。焦って並列化するより、まず1つを深掘りして型を作る方が、結果的に近道になります。
まとめ
- タスクには、深掘りしないと進められない直列型と、定型化されていて並行させやすい並列型がある
- AIに投げる前に、チェックリストでどちらの型かを見極める
- 直列型を無理に並列化すると、文脈が途切れ、判断の待ち行列が長くなるだけ
- 並列型は、タスク定義をしっかり書いて、レビューできる数だけ回す
- 直列型も、深掘りを繰り返して型を作れば並列型に変えられる
並列で回せるタスクを増やしたいなら、まずは目の前の直列型タスクを1つ、じっくり深掘りするところから始めてみてください。