Planでは自由に、修正では厳密に――AIコーディングを安定させるコミット境界

この記事は、主に Antigravity 2.0（Gemini 3.5 Flash (High)） を使って開発する中で得られた知見をまとめたものです。

特定のツールだけに通用する話ではなく、AIコーディングエージェント全般にも応用できるのではないかと考えています。

AIコーディングエージェントに実装を任せると、最初は驚くほど順調に進むことがあります。
関連ファイルを調査し、構成を考え、複数のファイルをまとめて変更してくれる。人間が一つずつ書くより、はるかに速く形になることもあります。

しかし、同じ会話の中で細かな修正を何度も頼むと、挙動が怪しくなることがあります。

• 表示だけ直してほしいのに、別の処理まで変更される
• 以前の修正を残してほしいのに、元へ戻される
• 一つの不具合を直した結果、別の不具合が生まれる

これは単純なAIの性能不足ではありません。

作業のフェーズが変わったのに、指示の出し方を変えていないことも原因の一つです。

結論

私は、AIコーディングを次の流れで進めるようになりました。

1. Planでは、広く調査させて自由に考えさせる
2. Implementation Plan¹は、人間が綿密にレビューする
3. 承認した計画に沿って、一度まとめて実装させる
4. 動く状態になったら、完全でなくてもコミットする
5. 以後の修正では、対象と制約を厳密に指定する
6. 文脈が混乱したら、新しいセッションへ移る

重要なのは、最初から最後まで同じ粒度の指示を使わないことです。

発散する段階では自由を与え、収束する段階では制約を強めます。

Planでは自由を与える

設計の初期段階では、人間側にも正解が見えていないことがあります。

この段階で変更方法を細かく指定しすぎると、AIがコードベースを調査して見つけたはずの、より自然な実装案を潰してしまいます。

Planでは、次のように依頼します。

関連するコードと既存の設計パターンを調査してください。
まだコードは変更しないでください。

複数の実装案がある場合は、利点と欠点を示してください。
私の前提が誤っている場合は指摘してください。

ここではAIを作業者ではなく、調査担当者や設計相談相手として使います。

Implementation Planは厳しく見る

方向性が決まったら、具体的な実装計画を作らせます。

確認するのは、主に次の内容です。

• 変更するファイル
• ファイルごとの変更内容
• 既存機能への影響
• テスト方法
• 完了条件
• 今回変更しないもの

AIが書いたコードをあとから直すより、計画の段階で直すほうが安く済みます。

建物を建てたあとで基礎を動かすより、図面へ赤線を引くほうが容易です。

完璧でなくても一度コミットする

計画を承認したら、一度まとめて実装させます。

命名や表示、エラー処理に改善点が残ることもあります。しかし、全く使えない状態でなければ、私は一度コミットします。

git add .
git commit -m "Add initial implementation"

ここでいうコミットは、完成の宣言ではありません。

ここまでは一つの到達点として保存するという意味です。

コミットすると、次の修正を独立した差分として確認できます。

git diff HEAD

意図しないファイルまで変更された場合も、すぐに気づけます。

さらに、AIに対して明確な基準を示せます。

現在のHEADを基準とします。
今回の修正対象以外は変更しないでください。

コミットは、コードを保存するだけの操作ではありません。

維持する部分と、これから変更する部分を分ける境界になります。

修正フェーズでは自由度を下げる

最初の実装では、AIが複数のファイルを横断して変更する能力が役立ちます。

しかし、仕上げの段階では、その能力が危険になることがあります。

修正時には、次の内容を明示します。

• 何を直すのか
• 何を維持するのか
• 変更してよいファイル
• リファクタリングの可否
• 完了条件
• 実行するテスト

たとえば、次のように指示します。

一覧画面の日付表示だけを修正してください。

制約:
- APIレスポンスは変更しない
- 新しいライブラリを追加しない
- 関係のないリファクタリングをしない
- 指定したファイル以外は変更しない

作業後にgit diffとテスト結果を示してください。

「よい感じに直してください」ではなく、変更契約を渡すイメージです。

これはAIの能力を低く見積もり、仕事を細切れにするための手法ではありません。

Planでは探索能力を生かす。修正では変更範囲を絞る。

フェーズに応じて役割を切り替えることで、AIの強みを生かしつつ、意図しない変更を防ぐための手法です。

コミットしても会話の文脈は消えない

注意点もあります。

Gitへコミットしても、同じAIセッションを続けている限り、過去の指示や失敗した修正は会話の文脈に残ります。

同じ箇所を何度も直させたあとに挙動が不安定になった場合は、新しいセッションへ移ります。

その際は、現在のHEAD、変更対象、禁止事項、完了条件を改めて伝えます。

つまり、

• コミットでコードの状態を整理する
• 新しいセッションでAIの文脈を整理する

この二つは別の操作です。

まとめ

AIコーディングを安定させるために必要なのは、完璧なプロンプトを一度で書くことではありません。

作業の状態に応じて、AIへの指示を変えることです。

Planでは自由に考えさせる。
Implementation Planでは、人間が厳しく確認する。
形になったら、完全でなくてもコミットする。

修正段階では、対象と制約を絞る。

文脈が混乱したら、新しいセッションへ移る。

AIへ常に細かく命令することが制御ではありません。

自由に走らせる場所と、止める場所を設計することこそ、現在のAIコーディングにおける有効な制御なのだと思います。

もっとも、この記事で延々と説明してきたような細かな制御をしなくても、状況を読み、必要な変更だけを選び、不要な変更を避けてくれるAIは、すでに現れ始めています。

人間がPlanとImplementation Planを分け、コミットを境界にし、変更してよいファイルを一つずつ指定する。
そんな作業を古い開発作法として振り返る日は、そう遠くないのかもしれません。

そのとき、この記事は何だったのか。

おそらく、AIが十分に賢くなるまでの、ほんの短い時代にだけに必要だった運転技術の記録です。

1. Implementation Planとは、タスクを達成するためにコードベースへ必要となる変更を設計し、具体的な技術的修正内容を示す、ユーザーによるレビューを前提としたArtifactです。 https://codelabs.developers.google.com/getting-started-google-antigravity?hl=ja#6 ↩