去年の11月、僕が担当しているNext.js + Prismaのプロジェクトで大規模リファクタリングが走った。コードベースは45,000行くらい、バックエンドAPIが80本以上、チームは5人。そのタイミングで「どのAIアシスタントを全員に統一するか」という話が出て、それなら自分でちゃんと試してみようと思った。
結果的に約2ヶ月、GitHub Copilot（Business）、Cursor（Pro）、Claude Code（Max）を並行して使い、同じタスクを意図的に各ツールで処理した。完璧なA/Bテストではない——実務だから当然タスクの種類にばらつきがある——でも、「実際の開発者が毎日使ったらどうなるか」という観点では、それなりにリアルなデータが取れたと思っている。
評価のやり方と、最初に犯したミス
正直に言っておくと、「コード補完の速度」だけで比べようとしたのは間違いだった。
初週に各ツールのレイテンシを計測するスクリプトを書いて満足していたんだけど、速度なんて正直どれもほぼ同じだ——ネットワーク環境への依存が大きいし、体感で差を感じることはほぼない。本当に差が出るのは、どれだけ意図を正確に読み取れるかとコンテキストをどう扱うかだと気づくのに1週間かかった。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は応答が長くなりがちで、急いでいるときは少しノイズに感じることもある。プロンプトで「箇条書きで簡潔に」と毎回書けば改善するけど、それが地味に手間だった。慣れたら苦じゃなくなるんだけど、最初の2週間は少しストレスがあった。
チームへの展開で気づいた現実
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/月。5人チームだと月5万円近い差が出る。「生産性向上で回収できるか?」——試験期間中に明確なROIを数値化できなかった、というのが正直なところだ。定性的には「Claude Codeが一番深く考えてくれる」という感想は複数出たが、それが月5万円分かと言われると断言できない。チームの状況と予算次第としか言えない。
2ヶ月使った後の正直な推薦
「チームによります」は言いたくないので、自分の判断を書く。
コードベースが複雑で、リファクタリングや設計議論に時間を使う場合はClaude Code。コストは飛び抜けて高いが、コンテキスト理解の深さと「ちゃんと考えて提案してくれる感」は他の2つとは別格だった。ただし、チーム規模が大きくなるほどコストの正当化が難しくなる。費用対効果に確信が持てないなら次の選択肢に行く。
チームのIDEがバラバラ、または展開のしやすさを優先するならCopilot Business。品質は他に劣る部分があるが、VS CodeとJetBrainsで同じ体験を提供できるのはCopilotだけだった。JetBrainsユーザーがいるならこれ一択に近い。
個人でとりあえず試したいならCursor。$20でコストパフォーマンスはいい。@codebaseを使いこなすまでの学習コストも大きくない。プロジェクトが45,000行を超えてくるとインデックスの問題が出てくることは頭に入れておくこと。
どのツールを選んでも共通して言えるのは、プロジェクトの文脈を教える手間を省くなということ。CLAUDE.mdでも.cursorrulesでも何でもいいけど、アーキテクチャと命名規則と「やってはいけないこと」を書いておくだけで、補完の質が体感で変わる。それをせずに「AIが使えない」と言うのは、新人に何も説明しないで仕事させるようなものだ。
3ヶ月後にはこのレポートの内容が古くなっているかもしれないし、各ツールも今も更新し続けている。ベンチマーク記事を読んで判断するより、自分のコードベースで1週間試すほうが正確な答えが出る。