Orca を使っていて、いちばん重宝しているのはオーケストレーションだ。エージェントを何人動かせるか、という数字が魅力なのではない。自分の頭の中にある「この順番なら進む」を、作業の流れとして外に出せるところに価値がある。
一人のエージェントに大きな依頼を渡す方法はシンプルだ。でも、調査、実装、検証、レビューまでが一つの長い会話に入ると、途中で何を信じてよいか分かりにくくなる。失敗したときの戻り先も曖昧になる。オーケストレーションは、その塊を意味のある仕事に分ける。
たとえば小さな機能追加なら、次のように考える。
- 調査役に既存実装・仕様・影響範囲をまとめてもらう
- 実装役に、調査結果を前提として worktree 内で変更してもらう
- 検証役に、変更とは別の視点でテストと回帰確認を任せる
- 最後に自分が差分と報告を読んで、採用するか判断する
ここでのコツは、エージェントに「全部やって」と言わないことだ。各担当の完了条件を一文で言える大きさにする。「変更箇所を列挙し、実装方針を3点にまとめる」「指定した画面だけを修正して、対象テストを実行する」「変更差分を読んで懸念点だけを報告する」。こうしておくと、結果が比較しやすく、次の担当へ渡す情報も薄まらない。
Orca の worktree と組み合わせると、この分担が安全になる。実装役は独立した場所で変更し、レビュー役は差分を見る。別案を試したければ、同じ依頼を別の worktree に振ってもよい。重要なのは、並列にしたすべての結果を採用しなくてよいことだ。オーケストレーションは「複数の正解を強制する」仕組みではなく、判断材料を早く揃える仕組みだと思っている。
途中の介入も、Orca を使う理由の一つだ。エージェントが調査の沼にはまりそうなら追加の指示を送る。実装が想定より大きくなっていたら、範囲を絞る。完了通知を受け取ったら、すぐ次の指示を返す。エージェントを起動して放置するのではなく、必要なタイミングだけ短く舵を切れる。この「待つだけではない」感覚が、長いタスクほど効いてくる。
失敗しにくい始め方は、まず二つの役割だけにすることだ。たとえば「調査」と「実装」。調査の結果を読んでから実装を始めるだけでも、巨大な依頼を一度に渡すより質が上がる。慣れたら「検証」や「別案の実装」を追加する。最初から人数を増やすより、受け渡しの言葉を磨くほうが効果が大きい。
オーケストレーションは、エージェントに仕事を丸投げするための魔法ではない。むしろ人が得意な、目的の設定、分解、優先順位づけ、最終判断をはっきりさせる。Orca はその判断の間にある待ち時間と画面移動を減らしてくれる。だからこそ、日々の開発で何度も使いたくなる。
小さく始めるための依頼テンプレート
```text
目的：ログイン画面のエラー表示を改善する
担当：既存実装の調査
完了条件：
- 関連ファイルを列挙する
- 現在の表示フローを3点で説明する
- 変更案とリスクを報告する
制約：コードは変更しない
```
調査結果を受け取ったら、実装役には「この報告を前提に、変更は最小限に」「対象テストを実行し、実行できない場合は理由を記録して」と渡せばよい。役割が変わるたびに、目的と完了条件を短く書き直す。それだけで、エージェントの仕事はかなり扱いやすくなる。