Antigravity を試しに使ったことがある方は多いと思いますが、「毎日、本番リリースを目指して使い続ける」という体験をされた方はまだ少ないかもしれません。このエントリは、3ヶ月間・6本の機能リリースを通じて見えてきた、Antigravityの現実的な姿を記録したものです。
結論から言うと、「使える」ツールです。ただし「何でもできる魔法」ではなく、「設計は人間、実装はAI」という役割分担を徹底したときに最もパワーを発揮します。この当たり前のようで実は難しい分担を、3ヶ月かけて学んでいきました。
最初の1ヶ月：スピード感に驚き、設計ドリフトに気づく
最初の1ヶ月は正直、驚きの連続でした。「ユーザーがウィジェットからアプリを開いたときの遷移アニメーションを改善したい」という要件を伝えると、30分でコードが出てきて、動いた。以前は半日かかっていた作業です。
しかし1ヶ月目の終わりに気づいた問題がありました。「設計ドリフト」です。複数のセッションに渡って機能追加を続けていると、Antigravityが提案するコードが徐々にプロジェクトの設計思想からズレていくのです。
具体的には、状態管理に Redux Toolkit を使っているプロジェクトで、ある日突然 useState と useContext を使ったローカル実装を提案してきました。「動くから問題ない」と思ってマージしてしまうと、次のセッションでは「既存コードに合わせて」さらに useState ベースの実装が増え始めました。
これを防ぐために導入したのが .agents.md への設計原則の明記です。
# 設計原則（.agents.md）
## 状態管理
- グローバル状態: Redux Toolkit (RTK) のみ使用
- ローカルUI状態: useState は許可するが、サーバーデータをキャッシュするためのローカル状態は禁止
- Context APIは認証情報の受け渡しのみに使用
## コンポーネント設計
- UIコンポーネントはビジネスロジックを含まない
- カスタムフックでロジックを分離する
- ファイル名は PascalCase (コンポーネント) / camelCase (hooks/utils)これを追加してから設計ドリフトは大幅に減りました。Antigravityは既存コードを読んで「空気を読む」能力がありますが、新しいセッションのたびにその空気をゼロから読み直しているため、明文化されたルールの方が確実に守られます。
2ヶ月目：コンテキスト汚染との戦い
2ヶ月目に直面したのが「コンテキスト汚染」の問題です。長いセッションの中で関係のないコードを何度も参照させると、後半になるほど提案の精度が落ちていきます。
特にやりがちな失敗が「1つのセッションで複数の機能を実装しようとする」ことでした。「まずAを実装して、次にBも実装して、最後にCのバグも直して」と続けると、セッション後半でAntigravityがAとBの実装を混同した提案をしてくるようになります。
解決策は単純で、「1セッション・1タスク」のルールを徹底することです。
良い例：
セッション1: ログイン画面のUIをリデザイン
セッション2: 認証フローのエラーハンドリングを改善
セッション3: ユーザープロフィール画面の実装
悪い例：
セッション1: ログインUI + 認証エラー処理 + プロフィール画面 + プッシュ通知設定を全部まとめて実装
また、セッション開始時に必ず「今日やること」を1文で宣言するクセをつけました。
antigravity.chat の最初のメッセージ例:
「今日のタスク: src/screens/Profile/ProfileEditScreen.tsx のバリデーション処理を改善する。
変更範囲はこのファイルとそのテストファイルのみ。他のファイルは変更しない。」
タスクと変更範囲を明示することで、Antigravityが余計なリファクタリングを提案してくる頻度が下がりました。
2ヶ月目後半：ループバグのパターンと対処法
Antigravityを使っているとたまに遭遇するのが「ループバグ」です。同じ修正を何度も提案してくる状態で、特に複雑なTypeScriptの型エラーを解決しようとしているときに起きやすいです。
私が遭遇したケースでは、Promise<void> と Promise<undefined> の型の不一致を直そうとしていたAntigravityが、5回連続で異なる「同じ間違い」を提案してきました。
このときの対処法として効果的だったのが「一度立ち止まって原因を分析させる」ことです。
NG：「エラーが出ています。直してください」
OK：「以下のTypeScriptエラーが出ています。
まず修正のコードを書く前に、なぜこのエラーが発生しているかを分析して説明してください。
修正案は分析の後に提示してください」
「説明してから修正」という順序にすることで、Antigravityが本質的な原因を把握してから実装するようになり、ループバグが解消されました。
3ヶ月目：「AIが得意なこと」の解像度が上がる
3ヶ月を経て、Antigravityが本当に得意なことと、そうでないことが具体的に見えてきました。
Antigravityが得意な作業：
- ボイラープレートコードの生成（CRUD操作・フォームバリデーション・APIレスポンス型定義など）
- テストコードの生成（特に正常系のユニットテスト）
- 既存コードのリファクタリング（関数の抽出・命名の改善・型注釈の追加）
- エラーメッセージのデバッグ支援
- ドキュメントコメントの生成
人間が判断すべき作業：
- アーキテクチャの決定（どのライブラリを使うか・ディレクトリ構成の設計）
- UX上のトレードオフ（スピード vs 安全性・シンプルさ vs 柔軟性）
- 既存ユーザーへの影響が大きい変更の判断
- セキュリティ要件の確認と承認
- パフォーマンス上の最適化方針
この「得意・不得意リスト」は人によって異なるかもしれませんが、私のプロジェクトでは上記の分担が最もうまく機能しました。アーキテクチャの決定をAntigravityに任せようとした回は、後から見直したときに「なぜこの構造にしたんだっけ」という状態になりがちでした。設計上の意思決定は、必ず自分が主体になる点が肝心です。
3ヶ月間の振り返り：数字と体感
3ヶ月間で完了した主な作業：
- 機能リリース：6本（以前の同期間比 +2本）
- 修正バグ：32件（うちAntigravityが発見・修正まで担当：18件）
- 追加テスト：61本
- コードレビューでの差し戻し：以前比 -40%
数字以上に変わったのは「実装への心理的ハードル」です。以前は「この機能、作るの大変だろうな」と感じた瞬間に後回しにしがちでした。今は「Antigravityと一緒にやれば大丈夫」という安心感があって、すぐ着手できるようになりました。
ただし、良いことばかりではありません。Antigravityを使い続けることで「なぜこのコードがこう動くのか」を深く考える機会が減り、コードベースの理解が浅くなる危険があります。1週間に1度、Antigravityを使わずに自分でコードを書く時間を意図的に設けるようにしたのは、そのためです。
個人開発者が最初に設定すべき3つのこと
この3ヶ月の経験から、Antigravityを使い始める前に整えておくべきことをまとめます。
1. .agents.md に設計原則を書く：最初に書くのが面倒でも、後から書くよりずっとコストが低いです。状態管理のルール・命名規則・テストの方針を最低限明記しておきましょう。
2. タスクの粒度を決める：「1セッション・1タスク」のルールを最初から守ることで、コンテキスト汚染を防げます。大きなタスクは必ず分割してから着手します。
3. 設計決定のログを残す：Antigravityとのやりとりで「なぜこの設計を選んだか」の理由が会話の中に流れていくのを防ぐため、重要な設計決定は別ファイルに記録します。私は DECISIONS.md というファイルをプロジェクトルートに置いています。
次の3ヶ月は、今回の記録をもとに「Antigravityのフック機能を使ったCI/CDとの連携」に取り組む予定です。リリースまでのフローをさらに自動化できると確信しています。