CursorがIDEの外に出てきた — TypeScript SDKでエージェントが「インフラ」になる

Cursorといえばエディタだ。コードを書くための場所であり、対話する相手であり、開発者が毎日開くアプリケーション。

だが4月29日に出たものは、エディタではない。

Cursor SDK（@cursor/sdk）は、Cursorのエージェントランタイムをプログラムから呼び出すためのTypeScriptパッケージだ。npm install @cursor/sdk してコードを15行ほど書けば、Cursorのデスクトップアプリやクラウドエージェントと同じAIが、自分のスクリプトの中で動き始める。

何が変わるのか

これまでCursorのAIエージェントを使うには、Cursorのアプリを開く必要があった。IDEの中で会話し、IDEの中で結果を受け取る。それ以外の方法はなかった。

SDKが出たことで、その制約がなくなる。

CI/CDパイプラインの中でエージェントを起動してPRの自動修正をかける。Slackのボットからエージェントを呼び出してバグレポートに対応させる。cronジョブで定期的にコードベースを巡回させて技術的負債を検出する。こういったことが、Cursorのモデルとツールチェーンを使いながら実現できる。

Rippling、Notion、Faire、C3 AIがすでに本番環境で稼働させているという。パブリックベータの段階でエンタープライズが動いているのは、需要の裏付けとして十分だ。

3つの実行モード

SDKには3つのデプロイメントモードがある。

ローカル実行は開発者のマシン上でエージェントを動かす。手元のリポジトリに対してテストスクリプトを回したいとか、デバッグ中に対話的にエージェントを使いたいといった場面向け。セットアップが一番簡単で、npm install して即動く。

クラウド実行はCursorのインフラ上の専用VMでエージェントが動く。リポジトリがクローンされ、サンドボックス環境でコードの読み書きとテスト実行ができる。自分のマシンのリソースを消費しないので、大量のタスクを並列で流すならこちらが適している。

セルフホスト実行はエンタープライズ向け。自社ネットワーク内にワーカーを立てて、コード実行を外部に出さずにエージェントを運用できる。金融やヘルスケアなど、コードが社外に出せない業界ではこれが唯一の選択肢になる。

この3段階の設計は素直に上手いと思う。個人開発者から大企業まで、規模やセキュリティ要件に応じて同じSDKのまま移行できる。

料金 — トークン従量課金

SDKはシートベースの課金ではなく、トークン消費量に応じた従量課金を採用している。

デフォルトモデルのComposer 2はインプット$0.50/M、アウトプット$2.50/Mで、Claude Opus 4.7（$5/$25）と比べると約10分の1。エージェントを大量に走らせるCI/CDワークフローでは、この価格差がかなり効いてくる。

もちろんComposer 2以外のモデル（Claude、GPT-5.5など）も選択可能だが、その場合は各モデルの正規料金が適用される。コスト最適化を考えるなら、Composer 2で十分な精度が出るタスクにはComposer 2を使い、難しいタスクだけフロンティアモデルに回す、という使い分けが現実的だろう。

Claude CodeやCodex CLIとの違い

同じ「プログラムから呼べるAIコーディングエージェント」として、AnthropicのClaude CodeやOpenAIのCodex CLIが競合になる。

Claude Codeはターミナル常駐型で、開発者との協調作業に強い。対話しながらコードを修正していくスタイルに最適化されている。一方Cursor SDKは対話よりもバッチ処理・自動化に寄っている。「人間の横で一緒に書く」よりも「バックグラウンドで勝手に仕事をしてくれる」方向だ。

Codex CLIもタスクを投げて結果を受け取るスタイルだが、Cursor SDKが独自に持っているのはコードベースインデックスの統合だ。セマンティック検索やインスタント grep がエージェント内部で使えるため、大規模リポジトリでの精度が高くなりやすい。

正直なところ、どれが最良かはユースケース次第。既存のCI/CDにAIを組み込みたいならCursor SDK、日常の開発フローで使いたいならClaude Code、ChatGPTエコシステムに揃えたいならCodex、という棲み分けになるだろう。

何が実現できるのか

SDKの活用パターンで面白いのは、MCP（Model Context Protocol）サーバーとの連携だ。外部のデータソースやツールをMCPで接続し、エージェントに「データベースの状態を見てマイグレーションスクリプトを書け」といったタスクを投げることができる。

スキルファイル（.cursor/skills/）の読み込みにも対応しているので、プロジェクト固有のルールや手順書をエージェントに食わせた状態でタスクを実行できる。たとえば「うちのプロジェクトではテストは必ずこの書き方で」というルールを定義しておけば、エージェントが自動生成するテストもそのルールに従う。

将来的にはサブエージェント機能で、1つのタスクを複数のエージェントに分解して並列処理させることも想定されている。大規模なリファクタリングやマイグレーションを、数十のエージェントが手分けして進める。まだ実験段階だが、実現すれば開発のスケーリングの考え方が根本から変わる。

気になる点

パブリックベータということもあり、ドキュメントはまだ薄い。公式ブログの記事とSDKのREADMEが主な情報源で、エッジケースの処理やベストプラクティスは手探りになる。

また、Cursor独自のランタイムに依存するため、ロックインのリスクがある。今日Cursor SDKで書いたコードは、そのまま別のプラットフォームに移植できない。この点はClaude CodeやCodex CLIのようなモデルAPI直呼びのアプローチのほうが柔軟性は高い。

とはいえ、コードベースインデックスやスキルの統合といったCursor独自の強みは確かにある。ロックインを受け入れてでもその体験を取るか、汎用性を重視して別の選択肢を選ぶか。チームの状況次第だ。