先週、AIコーディングアシスタントを使って
3つのファイルにまたがる機能を一気に実装した。
動いた。テストも通った。その日はそれで満足した。
翌日、別のファイルから同じロジックを呼び出そうとして気づいた。
自分で書いたコードなのに、何をしているのか追えない。
AIが生成したコードは確かに正しかった。でも、プロジェクト全体の
文脈を知っているのはAIではなく自分のはずなのに、
なぜかAIの方が「全体を知っているふり」をしていた。
問題はAIではなく「どのAIを使うか」だった
あとから気づいたのは、使っていたツールが「今開いているファイル」しか見ていなかったということです。
プロジェクト全体の依存関係、命名規則、型定義——
これらを理解した上で提案できるツールと、
現在のファイルだけを見て補完するツールでは、
複数ファイルにまたがる開発での結果が全然違います。
G2が20以上のツールを評価した結果でも(https://learn.g2.com/best-ai-coding-assistants、この「コンテキスト認識」の差が実際の開発体験を最も左右する要因として繰り返し挙げられています。G2が20以上のツールを評価した結果でも、この「コンテキスト認識」の差が
結局どのツールが違いを生むのか
試行錯誤の末にわかったのは、ツールごとに「得意な文脈の広さ」が違うということです。
-
Cursor はプロジェクト全体を参照した提案が得意で、
複数ファイルの編集でも一貫性が崩れにくい - Claude は大きなコードベースごと渡して設計の問題を聞く使い方で真価を発揮する
- GitHub Copilot はリポジトリ内のパターンを読んだ補完が安定している
- Amazon Q Developer はAWS環境でインフラとアプリをまたぐ文脈に強い
どれが「最高」かではなく、自分のプロジェクトの構造に合うかどうかが選ぶ基準です。
翌日の自分が読めるコードを書くために
AIに任せる範囲を広げるほど、ツールの「文脈理解力」が重要になります。