「先週まで動いていた機能が、今朝から動かない」— その瞬間に頭をよぎるのは、ここ数日の commit 履歴のどこかに原因が潜んでいるという事実だけです。git log を眺めて当たりを付ける作業は地味で、しかも勘がはずれた時の徒労感が大きい工程ではないでしょうか。
最近、Antigravity の AI を伴走役にして git bisect を進めるやり方に切り替えてから、リグレッション調査が一気に短縮できるようになりました。ここではそのワークフローを「AI に何を任せて、何を任せないか」という分担の観点から整理してお伝えします。
なぜ git bisect だけでは詰まりやすいのか
git bisect 自体は二分探索でコミットを絞り込むだけのシンプルな仕組みです。それでも実務で詰まりがちなのは、各ステップで「good か bad か」を判定するための再現手順が、人間にとって地味に重いからではないでしょうか。
- ブランチを切り替えるたびにビルド・依存関係のインストールが必要になる
- 再現するために UI 操作・特定 API 呼び出しを毎回繰り返さなければならない
- 一見「動いた」ように見えても、別の機能が壊れている可能性がある
この「判定が地味に重い」工程こそ、AI に伴走してもらう価値が大きい部分です。一方で、最終的に「これが原因コミットだ」と認識する判断は人間側で握っておきたい。役割分担を最初に決めておくと、迷子になりません。
Antigravity と組み合わせる「3 + 1」の役割分担
私はいつも次の役割分担で進めています。
- AI に任せる: 各コミットでの再現手順実行 / ログとスタックトレースの一次解析 / コミット内容の要約
- AI に下書きさせて自分で承認する: 各ステップの good / bad 判定の理由メモ
- 人間が握る: 「good」「bad」の最終マーキング / 探索範囲の決定 / 修正コミットの作成
特に判定の理由メモを残しておくのが効きます。bisect の途中で「あれ、さっきのコミットを bad にしたけど、ほんとに再現していたっけ？」と不安になる場面が必ず来るからです。Antigravity の Inline Chat でその場でメモを書き出してもらい、PR 説明文の素材としても使い回しています。
実践フロー — フロントエンドのリグレッションを30分で特定する
ここから具体的な手順です。Next.js プロジェクトで「ログイン後にダッシュボードのチャートが描画されない」というリグレッションが発生した場面を想定して整理します。
1. 探索範囲を決める
まず最後に正常だった日付・コミットを思い出します。曖昧でも問題ありません。AI に手伝ってもらえます。
# 最後に動いていた可能性のあるコミットを直近2週間からピックアップ
git log --since='14 days ago' --pretty=format:'%h %ad %s' --date=shortこのログを Antigravity の Inline Chat に貼り付けて、こう聞きます。
「この commit 一覧から、ダッシュボードのチャート描画に関係しそうなコミットを抜き出してください。理由も添えてください」
ファイル名と commit メッセージから当たりを付けてくれるので、git bisect の good 開始点を「2 週間前のリリース直後」に置く判断ができます。
2. bisect を開始する
git bisect start
git bisect bad # 現在の HEAD は bad
git bisect good v3.4.0 # 2週間前のリリースタグここから二分探索が始まります。Antigravity のターミナルは bisect の状態を保ってくれるので、複数の操作を並行してもステップを失いません。
3. 各ステップを AI に再現させる
git bisect が次のコミットに切り替えるたびに、以下のコマンドを Antigravity に依頼します。
今 checkout されているコミットでビルドし、http://localhost:3000/dashboard
にアクセスしてチャートが描画されるか確認してください。
描画されなければエラーを取り、原因仮説を3つ書いてください。ビルド完了を待つ時間も含めて、ターミナルログとブラウザコンソールの両方を AI が監視してくれます。「描画されない」と判定された場合だけ、私が手動で git bisect bad を実行します。
4. 範囲が3コミット以下になったら手動で精査する
機械的な絞り込みは bisect に任せ、最後の1〜3コミットだけ人間が git show で目視確認します。差分が小さい段階で見ると、原因行が驚くほどあっさり見えます。
bisect 中に AI に投げると効くプロンプト
実際に使って手応えがあった頼み方を3つ共有します。コピーして使えるよう、そのままの形で載せます。
プロンプト1: 差分の意味を要約させる
このコミットの diff を読んで、「ユーザーから見た振る舞いがどう変わるか」を
箇条書きで3つ以内にまとめてください。実装の詳細ではなく、結果に絞ってください。差分の規模が大きい時に、見るべき箇所を絞り込めます。
プロンプト2: 「動いて見える」を疑わせる
今、ダッシュボードは描画されているように見えました。
ただし、念のため次の3点も確認してください:
- 1秒以内にチャート要素が DOM に挿入されているか
- console にエラーが出ていないか
- ネットワークタブで /api/metrics が 200 を返しているか
ひとつでも怪しければ "bad寄り" と教えてください。二分探索は判定を間違えると30分が無駄になります。「動いてそう」を疑う癖を AI 側に持たせておくと、後戻りが減ります。
プロンプト3: 原因仮説を3つに絞らせる
範囲が確定した後、最終確認の前に投げます。
HEAD のコミットが原因だと仮定して、なぜチャートが描画されなくなったのか、
原因仮説を3つ挙げてください。優先順位もつけてください。
私はその後、最も確からしい仮説から検証します。仮説を先に並べておくと、修正に着手する際の試行錯誤がぐっと減ります。
git の操作面で迷いが出る場合は、Git のコンフリクトを Antigravity の AI で解消する手順 や、git worktree を使った並列ワークスペース運用ガイド と組み合わせると、調査と修正を別ワークスペースに分離できて快適です。
失敗パターンと回避策
実際にやってみて、私がはまったポイントを3つだけ書いておきます。
1. 環境変数や DB スキーマが古いコミットで合わない
古いコミットに戻ると、その時点の .env や migration が必要になります。bisect を始める前に「環境変数の差分」と「DB のスキーマ差分」を AI に整理してもらい、必要なら一時的に .env.bisect を用意しておきます。
2. テストでは再現するが、git bisect run が誤判定する
git bisect run は便利ですが、E2E テストの flake で誤判定が起きやすい工程です。最初の数ステップは手動で良し悪しを確認し、安定して再現するスクリプトを作ってから自動化に切り替えるのがおすすめです。E2E 自動化との付き合い方は Antigravity の Browser Agent で E2E テストを書く実践ガイド も参考になります。
3. AI の「直しておきました」を即マージしない 原因が見えると、Antigravity が修正コミットまで提案してくれることがあります。便利ですが、bisect で特定した原因と、修正で触るファイルが一致しているかは必ず人間がレビューしてください。原因コミットの作者の意図（あえてその実装にした理由）を見落とすと、別のリグレッションを生みます。
git bisect のような調査の手応えを上げる前提として、コードを読み解く力そのものを底上げしておくと、AI が出してきた仮説の良し悪しを早く判断できます。
全体を振り返って — 次にやる一歩
次にあなたのリポジトリでリグレッションが起きたら、いきなり git log を凝視するのではなく、まず 直近2週間の commit 一覧を Antigravity の Inline Chat に貼り付けて「該当機能に関係しそうなコミットを抜き出してください」と聞いてみてください。それだけで git bisect の探索範囲が現実的なサイズに絞れます。
二分探索の判定はあなたが握り、再現と一次解析は AI に任せる。この役割分担を一度体得すると、夜遅くにバグを追う時間がはっきり短くなる手応えがあるはずです。