評価軸はもう「補完精度」じゃない。Claude Code・Cursor・GitHub Copilotを6つの軸で比べ直した話

はじめに

こんにちは。メンバーズルーツカンパニーのフロントエンドエンジニアの柴田です。

以前、GitHub Copilot、Cursor、Amazon Q Developer の3つを比較した記事を書き、最終的にチームの標準ツールとして Cursor を導入したという話をお伝えしました。

しかし、あれから1年以上経ち、いまチームの標準ツールは Claude Code に移行しました。

「あれだけ Cursor を推していたのに？」と思われた方もいるかもしれません。
今回は、この1年で何があったのか、そしてなぜ最終的に Claude Code に一本化することになったのか、この記事を通してお伝えできればと思います。

なお、今回は Amazon Q Developer は比較対象から外しています。
前回の試用以降は使用しておらず、最新情報を持ち合わせていない状態では、正確な比較ができないためです。

また、GitHub Copilot と Cursor に関する評価は、実際に契約して使用していた当時の仕様に基づくものです。
両ツールとも料金体系の大幅な変更があったように、私が使っていた頃と比べて大きく機能や仕様が変わっている可能性が大いにあるため、その点はあらかじめご了承ください。

この1年の変化

前回記事を執筆した頃、AI コーディングツールはまだ「補完ツール」程度のレベルでした。
GitHub Copilot や Cursor のエージェントモードも登場してはいましたが、私の評価基準はあくまで「コード生成や補完の精度」や「コードベースの理解力」が中心で、ツールは基本的に人間が指示を出し続ける前提のものでした。

この1年の変化を一言で言うなら「補完ツール」から「エージェント」へのパラダイムシフト、といった感じかなと思います。

以前は Cursor を使っていても、数行単位でコードを読み込ませて修正を依頼する、または機能ごとに個別で実装を進めるといった使い方が中心でした。
ところが、今は実装してほしい機能と仕様を渡したらあとは自律的に計画を立てて実装を進める形に変わってきています。

ハーネスエンジニアリングと呼ばれる領域(エージェントに何をどう任せるかの設計の部分)自体もどんどん進化しており、以前ほど細かくコードをチェックしなくても安心して任せられるようになりました(もちろん、最終的なコードの確認は今も人間が行っていますよ)。

この変化に伴い、前回記事の5つの評価基準ではもはやツールの実力を正しく測れなくなってきていると感じました。
そこで今回は評価基準そのものを作り直すところから始めています。

新しい評価基準(6軸)

「エージェントとしてどれだけ自律的に、かつ拡張性を持って開発を進めてくれるか」という観点を軸に、以下の6つの基準で改めて比較しました。

• 自律性・エージェント性能
  • どこまで自律的にタスクを遂行できるか
• 拡張性・エコシステム(MCP対応など)
  • 外部ツール・データソースとの連携のしやすさ
• コードベース／プロジェクト理解力
  • プロジェクト全体を踏まえた提案ができるか
• 使いやすさ(ワークフロー適合性)
  • 日々の開発フローにどれだけ自然に組み込めるか
• コスト
  • 料金体系と実際の使用感
• セキュリティ
  • 企業導入における安全性・管理のしやすさ

前回の基準と比べると、「コード生成や補完の精度」という単独項目がなくなり、代わりに「自律性・エージェント性能」と「拡張性・エコシステム」を新たに追加しました。
これは、もはや個々の補完精度よりも「どこまで任せられるか」「何と繋がるか」が大事になってきているいまの潮流に合わせたものになっています。

評価基準に沿った詳細比較

実際に使ってみた項目ごとの評価を表にまとめました。

それぞれ、ざっくりとした印象は以下の通りです。

• Claude Code
  • 自律性とエコシステムの広さが頭ひとつ抜けている
• GitHub Copilot
  • GitHub のエコシステムとの連携や、企業向けセキュリティ管理の手堅さ
• Cursor
  • GUI ネイティブな体験の快適さ、タスクに応じた複数モデルの選択性

自律性・エージェント性能

Claude Code を使い始めた当初に感動した部分は、タスクを渡した後の「任せられる範囲」の広さです。
実装してほしい機能と仕様さえ渡せば、計画を立て、複数ファイルにまたがる変更を実行し、途中で発生した懸念点まで自律的に報告してくれます。

以前のように、数行単位で修正を依頼したり、機能ごとに細かく指示を出したりする必要があまりなくなりました。

GitHub Copilot・Cursor もそれぞれエージェントモードを備えており、複数ファイルにまたがる変更を自然言語で指示できる点は同様です。
ただ、タスクを最後まで自律的にやり切り、かつ人間の確認頻度を減らせるという意味では、この1年の使用感としては Claude Code の自律性が頭ひとつ抜けている印象です。

拡張性・エコシステム(MCP対応)

MCP(Model Context Protocol)自体はオープンな汎用規格なので、正直なところ「Claude ならではの MCP」という差別化できる要素はあまりないかな、といったところです。

チームで一番活用しているのは、Figma のデザインを MCP 経由で読み込み、そこからコンポーネント実装やページ実装まで一気通貫で進めるパターンですが、チームで Claude を導入したタイミングでは Claude の hooks などがうまく動作できており、その点では Claude Code に軍配が上がりました。

ただ、現在はGitHub CopilotにもCursorにも同様の機能があるためそこも各社足並みは揃っている印象です。

コードベース／プロジェクト理解力

前回記事では、Cursor が「まだ一度も import していないコンポーネントに対しても適切な import 文を提案してくれた」という文脈理解力の高さを決め手の一つに挙げていましたが、この1年でモデル性能そのものが底上げされたこともあり、この領域の理解度は各ツールとも大きく向上しています。

現在の Claude Code は、当時の Cursor 以上にプロジェクト全体を理解した上でコードを書いてくれる感覚がありますが、これが「Claude Code だから」なのか「モデルの進化そのもの」なのかは正直切り分けが難しいところです。

現行の GitHub Copilot・Cursor がどこまで進化しているかは実際に触れていないため分からないため、この項目についてはフェアに見るなら「両者とも高いレベルにある」というのが正確なのかなと思います。

使いやすさ(ワークフロー適合性)

ここは Claude Code にとって一番の弱点だと感じている部分です。
私含め、チームメンバーは基本的に GUI での操作に慣れているため、CLI メインの Claude Code に移行した当初はかなり戸惑いがありました。
正直なところ、今でも完全に慣れたかと言われると微妙な部分があります。

とはいえ、tmux や並列実行支援ツールを使って複数セッションを同時に起動したり、Ghostty のペイン分割を活用したりと、CLI ならではの運用スタイルも定着してきました。一方で、VS Code 拡張やデスクトップ版を使う場面も依然として多く、「GUI がもっと使いやすくなってくれれば」という気持ちは正直あります。

対して GitHub Copilot・Cursor はどちらも使い慣れたエディタにそのまま統合される形なので、導入直後からの使いやすさという点では今でも一日の長があると感じています。

コスト

3ツールとも、この1年で料金体系が大きく変わりました。

GitHub Copilot は 2026年6月1日に、プレミアムリクエスト単位からトークン消費量に基づく「GitHub AI Credits」制へ移行しました。基本のサブスクリプション価格自体は据え置きですが、エージェントモードやチャット、コードレビューなどの利用がトークン量に応じて課金されるようになり、実質的に使える範囲が狭まったと感じています。

Cursor も 2025年6月に、固定リクエスト数から「プラン料金と同額のクレジットプール」を消費する方式に移行しています。これは前回記事を書いた時期とほぼ同時期の変更で、その後半年ほど使い続けた実感としては、月の途中でクレジットを使い切ってしまい、業務に支障が出ることが度々ありました。

Claude Code は Claude の Pro / Max / Team プランに含まれる形で利用でき、チームでは Team プランのスタンダードシートを契約しています。Team プランなので支払いが一括管理できるのはありがたいポイントです。
Claude Code の利用上限は「5時間ごとのローリングウィンドウ」と「週単位の上限」という組み合わせになっています。この仕組みが個人的には気に入っていて、仮に上限に達してしまっても5時間経てばまた使えるようになりますし、週明けにはリセットされます。
Cursor のように、月単位で貰えるクレジットを使い切ってしまうと追加課金するか翌月のリセットまで待つしかない、という詰み方はしません。
「今日は上限まで使ってしまったけど、昼過ぎにはまた動かせる」という安心感は日々の開発を進めるうえで大きなメリットだと思います。

厳密な費用対効果の比較は使用量に依存するため一概には言えませんが、「決まった範囲で安心して使い切れるか」という部分の安定性では Claude Code に軍配が上がった形です。

セキュリティ

Claude Code は、入力したコードが学習に利用されない旨が明記されている点が安心できるポイントです。
導入した時期にはすでに国内の大手企業でも採用が進んでいたこともあり、社内稟議の面でも大きな障壁なく導入できました。

SSO 対応などもできるため、セキュアな管理体制を敷ける点も評価しています(実際の運用管理は情シス部門が行っているため、細かな設定までは私は把握していませんが…)。

GitHub Copilot・Cursor も、プライバシーモードや SSO 対応など企業利用に耐えるセキュリティ機能を備えておりこの軸については3ツールとも大きな差はないというのが正直な印象です。

なぜ Claude Code に乗り換えたのか

最終的にチームメンバーに導入するツールを Claude Code へ乗り換えた決め手は、大きく2つあります。

1. 自律性の高さ
2. コストの面

Claude Codeに乗り換える最初のきっかけは「世間の風潮」でした。

当時、Zenn をはじめとする技術記事の多くが Claude Code の紹介で埋め尽くされており、「Cursor や GitHub Copilot よりも Claude Code だろう」という空気が流れていて、まずはその流れに乗ってみよう！ということで導入が始まりました。

1ヶ月ほど使い続けてみて、hooks とサブエージェントの良さに気づき、hooks で lint を自動実行させるようにしているほか、サブエージェントを計画担当・実装担当・レビュー担当といった形でタスクごとに切り分け、オーケストレーションのような形で開発を進めるようになっていきました。

この「1人のエージェントに全部任せる」のではなく Claude の自律性の高さを活かした「役割ごとにエージェントを組み合わせる」という拡張の仕方が、GitHub Copilot・Cursor にはない Claude Code ならではの強みだと感じたところが大きな理由になっています。

ただし現在ではGitHub CopilotもCursorも、サブエージェントを組み合わせた開発フローを組めるようになっているため、当時の感想であるというところには注意が必要です。

そしてコストの面でも Claude Code は素晴らしかったです。
GitHub Copilot も Cursor も、この1年で固定リクエスト数からクレジット制・トークン課金へと移行し、上限に達すると追加課金するか次の請求サイクルまで待つしかない、という制約が強くなりましたが、一方で Claude Code は5時間ごとのローリングウィンドウと週単位の上限という組み合わせで、上限に達してもすぐにリセットされるため、日々の開発フローを止めずに済みます。

Cursorと変わらない値段で、手を大きくは止めることなく開発を進められるのも大きな理由の1つでした。

GitHub Copilot・Cursor から離れた理由

前述の通り、クレジット制への移行でこれまで使えていた利用量が大幅に減る見込みとなったことが直接的なきっかけです。
月の途中でクレジットを使い切ってしまうことが度々発生し、業務の進行に支障が出るようになったことで、「本当にGitHub Copilot・Cursorを使い続けるべきなのだろうか」という疑問が生じ、別のツールへの移行の検討が始まったという流れがあります。

また、私たちの開発環境自体が GitHub に強く依存しているわけではなかったため、GitHub Copilot の最大の強みであるはずの GitHub エコシステムとの連携を十分に活かしきれていなかった、という背景もあります。

はっきりいって、ユーザー体験としては今でも Cursor が一番快適だったと感じています。というのも、エディタから直接編集を依頼できたり、GUI にネイティブに統合されたエージェントモードがあったりと、CLI ツールに慣れていない私やチームメンバーからすると Cursor の体験はとても良かったと今でも思っています。

それでも、自律性とクレジットの安定性という業務上の利益を優先し、Claude Code への一本化を選びました。

導入前の期待 vs 導入後の実際

前回記事では、Cursor 導入にあたって4つの効果を期待していました。
1年経った今、Claude Code を使い続けている実績をベースにして振り返ってみます。

開発速度の向上

開発速度は Cursor の時と比べてさらに向上しました。

以前は数行単位で細かくコード編集を依頼していた部分も、今はコード全体を把握した上で自律的に実装を進めてくれます。

加えて、途中で懸念点を自発的に伝えてくれるため、品質担保やセキュリティリスクの低減という副次的な効果も感じています。
参照するコードの一貫性も上がり、実装のばらつきも以前より減った印象です。

コード品質の向上

こちらも実感として向上しています。
ただし、これは Claude Code そのものの機能というより、Skills の追加やハーネス自体の見直しなど、開発手法そのものが変化したことによる部分が大きいと感じています。

後から機能を追加することを見越した実装や、拡張性を考慮した提案をしてくれるようになったことが結果的にコード品質の底上げにつながっています。

技術的負債の削減

上記と繋がるところではありますが、拡張性を前提とした実装提案が増えたことで後から手を入れる際の負債が積み上がりにくくなってきた実感があります。

チーム全体のスキル向上

社内で Claude Code の勉強会を開催したり、ナレッジシェアを行ったこともあり、チームメンバーもうまく Claude Code を活用できるようになってきている気がします。

ツール単体の効果というより、こうした運用の工夫も含めての成果かなと思います。

まとめ

1年前、私たちは「プロジェクト全体の文脈理解力の高さ」「自然言語による柔軟な指示」「導入ハードルの低さ」を理由に Cursor を選びました。
その選択自体は当時の判断としてチームにあっていたと今でも思います。

ただ、この1年で開発ツールに求められる価値は「補完の精度」から「どこまで自律的に、拡張性を持って任せられるか」へと明確に変化したと考えています。

その変化の中で、hooks やサブエージェントによる拡張性、そして自律性の高さという実務上の利点を最も強く感じられたのが Claude Code でした。

もちろん、GitHub Copilot の GitHub エコシステムとの連携力がありますし、Cursor の GUI ネイティブな体験の快適さは今も十分魅力的だと思います。
特にエディタに統合された体験の心地よさという点では、Cursor は今でも捨てがたい選択肢かなと。

とはいえ、エージェントの自律性を重視する開発現場においては、現時点で Claude Code が頭一つ抜けているというのが、1年使ってみての結論です。

なお、この記事の執筆時点では ChatGPT の Codex の性能も上がってきているという話も耳にしています。AI コーディングツールをめぐる競争は、この1年でむしろさらに激化していると感じています。

どのツールを選ぶにせよ、大事なのはツールが常に進化し続けているという前提で、いつでも最新の情報を追いかけながら、チームのニーズに合わせて柔軟にツール選定を見直していくことだと思います。

この記事が、皆様のツール選定の一助になれば幸いです。