去年の11月、僕が担当しているNext.js + Prismaのプロジェクトで大規模リファクタリングが走った。コードベースは45,000行くらい、バックエンドAPIが80本以上、チームは5人。そのタイミングで「どのAIアシスタントを全員に統一するか」という話が出て、それなら自分でちゃんと試してみようと思った。
約2ヶ月、GitHub Copilot（Business）、Cursor（Pro）、Claude Code（Max）を並行して使い、同じタスクを意図的に各ツールで処理した。完璧なA/Bテストではない——実務だから当然タスクの種類にばらつきがある——でも、「実際の開発者が毎日使ったらどうなるか」という観点では、それなりにリアルなデータが取れたと思っている。
評価のやり方と、最初に犯したミス
最初に正直に言っておくと、「コード補完の速度」だけで比べようとしたのは間違いだった。
初週に各ツールのレイテンシを計測するスクリプトを書いて満足していたんだけど、速度なんて正直どれもほぼ同じだ（ネットワーク環境に依存する部分が大きい）。本当に差が出るのは、どれだけ意図を正確に読み取れるかとコンテキストをどう扱うかだと気づくのに1週間かかった。
なので評価軸を3つに絞った:
- 補完の適切さ — 提案されたコードをそのまま使えるか、それとも大幅に修正が必要か
- コンテキスト理解の深さ — 離れたファイルの型定義や既存のパターンを把握しているか
- デバッグ支援の質 — エラーの根本原因まで辿り着けるか
チームメンバー5人からの感想も隔週で集めた。完全に非科学的なんだけど、数字に出てこない「なんかモヤモヤする」という不満を拾うには意外と役に立った。
コード補完: 「量」より「信頼できるか」
Copilotは今でも補完候補の量は多い。ファイルを開いた瞬間から積極的に提案してくる。でも、僕が2ヶ月で一番ストレスを感じたのはここだった——自信満々に間違ったコードを出してくる。
具体的な例を挙げると、Prismaのトランザクション処理を書いていたとき、Copilotが提案したコードがこれ:
// Copilotの提案 (一部改変して匿名化)
const result = await prisma.$transaction(async (tx) => {
const user = await tx.user.update({
where: { id: userId },
data: { credits: { decrement: amount } },
});
// ここが問題: creditが0未満になってもエラーにならない
const order = await tx.order.create({
data: { userId, amount, status: 'PENDING' },
});
return { user, order };
});
一見正しそうに見える。でも僕のプロジェクトでは「クレジットが足りない場合はトランザクションをロールバックする」というビジネスロジックが必要だった。Copilotはその制約を知らないから当然だとも言えるけど、コードが動くように見えるから見落としやすいという点が厄介だった。見た目が「正しいコード」すぎるのが一番怖い。
Claude Codeの場合、同じ箇所で「creditの残高チェックはしなくていいですか?」と聞いてきた。既存のコードベースにあるInsufficientCreditsErrorクラスを見ていたからだと思う。
Cursorは中間くらい。@codebaseでインデックスを使えば精度が上がるが、プロジェクトが大きいとインデックス更新が遅れることがある（うちの環境では45,000行で体感3〜4分かかることがあった）。
補完候補の多さで選ぶより、プロジェクトのコンテキストをどれだけ把握できるかで選んだほうがいい。特に既存パターンへの追従精度は、チームの統一スタイルを維持するうえで思いのほか重要だった。
コンテキスト理解: ファイルを超えて考えられるか
これが一番差が出た領域だった。
うちのプロジェクトはモノレポ構成で、packages/coreに共通ロジック、apps/apiとapps/webが別々にある。あるAPIエンドポイントのバグを追っているとき、根本原因がpackages/coreの型定義の微妙なズレにあった——Nullable<T>とT | nullを混在させていたやつ。
Cursorはこれを割と早く見つけた。@codebaseと@Docsを組み合わせたプロンプトで、関連ファイルを横断して調査してくれた。ただ、たまに関係ないファイルもコンテキストに引き込んで、トークン上限に引っかかることがあった。
Claude Codeは少し違うアプローチで、/initでプロジェクト構造を把握させてから作業させると、どのツールよりもコードの「意図」を読むのが上手かった。CLAUDE.mdにアーキテクチャの説明を書いておく手間は必要だけど、一度設定すれば毎回説明しなくていい。
Copilotはコンテキスト理解が正直弱い。VS Code上での動作は快適だが、複数ファイルにまたがる問題はCopilot Chatに切り替えて追加の説明をしないといけないことが多かった。これが思ったより面倒だった。
一個おもしろかったのは、テストコードの生成精度。既存のテストファイルのパターンを読んで同じスタイルで書いてくれるかどうかを試したんだけど、Claude Codeが一番忠実だった。うちはVitest + @testing-library/reactを使っているんだけど、既存テストのdescribeブロックの構造やモックの書き方をほぼそのまま踏襲してくれた。
// 既存テストのパターン (抜粋)
describe('useCredits', () => {
const mockUser = createMockUser({ credits: 100 });
beforeEach(() => {
vi.clearAllMocks();
mockAuthStore.setState({ user: mockUser });
});
it('should decrement credits after successful order', async () => {
// ...
});
});
// Claude Codeが同じパターンで生成した新しいテスト
// createMockUser, mockAuthStore など既存のヘルパーを自動的に使ってきた
// ——これは正直助かった
デバッグ支援: スタックトレースから根本原因まで
ここが「毎日使うとどれだけ時間を節約できるか」に直結する部分だ。
全部のツールで同じようなスタックトレースを投げてみたとき、最初の回答の質はどれも似たようなものだった。差が出たのは、追加の質問を重ねたときの精度だ。
あるNext.js App RouterのRoute HandlerでInternal Server Error 500が出て、スタックトレースが役に立たない状況があった（Prismaの接続エラーが本当の原因だったんだけど、表面上はまったく別のエラーが出ていた）。
Copilot Chatは最初の提案でPrismaの接続設定を確認するよう言ってきたが、具体的な診断手順がなかった。自分でDATABASE_URLを確認して、prisma db pullしてみて… という作業を手動でやった。
CursorはEdge Runtimeの制約について早い段階で言及してきた。実際、うちのRoute HandlerがedgeランタイムになっていたのにPrismaクライアントが対応していないという問題で、これはCursorが一番早く気づいた。
Claude Codeには少し違う使い方をした——エラーログだけじゃなくてRoute Handlerのコード全体とnext.config.tsも一緒に渡した。そうしたら、serverExternalPackagesの設定漏れまで指摘してきた。これは自分では気づかなかったと思う。
ただ、Claude Codeは応答が長くなりがちで、急いでいるときは少しノイズに感じることもある。プロンプトの書き方で改善できる——「3行以内で答えて」と書くだけで全然違う——けど、慣れるまでに少し時間がかかった。
チームへの展開で気づいた現実
5人のチームで各ツールを試してもらった感想で一番多かったのは、「結局自分のワークフローに合わせられるかどうか」だった。
IDEへの依存度でいうと:
– Copilot: VS Code/JetBrains前提。拡張機能として完成度が高く、既存環境を変えたくない人に向いている
– Cursor: VS Codeフォーク。慣れると便利だが、会社の端末でのインストール制限が問題になることがある（うちはなかったが）
– Claude Code: ターミナルベース。VSCode拡張もあるが、CLIとして使うとgit操作も含めてタスクを任せられる
チームメンバーの1人がJetBrains派で、Cursorを渡したら「これ慣れるのに時間かかるな…」という反応だった。IDEの移行コストは思ったより小さくない。
コストの話も正直にしておく。Copilot Businessが1ユーザー$19/月、CursorのProが$20/月、Claude CodeのMaxが$100/月。Claude Codeが頭一つ抜けて高い。5人チームだと月5万円近い差が出る。これを「生産性向上で回収できるか?」は、チームの状況による——少なくとも僕のチームでは、試験期間中に明確なROIを数値化できなかった。これは正直に言っておく。
2ヶ月使った後の正直な推薦
曖昧な「チームによります」は言いたくないので、僕なりの判断を書く。
個人開発者または小規模チームで、コードベースの複雑さが高い場合: Claude Codeを使う価値がある。コストは高いが、コンテキスト理解の深さと「ちゃんと考えて提案してくれる感」は他のツールより上だった。特にリファクタリングや設計の議論に使うと差が出る。
5人以上のチームでIDEの統一が難しい場合: Copilot Businessが無難。品質は他に劣る部分があるが、展開のしやすさと安定性は一番高い。JetBrainsユーザーがいるならなおさら。
個人でとりあえず試してみたい場合: Cursorを2週間使ってみる。$20でコストパフォーマンスはいい。ただ、プロジェクトが大きくなるとインデックスの問題が出てくることは頭に入れておいたほうがいい。
最後にひとつだけ付け加えると、どのツールを選んでもプロジェクトの文脈をちゃんと教える手間を省くなということ。CLAUDE.mdでも.cursorrulesでも何でもいいけど、アーキテクチャと命名規則と「やってはいけないこと」を書いておくだけで、補完の質が体感で変わる。それをせずに「AIが使えない」と言うのは、新人に何も説明しないで仕事させるようなものだと思っている。
3ヶ月後にはこのレポートの一部が古くなっているかもしれない——ツールのアップデートが速すぎるので。ただ「どういう軸で評価するか」は変わらない。自分のチームで試す際の参考にしてもらえれば。