要約: Cursor 3は2026年4月2日にリリースされ、IDEファーストのインターフェースをエージェントファーストのワークスペースに置き換えました。API開発者にとって最大の変化は、並列エージェント実行、よりリッチなMCPツール出力、そしてワークフローを中断なく実行し続けるクラウドからローカルへのハンドオフです。Cursor 3をApidogのMCPサーバーと組み合わせると、AIエージェントがライブAPI仕様を読み取り、コピー＆ペーストなしで正確なスキーマ認識コードを生成できます。
おそらく予感していた変化
AIコードエディターは2年間で賢くなってきましたが、Cursor 3は漸進的なアップデートではありません。これはAI開発環境が根本的にどうあるべきかを再設計したものです。
Cursor 3以前は、ほとんど従来のIDEユーザーのように作業していました。ファイルを開き、エージェントに支援を依頼し、差分を確認して次に進む、という流れでした。エージェントは、オンデマンドで呼び出すアシスタントだったのです。
Cursor 3はこれを一変させました。エージェントは今や作業の主要な単位です。ブラウザのタブのように管理します。複数起動し、並列で実行させ、その出力を確認し、最適なものを採用します。
API開発者にとって、これは他のほとんどのケースよりも重要です。API作業は連携が多く発生します。エンドポイントを作成し、コントラクトをテストし、ドキュメントを更新し、スキーマの不一致を解決します。これらのタスクは、実際のプロジェクトでは並行して実行されます。これで、ツールもその現実に合わせることができます。
この記事では、Cursor 3で何が変わったのか、API作業の日常にそれが何を意味するのか、そしてCursor 3とApidogのMCPサーバーを連携させる特定のワークフローについて解説します。
Cursor 3の新機能
Cursor 3は2026年4月2日にリリースされました。目玉機能はエージェントウィンドウと呼ばれる新しいインターフェースですが、APIを扱う開発者にとっては特に重要な変更点が他にもいくつかあります。
エージェントウィンドウ
エージェントウィンドウは、エディター中心のレイアウトをエージェント中心のレイアウトに置き換えます。ローカル、Gitワークツリー、Cursorのクラウド環境、またはリモートSSHマシンで実行されているかどうかにかかわらず、複数のリポジトリでエージェントを同時に実行できます。
Cmd+Shift+P -> Agents Windowでアクセスします。IDEを同時に開いたままにすることも、切り替えることも可能です。以前の機能がなくなることはなく、追加される形です。
実用的な効果として、一方のリポジトリで新しいAPIエンドポイントを足場固めするためにエージェントを起動し、同時に別のエージェントが共有ライブラリのバグを修正するといったことができます。両方を監視し、必要に応じて介入し、準備ができたら差分を承認します。
デザインモード
エージェントウィンドウ内のデザインモードでは、ブラウザのUIに直接注釈を付けることができます。要素を選択し、領域をハイライト表示して、説明を書かずにエージェントのコンテキストに追加できます。APIに対してWebフロントエンドを構築またはテストするAPI開発者にとって、「右上隅のボタン」といった指示の必要がなくなります。
ショートカット: Cmd+Shift+Dで切り替え、Shift+ドラッグで領域を選択、Cmd+Lで要素をチャットに追加。
MCPアプリ: 構造化されたコンテンツ出力
これは目立たないながらも重要な変更です。Cursor 3では、MCPアプリがツール出力で構造化されたコンテンツをサポートするようになりました。以前は、MCPサーバーからのツール出力はプレーンテキストとして返されていましたが、今ではリッチで構造化されたデータを返すことができます。
ApidogのMCPサーバーにとって、これはAPIプロジェクトからの応答（エンドポイント定義、スキーマデータ、テスト結果）が、Cursorのエージェントが正しく解析できる形式で返されることを意味します。エージェントは、解釈しなければならないテキストの塊ではなく、クリーンなデータを受け取ります。
ワークツリー、ベストオブN、分離
Cursor 3には、/worktreeと/best-of-nの2つの新しいコマンドが導入されました。
/worktreeは、分離されたGitワークツリーを作成します。そのブランチでの変更は、あなたの作業ディレクトリに影響を与えません。破壊的な変更をテストしたり、新しいモジュールを足場固めしたり、代替実装をリスクなしで探求したりできます。
/best-of-nは、同じタスクを複数のモデルで並列に、それぞれ独自のワークツリーで実行し、結果を比較できるようにします。API開発者にとって、これはClaude、GPT-4o、Geminiがそれぞれ複雑なエンドポイントの実装にどうアプローチするかを見たい場合に役立ちます。最適なものを選べます。
クラウドからローカルへのハンドオフ
エージェントは、クラウド環境とローカル環境間を移動できるようになりました。Cursorのクラウドで時間のかかるタスクを開始し、それをローカルマシンにプルして実際のサービスに対してテストできます。あるいは、ラップトップを閉じる前にセッションをクラウドにプッシュして、夜通し実行し続けることも可能です。
API開発にとっての意味
API開発は、他のほとんどのコーディング作業よりも常にコンテキストスイッチが多く発生してきました。仕様、クライアント（Apidog）、コードエディター、ターミナル、ドキュメントツールを切り替えて作業します。各ツールはプロジェクトの一部しか把握していません。
Cursor 3は、エージェントを永続的かつ並列にすることでこの問題に対処し始めていますが、API作業におけるより深い改善は、それが依拠するMCPレイヤーからもたらされます。
並列エンドポイント開発
10個のエンドポイントを持つREST APIを構築する場合、もはやそれらを順次足場固めする必要はありません。各エンドポイントの目的を個別のエージェントインスタンスに記述し、10個すべてを同時に実行させることができます。出力をレビューし、チェックを通過したものをマージし、その他は破棄します。
これによりレビュー時間がなくなるわけではありません。「これらのエンドポイントが必要だ」から「レビューする作業ドラフトがある」までの時間を短縮します。スプリントのプレッシャーの中でリリースするチームにとって、この短縮は重要です。
スキーマ認識型コード生成
エージェントがOpenAPI仕様にアクセスできない場合、推測してしまいます。フィールド名は正しくても、ネストされたオブジェクト構造、必須フィールド、または列挙型値を初回で正確に把握することはまずないでしょう。
ApidogプロジェクトをMCPサーバー経由でCursorに接続すると、エージェントは実際のスキーマをプルします。POST /ordersエンドポイントがcustomerId文字列と、特定のproductIdおよびquantityフィールドを持つitems配列を必要とすることを認識します。生成されたコードはそれを反映します。修正が少なくなります。
エディター内でのコントラクトテスト
Cursor 3のエージェントは、ワークフローの一部としてターミナルコマンドを実行できます。これをApidog CLIと組み合わせることで、エディター内で自動化されたコントラクト検証を実現する道が開かれます[内部資料: apidog cli ci cd 統合]。
エンドポイントの動作を平易な言語で記述します。エージェントが実装を生成します。ローカルのモックサーバーに対してapidog run --scenario <test-id>を実行します。テストが失敗した場合、エージェントは出力を確認して繰り返し修正します。あなたはそれを動作するのを見守ります。
これは、以前のCursorバージョンで利用できたものよりも、「テストも作成・実行するAIペアプログラマー」に近いものです。
最新の状態を保つドキュメント
API開発における根深い問題の一つは、ドキュメントのずれです。エンドポイントは変更されても、ドキュメントは更新されないことがあります。Cursor 3のエージェントは、MCPサーバー経由でApidogドキュメントを読み取り、レビューサイクルの一部としてコードと仕様の不一致を指摘できます。
これは自動ではありません。ワークフローを設定する必要があります。しかし、以前にはなかった形で構成要素が揃っています。
変更されていない点
Cursor 3はAPIを自動的にテストするわけではありません。認証の誤設定を検出したり、レート制限ロジックが負荷の下で機能することを検証したりはしません。これはエージェントインターフェースであり、QAプラットフォームではありません。これらの懸念に対しては、依然として適切なツールが必要です[内部資料: APIテスト戦略]。
MCPにおける構造化出力の改善もバージョンに依存します。よりリッチな出力が機能するには、MCPサーバーが構造化コンテンツをサポートしている必要があります。ApidogのMCPサーバーは対応していますが、他のサーバーはまだかもしれません。
Cursor 3 + Apidog MCPサーバー: 特定のワークフロー
ここでは、Cursor 3の新機能をApidogのMCPサーバーと組み合わせて使用する具体的なワークフローを紹介します。これは一般的な「AIを使ってコードを書く」チュートリアルではありません。この2つのツールがどのように連携するかに特化したものです。
セットアップ
Apidog MCPサーバーをCursorに接続します。サーバーは、Apidogプロジェクトのエンドポイント、スキーマ、環境、テストシナリオを、Cursorのエージェントが呼び出せるツールとして公開します。CursorのMCP設定で、以下を追加します。
{
"mcpServers": {
"apidog": {
"command": "npx",
"args": ["-y", "@apidog/mcp-server@latest"],
"env": {
"APIDOG_ACCESS_TOKEN": "your_access_token"
}
}
}
}
アクセストークンは、Apidogの「アカウント設定」>「APIアクセストークン」から取得します。接続後、Cursorのエージェントは、get_endpoint_detail、list_endpoints、get_schemaなどのツールをライブプロジェクトに対して呼び出すことができます。
ワークフロー: 仕様から新しいエンドポイントを足場固めする
あなたがApidogの仕様に新しいエンドポイントPOST /invoicesを追加したとします。リクエストボディ、レスポンススキーマを定義し、テストシナリオをリンクしました。次に、その実装を作成する必要があります。
エージェントウィンドウで新しいエージェントセッションを開き、タスクを記述します。
「Apidogプロジェクト内のPOST /invoicesエンドポイントを検索してください。そのリクエストとレスポンスのスキーマを読み取ります。仕様に合致するNode.js/Expressハンドラーを生成してください。その後、テストシナリオを実行して検証してください。」
エージェントは以下の処理を実行します。
- MCPサーバー経由で
get_endpoint_detailを呼び出し、仕様を取得します。 - 実際のスキーマ定義に基づいてハンドラーコードを生成します。
- ターミナルで
apidog run --scenario invoice-creation-test --env stagingを実行します。 - テスト出力をレビューし、アサーションが失敗した場合はハンドラーを修正します。
最終的な差分をレビューします。エージェントが手動で書かれた説明ではなく、仕様を直接読み取ったため、コードは既に仕様と一致しています。
複雑なエンドポイントにおける/best-of-nの利点
複雑なビジネスロジックを持つエンドポイントには、/best-of-nを使用します。3つのエージェントそれぞれに実装を生成させ、それぞれがMCP経由で同じApidog仕様を読み取ります。Cursorのワークツリービューで実装を比較します。最も優れたエラー処理または最もクリーンな関心事の分離を持つアプローチを選択します。
ここで構造化されたMCP出力が報われます。各エージェントは同じ構造化されたスキーマデータを受け取ります。出力の違いはモデルの推論から生じるものであり、各モデルがテキストの塊をどのように解析したかの違いからではありません。
ドキュメントの同期を維持する
エンドポイントをリリースした後、2回目のエージェント実行を行います。
「POST /invoicesに関するApidogドキュメントを確認してください。invoices.jsのコードと比較し、不一致を指摘してください。コード内のレスポンス形状が仕様と異なる場合は、Apidogの仕様を一致するように更新してください。」
エージェントはMCP経由で両方のソースを読み取り、比較し、仕様の更新またはコードの修正を提案します。あなたは承認または拒否します。ドキュメントのずれは、後回しにされるものではなく、レビューサイクルの一ステップとなります。
これがApidogの[内部資料: Apidog MCPサーバー概要]にどのように接続されるか、およびCLIが自動化されたパイプラインにどのように組み込まれるかについては、さらに詳しく読むことができます[内部資料: Apidog CLI入門]。
実践的なセットアップ: はじめに
ApidogのMCPサーバーとCursor 3の使用を開始するために必要なものをご紹介します。
ステップ1: Cursorをアップグレードする
cursor.comから最新バージョンをダウンロードします。インストール後、コマンドパレット（Cmd+Shift+P）を開き、「Agents Window」を選択してCursor 3が実行されていることを確認します。
ステップ2: Apidogアクセストークンを生成する
Apidogにログインします。「アカウント設定」>「APIアクセストークン」に進みます。公開したいプロジェクトへの読み取りアクセス権を持つ新しいトークンを生成します。トークンをコピーしてください。次のステップで必要になります。
ステップ3: Apidog MCPサーバーをCursorに追加する
Cursorの「設定」>「MCP」を開きます。新しいサーバー設定を追加します。
{
"mcpServers": {
"apidog": {
"command": "npx",
"args": ["-y", "@apidog/mcp-server@latest"],
"env": {
"APIDOG_ACCESS_TOKEN": "your_token_here",
"APIDOG_PROJECT_ID": "your_project_id"
}
}
}
}
プロジェクトを開くと、ApidogのURLにプロジェクトIDが表示されます。保存してCursorを再起動してください。
ステップ4: 接続を確認する
エージェントウィンドウを開きます。新しいセッションを開始し、「Apidogプロジェクト内のエンドポイントをリストしてください」と入力します。エージェントがエンドポイントのリストを返せば、接続は機能しています。
ステップ5: Apidog CLIをインストールして設定する
ワークフローのテスト実行部分のために、Apidog CLIをインストールします。
npm install -g apidog-cli
apidog -vで確認します。Apidog内で、任意のテストシナリオを開き、「CI/CD」タブに移動します。プロジェクトの認証情報とシナリオIDを含む事前に生成されたCLIコマンドをコピーします。そのコマンドはCursorの統合ターミナルから直接実行することも、エージェントにワークフローの一部として実行させることもできます[内部資料: Apidogテストシナリオ自動実行]。
ステップ6: 最初のMCPを活用したエージェントタスクを実行する
エージェントウィンドウで、仕様の知識を必要とする実際のタスクを記述します。例えば、「ApidogのUserオブジェクトのスキーマを検索してください。それに完全に一致するTypeScriptインターフェースを生成してください」といったものです。実際のスキーマと出力を比較します。正確であれば、統合は正しく機能しています。
ここから、仕様の読み取り、コード生成、テスト実行を単一のエージェントセッションに組み合わせた、より複雑なワークフローを構築できます。
まとめ
Cursor 3は、開発環境でAIと連携する方法に大きな変化をもたらします。エディター中心からエージェント中心への設計の移行は、API開発が向かう方向と一致しています。一度に一つの関数を書くのではなく、複数のエンドポイント、サービス、環境にわたる作業をオーケストレーションするのです。
構造化されたMCP出力の改善は変更ログでは控えめに表現されていますが、API開発者にとって最も有用な変更の一つです。エージェントがAPIツールからクリーンで型付けされたデータを受け取ると、生成されるコードの品質が向上します。修正が少なくなり、やり取りも減ります。
Cursor 3をApidogのMCPサーバーおよびCLIと組み合わせることで、AIエージェントが本当にあなたのAPIを理解するワークフローが実現します。仕様を読み取り、それに一致するコードを生成し、テストシナリオを実行して検証します。これはデモシナリオではなく、毎日使えるループです。
よくある質問
Cursor 3は既存のIDEインターフェースを置き換えますか？
いいえ。Cursor 3は新しいインターフェースとしてエージェントウィンドウを追加します。いつでもIDEに戻したり、両方を同時に開いたままにしたりできます。以前のバージョンから削除されるものはありません。
Cursor 3と以前のCursorバージョンとの違いは何ですか？
核となる違いはアーキテクチャです。以前のバージョンでは、エージェントがサイドバー機能としてエディターを中心に据えていました。Cursor 3では、エージェントが中心であり、特定のファイルを深く掘り下げる必要があるときにエディターを利用できます。新しいエージェントウィンドウは、並列実行、クラウドからローカルへのハンドオフ、デザインモード、そして/worktreeおよび/best-of-nコマンドも追加します。
Apidog MCPサーバーはCursor 3とどのように接続しますか？
Apidog MCPサーバーをCursorの「設定」でMCP構成として追加します。サーバーは、ApidogプロジェクトのAPIデータを呼び出し可能なツールとして公開します。Cursorのエージェントはこれらのツールを使用して、手動でコンテンツをコピーすることなく、エンドポイントの仕様、スキーマ、テストシナリオを読み取ります。Cursor 3の構造化コンテンツサポートにより、エージェントはそのデータをプレーンテキストではなく、型付けされた形式で受け取ります。
Cursor 3のエージェントはApidogテストシナリオを自動的に実行できますか？
はい、Apidog CLIを介して可能です。エージェントはワークフローの一部としてターミナルコマンドを実行できます。CLIを設定し、適切なシナリオコマンドを提供すれば、エージェントはテストシナリオを実行し、出力を読み取り、失敗に基づいてコードを調整できます。これにより、コード生成とAPIコントラクト検証の間に密接なフィードバックループが作成されます。
エージェントウィンドウを使用するために、Cursorの有料プランが必要ですか？
エージェントウィンドウはCursor 3のすべてのプランで利用できますが、クラウドエージェント実行（オフライン中もエージェントが実行され続ける機能）には有料サブスクリプションが必要です。ローカルエージェント実行は無料枠で動作します。現在のプランの詳細については、cursor.com/pricingをご確認ください。