AIを活用してツール開発をしていると、想像以上にスムーズに進む場面があります。
CursorやAntigravityのような開発支援ツールに要望を伝えると、画面や機能を作り、エラーを見て、修正案を出し、次の作業まで進めてくれます。
以前なら自分で調べ、コードを読み、原因を探し、試行錯誤していた作業を、かなりの速度で進められるようになりました。
ただし、AI開発支援にはひとつ大きな落とし穴があります。
何度やっても直らないバグにぶつかったとき、同じAIの中だけで粘り続けると、どんどん視野が狭くなることがあります。
そんなときは、別のAIに聞く。
これは、AIを使ったツール開発ではかなり大事な考え方だと思います。
AIは「分かりません」とはなかなか言わない
開発支援AIは、とても頼もしい存在です。
エラーが出れば原因を探ります。ログを読みます。関連ファイルを確認します。仮説を立て、修正を提案し、実装まで進めます。
この流れ自体は非常に便利です。
ただ、AIは人間の開発者のように「これは今の情報だけでは分からない」「この方向では厳しいかもしれない」とは、なかなか言いません。
むしろ、何らかの仮説を立てて前に進もうとします。
それがうまくいくことも多いです。
しかし、仮説が外れている場合、似たような修正を何度も繰り返すことがあります。
ログを見ている。コードも読んでいる。修正もしている。なのに直らない。
AIは一生懸命やっているのに、問題の核心には届いていない。
こういう場面は、AI開発では決して珍しくありません。
同じAIの中で粘るほど、原因が固定されることがある
バグ対応では、最初に立てた仮説がその後の調査を引っ張ります。
たとえば、「状態管理の問題ではないか」と考え始めると、その方向の修正が続きます。
「CSSの競合ではないか」と考えれば、表示まわりの調査に寄っていきます。
「APIレスポンスの形式が違うのでは」と考えれば、データ構造ばかりを見るようになります。
もちろん、それで解決することもあります。
でも、最初の仮説がずれていた場合、どれだけ丁寧に作業しても遠回りになります。
AIは文脈を引き継いで作業してくれるため、便利な反面、同じ方向に考え続けてしまうこともあります。
人間側が「これは違うのでは」と感じたら、一度流れを切ることも必要です。
別AIに聞くと、前提がリセットされる
行き詰まったときに有効なのが、別のAIに相談することです。
たとえば、開発作業はCursorやAntigravityで進めているとして、詰まったバグについてはGemini、ChatGPT、Claudeなど別のLLMに聞いてみる。
ここで大事なのは、単に「このバグを直して」と聞くことではありません。
現在起きている症状、環境、エラーメッセージ、試したこと、関連しそうなコード、使っているライブラリやフレームワークをまとめて渡します。
そのうえで、次のように依頼します。
- 既知の問題がないか調べる
- 似た症状の原因を複数挙げる
- こちらの仮説以外の可能性を出す
- 調査順序を提案する
- 最小再現の作り方を考える
- 修正前に確認すべきログや設定を整理する
別AIに聞くメリットは、今の開発AIが抱えている文脈から一度離れられることです。
別の角度から見ることで、見落としていた前提や、調べるべき既知の問題に気づけることがあります。
Deep Research系の使い方は、バグ調査と相性がいい
解決が難しいバグでは、既知の問題を調べることが重要になる場合があります。
特定のライブラリのバージョン。
ブラウザやOSとの相性。
フレームワークの仕様変更。
APIの制限。
過去のissueやフォーラムで報告されている不具合。
こうした情報は、コードだけを見ていても分からないことがあります。
GeminiのDeep Researchのように、横断的に情報を集めて整理できる機能は、この場面で役立ちます。
AIに「直してもらう」のではなく、「調査資料を作ってもらう」と考えると使いやすいです。
その調査結果を、開発中のAIに読ませる。
すると、開発AIは新しい前提や候補を持った状態で、改めて原因を切り分けられます。
これは、人間の開発でもよくある「別の人に見てもらう」「詳しい人に聞く」「issueを調べ直す」に近い使い方です。
別AIに渡す情報は整理した方がいい
別AIに聞くときは、情報の渡し方がかなり大事です。
ただエラーメッセージだけを貼っても、的外れな回答になることがあります。
最低限、次の情報を整理して渡すとよいです。
- 何を作っているのか
- 期待している動作
- 実際に起きている不具合
- エラーメッセージやログ
- 使っている技術、ライブラリ、バージョン
- すでに試した修正
- 試した結果どうなったか
- これ以上やりたくない方向
特に「すでに試したこと」は重要です。
これを書かないと、別AIも同じ提案を返してくる可能性があります。
また、「原因をひとつに決めつけず、可能性を優先度順に並べてほしい」と頼むのも有効です。
バグ調査では、最初から正解を当てることより、調査順序を間違えないことが大切だからです。
開発AIに戻すときは、資料として渡す
別AIから得た回答は、そのまま人間が読んで終わりにしない方がよいです。
開発作業をしているAIに、調査資料として読ませます。
たとえば、
「この調査結果を読んで、現在の実装に関係しそうなものを優先度順に確認してください」
「この候補のうち、既存コードで検証できるものから順に見てください」
「まだ修正せず、まず確認項目をリストアップしてください」
のように依頼します。
いきなり修正させるより、まず確認項目に落とす方が安全です。
別AIの調査結果も、必ず正しいとは限りません。
だからこそ、開発AIにそのまま実装させるのではなく、仮説として扱い、確認してから修正する流れにした方がよいです。
LLMは開発そのものより、問題解決の情報整理に強いことがある
AIにコードを書かせると、速く形になります。
ただし、難しいバグや複雑な環境依存の問題では、ひとつのAIだけで解決しようとすると詰まることがあります。
LLMは、コードを書くこともできます。
しかし、それ以上に強いのは、情報を整理し、仮説を並べ、調査の方向性を広げることかもしれません。
人間がすべてのissueやドキュメントを読み切るのは大変です。
AIに横断的に調べてもらい、候補を整理してもらう。
そのうえで、人間が判断し、開発AIに検証させる。
この組み合わせは、かなり実用的です。
ひとつのAIで頑張りすぎない
AI開発支援を使っていると、どうしても目の前のAIに解決してもらおうとします。
何度も修正を依頼する。
ログを追加する。
別の実装を試す。
それでも直らない。
そんなときは、同じAIの中で粘り続けるより、一度外に出た方がよい場合があります。
別AIに聞く。
公式ドキュメントやissueを調べ直す。
最小再現を作る。
仮説を並べ直す。
AIを使った開発では、この切り替えがとても大切です。
AIに任せることと、AIを使い分けることは違います。
複数のAIを、開発担当、調査担当、レビュー担当のように役割分担させると、行き詰まりから抜け出しやすくなります。
まとめ
AIを活用したツール開発では、ひとつのAIだけで頑張り続けないことが大切です。
開発AIは、実装、修正、ログ確認を進めるのに向いています。
一方で、解決しないバグにぶつかったときは、別AIに調査させることで、新しい視点や既知の問題にたどり着けることがあります。
Gemini、ChatGPT、Claudeなどを、単なる会話相手ではなく、問題解決の調査役として使う。
その調査結果を開発AIに渡し、確認項目に落とし、慎重に修正する。
この流れができると、AI開発支援はかなり実用的になります。
大事なのは、一つのAIに固執しないこと。
AIを使うほど、人間側の役割は「どのAIに何を聞くか」「どこで流れを切り替えるか」を判断することになっていきます。
