「Claude Code を使ってはいるけど、規模が大きくなるとコンテキストが溢れて精度が落ちる」
「結局、AI に修正指示を出している自分の手が一番の渋滞ポイントになっている」
このあたりで止まっている人は多いと思います。僕も最初は1つのセッションにコードもテストも設計議論も全部投げ込んで、履歴が膨らむほど Claude の精度が落ちていくのを眺めていました。
最近わかってきたのは、1人で複数の Claude Code を並行で回すための仕組みを、Claude Code 自身が公式に3つ用意しているということです。
しかもこの3つは似て非なるもので、混同すると逆に事故ります。
逆に役割で分けてしまえば、自分はコードを1行も書かずに「指揮する側」へ回れます。
今日はその3つの仕組みと、役割境界の正しい固定方法を、公式ドキュメントの一次情報で確認しながら整理します。
具体的には、指揮・実装・品質の3層に8セッションを配置する形まで落とし込みます。
ついでに、よく見かける「CLAUDE.md に役割 ID を書いて切り替える」「SQLite で記憶を共有する」という説明が、なぜ公式の仕組みとズレているのかも一次情報で確認します。
tatsuki（@nobel_824）と申します。
中小企業向けに AI の活用サポートをしていて、Claude / Codex の業務導入を手伝いつつ、自分でも Claude Code を1日中走らせています。
並列運用は仕事でもプライベートでも毎日触っている領域です。
関連記事：【vibe coding入門】コードが書けない人がClaudeでアプリを作る6ステップ。週末で内製化できる時代になった
https://note.com/nobel/n/n8192ec07d689
1. なぜ「1セッションに全部詰め込む」と破綻するのか
最初にハマる罠は、1つのセッションに情報を盛りすぎることです。どれだけ Claude のモデルが賢くても、構造的な限界に当たります。
具体的には、次の3つに当たります。
- コンテキストの汚染：実装コード、テスト、デバッグ履歴、設計議論が同じ文脈に混ざると、推論の足場が濁って精度が落ちます。
- 指示のコンフリクト：「スピード優先で実装して」と「セキュリティを厳格に」が同じ場所にあると、判断が中途半端になります。
- トークン（AI が処理する文章の最小単位）の肥大化：膨らんだ履歴を毎回読み込ませるのは、時間的にもコスト的にも無駄が出ます。
ここを解くのが「自分が1人の指揮官になり、専門化した Claude を並べる」という発想です。CTO の下にテックリードやバックエンド担当を置く感覚に近いですが、大事なのは雰囲気ではなく、Claude Code が公式に持っている仕組みに正しく乗せることです。
今日できる1アクション：いまの自分のセッションを思い出して、「実装」「調査」「レビュー」が1つの文脈に同居していないか確認してみてください。同居していたら、それが分割の出発点です。
2. 公式が用意した「3つの並列の仕組み」を正しく分ける
ここが記事の核心です。Claude Code には並列のための仕組みが3つあり、それぞれ守備範囲が違います。
ひとつめが subagent（サブエージェント。メインの会話とは別のコンテキストで動く補助 AI） です。調査やレビューのような脇道のタスクを、独自のコンテキストウィンドウ・専用の system prompt（AI の役割を決める指示文）・限定したツール権限で実行し、結果の要約だけをメインに返します。ポイントは、subagent は同一セッション内で動き、メインにだけ報告し、subagent 同士は会話しないことです（公式ドキュメント）。
ふたつめが agent teams（エージェントチーム。複数の Claude Code セッションがチームとして連携する仕組み） です。1つのセッションが team lead（リーダー）になり、teammate（メンバー）を生成して、共有のタスクリストと mailbox（メッセージの受け渡し箱）を介して連携します。subagent と違って teammate 同士が直接メッセージを送り合えるのが大きな差です。これは実験的機能で、デフォルトでは無効です。CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 を設定して有効化し、Claude Code v2.1.32 以降が必要だと公式が明記しています（公式ドキュメント）。
みっつめが git worktree（同じリポジトリから複数の作業ディレクトリを切り出す Git の機能） です。claude --worktree feature-auth のように起動すると、別ブランチ・別ディレクトリの隔離された作業環境で Claude が立ち上がり、別ターミナルでもう1つ走らせれば、互いのファイルを踏まずに並行できます（公式ドキュメント）。デスクトップアプリを使う場合は、新しいセッションごとに worktree が自動で作られます。
3つの違いを表にすると、こうなります。
worktree がファイルの隔離を担当し、subagent と agent teams が作業そのものの連携を担当する、という分担で覚えると混乱しません。
今日できる1アクション：まず claude --worktree bugfix-test を打って、隔離されたセッションが1つ立ち上がる感覚だけ掴んでみてください。変更を加えて終了すると、worktree を残すか消すか聞かれます（変更もコミットも無ければ自動で片付きます）。
3. 実践：8セッションを「3層構造」で配置する
ここまでの3つの仕組みを、実際に8セッションへ落とすとどうなるか。僕が回しているのは、指揮・実装・品質の3層に分ける配置です。
指揮・設計レイヤー（2セッション）
- Session 1 PM（プロジェクトマネージャ）：全体の進捗管理、タスクの切り出し、人間への報告。
- Session 2 Architect（設計担当）：技術的な整合性とディレクトリ構造を決める。plan approval を要求して、設計だけ出させてコードは書かせない。
実行・実装レイヤー（4セッション）
- Session 3 Frontend：コンポーネント作成、画面まわりの調整。
- Session 4 Backend：エンドポイント実装、クエリ最適化。
- Session 5 Infra/DevOps：Docker、CI/CD（自動でビルドとデプロイを回す仕組み）の整備。
- Session 6 Security：脆弱性チェック、認証まわりの堅牢化。
品質・保守レイヤー（2セッション）
- Session 7 QA/Reviewer：PR レビュー、エッジケースの指摘。
- Session 8 Technical Writer：README、API ドキュメントの整備。
配置のコツは3つです。実装レイヤーの4つは worktree で隔離して互いのファイルを踏ませない。品質レイヤーは subagent 定義や agent team の teammate として役割を固定する。そして各セッションは共有の Markdown ファイル（設計メモやレビュー結果）を介して情報をリレーする。Architect が設計を更新し、それを見た実装層が動き、Reviewer が結果を書き戻す。人間はこのファイルの更新をトリガーに各セッションへ指示を出すだけで済みます。
1つ注意があります。agent team の1チームは3〜5人が公式の目安なので、8を一気に1チームに詰め込まないことです（公式ドキュメント）。worktree で隔離したセッションと、3〜5人の agent team、必要なら subagent を組み合わせて、合計で8の働き手にするイメージが安全です。
今日できる1アクション：上の8役割のうち、いまの自分のプロジェクトで「すぐ分けられそうな2つ」を選んでみてください。多くの場合、Architect（設計）と Reviewer（レビュー）の2つが最初の分割点になります。
4. 役割境界は「CLAUDE.md」ではなく「subagent 定義」で固定する
並列運用でよく出回っている誤解を、ここで1つ正しておきます。「CLAUDE.md に役割（ID: arch、ID: dev-main…）を書いて、起動のたびにペルソナを切り替える」という説明を見かけますが、これは仕組みとして存在しません。
CLAUDE.md は、Claude Code が起動時に読み込む共通の指示ファイルです。ただし公式は、CLAUDE.md を「context であって、強制される設定ではない」とはっきり書いています。system prompt の後に user message として渡されるため、厳密な遵守は保証されず、何かを必ず止めたいなら hooks（特定のタイミングで動くシェルコマンドのフック）を使う、という位置づけです（公式ドキュメント）。つまり「憲法」のような絶対ルールではなく、効きやすい強めの推奨だと考えるのが正確です。
では役割固定はどこでやるか。答えは subagent 定義です。.claude/agents/ 配下に、名前・説明・使えるツール・モデルを frontmatter（ファイル先頭の設定欄）で書いたファイルを置くと、再利用できる専門家が1つ完成します。たとえば次のような最小形です。
name: security-reviewer
description: 認証・入力検証・セッション管理のセキュリティ観点でコードを批判的に監査する
tools: Read, Grep, Bash
model: sonnet
あなたはシニアのセキュリティレビュアーです。トークンの扱い、
セッション管理、入力検証を重点的に見て、指摘は重大度つきで報告してください。
しかもこの定義は、agent teams の teammate としても名前指定で呼び出せます。「security-reviewer の agent type で teammate を立てて auth モジュールを監査して」と頼めば、その定義の tools 許可リストとモデルを引き継いだメンバーになります（公式ドキュメント）。役割は1回 subagent 定義として書けば、subagent としてもチームメンバーとしても使い回せる、という設計です。
コピペで試せるプロンプト例（役割定義を Claude に作らせる）：
.claude/agents/ に置く subagent 定義を1つ作って。
役割は「実装コードのパフォーマンスとN+1クエリを指摘するレビュアー」。
frontmatter に name / description / tools / model を入れて、
本文はシニアエンジニアのペルソナで書いて。
5. 精度を上げる「Architect-Reviewer」を agent teams で組む
並列運用で効きが大きいのが、「作る人」と「疑う人」を別々に立てる構成です。これは概念論ではなく、公式ドキュメントが実例を出しています。
公式の「並列コードレビュー」の例では、1つの PR（プルリクエスト。変更をまとめてレビューに出す単位）に対して、セキュリティ担当・パフォーマンス担当・テストカバレッジ担当の3人の teammate を立て、それぞれ別の観点で見させて lead が結果を統合します。さらに「競合する仮説」の例では、5人の teammate にバグの別々の仮説を割り当て、互いの説を反証し合う科学的な議論をさせて、生き残った説を真因とみなす、という使い方が紹介されています（公式ドキュメント）。1人の調査だと最初の説に引っ張られがちなので、わざと対立させて精度を上げる発想です。
Architect（設計する人）に「コードを書く権限を与えない」運用も、公式機能で実現できます。teammate に plan approval（計画承認）を要求すると、teammate は読み取り専用の plan mode（計画モード）で設計だけを出し、lead が承認するまで実装に入りません。承認基準は lead のプロンプトに「テストカバレッジを含む計画だけ承認して」のように書けます。
コピペで試せるプロンプト例（対立構造を1発で組む）：
PR #142 をレビューする agent team を作って。teammate を3人立てて、
1人はセキュリティ、1人はパフォーマンス、1人はテストカバレッジ。
それぞれ独立にレビューして指摘を重大度つきで出させて、最後に統合して。
表示は2モードあります。in-process（全 teammate を同じターミナルで動かし、Shift+Down で巡回）と split panes（各 teammate を別ペインに分割。tmux か iTerm2 が必要）です。まずは追加設定の要らない in-process から始めるのが楽だと思います。
6. 記憶の共有は「SQLite」ではなく公式 auto memory（markdown）で
複数セッションを回すと、次に詰まるのが「セッションをまたいだ記憶の共有」です。ここで「SQLite にタグ付きで記憶を貯めて動的に注入する」といった高度なテクニックが紹介されることがありますが、それは Claude Code の標準機能ではありません。自分で MCP（Model Context Protocol。外部ツールを Claude に繋ぐ仕組み）経由で DB を組むなら可能、という話と、公式に用意されている記憶機構は分けて考えた方がいいです。
公式の auto memory（自動メモリ）は、markdown ファイルで動きます。~/.claude/projects/<project>/memory/ の中に MEMORY.md（索引）と、debugging.md のような話題別ファイルが置かれ、Claude が作業しながら自分で書き溜めます。読み込みのルールも明確で、毎セッションで読まれるのは MEMORY.md の先頭200行か25KB までで、話題別ファイルは必要なときだけ Claude が読みに行きます。Claude Code v2.1.59 以降で使え、保存はリポジトリ単位なので worktree 間で共有され、マシンローカルに置かれます（公式ドキュメント）。
この設計の良いところは、「索引だけ常時ロードして、詳細は必要時に取りに行く」ことで、コンテキストウィンドウ（AI が一度に読める文章量の上限）をクリーンに保てる点です。数千の細かいルールがあっても、索引が膨らみすぎなければ毎回汚染されません。
順番としては、SQLite を自作する前に、まず公式の markdown ベース auto memory を使い切る。DB 化を検討するのはその先です。
今日できる1アクション：セッション中に /memory を打つと、いま読み込まれている CLAUDE.md と auto memory のファイル一覧が見えます。まず自分の記憶がどこに何件あるかを覗いてみてください。
7. 並列運用で事故る3つの落とし穴（コスト・DB・権限）
仕組みが分かったところで、運用で踏みやすい3つの注意点を先に出しておきます。
ひとつめはトークンコストです。agent teams は teammate ごとに独立したコンテキストを持つので、トークン使用量は人数に比例して増えると公式が明記しています。ルーチン作業を5人がかりでやるとコスト負けします。だから公式も推奨人数を3〜5人とし、「3人の集中したメンバーは5人の散漫なメンバーに勝ることが多い」と書いています（公式ドキュメント）。
ふたつめは worktree の隔離範囲です。worktree はあくまで Git のファイル分離の仕組みなので、データベースや環境変数、起動中のサービスは共有されたままです。2つのセッションが同じローカル DB にマイグレーション（DB のスキーマ変更を適用する操作）をかけると壊れます。公式も「各 worktree で開発環境を初期化する（依存のインストールや仮想環境のセットアップ）のを忘れずに」と注意していて、タスクが DB に触るならスキーマや Docker（コンテナでアプリを動かす仕組み）コンテナ、.env を分ける必要があります（公式ドキュメント）。
みっつめは権限です。teammate は生成（spawn）された時点で lead の権限設定を引き継ぎます。lead を --dangerously-skip-permissions（権限確認を飛ばす危険なフラグ）で動かしていると、全 teammate も同じ無確認状態になります。並列だと事故の影響も並列に広がるので、権限は lead 側で絞っておくのが安全だと思います。
8. 中級者向け補足：人数・拡張・品質ゲートのよくある疑問
最後に、よく出る疑問を補足します。
Q. 結局、何セッションが現実的？ ひとつの目安が、さきほどの3層8セッションです。ポイントは、1つの agent team に8人を詰め込むのではなく、3〜5人のチームを軸にして、worktree セッションや subagent を足して合計8にすること。これは公式の推奨（agent team は3〜5人・teammate あたり5〜6タスク）とも噛み合います。最終的な上限は、自分が監視して舵を切れる範囲です。指揮できない数まで増やすと、逓減してむしろ遅くなります。
Q. subagent や agent team では足りない規模になったら？ 独立したセッションを多数並べて1か所から監視したい場合は、background agents（バックグラウンドで走る独立セッション群）という別の仕組みがあると公式ドキュメントの subagents ページが案内しています。subagent は同一セッション内の補助、agent teams は会話する並列チーム、その先に「多数の独立セッションを束ねて見る」レイヤーがある、という階層で捉えると拡張の方向が見えます。
Q. 品質を必ず担保したい場合は？ CLAUDE.md の推奨だけだと「効きやすい指示」止まりです。必ず実行したいチェックは hooks で強制します。agent teams には TeammateIdle（メンバーが手を止める前）・TaskCreated（タスク作成時）・TaskCompleted（完了時）のフックがあり、exit code 2 を返すとフィードバックを送って作業を続けさせられます（公式ドキュメント）。「テストが緑じゃないと完了させない」をコードで縛れる、ということです。
まとめ：監視する人から、設計して任せる人へ
Claude Code の値打ちは、コードを速く書かせること以上に、専門化した複数の Claude を1人で統制できることにあると思います。要点を並べておきます。
3つの仕組みを混同しない。subagent は結果を返す補助、agent teams は会話する並列チーム、worktree はファイルの隔離。8セッションは指揮・実装・品質の3層に分け、実装は worktree で隔離、品質は subagent 定義や agent team で固定する。役割境界は CLAUDE.md に書くのではなく subagent 定義で固定し、必ず守らせたいことは hooks で縛る。記憶の共有は SQLite を自作する前に、公式の markdown ベース auto memory を整える。1つのチームは3〜5人を目安に、層を足して8の働き手にするのが安全です。
今日から試す3ステップ
- [ ] claude --worktree test-1 を打って、隔離セッションが立ち上がる感覚を掴む
- [ ] .claude/agents/ に「reviewer」役の subagent 定義を1つ書いて、実装をレビューさせる
- [ ] CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 を設定し、PR レビューを3人の teammate で並列に回してみる
単一セッションで自分が修正指示を打ち続けていた時間が、役割を設計して任せる時間に変わっていきます。次に自分が何を手放して、何を見る側に回すか。そこを決めるのが、並列運用でいちばん人間に残る仕事だと思います。
参考リンク（公式一次ソース）
- Create custom subagents（Claude Code 公式ドキュメント）
- Orchestrate teams of Claude Code sessions（Claude Code 公式ドキュメント）
- Run parallel sessions with worktrees（Claude Code 公式ドキュメント）
- How Claude remembers your project／CLAUDE.md と auto memory（Claude Code 公式ドキュメント）
Xで発信できない有益な情報は、こちらのオプチャにて発信予定です。興味のある方は、ぜひ今のうちにご参加ください。
