はじめに

Claude Code の Subagent + isolation: worktree で並列開発するの、最高ですよね。
たくさん subagent をぶん回すスタイルが定着してきましたが、運用を続けるうちに、人間がやらなくていい仕事 がいくつか見えてきました。

僕の運用では、人間 ←→ subagent の間に 中間管理職 Claude を 1 体常駐させ、auto mode で動かしています。この中間管理職くんが何をやってくれてるかというと、主に2つ:

大きな Issue を僕と一緒に読んで、subagent でこなせる粒度までバラす
subagent をいつ何体立てるか決める (admission control)
この記事では、この2つを具体的にどう自動化してるかを書きます。

前提: 粒度のピラミッド

抽象度のピラミッドを描いておきます。テッペンが「抽象」、底が「具体」:

              A              ← 抽象 (1個の親 Issue)
           ↙  ↓  ↘
        A-A  A-B  A-C        ← やや具体 (サブ Issue)
       ↙↓↘  ↙↓↘  ↙↓↘
     A-A-A  A-A-B  ...       ← 超具体

底に行くほど分割数 (並列数) を増やせて、subagent でも仕事が簡単になります。
経験的には 5-10 分工数のチャンクまで降ろすと失敗率が下がる。10 分を超えるとコンテキスト劣化で質が落ちやすく、戦死率も跳ね上がります。

このピラミッドを前提に、人間とエージェントの役割分担はこうなっていてほしい:

人間がやる:

ピラミッドのテッペン (親 Issue) を考えて投げる
各層で出てきた Issue にコメントして方向修正
PR を review して merge
人間がやらなくていい:
Issue を「ちょうどいい粒度」までバラす作業
どの subagent をいつ立てるかの判断
下の2つを中間管理職くんに投げます。

仕事1: Issue 分析・分解 ──「もう一段具体化」もsubagentにやらせる

データベースの世界で、並列実行できる単位を切り出すことを task partitioning と呼びます。partition の独立性が高いほど並列度を上げられる、というのが原則。Claude Code でも同じで、Issue がうまく partition されているほど subagent が並列で動けます。

そして partitioning という労働自体も subagent にやらせられます。

フロー

人間は大きな親 Issue を 1 個書く
中間管理職くんに「これを分析して分解して」と指示
中間管理職くんが Issue 分解 subagent を立てて、分析と分割をやらせる
出てきたサブ Issue を人間が眺めて、コメントだけ入れる
サブ Issue のうち抽象度がまだ高いものは、さらに subagent に投げて再分解
5-10 分工数まで降りたら、実装 subagent を立てる
つまり、Issue を読んで分析・分解する作業そのものを subagent の仕事にする。
人間は方向性のコメントだけ書いていれば、ピラミッドが勝手に育ちます。

Issue 分解 subagent への指示

あなたは Issue 分解 subagent です。
親 Issue を読んで、以下を行ってください:
 
1. タスクの抽象度を評価 (L0=最抽象 〜 L3=最具体)
2. L2 以下なら、それ以上分解せず実装フェーズに渡す
3. L0-L1 なら、独立に並列実行できる単位に分割
4. 分割した各 Issue は:
   - 「何を、どこのファイルに対して、どう変えるか」が明確
   - 5-10 分で完了できそうな粒度
   - 他の Issue とファイル所有権が被らない
5. 親 Issue にコメントとして提案を投稿し、人間の承認を待つ

ポイントは 「ファイル所有権が被らないこと」 を明示すること。
TP の partitioning と同じ発想で、partition 間の独立性 (= ファイル衝突のなさ) が高いほど安心して並列度を上げられます。

抽象度ラベル

Issue ラベルで抽象度を明示しておくと、中間管理職くんが「この層なら N 並列まで OK」と判断しやすくなります:

- abstraction:L0 (最抽象)  → 並列度 1
- abstraction:L1           → 並列度 ~3
- abstraction:L2           → 並列度 ~6
- abstraction:L3 (最具体)  → 並列度 ~10

ここまで来ると、人間がやってるのは「親 Issue を書く」と「途中のサブ Issue にコメントする」だけ。
Issue 分解という労働自体が並列化される ので、構想と実装のあいだの時間がガクッと縮みます。

仕事2: Admission Control ── spawn しすぎ問題

並列度は高い方が嬉しい、と最初は思いました。
でも実際に運用すると、無制限に subagent を立てると全体が崩壊します:

開発サーバーの CPU / メモリが詰まる
API レートリミットに刺さる
中間管理職くんが状態を管理しきれなくなる
戦死率が上がる (リソース不足由来の二次戦死)
これはデータベースの世界では admission control と呼ばれる古典問題で、新規トランザクションを受け入れるかどうかをシステム負荷で決めます。Claude Code でもこれがそのまま持ち込めます。

中間管理職くんへの指示

## Admission Control
 
subagent を立てる前に、必ず以下を確認:
 
1. `uptime` で load average を確認
2. CPU コア数の 80% を超えていたら、新規 spawn を控える
3. 走行中 subagent 数を確認
4. 上限 (デフォルト N=8) を超えていたら、既存タスクの完了を待つ
5. Issue ラベルの abstraction レベルに応じた並列度上限を守る
 
緊急タスクが来た場合のみ、ユーザーに「並列度を上げますか?」と確認。
勝手に上げないこと。

これで中間管理職くんが 自律的にスロットリング してくれます。
ロードが下がってくると spawn を再開する。queue depth に応じた flow control がそのまま動いてる感じ。

ポイントは「ユーザーに聞かないと勝手に上げない」ガード。
auto mode で運用しているので、暴走防止として重要です。

2つは繋がっている

ここまで読むと「Issue 分解」と「admission control」は独立した話に見えますが、実はそうではないです。

Issue が粗いまま (L0/L1) だと、1 subagent が長時間 CPU/トークンを占有する
Issue が細かい (L3) と、短時間で完了して次の subagent に明け渡せる
つまり、

Issue 分解が雑だと admission control が破綻する。
Admission control が効くと、粒度が雑な仕事は自然に止まる。

partitioning と admission control はセットで効く

まとめ

人間が並列 Claude Code 開発でやることは、親 Issue を書く と PR を merge する の2つだけにできます。
間にある「分解」と「並列度判断」は、中間管理職くんに丸ごと投げられます。

仕事	データベース屋の語彙	投げる先
Issue 分析・分解	Task Partitioning	Issue 分解 subagent
並列度の判断	Admission Control	中間管理職 Claude

「TP 屋の語彙で Claude Code を再設計する」というレンズで他にも持ち込めるものは色々あって、たとえば WAL での戦死リカバリとか。サブエージェントにログを書かせるとリトライ時に幸せになれます。などなど...