エラー解決に使うならどのAI？

プログラミングのエラーをAIに聞くとき、エラーメッセージだけ貼れば解決することもあります。ただ、実務で厄介なのは「どのファイルが原因か分からない」「修正すると別のテストが落ちる」「ローカルでは動くのに本番では失敗する」といったケースです。

先に整理すると、リポジトリ全体を見ながら修正・テストまで進めたいならCodex、ターミナル中心で失敗テストやスタックトレースから根本原因を追いたいならClaude Code、Google系のエージェントIDEでコードを見ながら修正したいならAntigravity系が候補です。どれが一番エラー解決率が高いかは、同じ不具合・同じ環境で比較していないため断定しません。

結論：エラー解決は「答え」より「再現→修正→確認」まで進められるかで選ぶ

表は横にスクロールできます

エラーの状況	まず見る候補
リポジトリ全体を調べて修正・テストまで進めたい	Codex
失敗テストやスタックトレースから原因を深掘りしたい	Claude Code
Google系のエージェントIDEでコードを見ながら直したい	Antigravity系
単発のエラー文だけ相談したい	ChatGPT / Claude / Geminiのチャットでも候補
一番エラー解決率が高いAIを知りたい	同一不具合・同一環境で実測

Codexはリポジトリ全体から修正まで進めたい場合の候補

OpenAIのCodexは、コードの作成、レビュー、リリースまでを扱うコーディングエージェントです。機能実装や複雑なリファクタリング、移行など、単一ファイルでは終わらない開発作業を前提にしています。

エラー解決でも、メッセージだけを読ませるより、実際のリポジトリを見せて「このコマンドで再現する」「関連コードを特定する」「修正後にテストする」と進める方が判断材料を増やせます。

ここで大事なのは、AIが出した修正案そのものより修正後に何を確認したかです。ビルドが通る、テストが通る、該当画面が動く、といった検証までセットにします。

Claude Codeは失敗テストやスタックトレースから原因を追いやすい

AnthropicのClaude Codeでは、公式の開発ユースケースとして「失敗したテストを修正する」が案内されています。テストファイルを読み、対象モジュールのコードパスを追い、不一致を見つけ、変更後にテストスイートを再実行する流れです。

また、公式の利用例にはスタックトレースから根本原因を探す使い方もあります。

これ、エラー解決ではけっこう大きいです。「この1行を直して」で終わらず、なぜ失敗したかをコードベース側へさかのぼる使い方が前提になっています。

ターミナルで普段からテストやログを確認しているなら、現場の作業にそのまま入りやすい候補です。

Antigravity系はGoogleのエージェント開発環境で直したい場合の候補

AntigravityはGoogle系のエージェント開発環境の候補です。利用できる機能と連携方法は公式の現行ガイドで確認します。Antigravity IDEではコードベースを理解したエージェントと会話しながら、コードの説明、生成、修正を進められます。

Google系の開発環境へ寄せたい人なら、「エラーを別チャットへコピーする」より、IDE内のコード文脈を使って調べる形が取りやすいです。

ただし、Codex・Claude Code・Antigravityのどれでも、エージェントが広い範囲を変更できるほど確認範囲も広がります。原因が分からないまま大きな修正を一括適用するより、まず再現条件と変更範囲を絞る方が安全です。

AIへ渡す情報で解決しやすさはかなり変わる

「エラー出た。直して」だけでは、AI側も前提を推測するしかありません。

最低限、

• 実行したコマンド

• エラーメッセージ全文

• 直前に変えた内容

• OSやランタイム

• フレームワークや主要パッケージのバージョン

• 再現手順

• 期待する動作

• 実際に起きた動作

を渡します。

さらに、エラーが再現するテストや最小ケースを作れるならかなり強いです。AIの回答がもっともらしくても、再現条件を満たさない修正なら採用しません。

AIものさし編集部の判断

エラー解決用途では、モデル単体の賢さより原因を調べるための文脈と、修正後の検証まで同じ流れで扱えるかを見た方が実用的です。

リポジトリ全体を見て修正・検証まで進めたいならCodex。失敗テストやスタックトレースを起点にターミナルで深掘りするならClaude Code。Google系のエージェントIDEへ寄せるならAntigravity系。

原因特定率、修正成功率、再発率、作業時間は同じ不具合で試していません。実際には「再現できたか」「修正後にテストが通ったか」を基準に評価します。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  Claude

  公式サイトを見るTool詳細を見る比較を見る

AIへ渡す「再現パック」を作る

エラー文だけでは、実行環境や直前の変更をAIが推測します。調査前に次を一つにまとめます。

• 症状：何をすると、どの画面やコマンドで失敗するか

• 期待値と実際値：どうなるはずで、何が起きたか

• 再現手順：最初のコマンドから失敗まで

• エラー全文：例外名、行番号、スタックトレース

• 環境：OS、言語・ランタイム、フレームワーク、主要依存の版

• 直前の変更：触ったファイル、設定、依存関係

• 最小ケース：単独でも失敗するテストや入力

• 試したこと：変更とその結果

まず「まだ修正しない」依頼を使います。

この失敗をまだ修正せず、再現条件と原因候補を整理してください。実行コマンド、エラー全文、直前の差分を読み、確認できた事実と推測を分けてください。足りない情報があれば質問してください。

原因候補を絞ったら、変更範囲とテストを指定します。

最も可能性の高い原因を再現テストで確かめてください。修正は関連する最小範囲に限定し、変更前に対象ファイルとテストを説明してください。修正後は同じ再現手順と既存テストを実行してください。別の挙動を変える必要があれば理由を先に示してください。

例：型エラーは値の出所から追う

TypeScriptの「Type 'string | undefined' is not assignable to type 'string'」は、未設定かもしれない値を、必須の文字列として扱う処理へ渡したときに起こる典型例です。エラー行へ非null assertionを足せば型検査は通るかもしれませんが、値がない場合の挙動は決まりません。

値がどこで作られるか、未設定が仕様上あり得るか、必須なら入力時に検出するか、任意なら処理を省くか既定値を使うか、型と実データが一致しているかを追います。正常文字列・未設定・空文字の3ケースで期待動作を定義します。単に型検査を通しただけなら、根本原因を直した証拠ではありません。

症状別の切り分け

表は横にスクロールできます

症状	まず見る場所	次の一手
コンパイル時に失敗	型、import、依存版、生成物	定義元と呼び出し元を追う
テストだけ失敗	fixture、時刻・乱数、外部依存、期待値	単体再実行し、基準ブランチと比較
ローカル成功・本番失敗	設定有無、権限、OS、ランタイム、データ差	値を出さず環境差だけ確認
実行時例外	入力、null/undefined、非同期処理	最小入力で再現し、例外経路を追う
遅い・タイムアウト	データ量、外部API、待ち時間、再試行	変更前に計測し同条件で比較
修正後に別機能が壊れる	共有処理、暗黙の依存、既存契約	変更を狭め、回帰テストを追加

ログにはアクセストークン、Cookie、顧客情報、内部URLが混ざることがあります。共有前に値を伏せ、キー名と構造だけ残してください。環境変数は実値ではなく「設定済み／未設定」と伝えます。機密コードを外部サービスへ渡してよいかは、組織ルールと契約を確認します。

修正案を採用する前の確認

• 同じコマンドで失敗が再現しなくなったか

• 既存と追加テストの両方が通るか

• 関係のないファイルや依存が変わっていないか

• エラーを隠す広いcatchや型の強制を増やしていないか

• 正常値、境界値、失敗入力を試したか

• ログに秘密情報が出ないか

• 変更を戻す手順を説明できるか

ビルド成功は必要ですが、テストを削除した、失敗条件を実行しないようにした場合は解決の証拠になりません。実行コマンド、対象テスト、省略した確認を分けて報告させます。

単発エラーの意味を聞くならチャット型でも足ります。複数ファイルやテストをまたぐなら、実リポジトリを読めるCodex、Claude Code、Antigravity系が候補です。再現できず原因が絞れないときは変更を広げず、追加ログや運用担当の確認を先にします。原因特定率の統一テストはないので、製品の成功率は順位付けしません。

原因が複数ありそうなら、一度に修正を適用せず、候補ごとに再現テストを作ります。最小再現が成功しない場合は、データ・権限・設定などコード外の条件も候補へ戻します。原因が確定できなくても、「ここまでは再現した」「この環境差は未確認」と整理できれば、次に担当者へ渡せる調査結果です。

切り分けでは、エラー表示の一行だけで原因を決めないことも大切です。発生した操作、直前の変更、入力値、環境差、再現頻度を一緒に渡します。認証やネットワーク障害なら、コードを直しても解決しません。まず再現条件を固定し、最小の変更だけ試して、同じ手順で再発するかを確かめます。

自分の条件なら？

「エラー修正だけでなく、実装、テスト、コードレビュー、PR作成まで含めてAIを選びたい」という場合は、AIものさしのかんたん診断で開発フロー全体から候補を比較できます。