エディタを替えるな、エージェントを繋げ — AI時代の開発環境を疎結合にする

AIのためにエディタを替えた。その乗り換え先が、いまや手元でいちばん重いアプリになっている。起動のたびに少し待たされ、気づけば月々の支払いも増えていく——そんな感覚は、ないでしょうか。

2025年6月、AIエディタの代表格だったCursorが料金体系を大きく変え、「unlimited」の意味をめぐって利用者の強い反発を招きました。CEOが謝罪し、期間中の超過請求を返金する事態になっています（Cursor公式ブログ「Clarifying our pricing」, 2025・TechCrunch, 2025）。同じ頃から日本語圏でも「Cursorが重い」「別のエディタへ移る」という記事が目立ち始めました（例: CursorからZedに乗り換えた, Zenn 2025）。

結論から書きます。この疲れの正体は、特定の製品の出来ではなく、エージェントとエディタを一体にする「密結合」という設計にあります。そして2026年のいま、エージェントをエディタから切り離して繋ぐ「疎結合」という選択肢が、現実的になってきました。エディタを替え続ける必要は、もうありません。これは個人の開発環境に閉じた話でもなく、企業のシステムにAIを組み込むときの設計と骨格は同じです。

立場も明かしておきます。私たちCognisantはLLMシステムの実装会社で、コードの大半をAIに書かせています。私自身は、長年Sublime Textを使い続けている人間です。その偏りは、割り引いて読んでいただいてかまいません。ただ、この記事は「昔のエディタに戻れ」という懐古でも、特定製品の批判でもなく、エージェント時代の開発環境をどんな構造で組むか、という設計の話です。

AIエディタが重く・高くなるのは、偶然ではない

Cursorの騒動を「一企業の値付けの失敗」と見ることもできます。ただ、実装者として構造を見ると、あれは事故というより密結合モデルの構造が表に出た瞬間でした。理由は3つあります。

ひとつは、収益の構造。 2025年の時点では、AIエディタの本体価格は実質的にLLM利用料の再販でした。モデルの推論コストが上がれば、あるいは利用者が想定より使えば、値上げか制限強化で調整するしかない。あの6月の変更は、$20のProプランを実質従量制へ移行させるものでした。同社が特別に強欲だったのではなく、モデルを抱き合わせたエディタはモデルのコスト変動を価格に転嫁せざるを得ない——そういう構造の問題です。

注目すべきは、その後です。Cursorはこの構造から抜け出すために、自社モデルの開発へ舵を切りました（Composer, 2025）。再販の苦しさへの答えとしては合理的だと思います。ただ、ユーザーから見ると結合はさらに深くなりました。エディタを選ぶことがモデルを選ぶことになり、モデルを選ぶことがエディタを選ぶことになる。垂直統合とは、両方が一蓮托生になるという意味でもあります。

ふたつめは、技術の構造。 CursorをはじめAIネイティブを名乗るエディタの多くは、VS Codeのフォークです。Electronの上で、コードベース全体を常時インデックスするプロセスと、AI機能のUIが同居する。しかもフォークである以上、本家VS Codeの更新に追従し続ける宿命も背負います。「アップデートのたびに重くなった気がする」という現場の声は、この構造から見れば自然な帰結です。

そして、選択の構造。 これがいちばん見過ごされていると感じます。密結合の世界では、エージェントの乗り換え＝開発環境の総取っ替えです。今年に入ってからも、新しいコーディングエージェントは次々に出ています。そのたびに、キーバインドと拡張と設定を抱えてエディタごと引っ越すのか——この「N人のエージェント × M個のエディタ」の掛け算問題は、個人の工夫では解けません。

分離は、もう始まっている

この掛け算問題、既視感がないでしょうか。かつて「言語サポート × エディタ」の掛け算は、Language Server Protocol（LSP）が「言語サーバーを1回書けば、どのエディタでも動く」形にして解きました。いまのエディタで当たり前に補完や定義ジャンプが効くのは、あの分離のおかげです。

同じことが、エージェントで起きています。

ACP（Agent Client Protocol）は、Zedが提唱しJetBrainsが合流した「エージェント⇄エディタ」の共通プロトコルです（JetBrains × Zed: Open Interoperability for AI Coding Agents, 2025）。2026年1月にはJetBrainsがIDE内からエージェントを選べるレジストリを8エージェントで公開しました（ACP Agent Registry Is Live, 2026）。エコシステム全体では対応実装は既に数十規模に広がり（実装一覧）、Zed・JetBrains IDEのネイティブ対応に加えて、NeovimやEmacsのコミュニティ実装も続いています。

Claude Codeは、この分離を最初から体現しているエージェントです。本体はターミナルに常駐するCLIで、エディタは必須ではありません。その上で、VS CodeやJetBrains向けの公式拡張は、WebSocketとMCPによる薄いIDE統合プロトコルでエディタと会話します。このプロトコルはコミュニティにも解析されていて、Neovim実装（claudecode.nvim）が仕様をドキュメント化しています。

つまり——エージェントは、エディタから独立した製品になった。これが2025〜26年に静かに起きた変化です。エディタに焼き込まれたAIを使うか、エディタの外で動くAIを繋ぐか。初めて、構造を選べるようになりました。

「操縦席」と「エンジン」を分ける

では疎結合の開発環境は、具体的にどういう形になるのか。私たちの構成はこうです。

エージェントはターミナルで動き、コードを書きます。エディタは、人間が読んで、判断して、必要なら手を入れる場所です。両者は薄いプロトコル層だけで繋がります。エディタの中では、エージェントの提案が左右に並ぶ差分として開き、承認すればファイルに反映される。選択範囲や開いているタブは、自動でエージェントに共有される。体験としては「AIエディタ」とほとんど変わりません。違うのは、構造だけです。

この構造の違いは、選択の自由に直結します。

「エディタを替えるな」という題は、Sublimeに来いという意味ではありません。エージェントの都合でエディタを決めなくていい、という意味です。Zedが気に入ればZedでいい。VS Codeに不満がなければそのままでいい。疎結合は「移る自由」と「留まる自由」の両方を含みます。

本当に薄い層で繋がるのか、作って確かめた

ここまでは設計論です。実装者としては「薄い接続層と言うが、実際どのくらい薄いのか」を確かめる必要がありました。私たちはSublime Text用の接続層を自作し、OSSとして公開しています（sublime-claude-code）。

結果から言うと、Claude CodeのIDE統合プロトコルを一通り実装して——差分レビュー、選択範囲の共有、複数セッション並列まで——依存ライブラリゼロ、全体で約1,800行でした。作業はAIと組んで実質2日。手元のWindows機でこの原稿を書いているいまのSublime Text（ウィンドウ2枚・LSP・本プラグイン込み）の実測メモリはこうです。

この数字には、ただし書きが要ります。軽さの主因はSublime Textがネイティブ実装（非Electron）であることで、疎結合そのものの効能ではありません。疎結合の効能は、軽いエディタを選ぶ自由が残ることのほうです。また、エージェント本体は別プロセスとして動いていて、手元の実測では1セッションあたり500MB前後を使います。RAMが消えるわけではなく、エディタの外に出るだけ——そのうえで、人間が読んで判断する場所だけは常に軽い、というのがこの構成です。

いいことばかり書くのは不誠実なので、コストも書きます。疎結合の代償はプロトコル追従を自分で持つことです。実際、公開ドキュメントと実クライアントの挙動には既に乖離がありました。差分レビューの応答仕様がドキュメントどおりでは動かず、実機で突き合わせて初めて分かる——という体験もしています（詳細はリポジトリの開発ノートに公開しています）。公式が仕様を変えれば、追従するのはこちらです。

もうひとつ、先回りして書いておきます。今回実装したのはClaude Codeネイティブのプロトコルで、業界の収斂先は前述のACPです。Claude Code自身も、Zed上では既にACPで動いています（公式アダプタ）。つまり私たちの接続層は、いずれACPクライアントに置き換わっていく側かもしれません。それでも困らない、というのがこの構成の要点です。層が薄ければ、乗り換えもまた薄い。

それでも、と思います。壊れたときに直す相手が「1,800行の薄い層」なのか、「重いエディタ本体のアップデート待ち」なのか。この差は、運用してみると想像以上に大きい。LSPの歴史が示すとおり、プロトコルは実装が増えるほど安定します。ACPにせよClaude CodeのIDEプロトコルにせよ、方向は同じです。

密結合にも、勝ち筋はある

公平のために、密結合でしか出せない価値も書いておきます。

キー入力のたびに数十ミリ秒で候補を返すタブ補完のような体験は、エディタ本体との深い統合が要ります。Cursorの補完UXが評価されてきたのは事実で、あれは疎結合では再現しにくい。また、チームで環境を標準化したい組織や、ターミナルに親しみがない開発者にとって、「全部入り」の分かりやすさには意味があります。

だから、線引きはこうなると思います。ミリ秒単位の補完体験に価値の中心がある人は密結合を、エージェントに設計・実装・検証を任せる働き方に移りつつある人は疎結合を。そしてコーディングの重心は、後者へ動きつつあります。エージェントが数分単位で作業を進める世界では、エディタに求められるのは「速い補完」より「速い起動と、読みやすい差分と、邪魔をしないこと」だからです。

10年馴染んだ道具を、AIの都合で捨てない

エディタは、単なるツールではなく手の延長です。10年かけて指に馴染ませたキーバインドや、自分用に書いた小さなプラグインは、とっくに元を取ったうえで、いまも複利で効き続けています。

AI時代の開発環境の答えが「AIのために毎年エディタを引っ越すこと」だとは、私たちは考えていません。エージェントはエディタの外で進化させ、エディタは手に馴染んだまま、間を薄いプロトコルで繋ぐ。 私たちはこの構成に落ち着き、その接続層をOSSとして公開しました。同じ構成を試したい方はリポジトリからどうぞ。

そして、これはエディタに限った話でもありません。「AIを入れるために既存の環境を捨てる」のではなく「いまの環境にAIを繋ぐ」——私たちCognisantが企業のAI導入で一貫して取っているのも、同じ設計です。

この記事は、AIツールを活用して作成し、Cognisant 工藤大地がファクトチェック・編集・監修を行っています。RAM・コード行数は筆者環境での実測値（2026年7月）です。