私は普段、Cursor のターミナルで完結させています。そこで Claude Code や Codex を起動するというスタイルです。Cursor の良さは全く活かせておらず、ファイルを直接いじりたいときだけ開く IDE くらいの位置づけでした。
ところが直近1ヶ月のアップデートを追いかけてみると、Cursor はもう「IDE」とは呼べないものになっているみたいで、ターミナル派の私としても無視できない変化が含まれているようです。
本記事では、私と同じく「Claude Code・Codex 中心で、Cursor は補助」という方に向けて、何が変わったのか、どう組み合わせると良さそうかを整理してみます。
直近1ヶ月のアップデート（新しい順）
Cursor SDK の公開（4月29日）
今回最大のニュースに見えます。これまで「人間が画面で使うアプリ」だった Cursor のエージェント機能が、SDK 経由でプログラムから呼び出せるようになったらしいです。
npm install @cursor/sdk で導入し、TypeScript から数行で呼び出せるとのこと。Composer 2 でも他のフロンティアモデルでも指定でき、ローカル実行と Cursor 側のクラウド VM 実行が選べるみたいです。
ターミナル派にとっては、「Cursor のエージェント実行環境」を自分のスクリプトやワークフローに組み込めるようになった、という意味で意外と大きい変化な気がします。
Cursor 3.2 / マルチタスク・マルチルートワークスペース（4月24日）
/multitask という機能で、Cursor 内のエージェントが非同期サブエージェントを並列実行するらしいです。Claude Code 側でも複数セッションを並列で動かしている人は多いと思いますが、Cursor の方は UI で一覧管理できるのが違いみたいですね。
マルチルートワークスペースは、複数リポジトリを1つのエージェントセッションでまたげるとのこと。フロントエンドとバックエンドが別リポジトリの SaaS を触ることが多い場合、これは試す価値ありそうですね。
Canvases（4月15日）
エージェントの返答が、テキストとコードだけでなく、ダッシュボード・チャート・テーブル・図といったインタラクティブな可視化として返ってくるみたいです。
ターミナルで作業している分には実感しにくい機能ですが、PR レビューで巨大な diff を「重要度でグルーピングして表示」のような使い方ができるらしく、レビュー作業は Cursor 側でやった方が明らかに楽になりそうですね。
CLI Debug Mode と /btw（4月14日）
Cursor CLI 側のアップデートです。/debug で再現困難なバグの根本原因調査を自動化、/btw で現在の run を止めずに脇道の質問ができるみたいです。
Claude Code でも長時間ランの最中に「ちょっと別の質問をしたい」となることはよくあるので、Cursor CLI の /btw は地味に羨ましい機能ですね。
Cursor 3.1 / タイル表示・音声入力（4月13日）
Agents Window を分割して複数のエージェントを並列で監視できるようになったとのこと。音声入力もバッチ STT で精度が上がったらしいです。
Cursor 3 / 完全な刷新（4月2日）
ここが今回の大改革の本丸みたいです。これまでの Cursor は「コードを書くエディタの中に AI 機能が組み込まれている」構造でしたが、Cursor 3 では「AI エージェントを管理するコンソールが中心で、エディタは脇役」という、ほぼ逆の構造に作り直されたとのこと。
ローカル PC・クラウド・複数の作業ブランチを横断してエージェントを管理でき、Slack や GitHub・Linear から起動したエージェントも一覧で見られる、という設計になっているようです。
1〜2ヶ月前の重要なアップデート
Composer 2（3月19日）
Cursor 自前のコーディングモデルです。100万トークンあたり入力 0.5 ドル・出力 2.5 ドルで、Anthropic・OpenAI のフロンティアモデルより5分の1以下の価格らしいです。
Auto モードで使う限り有料プランでは無制限に使える、とのこと。Claude Code で月のクレジットを使い切りそうな時の「逃げ場」として組み合わせるのが現実的な使い方かもしれません。
プラグインマーケットプレイス（2月17日〜3月11日）
Skills・Subagents・MCP server・Hooks・Rules を単一パッケージで配布・インストールできる仕組みのようです。Claude Code 側の Skills と概念は近いですね。
AWS、Cloudflare、Stripe、Linear、Figma、Datadog、GitLab、shadcn/ui など主要サービスのプラグインが揃っているとのことなので、Cursor 側で動かすときの初期設定はかなり楽になりそうです。
ターミナル派にとって、結局Cursorで何をやるべきか
ここからが本題です。Claude Code や Codex で作業の大半が完結している前提で、Cursor をどう活用すると効くかを考えてみます。
1. 大きな diff のレビューは Cursor でやる
個人的に一番効きそうな使い方です。Claude Code や Codex で実装は走らせて、最後の人間レビューだけ Cursor で開く。Canvases が重要度別にグルーピングしてくれるなら、巨大な PR の確認は明らかに Cursor 側が楽になりそうですね。
2. 複数リポジトリを横断する作業はマルチルートワークスペースで
フロントとバックエンドが別リポになっている構成で、API 変更を両側に同時に反映するような作業は、Cursor 3.2 のマルチルートワークスペースが向いているみたいです。Claude Code で個別リポを触るのと併用する形ですね。
3. SDK で Cursor をパイプラインの部品にする
これが一番面白そうな使い道です。Cursor SDK を使えば、自分の n8n ワークフローや cron ジョブの中に「Cursor のエージェント実行」を組み込めるとのこと。
Claude Code の CLI をスクリプトから叩く運用をしている人は多いと思いますが、Cursor は「クラウド VM での実行」も SDK 経由でできるみたいなので、ローカルで動かしたくない長時間タスクや定期実行系は Cursor SDK 経由の方が向いていそうですね。
4. Composer 2 をクレジット節約の逃げ場に
Claude Code（Opus）を使い続けると、Ultra や Max プランでも月の使用量が気になる場面があります。「定型的だけど量がある」作業は Cursor + Composer 2 に逃がすと、コストを抑えられそうです。
5. プラグイン経由で外部サービスを操作する
Stripe・Linear・Datadog などは Claude Code 側の MCP でも動かせますが、Cursor のプラグインは「MCP + Skill + Rules」がパッケージ化されている分、初期設定が楽そうな印象です。「Stripe で料金プランを作る」「Linear にタスクを切る」のような操作系の作業は、Cursor のプラグイン UI 経由のほうが速い場面もありそうですね。
逆に、無理にCursorに移さなくて良さそうな部分
ターミナル中心で困っていない部分は、無理に切り替える必要はないと思います。
- コードを書くタブ補完：Claude Code の CLI で完結している人にとっては、Cursor のタブ補完を使うために態度を変える必要はなさそうです。
- 長時間の自律実行：Claude Code の方がトークン効率も実績も優位とされているようなので、本格的な長時間ランは Claude Code のままで良いと思います。
- Agents Window 中心の運用：これは Cursor 中心の人向けの UI なので、Claude Code/Codex 中心の人がここに移行する必然性は薄そうですね。
結論：併用前提で、それぞれの強みに任せる
私の現時点の結論は、「メインは Claude Code（または Codex）、Cursor は特定用途で組み合わせる」というスタイルです。
役割分担の現実的な切り方としては、こんな形が良さそうです。
- Claude Code / Codex：実装、長時間自律ラン、CI 連携、定型作業の自動化
- Cursor：大きな PR レビュー（Canvases）、複数リポジトリの横断作業（マルチルートワークスペース）、自社パイプラインへの組み込み（SDK）
両者は同じ Git リポジトリの上で問題なく共存できます。Cursor に完全移行する必要はなく、「Cursor のこの機能だけ取り込む」という発想で十分そうですね。
LLM 自体の賢さは各社で横並びに近づいてきているので、結局差がつくのは 「どの作業環境に置くか」 です。Cursor は2026年に入ってから明確に「エージェント実行環境」へ舵を切った印象なので、ターミナル派にとっても、Cursor を「IDE」ではなく「補助的なエージェントランタイム」として捉え直すと、使いどころが見えてくるのではないかと思います。