独立したタスクは、まとめてサブエージェントに投げる ― Claude Code を使い倒す①（検証は人が持つ）

開発現場で Claude Code をどう「使い倒す」か、実運用でやっていることをシリーズで書きます。初回はサブエージェントによる並列化です。結論から言うと、効くのは「独立したタスクをまとめて投げる」ときで、速くなるのは下書きまで。検証（QA）は人が集約して持つ——これが肝でした。

題材は、この技術ブログ自体です。自社のAI活用事例を紹介する記事を9本用意する必要がありました。1本ずつ順番に書くと直列で時間がかかります。しかし記事どうしに依存関係はありません。D-1の記事を書くのにH-1の記事は要らない。こういう「独立していて、出力を最後に集約できる」作業が、サブエージェント並列化のいちばんの当たり所です。

やったこと ― 8本を並列で下書きさせる
どれくらい速いのか（正直な数字）
肝は「検証を人が集約する」こと
つまずきやすいところ
並列にすべきか、直列にすべきか
まとめ

やったこと ― 8本を並列で下書きさせる

まず1本（G-1）を自分で書いて型（文体・章立て・図・サムネの作法）を固定し、それを見本として渡したうえで、残り8本を8つのサブエージェントに1本ずつ割り当てました。各エージェントに渡したのは、次の4点です。

一次ソースの絶対パス。事例ごとの「数値の出所」「掲載パッケージ（禁止事項つき）」「技術詳細の下書き」を、エージェント自身に読ませる。要約を渡して丸投げしない。
文体の見本。先に自分で書いた1本のファイルパス。完成度の基準をコードではなく実物で示す。
厳守事項。数値には必ず母数と条件を添える、事例ごとの「書いてはいけないこと」（防御と書かない・工数削減%を書かない等）を明記。
出力の受け取り方。書き出し先のファイルパスと、最終メッセージで返す項目（タイトル・サムネ見出し2行・タグ・使用画像・自己チェック結果）を構造化して指定。

あとは8本をバックグラウンドで一斉に起動し、完了通知を待つだけです。ここで大事なのは、手が空いたからといって進捗をポーリングしないこと。ハーネスが完了を通知してくれるので、待っている間は別の作業（画像の準備やスケジュール設計）を進めておきます。

どれくらい速いのか（正直な数字）

8本の下書き生成にかかった時間は、1本あたりおよそ2〜7分でした（最長の1本で約7.2分）。並列で流したので、全体の待ち時間はいちばん遅い1本とほぼ同じ＝約7分。仮に直列で1本ずつ書いていたら、単純合計で約27分かかっていた計算です（8本の実測時間の合計）。

ただし、これは「下書きが上がるまで」の時間です。ここから先――数値のチェック、サムネ画像の生成、投稿の作成と公開予約――は人の作業で、こちらのほうが時間がかかりました。「並列化で速くなった」のは執筆の初速であって、公開までの総時間ではありません。ここを混同すると見積もりを外します。

肝は「検証を人が集約する」こと

並列で8本の下書きが同時に上がってくると、品質のばらつきや指示違反が混ざるリスクも同時に増えます。ここで「各エージェントが自己申告でOKと言っている」を信じてはいけません。検証は親（呼び出し側）が一手に引き受けます。しかも、なるべく機械でチェックできる形に落として。

今回、実際に回した集約チェックはこんな内容です。

禁止表現の文脈確認。事例ごとの「書いてはいけない言葉」を grep で拾い、ヒットした箇所が否定文（「〜とは書けません」）の中だけかを1件ずつ目視。
必須の数値の有無。「この事例なら母数◯件が必ず添えてあるはず」という数値を grep で存在確認。
構造の整合。Gutenberg ブロックの開き／閉じの数が合っているか、空の <p></p> が生まれていないか。
画像の実在。本文が参照する画像URLが実際に 200 を返すか（サーバ側でファイル存在も確認）。

結果として、数値の母数はすべて条件つきで書かれており、禁止表現も否定文の中だけに収まっていました。とはいえノーチェックで通したわけではありません。用語のゆれ（「ベクタDB」と書かれていた箇所を「ベクトルDB」に統一するなど）は人が直しています。この検算の工程を省くと、並列化は「速く間違える」だけの仕組みになります。

正直に書いておくと、この記事群の下書き自体がこの方法で作られています。ただし公開しているのは、数値・母数・「書いてはいけないこと」を人が全数チェックしたあとです。速いのは下書きまで、確定は人が持つ――私たちがAIを使うときの基本の型は、開発でも記事でも同じです。

つまずきやすいところ

丸投げしない。要約だけを渡すと、根拠のない数字や存在しない仕様を書きがちです。一次ソースのパスを渡して自分で読ませると、精度が上がります。
成果は「最終メッセージ」しか返らない。サブエージェントの作業ログは呼び出し側に残りません。だからファイルに書き出させ、最終メッセージには受け取りたい項目だけを構造化して返させる設計にします。
作業ファイルは衝突させない。共有の作業ディレクトリに、エージェントごとに別ファイル名で書かせます。同じファイルを複数エージェントに触らせない。
自己申告を検品の代わりにしない。「制約は守りました」という報告は出発点で、確認は呼び出し側で機械的にやり直します。

並列にすべきか、直列にすべきか

向いている（並列）	向いていない（直列でやる）
タスクどうしが独立している	前の結果を次が使う（依存がある）
読み取り中心・出力を最後に集約できる	同じファイル／状態を書き換え合う
各タスクの成否を機械で検証できる	手順に順序がある（マイグレーション等）

「独立・読み取り中心・検証可能」の3つが揃うと、並列化の効果が素直に出ます。

コードの現場でも同じ当たり所があります。たとえば複数ファイルにまたがる横断調査（「この関数の使用箇所を全部洗う」）、観点ごとのレビュー（バグ・性能・テスト網羅を別々のエージェントに）、独立したモジュールのテスト追加など。逆に、マイグレーションのように順序が決まっている作業や、同じ設定ファイルを何人もで書き換える作業は、並列にすると壊れます。