Cursor SDKが「自分のツール」を受け入れ始めた — 6月アップデートで変わる4つのこと

5月にTypeScript SDKが出て「Cursorがエディタの外に出てきた」と書いた。あれから1か月、Cursorは次の一手を打ってきた。

6月4日のアップデートで、Cursor SDKにカスタムストア、カスタムツール、auto-review、ネストサブエージェントの4機能が追加された。TypeScript版・Python版の両方に対応している。

前回のSDKリリースが「CursorのAIを外から呼べるようにした」だとすれば、今回は「呼んだ先で何をさせるかを自由に設計できるようにした」。プラットフォームとしての本気度が一段上がった。

カスタムツール — MCPサーバーを立てなくていい

これが今回の目玉だと思う。

これまでCursorのエージェントに独自の機能を使わせたければ、自前でMCPサーバー（stdioかHTTP）を立てて、設定ファイルに接続情報を書いて、エージェントに認識させる必要があった。動くまでの手間がそれなりにある。

6月のアップデートで、Agent.create() や send() に関数定義を local.customTools として直接渡せるようになった。SDK側が内部的に custom-user-tools という組み込みMCPサーバーを立ち上げて、渡した関数を他のMCPツールと同じ経路・同じ権限ゲートで呼び出し可能にしてくれる。

つまり、関数を1つ書くだけでいい。MCPの仕様を意識する必要がない。

地味だが、これはかなり大きい。たとえば社内のデータベースに問い合わせる関数を1つ渡せば、エージェントがコードを書きながらリアルタイムでDBのスキーマを参照できる。Jiraのチケットを読む関数を渡せば、PRの作成時にチケットの内容を自動で反映させられる。

しかも、親エージェントに渡したカスタムツールは配下のサブエージェントにも自動で引き継がれる。一度定義すれば、実行ツリー全体で使える。

カスタムストア — 永続化先を選べる

エージェントの状態をどこに保存するかを選べるようになった。

デフォルトではインメモリだが、SQLiteやJSONL（追記型のファイル）も選択できる。さらに LocalAgentStore インターフェースを実装すれば、PostgresでもRedisでも好きなバックエンドに差し替えられる。

使い分けとしては、CIの一時的な実行ならインメモリで十分。長期間動かすエージェント（たとえば毎晩コードベースを巡回するやつ）ならSQLiteに落としておくと、翌日の実行で前回の状態を引き継げる。エンタープライズで複数のエージェントの実行履歴を一元管理したいなら、Postgresに流すのが自然だろう。

正直、これが今まで選べなかったのが不思議なくらいだ。SDKを本番に載せるなら永続化は必須で、それがようやく公式にサポートされた。

auto-review — ヘッドレス実行の安全弁

auto-reviewは、エージェントが実行するツールコールを3つのバケットに自動分類する機能だ。

Allowlisted（即座に実行）、Sandboxable（サンドボックス内で実行）、そしてそれ以外（分類サブエージェントに回す）。ヘッドレス（無人）でエージェントを動かすときに、どのツールコールをどこまで信用するかをプログラムで制御できる。

CIパイプラインでエージェントを回すとき、ファイル読み取りは即座に許可し、rm -rf は分類器に回して判断させる、といった運用が簡単に書ける。

無人実行を前提にしたAIコーディングツールはまだ少ない。Claude Codeのルーティンやhooksは似た方向を向いているが、Cursor SDKのauto-reviewはツールコール単位で粒度が細かい。ここはCursorが一歩先を行っている印象がある。

ネストサブエージェント — 再帰的な分業

サブエージェントがさらにサブエージェントを呼べるようになった。深さに制限はない。

レビュー担当のサブエージェントがテストライター用のサブエージェントを呼び出し、そのテストライターがさらにフィクスチャ生成用のサブエージェントに委任する、といった多層構造を組める。各階層で独自のプロンプトとモデルを保持できるので、レビューにはOpusを使い、テスト生成にはSonnetを使う、という使い分けも可能。

特別な設定は不要で、サブエージェントを定義しているエージェントなら自動的にネストが有効になる。

これはまだ「使いこなすには経験が要る」段階だと思う。深くネストしすぎるとデバッグが困難になるし、トークン消費も跳ね上がる。ただ、複雑なリファクタリングや大規模なコードレビューのように、人間でも複数人で分業するようなタスクには、再帰的なエージェント構造がフィットする場面は確実にある。

SDKの「プラットフォーム化」が意味すること

この1か月で、Cursor SDKは「AIを外から呼べるAPI」から「AIの振る舞いを細かく設計できるフレームワーク」に変わった。

カスタムツールで独自機能を注入し、カスタムストアで永続化を制御し、auto-reviewで安全性を担保し、ネストサブエージェントで複雑なワークフローを組む。これらを組み合わせると、Cursor SDKの上に独自のAIコーディングプラットフォームを構築できる。

実際、RipplingやNotionといった企業はすでにSDKを使って社内のコーディングワークフローを自動化している。6月のアップデートで、そうしたエンタープライズユースの自由度がさらに広がった。

一方で、SDKの進化が速すぎて、5月に書いた実装コードが6月には古くなるリスクもある。APIの安定性については、まだパブリックベータの段階なので過度な期待はしないほうがいい。

ただし方向性は明確だ。CursorはIDEの会社から、AIコーディングインフラの会社へと変わろうとしている。SDKの6月アップデートは、その道筋をさらに1歩進めたものだった。