Windsurf 3 vs Cursor 2026：Apple Silicon リソース使用量の比較実測

「動く」と「安定して動く」は別問題

M シリーズ Mac への Windsurf や Cursor のインストールは数分で済む。公式サイトにも「ネイティブ Apple Silicon 対応」とある。 しかし実務で差が出るのは長時間の高負荷だ。コンテキストウィンドウを 128K token まで広げ、 Agent に十数ファイルを同時改修させ、xcodebuild を走らせながら AI にクラッシュログを解析させる—— このとき 16 GB ユニファイドメモリが枯渇するか、索引スレッドがコンパイルとパフォーマンスコアを奪い合うかが、 日常開発で最初にぶつかる壁になる。

機能比較記事はモデル一覧や拡張機能エコシステム、料金に焦点を当てがちだ。 本記事が答えるのはもっと実務的な問い：同一の物理 Mac 上で、2 つのツールはそれぞれどれだけのシステムリソースを消費し、ボトルネックはどのタスクで発生するか。 8 GB や 16 GB メモリのノート PC を使っている場合、この結論はクラウド専用ノードへの移行判断に直結する。

テスト手法と比較可能性の担保

AI IDE のパフォーマンスは単一ベンチマークでは測れない。索引、補完、チャット、Agent はそれぞれ異なるサブシステムを通る。 ワークロードを 4 段階に分割し、各段階で両ツールを5 回実行して中央値を取り、ピーク値と定常値を記録した。

1. 01
   アイドル定常（Idle）

   リポジトリを開いた後 10 分間放置し、AI リクエストを発行しない。常駐メモリとバックグラウンド CPU を記録。

2. 02
   フル索引（Index）

   ローカル索引キャッシュを削除してプロジェクトを再オープン。起動から「索引完了」通知までの時間とメモリピークを計測。

3. 03
   大規模コンテキスト Q&A（Chat 128K）

   40 ファイル以上にまたがるアーキテクチャ説明を選択し、「モジュール依存を説明し循環参照を検出せよ」という質問を送信。初 token 遅延と総所要時間を記録。

4. 04
   Agent 複数ファイル改修（Cascade / Composer）

   指示：「REST クライアントを async/await に統一し、12 呼び出し箇所と対応テストを更新せよ」。改修ラウンド数、ディスク書き込み量、IDE のカクつき主観評価（1–5）を記録。

モデルティアは可能な限り揃えた。Windsurf は SWE-1 シリーズのデフォルトルーティング、Cursor は同クラスの Claude Sonnet 互換モデル（Max モードなし）。 ネットワーク遅延は同一ノード出口で測定し、家庭用回線の変動を排除。物理マシン専用帯域により、索引時の依存関係取得も隣接テナントの影響を受けない。

アイドルと索引：常駐型か、バースト型か

10 分間のアイドル後、Cursor 2026 の常駐メモリは約 1.9 GB（Electron メインプロセス + 言語サービス含む）、バックグラウンド CPU 平均 < 2%。 Windsurf 3.0 は約 1.6 GB、バックグラウンド CPU 平均 < 1.5%。差は小さいが、Windsurf は Cascade パネルを閉じるとサブプロセスをより徹底的に解放し、1.4 GB 付近まで低下する。 Cursor の Tab 補完サービスはやや高いベースラインを維持する。

索引フェーズで差が顕著になる。キャッシュクリア後のフル索引：Windsurf 3.0 は 3 分 41 秒、メモリピーク 5.8 GB。 Cursor 2026 は 4 分 12 秒、ピーク 6.4 GB。 どちらも一時的に 4 つのパフォーマンスコアを占有するが、Cursor は TypeScript 言語サービスと ripgrep の並行時にエフィシェンシーコアまで引き上げ、 3 分以内に筐体表面温度が約 4°C 上昇。Windsurf の索引スレッドスケジューリングはより集中し、温度曲線は急だが回復も速い。

1 日に 3〜4 リポジトリを切り替える場合、索引時間とメモリピークは「起動コスト」として累積する。 Windsurf はやや速く、やや省メモリ。9 万行の Go monorepo で別途テストしたところ差は 20 秒以内に縮小し、 索引器の大ファイル戦略が異なることがわかる——単一の数値だけで判断すべきではない。

大規模コンテキストチャット：初 token とメモリの崖

128K コンテキストをフル活用すると、メモリ曲線に「崖」が現れる。Windsurf の定常値は約 7.2 GB、 質問送信後 3 秒で 9.1 GB まで上昇。Cursor の定常値は 7.8 GB、ピーク 9.6 GB。 16 GB マシン単体では安全圏内だが、Chrome で 30 タブ、Docker Desktop、Xcode を同時起動すると memory_pressure が黄色ゾーンに入り、補完遅延が 80 ms 級から 300 ms 級以上に悪化する。

初 token 遅延（ネットワーク RTT 控除後）：Windsurf 中央値 1.8 秒、Cursor 2.1 秒。 完全な回答生成（約 1,200 語の技術説明）：Windsurf 38 秒、Cursor 41 秒。 差の主因はモデルそのものではなくコンテキストパッキング戦略——類似のクラウドモデル使用時、ボトルネックはローカルシリアライズと UI レンダリングに偏る。

Agent 複数ファイル改修：スループット、ロールバック、ディスク IO

Agent シナリオはプロダクト思想の差が最も出る。Windsurf 3 の Cascade は小さなステップでコミット、各ステップをプレビュー可能という傾向。 上記 async/await リファクタは 4 ラウンドで完了、総時間 2 分 54 秒、12 ファイル + 6 テストを改修、ディスク書き込み約 380 KB、途中で 2 回手動確認。 Cursor 2026 の Composer Agent はより攻撃的で、1 ラウンドで 14 ファイルを提案、総時間 2 分 21 秒だが型エラーで 1 回フルロールバックが必要で、実質的な「有効推進」時間は Windsurf と同等。

CPU 面では Agent 稼働中どちらも 6〜8 スレッドを占有。Windsurf の言語サービスプロセス CPU ピーク約 280%、Cursor 約 340%（マルチスレッド合計）。 メモリピーク：Windsurf 8.7 GB、Cursor 9.3 GB。 主観カクつき評価（1=スムーズ、5=明確なフレーム落ち）：Windsurf 2.2、Cursor 2.6——diff プレビューアニメーションと大量の inline suggestion が同時表示されると Cursor の方が落ちやすい。

制御可能でレビューしやすい段階的マージを重視するなら Windsurf の Cascade が Code Review 文化に合う。 単一指示で可能な限り多くのファイルを変更したいなら Cursor Composer のスループットが高いが、誤修正への対応時間を見込むべきだ。 M4 上ではどちらも「使えない」わけではなく、メモリ余裕と操作リズムの違いが本質である。

発熱、ファン、ノート PC バッテリーの隠れコスト

Mac mini にバッテリーはないため、コア温度センサーと消費電力推定で「ノート PC 体験」を等価評価した。 15 分間の Agent タスク継続：Windsurf の平均パッケージ消費電力約 12 W、Cursor 約 14 W。 CPU パフォーマンスコア平均使用率は Windsurf 45%、Cursor 52%。 14 インチ MacBook Pro M3（16 GB）で同一 Agent タスクを再テストすると、100% から 80% までの所要時間は Windsurf 47 分、Cursor 39 分—— Cursor の方が高消費電力で、より高い CPU 占有率と一致する。

ファン戦略では Mac mini は両 IDE とも低回転を維持。ノート PC では Cursor Agent ピーク時に聴こえるファン音があり、Windsurf はやや静か。 リモートワークで Mac をデスクトップマシンとして VNC 経由で使う場合、クラウド Mac mini にはファン騒音の悩みがなく、 7×24 で索引と CI を走らせる運用形態にも向く——ローカルノート PC が苦手とする使い方だ。

ワークフロー別選定：絶対的な勝者はいない

上記データを決定木に圧縮すると、おおよそ次のようになる。

Windsurf 3.0 を優先する条件：① メモリ ≤ 16 GB で複数アプリを常時起動；② Cascade による段階的レビューが必要； ③ 索引ピークとアイドル占有をやや抑えたい；④ VS Code 系拡張を使っており移行コストを下げたい。

Cursor 2026 を優先する条件：① Composer で一度に多ファイル改修、偶発的ロールバックを許容； ② Tab 補完とカスタム Rules を深く使う；③ Background Agent や Bugbot など Cursor エコシステムに既に投資； ④ メモリ ≥ 24 GB、または AI とコンパイルを時間分割運用。

どちらも Apple Silicon 上でネイティブ動作し、「M チップでは特定メーカーしか使えない」という問題はない。 本当の制約はユニファイドメモリの予算と並行タスク数だ。 機能は四半期ごとに変わるため、自分のメインリポジトリで索引と Agent シナリオを再テストする方が、単一ベンチマークを信じるより実用的である。

ローカルメモリが足りないとき：AI 重負荷をクラウド Mac へ

実測で最も多かったフィードバックは「Cursor と Xcode を同時に開けない、16 GB では無理」というものだ。 新しいノート PC は数千ドルかかり、更新サイクルも長い。8 GB のクラウド VPS では完全な macOS と Apple ネイティブ IDE は動かない。 より現実的な選択は：AI コーディングとコンパイルを常時オンラインの専用 Mac mini に載せ、 ローカルはブラウザと会議アプリだけにし、VNC または SSH でリモートデスクトップを操作することだ。

PixVPS は物理 Mac mini M4 を専用提供：仮想化なし、オーバーセルなし。16 GB メモリと 1 Gbps 帯域が丸ごと利用可能で、 支払い後 1–5 分で自動開通。シンガポール、東京、ソウル、香港、米国東部の 5 ノードから選択できる—— 日本国内チームは東京ノードで VNC 遅延を最小化しやすい。北米チームとの協業なら米国東部が向く。 日額 $21.1、週額 $57.1、月額 $105.7。長期契約なしで、リリース週や大規模リファクタ週だけ専用 AI ワークステーションを借りる使い方に合う。

典型的な構成：クラウド Mac に Windsurf または Cursor + Xcode をインストールし、ローカルの 8 GB 軽量ノートからブラウザ VNC で接続。 Agent 索引と xcodebuild がクラウド側でリソースを消費し、ローカルのファンを酷使しなくなる。 監査と隔離が必要なら OpenClaw サンドボックスで Agent のファイルシステム範囲を制限し、本番キーの誤改修を防げる。 複数人で使う場合は開発者ごとに独立ノードを開くか、シフト制でレンタルする方が、共有オフィス Mac より権限トラブルが少ない。

1. 01
   近いノードを選んで開通

   PixVPS コンソールから注文し、SSH と VNC 認証情報を取得。遅延テストはヘルプセンターの接続ガイドを参照。

2. 02
   IDE をインストールしリポジトリを同期

   git clone または rsync で monorepo をクラウドに配置。初回索引はクラウドで完了させ、ローカルでメモリを二度消費しない。

3. 03
   ローカルは軽量接続、重いタスクはクラウド

   日常は VNC で AI IDE を操作。実機デバッグが必要なときだけローカル Xcode でシミュレータに接続——またはクラウド上のシミュレータ画面をそのままストリーミング。

Windsurf と Cursor の Apple Silicon 上での差は、多くの場合数十秒の時間差、数百 MB のメモリ差のオーダーだ。 本当にストレスになるのは 16 GB マシンでの swap とファン回転である。 選定時はまず自分のワークフローに合わせ、AI 専用にクラウド物理 Mac を用意するかを判断する—— 「どちらのマーケティングが強いか」を悩むより、1 週間の実効コーディング時間を伸ばしやすい。