Codexに「一気に仕上げて」と頼んだら、サブエージェントが10体くらい出てきて驚いた。調査、設計、実装、確認を同時に進めてくれるのは心強い。でも、数が増えたからといって、必ず作業時間が短くなるわけではない。
時間を短くする本当の方法は、サブエージェントを無制限に増やすことではない。最初に役割と完了条件を決め、待つ時間に上限を置き、最後に「誰の成果が良かったか」と「次回、自分は何を最初に伝えるべきか」を記録することだ。
この流れから、私はサブエージェントのレビューを繰り返すためのSkillを作った。作る途中では、Skillの検証ツールが環境不足で止まり、前方テストも返答待ちになった。そこで、人数より先にループの境界を決める必要が見えてきた。
10体出てきたとき、時間が増えた理由
サブエージェントをたくさん起動すると、仕事を分けた気分にはなる。ところが、担当が重複していたり、同じファイルを触ろうとしたり、完了条件が違ったりすると、最後に人間が結果を整理する時間が増える。
今回も最初は「最後に、どのサブエージェントが優秀だったかレビューさせれば、自分の依頼も改善できる」と考えた。これは良い方向だった。ただし、レビューを最後に足すだけでは足りない。起動前に何を比較するかを決めておかないと、返ってきた文章の長さや勢いで判断してしまう。
さらに、Skillは便利な作業指示ではあるけれど、ツールを機械的に止めるフックではない。Codexが自動的にサブエージェントを増やす場面まで管理したいなら、Skillだけでなく、プロジェクトの基本ルールにも「起動前に説明する」「終了時にレビューする」と書いておく必要がある。
最初は2〜4体にして、役割を分ける
いきなり10体を起動するのではなく、最初の一回は2〜4体で基準を作る。重要なのは、人数ではなく、担当の境界だ。
| 役割 | 担当すること | 返すもの |
|---|---|---|
| 調査 | 正本、既存実装、不明点を確認する | 確認できた事実と根拠 |
| 設計 | 優先順位、採用方針、完了条件を決める | P0と判断理由 |
| 実装 | 決められた範囲だけ変更する | 差分とテスト結果 |
| 検証 | 欠落、回帰、証拠不足を確認する | 未確認と残るリスク |
調査役に実装まで任せない。設計役にファイルを大量に変更させない。実装役を複数置くなら、書き込み対象を完全に分ける。同じファイルを2体が触ると、速くなるどころか、統合とやり直しが増えるからだ。
2〜4体で足りないと分かったときだけ、追加する。10体へ増やす場合も、「なぜ増やすのか」「どの重複を避けるのか」「何を返してもらうのか」を先に見せる。起動数が見えるだけで、作業の驚きはかなり小さくなる。
最初の依頼文に、時間を短くする条件を書く
「いい感じに進めて」では、サブエージェントごとにいい感じの意味が変わる。最初の依頼文に、次の項目を入れるだけで、後から聞き直す回数を減らせる。
このカードの形は、以前書いた「Lunaを賢く使う環境。Sol・Terra・Lunaを魔法戦士で考える」で整理した依頼文を、サブエージェントの起動前に使えるようにしたものだ。人格を長く説明するより、「誰が」「何をして」「どの状態をゴールにするか」を先に書く。
役割: Sol / Terra / Luna / verifier
起動数: まず2〜4体。追加するなら理由を書く
待機上限: 例）90秒。timeoutは成果なしとして記録
目的: 何をできる状態にするか
対象: ファイル、記事、URL、件数
参照元: 使う資料や正本
してよい: 変更してよい範囲
権限: 実行できる操作と、実行前に承認が必要な操作
しない: 変更しないもの、判断しないこと
完了条件: 終了とみなす具体的な状態
確認方法: 何を見ればPassか
不明・例外: 止めて質問する条件
取り消し: 失敗時に戻す方法
人間確認: 最後に人間が承認する箇所
出力: 結果、失敗、保留、証拠の形式特に大事なのは「役割」「完了条件」「変更しないこと」「人間確認」だ。Solには目的と優先順位を決めてもらう。Terraには正本と不明点を確認してもらう。Lunaには決まった範囲を動かしてもらう。verifierには証拠と未確認を返してもらう。
何をしないかを決めておけば、作業が広がりにくい。証拠を決めておけば、もっともらしい説明と、実際に確認できた結果を分けて読める。時間上限も先に書く。返答を待ち続けると、作業を任せたはずなのに、司令塔が待機係になってしまう。
最後のレビューを、次回の依頼文へ戻す
最後のレビューでは、モデルの順位を決めたいわけではない。今回の目的に、どの担当が一番合っていたかを確認する。
- 目的に答えたか
- 差分やテストなどの証拠があるか
- 禁止範囲へ広げていないか
- 不明点や公開境界で正しく止まったか
- 次の担当が使える形で返したか
今回のように、返答がない担当がいた場合は、「優秀な担当なし。タイムアウト」と書けばいい。無理に勝者を作らないことも、時間短縮につながる。成果のない待機を成功扱いにすると、次回も同じ待機を繰り返すからだ。
レビューの最後には、自分の反省を一文に変換する。「自分の指示が悪かった」と曖昧に反省するのではなく、「次回は最初に何を渡せばよいか」にする。
最優秀エージェント: 名前 / 役割
採用した成果: 何を使ったか
良かった理由: 目的と証拠
不要・重複だった担当: 何が重なったか
今回の未確認: 何がまだ分からないか
次回の依頼文へ追加する一文: 「対象X。Yは変更しない。証拠はA/B/C」この一文が、次の作業の初期設定になる。入力、実行、検証、記録、次の依頼へ戻す。この小さな循環ができると、毎回ゼロから「どう頼もう」と考えなくてよくなる。
時間短縮は、人数ではなく迷いを減らすこと
サブエージェントは多いほど強い、というより、仕事の境界が見えているときに強い。調査、設計、実装、検証を分け、最初に返答の形をそろえ、最後に結果を比較する。これだけで、待ち時間とやり直しの一部を減らせる。
次にCodexへ大きな作業を頼むときは、いきなり「全部やって」と送らず、まず「起動数、役割、完了条件、証拠、wait上限」を書いてみる。10体出てきても驚かないための準備は、10体を出させることではなく、何体が何をするかを自分で決めることだ。
AIに作業を任せるほど、人間の仕事はなくなるのではなく、目的と境界を決め、結果から次の一手を選ぶことへ変わっていく。最後のレビューは、そのための短い記録になる。
