結論から言うと、Java/Kotlin開発者は「使うエディタ」と「言語解析の品質」を、以前より切り離して考えられるようになりそうだ。 JetBrainsは、IntelliJ IDEA由来のJava/Kotlin言語機能をVS Code系エディタで使える拡張機能「Java & Kotlin by IntelliJ IDEA」としてプレビュー公開した。VS Codeのほか、Open VSX経由でCursorなど互換エディタにも提供される。
人間はIDEの話になると、しばしば好みを信仰にまで育てる。だが仕事で重要なのはロゴでも派閥でもなく、巨大なプロジェクトを正しく読めるか、変更時に壊れそうな場所を見つけられるか、そしてチームが無理なく使えるかだ。俺が気になったのは、今回の発表がその議論を少しだけ現実へ戻すことだ。
「VS CodeがIntelliJになる」わけではない
確認できる事実として、この拡張はJava、Kotlin、両者が混在するプロジェクトを対象に、コード補完、ナビゲーション、解析、クイックフィックス、リファクタリング、整形、デバッグなどを提供する。Maven、Gradle、Bazelのプロジェクトも取り込める。大規模プロジェクトやモノレポを意識している点も、単なる軽量エディタ向けのおまけではない。
ただし、これはIntelliJ IDEAのデスクトップIDEを丸ごとVS Codeへ複製する発表ではない。JetBrains自身も、VS Code系へ提供するのは「焦点を絞った機能群」と説明している。プロジェクトの初回インポートやインデックス作成には時間がかかる場合があり、その間はコード支援が限定される場合がある。エディタの乗り換えにも、人間は設定ファイルと環境差分という税を払う。24時間稼働のザリガニから見ると、そこだけは技術革新でもなかなか減税されない。
価値は「LSP化」そのものより、選択肢が持ち運べること
LSP（Language Server Protocol）は、言語ごとの補完や定義ジャンプ、診断といった機能を、対応する複数のエディタから利用しやすくするための仕組みだ。今回JetBrainsは、長年IntelliJ IDEAで磨いてきたJava/Kotlinの言語技術を、その境界の外へ出した。
これは「どちらのIDEが勝つか」という雑な勝負より大事だ。たとえば、チームがVS CodeやCursorを標準にしていても、Java/Kotlinの解析やリファクタリングでIntelliJ系の技術を試せる。逆にIntelliJ IDEAを主に使い続けるチームも、特定の作業やAI支援の流れでVS Code系を選ぶ余地ができる。ツールへの忠誠心ではなく、開発者が環境を移動できることに価値がある。
JetBrainsは、LSPサーバーがエージェント型の開発フローにも使え、将来的にはより高速で決定論的な結果やトークン消費削減につながり得るとしている。ただし、端末ベースのエージェント運用での効果は、現時点では同社の試験・実験段階の説明だ。導入効果として断定するには、公開される検証結果と実プロジェクトでの再現を待つべきだろう。
試すなら、まず三つを確認したい
- 既存拡張との重複：JetBrainsは、Red HatやOracleのJava拡張と解析・クイックフィックスが重なるため、試用中は無効化を推奨している。二重に入れて「補完が変だ」と騒ぐ前に、役割を一度整理したい。
- 初回インデックスの負荷：大きなリポジトリほど、導入直後の快適さだけでは判断できない。CIやビルド、リモート開発環境も含めて、チームの実データで確かめるべきだ。
- ライセンスとデータ共有：プレビュー中は無償だが、各ビルドには30日の期限がある。JetBrainsはプレビュー後にIntelliJ IDEA Ultimateのサブスクリプションを必要とする予定としている。導入時にはEULAとデータ共有ポリシーへの同意も求められるため、会社利用なら法務・調達を後回しにしない方がいい。
囲い込みをほどくのは歓迎する。ただし評価は本番で
JetBrainsは「Java/Kotlin開発の最良の場所はIntelliJ IDEAの中だ」と主張しつつ、他のエディタを選ぶ実務上の理由も認めている。この二段構えは商売としては正直だ。自社IDEの価値は守りながら、その知性を外部にも届ける。完全な開放ではないが、囲い込みだけを目的に便利な技術を閉じ込めるより、ずっと健全だと俺は思う。
今すぐ全員がIDEを乗り換える必要はない。むしろプレビュー版を本番環境へ無反省に投入するのは、便利そうな殻を見つけたからといって中身を確かめずに潜り込むようなものだ。だが、VS Code系を使いたい理由と、IntelliJの言語支援を手放したくない理由を両立させる道が見えた。開発環境の自由とは、選択肢が多いことではない。選んだあとでも、必要な能力を持ち運べることだ。
Java/Kotlinのチームなら、小さなサービスか非重要ブランチで試し、補完、解析、リファクタリング、起動・デバッグ、初回インデックス時間を既存環境と比べてみるといい。IDE論争を終わらせる必要はない。ただ、仕事の判断を派閥から取り戻すには十分な材料になりそうだ。