あるとき、謎のエラーを40分かけて追いかけていたことがあります。ログを見て、スタックトレースを確認して、ブレークポイントを仕込んで——それでも原因がわからありません。諦めかけたタイミングで気づきました。Antigravityのエージェントが30分前に設定ファイルをひっそりと書き換えていたのです。
デバッグの対象が変わっていたのに、自分は旧来の方法で原因を探していました。
AIと組むと、何がどう変わるのか
従来の開発では、コードを変更するのは人間だけでした。何かおかしな挙動があれば、「直前に自分が変えた箇所」を疑えばよかった。変更の痕跡は自分の頭にあるか、Gitの差分を見ればわかりました。
AIエージェントと組むと、この前提が崩れます。エージェントは複数のファイルを同時に、しかも素早く変更します。しかも「直しましたよ」とだけ報告して、変更の全容を伝えないことがあります。善意の変更が、予期しない副作用を生む。これがAI時代のデバッグを難しくしている構造的な問題です。
Antigravityのエージェントは特に高性能で、複数ファイルにまたがる変更をスムーズにこなします。それゆえ、「どこが変わったか」を把握しないままにすると、問題が起きたときの原因探索範囲が一気に広がります。
「三層構造」でエラーを見る
AIと組んだ開発でエラーが出たとき、私は次の三層を順番に確認するようにしています。
第一層: 環境・設定ファイル
エージェントが最初に手を入れるのは往々にして設定ファイルです。package.json、.env、tsconfig.json、フレームワーク固有の設定——これらが変わっていないかを最初に確認します。
# 直近のgit差分を確認（エージェントセッション開始以降）
git diff HEAD~3 -- "*.json" "*.env*" "*.config.*"
# または特定ファイルを重点確認
git log --oneline --follow -- tsconfig.json package.json第二層: AIが変更したファイル全体
Antigravityのチャット履歴やDiff Viewを使い、エージェントが今回のセッションで変更したファイルを洗い出します。見落としがちですが、エラーの直接原因でない別ファイルの変更が、間接的に問題を引き起こしていることがあります。
# セッション中の変更を一覧で把握
git diff --name-only HEAD~1 HEAD
# 変更量が大きいファイルほど要注意
git diff --stat HEAD~1 HEAD | sort -k3 -rn | head -10第三層: 自分が意図したコード変更
最後にようやく、自分の変更を確認します。従来と逆順です。AIに任せた部分が想定外に動いていることが多いため、意図的に「自分のコードは最後に疑う」という順序にしています。
AIを信じすぎる問題と、疑いすぎる問題
AIエージェントを使い始めた頃、「AIが直してくれた」と言うメッセージを信じて確認をサボる癖がつきました。エラーが消えても、根本原因が解決されていないまま別の書き方で回避されていただけ——という経験を何度かしてからは考えを改めました。
一方で、AIの提案を全て疑ってかかるのも非効率です。毎回「本当に正しいか」を1から検証していたら、AIを使う意味がなくなります。
私が今採用している基準はシンプルです。
「変更の規模」と「自分が把握できているか」で判断する
小さな変更（数行のバグ修正、型エラーの解消）はAIの判断を信頼して先に進みます。大きな変更（設定ファイルの書き換え、アーキテクチャレベルの再構成）は必ず差分を自分の目で読みます。把握できていない変更は、たとえ動いていても信頼しません。
// 例: エージェントがデータ取得関数を「改善」してくれた場合
// 動いているからといって確認をスキップしない
// Before（自分が書いたコード）
async function fetchUser(id: string) {
return await db.user.findUnique({ where: { id } });
}
// After（エージェント変更後）
async function fetchUser(id: string) {
const cached = await cache.get(`user:${id}`);
if (cached) return JSON.parse(cached);
const user = await db.user.findUnique({ where: { id } });
await cache.set(`user:${id}`, JSON.stringify(user), { ttl: 300 });
return user;
}この場合、キャッシュの追加は一見改善に見えます。しかし「キャッシュが古くなったらどうなるか」「エラー時のハンドリングは？」を確認しなければ、本番で問題が起きたとき原因がわからなくなります。
「なぜ直ったか」を必ず自分の言葉で言えるようにする
AIがエラーを直したとき、私は「なぜそれで直ったか」を自分の言葉で説明できるまで確認するようにしています。説明できなければ、再現方法も予防方法もわかりません。
# エラー修正後の確認スクリプト（例）
echo "=== エラー修正確認チェックリスト ==="
echo "1. 何が原因だったか（1文で言えるか）"
echo "2. どのファイルがどう変わったか（git diffで確認したか）"
echo "3. 修正が「回避」ではなく「解決」かどうか"
echo "4. 同じ問題が他の場所でも起きていないか"手間に感じるかもしれませんが、この習慣が長期的なコードベースの健全性を守ります。AIが「動くコード」を生成できても、「なぜ動くか」を理解しているのは人間でなければなりません。
Antigravityのチェックポイント機能を活かす
Antigravityにはcheckpoints機能があります。エージェントが大きな変更を行う前に自動的にスナップショットを作る機能で、問題が起きたときに特定のポイントまで戻れます。詳しい使い方はAntigravity Checkpoints & Rollback 完全ガイドにまとめています。
私はデバッグ作業の前に手動でチェックポイントを作る習慣をつけました。「デバッグを始める前」の状態を保存しておくと、AIが意図しない変更をした場合でも安全に戻れます。
# Antigravity での手動チェックポイント作成
Cmd+Shift+P → "Create Checkpoint"
→ 名前: "debug-session-start-2026-05-08"
加えて、長いデバッグセッションでは定期的にGitコミットを挟むことを強くすすめます。「とりあえず動く状態」を保存してから次の問題に取り組む——この習慣がAI時代のデバッグを安定させます。
全体を振り返って：疑う場所が変わった
AI以前のデバッグは「自分が書いたコードのどこが間違っているか」を探す作業でした。AIと組む今は「自分が理解していない変更がどこにあるか」を探す作業に変わっています。
疑う場所が変わったことを意識するだけで、デバッグにかける時間は大幅に短縮できます。次のデバッグセッションでは、まずGitの差分を確認するところから始めてみてください。それだけで、謎のエラーの半分は解決のヒントが見えてくるはずです。
同じ試行錯誤をしてきた方の参考になれば幸いです。