SalesforceがCursorを「デフォルトのコーディングエージェント」に指定した。対象は25年分のコードベースを抱え、世界中で毎日新製品をリリースするエンジニア組織だ。
「ゼロからイチだ」——VP of Engineeringはそう表現した。大げさではなかった。
Salesforceとは何者か
Salesforceは世界最大級のCRMソフトウェア企業だ。営業管理ツールを中心に、マーケティング・カスタマーサービス・データ分析などを提供するSaaS企業で、世界15万社以上が使っている。2024年度の売上は350億ドル超。エンジニアリング部門だけで数万人規模の組織だ。
重要なのは「25年以上のコードベース」という点だ。Salesforceは1999年創業。四半世紀分の積み重ねが、今も現役のコードとして稼働している。新しく入ったエンジニアが「このコードは何をしているのか」を理解するだけでも、膨大な時間がかかる。
数字を解剖する
cursor.com/blog/salesforce（2026年1月21日公開）が示すデータは明確だ。
- エンジニアの**75%**が日常ワークフローでCursorを使用
- PR velocity（PR処理速度）: 30%超の向上
- cycle time・bug count・throughputの3指標: いずれも二桁パーセントの改善
- レガシーコードのテストカバレッジ作業時間: 85%削減（1チームの事例）
「二桁」は10%以上を意味する。具体的な数値（15%なのか20%なのか）は非公開だが、PRを処理する速度が30%速くなり、バグが二桁パーセント減り、スループットが二桁パーセント上がった——これは「使ってみたら便利だった」レベルの話ではない。
Shan Appajodu（SVP of Engineering at Salesforce）の言葉がある。
"It's 0 to 1 in terms of how Cursor has transformed the way our developers use tools to improve quality."
「0から1」というのは、エンジニアが品質向上のためにツールを使う姿勢そのものが変わった、という意味だ。改善度合いではなく、次元が変わったと言っている。
採用がどう広がったか
Salesforceの全社展開は「命令」ではなかった。有機的な拡散だった。
最初に飛びついたのはジュニアエンジニアだ。パンデミック期間中に入社したエンジニアたちは、オフィスでの先輩からの直接指導が少なかった。25年分のコードベースを把握する機会が制限されていた世代だ。
倉庫で例えるなら、25年分の書類が詰まった部屋に一人で放り込まれた状態だ。Cursorはその倉庫の全体マップを見せてくれる地図になった。
# ジュニアエンジニアの活用パターン（初期）
"この25年分のコードベースを理解したい。
このファイルが何をしているか説明して、
似たパターンを他のファイルで探して"
一方、シニアエンジニアは入口が違った。「退屈で手間のかかるタスク」から始めた。テンプレートの生成、クエリの書き直し、繰り返しの整形作業——AIにやらせていい仕事から信頼を積み上げていった。
# シニアエンジニアの活用パターン（初期）
"このQ4パフォーマンステストテンプレートを自動生成して。
Splunkダッシュボードのクエリも書き直してほしい"
使った人が「これは良い」と周囲に伝える。火が燃え広がるように、数ヶ月以内に組織全体へ広がった。コードカバレッジのメトリクスにも現れた——エンジニアがユニットテストをより多く生成するようになったのだ。
Salesforce Engineering Blogには、CursorとCodeGenieが「デフォルトのコーディングエージェント」として公式に指定された経緯が記されている。
なぜCursorだったのか
Salesforceはもちろん、Cursorを選ぶ前に比較をした。なぜGitHub Copilotではなかったのか。
設計思想の違いが大きい。GitHub Copilotは「既存のIDEに追加するプラグイン」として設計されている。補完の精度は高く、VS CodeやJetBrainsにシームレスに統合できる。エンタープライズ向けガバナンス機能も充実しており、Microsoft製品との連携を重視する企業には有力な選択肢だ。
Cursorは「AIを中心に再設計されたIDE」だ。コードベース全体をコンテキストとして持ち、複数ファイルを横断した編集や、コードベース全体への質問に答えられる。
「補佐役か相棒か」で言えば、Copilotは有能な補佐役、Cursorは一緒にコードベースを歩き回れる相棒に近い。
Salesforceのような「25年分のコードベース」「複数クラウドにまたがる大規模組織」という文脈では、ファイル単体の補完よりも、コードベース全体を理解しながら動けるCursorが合っていた。
GitHub Copilotが適している場面もある。Microsoft/GitHubとの既存契約がある、Azure DevOps統合が必須、SOCコンプライアンスがすでに通っている——こういった条件が揃っているならCopilotが有力だ。ツールの善悪ではなく、文脈の問題だ。
Salesforceだけではない
Salesforceの事例が注目を集めるのは、それが例外ではないからだ。
cursor.com/blog/nvidiaによると、NVIDIAでは30,000人の従業員がCursorを使用しており、コミット数が3倍になった。
Stripeでは、Patrick Collisonが全エンジニアのマシンにCursorをプリインストールした。採用率はシングルデジットから80%超へ跳ね上がった。
BoxのCursorケーススタディは、エンジニアの85%以上が毎日Cursorを使用し、ロードマップ処理速度が30〜50%向上、マイグレーション工数が80〜90%削減されたと報告している。
cursor.com/enterpriseが示すマクロな数字もある。Fortune 500の64%がCursorを導入し、50,000社以上の企業が使っている（2026年時点）。ARRは20億ドル超に達した（2026年2月時点）。
これらはいずれも、「試しに入れてみた」ツールの数字ではない。組織の開発フローに組み込まれた結果だ。
エンタープライズ導入の壁
ただし「大企業がやっているなら自社でもすぐできる」という話ではない。
SalesforceやNVIDIAが全社展開できた背景には、セキュリティレビューとガバナンス整備がある。Salesforceは顧客データを扱うSaaS企業だ。AIツールにコードを送信することへのセキュリティ審査、SSO（シングルサインオン）によるアクセス管理、利用状況のモニタリング——これらを整えた上での展開だ。
小規模チームなら、これらの整備コストは相対的に小さい。問題は中規模以上の組織だ。「使いたい人が個人で契約して使う」段階から「組織として統一的に管理する」段階への移行に、相応の準備が必要になる。
CursorはエンタープライズプランでSSOやセキュリティポリシーの一元管理を提供している。それでも「入れたら終わり」ではなく、利用ガイドライン策定・データ取り扱いポリシーの更新・既存ツールとの統合が必要になる。
AIツールをコードベースへのアクセス権付きで導入する場合、コード補完の送信先と保持期間を確認すること。エンタープライズプランでは通常、コードのAI学習への使用を無効化できる。個人プランのデフォルト設定とは異なる場合がある。
「まだ始まりに過ぎない」
Shan Appajouはこう締めくくった。"We're really just at the beginning."
Salesforceはまだ探索段階だ、と言っている。コードの記述から、要件定義・設計・テスト・デプロイまで——ソフトウェア開発ライフサイクル全体にAIを統合する実験が続いている。
25年分のコードベースを持ち、毎日新製品をリリースし、世界中の顧客データを扱う組織が「これはまだ序章」と言う。それがどういう意味を持つか、考える価値はある。
Money Forwardの1,000人展開がエンジニア以外への波及を示したとすれば、SalesforceとNVIDIAとStripeの事例は「エンジニア生産性の数値化」を示した。ツールが成熟するほど、計測可能な指標で話せるようになる。その流れはこれからも続く。