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

> Claude Codeのエージェントチーム、サブエージェント、Skills、Workflowsの違いと、git worktreeによる並列作業、成果の検証、利用上限を解説します。

Source: https://ailoot.ai/blog/ja/claude-code-parallel-worktree-agents/
Canonical: https://ailoot.ai/blog/ja/claude-code-parallel-worktree-agents/
Language: ja
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-179
Revision: sha256-0e61a4af185e03265c5ffe4fd0d71bfb1e7956066f5df21b83ffb9f185c88e8d


<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

重要なポイント

Claude Codeには、複数のエージェントに作業を分担させる方法が4つあります。1つのセッション内のsubagents、指示を含むskills、リーダーと別々のウィンドウで動くagent teams、そしてランタイムが実行するJavaScriptスクリプトとしてのDynamic Workflowsです。1台のマシンでClaude Codeのインスタンスを5つより多く並列実行したい場合は、git worktreeでファイルを分離しましょう。公式ランタイムの上限は、同時に16エージェント、1回の実行につき合計1000エージェントです。最大の落とし穴はコードにあるのではありません。「50のエージェントを動かしている」はたいてい、「誰も確認しないまま、50のエージェントが並列で無意味なものを生成している」ということです。成果を評価基準のルーブリックと独立したレビュアーエージェントで確認すれば、この問題に対処できます。

</div>

エージェントを並列で扱うための実践資料：[Ailootのドキュメント](https://ailoot.ai/docs/)。

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

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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

重要なポイント

Claude Codeにおけるマルチエージェントとは、1つの会話ではなく、複数の作業ストリームでタスクに取り組む状況全般を指します。別々のウィンドウで複数のセッションを動かす場合も、1つのセッション内でリーダーが部下を動かす場合も、ランタイムがオーケストレーションするスクリプトを使う場合もあります。「1000エージェント」は、1つのDynamic Workflowでの技術的な上限です。これはランタイムが制御不能にループするのを防ぐ安全策であり、推奨作業量ではありません。

</div>

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

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

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

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

ちなみに「1000エージェント」は実在する数値です。Claude Codeにおける1つのDynamic Workflowの上限です。[Anthropicの公式ドキュメント](https://code.claude.com/docs/en/workflows)には、次のようにあります。

<figure>
<blockquote>
<p>同時に実行できるのは最大16エージェントです。CPUが限られているマシンでは、さらに少なくなります。1回の実行につき、合計1000エージェントまでです。これは制御不能なループを防ぐためです。</p>
</blockquote>
<figcaption>— Anthropic Claude Code Docs, https://code.claude.com/docs/en/workflows</figcaption>
</figure>

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

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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

重要なポイント

Claude Codeの公式ドキュメントでは、マルチエージェント作業を4つの異なる層に分けて説明しています。Subagentsは1つのセッション内で一時的に働く作業者です。SkillsはClaudeが従う指示です。Agent teamsは、リーダーと別々のウィンドウで動く常設の「同僚」です。Workflowsはランタイムがオーケストレーションするスクリプトです。それぞれ同時実行数の上限があり、中間結果を置く場所も異なります。

</div>

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

|  | Subagents | Skills | Agent Teams | Workflows |
|----|----|----|----|----|
| 何を指すか | Claudeが起動する作業者 | Claudeが従う指示 | 別々のウィンドウにいるチームを率いるリーダー | ランタイムが実行するスクリプト |
| 誰が手順を決めるか | 会話の進行に応じてClaude | 指示に基づいてClaude | リーダー | スクリプト自体 |
| 結果の保存場所 | Claudeのコンテキストウィンドウ | コンテキストウィンドウ | 共有タスクリスト | スクリプト変数 |
| 再利用できるもの | 作業者の説明 | 指示そのもの | チームの説明 | オーケストレーション全体 |
| 規模 | 一度に数個 | 同程度の数 | 少数の常設の同僚 | 1回の実行につき数十から数百 |
| 中断された場合 | ターンを再開する | ターンを再開する | 同僚は作業を続ける | 同じセッションで再開する |

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

Subagentsについては、[Claude Code Subagents 2026ガイド](https://ailoot.ai/blog/ja/claude-code-subagents/)で詳しく解説しています。「特定のタスクに何を使うか」の判断ツリーは、[Skills、Subagents、MCP、Pluginsガイド](https://ailoot.ai/blog/ja/skills-subagents-mcp-plugins-claude-code/)をご覧ください。このガイドでは、git worktreeを土台に、それらをマルチエージェント構成として組み立てる方法を扱います。

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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

重要なポイント

Subagentは、Claudeのセッション内で一時的に働く「作業者」です。メインエージェントに「フロントエンド開発者、バックエンド開発者、テスター、ドキュメント担当者として4つのsubagentsを起動して」と指示すると、それぞれが担当分を処理し、結果を共有会話に返します。同時実行数は2～5で、すべて1つの共有コンテキスト内に収まります。

</div>

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でトークンが消費される場所のガイド](https://ailoot.ai/blog/ja/where-claude-code-tokens-go/)をご覧ください。

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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

重要なポイント

Subagentsは1つのセッションと1つのファイルシステムを共有します。同じリポジトリで、別々のターミナルにある2つの本格的なClaude Codeインスタンスで作業したい場合、それぞれに別の作業コピーが必要です。Git worktreeを使えば、追加費用なしで実現できます。`.git`内の信頼できるソースは1つのまま、ディスク上に独立したディレクトリを2つ作れます。

</div>

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

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

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

```bash
# メインのプロジェクトディレクトリから
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人のリードエージェントが統括

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

重要なポイント

Agent teamsは、別々のウィンドウでチームとして作業する複数のClaude Codeインスタンスです。1人のリードエージェントが共有タスクリストを管理し、他のエージェントはそのリードに報告します。互いのやりとりには共有ファイルシステムを使います。「1つの会話内のsubagents」と「コードとしてのDynamic Workflows」の中間に位置するオーケストレーション層です。

</div>

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オーケストレーションスクリプトを書く

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

重要なポイント

Dynamic Workflowは、Claudeがタスク用に書き、ランタイムがバックグラウンドで実行するJavaScriptスクリプトです。ランタイムは一度に最大16エージェント（1回の実行につき合計1000エージェント）を起動し、その間もセッションは応答可能な状態を保ちます。プロンプトのキーワード`workflow`、`/effort ultracode`設定、または組み込みの`/deep-research`コマンドで有効化できます。2026年5月28日に公開され、Claude Code v2.1.154以降が必要です。

</div>

これまでの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に関する別ガイド](https://ailoot.ai/blog/ja/claude-code-dynamic-workflows/)をご覧ください。

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

**主な制約。** Workflowは通常のセッションより大幅に多くのトークンを消費します。Anthropicは[ドキュメント](https://code.claude.com/docs/en/workflows)で、次のように推奨しています。

<figure>
<blockquote>
<p>Dynamic workflowsは、一般的なClaude Codeのセッションよりかなり多くのトークンを使うことがあります。そのため、範囲を限定したタスクから始めることを推奨します。</p>
</blockquote>
<figcaption>— Anthropic Claude Code Docs, https://code.claude.com/docs/en/workflows</figcaption>
</figure>

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

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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

重要なポイント

マルチエージェントの主な問題は、エージェントが完成したように「見える」ものを作ることです。引用は正しそうに見え、レポートは完全に見えます。AnthropicのOutcomesは、新しいコンテキストで別のエージェントを起動し、ルーブリックを読んで最初のエージェントの成果を確認する仕組みです。2026年5月6日にCode with Claudeで公開されました。Harveyではタスク完了率が6倍に上がり、Wisedocsではレビュー時間が50%短縮しました。

</div>

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

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

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

[Anthropic Cookbook](https://platform.claude.com/cookbook/managed-agents-cma-verify-with-outcome-grader)からの引用です。

<figure>
<blockquote>
<p>エージェントは、完成したように「見える」ものを作るのが得意です。出典付きの調査レポートを作るよう頼むと、脚注付きの洗練された文書が返ってきます。詳しく見ると、話題を表面的に扱っていたり、引用が出典の内容からずれていたり、出典として一次文書ではなくプレスリリースを挙げていたりします。</p>
</blockquote>
<figcaption>— Anthropic Cookbook - Outcomes, https://platform.claude.com/cookbook/managed-agents-cma-verify-with-outcome-grader</figcaption>
</figure>

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

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

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

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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

重要なポイント

あらゆる並列構成で最大の間違いは、各エージェントが何をしているか把握せずに、大量のエージェントを起動することです。実際には、AIエージェントを3～4時間かけて作成したとき、並列の作業ストリームは最大2～3個でした。vibe coderが「並列で50個」と自慢するとき、それはたいてい「誰も確認しないまま、50個が並列でゴミを生成している」という意味です。各エージェントが具体的に何を解決しているか30秒で説明できないなら、その状態だとわかります。

</div>

これがマルチエージェントにおける中心的な反パターンです。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個の同時実行です。それを超えると、速度制限が始まります。



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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

重要なポイント

マルチエージェント構成では、トークン消費が倍数単位で増えます。Subagentsは通常のセッションの2～4倍、agent teamsは3～6倍、Dynamic Workflowsは10～30倍です。主な節約ルールは、各エージェントの対象ファイルを明示すること、プロジェクト全体を一度にworkflowの対象にしないこと、小さな範囲で費用を確かめることです。

</div>

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

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

<figure>
<blockquote>
<p>Workflowは多くのエージェントを実行するため、通常の会話で同じタスクを完了する場合と比べ、1回の実行で大幅に多くのトークンを消費することがあります。大規模な実行の前に費用を把握するには、小さな範囲でworkflowを試してください。</p>
</blockquote>
<figcaption>— Anthropic Claude Code Docs, https://code.claude.com/docs/en/workflows</figcaption>
</figure>

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

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でトークンが消費される場所のガイド](https://ailoot.ai/blog/ja/where-claude-code-tokens-go/)と[Claude Codeの利用上限を使い切らない方法](https://ailoot.ai/blog/ja/claude-code-token-limits-saving/)をご覧ください。

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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

重要なポイント

いきなりDynamic Workflowsを使う必要はありません。基本的なマルチエージェント構成なら、30分で作れます。worktreeを2つ、ターミナルを2つ、そして`tasks.md`にまとめるリード用チェックリストがあれば十分です。これでシナリオの80%をカバーできます。残りの20%（大規模な監査や移行）には、数週間後に自然と取り組むことになるでしょう。

</div>

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`は別ファイルで、自動同期しません。書き手はリードのセッションだけにし、作業者は一覧を読んで結果を報告します。

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

    ```bash
    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つ目のターミナル：

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

    2つ目のターミナル：

    ```bash
    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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

重要なポイント

基本的なマルチエージェント構成で、タスクの80%に対応できます。今後注目する3つの機能は、セッション間のメモリを扱うDreaming付きManaged Agents、すべてのPRでエージェントチームが行うCode Review、そしてClaude Agent SDKのMulti-Agent Orchestration v2です。いずれも研究プレビューまたはパブリックベータであるか、限定提供が発表された段階です。

</div>

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のための実用的な構成

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

重要なポイント

マルチエージェント構成が機能するのは、意図的なコンテキストエンジニアリングを土台にしている場合だけです。これがなければ、どんな並列オーケストレーションも「無意味な作業をする50エージェント」という反パターンに陥ります。

</div>

実践資料は[Ailootのドキュメント](https://ailoot.ai/docs/)をご覧ください。



<div class="section" role="doc-bibliography" aria-label="Sources">

### 出典

- [Anthropic - Orchestrate subagents at scale with dynamic workflows (公式ドキュメント)](https://code.claude.com/docs/en/workflows)
- [Anthropic - Introducing Dynamic Workflows in Claude Code](https://claude.com/blog/introducing-dynamic-workflows-in-claude-code)
- [Anthropic Cookbook - Outcomes: agents that verify their own work](https://platform.claude.com/cookbook/managed-agents-cma-verify-with-outcome-grader)
- [Anthropic - New in Claude Managed Agents (Dreaming、Outcomes、Multi-Agent v2)](https://claude.com/blog/new-in-claude-managed-agents)
- [Claude Code - Run agents in parallel (subagents and agent teams documentation)](https://code.claude.com/docs/en/agents)

</div>







その他の資料とツール：[Ailoot](https://ailoot.ai/)。

## Claude Codeの並列作業：worktree、エージェント、Workflows | Ailoot：よくある質問

### 2つのworktreeでtasks.mdが違うのはなぜですか？

各worktreeは別々のファイルを持ちます。両方の外にある1つの絶対パスへ調整用リストを置き、展開後の同じパスを各エージェントへ渡し、開始前に両方から読めるか確認してください。

### 共有タスクリストは誰が更新しますか？

リードのセッション1つだけを書き手にします。作業者は一覧を読み、自分に割り当てられたworktree内のファイルだけを編集し、成果と障害をリードへ報告します。同じパスを共有するだけでは、同時編集を防げません。


## Ailoot · 企業とそのプロジェクト群

Ailootは、蓄積した運営経験、幅広い顧客基盤、安定したサービス、継続的なKPI管理を基盤としています。

企業とそのプロジェクト群：数百万の顧客、毎月数十億規模の売上。

Ailootはこの運営経験を、お客様の製品、エージェント、アプリケーション、自動化でAI機能を利用するためのAPIアクセスに活かしています。