金曜の夕方、管理画面に CSV エクスポートを付けたくなり、「一覧画面に CSV エクスポート機能を追加してください」とだけ書いてエージェントに渡しました。40分後に返ってきた実装は、たしかに動きました。ただ、既存のダウンロード処理とほぼ同じロジックが別ファイルに二重に生え、ボタンのスタイルも他画面と揃っていません。結局、月曜の朝に自分で書き直しました。
敗因はエージェントの能力ではありません。依頼の切り方でした。複数のプロジェクトを並行して回す個人開発では、エージェントに渡す時間そのものより、返ってきたものを直す時間のほうが高くつきます。この失敗のあと、タスクの切り方と依頼文の書き方を一度整理してから、手戻りの形が目に見えて変わったので、その基準を実例ごと残しておきます。
大きな依頼が壊れやすい理由 — 判断の数だけ分岐がある
あの1行の依頼に含まれていた暗黙の判断を、あとから数えてみました。どのファイルに置くか、既存処理を再利用するか、絞り込み条件を反映するか、文字コードはどうするか、ボタンはどこに出すか。少なく見積もって10個を超えます。
1行で渡すということは、この10個をすべてエージェントが単独で決めるということです。しかも判断は積み木のように連なっていて、最初の「既存処理を見ない」という1個のズレの上に、残り9個が正しく積まれていきます。返ってきたものが「動くのに使えない」とき、壊れているのはコードではなく、たいてい判断の前提のほうです。
かといって、判断1個ずつに分けてチャットで往復すれば、今度は文脈が細切れになります。前のやり取りの前提が次の依頼に引き継がれず、説明し直しのコストが膨らむ。大きすぎても小さすぎてもだめだとすると、どこかに切る基準が要ります。
「自分が15分でレビューできる量」を1タスクにする
私はこの基準に落ち着きました。返ってきた成果物を、自分が15分で読み切って良し悪しを言える量。それを超える依頼は分割します。
レビュー可能性で切ると、結果的にタスクは「調査」「実装」「検証」の節目で切れることが多くなります。これは Antigravity の挙動とも相性がよく、エージェントは実装計画や walkthrough を Artifacts として出してくるので、コードを読む前に計画だけをレビューする、という関所を自然に作れます。計画の段階で「既存処理を再利用してください」と一言返すのは数秒ですが、実装後に同じ指摘をすると40分が消えます。
実例 — CSV エクスポートを3通の依頼に分け直した
書き直しになった例の依頼を、後日、別の画面で次の3通に分けて出し直しました。
1通目（調査・コード変更なし）
src/admin 配下で、データのエクスポートやダウンロードに関わる既存処理を洗い出してください。再利用できそうな関数と、再利用しないほうがよい場合はその理由を一覧にまとめてください。コードは変更しないでください。
2通目（実装・受け入れ条件つき）
調査メモの useExportBase を再利用して、受注一覧に CSV エクスポートを実装してください。受け入れ条件は次の3つです。(1) 一覧右上に他画面と同じスタイルのボタンが出ること、(2) 現在の絞り込み条件が反映された CSV が落ちること、(3) 新しいユーティリティ関数を増やさないこと。
3通目（検証）
実装した機能をブラウザで操作して確認し、walkthrough を残してください。確認してほしいのは、0件のとき・10万行のとき・セル内に改行と引用符が混ざるときの3ケースです。
3通の合計所要時間は、1行で投げたときより長くなります。それでも、月曜の書き直しがない分だけ、締めてみれば速い。1通目で「コードは変更しないでください」と明記するのは小さなコツで、調査だけ頼んだつもりが気を利かせた実装まで返ってくる事故を防げます。
受け入れ条件は「終わった状態」を3行で書く
2通目に付けた受け入れ条件が、この運用の要です。書き方は単純で、「終わった状態」を観察可能な文で3行ほど並べるだけです。
コツは、曖昧語を消すことに尽きます。「いい感じに」「適切に」「必要に応じて」は、エージェントに対しては「あなたが決めてください」と同義です。決めてほしくない判断があるなら、その場で条件として書く。書かなかった判断は委ねたものとして、返ってきた結果に文句を言わない。この線引きを依頼文の側に置くようにしてから、レビューの揉め事（相手はエージェントですが）が減りました。
受け入れ条件にはもう1つ利点があります。3通目の検証タスクが、受け入れ条件をそのままチェックリストとして使えることです。書く時間は2分ほどで、検証の設計が同時に終わります。
並列に走らせるなら、ファイル境界で切る
Antigravity 2.0 で worktree とプロジェクト管理が入り、複数エージェントを並列に走らせるのが現実的になりました。ただ、並列の失敗は原因がほぼ1つに集約されます。同じファイルを2つのタスクが触ることです。
私のルールは保守的で、「触るファイル集合が交わらない」と言い切れるときだけ並列にします。交わるかもしれない、と迷った時点で直列です。実際に運用してみると、並列化で縮む時間は思ったより小さく、マージの衝突を解きほぐす時間は思ったより大きい。フロントとバックエンド、アプリ本体とドキュメント、といった粗い境界で分けられるときだけ、並列の利得が残ります。
それでも大きく投げてよい場面
この切り方を原則にしつつ、例外も決めています。私自身、捨てる前提の検証コードまで律儀に3分割して、かえって遅くなったことがあるからです。使い捨てのプロトタイプ、まっさらな新規プロジェクト、失敗しても困らない探索は、むしろ1行で大きく投げます。レビューしない前提の成果物を、レビュー単位で切る理由はないからです。
基準は成果物を長く保守するかどうかです。長く持つコードは小さく切って関所を通し、捨てるコードは大きく投げて速度を取る。同じエージェント相手でも、依頼の形は成果物の寿命で変えるのが、いまのところ一番納得のいく整理です。
次の依頼の送信前に、ひとつだけ
次にエージェントへ何か頼むとき、依頼文を書き終えたら、送信する前に「この結果を自分は何分でレビューできるか」と自問してみてください。15分を超えそうなら、まず調査か計画だけを先に頼む。それだけで、返ってくるものの精度と、直しに使う時間の形が変わるはずです。