夜中に、4本のアプリのうち1本のストア説明文をまとめて差し替えようとしていたときのことです。
Antigravity に Planning モードで段取りを立てさせると、きれいな7ステップのプランが返ってきました。ほとんどは申し分ありません。ただ、5番目に「課金まわりの設定ファイルも整合性のために更新します」という一文が紛れ込んでいました。頼んでいないのに、です。
ここで「全部やり直し」と突き返すのは、もったいない選択でした。残り6ステップは正確で、私の意図どおりだったからです。必要だったのは、5番目だけを静かに抜くこと。プランを承認する前に、その一手だけを削る——この小さな所作が、エージェント運用の事故をかなり減らしてくれます。
なぜ「作り直し」ではなく「部分編集」なのか
Planning モードのプランは、エージェントが文脈を読み込んで組み立てた成果物です。多くの場合、8割は正しい。問題は残りの2割に、触れてほしくない領域への一手が混じることです。
ここで再プロンプトに頼ると、せっかく当たっていた8割も作り直しになります。新しいプランが前より良くなる保証はありません。むしろ、同じ誤解を別の形で繰り返すことのほうが多いのです。
部分編集は、この非対称性に効きます。正しい部分は固定し、危ういステップだけを外科的に取り除く。個人開発で一人が複数リポジトリを回していると、レビューに割ける時間は限られています。プラン全体を読み直すより、危険な一手を見抜いて削るほうが、はるかに速くて安全でした。
判断の枠組みは、承認・編集・却下の3択で考えると整理しやすくなります。
| 状況 | とるべき操作 | 理由 |
|---|
| 全ステップが意図どおり | 承認 | 編集の手間は不要。すぐ実行へ |
| 大筋は正しいが一部に余計な一手 | 部分編集 | 良い部分を残し、危険なステップだけ外す |
| 前提そのものが取り違えられている | 却下して再指示 | 土台がずれている場合は作り直しが速い |
迷ったときの目安は単純です。「直したいのはステップか、前提か」。ステップなら編集、前提なら却下。冒頭のストア説明文の例は、前提は合っていてステップが一つ余分なだけでしたから、編集が正解でした。
削るべき一手を見抜く
プランを眺めるとき、私はまず次の3種類のステップに目を走らせます。これらは「余計な一手」が紛れやすい場所です。
ひとつめは、保護したい領域に触れるステップ。決済の設定、AdMob の構成、本番運用のリダイレクト定義、認証まわりなど、壊れると影響範囲が読みにくい場所です。「整合性のために」「念のため」といった枕詞がついていたら、特に警戒します。
ふたつめは、取り消しにくいステップ。ファイルの一括削除、外部への push、本番へのデプロイ。これらが計画の中盤に何気なく挟まっていると、実行が走り出してから止めるのは難しくなります。
みっつめは、無関係な変更を抱き合わせたステップ。「ついでにリファクタリングもします」という一文です。意図は善意でも、レビューの粒度が一気に粗くなり、後で差分を追えなくなります。
この3つに当てはまるステップを見つけたら、その場で削る。これだけで、エージェントの暴走と呼ばれるものの多くは回避できます。
3つの部分編集
部分編集には、実務上3つの型があります。順に見ていきます。
削る
最も基本的な操作です。プランのステップを文字どおり消します。Antigravity のプランは編集可能なテキストとして提示されるので、該当行を選んで削除します。
ただし、削っただけだと不十分なことがあります。理由は後述しますが、削除と同時に「なぜ削ったか」を一言添えておくと、実行中の復活を防げます。たとえば 5番目を消す代わりに、こう書き換えます。
削除前:
5. 整合性のため pricing.ts のラベルも更新する
削除後（負の制約として明記）:
注意: pricing.ts および決済関連ファイルは今回の作業対象外。
変更してはならない。
ステップを消すだけでなく、「触れてはいけない」という否定形の指示に変換しておく。この一手間が効きます。
並べ替える
検証ステップが最後に置かれているプランは少なくありません。ですが、危ない変更ほど検証は前倒ししたいものです。
たとえば「全ファイルを書き換える → 最後にビルドして確認する」という順序なら、「1ファイルだけ書き換える → ビルド確認 → 残りを書き換える」に並べ替えます。最初の1ファイルで方針が間違っていれば、被害は1ファイルで止まります。
並べ替えは削除より見落とされがちですが、不可逆な操作を含むプランでは効果が大きい編集です。
制約を足す
プランの冒頭に、作業全体にかかる制約を書き足す方法です。個別のステップではなく、実行全体のガードレールを宣言します。
この計画の実行にあたり、以下を厳守すること:
- content/ ディレクトリ配下のみ変更してよい
- src/config/ には一切触れない
- 各ステップ完了ごとに変更ファイル一覧を報告する
ステップごとに注意書きを散らすより、先頭でまとめて宣言したほうが、エージェントの遵守率は体感で高くなります。とくに「変更してよい範囲」を許可リストとして明示する書き方は、保護したいファイルを列挙するより漏れが少なく、安全側に倒れます。私の場合は、この許可リスト方式をお勧めします。
削ったステップが復活する落とし穴
ここが、部分編集でいちばんつまずく点です。
プランから 5番目を削っても、実行中にエージェントが「整合性のために必要だ」と再び判断し、削除したはずの作業を勝手に補ってしまうことがあります。プランはあくまで計画であって、実行を縛る契約ではないからです。
これを防ぐのが、先ほどの「否定形への変換」です。ステップを消すのではなく、「pricing.ts は変更してはならない」という制約として残す。空白にするのではなく、明示的な禁止に置き換えるわけです。エージェントは空白を埋めようとしますが、明文化された禁止は埋めません。
実行が終わったら、必ず差分で確かめます。
# 変更されたファイルの一覧だけを確認する
git status --porcelain
# 触れてほしくなかったパスが含まれていないか
git status --porcelain | grep -E 'pricing|config|checkout' || echo "保護パスへの変更なし"
grep が何も返さず「保護パスへの変更なし」と出れば、削ったステップは復活していません。もし引っかかったら、その変更を取り消してから、制約の書き方を見直します。
個人開発で複数のアプリを回している私の運用では、この差分確認を省いた日にかぎって余計な変更が混じる、という経験を何度かしました。プランを編集した安心感が、最後の確認を飛ばさせるのだと思います。編集と検証は、いつもひとそろいで考えるようにしています。
同じ削除を繰り返さないために
毎回プランから決済まわりの一手を削っているなら、それはプロジェクト側のルールに昇格させる合図です。
Antigravity では、繰り返し効かせたい制約を AGENTS.md のようなプロジェクトルールに書いておけます。「src/config/ は明示的な指示がない限り変更しない」と一度書いておけば、Planning モードはその制約を踏まえた上でプランを組むようになります。手作業での削除が、設計時の前提に変わるわけです。
とはいえ、すべてをルール化すると今度はプランが硬直します。私は、3回続けて同じステップを削ったら AGENTS.md に移す、という緩い基準で運用しています。その場の判断と、恒久的なルール。この二層を意識して使い分けると、レビューの負担が静かに下がっていきます。
この習慣を2週間ほど続けてみて、はっきり変わったことがあります。プランを丸ごと却下して「やり直し」と打つ回数が、体感で半分以下になりました。以前は1割ほどの違和感でもつい全体を突き返していたのですが、いまは余計な一手だけを外して残りを活かす。エージェントに任せるたびに最初からやり直すのではなく、出てきた段取りを土台として育てる感覚に近づいています。
次の一歩
今日のプランを承認する前に、一度だけ立ち止まってみてください。「触れてほしくない領域に踏み込むステップは、この中にないか」。もしあれば、消すのではなく「変更してはならない」という制約に書き換える。そして実行後に git status --porcelain で答え合わせをする。
この小さな手順が習慣になると、エージェントに任せられる範囲は自然と広がっていきます。お読みいただき、ありがとうございました。