生成AIを安全に並列実行する：速さを事故に変えないタスク粒度と分け方

生成AIエージェントへ複数の仕事を同時に頼むとき、「並列にしてよい仕事」と「順番に渡すべき仕事」を見分け、結果の取り違えや同一ファイルの上書きを防ぐ設計ができるようになります。

📌 主役は「タスク境界」——並列数ではなく、仕事の切れ目を設計する

生成AIの並列実行とは、依存しない複数の仕事を、別々の担当者・コンテキスト・作業領域で同時に進めることだ。レストランで「前菜」「主菜」「デザート」を別の料理人が作るのに似ている。ただし、全員が同じ一枚のまな板で切り始めたら、速い以前に危ない。

この記事の主役である「タスク境界」は、そのまな板を分ける線だ。境界をうまく引けば、調査、テスト、独立モジュールの実装、レビューを同時に進められる。逆に、同じファイルの編集、似た名前の依頼、前工程の結果が必要な仕事を並列化すると、成果物の帰属が曖昧になり、競合や誤採用が起きる。

🎯 動機：速く終わったのに、確認で時間が溶ける

「ログイン周りを確認して」と「認証周りを調べて」を二つのAIに渡したら、よく似た回答が二つ返ってきた。どちらがどの依頼への回答なのか分からない。さらに二者が同じ設定ファイルを直していた——こんな“並列化税”は、実行時間の短縮を簡単に食い尽くす。

問題はAIが複数いることではない。入力、所有範囲、出力名、完了条件のどれかが重なっていることだ。GitHubの公式説明でも、競合は複数人が同じファイルの同じ行を変更した場合や、一方が編集したファイルを他方が削除した場合に発生するとされる。AIもGitの外では魔法使いではなく、同じ種類の衝突を起こす。

🧭 仮説：並列化できるのは「独立性を説明できる仕事」だけ

ここでの仮説は単純だ。二つのタスクが同じ入力を読んでもよいが、同じ可変資源を書かず、片方の結果をもう片方が待たないなら並列化しやすい。宅配便でいえば、同じ地図を見るのは問題ない。しかし同じ荷物を二人が別方向へ運んではいけない。

🔬 検証：タスクの種類を「読む・作る・決める」で分ける

少し込み入った話になるので、コーヒーを一口どうぞ。Google Agent Development Kit（ADK）の ParallelAgent はサブエージェントを同時実行する一方、実行中にサブエージェント同士が自動で対話する仕組みではないと明記している。つまり並列は「相談しながら共同制作」より、独立した仕事を集めるのが得意だ。Anthropicのサブエージェントも、独立したコンテキスト、個別プロンプト、ツール権限を持つ。この設計からも、境界を明記した委任が重要だと分かる。

粒度は「一つのプロンプトに一つの検証可能な成果物」が目安になる。小さすぎると説明と引き継ぎが増え、大きすぎると内部で依存関係が絡む。たとえば「認証機能を全部」は大きすぎるが、「auth.ts の42行目を直す」は周辺仕様を失いやすい。「認証エラーの再現条件を調べ、根拠と再現手順を TASK-101-research.md に記録する」なら、境界も完了条件も明確だ。

📊 結果：安全な並列化は「速度」より先に観測可能性を作る

検証から得られる結論は、最大同時実行数を増やす前に、誰が何をして何を返したかを追跡可能にすべき、ということだ。OpenAIのCodex紹介でも、クラウド上の各タスクはリポジトリを読み込んだ分離環境で実行され、変更の証拠として端末ログやテスト結果を示す設計が説明されている。分離と証跡はセットなのである。

Gitの worktree は一つのリポジトリに複数の作業ツリーを持たせ、複数ブランチを同時にチェックアウトできる。これは厨房を分ける仕切りとして有効だ。ただし、別worktreeにしただけで論理競合が消えるわけではない。最後に統合係が差分、テスト、仕様整合を確認する必要がある。

💭 考察：ファイルを分けても「意味」は衝突する

物理的な競合だけ見ていると、静かな事故を見落とす。エージェントAがAPIの返却名を userId にし、エージェントBがUI側で user_id を期待すれば、編集ファイルは別でも意味が衝突する。これは二人の大工が別々の部屋を作ったのに、ドアと廊下の幅が合わないようなものだ。

したがって、型定義、API契約、DBスキーマ、共通設定、依存ファイルは「共有境界」として先に固定するか、一人だけを所有者にするのがよい。並列化の単位はファイル数ではなく、変更の影響が閉じる単位で考える。ここがタスク粒度の核心だ。

💡 活用事例：探索は扇形、変更は島、統合は一本線

たとえば既存サービスへ検索機能を追加するとしよう。最初に三者が「UIの既存パターン」「API制約」「テスト方針」を読み取り専用で並列調査する。次に契約を一人が確定し、UI、API、テストデータを別worktree・別所有範囲で実装する。最後に統合担当が順番に取り込み、全体テストを行う。広げて、分けて、絞る流れだ。

これは特定製品だけの作法ではない。ADKの並列エージェントも、後段のエージェントで結果を合成するパターンを例示している。並列担当に最終判断まで任せず、集約点を明示するから結果の帰属が保たれる。

🔥 ハマりポイント：同じ依頼を言い換えただけでは分業にならない

最も危ないのは「二人なら精度も二倍だろう」と、似た依頼を区別なく投げることだ。多様な案が欲しいなら並列化自体は有効だが、回答ラベルと評価軸がなければ、確認者の手元には“よく似た二つの何か”だけが残る。

さらに、共有セッション状態への同時書き込みにも注意したい。ADKの公式文書は、並列ブランチが同じ状態キーを更新すると競合や上書きが起こり得るため、異なるキーを使うよう注意している。同じファイルだけでなく、同じキャッシュキー、同じチケット、同じ外部API上の資源も「同じまな板」なのだ。

🚀 取り込み方：今日5分、今週、今月で安全柵を作る

最初から壮大なオーケストレーターを作る必要はない。まず依頼票をそろえるだけで、取り違えはかなり見つけやすくなる。

依頼テンプレートは次の最小形で十分だ。

task_id: SEARCH-API-02
objective: 検索APIの空クエリ時の仕様を実装する
owns: ["src/search/api.ts", "tests/search/api.test.ts"]
read_only: ["src/contracts/search.ts"]
do_not_touch: ["src/config.ts"]
deliverable: "commit + test result"
done_when: "空・空白・通常クエリのテストが通る"

実装タスクを分離するなら、公式Git文書を確認したうえで、たとえば git worktree add ../wt-search -b task/search-api のように専用作業ツリーを用意できる。削除や統合まで自動化する場合は、途中失敗でも既存作業を消さない設計にしよう。

✅ 要点まとめ：並列化する仕事、直列化する判断

最後に持ち帰るべきなのは、「たくさん起動する技術」ではなく「混ざらないように設計する技術」だ。

これを読んだあなたは、タスクを「探索」「独立変更」「依存変更」「統合」に分類し、同じファイルや似た依頼を安易に並列化せず、安全に速くなる境界を引ける。並列数を増やすのは、その後でいい。

参考文献

ここまでの事実確認には、製品ブログだけに寄らず、各ツールの公式文書を優先して参照した。

1. Anthropic, “Create custom subagents” — サブエージェントの独立コンテキスト、プロンプト、ツール権限。
2. OpenAI, “Introducing Codex” — 分離されたクラウド環境、並列タスク、ログ・テスト結果による検証。
3. Google, “Parallel agents - Agent Development Kit” — 並列サブエージェント、後段での集約、共有状態の競合への注意。
4. Git, “git-worktree Documentation” — 複数作業ツリーと複数ブランチの同時チェックアウト。
5. Git, “git-merge Documentation” — マージの動作、競合時の停止と解消手順。
6. GitHub Docs, “About merge conflicts” — 同一行の競合、編集と削除の競合。
7. Microsoft AutoGen, “Teams” — 複数エージェントチームの選択と、複雑性を増やす前に単一エージェントを最適化する指針。