906人のエンジニアが8ヶ月で乗り換えた理由。Pragmatic Engineer調査「Claude Code 46% vs Cursor 19%」を日本語で読み解く
まず調査の概要を整理します。
先週の記事で「バイブコーディングに疲れた原因はツールじゃなかった」という話を書きました。読んでくださった方から「じゃあ結局、何を使えばいいの？」という声をいくつかいただいて。
そのタイミングで、ちょうど気になるデータが出ていたんです。
Pragmatic Engineer（プラグマティックエンジニア）という、世界中のエンジニアが読む技術ニュースレターが、906人の開発者を対象にした調査を公開しました（2026年3月公開）。その結果が、なかなか衝撃的でした。
「最も気に入っているAIコーディングツール」の1位は、Claude（クロード） Code（クロードコード）で46%。Cursor（カーソル）は19%、GitHub Copilot（ギットハブコパイロット）は9%。
Claude Codeがリリースされたのは2025年5月。わずか8ヶ月で、先行していたCursorを2倍以上の差でひっくり返したことになります。
でも、私が気になったのは「46%と19%」という数字そのものではありませんでした。「なぜ乗り換えたのか」という理由のほうです。
この記事では、調査データを読み解きながら「どちらが優れているか」という論争をいったん脇に置いて、906人の開発者が行動した理由を3つの軸で整理します。結果として、自分のツール選びに使える判断基準が見えてくるはず、という記事です。
8ヶ月で逆転が起きた：Pragmatic Engineer調査とは何か
まず調査の概要を整理します。
Pragmatic Engineerは、世界で最も読まれているソフトウェアエンジニア向けニュースレターの一つです。著者のGergely Orosz（ゲルゲリ・オロシュ）は元Uberのエンジニアで、Uber・Booking.com・Microsoftなどのエンジニアリング組織の内部事情を詳細に解説することで知られています。
読者層は「プロの開発者」が中心。今回の調査（AI tooling in 2026）は2026年1月27日〜2月17日に実施され、906人から回答を得ています。
調査結果の主要数値はこちらです。
| ツール | 「最も気に入っている」割合 |
|---|---|
| Claude Code | 46% |
| Cursor | 19% |
| GitHub Copilot（コパイロット） | 9% |
| その他 | 26% |
Claude Codeがリリースされたのは2025年5月。同年末にはすでに業界で話題になっていましたが、今回の調査で「数字として」逆転が可視化された形です。
AI全体の利用状況も興味深い。調査回答者の95%が「週1回以上AIを使っている」と答え、75%が「エンジニアリング業務の半分以上にAIを使っている」と回答している。AIなしで開発している人はすでに少数派というのが、この調査の出発点でした。
さらに、70%が2〜4ツールを同時利用、15%が5ツール以上を使っています。「Claude CodeかCursorか」ではなく、「どう組み合わせるか」が現場の実態に近い。この点は後半で詳しく取り上げます。
要因①：タスクをどこまで「委任」できるか
乗り換えの理由として、調査データと現場のフィードバックから浮かびあがる1つ目の軸は「タスク委任の深さ」です。
Cursorは、VS Code（エディタ）に組み込まれたAIコーディング支援ツールです。コードの提案を受け取り、差分を確認して、ワンクリックで承認か却下を選ぶ。視覚的なフィードバックが中心で、「自分がコードを書く速度を上げる」という設計です。
Claude Codeは、ターミナル（コマンドライン）上で動くAIエージェントです。コードを書くだけでなく、gitのコミット・テストの実行・デプロイまで自律的に動きます。「コードを書く補助」ではなく「タスクを渡して完了を待つ」という設計に近い。
この違いは、使い方の感覚を大きく変えます。
Cursorを使っているとき、私は「コパイロット」という感覚です。AIが横に座って提案してくれて、採用するかどうかを自分が判断する。自分がドライバーで、AIが助手席にいる状態。
Claude Codeを使うと、感覚が変わります。「この機能を実装してほしい」とターミナルに指示を入れて、コーヒーを入れにいく。戻ってきたら、コードが書かれていてテストも通っている状態になっている。自分がPM（プロジェクトマネジャー）になって、AIが実装チームになる感覚です。
この「委任の深さ」が、どちらのツールを好むかを分けます。
「自分でコードを書いていたい」「差分を確認しながら品質をコントロールしたい」という人には、Cursorの視覚的なフィードバックが合っています。「タスクを渡して結果だけ受け取りたい」「ファイル構成やgit操作もAIに任せたい」という人には、Claude Codeのターミナル統合が強みを発揮します。
挫折エンジニアの私が正直に言うと、Claude Codeを初めて使ったときは少し怖かった。「ターミナルで何でもやる」って、昔の自分が苦手だった世界なので。でも実際に使ってみると、逆に「ターミナルを自分で操作しなくていい」ことがわかって、むしろ敷居が下がりました。
以下は、Claude Codeでの典型的な指示の流れを示すコードです。ターミナルやコードが苦手な方はここはスキップOKです。「指示を書いたら動くものが出てくる」というイメージだけ掴んでもらえれば十分です。
# Claude Codeでの典型的な指示の流れ
# ターミナルでclaudeを起動して、自然言語で指示を書くだけ
$ claude
# プロンプト例:
# 「src/api/users.tsにユーザー削除エンドポイントを追加して。
# 既存のCRUD実装に合わせたスタイルで、テストも書いて。
# 完了したらgit commitもしておいて」
# → Claude Codeが実装・テスト作成・コミットまで自動で実行する「完璧なコードより動くコードを」がスタンスの私にとって、「指示を出したら動くものが出てくる」という体験は、ブランク組のエンジニアに一番刺さる体験でした。
要因②：トークンコストの現実。33,000 vs 188,000の差
2つ目の軸は、少し技術的な話になりますが「トークン効率」です。ただ、数字だけ知ってもらえれば十分です。
開発者コミュニティで話題になった比較テストによると、同一タスクでの消費トークン数に約5.5倍の差が出たという報告があります。Claude Codeが約33,000トークン、Cursorが約188,000トークン。（この数値はコミュニティでの実測報告をもとにしており、公式ベンチマークではありません。参考値としてご認識ください）
「トークン」というのは、AIがテキストを処理する単位です（文字数のようなもの）。APIを通じてAIを使うとき、消費するトークン数でコストが決まります。
この差は、何が原因なのか。
CursorはIDEに組み込まれているため、エディタで開いているファイルの内容を丸ごとAIに送ることが多い。「コードを表示しながら提案する」という設計上、必要以上にコンテキスト（背景情報）を送り続けます。
Claude Codeはターミナルで動き、「今何が必要か」を自分で判断して最小限のコンテキストで処理します。コンテキスト長は最大100万トークンと非常に大きいですが、無駄に使わない。
APIコストが直接かかる個人開発者やスタートアップにとって、この差は財布に響きます。Claude Code Proのサブスクリプション（月額）とAPI従量課金のどちらが得かは使い方によりますが、「重いタスクをまとめて処理する」ならClaude Codeのほうがコスト効率が出やすいケースが多い。
もう一つ、コンテキスト長の話です。
大きなコードベース（複数ファイルにまたがる実装）を扱うとき、AI側がプロジェクト全体を「理解した状態」で答えてくれるかどうかが変わります。コンテキスト長が長いほど、「このファイルはどこかで参照されているの？」「この関数はプロジェクト全体でどう使われているの？」という質問に答えやすくなります。
業務ツール開発をやっている私の実感では、スプレッドシート連携のSlack Bot（数ファイル構成）くらいの規模ならCursorでもClaude Codeでも大きな差は出ません。一方、複数のAPIと連携する社内ダッシュボードを作るときは、Claude Codeの「プロジェクト全体を把握した上で答えてくれる」感覚が明らかに助かりました。
次のコードは、複数ファイルにまたがる修正の依頼例です。コードが苦手な方はスキップOKです。「複数のファイルをまとめて渡せる」というイメージが伝わればOKです。
// 例: 複数ファイルにまたがる修正を依頼する場合
// Claude Codeへの指示例
// 「src/components/Dashboard.tsxと
// src/hooks/useAnalytics.tsと
// src/api/metrics.tsをまとめて読んで、
// APIレスポンスのキャッシュ戦略を追加して」
// → Claude Codeはファイルを横断して理解し、
// 一貫性のある実装を返す
// Cursorの場合:
// 開いているファイルに対しては優秀だが、
// 複数ファイルの「全体把握」はClaude Codeに分がある「どちらが上か」ではなく「どんなプロジェクト規模で使うか」によって、コスト効率が変わる、という話です。
要因③：企業規模が決める「相性」。スタートアップ75%の理由
3つ目の軸は、企業規模と用途です。
今回の調査で、最も興味深かった分岐がここにあります。（以下の数値は、Pragmatic Engineer調査の回答者属性別の集計として報告された傾向値です。企業規模の定義や回答分布によって変動しうる点はご留意ください）
| 企業規模 | Claude Code | Cursor | Copilot |
|---|---|---|---|
| 小規模スタートアップ | 75% | 42% | 低い |
| 大企業（1万人以上） | 低い | 中程度 | 56% |
スタートアップの75%がClaude Codeを選び、大企業の56%がCopilotを選ぶ。なぜこうなるのか。
大企業には、情報セキュリティと管理の要件があります。GitHub Copilotは、GitHubのエンタープライズ契約と統合されていて、管理者がチーム全体の使用状況を把握できる。IT部門が承認しやすい形になっている。「組織で導入管理できること」が評価される環境では、Copilotが強い。
スタートアップは、速度と柔軟性を優先します。「使える人が一番いいツールを使う」という文化が多い。Claude Codeはターミナルから使えて、特別なセットアップが少ない。「とにかく手を動かしたい」という個人の開発者が、自分の判断で導入しやすい形です。
もう一つ、タスクの性質も関係します。
大企業の開発現場では、「既存の大規模コードベースに対して変更を加える」という作業が多い。コードレビューの文化があり、差分を丁寧に確認するプロセスが整っている。Cursorの「差分を視覚的に確認してワンクリック承認」という設計は、このワークフローと相性がいい。
スタートアップの初期開発では、「ゼロから何かを作る」というフェーズが多い。速く動くプロトタイプを作って、動かしながら直す。Claude Codeの「タスクを渡して完了を待つ」という設計が、このサイクルに合っています。
私のケースで言うと、カスタマーサクセスの業務ツール開発はほぼ「自分一人のプロジェクト」。コードレビューをしてくれる同僚もいない。「承認ワークフロー」よりも「動くものが出てくるかどうか」のほうが重要で、Claude Codeの設計が自分の状況に合っていました。
「大企業に所属しているけどClaude Codeを使いたい」という人は多いと思います。実態として、個人のラップトップや検証環境で使っているケースも少なくない。ただし、業務データを含むコードをAIに渡す場合は、必ず自社のセキュリティポリシーを確認してください。
次のコードは、業務ツール開発の典型例です。これもコードが苦手な方はスキップOKです。「Claude Codeに自然言語で指示を渡したら、こんなコードが出てくる」というイメージを確認したい方だけ読んでください。
# 業務ツール開発の典型例: スプレッドシート→Slack通知ボット
# Claude Codeへの指示:
# 「Google Sheetsから特定の列の値を読み取って、
# 条件を満たす行をSlackの特定チャンネルに通知するスクリプト。
# 認証情報は.envファイルから読む形で。
# ローカルで動けばOK、デプロイ不要」
# → 以下のようなコードが生成される
import os
from google.oauth2.credentials import Credentials
from googleapiclient.discovery import build
from slack_sdk import WebClient
from dotenv import load_dotenv
load_dotenv()
def check_sheet_and_notify():
# Google Sheets APIの初期化
creds = Credentials.from_authorized_user_file('token.json')
service = build('sheets', 'v4', credentials=creds)
# シートからデータ取得
sheet = service.spreadsheets()
result = sheet.values().get(
spreadsheetId=os.getenv('SPREADSHEET_ID'),
range='Sheet1!A:E' # A列からE列を取得
).execute()
values = result.get('values', [])
# 条件チェック（例: D列が「要対応」の行）
slack_client = WebClient(token=os.getenv('SLACK_BOT_TOKEN'))
for row in values[1:]: # ヘッダー行を除く
if len(row) > 3 and row[3] == '要対応':
message = f"【要対応】{row[0]}さんから問い合わせがあります（{row[2]}）"
slack_client.chat_postMessage(
channel=os.getenv('SLACK_CHANNEL_ID'),
text=message
)
if __name__ == '__main__':
check_sheet_and_notify()「動くコードが出てきた」という体験ができるかどうかが、ツールの評価を大きく変えます。業務ツール開発の初手では、Claude Codeの「タスクを丸ごと渡す」スタイルが向いています。
じゃあ、自分はどちらを使うべきか。判断基準3軸
「要因が3つ分かったけど、結局どっちにすればいいの？」という話に進みます。
「どちらが上か」という答えはありません。調査データを見ても、乗り換えた906人にとってClaude Codeが「最も気に入っている」ツールというだけで、Cursorが悪いということではない。
自分の状況を3軸で整理してみると、判断が見えやすくなります。
軸1: どんな作業が多いか
「既存コードへの追記・修正」が中心なら、Cursorの「差分確認×ワンクリック承認」が使いやすい。「新機能をゼロから作る」「複数ファイルにまたがる大きな実装をAIに任せる」なら、Claude Codeが向いています。
軸2: コードを見ながら作業したいか
「自分がコードを書いている感覚」を残したい人にはCursorが合います。「完成したものが出てくれば工程は問わない」という人はClaude Codeのほうがストレスが少ない。
軸3: 使っているエディタと職場環境
VS Codeを使っていてチームで開発しているなら、CursorはVS Codeと設定をほぼそのまま使えます。個人で開発していてエディタにこだわりがないなら、Claude Codeはターミナルだけで完結するのでセットアップが楽です。
職場のセキュリティポリシーで「GitHubエンタープライズ以外のAIツール禁止」という場合は、Copilotの一択になります。その制約がない個人開発者やスタートアップ環境なら、この3軸で選ぶ余地があります。
「どちらを選ぶか」の前に、「自分の状況」を確認するほうが先です。906人の調査データは「こういう状況の人がClaude Codeを選んだ」という参考情報であって、「Claude Codeを使わないと遅れる」という話ではありません。
マルチツール戦略の現実：70%が2〜4ツールを使っている
もう一つ、調査データで見落としやすい数字があります。
70%が2〜4ツールを同時に使っている、15%は5ツール以上。「どちらか1つを選ぶ」という前提自体が、現場の実態と少しずれています。
実際、調査の中でも「Claude CodeとCursorを組み合わせるのが理想」という声が複数あります。日常的なコーディング（IDE上での細かい修正・補完）はCursorの速度が快適で、「大きなタスクを丸ごと投げる」「複雑な設計を考えてもらう」ときはClaude Codeが強い、という使い分けです。
私も実際にそうしています。
Cursorをメインエディタにしつつ、「この機能、一から設計するのが面倒」というときだけClaude Codeに切り替える。90%の日常作業はCursorで速く進めて、重い10%のタスクをClaude Codeに任せる、というイメージです。細かい修正はCursorのほうが圧倒的に速いし、「この部分をAIがどう変えたかを目で追いたい」場面もある。逆に「仕様だけ渡して実装は任せたい」大きめのタスクはClaude Codeが楽です。一度この使い分けに慣れると、どちらか一方に戻る気にはなれないです。
この「クロスIDE設定」を統一するために、最近使われているのがCLAUDE.mdとAGENTS.mdの2ファイル戦略です。
# CLAUDE.md の例（プロジェクトルートに置く）
## プロジェクト概要
カスタマーサクセス向けの社内ダッシュボード。
Reactフロントエンド + FastAPI バックエンド。
## コーディングルール
- TypeScript strict mode ON
- コンポーネントはfunction宣言（アロー関数は使わない）
- APIレスポンスはzodでバリデーション
## 使用技術バージョン
- React 18.3.1
- FastAPI 0.115.0
- Python 3.12
## よく使うコマンド
- 開発サーバー起動: npm run dev
- テスト実行: pytest tests/ -v
- 型チェック: npx tsc --noEmit
## 注意事項
- .envファイルの値をコードに直接書かない
- APIキーはすべてos.getenv()経由で取得CLAUDE.mdをプロジェクトルートに置いておくと、Claude Codeがプロジェクト起動時に自動で読み込みます。CursorやGitHub Copilotも.cursorrulesや.github/copilot-instructions.mdという似た仕組みがあります。
どのツールを使っても「このプロジェクトのルール」を統一して伝えられる状態にしておくことで、ツールを切り替えるコストが下がります。
マルチツール戦略で実感したのは、「ツール同士は競合ではなく分業できる」ということです。Cursorの「IDE統合の速さ」とClaude Codeの「深い推論と自律実行」は、向いているタスクが違う。両方の強みを組み合わせるほうが、どちらか一方に絞るより実際の開発速度は上がります。
ただし、サブスクリプションのコストは積み重なります。Claude Code ProとCursorを両方使うと、月額で数千円〜1万円台になることもあります。「どちらか一方で十分か」という確認は、試してみてから判断するのが現実的です。どちらも無料トライアルや一定の無料枠があります。
まとめ：「乗り換え」ではなく「選択」の話
906人の調査が示したのは「Claude Codeに乗り換えるべき」という話ではありません。
「どんな状況の開発者が、何を理由にClaude Codeを選んだか」というデータです。その理由を、タスク委任の深さ・トークン効率・企業規模と用途の3軸で整理した。
先週の記事で「バイブコーディングの疲れはツールじゃなく設計の問題だった」と書きました。設計の問題が解決していないなら、ツールを変えても疲れは続きます。でも設計の問題に取り組みながら、「自分の状況に合ったツールを選ぶ」という視点は持っておく価値があります。
私が実際に使って感じた結論は、「Claude Codeは挫折エンジニアに優しい」です。
「ターミナルが怖い」という感覚があっても、「指示を書けば動くものが出てくる」体験は、ターミナルへの苦手意識を薄めてくれました。「コードがわからなくても指示の出し方でカバーできる」という感覚が、バイブコーディングの再出発点になりました。
Cursorは「コードを書ける人の速度を上げる」ツール、Claude Codeは「コードを書かなくても動くものを作れる体験を提供する」ツール。この棲み分けが、ざっくりとした私の印象です。
今週試してほしいこと3つ
- 今のツール（Cursor/Copilot）で「ここがもどかしい」と感じた場面を1つメモする。「提案を見ながら確認するのが面倒」「複数ファイルの修正が大変」「一から作るのに時間がかかりすぎる」など、ピンポイントで言語化できると次のステップが明確になります
- Claude Codeの無料枠（またはPro）で、その「もどかしいタスク」を一度投げてみる。初回は小さいタスクでOKです。「スプレッドシートのデータを整形するスクリプトを書いて」くらいから始めると、体験のコストが低い
- 結果より「指示を受け取った感触」を比べてみる。それがツール選択の出発点になる
「46%が選んだから自分も乗り換えるべき」ではなく、「自分の仕事が楽になる選択肢が増えた」という受け取り方が、一番実用的だと思っています。
挫折した経験があるから、「難しそう」という感覚は人一倍わかります。でも「指示さえ出せば動くものが出てくる」という体験を一度でもすると、その感覚は確実に変わります。906人のデータが証明しているのは、ツールの優劣ではなく、「どんな状況の人にどのツールが刺さるか」です。ぜひ自分の状況を3軸で確認してみてください。
参照:
正直、一度エンジニアは諦めました。新卒で入った開発会社でバケモノみたいに優秀な人たちに囲まれて、「あ、私はこっち側じゃないな」って悟ったんです。その後はカスタマーサクセスに転向して10年。でもCursorとClaude Codeに出会って、全部変わりました。完璧なコードじゃなくていい。自分の仕事を自分で楽にするコードが書ければ、それでいいんですよ。週末はサウナで整いながら次に作るツールのこと考えてます。
