目次

しばらくの間、私は AI が作業するのを眺めながら、内心ぼやいていました。そこそこ大きなタスクで、AI は一つのモジュールを書き終えてから次に取りかかる。私はその横で、片方が終わってもう片方の番が来るのをただ待っている。作業そのものに問題はない——ただ遅い。ずっと順番待ちしているから遅いのです。

そこであることに気づきました。多くのモジュールはそもそも互いに無関係なのに、なぜ一つずつ順番にやらせるのか。分割して、複数の agent に同時に作業させればいい、それだけの話です。

欲しいもの、そしてその境界

欲しいものはシンプルです。同じ作業を、ほぼ同じトークンで、完了までの時間を大幅に縮める。

ただ先に境界を言っておくと——すべてのタスクがこう分割できるわけではありません。これは私が自分なりに編み出したやり方で、参考程度に受け取ってください。

分割できる前提：アーキテクチャがまず綺麗であること

複数の agent が互いにぶつからずに同時作業するための前提は、AI ではなく、あなたのアーキテクチャにあります。

あのタスクを分割できたのは、それ自体がもともと複数のモジュールで、互いにインターフェース経由で通信し、内部実装は影響し合わない——インターフェース契約さえ守れば、各ブロックが独立して完成できる構造だったからです。つまり疎結合・高凝集。この設計は、手を動かす前に opus と一緒に固めておきました。opus が整理し、案を出す。決めるのは私です。

ここで手を抜いてはいけません。綺麗に分割していないアーキテクチャに無理やり並列をかけるのは、絡まった毛糸を何本かに切っても全部まだ繋がっているようなもので、かえって散らかるだけです。

役割分担：誰が統括し、誰が計画し、誰が手を動かすか

設計が決まったら、次は配置です。私が習慣にしている分担はこうです。

  • opus が統括——全体を見渡し、作業を割り振り、最後にチェックする；
  • sonnet が TDD の計画——設計に沿って、各モジュールをどうテストし、どう実装するかの筋道を先に敷く；
  • haiku がコードを書きテストを走らせる——力仕事はこれに任せる。安くて十分。

この分担は、実は前回の「モデル階層化」の続きです——良い鋼は刃に使う。前回は節約の話でしたが、今回はこれらの役割がどう連携して一緒に動くかの話です。

オーケストレーション：上に統括の opus、そこから独立したモジュールを sonnet（計画）と haiku（実装＋テスト）にばらまく。モジュール内ではさらに分担でき、終わった作業は opus に戻ってレビューされる

どうやってばらまくか

具体的には、三つやりました。

  1. グローバルの CLAUDE.md に一行書き込む：「並列にできるなら並列にせよ。」全プロジェクト共通のデフォルトルールです。
  2. Claude の設定で同時 subagent 数の上限を調整する——これが本当に効くバルブです。
  3. 指示を出すたびに一言添える：「できる限り並列で。」統括の opus は自分でも並列に割り振りますが、一声かけると意図がよりはっきり伝わります。

統括がモジュールを下に割り振り、モジュール内部ではさらにもう一段分担できる。層が重なって、タスク全体が広がっていきます。

レビューの工程は、省けない

並列で速く回す——では品質はどう担保するか。私のやり方は、統括自身にレビューさせることです。

理屈は単純で、作業を割り振ったのは統括なので、各 subagent が何を出すべきかを把握しています。チェックも統括にやらせるのが一番噛み合う。専用のレビュー agent を別に立ててみたこともありますが、タスクを一から理解し直す羽目になり、もう一周トークンを焼いて、しかも遅い。統括が自分でレビューすれば、その理解し直しのコストが消えて、速くて鋭い。

問題が見つかった後の小さなディテールもあります。統括はたいてい「これは私が直接直すか、別の agent を立てて直すか？」と聞いてくる。私はだいたい「直接直して」と答えます。たった今その不具合を見つけた当人なので、どこが問題か一番わかっているし、そこから直すのが一番ストレートだからです。

私が落ちた二つの落とし穴

一つ目はメモリ。 最初は欲張って同時並列を 10 に設定しました。しかし当時は別のプロジェクトも並列で走らせていて、マシンのメモリがきれいに食い尽くされた。そこで素直に 5 に下げたら、かえって快適でした——この一タスクだけで見れば、5 並列はおおよそ直列の 5 倍の効率。さらに同時に走る他のタスクを足すと、全体の高速化は 10 倍以上にもなる。マシンと枠に余裕があればこの数字はもっと上げられるし、なければ無理をしないことです。

二つ目は、分割のための分割をしないこと。 結合の強いモジュールは本来順番にやるべきで、無理に引き剥がして並列にすると、agent 同士が影響し合って品質がまるで担保できなくなる。なので AI に渡す前に一言添えます：「これらのモジュールは結合しているので、無理に分割しないで。」幸い、多くの AI は自分でこれを認識して、無理に分割しません。本当に分割できないものは、素直に一つの agent に直列でやらせるか、統括自身が一本の線で最後までやり切ればいい。

直感に反する勘定

「5 つの agent を同時に焼く」と聞くと、多くの人の第一反応は「トークンが何倍にもなるのでは？」です。

私が計算した限り、そうはなりません。同じ作業の山を直列でやっても、トークンの消費量はほぼ同じ——読むべきものは読むし、書くべきものは書く。並列が余計な作業を生むわけではない。並列が本当に変えるのはコストではなく、ウォールクロック（経過時間）です。順番待ちで流していた区間が、同じ時間枠の中でまとめて流れる。余計に焼くわずかなトークンと引き換えに、時間コストが大きく下がる——割のいい取引です。

直列 vs 並列：同じ作業で、トークン総量はほぼ同じ。だが並列は経過時間を約 1/5 に削る——節約できるのは時間であって、消費ではない

なので、本当に分割できないものを除けば、今の私は並列にできるものは基本すべて並列にしています。

振り返り：そのまま実践できる三箇条

一、アーキテクチャをまず綺麗に分割する、並列の話はその後。疎結合・高凝集・インターフェース契約による通信——この土台がなければ、分割は災いです。設計フェーズで AI と一緒に固めておく。

二、並列にできるものは全部並列に、ただし上限を設ける。数字は大きいほど良いわけではない。マシンのメモリと AI の枠を見て決める。私が 10 から 5 に戻したのは、メモリに痛い目を見せられたからです。

三、高速な並列には、レビューが必須。しかもレビューする側がタスクを本当に理解していること——作業を割り振った統括自身にチェックさせるのが、一番安くて鋭い。問題を見つけたら、そのまま直させる。

今日読んですぐできることを一つ：グローバルの CLAUDE.md を開いて「並列にできるなら並列にせよ」と一行足し、設定で同時 subagent 数の上限を、マシンが耐えられる値まで上げる。次に分割できる大きなタスクを渡したとき、AI が順番待ちをやめているのに気づくはずです。

次回は、これにすぐ続いて出てくる問題を取り上げたいと思います。複数の agent が同時にコードを編集するとき、何が彼らの衝突を防ぐのか？その裏にあるのが git worktree——各 agent に独立した作業領域を与え、それぞれが自分のコピーを触り、誰も互いの邪魔をしない仕組みです。興味があればコメントで教えてください。