Claude Codeの並列実行の使い分け — 5手段を3つの問いで選ぶ

Claude Codeで複数のタスクを同時に進める手段は5つあります。subagents、agent view、agent teams、dynamic workflows、Projectsです。違いは性能の優劣ではなく、誰が計画を持ち、ワーカーがどこで動くかにあります。

選び方は3つの問いに絞れます。誰が調整するのか、ワーカー同士が会話する必要があるのか、同じファイルを触るのか。この記事では3問で5手段を振り分け、worktreesや/batchなどの補助ツールの位置づけまで確認します。

5手段は「誰が計画を持つか」で分かれる

5手段はどれも中身はClaudeのセッションです。別のツールを混ぜたいときは、MCPサーバーとしてClaudeに見せる形になります。違うのは、あなたがどこまで関わり続けるかと、処理が手元のマシンで動くかクラウドで動くかです。

計画の持ち主で並べ直すと、境界がはっきりします。subagentsとagent teamsではClaudeが一手ずつ判断し、workflowsではスクリプトが判断し、agent viewではあなたが判断します。Projectsは、あなたが「何をやるか」だけを伝え、割り振りをClaudeに任せる形です。

3つの問いで選ぶ

問い1: 誰が調整するのか

調整役は4通りに分かれます。

• Claudeが1つの会話の中で委任し、結果を集める: subagents
• あなたが独立したタスクを渡し、後で見に来る: agent view
• Claudeが計画し、割り当て、ワーカー群を監督する: agent teams
• Claudeの一手ごとの判断ではなく、スクリプトが計画を持つ: dynamic workflows

workflowsだけは、中間結果がClaudeのコンテキストに溜まりません。ループも分岐も中間結果もスクリプト側にあり、Claudeのコンテキストには最終的な答えだけが残ります。大規模な調査や移行で効くのはこのためです。

問い2: ワーカー同士が話す必要はあるか

話せる範囲は手段ごとに違います。

「話す」必要の中身は、たいてい2種類です。進捗や発見を渡したいだけなら、セッション間メッセージで足ります。互いの結論に反論させたいなら、agent teamsの領分です。反論の実例はAgent Teams並列コードレビューの実践にあります。

問い3: 同じファイルを触るか

同じファイルを触るなら、作業ごとに別のチェックアウトを持たせるのが基本です。手段によって、隔離の面倒を誰が見るかが変わります。

agent teamsだけは「隔離で守る」ではなく「分担で守る」設計です。同じファイルを2人が編集すると上書きが起きるため、1人が1組のファイルを持つよう、最初に頼みます。

手段ごとの入口

最初の一歩は、手段によってかなり重さが違います。

agent viewは、シェルからも行を足せます。

claude agents
claude --bg "investigate the flaky login test"

agent teamsは既定で無効で、有効化はsettings.jsonのenvで行います。

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

有効にすると、普通の委任の挙動も変わります。Claudeが名前を付けて生成したサブエージェントは、チームメンバーとして起動します。頼んでいないのにチームが組まれる可能性があるため、subagentsだけを使いたい環境では有効化の影響を知っておく価値があります。非対話モード(-p)ではメンバーは生成されません。

補助であって手段ではない3つ

次の3つは、並列に動かすための補助です。調整の仕方を決める手段ではありません。

• worktrees: 各セッションに別のgitチェックアウトを与える。詳細はWorktree実践ガイド
• セッション間メッセージ: 自分で動かす複数のセッションの間で、発見と状態を渡す。@メンションでの連携が入口
• /batch: 大きな変更を5〜30個の独立した単位に分け、worktree隔離のサブエージェントに割り当てるスキル

/batchは、subagentsとworktreesの組み合わせ方を1つ決めたものです。別種の調整方式ではないため、「5手段のどれか」を選ぶ段階で迷う対象ではありません。使いどころは/batchコマンドの解説にまとめています。

並列に見えても、手段に入らないものもあります。バックグラウンドのbashコマンドは、シェルコマンドを1つ流すだけでエージェントを生成しません。ルーチンはクラウドでの定期実行で、手元との並列とは性質が違います。

選び間違えやすい組み合わせ

規模・プラン・コストの条件

数字で比べると、手段ごとの上限と条件の違いが見えます。

コスト面では、どの手段も同時に走らせるほどトークンを使います。agent viewは10個並べれば、1個のときの約10倍の速さでクォータを使います。agent teamsはメンバーごとに別のコンテキストを持つため、人数に比例して増えます。

workflowsには、巨大な実行への注意があります。エージェントが25個を超えるか、見込みのトークン総量が150万を超えると、Large workflowの警告が出ます。大きな仕事の前に、1ディレクトリ分のような小さな範囲で試すと見積もりやすくなります。サイズの目安は/config workflowSizeGuideline=smallのように指定でき、既定はmedium、Proプランではsmallです。

利用条件の違いも、選択に直結します。

• agent teams: 実験的で既定は無効。対話セッションが必要
• agent view: リサーチプレビュー。セッションは手元のマシン上にあり、シャットダウンで止まる
• Projects: ProとMaxの公開ベータ。TeamとEnterpriseは対象外。ターミナルのCLI、VS Code拡張、JetBrainsプラグインからは使えない
• dynamic workflows: 全有料プランで利用でき、Proでは/configの行から有効にする

迷ったときの出発点

実務で迷う場面は、おおよそ次の2つに集約されます。

1つ目は、サブエージェントでは足りないが、チームを組むほどでもない場面です。各タスクが独立していて、あなたが状態を見て必要なときだけ入る運用なら、agent viewに行を並べる形が合います。結果の突き合わせまで要るならworkflowsです。

2つ目は、数日にわたる継続作業です。ターミナルを開いたままにする前提なら、agent viewとworktreesで足ります。マシンを閉じても進めたいなら、Projectsの出番です。

どの手段でも、起動のしかたは「何をいくつ、どの粒度で任せるか」を言葉にすることから始まります。たとえばagent teamsなら、公式の例のように、役割と範囲と観点まで書いた生成指示が土台になります。

Spawn a security reviewer teammate with the prompt: "Review the authentication module
at src/auth/ for security vulnerabilities. Focus on token handling, session
management, and input validation."

別の手段を試すときも、「誰が・どの範囲を・何を返すか」を最初に文にしておくと、手段の向き不向きが早く見えます。

まとめ

3問のうち最初に答えるべきなのは、誰が計画を持つかです。あなたが持つならagent view、Claudeが一手ずつならsubagentsかagent teams、スクリプトならworkflows、会話ごと任せるならProjectsに分かれます。ワーカー同士の会話とファイルの重なりは、その中でagent teamsを選ぶかどうかの絞り込みになります。

agent teamsは実験的で既定が無効、Projectsはプランと提供面が限られるため、この2つは利用条件を満たすと分かってから候補に入れる手段です。subagentsの作り方はSubagents完全ガイド、workflowsの仕組みはダイナミックワークフローの解説、チームの全体像はAgent Teamsとはで確認できます。