Claude Codeの並列作業：worktree、エージェント、Workflows

エージェントを並列で扱うための実践資料：Ailootのドキュメント。

このガイドでは、実践経験とツールをどこで使うかの全体像をまとめています。Claude Codeの公式プリミティブ4つ、用途の全体像、そしてvibe coderに実際に必要な並列エージェント数を考えるための誇張を避けた枠組みを紹介します。数値と引用には、Anthropicの一次資料へのリンクを付けています。

Claude Codeのマルチエージェントとは何か、なぜ「1000エージェント」ではないのか#

マルチエージェント構成とは、1つのタスクをいくつかの独立した作業ストリームに分割し、それぞれが担当部分を処理して結果を返す構成です。最も簡単な例を挙げると、同じマシン上で、共有gitリポジトリを使いながら、1つのClaude Codeウィンドウでフロントエンドを書き、別のウィンドウでバックエンドを書くことです。「オーケストレーション」と呼ぶほどのことではありませんが、これもすでにマルチエージェントです。

もう少し複雑な構成では、1つのClaude Codeセッション内で役割の異なる5つのsubagents（フロントエンド開発者、バックエンド開発者、セキュリティレビュアー、テスター、ドキュメント担当者）を起動し、それぞれが担当分の結果を共有会話に返します。制御点が1つというだけで、同じマルチエージェント方式です。

さらに複雑な例では、「プロジェクト内にある500ファイルすべてのセキュリティ監査を毎週実行して」とClaudeに頼み、ClaudeがJavaScriptのオーケストレータースクリプトを書きます。ランタイムはバックグラウンドで数十のエージェントを起動し、それぞれが担当セクションを監査します。続いて独立したエージェント同士が互いの指摘を確認し、1つのレポートを返します。これが、Anthropicが2026年5月28日に公開したDynamic Workflowsです。機能の詳しい内訳は、Dynamic Workflowsの別ガイドをご覧ください。

この3つのシナリオの違いは、エージェントの数ではありません。違いは、次のエージェントに何をさせるかを誰が決めるかです。最初のシナリオではあなた、2つ目では会話の進行に応じてClaude、3つ目ではClaudeが書いたJavaScriptスクリプトが決めます。

ちなみに「1000エージェント」は実在する数値です。Claude Codeにおける1つのDynamic Workflowの上限です。Anthropicの公式ドキュメントには、次のようにあります。

つまり、これは制御不能な動作を防ぐ技術的な安全策であり、推奨作業量ではありません。実際には、タスクの95%は2～8の並列作業ストリームで対応できます。それ以上を計画しているなら、まず、それぞれに何をさせるのか考えてみましょう。

Claude Codeの4つのプリミティブ：subagents、skills、agent teams、workflows#

Claude Codeには、1つのタスクを複数のエージェントに分担させるための公式プリミティブが4つあります。AnthropicはDynamic Workflowsのドキュメントで、それらを比較表にまとめています。要点を平易にまとめると、次のとおりです。

これらのプリミティブはそれぞれ、異なる問題を解決します。Subagentsは、1つのタスク内で2～3個の確認作業を委任するためのものです。Skillsは、Claudeに従わせる既成の指示（「このチェックリストを使ってPRをレビューする」など）がある場合に向いています。Agent teamsは、製品の複数の部分を別々のウィンドウで扱い、調整役が必要な場合に使います。Workflowsは、1つのコンテキストウィンドウには大きすぎるタスクに向いています。

Subagentsについては、Claude Code Subagents 2026ガイドで詳しく解説しています。「特定のタスクに何を使うか」の判断ツリーは、Skills、Subagents、MCP、Pluginsガイドをご覧ください。このガイドでは、git worktreeを土台に、それらをマルチエージェント構成として組み立てる方法を扱います。

レベル1：1つのセッション内のsubagents――最も手軽な始め方#

Subagentは、タスクを分割する最も簡単な方法です。メインの会話が調整役となり、作業の進行に応じてメインエージェントが一時的な作業者を起動します。

説明されているプロジェクトの具体例を挙げます。ガイドの初稿を書いた後、レビューを次のように設定します。Claudeに「6つのsubagentsを並列で起動して。1つ目はAIの特徴を示す表現、2つ目は法務用語、3つ目は文体とトーン、4つ目はWebFetchを使った事実確認、5つ目はSEO構成、6つ目は内部リンクの正確さを確認して」と依頼します。それぞれがレポートを返した後、修正を適用します。

技術的には、役割とツールを記述した.claude/agents/[subagent-name].mdというファイルを使って実現します。呼び出しには、メインの会話内でAgentツールを使います。subagentに依頼を送るタイミングはClaudeが判断します。

適している場面。 1つの成果物（コード、文章、デザイン）について、3～7個の並列チェックを行うタスクです。それぞれのチェックは独立しており、結果はメインのコンテキストウィンドウに収まります。

行き詰まる場面。 ファイルが50個以上ある場合や、各チェックにそれぞれ5万トークンのコンテキストが必要な場合は、メインウィンドウがいっぱいになります。workflowsまたはagent teamsが必要です。

主なリスク。 各subagentが個別にトークンを消費します。200ファイルのプロジェクトで6つ起動し、それぞれが200ファイルすべてを読み直すと、費用は6倍になります。そのため、subagentに調べさせるファイルを必ず正確に指定してください。詳しくはClaude Codeでトークンが消費される場所のガイドをご覧ください。

レベル2：git worktree――並列セッション間でファイルを分離する#

Subagentsだけでは足りず、同じリポジトリ上で別々のターミナルを使う2つの本格的なClaude Codeインスタンスが必要になると、典型的な問題が起こります。両方が同じファイルを編集し始め、一方が先に保存すると、もう一方がその内容を上書きしてしまいます。先週、あるクライアントがサポートチームに「5つが同時に互いを上書きしています」と伝えました。

解決策はgit worktreeです。gitに組み込まれた機能で、同じリポジトリに対してそれぞれ独自のブランチを持つ複数の作業コピーを作成し、1つの.gitリポジトリを共有できます。元の場所は1つ、ディスク上のディレクトリは複数で、それぞれのファイルは重なりません。仕組みについては、Claude CodeでのGit worktreeガイドで詳しく説明しています。

5分でセットアップするコマンド：

# メインのプロジェクトディレクトリから
cd ~/projects/my-app

# feature/auth用のworktreeを作成
git worktree add ../my-app-auth feature/auth

# feature/billing用のworktreeを作成
git worktree add ../my-app-billing feature/billing

# ターミナルウィンドウを2つ開く
cd ~/projects/my-app-auth && claude   # 1つ目のClaude Code
cd ~/projects/my-app-billing && claude # 2つ目のClaude Code

それぞれのコピーは独自のブランチにあります。各Claude Codeインスタンスは、それぞれのディレクトリに書き込みます。作業が終わったら、そのブランチからgit pushを実行し、続けてgit worktree remove ../my-app-authを実行します。

知っておくこと。 Worktreeは、node_modules、.venvなど.gitignoreに記載されたファイルを複製しません。各ブランチで別々の依存関係（ライブラリのバージョンなど）が必要なら、worktree addの後、新しいディレクトリで個別にnpm installを実行します。

1人あたりのworktree数。 2026年のチーム調査によると、開発者1人が並列で使うworktree数の実用上の上限は4～8です。制約になるのはClaudeではなく、結果を確認して受け入れられる人間の能力です。worktreeが10個あっても、レビュー待ちになります。

説明されている実践では、通常、並列で使うworktreeは2～3個です。作業中のメイン用が1つ、緊急のhotfix用の予備が1つ、実験用（確信のない新機能）が1つです。それ以上は必要ありません。

レベル3：agent teams――複数のウィンドウを1人のリードエージェントが統括#

Agent teamsは比較的新しいプリミティブです。考え方は、1人のリードエージェントがタスクリストとして共有計画を管理し、別々のウィンドウにある複数のピアセッションが、リードから割り当てられたタスクを担当するというものです。全員が同じファイルシステムで作業し、他のエージェントの中間成果物も確認できます。

これは、数時間かかる大きな作業ストリームが3～5個あるタスクに役立ちます（大規模モジュールの移行、サブシステムの書き換え、包括的なセキュリティ監査など）。この場合、リードエージェントが、worktreeの外の絶対パスにある1つの共有タスクファイルで計画を管理します。作業者はそのパスを読んで結果を報告し、状態を更新するのはリードだけです。調整ファイルへの競合する書き込みを避けられます。

技術的には、agent teamsとは、1つの計画共有ポイントを持ち、git worktree上で動く複数のウィンドウです。実際には、80%の人は上記のworktreeを使った説明のように、agent teamsを手作業で管理しており、専用の「teams framework」は使いません。それで問題ありません。

そもそもフレームワークが必要かわからないなら、ほぼ間違いなく必要ありません。手動のworktreeと、メインディレクトリのリードエージェント1つで十分です。

レベル4：Dynamic Workflows――ClaudeがJSオーケストレーションスクリプトを書く#

これまでの3つのレベルでは、計画は会話の中、つまりメインエージェントの頭の中かリードエージェントのタスクリストに置かれます。Dynamic Workflowsでは、計画をコードの中に置きます。ClaudeがタスクをJavaScriptスクリプトとして表現し、ランタイムが隔離された環境で実行します。中間結果はコンテキスト内ではなくスクリプト変数に保存されるので、エージェントがバックグラウンドで動いている間もセッションは応答可能な状態を保ちます。

公式ドキュメントにある具体例を見てみましょう。次のように指示します。

ultracode: audit every API endpoint under src/routes/ for missing auth checks

Claudeは、おおよそ次のロジックを持つJavaScriptスクリプトを書きます。「src/routes/のファイルをすべて取り出し、エンドポイントを30件ずつのグループに分け、各グループに同じ確認作業を行うエージェントを実行する。次に、独立したgraderエージェントを2つ起動して指摘を確認し、最終レポートにまとめる。」スクリプトが実行されると、結果の表と、確実に確認が必要なエンドポイントの一覧が返されます。

適している場面。

• プロジェクト全体を対象に、1種類の問題を監査する場合（セキュリティ、型付け、非推奨APIなど）。
• 大規模な移行（共通のルールが適用される500以上のファイル）。
• 複数の独立した視点から確認する必要がある調査課題（Anthropicは組み込みの/deep-researchコマンドでこれを行います）。

Dynamic Workflowsの詳しい内訳、上限、ultracodeの仕組みについては、Claude CodeのDynamic Workflowsに関する別ガイドをご覧ください。

使わない場合。 タスクが直線的で明確な場合です。「このコンポーネントを完成させて」というタスクにworkflowは不要です。workflowが役立つのは、タスクが10以上の独立したサブタスクに分かれ、相互確認が必要な場合です。

主な制約。 Workflowは通常のセッションより大幅に多くのトークンを消費します。Anthropicはドキュメントで、次のように推奨しています。

つまり、最初のworkflowはプロジェクト全体ではなく、1つのディレクトリを対象に実行しましょう。費用を確認してから、規模を広げる価値があるか判断します。

Outcomes：評価基準のルーブリックと独立したレビュアー#

マルチエージェント作業で最も危険なのは、エージェントの出力を信頼してしまうことです。どのエージェントも、完成したように見える文章を返します。引用は正しそうに見え、レポートは完全に見え、移行は終わったように見えます。エージェントが1つなら自分で確認できますが、10個になると時間が足りず、確認できません。

Anthropicは2026年5月6日に公開したManaged Agentsの機能「Outcomes」で、この問題に対処しています。考え方は単純です。セッション内にSECOND agent（採点役）を置き、その唯一の仕事を、厳格なルーブリックに照らして最初のエージェントの成果を確認することとします。

技術的な仕組みを説明します。ルーブリックとは、「完了」の定義、確認する情報源、使うラベルを詳しく記載したMarkdown文書です。プラットフォームは、新しいコンテキストウィンドウ内に採点役エージェントを自動で作成します。採点役が受け取るのはルーブリックと成果だけで、それ以外は何も受け取りません。メインエージェント（執筆者）が試行するたび、採点役は成果を読み直し、合格と判定するか、未完了項目の一覧を返します。

Anthropic Cookbookからの引用です。

実際の効果を示す数値を紹介します。OutcomesをClaude Managed Agentsに統合した後、AI企業Harveyのタスク完了率は約6倍に上がりました。医療文書を扱うWisedocsでは、文書のレビューにかかる時間が50%短縮しました。これらの数値は、公式の機能発表に基づいています。

企業ではなくvibe coderにとって重要なのは、Outcomesを特定の機能ではなくパターンとして捉えることです。同じ基準を.claude/agents/grader.mdに記述し、試行のたびにメインエージェントに実行させれば、独自のgrader agentを作れます。Managed Agentsに限らず、どんなマルチエージェント構成でも機能します。

Cookbookにあるルーブリックの主な執筆ルールは、一般的な指示ではなく、検証可能なことを指定することです。「概要に請求に関する内容が含まれているか確認する」ではなく、「概要を開き、請求に関するセクションを探し、金額が$で示されているか、または売上に対する割合として示されているか確認する」と指示します。最初の指示では、採点役はざっと目を通してチェックを付けるだけです。2つ目では、文書を開き、具体的な数値を探す必要があります。

反パターン：「無意味な作業をする50エージェント」#

これがマルチエージェントにおける中心的な反パターンです。Claude Codeは一度に16エージェントを動かせ、Dynamic Workflowsは1回の実行で1000エージェントを動かせると知り、実際に座って起動してしまう。その結果はゼロです。トークン消費は通常のセッションの10倍になります。

簡単なテストがあります。紙を用意し、エージェントごとに枠を描きます。それぞれの枠に、次のことを書き込みます。

1. 具体的な仕事（1文）。
2. 触るファイル。
3. 返すもの。
4. 確認する人。

このうち1つでも30秒で答えられないなら、そのエージェントは起動すべきではありません。このルールは、subagents、agent teams、Dynamic Workflowsのすべてのレベルで有効です。

2つ目の反パターンは、順番に行うべき作業を並列で行うことです。APIスキーマを読むためにフロントエンドが先にバックエンドを必要とするなら、並列で実行しないでください。先にバックエンドを行い、その後にフロントエンドを進めます。タスクを並列化するのは、互いに独立している場合だけです。

3つ目の反パターンは、速くする目的でマルチエージェントを使うことです。これはある程度までしか機能しません。タスクを独立した4つの作業ストリームに分割すれば、（最小限の調整時間を除き）1つのストリームで行う場合とほぼ同じ時間で完了します。しかし、1台のマシン上で50のストリームを動かすと、CPUを共有するため、それぞれの進行が遅くなります。ノートPCでの実用上の上限は、Claude Codeインスタンス4～6個の同時実行です。それを超えると、速度制限が始まります。

費用はいくらかかり、利用上限を使い切らないためにはどうすればよいか#

2026年5～6月、業界はAIによるコーディングが予想以上に高くつくという現実に直面しました。

通常のClaude Codeチャットセッション1回なら、比較的妥当な費用で済みます。Dynamic Workflowsをリポジトリ全体に対して有効にすると、請求額は20倍になります。Anthropicの公式ドキュメントには、次のようにあります。

実際に何をすればよいか、説明されている実践に基づく節約ルールを紹介します。

1. 各エージェントが対象にするファイルを正確に指定する。 「プロジェクトに目を通して問題を探す」ではなく、「src/auth/*.tsを調べ、すべての関数がuserIdを検証しているか確認する」と指示します。2つ目のプロンプトなら、支払う費用に見合った作業を正確に指示できます。

2. まずworkflowを1つのディレクトリで試す。 src/全体ではなく、src/auth/から始めます。結果に納得し、費用も把握できたら、より広い範囲に展開します。

3. デフォルトでは/effort highを使い、ultracodeは意図的に選ぶ。 /effort ultracodeはxhighに自動オーケストレーションを加えた設定です。非常に高くつきます。並列の作業ストリームが複数、本当に必要な場合に使いましょう。

4. 可能ならsubagentsには小さめのモデルを使う。 1つのガイドを6つのsubagentsでレビューする場合、AIの特徴を確認するQAエージェントや内部リンクチェッカーにOpusは必要ありません。Sonnetで十分です。使用量を3～5倍減らせます。

トークン節約について詳しくは、Claude Codeでトークンが消費される場所のガイドとClaude Codeの利用上限を使い切らない方法をご覧ください。

今日から始める：30分のチェックリスト#

1. Claude Codeをv2.1.154以降にアップデートする

   Dynamic Workflowsに対応する最低バージョンです。ターミナルでclaude updateを実行します。

2. /configでDynamic Workflowsを有効にする

   Proプランではデフォルトで無効になっています。/configを開き、「Dynamic workflows」の行を探して有効にします。Max、Team、Enterpriseでは、すでに有効です。

3. 最初のworktreeを作成する

   メインのプロジェクトディレクトリで、git worktree add ../<project>-experiment <branch>を実行します。そのディレクトリで2つ目のターミナルウィンドウを開き、claudeを実行します。

4. 共有タスクリストを追加する

   すべてのworktreeの外の1つの絶対パスを使います。各worktreeのtasks.mdは別ファイルで、自動同期しません。書き手はリードのセッションだけにし、作業者は一覧を読んで結果を報告します。

   調整用のディレクトリと一覧は一度だけ作ります。

   mkdir -p "$HOME/projects/my-app-coordination"
   printf '%s\n' '# Tasks' '- Auth: assigned to the auth worktree' '- Billing: assigned to the billing worktree' > "$HOME/projects/my-app-coordination/tasks.md"
   

   1つ目のターミナル：

   cd "$HOME/projects/my-app-auth"
   printf 'Shared task list: %s\n' "$HOME/projects/my-app-coordination/tasks.md"
   claude
   

   2つ目のターミナル：

   cd "$HOME/projects/my-app-billing"
   printf 'Shared task list: %s\n' "$HOME/projects/my-app-coordination/tasks.md"
   claude
   

   両セッションへ、上に表示された展開済みの同じ絶対パスを渡します。「この共有タスクリストを読んで、自分の担当タスクとファイルだけを作業してください。一覧は編集せず、完了と障害を、更新担当のリードへ報告してください」と伝えます。開始前に両方がそのファイルを読めることを確認し、そのパスへの権限確認を解決してください。状態を調整するのは一覧ですが、コード変更は別々のworktreeに残ります。

5. 1週間この方法で作業する

   最初からGUIラッパーをインストールする必要はありません。worktreeを2つ使い、1週間は手作業で進めてみましょう。不足しているものが見えたら、具体的な問題に応じてツールを選びます。

6. その後にのみ`/effort ultracode`を有効にする

   「src/routes/にある、認証チェックのないAPIエンドポイントをすべて見つける」など、タスクを1つ選びます。/effort ultracodeを有効にし、Claudeが書くworkflowと費用、結果を確認します。それが最初のDynamic Workflowです。

次に進むには：セッション間のメモリ、Code Review、Multi-Agent v2#

2026年5～6月に登場した機能と、Claude Codeのマルチエージェントが向かう先を紹介します。

Dreaming付きManaged Agents。 2026年5月6日、Code with Claudeで公開されました。セッション間にエージェントの過去のトランスクリプトを読み、繰り返し現れるパターンを特定し、メモリを更新するスケジュール実行のプロセスです。AI法律企業Harveyでは、Dreamingを導入した後にタスク完了率が6倍に向上しました。まだ研究プレビューの段階です。

Managed Agentsの機能としてのOutcomes。 前述のとおりです。Claude Code CLIから直接ではなく、Claude Agent SDKを通じて利用できます。同じパターンは、今すぐgrader subagentを使って手作業で実現できます。

Claude Agent SDKのMulti-Agent Orchestration v2。 リードエージェントが共有ファイルシステムを使い、自らsubagentsに作業を委任します。「N個のsubagentsを手動で起動する」から、「タスクを説明すると、リードが誰に何を委任するかを自分で判断する」への一歩です。subagentsを学び始めたばかりなら、まだv2を気にする必要はありません。「メインエージェント1つ＋役割を持つsubagents 3～5個」という従来のパターンを身につけ、3～6か月後に自然にv2へ移行しましょう。

エージェントチームによるCode Review。 AnthropicはCode with Claudeで、PRを開いたときに自動でコードレビューを行う機能を発表しました。AIエージェントのチームがdiffを並列で確認し、バグを探し、互いに指摘を検証し、深刻度順に並べます。TeamとEnterpriseで利用可能で、Proではまだ使えません。

Plugin Marketplace。 2026年5月23日、v2.1.128-136で公開されました。マーケットプレイスのプラグインには、parallel-review、security-audit、migration-helperなど、すぐに使えるマルチエージェント構成があります。/plugin install <name>@claude-plugins-officialでインストールして仕組みを確認すれば、自分で作る方法を学ぶうえで役立ちます。

Claude Codeのマルチエージェントは、成熟度の異なるプリミティブが集まった状態です。Subagentsとgit worktreeは安定しており、実績があって、どこでも使えます。Agent teamsは半自動、半手動です。Dynamic Workflowsは研究プレビュー段階で、急速に変化しています。Managed Agents v2はEnterprise専用です。そのため、これから1年間、vibe coderにとって最適な構成は最新リリースではなく、特定のタスクに必要な最小限の構成になるでしょう。1か月間の活発な作業なら、worktreeを2つとgrader subagentを1つで十分です。制約を感じ始めたら、複雑さを加えましょう。

vibe codingのための実用的な構成#

実践資料はAilootのドキュメントをご覧ください。

その他の資料とツール：Ailoot。