Codex・Claude Code・Antigravityを実際に使って分かった、AI時代のデバッグ術
はじめに：AIは「動くコード」を作れる。でも、その先が問題だった
以前、私はAIコーディングについてこんな趣旨の記事を書きました。
AIは、とにかく「動くもの」を作る。
しかし、それが保守できるコードとは限らない。
実際にAIにアプリを作らせていると、これはかなり実感します。
「この機能を追加して」
「ここも変更して」
「この条件にも対応して」
と追加指示を繰り返しているうちに、使われなくなった変数が残り、似たような処理が複数箇所に増え、本来ならSwitch/Caseなどで整理できる条件分岐が大量のIF文で実装されている。
それでもアプリは動く。
AIからすれば、要求された機能を実現したのだから「完成」なのかもしれません。
しかし人間から見ると、
「これ、半年後に誰が保守するんだ？」
というコードが出来上がることがあります。
だから私は以前の記事で、
AIにコードを書かせることはできる。
しかし、コードを理解している人間が設計し、チェックする必要はなくならない。
という結論を書きました。
ところが、Codex、Claude Code、Google Antigravityなどのコーディングエージェントを実際の開発で使い続けていると、その先にもう一つ厄介な問題があることに気付きました。
AIが書いたコードでエラーが発生したときです。
AIの「原因が分かりました」は、本当に分かっているのか？
AIコーディングをしている人なら、一度くらいこんな経験があるのではないでしょうか。
エラーが発生する。
AIに、
「このエラーを修正して」
と頼む。
するとAIは自信満々に答えます。
原因が分かりました。
○○の処理に問題があります。修正します。
コードを書き換える。
ビルドする。
直らない。
もう一度エラーを渡します。
するとまた、
原因を特定しました。
と言って別の場所を変更する。
それでも直らない。
さらに修正。
さらに修正。
気が付くと、さっき追加した処理を削除したり、別の場所に似た処理を追加したり、数回前の実装に近い状態へ戻ったりする。
私はこれを何度も何度も経験しました。
またループするときもあります。例えばAはBでした、いややっぱりBはAでした。と何度も繰り返すことです。
ちなみにここでコードが読めれば、それさっき直したやつじゃんとなります。
そして、ここで一つ重要なことに気付きます。
AIは、本当に原因を特定したからコードを変更しているとは限らない。
エラーメッセージや現在のコードから、
「おそらくここが原因だろう」
という確率の高い仮説を立てて変更している場合があります。
もちろん一発で当たることも多い。
問題は、外れたときです。
「修正してください」を繰り返すと、コードが壊れていく
最初はシンプルだったコードが、AIによる修正を繰り返すことで徐々に複雑になっていきます。
典型的にはこうです。
エラー発生
↓
AIが原因を推測
↓
コード変更
↓
直らない
↓
別の原因を推測
↓
さらにコード変更
↓
直らない
↓
別の回避処理を追加
↓
さらにコードが複雑になる
そして最終的には、
最初のエラーより、コードの状態の方が問題になる。
これはAIコーディングで意外と危険なパターンです。
人間のエンジニアなら途中で、
「ちょっと待て。そもそも原因をちゃんと調べよう」
となるところですが、AIは指示された通り、律儀に次の修正案を生成し続けることがあります。
AIは疲れません。
だからこそ、間違った方向にも疲れずに走り続けます。
「申し訳ありません」とかお茶目な回答をしながら・・・。
そこで私は、何度か修正しても直らない場合、AIへの指示そのものを変えるようになりました。
「もう修正するな。まずログを取れ」
これが最近、かなり効いている方法です。
AIが2回、3回と修正しても同じエラーを解決できない場合、私はこんな趣旨の指示を出します。
これ以上、推測でコードを修正しないこと。
まず、この問題の詳細な原因を特定できるログ取得の仕組みを実装してほしい。
必要な状態、入出力、例外、Stack Traceなどを取得できるようにする。
そのログを確認した上で真の原因を分析し、原因を特定してから修正すること。
ポイントは、
「エラーを直せ」から「エラーを観測できるようにしろ」へタスクを変更することです。
するとAIの動きが変わります。
AIを賢くするのではなく、「現場のファクト」を渡す
例えばAndroidアプリなら、
- Logcat
- Stack Trace
- IntentやURIの内容
- ファイル名
- MIME Type
- ファイルサイズ
- APIのRequest / Response
- HTTP Status Code
- WebViewのJavaScript Error
- WASMのロード状態
など、原因を判断する材料はいくらでもあります。
それまでAIは、
「こうなっているはず」
という推測でコードを書いていた。
しかしログを取れば、
「実際にはこうなっている」
という情報を渡せます。
ここには大きな違いがあります。
AIのモデルそのものが突然賢くなったわけではありません。
AIが判断するための情報の質が上がったのです。
これはAIエージェントを使っていて非常に重要だと感じています。
AIが現場で妙な判断を始めたとき、さらに長いプロンプトを書くより、
「現実に何が起きているのかを取得させる」
方が効く場合があります。
それでもダメなら、AIを交代させる
もう一つ、私がよく使っている方法があります。
担当AIを替えます。
例えば私はGoogle Antigravityをコーディングに使うことがあります。
何度か修正させても同じエラーを解決できない。
そんなときは、さらにAntigravityへ、
「もう一度考えて」
と延々と頼むのではなく、
Claudeへ持っていくことがあります。
現在のコード、現象、再現条件、そして取得したエラーログを渡して、
「原因を分析してくれ」
と頼む。
すると、それまでとはまったく違う原因を指摘してくることがあります。
そして、それで解決することがある。
これは「Claudeの方が賢い」という話ではない
ここは誤解しないでください。
Claudeで直ったから、
Claude ＞ Antigravity
と単純に評価しているわけではありません。
逆のケースもあり得ます。
重要なのは、
別のAIは、それまでのAIが積み上げてきた「思い込み」を持っていない
ということです。
人間の開発現場でも同じことがあります。
一人のエンジニアが何時間も障害解析をしている。
最初に、
「ネットワークが怪しい」
と思った。
すると、その後に得られた情報までネットワーク障害という仮説に結び付けて考えてしまう。
そこへ別のエンジニアがやってきて、
「これ、認証じゃない？」
と指摘する。
調べたら10分で解決した。
珍しい話ではありません。
AIでも似たことが起こります。
だから私は、AIが同じような修正を繰り返し始めたら、
AIにもセカンドオピニオンを取る
ようにしています。
私はCodex・Antigravity・Claudeをこう使い分けている
現在、私は複数のAIコーディング環境を使っています。
使っているうちに、自然と役割が分かれてきました。
Codex：上流工程と難しい判断
Codexは、単純にコードを書かせるだけでなく、
- 要件定義
- 仕様整理
- アーキテクチャ検討
- 実装方針
- 難しい問題の分析
といった、上流工程でよく使います。
理由の一つが利用枠です。
私は週次の利用状況を見ながら使っていて、残量が30％を切ってくると、通常のコーディング作業からは外すようにしています。
使い切ってしまって、本当に必要なときに使えない方が困るからです。
言ってみれば、
Codexは「考える仕事」に温存する。
という運用です。
Antigravity：実装担当
仕様がある程度固まったら、実装側ではGoogle Antigravityを使うことがあります。
特にAndroid系のアプリ開発では、
仕様 → 実装 → ビルド → エラー → 修正
というサイクルを回す実装担当として使いやすいと感じています。
ここは今後、さらに使い込んでみたいところです。
Claude：トラブルシューティング担当
そして、Antigravityなどが同じ問題で詰まり始めたらClaudeを投入します。
Claudeには、
「前のAIはこう考えていた」
と余計な先入観を大量に渡すより、
現在のコード
再現条件
実際のエラーログ
を渡して、新しい視点で原因を分析させます。
私の中では、
AI版セカンドオピニオン
です。
AIを「一人の天才エンジニア」だと思わない
ここまで使ってきて、AIコーディングに対する考え方が少し変わりました。
以前は、
どのAIが一番優秀なのか？
という発想がありました。
Codexなのか。
Claude Codeなのか。
Antigravityなのか。
でも実務で使っていると、あまり意味のある問いではない気がしています。
人間の開発チームだって同じです。
アーキテクチャ設計が得意な人。
実装速度が速い人。
障害解析が得意な人。
レビューが得意な人。
全員の能力は違います。
だったらAIも同じように配置すればいい。
私の場合、現在はおおむね、
Codex：アーキテクト／上流SE
↓
Antigravity：実装エンジニア
↓
Claude：トラブルシューティング／セカンドオピニオン
という形になっています。
そして、そのAIチームを管理する役割が人間です。
AI時代、人間はコードを書かなくてよくなるのか？
ここで以前の記事の話へ戻ります。
「AIがコードを書いてくれるなら、プログラミングを理解する必要はなくなる」
という意見があります。
確かに、自分ですべてのコードを書く必要性は下がっていくと思います。
私自身、以前よりAIに書かせるコードは圧倒的に増えました。
しかし、
コードを理解する必要がなくなる
とは、今のところ感じていません。
むしろ逆です。
AIが大量のコードを高速に生成できるからこそ、人間には別の能力が必要になります。
「書く能力」から「判断する能力」へ
AIが書いたコードを見て、
「この変数、もう使ってないよね」
と気付く。
大量のIF文を見て、
「この条件分岐、設計がおかしくないか？」
と気付く。
同じエラー修正を3回やっているのを見て、
「もう修正するな」
と止める。
そして、
「まずログを取れ」
と指示する。
それでも詰まったら、
「別のAIに見せよう」
と担当を替える。
これらはすべて、コードを一文字も書かなくてもできる仕事です。
しかし、ソフトウェア開発を理解していなければできません。
AIがエラーを直せないとき、さらにコードを書かせるな
今回、この記事で一番伝えたいことはこれです。
AIがエラーを直せないとき、さらにコードを書かせるな。まずログを書かせろ。
そして、もう一つ。
同じAIが同じところを何度も直しているなら、別のAIに交代させろ。
AIは非常に優秀です。
しかし万能ではありません。
間違った仮説に入ることもあるし、局所的な修正を積み重ねてコードを複雑にすることもあります。
だから人間の仕事は、AIより速くコードを書くことではなくなっていくのかもしれません。
AIが何をしているのかを理解する。
暴走し始めたら止める。
推測ではなく事実を集めさせる。
必要なら別のAIへ仕事を渡す。
そして最後に、
出来上がったものが本当に正しいかを判断する。
AI時代のエンジニアは「AIチームのテックリード」になる
AIコーディングが進化すると、プログラマーが不要になる。
私は、少なくとも現時点では少し違う景色を見ています。
コードを書く仕事の一部は、確実にAIへ移っています。
しかしその代わりに、
設計
レビュー
デバッグ方針の判断
Root Cause分析
品質管理
AIへのタスク配分
の重要性が上がっています。
つまり人間の役割が、
「コードを書く人」から「AIにコードを書かせ、品質を担保する人」へ移っている。
私は最近、Codex、Antigravity、Claudeを切り替えながら開発していて、時々こう思います。
これはもうAIツールを使っているというより、
小さなAI開発チームを率いているのではないか。
そして困ったことに、このAIエンジニアたちは24時間働くし、コードを書く速度も猛烈に速い。
ただし、ときどき自信満々に間違えます。
だから当面の間、人間のテックリードは必要そうです。
少なくとも、
「原因が分かりました」
というAIの言葉を、そのまま信じなくなるくらいの経験は必要なのかもしれません。
