AIを同時に何人も動かす｜速くなる分け方・遅くなる分け方

AIを何人も同時に動かすと速くなる——半分は本当で、半分は違います。分けていいのは、お互いの結果を知らなくても完成できる仕事だけ。前の答えを待つ仕事まで分けると、確認とやり直しが増えて、一人でやるより遅くなります。

先に、ことわっておきます。この記事に出てくる「一人」「三人」は、人間のことではありません。AIのセッション(=AIとやり取りする窓口)や、エージェント(=仕事を任せるAIの担当)の数のたとえです。

この記事で分かることは3つです。速くなる分け方、費用と時間の違い、そのまま使える実行手順です。

AIの並列実行は「待たない仕事」を同時に進める方法

AIの並列実行(=同時に何本も動かすこと)とは、複数のAIに別々の仕事を渡し、同時に進めることです。ただし本質は、人数を増やすことではありません。互いを待たずに完了できる仕事を、同時に進めることです。

Anthropic(Claudeを作っている会社)は、並列化には2種類あると整理しています(Building effective agents)。

• 仕事を分ける型(sectioning): 独立した小さい仕事に分けて、同時に走らせる。速くしたいときに使う。
• 同じ仕事を重ねる型(voting): 同じ問題を複数のAIに解かせて、答えを比べる。間違えたくないとき、視点を増やしたいときに使う。

この2つは目的が違うので、混ぜないでください。「速くしたい」なら分ける型、「確信を持ちたい」なら重ねる型です。

分けてよいかの判断は、一問で済みます。**担当Aが終わらなくても、担当Bは最後まで書けるか。**答えが「はい」なら、分ける候補です。

速くなる分け方と、遅くなる分け方

たとえば旅行記事を作るなら、「持ち物を調べる」「移動時の注意を調べる」「家族向けの困りごとを挙げる」は同時に進められます。どの担当も、ほかの原稿を待たずに結果を出せるからです。最後に一人が重複を消し、記事へまとめます。

反対に、「構成を決める」「その構成で本文を書く」「本文に合う題名を付ける」には順番があります。本文担当は構成を待ち、題名担当は本文を待ちます。三人を同時に動かしても、前提が違う原稿が三つできるだけです。

Anthropicが自社の調査システムを作った経験でも、向き不向きは同じでした。複数の独立した方向を同時に調べる幅広い調査はマルチエージェント(=複数AIの分業)に向く一方、共有の前提や依存関係(=前の結果を使う関係)が多い仕事は不向きだと報告しています(How we built our multi-agent research system)。Claude Codeの公式ガイドも、順番のある仕事や同じファイルの編集には、チーム実行より1本のセッションの方が向くとしています(Orchestrate teams of Claude Code sessions)。

もうひとつの落とし穴が「同じ場所の編集」です。二人のAIに同じファイルを直させると、あとから保存した方が先の変更を消してしまいます。公式ガイドは、担当ごとに別のファイルの集合を持たせるよう勧めています。どうしても同じリポジトリ(=コードの保管庫)を並行で触るなら、git worktree(=同じ履歴を共有したまま、作業フォルダだけ分ける仕組み)を使うと、一方の編集が他方の作業ファイルに直接触れません(Run parallel sessions with worktrees)。

見分け方を早見表にします。

見分けるポイント	分けて速くなる仕事	分けると遅くなる仕事
待ち	ほかの結果を待たずに提出できる	前の答えが出ないと書き始められない
例	調査テーマ別・レビュー観点別・原因の仮説別	構成→本文→題名のような順番仕事
場所	担当ファイル・フォルダが別々	同じファイルを全員で編集する
前提	短い指示だけで完結する	全員が同じ長い文脈を読む必要がある
最後	まとめ役一人が統合する	統合のたびに食い違いを直す

ありがちな失敗例も挙げます。記事作りを「冒頭」「中盤」「まとめ」と場所で分けると、三本とも読者像や言葉の使い方が少しずつずれ、つなぎ直す作業で遅くなります。場所ではなく独立した役割(具体例を集める・反対例を探す・初心者が迷う言葉を探す)で分け、本文を書く担当を一人に固定すると、話の流れが崩れません。

終わるのは速くても、使う量は増える(前の版の訂正)

この記事の前の版には「同時に走らせたことだけで、使う量が増えるわけではありません」と書いていました。これは正確ではなかったので、訂正します。

Claude Codeの公式ドキュメントは、複数のセッションやサブエージェント(=子担当のAI)を同時に動かすと、トークン(=AIが読み書きする量の単位。料金のもとになる数)の使用量が増える、とはっきり書いています(Run agents in parallel)。担当が増えるほど、それぞれが指示を読み、調べ、結果を返すからです。

Anthropicの実測では、エージェントは普通のチャットの約4倍、マルチエージェント構成は約15倍のトークンを使いました。ただし、これは同社のResearchシステムで測った値です。どんな作業でも15倍になる、という意味ではありません。

一方で、時間は大きく縮むことがあります。同社は複雑な調査で、まとめ役が3〜5の子担当を同時に動かす形へ変え、調査時間を最大90%短縮したと報告しています。これも同社の調査システムでの結果で、あなたの作業がそのまま90%縮む保証ではありません。

整理すると、見るべき数字は3つに分かれます。

• 経過時間: 並列でいちばん縮めやすい数字。
• 利用量(トークン): 担当を増やすほど増えやすい数字。料金は契約と製品で変わるので、使う時点の公式案内で確認してください。
• 調整の手間: 依頼文づくりと、最後の統合にかかる時間。人数を増やすほど重くなり、増やした人数のぶん比例して速くなるわけではありません(Orchestrate teams of Claude Code sessions)。

迷わない実行手順

1. 完成物を一文で決める(例:「初心者向けの持ち物チェック記事を1本」)。
2. 仕事を小さく分け、各項目に「ほかの結果を待つか?」と書き込む。
3. 待たない項目だけを同時に始める。待つ項目は順番に並べる。
4. 各担当への依頼に、次の4点を必ず書く。目的/出力の形/担当範囲(使ってよい情報源・道具)/触らない範囲。Anthropicは、この説明が足りないと担当同士の重複や抜けが起きたと報告しています(How we built our multi-agent research system)。OpenAIも、Codexでは範囲がはっきりした仕事を複数の担当へ同時に割り当てることを勧めています(Introducing Codex)。
5. コードを直させるなら、担当ファイルを分けるか、worktreeで作業場所ごと分ける。
6. まとめ役を一人に固定する。最後にその一人が、重複・矛盾・抜け・テスト結果を確認してから統合する。AIが作ったコードは、取り込む前に人が確認します(Introducing Codex)。

調査だけの並列なら、もっと簡単です。独立した調べものを子担当に同時に渡し、親(=まとめ役のAI)が結果を統合する形が、公式ドキュメントでも「調査経路が互いに依存しないときに最も機能する」とされています(Create custom subagents)。ただし、子が返す詳しい結果は親の読み込み量も増やすので、報告は要点だけ返させるのがコツです。

よくある質問

AIは多ければ多いほど速くなりますか?

いいえ。独立した仕事が十分にある範囲では速くなりますが、人数が増えるほど連絡・統合・衝突が増え、追加した人数の効果は小さくなっていきます(Orchestrate teams of Claude Code sessions)。最初から最大人数にせず、はっきり分けられる仕事の数から人数を決めてください。

同じ質問を複数のAIへ頼むのも並列実行ですか?

はい。ただし目的が違います。時間を縮める使い方ではなく、違う視点の答えを比べて確信度を上げる「重ねる型(voting)」です(Building effective agents)。どの答えを採用するかの基準と、比べる担当を先に決めておきます。

並列実行すると料金や利用量は増えますか?

増える可能性が高いです。複数のセッションや子担当は、それぞれがトークンを使います(Run agents in parallel)。経過時間が縮むことと、利用量が増えることは別の話として数えてください。具体的な料金は変わりやすいので、その時点の公式案内で確認してください。

複数のAIに同じファイルを直させてもよいですか?

原則として避けてください。担当ファイルを分けるか、worktreeなどで編集場所を隔離し、最後に一人が差分とテスト結果を見て統合します(Run parallel sessions with worktrees)。

最初は何人で試すのがよいですか?

どんな場合にも合う人数はありません。まず、まとめ役一人と、互いを待たずに完了できる少数の担当から始めるのが安全です。公式資料にある「3〜5」といった数は、特定の製品・特定の用途での目安であり、すべての場面の正解ではありません(How we built our multi-agent research system)。

まとめ

• まず「ほかの結果を待たずに終えられる仕事」だけを2〜3個選び、小さく並列を試す
• 経過時間だけでなく、トークンの利用量と、統合にかかった時間もメモして比べる
• まとめ役(最後に検証する担当)を一人に固定してから、人数を増やすか決める

公式一次情報

確認日: 2026-07-25

• Building effective agents: 並列化には仕事を分けるsectioningと、同じ仕事を重ねるvotingの2種類があると整理した公式解説
• How we built our multi-agent research system: マルチエージェントの向き不向き、トークン約4倍・約15倍、調査時間最大90%短縮などの実測報告
• Run agents in parallel: 複数セッション・サブエージェントの同時実行でトークン使用量が増えることと、方式の選び方
• Create custom subagents: 独立した調査を子担当で同時に進め、親が統合する形が最も機能するという説明
• Orchestrate teams of Claude Code sessions: チーム実行の向き不向き、人数を増やしても比例して速くならないこと、同じファイル編集を避ける指針
• Run parallel sessions with worktrees: git worktreeで作業フォルダを分け、並行編集がぶつからないようにする方法
• Introducing Codex: タスクごとの隔離環境、範囲を明確にした依頼、統合前に人が検証する必要性