AIに作業を任せられるようになると、次に思う。これを3本、4本と同時に走らせたら、もっと速くなるのではないか。
ところが試してみると、速くならない。許可を求めて止まったタブが並び、答えて回るのが仕事になる。完成したものが積み上がるのに、受け入れが追いつかない。しかも、気づかないうちに自分が作ったファイルが、別の作業の記録に紛れ込んでいる。
並行を詰まらせるのは、AIの速さではありません。起動方式の選び間違い、準備不足、そして人のレビューです。 この記事では、そこを順に潰す手順を書きます。実際に4本を並行させて起きた失敗も、そのまま載せます。
そもそも「同時に走らせる」とは
ここで言う「同時に走らせる」は、1つの大きな仕事を分けて、複数のAIに別々に進めさせることです。分け方は大きく3つあります。
| 方式 | 中身 | 向いている仕事 |
|---|---|---|
| ① サブエージェント（裏で動かす） | 自分は別の作業を続けられる。ただしコマンドを実行できない | 調査・比較、文書の下書き、レビュー |
| ② サブエージェント（待ちながら動かす） | 終わるまで待つ。許可を求められたら答えられるのでコマンドを実行できる | テストの実行、git 操作を伴う作業 |
| ③ worktree ＋ 別セッション | 作業フォルダごと分けた、完全に別の会話。中断・再開ができる | 数日かかる実装、複数機能の同時開発 |
①と②は別の仕組みではなく、同じサブエージェントの実行モードの違いです。別物だと思っていると、切り替えられることに気づけません。
選ぶ決め手は「途中で会話が必要か」
作業時間や規模で選ぼうとすると迷います。本当の分かれ目は、次の3つの問いです。
- 設計判断が出てくる、仕様が固まっていないなど、途中で相談・方向修正が必要か
- 今日で終わらない、中断して再開するなど、何日もかけて進めるか
- 多くのファイルを書き換え、他の作業と同じファイルを触りうるか
どれか1つでも「はい」なら worktree ＋ 別セッション。 すべて「いいえ」ならサブエージェントで足ります。サブエージェントは1回の依頼で完結するので、方向がずれても最後まで走ってから気づくことになります。
迷ったらサブエージェントから始めてください。worktree は作業場の作成・統合・片づけの手間がかかります。「途中で相談したくなった」「今日で終わらない」と分かった時点で切り替えれば、途中まで進んだ内容は新しい作業場へ持っていけます。
選び間違えると、次のことが起きます。
| 間違い | 症状 |
|---|---|
| worktree にすべきものをサブエージェントに投げた | 途中で相談できないまま最後まで走り、方向のずれたものが完成する。大量の出力でメインの記憶も圧迫される |
| サブエージェントで足りるものを worktree にした | 15分の作業に30分の準備がかかる |
| worktree を作ったまま放置した | 次に間違えてそこで作業する。本流に統合されないまま古くなり、最後に大量の競合を抱える |
いちばん多い失敗は、コマンドが要る作業を「裏で」動かすこと
裏で動かすサブエージェントは、許可を尋ねる相手がいないので、コマンドを実行できません。コマンドが要る作業を裏に回すと、着手する前に止まります。
対処は分業です。ファイルの編集だけをエージェントに任せ、コマンドの実行は自分（メインセッション）が行います。指示の末尾に次の一文を足します。
コマンドの実行はこちら（メインセッション）で行います。
あなたはファイルの作成・編集までを行い、完了報告に
「メインセッションで実行すべきコマンド」を列挙してください。実装を並行させるなら、子セッションが要る
実装には git の操作やテストの実行が付きものです。裏で動かすエージェントだけでは完結しません。そのため実装を並行させるときは、メインセッションが子セッション（別タブの Claude Code）を起動し、会話し、統合する形をとります。「エージェントに全部やらせる」のではなく、「メインが子セッションを操る」。これが、いわゆる全自動の実体です。
このときメインは実装をしません。分解・作業場づくり・起動・連絡・統合・片づけに専念します。以降、このメインを管制塔と呼びます。人が手を動かすのは、最初の依頼と、止まったときの判断と、最後の受け入れだけです。
用意するもの
並行させる前に、次の4つがあるかを確かめます。無いまま始めると、右の列のことが起きます。
| 用意するもの | 無いとどうなるか |
|---|---|
| 許可リスト（よく使うコマンドの事前許可） | 子セッションが毎回「実行してよいですか」で止まる。4本なら許可を求める場面は4倍になり、タブを見て回ることが主な作業になる |
| 禁止リスト（「変更を全部まとめて記録する」操作の禁止） | 別のセッションが作業中のファイルまで巻き込まれ、巻き込まれた側は気づく機会がない |
| 並行運用のルールを書いた CLAUDE.md | 同じ指示を毎回説明することになる。2回言ったことは CLAUDE.md に書く |
| 作業ごとに分けた作業場（worktree） | 同じフォルダを2つのセッションが触り、編集の上書きや、ブランチ切り替えによるファイルの入れ替わりが起きる |
もう1つ、担当ファイルの一覧が要ります。誰がどのファイルを持つかを1つの表にして、全員が同じものを見られるようにします。
なぜ同じフォルダで並行できないのか。フォルダは「いま1つの状態」しか持てないからです。一方のセッションがブランチを切り替えると、フォルダの中身が丸ごと入れ替わり、もう一方が編集していた内容も一緒に消えます。worktree は、1つのリポジトリから作業フォルダだけを複数作る仕組みです。履歴は共有したまま、フォルダごとに別のブランチを開けます。
分けるかどうかの決め方は1つだけです。ファイルを1つでも書くなら作業場を分ける。読むだけなら分けなくてよい。「レビューするだけ」「調べるだけ」を理由に分けないのは危険です。調べた結果をまとめた文書も、立派な成果物だからです。実際に、「調査だけだから」と分けずに始めたセッションが数百行の調査メモを書き、それが別の作業の記録に紛れ込みました。そのコミットの題名は「デプロイ手順の訂正」で、中身には調査メモが丸ごと入っていました。内容が消えるわけではありませんが、題名と中身が一致しなくなり、あとから「あの変更だけを取り消したい」と思ってもできません。
手順
手順1 許可リストを整える
子セッションは、コマンドを実行するたびに許可を求めてきます。答えるまで、その子は止まったままです。よく使うコマンドを許可しておけば、この停止はほぼ無くなります。メインに次のように頼みます。
これから複数の作業を並行させます。
子セッションが毎回「実行してよいですか」で止まらないように、
許可リストを整えてください。
1. このプロジェクトでよく使うコマンドを洗い出す
（テスト実行 / ビルド / 状態確認 / 差分確認 など）
2. そのうち「読み取りだけ」「元に戻せる」ものを許可リストの候補として挙げる
3. 候補を一覧で見せてから、私が承認したら設定に追加する
次のものは許可リストに入れないでください。
- ファイルやフォルダを消すもの
- 外部へ送信するもの（デプロイ・アップロード・メール送信）
- 本番環境に触れるもの
追加した内容は、あとで見返せるように記録も残してください。なぜ最初にやるのか。 ここを先に潰しておくと、走らせている間にやることが本当に減るからです。許可リストに入れるのは「読み取りだけ」「元に戻せる」ものに限ります。消す、送る、本番に触れる、は入れません。
禁止リストも、準備としては同じ時点で入れます。独立した節で詳しく書くので、先に手順の続きを進めます。
手順2 CLAUDE.md に並行のルールを書く
並行のルールを CLAUDE.md に貼っておくと、毎回同じことを指示せずに済みます。入れる項目は次のとおりです。
## 並行開発のルール
### 所有権を先に決める
- 作業を割る前に「どのファイルを誰が触るか」の表を作り、全員が同じ表を見る
- 表は tasks/ownership.md に置き、変更は管制塔だけが行う
- 所有権は「ファイル」ではなく「そのデータへの書き込みロジック」で切る
### 触ってよい範囲
- 自分の作業場から出ない。他の担当のファイルは読んでよいが、書いてはいけない
- 必要になったら、自分で直さず「こう変えたい」と管制塔へ報告する
- 共有ファイル（設定・共通関数・型定義）は管制塔が持つ
### 報告のしかた
- 区切りごとにコミットする（作業が失われるのを防ぐ／進捗が外から見える）
- 検証が終わっていないものを「終わった」と書かない
### 止まる条件（必ず人に聞くこと）
- 担当ファイルが重なるとき
- 統合で競合が出たとき
- 仕様の解釈が2通り以上あるとき
- 消す・上書きするなど、元に戻せない操作をするときなぜか。 「所有権をファイルではなく書き込みロジックで切る」のは、ファイル単位で分けたつもりでも、同じデータを2か所から更新する構造ができてしまうことがあるからです。そうなると、どちらを正とするかを後から決め直すことになります。
手順3 セッションどうしが連絡できるかを確かめる
管制塔から子セッションへ直接メッセージを送れる環境かどうかを、先に確認します。送れない場合は、あなたが内容を転記することになり、進め方が変わります。次の1行で足ります。
いま起動している Claude Code のセッションを一覧で出せますか。
出せる場合、そのセッションへ直接メッセージを送れるかも教えてください。
できない場合は、その旨だけ答えてください。手順4 プロンプト1本で回す
準備ができたら、依頼は1回で済みます。分解・作業場づくり・起動・指示・進捗管理・統合・片づけまで、1本に含めます。要点は次の5つです。
- 分解 1つ1〜3時間で終わる粒度に割る。担当ファイルが重ならないよう割り当て、一覧を
tasks/ownership.mdに残す。分解結果は画面に出させるが、承認は待たせない - 作業場づくりと起動 作業ごとに worktree を作り、Git 管理外だが必要な設定ファイルを引き継ぎ、子セッションを起動して最初の指示を渡す
- 走っている間 完了したら通知を受ける形にし、子どうしを直接やり取りさせない。指示が誤っていたら、気づいた1本だけでなく全部の作業場へ訂正を配る
- 完了報告を受けたら 鵜呑みにせず、履歴と差分を自分で確認してから受け入れる
- 統合と片づけ 小さいものから順に統合し、1本統合するごとに残りへ最新を取り込む。最後に統合後の状態で動作確認まで行う
子セッションに渡す最初の指示には、必ず次を含めます。何をするか（前提を知らない相手に説明する形で）、触ってよいファイルと触ってはいけないファイル、完了条件、コミットまで行い push はしないこと、完了したら何を報告するか。
そして、次の場合は必ず止まって人に聞かせます。
- 担当ファイルが重なってしまう
- 統合で競合が出た
- 仕様の解釈が2通り以上ある
- 消す・上書きするなど、元に戻せない操作をする
これ以外は自分の判断で進めさせ、決めたことは理由とセットで1か所に記録させます。「私の承認は待たなくてよい」を入れるのは、分解のたびに止めると自動化した意味がほぼ無くなるからです。 ただし、分解の結果を画面に出させることだけは残してください。止まらないので手間はゼロですが、あとで問題が起きたときに「どう割り当てたか」を遡れます。これが無いと、原因を追うところからやり直しです。
並行が2〜3本で、領域が明確に分かれ、新規ファイルの追加が中心なら、分解の承認は省略して構いません。逆に、並行が4本以上、同じモジュールを複数が触る、共通部分（設定・共通関数・型定義）に手が入る、といった場面では止めてください。省略するなら、統合の前に作業場どうしの重なりを検出させることで補います。事前に止めるか事後に見つけるかの違いで、どちらも無いと、競合に気づくのがマージの瞬間になります。両方の作業が終わってからのやり直しです。
手順5 受け入れて、統合して、片づける
人がやるのは受け入れの判断です。読む前に、メインに照合させます。
並行して進めた作業を受け入れます。私が読む前に、次を確認して一覧で報告してください。
1. 各作業が完了条件を満たしているか（1つずつ照合して結果を書く）
2. 割り当てたファイル以外を触っていないか（差分で確認する）
3. 作業場どうしで同じファイルを触っていないか
4. 同じ用途のものを別々に作ってしまっていないか
5. 顧客名・パスワードの混入が無いか（機械的に検査する）
6. 私が判断すべき点（作業ごとに3点以内）
「問題ありません」だけの報告はしないでください。
確認した内容を1項目ずつ示してください。レビューは「読む」のではなく「完了条件に照らす」作業にします。そうしないと、読むたびに気になる点が増えて終わりません。機密の混入は目視ではなく検索で確認します。直すときは全部やり直しではなく、どこを・なぜ・どう直すかを指定します。
統合は、変更量が小さいものから順に行います。大きい方を先に入れると、小さい方が大量の競合を抱えるからです。1本統合したら、他の作業場へ最新を取り込みます。ずれが小さいうちに解消するためです。競合が出たら、管制塔のフォルダで直します。子セッションに直させると、同じ箇所を別々に直して、さらに壊れます。統合し終えたら作業場と枝を消します。残すと、次に間違えてそこで作業してしまうからです。
人が手放してはいけないのは3つです。レビューと受け入れ、競合の解消方針、仕様の解釈が割れたときの決定。 どれもやり直しが効かない判断です。
事故を防ぐ設定 — 許可リストとセットで「禁止リスト」も入れる
許可リストは「止まらないようにする」ためのものでした。これとは別に、並行させるなら必ず入れておきたい禁止があります。「変更を全部まとめて記録する」操作です。
| 操作 | 並行時に何が起きるか |
|---|---|
変更を全部まとめて記録する（git add -A / git add . / git commit -a） |
フォルダの中身を丸ごと拾うため、別のセッションが作業中のファイルまで巻き込む。巻き込まれた側は自分で記録していないので、気づく機会がない |
変更したファイルを名指しで記録する（git add ファイル名） |
自分が触ったものだけが記録される。これを既定にする |
禁止リストの対象は、git add -A、git add .、git add --all、git commit -a です。書き方の違いで抜けないよう、表記ゆれもまとめて並べます。1つでも漏れると、そこから入ってきます。
設定ファイルの書き方は使っているツールによって違うので、自分で書式を調べるより、後述のようにメインへ頼んで入れてもらうのが確実です。
もう1つ入れるのが、記録する直前に、いま自分がどのブランチに居るかを毎回表示させる仕組みです。セッションを始めたときの表示は、途中で古くなります。別のセッションがブランチを切り替えると、自分が変えていないのに、居る場所が変わります。「記録したはずの変更が、目的のブランチに無い」という事故は、これで起きます。
メインには、次のように頼みます。
複数のセッションを並行させるので、事故防止の設定を入れてください。
1. 「変更を全部まとめて記録する」操作を禁止リストに入れる
（git add -A / git add . / git add --all / git commit -a）
→ 記録は必ずファイル名を指定する形にしたい
2. 記録する直前に、いま自分がどのブランチに居るかを
毎回表示するようにしてください
→ セッションを始めたときの表示は、途中で古くなるため
3. 入れ終わったら、実際に禁止されているかを1回試して確認してください
（危険のない形で試せる方法があれば、それで確認してください）
設定した内容と、確認した結果を報告してください。3番を必ず入れてください。設定に書いただけでは、確認になっていません。
なぜ「ルールを書く」ではなく「設定で止める」のか
同じ事故を防ぐために、CLAUDE.md に禁止事項として書いた対策が、2回とも破られたことがあります。2回目は、そのルールを書いた本人（AI）が、ルールを読める状態のまま破りました。
「なぜそうするか」は CLAUDE.md に、「何を禁止するか」は設定に書く。文章で書いたルールは実行直前に読まれる保証がない。
CLAUDE.md は、AIが判断するときの理由と背景を伝える場所です。ただ、実行の直前に読み返される保証はありません。実行を止められるのは設定だけです。この2つを混ぜると、片方が効かなくなります。禁止を文章だけで書いて満足しないでください。
なお、禁止リストは最後の網です。そもそも作業場を分けていれば、他のセッションのファイルを巻き込む事故は起きません。分ける、禁止する、直前に現在地を見る、の3つを重ねておくと、どれか1つが抜けても事故になりません。
走っている間に見る場所
並行しているものを全部追いかける必要はありません。見る場所は5つに絞れます。このうち1と3だけが、人にしかできません。
| # | 見るもの | だれが | 放っておくとどうなるか |
|---|---|---|---|
| 1 | 止まって聞いてきたこと（担当の重なり・競合・解釈が2通り・元に戻せない操作） | あなた | 推測で進み、完成してから方向違いが分かる |
| 2 | 確認待ちの件数（3件を超えたら新しく始めさせない） | メイン | 成果物は増えるのに、いつまでも完了しない |
| 3 | 許可を求めて止まっているタブ | あなた | 作業を抱えたまま静かに止まり続ける |
| 4 | 使っている資源の残り（外部サービスの呼び出し回数・容量・同時実行数） | メイン | 全部が同時に止まる |
| 5 | 担当ファイルの一覧 | メイン | 重なりに気づくのが統合の瞬間になる |
状況は、1日1〜2回、次のようにまとめて出してもらいます。
いまの状況をまとめて出してください。
1. 各作業場の進み具合（コミット数 / まだ保存していない変更の数 / 直近の作業内容）
2. 全体の到達点
3. 作業場の一覧（放置されているものがあれば指摘する）
4. 使っている資源の残り（外部サービスの呼び出し回数・容量など）
5. 私の確認待ちになっているもの
6. 止まっているもの（あれば理由も）
確認待ちが3件を超えていたら、新しい投入を止めて
先に見るべきものから順に出してください。「まだ保存していない変更の数」を入れているのは、子セッションが長時間コミットせずに書き続けていることがあるからです。そのまま落ちると全部失われます。「区切りでコミットして」と伝えるだけで防げます。
並行数の目安
| 指標 | 目安 | 崩れたときの症状 |
|---|---|---|
| 同時に動かす数 | 3〜4本 | 超えると、分割・統合・衝突の解消に時間を取られる |
| レビュー待ち | 3件以下 | 超えたら新しい投入を止める |
| 投入からレビューまで | その日のうち | 翌日以降になると、内容を思い出す時間が上乗せされる |
並行数を増やせば速くなる、というのは途中までしか正しくありません。レビューするのは常に自分1人なので、そこが詰まると全体が止まります。増やすべきは投入数ではなく、片づける速さです。 レビュー待ちが増えたら、新しい投入を止めて片づけを優先してください。
並行してよいかの判定は、「Aが終わっていなくてもBを始められるか？」と問うだけです。始められないなら順番が必要です（データ構造の変更から実装へ、公開から動作確認へ、同じファイルを2人が編集、など）。
4本以上を回すときに効いたこと
2〜3本と4本以上では、必要な仕組みが変わります。実際に4本を並行させて分かったことです。
| やったこと | やらないとどうなるか |
|---|---|
| 所有権を1つの表にまとめ、全員に同じものを見せる。初期プロンプトの「触ってよい／いけないファイル」の列挙だけでは足りない | 担当の重なりに気づくのがマージの瞬間になり、両方の作業が終わってからやり直しになる |
| 所有権を「ファイル」ではなく「書き込みロジック」で切る | 同じデータを2か所から更新する構造ができ、どちらを正とするかを後から決め直すことになる |
| 管制塔から各セッションへ直接連絡する手段を用意する | 伝達が人の手作業の転記になり、伝え漏れと遅れが積み上がる |
| 終わったら知らせてもらう（聞きに行かない） | 状況確認そのものが管制塔の仕事になり、待ち時間が増える |
| 報告を鵜呑みにせず、必ず自分で確かめる | 誤った前提の上に次の判断を積み上げ、後からまとめて崩れる |
| 管制塔の指示が誤っていたら、全員へ訂正を配る | 他の担当が誤った前提のまま作業を続ける |
報告と実物がずれた実例
実際に4本を回したとき、次のずれが起きました。悪意はなく、自分の手元しか見えていないことが原因です。
- 「コミット8本」と報告されたが、実際は10本だった
- 「この不具合を直してほしい」と2回報告されたが、すでに直っていた（その担当の手元が古いままだった）
- 管制塔が「この変更で直るはず」と見立てたが、前提を1つ見落としていて外れた
報告を受けたら、履歴と差分を自分で確認してから受け入れる。これが管制塔の中心的な仕事になります。
並行数は「レビュー能力」だけでは決まらない
3〜4本という目安は、レビューが詰まる限界から来ています。実際にはもう1つ、環境側の上限があります。外部サービスの1日あたり呼び出し回数、テスト環境の容量、ビルドの同時実行数などです。4本が同時に検証を回すと、1本のときの4倍の速さで上限に達します。実例として、開発用の検証環境が1日の呼び出し上限に達し、4本すべてが半日止まりました。 並行を増やす前に、共有している資源の上限を1度確認してください。
うまくいかないときの原因
並行運用で起きる失敗に絞って整理します。
| 症状 | 原因 | 対処 |
|---|---|---|
| 着手する前に止まる | コマンド実行が必要な作業を、裏で動かした | 待ちながら動かす。または編集だけ任せ、コマンドは自分で実行する |
| 並行させたのに遅い | 順番が必要な作業を同時に動かした | 「Aが終わらなくてもBを始められるか」で判定する |
| 成果物は増えるが完了しない | 投入を続けてレビューが詰まった | レビュー待ち3件で投入を止める |
| 作った文書が、別の作業の記録に紛れ込んでいる | 同じ作業フォルダで2つのセッションが動き、片方が変更を全部まとめて記録した | 禁止リストで「全部まとめて記録」を止める。書く作業なら必ず作業場を分ける |
| 記録したはずの変更が、目的のブランチに無い | 別のセッションがブランチを切り替えた後だった。始めたときの表示は古くなる | 記録の直前に現在地を毎回表示させる。作業場を分ければそもそも起きない |
| 同じ失敗を2回した。ルールは書いてあった | 禁止を文章で書いただけで、実行を止める仕組みが無かった | 「なぜ」は CLAUDE.md、「何を禁止するか」は設定に分けて書く |
| 統合の瞬間に競合が大量に出る | 担当ファイルが重なっていた。または作業場を放置して古くした | 割り当てを先に決める。1本統合するごとに残りへ最新を取り込む |
| 全部の作業が同時に止まる | 共有している資源（呼び出し上限・容量）が尽きた | 並行を増やす前に上限を確認する。残りが少なくなったら全員へ節約を通達する |
| 報告と実物が食い違う | 子セッションは自分の手元しか見えていない | 履歴と差分を自分で確認してから受け入れる |
最初の1週間の進め方
いきなり並行させないことです。1件を最後まで通す経験がないと、詰まったときに原因が分かりません。
| 日 | やること |
|---|---|
| 1〜2日目 | CLAUDE.md を置く（最小構成でよい）。1件だけ任せてみる |
| 3〜4日目 | 分解を頼み、依存関係を出させる。2件を並行させる |
| 5〜6日目 | 4件まで増やす。レビュー待ちを数え、詰まる感覚をつかむ |
| 7日目 | 繰り返した作業を、スキル（手順書）として固定する |
並行は3日目以降、スキル化は7日目でよい、という目安です。
チェックリスト
並行させるとき
- このセッションはファイルを書くか。書くなら作業場を分けたか（「調べるだけ」でも成果物は生まれる）
- 「変更を全部まとめて記録する」操作を禁止リストに入れたか
- その禁止が実際に効くかを1回試して確かめたか（設定に書いただけでは確認になっていない）
- 元のフォルダは管制塔専用にして、そこで作業していないか
- レビュー待ちは3件以下か
レビューのとき
- 完了条件を1つずつ照合したか
- 機密の混入を検索で確認したか
- 直すなら、どこを・なぜ・どう直すかを指定したか
- かかった時間を記録したか
補足 自分でコマンドを打って並行させる
ここまでの自動化は、メインセッションが次の手順を代わりに実行しているだけです。うまく動かないときに中身を確かめられるよう、手動の手順を残します。
# 1. 作業場を作る（main から feature-a という枝を切って、隣に新しいフォルダを作る）
git worktree add ../myproject-feature-a -b feature-a
# 2. その作業場へ移動して、子セッションを起動する
cd ../myproject-feature-a
claude
# 3. 統合する（管制塔のフォルダに戻ってから）
cd ../myproject
git merge feature-a
# 4. 片づける（統合が終わったら作業場と枝を消す）
git worktree remove ../myproject-feature-a
git branch -d feature-a注意したいのは、競合を防ぐのは worktree ではなく「割り当て」だということです。worktree はフォルダを分けるだけで、統合するときの競合は防ぎません。2つの作業場が同じファイルの同じ行を直していれば、マージで必ずぶつかります。子セッションの最初の指示には、触ってよいファイルと触ってはいけないファイルを明示してください。
この作業場（feature-contact-form）で、問い合わせフォームを実装してください。
【触ってよいファイル】
- src/forms/contact.py（新規作成）
- src/forms/__init__.py（1行の追記のみ）
- tests/test_contact.py（新規作成）
【触ってはいけないファイル】
- src/main.py … 別の作業場が触っています
- config.json … 管制塔が管理しています
必要になった場合は、自分で編集せず「こう変えたい」と報告してください。
【完了条件】
- テストが通ること
- 上記3ファイル以外に変更が無いこと（git status で確認する）
【完了したら】
1. コミットまで行う（push はしない）
2. 変更したファイルの一覧を報告する
3. 私（管制塔）に伝えるべき点があれば書く子セッションどうしは会話させません。情報は必ず管制塔を経由させます。直接やり取りさせると、何が決まったのかを管制塔が把握できなくなります。
まとめ
- 同時に走らせる前に、起動方式を選ぶ。決め手は「途中で会話が必要か」。迷ったらサブエージェントから始める
- 実装を並行させるなら、worktree で作業場を分け、ファイルを1つでも書くなら分ける
- 準備は3つ。許可リストを整え、禁止リストで「全部まとめて記録」を止め、並行のルールを CLAUDE.md に書く
- 「なぜ」は CLAUDE.md に、「何を禁止するか」は設定に書く。文章のルールだけでは止まらない
- 速くなるかどうかは、投入数ではなく片づける速さで決まる。レビュー待ち3件で投入を止める
- 報告は鵜呑みにしない。履歴と差分を自分で確かめる
最初から4本を回す必要はありません。1件を最後まで通し、次に2件を並行させ、禁止リストが実際に効くことを1回試す。ここまで通せば、並行運用の土台はできています。
この記事の進め方を、自分のプロジェクトに合わせて組み立てたい場合は、1on1のトレーニングで一緒に設定しながら進めることもできます。作業場の分け方や禁止リストの入れ方は、実際のリポジトリを見ながらのほうが早く決まります。
内容を知りたい方はAI開発トレーニングのページをご覧ください。
