夜中に一度だけ、驚くほど的確に動いたプロンプトがありました。リリース前のスクリーンショットを並べ、文言のはみ出しと端末ごとの余白を指摘させたものです。翌週、同じ作業をもう一度やろうとして、私はそのプロンプトを探せませんでした。会話のスクロールの奥に沈んでいたのです。
Antigravity 2.0 では dynamic sub-agents が複数のタスクを並行で引き受けてくれます。便利な反面、子エージェントへ渡した指示は会話のなかで生まれて、会話のなかで消えていきます。一度きりで終わらせるには惜しい働きほど、残し方を決めておく価値があります。
なぜ「うまくいったプロンプト」は二度と同じ働きをしないのか
理由は単純で、その場で書いたプロンプトには前提が書かれていないからです。
そのとき開いていたファイル、直前のやり取り、頭の中にあった暗黙の合格ライン。これらが揃って初めて成立していた指示を、文字列だけコピーしても再現できません。翌週の自分は、別のコンテキストの中にいます。
つまり残すべきは「プロンプトの文面」ではなく、「その指示が成立していた条件ごと」です。サブエージェントの定義とは、その条件を明文化したものにほかなりません。
再利用できるサブエージェント定義に必要な4つの要素
私が繰り返し使えると感じた定義には、共通して次の4つが入っていました。
役割と境界
何をする係なのかを一文で書きます。同じくらい大切なのが、してはいけないことです。
「スクリーンショットの体裁を点検する係。コードやアセットには触れない」のように、許可された範囲と禁止された範囲を両方明示します。境界を書かないと、子エージェントは親切心から余計な変更まで提案し、レビューの手間がかえって増えます。
入力と前提
どのファイル、どのディレクトリ、どの状態を見れば仕事ができるのかを書きます。
ここを曖昧にすると、毎回「対象はどれ？」というやり取りが発生し、再利用の旨味が消えます。入力を固定できない場合は、呼び出すときに渡すプレースホルダとして定義しておきます。
完了の定義
何をもって終わりとするか。ここが定義の心臓部です。
「各端末サイズで文言が枠内に収まっているか、収まっていない箇所を画面名とともに列挙する。問題がなければ『問題なし』とだけ返す」。出力の形まで決めておくと、結果を機械的に扱えるようになります。
失敗時のふるまい
判断できない、対象が見つからない、前提が崩れている。そうした場合に勝手に進めないことを書きます。
自動運用では特にここが効きます。曖昧なまま走られるより、止まって報告してくれるほうが、後始末の総量はずっと小さくなります。
実際の定義ファイル
私はリポジトリ内に docs/agents/ を作り、係ごとに1つのマークダウンを置いています。Antigravity の AGENTS.md から参照させても、呼び出し時に本文を貼っても機能します。
# screenshot-reviewer
## 役割
リリース前スクリーンショットの体裁を点検する係。
コード・画像アセットの変更は行わない（提案も不要）。
## 入力
- 対象: {{ scshots_dir }}（既定: ./fastlane/screenshots）
- 端末: iPhone 16 Pro / iPhone SE / iPad Pro 13 の3サイズ
## 手順
1. 各端末サイズの全画像を確認する
2. 文言が枠外にはみ出している箇所を検出する
3. 端末ごとの上下左右の余白が極端に不揃いな画面を検出する
## 完了の定義
- 問題がある場合: 「画面名 / 端末 / 症状」を1行ずつ列挙
- 問題がない場合: 「問題なし」とだけ返す
- 推測で修正案を書かない（検出に徹する）
## 失敗時
- 対象ディレクトリが空、または見つからない → 進めずにその旨を報告
- 端末サイズが3つ揃っていない → 欠けているサイズ名を報告して停止
ポイントは、手順を3つ程度に絞り、出力の形を1つに固定していることです。やることを増やすほど定義は再利用しにくくなります。係は小さく、たくさん持つほうが扱いやすいというのが、個人開発で道具を増やしてきた実感です。
私自身、Dolice Labs で複数のサイトとアプリを一人で回しているので、巨大な万能エージェントより、小さな点検係をいくつも常備しておくほうが、結局は壊れにくく直しやすいと感じています。万能を1つ作ると、どこが効いてどこが効いていないのかが見えなくなり、手を入れるたびに全体が揺れます。
使い捨てプロンプトから定義へ — 3ステップの蒸留
その場のプロンプトを、上の形に落とすときの手順です。
- 動いた事実を確定させる。 まず、そのプロンプトが本当に役立った出力を1つ手元に残します。手応えだけで定義を作ると、再現しない係ができあがります。
- 暗黙の前提を表に出す。 「このとき何を見ていたか」「どこで満足したか」を自問し、入力と完了の定義に書き写します。ここで言葉にできない合格ラインこそ、毎回ぶれていた原因です。
- やらないことを足す。 実際に余計だと感じた振る舞いを禁止事項として書き加えます。私の場合、最初の定義には必ず「修正案を書かない」が抜けていて、点検係がいつの間にか作業係に化けていました。
この3つを終えると、文面のコピーではなく、条件ごと持ち運べる係が手元に残ります。
呼び出しと、結果を本筋に取り込む
定義ができれば、本筋の会話を止めずに脇へ投げられます。/btw のような使い捨ての横道タスクと相性が良く、定義の本文を渡して入力だけ差し替えます。
# CLI から、定義つきでスクリーンショット点検だけを単発実行する例
agy run \
--agent docs/agents/screenshot-reviewer.md \
--var scshots_dir=./fastlane/screenshots/ja \
--output-format text
# 「問題なし」以外が返ったときだけ、本筋の作業に持ち帰る
戻ってきた出力が「問題なし」なら、本筋の手を止める必要はありません。何か挙がってきたときだけ、その行をそのまま親の会話に貼り、修正の判断は人間が行います。検出と判断を分けておくと、子エージェントを増やしても全体の見通しが保てます。
育て方 — 版を重ねて精度を上げる
定義は一度書いて終わりではありません。使うたびに、外した点を1行ずつ足していきます。
私は AdMob のバナー位置を確認させる係を持っていますが、最初は「広告が本文に重なっていないか」しか見ていませんでした。実機で重なりが起きてから「セーフエリア下端との距離も見る」を追記し、誤検出が続いてから「ダークモードのスクリーンショットは別系統として扱う」を足しました。三度ほど版を重ねたあたりから、ほとんど手戻りが出なくなりました。
定義ファイルはコードと同じくリポジトリに置いてあるので、変更の履歴がそのまま係の成長記録になります。どの版で何を学んだかが残るのは、自動運用を長く続けるうえで思った以上に支えになります。
もう一つ実感しているのは、係が育つほど、人間が見るべき場所が減っていくことです。最初は出力を全部読み直していたものが、版を重ねると「問題なし以外だけ開く」で済むようになります。点検そのものを速くするより、自分が読む量を減らす方向に効くというのが、繰り返し使ってみての発見でした。
次の一歩としては、今いちばん「あのプロンプト、また書くのか」と感じている作業を1つだけ選び、4要素に分解してみてください。完璧な定義を目指さず、動いた事実を1つ残すところから始めれば十分です。お読みいただきありがとうございました。