Claude Code のサブエージェント並列で本番サイト群を保守する — 司令塔パターンの運用設計

2026/7/19Web開発者向け

AI コーディングエージェント（Claude Code）を、1 人のアシスタントとしてではなく、司令塔と並列の実働班からなる小さなチームとして編成し、本番稼働している複数サイトの保守を日々回しています。本記事は「試してみた」報告ではなく、既に回している運用の設計原則と、なぜそうしているのかの機構を淡々とまとめたものです。

扱うのは 8 サイトのモノレポ（Astro / EmDash ベースの CMS 群、Cloudflare Workers 上で本番稼働）です。監視基盤の構築、404 の正規化、sitemap のエラー修正、クエリ最適化、画像の欠損復旧といった、地味だが本数の多い保守作業を、人間の操作を数回に抑えたまま出荷しています。

前提: Claude Code のサブエージェント（Agent / Task ツール）、git worktree、バックグラウンド実行、CI 連携を組み合わせた運用です。特定の魔法のツールがあるわけではなく、既存の機能を「編成」で使い切る話として読んでください。

編成: 人間・司令塔・実働班の三層

役割を三層に分けています。

人間（意思決定）: 何をやるかの承認、UI・コンテンツの最終判断、本番認証の承認、そして「これは人間が決めるべき」とエスカレーションされた案件の判断。
司令塔エージェント（メインセッション）: タスクの分解、各実働班への指示書作成、完了報告のレビュー、PR 作成・CI 監視・マージ、そして人間へのエスカレーション。手を動かして実装するより、段取りと検収に徹する。
サブエージェント 4〜5 並列（実働班）: 調査・実装・計測。それぞれが独立したコンテキストで動き、司令塔には結論だけを返す。

この三層は、Claude Code のサブエージェントが「独立したコンテキストウィンドウで作業し、結果の要約だけを親に返す」という性質にそのまま乗っています。探索やビルドログで親セッションのコンテキストを溢れさせず、司令塔は全体の見通しを保ったまま複数の班を並べられます。

実績の目安として、ある 1 日ではこのモノレポで、監視基盤の構築・404 の正規化（8 サイト 33 ルート）・sitemap の 500 エラー修正・3 サイトのクエリ最適化・画像 404 の 36 件復旧などを、12 本の PR として出荷しました。この日、人間が手を動かしたのはレビュー判断と認証承認など数回だけです。以下、この編成を支えている設計原則を、理由込みで並べます。

原則 1: git worktree で実装班を物理分離する

並列で実装させると、複数のエージェントが同じファイルを同時に書き換えて壊し合う事故が必ず起きます。これを規律（「気をつけて書く」）で防ぐのは無理です。物理的に分離します。

実装を担う班ごとに git worktree を割り当てます。worktree はそれぞれ独立したブランチ上の別チェックアウトなので、班 A の編集と班 B の編集はディスク上で衝突しません。司令塔は各 worktree の成果を PR として個別に受け取り、順にマージしていきます。

# 班ごとに独立したチェックアウト（別ブランチ）を与える
claude --worktree fix-404-normalization
claude --worktree optimize-ssr-queries

それでも同一ファイルを触らざるを得ない班が出ることはあります。その場合は worktree で分けたうえで、指示書に「担当する行・関数の範囲」を明示し、責任範囲を重ねない。分離できる衝突は物理で、分離しきれない衝突は指示で潰す、という二段構えです。

原則 2: 指示書に計測プロトコルを埋め込む

サブエージェントへの指示書には、やることだけでなく「良し悪しをどう測るか」を書き切ります。特にパフォーマンス系の修正では、以下を必須プロトコルとして埋め込みます。

ウォームアップ後の A/B 計測を必須にする: 初回リクエストのばらつきを排除し、修正前後を同条件で比べる。
表示が変わっていないことを HTML のバイト一致で証明する: 「速くなったが表示が壊れた」を出荷しないため、レンダリング結果の同一性を機械的に確認する。
悪化したら出荷しない: これを指示書の絶対条件として明記する。

このガードレールは実際に機能しています。あるとき、指示した本命の修正について、実装班が計測の結果「クエリ数が 19 から 22 に増えた（悪化した）」と報告し、自ら出荷を拒否してきました。指示された作業を盲目的に完遂するのではなく、「悪化したら出荷しない」という条件に照らして正しく止まった例です。計測プロトコルを指示書に焼き込んでおくと、エージェントは「言われたからやる」ではなく「条件を満たすからやる」に寄ります。

計測プロトコルそのものの詳細（リクエスト内キャッシュの重複排除など）は姉妹記事「SSR のクエリ最適化とリクエスト内キャッシュの重複排除」にまとめています。

エージェントを自走させる土台は、指示書ではなくその外側のハーネス（lint・typecheck・CI・Hooks といった決定的な検証パイプライン）の側にあります。設計は姉妹記事「エージェントを自走させるハーネス設計」にまとめています。

原則 3: 知見は司令塔が運搬する

サブエージェントはセッションをまたいで記憶を持ちません。先行した班が踏んだ罠は、そのセッションが終われば消えます。後続の班は同じ罠をゼロから踏み直します。

そこで、先行班が発見した事実（例: 「このクエリはリクエスト内でキャッシュされるので、素朴に数えると重複排除で見かけ上減る」といった落とし穴）を、司令塔が事実シートとして後続班の指示書に焼き込みます。エージェントが記憶の運搬役を担えない以上、司令塔が知識の運び手になる、という役割分担です。

これは人間のチームで言えば「引き継ぎメモ」に相当しますが、相手が毎回まっさらな新人である前提で書く点が違います。暗黙の前提を残さず、踏んだ罠を明示的に文章化して次に渡す。並列数を増やすほど、この運搬の質が全体の速度を決めます。

原則 4: 権限は非対称にする

サブエージェントには、本番への書き込み禁止・共通パッケージの改変禁止といった制約を最初から課します。実働班ができるのは調査・実装（自分の worktree 内）・計測までで、そこから逸脱が必要になったら司令塔を経由して人間に上げる、という一方通行です。

この非対称が効いた実例があります。ある実働班が、認証まわりの詰まりに対して「本番 DB を直接 UPDATE すれば認証を迂回できる」と技術的には正しい提案をしてきました。提案自体は妥当でしたが、認証に関わる操作は権限の外です。司令塔はこれを実行させず人間の判断に上げ、結果的に正規の経路を選びました。

能力があることと、その操作を許すことは別です。エージェントが賢いほど「正しいが越権な近道」を見つけてくるので、越権の入口を最初から塞ぎ、判断を人間に集約する設計にしておきます。

原則 5: 検証は司令塔が二重に行う

サブエージェントの完了報告をそのまま信じません。本番に反映されたはずの変更は、司令塔が独立に curl 等でスポットチェックします。

実例として、「site_url の修正が効いた」という完了報告を受けたものの、実際には反映されておらず、人間が本番を確認して乖離に気づいたケースがありました。報告（エージェントが「やった」と言っている状態）と実体（本番が実際にどうなっているか）は乖離しうる、というのを前提に設計します。

ドメイン切り替え直後のように、手元の環境からは本番の実体が正しく見えない状況もあります。この種の検証で手元の DNS が古い IP を返して確認にならない問題と対処は「DNS が古い環境からドメイン切り替え直後のサイトを検証する」にまとめました。いずれにせよ、「報告」ではなく「本番のレスポンス」を真実とするのが検収の原則です。

原則 6: 人間の介入点を明確にする

人間を「全部の承認者」にすると、並列化の意味が消えます。逆に人間を外すと、取り返しのつかない操作まで自動で走ります。だからどこで人間が要るかを明示的に切り分けます。

人間が介入する点:

マージ判断（ただし CI が緑なら自動化してよい領域）
本番認証（デバイスコード承認、マジックリンクなど、人間の手が物理的に要る操作）
UI・コンテンツの最終判断（見た目や文面の良し悪しは人間が決める）

それ以外では人間を待たせません。調査・実装・計測・PR 作成・CI 監視は司令塔と実働班で回し、人間は上の 3 種類の判断に集中します。介入点を減らすのではなく、介入点を明確にするのが目的です。

チーム機能との使い分け

Claude Code には、サブエージェントとは別に Agent Teams（チーム機能）もあります。対等なエージェント同士が P2P で連携する編成です。この運用でサブエージェントを選ぶのは、タスクが明確に切り出せているからです。境界のはっきりした調査・実装・計測は、司令塔に結果を集約する形が安く確実に回ります。相互通信や議論が必要になって初めてチームを検討します。詳細は姉妹記事「Agent Teams とサブエージェントの使い分け」にまとめています。

モデル選定の自由度は、タスクを切り出せていることに直結します。実運用では司令塔に最上位モデル、各実働班には難度に応じたモデルを指定しています（Claude Code の Agent 呼び出しはモデルを指定できます）。境界が明確なほど選べるモデルの幅は広がります。

機構のまとめ

この運用を支えている Claude Code 側の機構は、いずれも特別なものではありません。

サブエージェント（Agent / Task ツール）: 独立コンテキストで作業させ、要約だけを親に返す。並列の実働班の実体。
git worktree: 班ごとに別チェックアウトを与え、並列編集の物理衝突を防ぐ。
バックグラウンド実行と通知: 長めのタスクを走らせつつ、完了を通知で受け取り、司令塔が検収に回る。
CI 監視: PR ごとに CI を回し、緑を確認してからマージする。マージ判断を機械的な基準に落とす。

編成の妙は道具ではなく、役割分担・指示書・検証の設計の側にあります。

限界: この方式で油断してはいけないところ

淡々と回っている一方で、はっきりした限界もあります。ここを見誤ると事故ります。

停止したサブエージェントは「監視している」と自称しても実際は寝ている。「CI を見張り続けます」と報告したエージェントが、実際にはポーリングを続けておらず止まっている、ということが起きます。ポーリングの生存は保証されません。継続監視は、生きているプロセスか外部のスケジューラに任せ、エージェントの自己申告を当てにしない。
報告の過信は禁物（原則 5 の再掲）。「やった」と「本番がそうなっている」は別物として扱う。
長時間タスクには引き継ぎ設計が要る。エージェントはセッションをまたいで記憶を持たない（原則 3）ので、中断・再開をまたぐ作業は、状態を外部（指示書・チェックリスト・PR の説明）に書き出しておかないと続きが繋がりません。

この編成は、AI エージェントが賢くなったから成立しているのではなく、賢いエージェントの弱点（記憶がない・報告と実体が乖離する・止まったら寝る）を前提に、司令塔と人間で穴を塞いでいるから成立しています。AI エージェントと開発環境の相性については、別記事「astro dev がエラーも出さず死ぬ — Astro 7 の AI エージェント検出」も、エージェント運用のクセを知る材料になります。

まとめ

AI コーディングエージェントは「1 人のアシスタント」より「司令塔 + 並列の実働班」に編成したほうが、本番の保守を数多くさばける。人間は意思決定に集中する。
並列実装は git worktree で物理分離する。分離しきれない衝突は指示書で担当範囲を明示して潰す。
指示書に計測プロトコル（ウォーム A/B・HTML バイト一致・悪化したら出荷しない）を埋め込む。実際に実働班が計測悪化を理由に自ら出荷を止めた。
エージェントはセッション間で記憶を持たないので、知見は司令塔が事実シートとして運搬する。
サブエージェントの権限は非対称にし、越権が必要なら人間に上げる。「正しいが越権な近道」を実行させない。
完了報告は信じず、本番のレスポンスを司令塔が独立に検証する。報告と実体は乖離する前提で設計する。
人間の介入点（マージ判断・本番認証・UI/コンテンツ）を明確にし、それ以外では人間を待たせない。
限界: 停止したサブエージェントの「監視中」は寝ている。報告を過信しない。長時間タスクは状態を外部に書き出して引き継ぐ。