メインコンテンツまでスキップ

マルチサブエージェントのワークフローを設計する

上級
What you'll learn
  • 各段階が独自のコンテキストと独自のツールセットを持つ、調査→実装→レビューのパイプラインを組む
  • メインエージェントが指示されなくても適切なサブエージェントに委任できるよう、十分に絞った description を書く
  • 形だけの承認で終わらず、差し戻すレビューゲートを加える
  • マルチエージェントの調整が得より損になる 3 つのケースを見分ける
  • 完了した実行を、分割が本当にうまくいったかを示す 4 つのシグナルで確認する

大きなタスクは、すべてを 1 つのコンテキストに詰め込むより、目的を絞ったサブエージェントに分けたほうがうまくいきます。調査→実装→レビューのパイプラインを設計してみましょう。

全体像​

各サブエージェントは独自のコンテキストと用途に合わせたツールセットを持ち、メインセッションに戻るのは結果だけなので、メインセッションはきれいに保たれます。

ステップ 1 — エージェントを定義する​

/agents インターフェースで 3 つを定義します。それぞれに絞り込んだ description(メインエージェントが正しく委任できるように)と、範囲を限定したツールを持たせます:

Guided walkthrough1 of 3
  1. 関連するコードをマップ化し、調査結果を返します。書き込みツールは一切なく、だからこそ広く読ませても安全です。重い探索はここで行われるため、メインのコンテキストには入りません。

description フィールドはドキュメントではありません — メインエージェントが委任するかどうかを判断するときに読む、ルーティングキーです。曖昧な description は、定義したサブエージェントが一向に使われない最も一般的な理由です。

A reviewer description that actually gets delegated to

Use this agent to review a completed code change adversarially before it ships.
Invoke it after the implementer reports done, and before telling the user the
task is finished. It reads the diff and the surrounding code and reports
problems; it does not fix them.

ステップ 2 — 引き継ぎでオーケストレーションする​

メインセッションは各段階の出力を次の段階に渡します: 調査→実装(調査結果を使う)→レビュー(実装を対象に)。レビューゲートを加えます: レビュアーが問題を見つけたら、完了する前に implementer に差し戻します。

The handoff instruction that creates the gate

Run this as three stages, and do not skip the gate:

1. Delegate the exploration to the researcher. Wait for its findings.
2. Give those findings to the implementer as its starting context.
 Do not ask it to re-explore.
3. Give the implementer's result to the reviewer. If the reviewer reports
 any issue, hand the issues back to the implementer and review again.
 Only report the task complete after a review that found nothing.

ステップ 3 — やってはいけないときを知る​

並列/マルチエージェントはタダではない
  • 逐次的な依存(実装には調査が必要)は逐次のままにします — 順序が重要なところで枝分かれさせないでください。
  • 共有ファイルへの書き込みは衝突しえます — git worktreeで隔離するか、直列化します。
  • 小さなタスクでは、調整のオーバーヘッドが利益を上回ります。規模が大きく、分解できる作業に使ってください。

ステップ 4 — 検証する​

よいマルチエージェントの実行では、次のことが見られます: 焦点の定まったメインコンテキスト(重い読み込みは researcher で行われた)、調査を反映した実装、そして実際に何かを捉えた(あるいは信頼できる形で承認した)レビュー。レビュアーが形だけの承認になっているなら、プロンプトを敵対的にします(「何が間違っているか探せ」)。

Check yourself

0/3
  1. reviewer サブエージェントを定義したのに、何度実行してもメインエージェントがそれに委任しません。最も可能性の高い原因はどれですか?
  2. タスクは小さいものです: 関数を 1 つリネームし、その 3 か所の呼び出し元を更新する。調査/実装/レビューのパイプラインを実行すべきですか?
  3. 2 つのサブエージェントが同時に同じファイルへ書き込む必要があります。解決策はどれですか?
Key takeaways
  • タスク名だけでなく、コンテキストとツールセットで分ける: researcher は読み取り専用、implementer は範囲限定の書き込み、reviewer は読み取り専用で敵対的。
  • メインセッションに戻るのは結果だけで、これこそが要点 — 重い読み込みは researcher のコンテキストにとどまる。
  • description はルーティングキー。曖昧だと、丁寧に定義したサブエージェントが一度も呼ばれない。
  • レビューゲートは差し戻せてこそ機能する: 問題は implementer に戻り、何も見つからなかったレビューの後でのみタスクが完了する。
  • reviewer は読み取り専用に保つ。書き込み権限を与えると報告せず修正してしまい、そのために作ったシグナルを失う。
  • 逐次だけの作業、隔離していない衝突する共有書き込み、小さなものには、このパターンを使わない。

さらに進むには​

同じパターンをプログラムで行うのがAPI でエージェントを構築するで、プロダクトの画面としてはCowork と Agent Teamsがあります。

次へ​