2026.2リリース以降、Windows Subsystem for Linux、またはWSL内に存在するプロジェクトをIntelliJ IDEA、WebStorm、PhpStormから開くと、JetBrainsがNativeモードと呼ぶ方式に移行する。このモードではIDE自体はWindows上で動作するアプリケーションのままだが、WSL内の小さなエージェントがIDEに代わってファイル操作やプログラムプロセスを実行する。同社は現在これを推奨されるエントリーポイントとしており、Remote Developmentのオプションはウェルカム画面から引き続き利用できるものの、WSLプロジェクトを開く際の優先方式ではなくなった。
これはユーザーインターフェース上の名称変更だけに関するものではない。WSL内に存在するLinuxプロジェクトをサポートするには、開発環境がファイルへアクセスし、正しいパスでツールを実行し、環境変数を管理し、ビルド、デバッグ、プロファイリングのプロセスを実行しながら、体感が自然に感じられるほど低い応答時間を維持する必要がある。JetBrainsは、従来の方式ではエントリーポイントに応じて異なるアーキテクチャーが使われていたため、製品やシナリオ間で性能と動作にばらつきが生じていたと説明している。
なぜ9Pの経路では不十分になったのか？
従来のアプローチでは、Windows上のJetBrainsアプリケーションが9Pファイルシステムプロトコルを介してWSLのファイルにアクセスし、GeneralCommandLineクラスがLinux環境内で実行されるコマンドの正規化を担っていた。これによりWSLプロジェクト上でIDEを動作させられたが、読み取りとインデックス作成の処理の大部分が、WindowsとWSLをホストする仮想マシンの境界を越えて行われていた。
JetBrainsによれば、主な問題は3つあった。第一に、9Pは\wsl$パス経由でLinuxのシンボリックリンクを正しく表示しないため、IDEが一部のツリーを解決またはインデックス化できない可能性がある。この問題は、pnpmワークスペース、Pythonの仮想環境、パスに依存するComposerリポジトリなど、シンボリックリンクを使用する環境に影響する。第二に、アクセス時のMicrosoft Defenderによるスキャンにより、WSLファイルの読み取りが数十秒長引く場合がある。第三に、このプロトコルはインデックス作成のように多数の小さなファイルを扱う処理に大きな時間を加える。
さらに、コマンド実行レイヤーによって、プラットフォーム開発者はコードベースのさまざまな部分でWSL固有のセマンティクスを扱う必要があった。JetBrainsは、これによりこのアプローチは、非ローカル開発環境向けの統一された基盤となるどころか、拡張と保守がより難しくなったと考えている。
Remote Developmentが追加したものとは？
Remote Developmentは、逆方向からこの問題に対処した。IDEの完全なバックエンドがWSLへ移動し、Windows側にはインターフェースを表示してユーザー入力を受け取るクライアントが残る。両者はJetBrains RDプロトコルを介して通信し、イベントモデル、エディターの状態、プロジェクトの状態を双方向に転送する。一方、インデックス作成、解析、ビルド、デバッグ、バージョン管理操作などの負荷の高い処理は、ファイルの近くにあるWSL内で実行される。
この設計によりファイルアクセスで9Pへ直接依存する必要はなくなったが、別のコストが加わった。JetBrainsによれば、バックエンドには約2GBの追加ディスク容量が必要であり、WSL内でダウンロードとインストールを行う時間も必要になる。また、クライアントとバックエンドの継続的なやり取りでは、インターフェースの状態とユーザー入力が常に転送されるため、応答性に影響する可能性がある。製品開発ではクライアントとサーバーの間でコードを分割する必要があり、一部のモジュールが分割されないままだと、動的なインターフェースで遅延やフリーズが発生する可能性がある。
Nativeモードはどのように動作するのか？
新しいアプローチは、IJentと呼ばれるエージェントを基盤としている。このエージェントは、9Pや汎用的な実行レイヤーを介して処理を渡すのではなく、対象環境内でファイル操作とプログラムプロセスを実行する。JetBrainsは、これはRustで記述された小さなコンポーネントであり、WSLやコンテナ内にJavaやKotlinなどの追加のランタイム依存関係を必要としにくくすると説明している。
IJentはStdioに基づく転送レイヤーを使用する。これは移植可能で、ファイアウォールのポートを開く必要がない。一方、WSLのHyper-Vソケットは、特に大量のファイルを転送する際に、より高速な経路を提供する。ファイルシステム操作はLinux環境そのもので実行されるため、パスとシンボリックリンクの処理はLinux本来のセマンティクスに近くなる。外部プラグインも、関連するファイル操作がIJentを経由する場合、この恩恵を受ける。
IJentは、JetBrainsがプラットフォーム開発者やプラグイン作成者に対してローカル環境とリモート環境の違いを隠すために設計したEelApiインターフェースと連携する。このモデルでは、同じコードで、ローカル環境、WSL、Docker、Dev Containerのいずれにも、それぞれの環境専用のロジックを追加せずに対応できる。同社によれば、IJentはEelApiを実装し、その実際の機能を提供する。
テスト結果は何を示しているのか？
JetBrainsは、23のサブプロジェクトと8,191個のソースファイルを含むspring-frameworkプロジェクトのコールドオープンテストで、9PモードとIJentモードを比較した。測定はWSL 2、Ubuntu 24.04、IntelliJ IDEA Ultimate 263.SNAPSHOTを搭載したWindows 11上で行われ、結果には5回の実行の中央値を用いた。
- 作業可能になるまで：18.5秒から11.5秒に短縮され、38%改善。
- プロジェクトツリーのスキャン：8.1秒から3.7秒に短縮され、54%減少。
- ファイルのインデックス作成：10.8秒から8.4秒に短縮され、22%改善。
- ファイル内容の読み取り：12.2秒から5.7秒に短縮され、53%減少。
同社は、少数のファイルしか含まない小規模プロジェクトでは、同じテストで測定可能な差が見られなかったと注意を促している。そのため、実際の最大のメリットは、大規模プロジェクトや、多数のファイルへのアクセスを繰り返すワークフローに関係する。
これは開発者にとって何を意味するのか？
最も重要な変更は、従来のすべての選択肢を直ちに廃止することではなく、推奨されるエントリーポイントとアーキテクチャーを統一することだ。対応製品でWSLプロジェクトを直接開くユーザーはNativeモードを利用する一方、Remote Developmentは、その経路を選択するユーザーや、クライアントとバックエンドを分離したモデルを必要とするユーザーにとって引き続き有用である。WSLg経由でIDE自体を実行することについては、技術的には可能だとJetBrainsは述べているが、描画、ウィンドウ管理、入力に関する制約や、Windows内のLinux表示レイヤーへのアプリケーションの依存により、第一級のサポート対象ワークフローではない。
公開された結果は一部の処理で目に見える改善を示しているが、テストの範囲は特定のプロジェクト、環境、バージョンに限られている。そのため、数値はすべてのプロジェクトやプラグインで一貫した優位性を証明するものではない。また、より多くのJetBrains製品で新しいアーキテクチャーを採用する作業は現在も進行中であり、さまざまな環境におけるプラグインの互換性と動作は、引き続き注目すべき点となる。