IntelliJ IDEAを使うJavaエンジニアが、IDEを乗り換えずにCursorを使えるようになった。
2026年3月4日、CursorがJetBrains IDEのエージェントとして利用可能になった。背景にあるのは「ACP（Agent Client Protocol）」——AIエージェントとIDEを繋ぐオープン標準だ。
IDEを変えずにAIを変える——これまでのジレンマ
Cursorを使いたいが、IntelliJ IDEAは手放せない——これは多くのJavaエンジニアが抱えていた現実の悩みだった。
Cursorはもともとvs Codeをベースにしたエディタとして設計されている。Cursorに乗り換えようとすれば、長年使い慣れたIntelliJのリファクタリング機能、データベースツール、デバッガ、コード解析を丸ごと諦める必要があった。Java・Kotlin・Pythonのエコシステムで働くエンジニアにとって、「IntelliJの開発体験」はVS Codeには代替できない部分がある。
一方、CursorのAI機能——コードベース全体を理解したうえでの提案、自律的なファイル横断編集、エージェント型の長期タスク実行——はJetBrains AI Assistantにはない能力だ。「CursorのAIが欲しいが、IDEは変えたくない」。どちらかを選ぶしかないという状況が続いていた。
ACPはこのジレンマを解消する仕組みだ。
ACPとは何か——LSPのAIエージェント版
ACPを理解するために、まずLSP（Language Server Protocol）から始めるといい。
LSPはMicrosoftが2016年に提案したオープン標準で、「どのエディタでも同じ言語サポートが使える」を実現した仕組みだ。LSP以前、Go言語のコード補完をVS Codeで動かすには「VS Code向けのGoプラグイン」を、Vimで使うには「Vim向けのGoプラグイン」を、Emacsで使うには「Emacs向けのGoプラグイン」を別々に作る必要があった。エディタの数 × 言語の数だけ実装コストがかかる状況だった。
LSPはこのN×M問題を解決した。Go言語の「言語サーバー」を1つ作れば、LSPに対応したどのエディタでも動く。エディタ側もLSPに対応すれば、あらゆる言語の補完が使える。「共通の通信規格を定める」ことで組み合わせ爆発を防いだ。
ACPはまったく同じ問題を、AIエージェントとIDEの間で解く。
JetBrains ACPページによると、ACPはJetBrainsとZed Industriesが共同で策定したオープン標準で、IDEとAIエージェント間の通信をJSON-RPC 2.0（stdin/stdout経由）で標準化する。技術的な詳細は難解だが、要するに「どのIDEでもどのAIエージェントも使える」を実現するための共通言語だ。
# ACP以前（N×M問題）
Cursor × JetBrains → 独自実装なしには不可
Gemini CLI × JetBrains → 独自実装なしには不可
goose × Zed → 独自実装なしには不可
# エージェントの数 × IDEの数だけ、個別の実装コストがかかる
# ACP後（統一プロトコル）
ACP対応エージェント × ACP対応IDE → どの組み合わせでも動く
Cursor × JetBrains → 対応（2026年3月〜）
Gemini CLI × JetBrains → 対応
Cursor × Zed → 対応可能（規格が共通）
JetBrains Blog（2025年12月）でJetBrainsはACPの設計思想をこう説明している: "Competition should happen on quality, not on who controls the integration"（競争は品質でおこなわれるべきで、誰がインテグレーションをコントロールするかで決まるべきではない）。
ACP Agent Registry——1クリックでエージェントをインストール
ACPという規格が生まれても、使い始めるのが面倒では普及しない。その課題を解決したのが「ACP Agent Registry」だ。
JetBrains Blog（2026年1月28日）によると、JetBrainsとZedが共同でACP Agent Registryをローンチした。
Registry以前は、エージェントを使うためにJSONファイルを手動で編集する必要があった。
// ❌ Registry以前（JSONファイルを手動編集してエージェントを登録）
// ~/.config/JetBrains/ai-assistant/acp.json
{
"agents": [
{
"name": "cursor",
"command": "cursor",
"args": ["agent", "acp"],
"env": {}
}
]
}
// ドキュメントを読みながら試行錯誤が必要
// 設定ミスするとエージェントが起動しない
Registry後は1クリックで済む。
// ✅ Registry導入後（UIから選ぶだけ）
// JetBrains IDE → AI Assistant → Agents → 「Install from ACP Registry...」
// → エージェント一覧から「Cursor」を選択 → インストール完了
// JSONを1行も書かない
2026年1月時点でRegistryに登録されているエージェントは、Kimi CLI（Moonshot AI）、goose（Block）、Augment Code、GitHub Copilot、Gemini CLI、Mistral Vibe、OpenCode（コミュニティOSS）、Qwen Code（Alibaba）、Factory Droidなど多岐にわたる。そして2026年3月4日、このリストにCursorが加わった。
JetBrainsでCursorを使う方法
Cursor BlogとJetBrains Blog（2026年3月）をもとに手順を説明する。
対象IDEはIntelliJ IDEA、PyCharm、WebStormを含むJetBrainsファミリー全製品だ。セットアップは4ステップで完結する。
- JetBrains IDEを2025.3.2以降にアップデートし、AI Assistantプラグインを有効化する
- IDE内のエージェント選択画面を開く
- 「Install from ACP Registry...」を選択する
- Cursorをインストールし、既存のCursorアカウントでサインインする
費用はシンプルだ——JetBrains AIのサブスクリプションは不要で、Cursorの有料プランのみが必要になる。
使えるAIモデルはCursorが通常提供しているものと変わらない。OpenAI、Anthropic、Google、Cursorのフロンティアモデルが選択可能で、大規模なエンタープライズコードベース向けのセキュアなコードベースインデックスとセマンティック検索にも対応している。
JetBrains IDEs Division責任者のAleksey Stukalov氏はこの統合についてこう述べている: "developers can have the best of both worlds—full environment control and sophisticated AI assistance"（開発者はIDEの完全なコントロールと洗練されたAIアシスタンスの両方を手に入れられる）。
MCPとACPの違い——補完関係を整理する
MCPとACPという2つの規格が登場し、混乱することがある。整理しておこう。
AnthropicのMCP発表（2024年11月）によると、MCPは「AIが外部ツールにアクセスする規格」だ。CursorがGitHubのPRを読んだり、Slackのメッセージを確認したりできるのはMCPのおかげだ。
一方ACPは「AIエージェントがIDEの中で動く規格」だ。IDEのファイルシステムにアクセスしたり、エディタのUIと連携したりといった、IDE固有の操作を標準化する。
両方が必要で、競合しない。MCPがAIの「ツール箱を広げる規格」なら、ACPは「そのAIをIDEに持ち込む規格」だ。JetBrainsのHead of AI DevTools EcosystemであるDenis Shiryaev氏が「We're not picking sides」（どちらかの側につくわけではない）と述べているように、JetBrainsはACP以外のプロトコルも受け入れる姿勢を取っている。
OpenAI App Serverとの違い——オープン対クローズド
同じ「N×M問題」を別のアプローチで解こうとしているのが、OpenAI App Serverだ（「OpenAI Codex App Server——なぜ同じAIがVS CodeでもCLIでも動くのか」で解説している）。
App ServerはOpenAI独自のバックエンドで、CodexエージェントをCLI・VS Code・JetBrains・macOSアプリで動かす仕組みだ。ただしOpenAI専用のプロプライエタリな中央集権型の仕組みであり、OpenAI以外のエージェントには使えない。
ACPは正反対のアプローチだ。仕様が公開されており、誰でも実装できる。OpenAIもAnthropicもGoogleも、ACP対応エージェントを作れば、JetBrainsでもZedでも動く。
電化製品のコンセントに例えるなら、App ServerはOpenAI製品専用のコンセントだ。ACPは国際標準のコンセント規格で、どのメーカーの製品も差し込める——規格に対応さえすれば。
なぜJetBrainsがオープン標準を主導したのか
JetBrainsは2024年のアニュアルハイライトで、1,140万人の定期アクティブユーザーを持つと発表している。その大半が、Java・Kotlin・Python・GoといったエンタープライズIDE利用者だ。
VS CodeベースのエディタがAI統合を加速させるなか、JetBrainsには固有の課題があった。CursorもWindsurfもVS Codeのforkであり、AI IDEツールがVS Code向けに作られることがほとんどだった。JetBrainsユーザーは「VS Codeに乗り換えればAI環境が充実する」という状況に置かれていた。
JetBrainsがACPをオープン標準として策定し、Zedと協力して推進した理由は明快だ——自社製品に縛るのではなく、あらゆるエージェントが対応しやすくすることで、JetBrainsユーザーのAI体験を充実させる。「インテグレーションのコントロール」を競争優位にするのではなく、「IDE自体の品質」で競争するという宣言だ。
「競争は品質でおこなわれるべきで、誰がインテグレーションをコントロールするかで決まるべきではない」——JetBrains Blog（2025年12月）
JetBrains Research（2025年1月）によると、世界の全プロ開発者数は約1,960万人（2024年推計）とされている。その6割近くがJetBrains製品のユーザーであるなら、JetBrainsがAI IDEの戦場を「VS Code専用」にさせたくない理由は明らかだ。
まとめ——IDEの選択とAIの選択が切り離された
2026年3月4日を境に、JetBrainsユーザーはIDEとAIエージェントを独立して選べるようになった。
IntelliJ IDEAのリファクタリング機能を使いながら、CursorのAIで自律的なコード編集をする——これがACPによって初めて可能になったことだ。
ACPはまだ始まったばかりの規格だ。対応エージェントも対応IDEもこれから増えていく。LSPが「どのエディタでも同じ言語サポートを使える」世界を作ったように、ACPが「どのIDEでも同じAIを使える」世界を作ろうとしている。
JetBrainsユーザーにとって今日やることは一つだ——IDEを2025.3.2以降にアップデートして、CursorをACP Registryからインストールしてみることだ。
