リリース済みのアプリで、特定の端末でだけ落ちるクラッシュに半日溶かしたことがあります。スタックトレースは手元にあるのに、どの非同期処理が原因かが絞り込めない。そんなときに Antigravity のエージェントへ初動を任せるようになってから、原因特定にかかる時間の感覚がはっきり変わりました。ここでは、私自身が個人開発の現場で繰り返し使っている、デバッグとテストのプロンプトの型を紹介します。
エラーログは「何をしたとき」とセットで貼る
Antigravity でデバッグを始める最もシンプルな方法は、エラーログをそのまま Editor View に貼り付けることです。スタックトレースやコンソール出力を渡すと、エージェントがコードベース全体を参照しながら原因を推測し、修正案まで提示します。
ただし、ログ単体ではエージェントの調査範囲が散らかりがちです。効くのは「どの操作で発生したか」を一文添えることでした。たとえば「ユーザー登録フォームで送信ボタンを押すと 500 が返る」と書くと、関連するエンドポイントやバリデーションまで自然に調査が広がります。逆にこの文脈がないと、表面的なログの行だけを直そうとして、見当違いの修正を引き当てることがあります。
ブレークポイントの代わりに「実行フローを語らせる」
従来のデバッガーではブレークポイントを置いて変数を追いかけますが、Antigravity では「この関数の実行フローを追って、各ステップの引数と戻り値を説明してください」と頼むだけで、内部の流れを言葉で受け取れます。
私が一番恩恵を感じたのは、AdMob のメディエーションまわりで起きていた、初期化の競合による表示抜けを追っていたときでした。複数のコールバックがどの順序で走るかをエージェントに説明させると、人間がブレークポイントを置く前に「ここで await が抜けています」という当たりがつきます。非同期処理や複数サービスの連携で起きる問題ほど、全体を俯瞰させるこのやり方が効きます。
テストケースは正常系・異常系・境界値で頼む
Antigravity のエージェントは、既存コードからテストケースを生成できます。対象の関数やモジュールを指定して「ユニットテストを作ってください」と依頼すると、正常系・異常系・境界値のテストコードがまとめて返ってきます。
package.json や設定ファイルからテストランナーを自動検出するため、Jest・Vitest・pytest のどれを使っているかを明示する必要はありません。私の場合、生成された雛形をそのまま採用することは少なく、異常系のケースだけを残して正常系は自分の意図に書き換える、という使い方に落ち着いています。雛形が出てくるだけで、書き始めの心理的な負荷がだいぶ軽くなります。
バグ修正のたびにリグレッションテストを足す
バグを直したら、その場で「この修正に対するリグレッションテストを追加してください」と指示します。修正内容に基づいた回帰テストが生成され、同じバグが再発したときに即座に気づける網が少しずつ編まれていきます。
GitHub Actions などの CI と組み合わせると、プルリクエストごとに自動でテストが走ります。個人開発では「自分一人が唯一のレビュアー」になりがちなので、この自動の網は精神的な保険として大きいと感じています。
誤った修正を引き当てないための3つの文脈
エージェントの精度は、渡す文脈の質でほぼ決まります。私が必ず添えるようにしているのは次の3つです。
- 再現手順を具体的に書くこと。「たまに落ちる」ではなく「Wi-Fi を切った状態で起動すると初回だけ落ちる」まで踏み込む
- 期待する動作と実際の動作を分けて書くこと。両者が混ざると、エージェントは「どちらが正しいのか」を推測で埋めてしまう
- テスト生成では、行カバレッジ 80% など到達したい目標を先に伝えること
この3つを省くと、もっともらしいけれど的外れな修正が返ってきて、かえって時間を失います。最初の一文を丁寧に書くことが、結局いちばんの近道でした。
返ってきた修正は、採用前に一度だけ疑う
エージェントの修正案は、たいてい「動くように見える」状態で返ってきます。ここで一呼吸おいて、なぜその修正で直るのかを自分の言葉で説明できるか確かめるようにしています。説明できないまま採用すると、根本原因ではなく症状だけを覆い隠した修正になりがちで、数週間後に別の形で再発します。
私の場合、修正案に対して「この変更で直る理由を、元のバグの発生条件と結びつけて説明してください」と追い質問を一つ投げます。理由が再現条件ときれいにつながれば採用し、つながらなければ調査をやり直します。この一往復を挟むだけで、その場しのぎの修正をコミットしてしまう事故がかなり減りました。
まず小さなバグから任せてみる
Antigravity を使ったデバッグとテストは、開発者の時間の使い方を静かに変えてくれます。次にバグに出会ったら、原因の当たりをつける最初の数分をエージェントに渡し、自分は再現手順を言葉にする側に回ってみてください。その分担がしっくり来たら、テストの雛形生成へと範囲を少しずつ広げていくのがおすすめです。