Claude Codeには、メインの会話とは別に子エージェントを走らせる機能があります。名前は知っていても、いつ使えば得なのか、指示をどう書けばいいのかが分からず、結局メインの会話だけで作業している人は多いはずです。編集部も最初はそうでした。この記事では、当サイト構築という実際の仕事で使った記録に基づいて、設計から失敗までを順に書きます。
サブエージェントとは何か
サブエージェントとは、メインの会話から独立したコンテキストで動く子エージェントです。親であるメインの会話は指示を出すだけで、作業の中身には立ち入りません。子は渡された指示だけを頼りに作業し、終わったら結果の要約だけを親に返します。
重要なのは「独立したコンテキスト」という部分です。子はメインの会話の履歴を知りません。親がそれまで何を話し、どんなファイルを読んできたかは、指示文に書かれていない限り子には伝わりません。この性質は制約であると同時に、次に述べる利点の源でもあります。
人間の組織にたとえるなら、外注先に仕事を出す関係に近い構図です。外注先は発注書に書かれたことしか知らず、納品物だけを返してきます。社内の雑談を聞いていない代わりに、発注書さえ正確なら安定した成果が返ってくる。サブエージェントの扱い方は、この発注書をどれだけ正確に書けるかにかかっています。
何が嬉しいか
利点は3つあります。
1つ目は、並列で走らせると待ち時間が消えることです。メインの会話は一度に1つの作業しか進みませんが、サブエージェントは複数を同時に発注できます。10本の記事を順番に書かせれば10本分の時間がかかりますが、10班に同時に書かせれば、体感の待ち時間は最も遅い1本分に縮みます。
2つ目は、親のコンテキストを消費しないことです。子が作業中に読み込んだ大量のファイルや試行錯誤は、子のコンテキストの中で完結します。親に返るのは結果の要約だけなので、メインの会話は長時間の作業を経ても簡潔なまま保たれます。コンテキストが膨らんだ会話は応答の質が落ちやすいので、これは速度以上に品質の問題です。
3つ目は、作業が分離されるので事故が減ることです。各班は自分の担当範囲しか知らず、担当外のファイルに手を出す動機がありません。範囲を区切った発注は、そのまま安全柵として機能します。
実録: 24ページを8班で作った時の設計
当サイトのローンチ時、用語辞典17語、ガイド4章、ニュース1本、Skill紹介2本の合計24ページを一度に作る必要がありました。編集部はこれを8班のサブエージェントに分けて並列で発注しました。結果は当サイト構築の実測記録に書いたとおり、発注から全稿完了まで約25分。書式不備による書き直しはゼロで、品質検査で見つかった修正はドメイン表記1箇所とHTMLタグ不整合1箇所の2件だけでした。
設計の要点は3つです。
第一に、班ごとに担当ページ群を割り当てました。用語辞典を数語ずつ、ガイドを章単位でというように、互いに依存しない単位で切り分けています。班同士が同じファイルを触らないので、衝突は構造的に起きません。
第二に、指示文にテンプレートファイルのパスと文体規範を必ず含めました。前述のとおり子は親の会話を知らないため、「いつもの形式で」は通じません。見本となるPHPファイルのパス、守るべき文体の規則、リンクの張り方までを、8班すべてに同じ形で書いて渡しました。全稿が同じ品質基準に揃い、手戻りがゼロだったのはこの事前固定のおかげです。
第三に、親は執筆に加わらず、編集長としてQAに回りました。親が自分でも1本書き始めると、発注の管理と検査が止まります。役割を「発注して検査する側」に固定したことで、8班の進行を待つ間も親のコンテキストは検査基準の保持だけに使えました。全稿が返ってきたあと、禁則文字、テンプレート準拠、リンクの検査を親の側で実施しています。この機械検査と索引統合まで含めても、全体は約1時間で完了しました。
つまずいた点と対策
順調な数字だけを書くとフェアではないので、編集部が実際につまずいた点を2つ書きます。
1つ目は、指示の情報不足です。初期に発注した班のひとつが、見当違いの構成で原稿を返してきたことがあります。原因は単純で、親の会話では何度も確認済みだった前提を、指示文に書き忘れていました。子は親の会話を一切知りません。「さっき話した方針で」は存在しない記憶への参照です。対策は、指示文だけを読んで作業が完結するかを発注前に自問することです。テンプレートのパス、規範、完成条件を毎回すべて書く。冗長に感じても、これが最短経路でした。
2つ目は、品質のばらつきです。同じ指示を渡しても、班によって仕上がりの精度には差が出ます。実際、25分で揃った24ページにも、検査で2件の修正が見つかりました。件数としては少ないものの、検査をしなければそのまま公開されていた不備です。対策は、受け入れ検査を工程として必ず入れることです。編集部は「サブエージェントの成果物は検査済みになるまで完成と呼ばない」を運用ルールにしています。書かせっぱなしで公開する運用は、いつか必ず事故になります。
向く仕事と向かない仕事
実測を通じて、向き不向きははっきり見えました。
向くのは3種類です。まず調査。コードベースや資料を大量に読む作業は、読んだ内容が親に残らない利点がそのまま効きます。次に量産。今回の記事24ページのように、独立した単位に分解できる作業は並列化の効果が最大になります。最後に独立したレビュー。書いた本人とは別のコンテキストで検査させることで、思い込みを引き継がない評価ができます。複数の子を協調させる構成の一般論はマルチエージェントの項も参照してください。
向かないのは、文脈の積み重ねが必要な対話的作業です。方針を相談しながら少しずつ形にしていく仕事は、履歴を持たない子には任せられません。発注のたびに全文脈を書き直すコストで、利点が消えます。もうひとつは、1つの小さな修正です。1行直すだけの作業に子を立ち上げるのは、指示文を書く手間の方が高くつきます。メインの会話で直す方が速い。
判断に迷ったら、「この仕事の発注書を、いま一度に書き切れるか」を基準にしてください。書き切れるなら任せられます。書いている途中で「これは相談しながらでないと決められない」と感じたら、その仕事はメインの会話で進めるべき仕事です。
まとめ
サブエージェントは、独立した単位に切れる仕事を並列で片付けるための道具です。使い方の核心は2つに要約できます。子は親の会話を知らないので、指示文に全情報を書くこと。品質はばらつくので、受け入れ検査を工程に組み込むこと。
いきなり8班を走らせる必要はありません。まず1班に、指示文だけで完結する小さな仕事を発注してみてください。返ってきた成果物を自分の目で検査する。この往復を体験すれば、どこまで任せられるかの感覚がつかめます。サブエージェントは発注だけでは戦力になりません。QAとセットで初めて戦力になります。