「複数の作業を同時に進めたい。でも、同じファイルを編集して変更が衝突しないか、誰が結果を確認するのかが決まっていない」 Claude Code並列エージェントとは、Claude Codeで複数のエージェントに仕事を分け、同時に進める方法です。Claude Codeの並列実行を始める前に整理したいのは、このような作業の境界です。タスクの依存関係を確認し、担当ファイルと承認の手順を決めてから実行方法を選びます。この記事では、Agent Teams、tmux、専用ツール、ヘッドレス実行、/batchを比較し、作業を分けるところから結果を確認するところまでを説明します。
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
「複数の作業を同時に進めたい。でも、同じファイルを編集して変更が衝突しないか、誰が結果を確認するのかが決まっていない」
Claude Code並列エージェントとは、Claude Codeで複数のエージェントに仕事を分け、同時に進める方法です。Claude Codeの並列実行を始める前に整理したいのは、このような作業の境界です。タスクの依存関係を確認し、担当ファイルと承認の手順を決めてから実行方法を選びます。この記事では、Agent Teams、tmux、専用ツール、ヘッドレス実行、/batchを比較し、作業を分けるところから結果を確認するところまでを説明します。
本記事は2026年8月時点の情報です。
開発リーダー・PM・CDOがClaude Codeの並列実行を検討するときに使えるよう、方法の違いと運用手順を整理します。
並列実行を検討する出発点は、作業の数ではなく「待っている間に、独立して進められる仕事があるか」です。先行する変更の完成を待たなければ着手できない仕事は直列のまま扱い、担当範囲を切り離せる仕事から並列化します。
StartLinkでは、CRMコンサルティング、自社ブログの運営、HubSpotアプリの開発、顧客向け提案資料の制作を進めています。たとえば記事の執筆と別リポジトリのコードレビューは、担当ファイルと確認者を分ければ同時に進められます。一方、レビュー結果を受けて実装する作業は、結果を確認してから着手する必要があります。
まずタスクごとに「先に受け取るべき成果物」と「編集する場所」を書き出してください。両方が重ならない仕事なら並列化を試し、同じ判断やファイルを必要とする仕事なら実行順を決めます。効果はエージェントの数から推測せず、待ち時間に加えて、成果物の統合や手戻りにかかった作業も見て判断します。
複数のエージェントを動かす場合、担当者の記憶だけでは、作業中のファイルや承認待ちの変更を追いにくくなります。そこで、タスク、担当、状態、次に進む条件を共有ファイルに記録します。
本記事では、その記録先を AGENT_SYNC.md とします。作業開始前には担当範囲の重複を確認し、完了時には成果物と未解決事項を追記します。途中参加する人が読んでも「今、何を確認すればよいか」がわかる状態を目指します。
並列実行では、人間がタスクの分割、担当の割り当て、成果物の確認を担います。特に、外部システムへの書き込みや本番への反映は、実行対象と影響範囲を確認してから判断します。
並列数を増やす前に、担当と承認の流れを決めてください。成果物の確認が追いつかないなら、エージェントを増やすより先にタスクを小さくするか、実行順を見直します。
| 観点 | 直列運用（Before） | 並列運用（After） |
|---|---|---|
| 人の主な作業 | 1タスクずつ指示し、完了を待つ | タスクを分割し、担当と承認を管理する |
| 作業状況の把握 | 担当者の記憶・手元メモ | AGENT_SYNC.mdなど共有ファイルに集約 |
| ボトルネック | 前タスクの完了待ち | タスク分割と成果物レビューの質 |
| 引き継ぎ | 口頭・個人依存 | 同期ファイルを読めば誰でも状況を追える |
Agent Teamsは、Claude Codeのチームリードが複数のチームメイトへ仕事を割り当て、進捗をまとめる機能です。同じ課題を異なる観点から検討する場合や、担当するモジュールを分けられる場合に検討できます。使い始める前に、チームメイト同士が編集するファイルの重複を確認します。
Agent Teamsは実験的な機能です。有効化の条件や表示方法は変更される場合があります。利用前に公式情報で利用条件と設定手順を確認し、手元の環境で設定項目の有無と動作を照合してください。設定項目や必要な操作を確認できない場合は、導入を前提に運用を決めないでください。
サブエージェントは、依頼された作業の結果を呼び出し元に返します。Agent Teamsでは、チームメイトが共有タスクリストを使い、互いにメッセージを送って調整できます。
次の図は、作業の依頼と結果の受け渡しがどう異なるかを示しています。調査結果だけを受け取れば次に進める場合はサブエージェント、担当者間で発見を共有して作業を調整する場合はAgent Teamsを選ぶ、という判断に使ってください。
複数の観点から同時に調査する場合も、まず各担当の問いと提出物を分けます。調査結果を統合した後で実装方針を決めるなら、実装はその判断を待ってから始めます。
公式ドキュメントでは、Agent Teamsを有効化する設定として、環境変数または settings.json の env ブロックに CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 を指定する方法が案内されています。手元で有効化する前に、利用条件を確認してください。
%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}有効化後は、達成したいことと各チームメイトの役割を自然言語で伝えます。次の例では、検討する観点を分け、結果を統合してから次の作業を決められます。
このCLIツールの設計を3人のチームメイトで検討してください。
1人はUX、1人は技術アーキテクチャ、1人は反対意見役でお願いします。以下は、チームの形成と表示方法に関する変更履歴です。バージョン固有の記述を導入手順として固定せず、利用時にはAgent teamsの現行記載と手元の動作を照合してください。
| バージョン | 変更内容 |
|---|---|
| v2.1.178 | TeamCreate / TeamDelete ツールが削除され、チームメイトを1体起動した時点でチームが自動形成される。セッション終了時に自動でクリーンアップ |
| v2.1.178 | Agent toolの team_name 入力は受理されるが無視される（非推奨）。フックのペイロードに含まれる team_name もセッション由来の名前を返すのみ |
| v2.1.179 | 表示モードの既定が "auto" から "in-process" に変更。明示的に設定しない限り、全チームメイトが1つのターミナル内に収まる |
チームメイトの画面を分割して表示したい場合は、Agent teamsで対応するターミナルと teammateMode の設定を確認します。まず標準の表示で作業し、同時に画面を見ながら指示する必要が生じた場合に分割表示を検討すると、表示方法とタスク分割の問題を切り分けられます。
{
"teammateMode": "auto"
}次の図は、設定と過去の変更点をまとめたものです。図中のバージョン表記は変更履歴として読み、実際の有効化手順は公式ドキュメントと照合してください。
最初にチームリードへ目的と担当範囲を伝え、作業の分割案を確認します。変更対象が重なっていたら、実行前に担当を調整します。完了報告を受けた後は、各成果物だけでなく、統合した状態での動作も確認します。
| フェーズ | 処理内容 | 担当 |
|---|---|---|
| 計画 | タスクを分析し、独立して処理できる単位に分割して共有タスクリストに登録 | チームリード |
| 起動 | 依頼内容に応じてチームメイトを起動（人間が承認してから起動） | 人間＋チームリード |
| 実行 | 各チームメイトがタスクを自ら取り、並列に実行。必要に応じてチームメイト同士が直接やり取り | チームメイト |
| 同期 | 完了報告（アイドル通知）を受け、成果を統合 | チームリード |
| 検証 | 統合結果をビルド・テストで検証し、最終報告 | チームリード |
表の「人間が承認してから起動」は、依頼時に設ける運用上の確認点です。チームメイトの起動に製品側の承認画面が挟まるという意味ではありません。分割案の確認が必要なら、依頼文に「担当範囲を提示し、確認を受けてから編集を始めてください」と明記します。
Agent Teamsは、同一リポジトリ内で異なる観点の検討を進める場合や、担当モジュールが分かれた実装に向いています。ただし、チームメイトの編集は自動的にGit worktreeへ隔離されるわけではありません（出典：Agent teams）。
依頼時に「チームメイトAは src/auth/、チームメイトBは src/dashboard/」のように担当を指定します。共通ファイルの変更が必要と判明したら、その時点で作業を止めて更新担当と順番を決めます。ブランチごとに作業場所を分けたい場合は、Git worktreeを使う方法を検討してください。
別々のリポジトリや種類の異なる業務を同時に進める場合は、次のtmux方式でセッションごとに作業場所を分ける方法があります。
tmux方式では、Claude Codeのセッションをそれぞれ起動し、作業ディレクトリと指示を分けます。別リポジトリの作業を並べる場合に使えますが、セッション間の担当調整は自分たちで設計する必要があります。
各セッションの作業ディレクトリを先に確認してから起動します。次のコマンドは構成例です。実行前にパスと指示を自分の環境に合わせて確認してください。
# セッション1: ブログ記事のレビュー
tmux new-session -d -s blog -c ~/projects/marketing 'claude "記事のレビューを進めてください"'
# セッション2: APIのテスト追加
tmux new-session -d -s api -c ~/projects/api-server 'claude "テストが不足している箇所を洗い出して追加してください"'
# セッション3: インフラ設定のレビュー
tmux new-session -d -s infra -c ~/projects/infrastructure 'claude "Terraformの設定をレビューしてください"'
# 全セッションを一覧表示
tmux list-sessionstmux attach -t blog のように対象セッションへ接続できます。複数セッションの表示や操作をまとめたい場合は、cmuxも比較対象になります。選ぶ際は画面の見やすさに加え、作業場所と担当を取り違えずに管理できるかを確かめます。
同時に画面を見て指示する必要がある場合は、ペイン分割を使えます。次の例では分割した各ペインでClaude Codeを起動します。
# 4分割レイアウトの作成
tmux new-session -d -s agents
tmux split-window -h -t agents
tmux split-window -v -t agents:0.0
tmux split-window -v -t agents:0.2
# 各ペインでClaude Codeを起動
tmux send-keys -t agents:0.0 'claude' Enter
tmux send-keys -t agents:0.1 'claude' Enter
tmux send-keys -t agents:0.2 'claude' Enter
tmux send-keys -t agents:0.3 'claude' Enter
tmux attach -t agentsペインごとの表示領域が足りなくなったら、常時確認したい作業だけを画面に残し、ほかは独立セッションで管理します。画面上の位置を担当の根拠にせず、タスクとファイルの所有者は共有ファイルに記録してください。
tmux方式では、セッションを分けただけでは担当や進捗を共有できません。
# AGENT_SYNC
## 現在のタスク分配
### チームメイトA（HubSpot設定）
- 状態: 作業中
- 担当: スコアリングプロパティ設定
- ファイル所有権: 06_dev/scoring/
- 備考: HubSpot APIのレート制限内で実行する
### チームメイトB（記事制作）
- 状態: 完了
- 担当: DD-46記事執筆
- ファイル所有権: 01_marketing/blog/articles/ai/claude-code-practice/
## 競合注意ファイル
- article_to_post_map.json: チームメイトBが更新予定。他は書き込み禁止
- 共有ファイルの更新担当と順番を決める
## 承認済みタスク
- （人間が承認したタスクだけをここに記載）この例では、HubSpotの設定作業を記録していますが、ファイルの担当と外部システムへの書き込み権限は別に判断します。設定スクリプトの作成と実際の反映を分け、反映前に対象と変更内容を確認します。
ファイル連携で先に決めるべきなのは、同じファイルをいつ誰が更新するかです。運用は次の順で進めます。
担当者が交代したときに、ファイルだけで次の確認事項を判断できなければ、記録項目を見直します。
複数の作業を始める前に、分割案と実行範囲を確認します。特に外部システムへの書き込みを含む場合は、準備作業と実行作業を区別します。
[チームリード] 以下のタスク分割を提案します:
タスク1: HubSpotカスタムプロパティの一括作成（チームメイトA）
- 必要権限: HubSpot API書き込み
- リスク: 既存プロパティとの名前衝突
タスク2: ブログ記事のMD生成（チームメイトB）
- 必要権限: ファイルシステム書き込み
- リスク: 記事IDの重複
承認しますか？ [Y/n/修正指示]この分割案なら、タスク1は書き込み先と作成内容を確認できるまで実行せず、既存プロパティとの照合を先に依頼します。タスク2も記事IDの重複を確認してから着手します。
| 確認項目 | 承認してよい状態 | 差し戻す状態 |
|---|---|---|
| 担当ファイル | タスク間で重複がない | 同じファイルを複数タスクが編集する |
| 外部への書き込み | 対象と範囲が明記されている | APIの書き込み先や件数が曖昧 |
| リスク欄 | 具体的なリスクと回避策が書かれている | 「特になし」で済まされている |
Agent Teamsでも、事前確認が必要なら依頼文にその条件を明記します。tmux方式では AGENT_SYNC.md の承認済みタスク欄を確認してから、各セッションへ実行を指示します。
tmuxでの起動やセッション管理を繰り返す場合は、専用ツールを検討できます。選定時には、名称や見た目だけで判断せず、自分たちの環境で必要な起動方法、担当の表示、終了後の状態確認を比較します。
次の表は、ツールを比較するための整理です。対応環境や機能は導入前に各プロジェクトの公開情報で確認してください。
| ツール | 概要 | 想定環境 | 特徴 |
|---|---|---|---|
| smux | AIエージェント並列実行向けのターミナル | macOS | セッション管理を直感的に扱うことを重視 |
| amux | エージェント向けマルチプレクサ | macOS / Linux | CLIベースで軽量。tmuxを土台にエージェント向けの同期機能を加える |
| dmux | 分散型マルチプレクサ | macOS / Linux | 複数マシンをまたいだ並列実行を想定 |
いずれもClaude Code本体とは別のツールです。導入を決める前に、利用中の環境への対応、セッションの復旧方法、共有ファイルをどう扱うかを確認してください。
次は、作業ディレクトリと指示を分けて記録するための構成例です。特定ツールでそのまま読み込める設定形式を示すものではありません。実際の設定項目は採用するツールの説明に合わせます。
agents:
- name: content-writer
directory: ./01_marketing
prompt: "DD-46の記事を制作してください"
- name: code-reviewer
directory: ./02_product
prompt: "Sync for freeeのコードレビューを実施してください"
- name: data-analyst
directory: ./00_strategy
prompt: "売上データを分析してください"定義を作ったら、ディレクトリが存在するか、担当範囲が重ならないか、指示だけで完了条件を判断できるかを確認します。初回の実行結果を見て指示の不足を補い、同じ作業をほかの担当者も再現できる状態にします。
まずtmuxで必要な作業を試し、繰り返し発生する操作を記録します。セッションの起動、状態確認、終了後の成果物整理のどこに負担があるかを特定してから、その操作を扱えるツールを比較します。複数マシンでの実行が必要なら、接続と権限の管理方法も選定条件に加えます。
ヘッドレス実行は、対話画面を介さずにClaude Codeを起動し、結果を受け取る方法です。定型的なレビューや分析をスクリプトで実行したい場合に検討します。最初に入力、出力、失敗時の扱いを決め、結果を人が確認できるようにします。
-p オプションで並列起動するClaude Codeは -p で非対話モードを実行し、--output-format json で結果を受け取れます（出典：Run Claude Code programmatically）。次の例では、作業ディレクトリごとに処理を起動します。
#!/bin/bash
mkdir -p results
(cd ./repo-1 && claude -p "READMEを更新してください" --output-format json > ../results/repo-1.json) &
(cd ./repo-2 && claude -p "依存パッケージの更新候補を洗い出してください" --output-format json > ../results/repo-2.json) &
(cd ./repo-3 && claude -p "Lintエラーを修正してください" --output-format json > ../results/repo-3.json) &
wait
echo "全タスクが完了しました"wait の後に表示する文言だけで各タスクの成功を判断せず、終了状態、JSONの内容、変更差分を確認します。編集を伴う作業では、先に対象ファイルが重ならないようにします。
PythonやTypeScriptから制御する方法もあります。既存のCLIを呼び出す場合は、タスクごとに作業ディレクトリと戻り値を対応付けます。次の例は asyncio を使った並列起動の形です。
import asyncio
TASKS = [
{"dir": "./repo-1", "prompt": "READMEを更新してください"},
{"dir": "./repo-2", "prompt": "依存パッケージの更新候補を洗い出してください"},
{"dir": "./repo-3", "prompt": "Lintエラーを修正してください"},
]
async def run(task):
proc = await asyncio.create_subprocess_exec(
"claude", "-p", task["prompt"], "--output-format", "json",
cwd=task["dir"],
stdout=asyncio.subprocess.PIPE,
)
out, _ = await proc.communicate()
return task["dir"], proc.returncode, out
async def main():
results = await asyncio.gather(*[run(t) for t in TASKS])
for d, code, _ in results:
print(f"{d}: exit={code}")
asyncio.run(main())終了コードを確認した後、返された内容が依頼に対応しているかを確認します。変更を自動で採用する前に、差分と検証結果を見る工程を置きます。
GitHub Actionsのmatrix戦略を使えば、サービスごとにレビュー処理を分けられます。次はジョブ構成を考えるための例です。導入時はインストール手順と認証方法を利用環境に合わせて確認してください。
name: Parallel Claude Code Review
on: pull_request
jobs:
parallel-review:
runs-on: ubuntu-latest
strategy:
matrix:
service: [service-a, service-b, service-c]
steps:
- uses: actions/checkout@v4
- name: Install Claude Code
run: ""
- name: Run Claude Code Review
working-directory: ./$
run: claude -p "変更内容をレビューし、問題があれば報告してください" --output-format json
env:
ANTHROPIC_API_KEY: $この例のインストール欄は実行内容が未設定です。利用環境での導入手順を確認してから設定し、ジョブの終了状態だけでなくレビュー結果も確認します。ファイル編集やコマンド実行を許可する場合は、Run Claude Code programmaticallyの --allowedTools の説明を確認し、必要な操作の範囲を定めます。
/batch は、コードベースにまたがる変更を独立した作業に分けて進めるためのコマンドです。使う前に、対象がGitで管理されているか、変更同士に順序依存がないかを確認します。分割案が提示されたら、編集対象と統合後の確認方法を見てから進めます。
/batch はGit worktreeを使い、分割した作業を別々の作業ディレクトリで進めます。次のように対象と生成するファイルの置き場所を指定すると、分割案で何を確認すべきかが明確になります。
/batch src/components/配下の全.tsxファイルにReact Testing Libraryを使ったユニットテストを追加してください。各テストファイルは対応するコンポーネントと同じディレクトリに、{コンポーネント名}.test.tsxとして配置してください実行前に、共通の設定ファイルやテスト用ユーティリティへ変更が集中しないかを確認します。集中する場合は、その変更を先に決めるか、対象から切り離します。処理が終わった後も、各作業の結果と統合した状態のテストを確認します。
変更ごとに、別の変更の完成を待つ必要があるか、共通の設計判断や更新順が必要かを確認します。どちらも不要なら分割を検討できます。必要な場合は設計判断を先に終え、順次実行します。依存関係を判断できない段階では、分割を決めません。
| 区分 | タスク例 |
|---|---|
| 適する | テストファイルの一括生成／importパスの一括修正／コメント・ドキュメントの一括追加／リントエラーの一括修正／国際化（i18n）対応の一括追加 |
| 適さない | アーキテクチャの大規模変更／DBスキーマ変更（マイグレーションの順序依存）／共通ユーティリティの新規作成と利用／状態管理ストアの設計変更 |
依存が見つかった場合は、/planコマンドなどで実行順を整理してください。
変更を分割するときは、着手前の判断と完了後の確認を一続きの作業として扱います。各段階の結果が次へ進む条件を満たしているかを確認します。
| 段階 | コマンド | 次へ進む条件 |
|---|---|---|
| 計画 | /plan | タスクが独立した単位に分割できると判断できた |
| 実行 | /batch | 全エージェントの処理が終わり、エラー報告が整理できた |
| 検証 | /diff | 意図しない変更がなく、全エージェントの変更方針が揃っている |
| 整理 | /compact | 実行結果を要約し、次のタスクに使えるコンテキストが空いた |
差分に想定外の共通ファイルが含まれていたら、整理に進む前に担当と変更理由を確認します。検証が済んだ内容を次の作業へ引き継ぐときに、/compact を使います。
方法を選ぶ順序は、まずタスクの依存関係、次に作業場所、最後に繰り返し実行する必要性です。同じファイルや判断を共有するなら作業を分け直します。独立しているなら、同一リポジトリ内か、複数プロジェクトにまたがるかで候補を絞ります。
| 観点 | Agent Teams | tmux | smux/amux/dmux | ヘッドレス実行 | /batch |
|---|---|---|---|---|---|
| セットアップ | 設定1つで有効化 | tmuxのインストール | ツールのインストール | スクリプト・CI設定の実装 | 不要（内蔵コマンド） |
| オーケストレーション | 自動（リード判断） | 手動 | 半自動（定義ファイル） | プログラム制御 | 自動（タスク自動分割） |
| リポジトリ横断 | 不向き（単一リポ） | 可能 | 可能 | 可能 | 不向き（単一リポ） |
| タスク種類 | 検討・コード変更中心 | 制限なし | 制限なし | 制限なし | 独立したファイル変更 |
| CI/CD統合 | 不向き | 不向き | 部分的 | 向いている | 不向き |
| 学習コスト | 低 | 中 | 中 | 高 | 低 |
表は最初の比較に使い、実際の採用前には現在の利用条件と作業範囲を確認してください。たとえば同じリポジトリでも、複数ブランチの変更を分ける必要があるなら作業場所の隔離を優先します。定型的な読み取り作業をCIで繰り返すなら、入力と出力を固定できるかを先に確かめます。
StartLinkの使い分け: 日常的なコード変更にはAgent Teams、ブログ制作とコンサル業務の並行処理にはtmux、リリース前の一括品質チェックにはヘッドレス実行という組み合わせで運用しています。
導入時は、現在の業務で分離しやすい作業を選びます。次の段階へ進むかどうかは、起動できたかではなく、担当の重複なく成果物を確認できたかで判断します。
ある段階でレビュー待ちが増えたら、並列数を増やさず、成果物の単位と確認担当を見直します。
AIには担当範囲が明確な調査や下書き、変更案の作成を任せます。人間は分割案の妥当性、顧客や本番環境への影響、成果物の採用を判断します。
| AIに任せる作業 | 人間が判断する作業 |
|---|---|
| 同種のファイル変更の一括実行 | どのタスクを並列にしてよいかの判断 |
| テスト・ドキュメントの下書き生成 | タスク分割案と担当ファイルの承認 |
| 変更内容のレビューと問題点の指摘 | 本番ブランチへの取り込み判断 |
| 内部リンクや表記の整合性チェック | 外部APIへの書き込みを伴う作業の実行可否 |
HubSpotのように顧客データを持つシステムへの書き込みは、準備した変更案と実行対象を人間が確認してから、実行可否を決めます。
方法を決める際は、実際のタスクを並べて、同時に進められる部分と結果を待つ部分を分けると判断しやすくなります。ここでは、記事制作、異なる業務の並行、複数PRのレビューを例にします。
記事ごとに対象ファイルを分けられるなら、執筆を並行できます。ただし、共通のキーワード表や公開管理ファイルを更新する場合は、順番を決めます。
#!/bin/bash
ARTICLES=(
"DD-41:Claude Code Hooks活用法"
"DD-42:Claude Code MCP統合ガイド"
"DD-43:Claude Code Git Worktree実践"
)
SESSION="blog-batch"
tmux new-session -d -s $SESSION
for i in "${!ARTICLES[@]}"; do
if [ $i -gt 0 ]; then
tmux split-window -t $SESSION
fi
tmux send-keys -t $SESSION "claude \"${ARTICLES[$i]}の記事を制作してください\"" Enter
done
tmux select-layout -t $SESSION tiled
tmux attach -t $SESSION起動前に、記事ID、担当ファイル、参照する資料を確認します。完了後は各記事を独立して確認し、記事間で表記や内部リンクが矛盾しないかをまとめて見ます。
article_to_post_map.json や master_keyword_map.md は担当を決め、前の更新を確認してから次へ渡す設定スクリプトの準備、記事の執筆、内部リンクの確認は、成果物を分けて進められます。ただし、リンク確認の結果を記事へ反映する作業は、確認結果を受け取ってから進めます。
├── エージェントA: HubSpotスコアリングプロパティの設定スクリプト作成
├── エージェントB: ブログ記事のMD原稿執筆
└── エージェントC: 既存記事の内部リンク整合性チェック設定スクリプトの作成をAIに任せ、実行前の差分確認と本番反映は人間が担当します。記事側では、エージェントCが確認したリンクをエージェントBへ渡し、反映後の本文を確認します。待ち時間を減らせるかどうかは、この受け渡しが明確かを見て判断します。
PRごとにレビューや修正を進める場合は、まず変更ファイルの重なりを調べます。重ならない範囲なら担当を分け、共通ファイルへ触れるPRは更新順を決めます。
4人のチームメイトを立てて、以下の4つのPRをそれぞれ割り当て、
コードレビュー指摘事項の修正を並列で進めてください。
各チームメイトは担当PRの変更ファイル以外を編集しないでください。
- PR #142: ユーザー認証フローの改善
- PR #145: ダッシュボードのパフォーマンス最適化
- PR #147: API v2エンドポイントの追加
- PR #149: E2Eテストの追加Agent Teamsのチームメイトはworktreeへ自動隔離されないため、この依頼文だけでPRごとの作業場所が分かれるわけではありません。先に作業場所を確認し、別ブランチの変更を同時に扱う必要があればGit worktreeでセッションを分けます。各PRの確認後には、共通のテストや設定への影響も見ます。
一律には判断できません。各セッションやチームメイトの利用量に加え、調整のためのやり取りや、やり直しの有無によって変わります。まず小さな独立タスクで利用量と成果物の確認にかかった作業を記録してください。確認や修正の負担が大きければ、並列数とタスクの分け方を見直します。
競合したファイルの編集をいったん止め、それぞれの変更目的と担当を確認します。採用する変更と更新順を決めてから差分を統合し、関連する検証をやり直してください。次回はAgent Teamsの依頼文や AGENT_SYNC.md に所有者を記録します。ブランチごとに作業場所を分ける必要があるならGit worktreeも検討します。
調査や確認の結果を呼び出し元が受け取れば進められる作業は、サブエージェントを検討します。担当者同士で発見を共有し、作業の割り当てを調整する必要がある場合はAgent Teamsを検討します。どちらを使う場合も、編集対象が重なれば先に担当を分けます。
自然言語で役割を依頼できる方法はありますが、作業の対象、成果物、確認者を決める必要があります。tmuxやヘッドレス実行を使う場合は、担当者が起動手順と結果の確認方法を用意し、利用者が意図した作業だけを実行できるか試してください。手順だけで成果物を判断できないなら、確認項目を追加します。
/batch はGit worktreeを使うため、Gitで管理された作業場所が必要です。Git管理されていない作業を進めたい場合は、先にリポジトリ管理の要否を判断してください。そのうえで、単に独立した作業を同時に進めたいだけなら、別ディレクトリのセッションやtmux方式も比較します。
Claude Codeの並列実行では、ツールを選ぶ前に、タスクの依存関係、担当ファイル、結果の確認者を決めます。
最初に、実際のタスクを「同時に着手できるもの」と「先行する結果を待つもの」に分けてください。次に担当ファイルと共有ファイルの更新順を記録し、小さな作業で成果物の受け渡しを試します。変更が衝突したりレビュー待ちが増えたりしたら、並列数ではなく分割方法を見直します。
企業様によって最適な形は異なります。既存の開発・制作フローに合わせ、誰が何を確認したら次へ進めるかまで決めることが、継続できる並列運用につながります。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
このテーマと関連する内容を、次の記事でも詳しく解説しています。
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
