Claude Code と Cursor の使い分け — 他人のベンチマークではなく自分の環境で測る

「初回正解率78%」を信じて選び、外した話

去年、AIコーディングツールを選ぶときに、比較記事に並んでいた数字をそのまま判断材料にしました。初回正解率が何パーセント、単純タスクは何パーセント高速。数字が並んでいると、それだけで検討した気分になれます。

実際に自分のリポジトリで動かしてみると、その数字はほとんど当たりませんでした。原因は明快で、ベンチマークで使われたタスクと、私が毎日やっている作業がまるで違ったからです。Kotlin の Android アプリと Next.js のブログを行き来する私の仕事は、どのベンチマークにも入っていません。

数字が嘘だったわけではないと思います。ただ、他人の測定環境で出た数字は、自分の環境の予測にはなりません。

ここでは Claude Code と Cursor を、出所の確認できる事実と、自分で測るための手順に絞って整理します。私が実際に両方を並行で使いながら決めた境界線も添えました。

設計思想の根本的な違い

Claude Code は Anthropic が提供するエージェント型のコーディングツールです。ターミナル、VS Code、JetBrains、デスクトップアプリから利用でき、タスクを渡すとファイルの読み書き、コマンド実行、Git 操作まで自律的に進めます。開発者の役割は「何をしてほしいか」を伝えて、結果をレビューすることに寄ります。

Cursor は VS Code ベースの AI ネイティブ IDE です。エディタ内に AI が深く統合されており、タブ補完・インラインチャット・エージェントによるコード生成を、開発者がリアルタイムで確認しながら進めます。人間が操縦席に座り続けるスタイルです。

# Claude Code: ターミナルからタスクを渡す
claude "このプロジェクトにユーザー認証を追加してください。
       JWT ベースのログイン・ログアウト・トークンリフレッシュと、
       それぞれのテストまでお願いします。"
# → ファイルを作成・編集し、テストを実行するところまで自律的に進む
 
# Cursor: エディタ内でインラインチャットを使う
# Cmd+K で開き、選択範囲に対して「この関数にエラーハンドリングを追加」と指示
# → 差分がインラインで表示され、Accept / Reject で適用

この違いは好みの問題ではなく、レビューをいつ行うかの違いです。Claude Code は完了後にまとめてレビューし、Cursor は一手ごとにレビューします。自分がどちらのリズムで集中を保てるかは、ベンチマークでは測れません。

コンテキストと、モデルの選び方

Claude Code で Pro / Max / Team / Enterprise プランを使う場合、Sonnet 5・Opus 5 をはじめとする現行世代のモデルで100万トークンのコンテキストウィンドウが利用できます（Pro で Opus 系の100万トークンを使うには usage credits の有効化が必要です）。これは正式提供済みの機能で、長いコンテキストに対する追加料金もありません。数百ファイルにまたがるリファクタリングで整合性を保ちやすいのは、この土台のおかげです。

Cursor はプロジェクト全体をインデックス化しますが、1リクエストで扱えるコンテキスト量は選んだモデルに依存します。そのかわり @codebase や @file で必要なファイルをピンポイントに指定できる操作性があり、狙いが定まっている作業では速いです。

モデル選択の自由度は Cursor に分があります。Claude、GPT、Gemini などを切り替えられる設計で、タスクの性質に応じて選べます。Claude Code は Anthropic のモデルを基盤としつつ、Sonnet 5 と Opus 5 の使い分けでコストと品質のバランスを取り、MCP を通じて外部ツールと連携します。

エージェント機能と、Hooks の書き方

Claude Code の自律実行は、Hooks による自動化と組み合わせたときに効いてきます。ここは公式ドキュメントの記法を取り違えたまま運用している例をよく見かけるので、正しい形を確認しておきます。

// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "if": "Bash(git commit *)",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/pre-commit-check.sh"
          }
        ]
      }
    ]
  }
}

構造は3段です。イベント名（PreToolUse）、発火条件を絞る matcher グループ、そして実際に走る hook ハンドラの配列。ここでよくある取り違えが2つあります。

ひとつは、matcher に Bash(git commit*) のようなパーミッションルール記法を書いてしまうこと。matcher が照合するのはツール名だけです。英数字・アンダースコア・ハイフン・空白・カンマ・パイプ以外の文字が入ると JavaScript の正規表現として扱われるため、Bash(git commit*) は Bash というツール名に一度もマッチせず、フックは静かに動かないままになります。コマンドの中身で絞りたいときは、ハンドラ側の if フィールドを使います。

もうひとつは、ハンドラのキーを "hook" と書いてしまうこと。正しくは "hooks" という配列で、各要素は type と command を持ちます。

そして、PreToolUse でツール実行を止めたいときは終了コード 2 です。

#!/bin/bash
# .claude/hooks/pre-commit-check.sh
npm test && npm run lint || {
  echo "テストまたはリントが通っていません" >&2
  exit 2   # 2 だけがツール呼び出しをブロックする
}
exit 0

終了コード 1 はブロックになりません。Claude Code は 1 を「ブロックしないエラー」として扱い、そのまま処理を続けます。慣習的に 1 を失敗として書いてしまうと、ゲートを置いたつもりで素通りする状態が生まれます。私はこれを本番で一度やりました。

Cursor もエージェントモードでターミナルコマンドの実行やファイル編集を自動化できます。ただし差分確認のステップが入るぶん、無人での完走という点では Claude Code のほうに寄ります。

「約12%高速」という数字が自分に転用できない理由

冒頭の話に戻ります。AIコーディングツールの比較で見かける「単純タスクは約12%高速」「初回正解率78%対73%」といった数字は、測定条件を書かずに引用された時点で、判断材料としての価値をほぼ失います。

理由は3つあります。

第一に、モデルが数週間単位で入れ替わります。測定時点のモデルと、あなたが今日使うモデルが同じである保証はありません。第二に、タスク集合が違います。ベンチマークの「単純なバグ修正」は、たいてい単一ファイル・単一言語です。自分の仕事がそうでないなら、その比率は転用できません。第三に、リポジトリの形が違います。設定ファイルの散らばり方、テストの実行時間、型定義の厚み。これらは所要時間に直接効きますが、ベンチマークでは平準化されています。

「何%」という数字を見たら、測定日・モデル名・タスク一覧・試行回数のどれが書かれているかを確かめてください。書かれていないなら、その数字は自分の環境に対しては何も言っていません。

自分のリポジトリで測るための最小手順

では何を見るか。私は、自分の直近のコミットからタスクを作って測るという方法に落ち着きました。他人のベンチマークより手間はかかりますが、自分の環境で出た数字なので判断に使えます。

まず、比較に使うタスクを自分の git 履歴から拾います。ちょうどよい大きさの過去コミットを探すスクリプトです。

#!/bin/bash
# pick-bench-tasks.sh — 直近の履歴から「比較タスク」候補を抽出する
# 変更が 2〜8 ファイル、40〜400 行程度のコミットが扱いやすい
 
git log --no-merges --since="3 months ago" --format='%H %s' | while read sha subject; do
  files=$(git show --stat --format='' "$sha" | tail -1 | grep -oE '^ [0-9]+' | tr -d ' ')
  lines=$(git show --numstat --format='' "$sha" | awk '{a+=$1+$2} END {print a+0}')
  [ -z "$files" ] && continue
  if [ "$files" -ge 2 ] && [ "$files" -le 8 ] && [ "$lines" -ge 40 ] && [ "$lines" -le 400 ]; then
    printf '%s\t%sファイル\t%s行\t%s\n' "${sha:0:8}" "$files" "$lines" "$subject"
  fi
done | head -20

抽出したコミットの1つを選び、その親コミットにチェックアウトして、コミットメッセージを指示文としてツールに渡します。答えが git 履歴に残っているので、出力の妥当性を自分で判定できます。これがこの測り方のいちばんの利点です。

計測は、所要時間とトークン消費の2つを取ります。Claude Code 側はセッションのコストが取得できます。

#!/bin/bash
# run-bench.sh <親コミットSHA> <指示文>
PARENT="$1"; PROMPT="$2"
WT="../bench-$(date +%s)"
 
git worktree add "$WT" "$PARENT" >/dev/null 2>&1
cd "$WT" || exit 1
 
START=$(date +%s)
claude -p "$PROMPT" --output-format json > result.json
END=$(date +%s)
 
echo "所要秒数: $((END - START))"
# Claude Code の JSON 出力にはセッションのコストが含まれる
python3 - <<'PY'
import json
d = json.load(open("result.json"))
print("コスト(USD):", d.get("total_cost_usd", "n/a"))
print("ターン数:", d.get("num_turns", "n/a"))
PY

同じ親コミットに対して Cursor でも同じ指示文を投げ、体感ではなく秒数と金額を並べます。3タスクほどでも、自分がどちらに寄せるべきかの傾向は見えます。

大事なのは、勝敗を出すことではありません。「自分の典型的な作業では、どちらでも大差がなかった」という結果もよくあります。それが分かれば、比較記事を読み続ける時間を止められます。

料金は、金額より「課金の形」を見る

金額そのものは変わりやすいので、比較すべきは構造のほうです。2026年9月時点で公開されている情報を並べると、次のようになります。

読み方はこうです。高性能モデルを頻繁に叩くなら Cursor のクレジット消費速度を、長時間まとめて回すなら Claude の週次上限を基準に比べると実態に近づきます。金額が同じ $20 でも、使い方によって先に尽きる場所が違います。

最新の数字は Claude の料金ページと Cursor の料金ページ、API 単価は Claude Platform の Pricing ドキュメントでご確認ください。この種の数字は記事よりも公式のほうが速く更新されます。

どちらに寄せるかの目安

• Claude Code に寄せる — 数十ファイルにまたがる移行が多い、ターミナル中心で作業している、SSH 先や Docker コンテナ内で動かしたい、CI に組み込みたい
• Cursor に寄せる — VS Code の拡張機能資産を手放したくない、タブ補完のリズムで書きたい、複数モデルを切り替えたい、差分を目で追いながら進めたい

どちらも当てはまる、という方が実際には多いはずです。その場合は次の節をご覧ください。

並列作業をどう見せるか、という新しい軸

ここ数か月で、比較の軸がひとつ増えました。複数エージェントの並列実行です。

Cursor は複数の AI エージェントを同時に走らせ、進捗をひとつのビューにまとめて確認できる方向に進んでいます。クラウド実行に対応しているのでローカルマシンに負荷がかからず、GUI で並列作業を見渡したい方には魅力的です。

Claude Code は見せ方が違います。git worktree で複数ブランチを同時に走らせ、SubAgent がタスクを分割して並列に進み、Hooks がツール実行の前後に処理を挟みます。可視化ではなく、パイプラインへの組み込みやすさに寄った設計です。この構成の具体的な組み方は「Claude Code のマルチエージェント並列実行 — Task ツールと SubAgent の実装パターン」に、worktree 側の運用は「Claude Code worktreeで並列開発を加速する」にまとめています。

なお、この節についても「どちらが何倍効率的」といった数字は書きません。並列実行のトークン消費はモデル選択とタスク分割の仕方で大きく変わり、他人の1タスクの結果は自分の運用の予測になりません。前の節の測り方を、並列実行にもそのまま使えます。

併用するなら、先に「役割の境界」を決めてください

「両方使えばいい」という結論は、そのままでは実務で機能しません。私が最初に失敗したのは、同じブランチで Claude Code に大きめのリファクタを任せながら、Cursor で別のファイルを直していたときでした。互いの前提が食い違ったまま差分が積み上がり、最後にコンフリクトの山を手で解くことになります。

いま採用しているのは、作業の長さで割り当てを分ける方法です。

• Claude Code に渡す仕事: 数十ファイルにまたがる移行、テストの追加、依存関係の入れ替えなど、着手から完了まで人が見ていなくてよいもの
• Cursor で行う仕事: 関数ひとつの書き換え、命名の調整、レビュー中に気づいた小さな修正など、目の前で結果を確かめたいもの

そして、この二つを同じ作業ツリーで同時に走らせません。Claude Code には git worktree で切った別ディレクトリを渡し、Cursor は元のワークツリーに残します。これだけでコンフリクトはほとんど消えました。

もう一段踏み込んで3ツールに分けたときの記録は「Claude Code × Cursor × Devin Desktop（旧 Windsurf）のハイブリッド開発環境」にまとめています。

ツールの優劣を比べる時間より、境界を決める30分のほうが、結局は生産性に効きました。

次にやること

この記事から持ち帰っていただきたいのは、ツールの結論ではなく手順のほうです。

自分の git 履歴から2〜3個タスクを抜き、親コミットにチェックアウトして、同じ指示文を両方に投げます。秒数と金額を並べます。それだけで、他人のベンチマークを何本読むより確かな判断材料が手に入ります。所要時間はおそらく1時間ほどです。

私自身、この測り方に切り替えてから、ツール選びで迷う時間がはっきり減りました。同じところで足踏みしている方の役に立てば嬉しいです。