JetBrains IDEのWSL連携がNative modeへ：9P・Remote Developmentとの違いと移行の実務

JetBrainsのWSL開発は「Native mode」が標準に

JetBrains IDEでは、これまでWSL上のプロジェクトを開く方法として、9P経由のファイルアクセス、WSLg、Remote Developmentなど複数のアプローチが存在していました。入口によって内部アーキテクチャが異なるため、同じWSLプロジェクトでも、ファイル操作の速度やプラグインの互換性、UIの応答性に違いが生じることがあります。

JetBrainsは2026.2リリース以降、WSLプロジェクトを開く方法としてNative modeを推奨します。対象となるIntelliJ IDEA、WebStorm、PhpStormでは、Windows上で動作するIDEと、WSL内で動作する小さなエージェントを組み合わせて開発環境を構成します。

この記事では、従来方式の課題とNative modeの仕組みを整理し、Java・Spring、JavaScript、PHP開発やIDEプラグイン開発にどのような影響があるのかを解説します。

WSL連携で難しいポイントは「ファイル」と「プロセス」

WSL上のプロジェクトをWindows側のIDEから扱うには、単にエディターでファイルを表示できればよいわけではありません。実際の開発では、次のような処理が常に発生します。

• プロジェクトツリーの走査
• ソースコードや依存ライブラリのインデックス作成
• シンボリックリンクの解決
• WSL内のJDK、Node.js、PHPなどの実行
• ビルド、テスト、デバッグ、プロファイリング
• Gitなどのバージョン管理操作
• ターミナルや実行構成からのコマンド呼び出し

これらの処理がWindowsとWSLの境界を何度もまたぐと、ファイル数の多いプロジェクトほど待ち時間が増えます。特にJavaScriptの依存関係や、Spring Frameworkのような大規模なマルチモジュールプロジェクトでは、インデックス作成やファイル走査の影響が目立ちます。

これまでの3つのアプローチと課題

9Pによるファイルアクセス

従来の方式では、Windows側のIDEがWSL内のファイルを扱うために、9Pベースのファイルシステム層を利用していました。WSL内のファイルをWindows側から参照できる一方、Linux環境のファイルシステムをWindows側から透過的に扱うことには限界があります。

主な課題は次のとおりです。

• Linuxのシンボリックリンクを正しく扱えないケースがある
• pnpmワークスペースやPython仮想環境、Composerのパスリポジトリなどで問題になりやすい
• 多数の小さなファイルを扱うと、WindowsとWSL間の通信遅延が積み重なる
• Microsoft Defenderのオンアクセススキャンが読み込み時間を大きく延ばす場合がある
• IDEのインデックス作成など、ファイルアクセス回数の多い処理で性能低下が表れやすい

また、WSL内でコマンドを実行するために、IDE側でLinuxパス、作業ディレクトリ、環境変数、実行ファイルなどを考慮する必要がありました。こうしたWSL固有の処理がIDE内部に広がるほど、保守や機能拡張も難しくなります。

WSLgでLinux版IDEを動かす

WSLgを使えば、WSL内でLinux版のGUIアプリケーションを起動し、その画面をWindowsデスクトップに表示できます。IDE本体をプロジェクトと同じLinux環境に置けるため、ファイルアクセスという観点では合理的です。

一方、JetBrainsはこの構成を推奨していません。Linux GUIアプリケーションをWindows上に投影する構成では、Windowsネイティブアプリケーションとしての操作感や統合性を維持しにくいためです。レンダリング、ポップアップ、ウィンドウ管理、入力方式など、WSLgやWaylandに依存する制約もあります。

そのため、WSLgによるIDE実行は技術的には可能でも、専用の製品体験として設計された標準ワークフローではありません。

Remote Development

Remote Developmentでは、IDEのバックエンドをWSL内で動作させ、Windows側にはクライアントを配置します。インデックス作成、コード解析、ビルド、デバッグ、VCS操作などの重い処理をWSL内で実行できるため、Linuxファイルシステムを直接扱える点がメリットです。

しかし、クライアントとバックエンドを分離することで、別のコストが発生します。

• IDEバックエンドのダウンロードとインストールが必要になる
• バックエンドだけで約2GBのディスク容量を必要とする
• ユーザー操作やUI状態をクライアントとバックエンド間で継続的に同期する
• 動的なUIでは通信や分割構成による遅延が発生する可能性がある
• IDEやプラグインの開発側でもクライアントとサーバーの分割を意識する必要がある

Remote Developmentは有効な選択肢である一方、WSL上のプロジェクトをローカルのWindows IDEから自然に扱うという目的には、より軽量な構成が求められていました。

Native modeの中核となるIJent

Native modeでは、Windows上のIDEをそのまま使いながら、WSL内のファイルやプロセスには専用エージェントのIJentを介してアクセスします。

イメージとしてはクライアントとサーバーの組み合わせですが、Remote Developmentのバックエンドほど大規模ではありません。IJentはIDEの環境アクセスに特化した薄いコンポーネントであり、WSL内で次のような処理を担当します。

• Linuxのファイルシステムに対する操作
• WSL内のプロセスやツールの実行
• シンボリックリンクを含むLinux固有のパス解決
• IDEやプラグインから要求された環境操作の仲介

IJentはRustで実装されています。JavaやKotlinのランタイムをWSLやコンテナ内に追加する必要がないため、エージェント自体を小さく保ちやすい構成です。

通信には標準入出力を利用し、WSLではHyper-Vソケットによる高速な経路も利用できます。これにより、ファイアウォールの影響を受けにくい構成と、ファイル転送が多い場面での効率化を両立しています。

シンボリックリンクをLinux側の意味で解決できる

Native modeで重要なのは、ファイル操作をWindows側の9P経由で代行するのではなく、IJentがWSL内で実行する点です。パス解決がLinux環境で行われるため、シンボリックリンクもLinuxのファイルシステム semanticsに沿って扱われます。

これは、次のような構成を利用する開発者にとって実務的な意味があります。

• pnpmワークスペース
• Pythonの仮想環境
• Composerのパスリポジトリ
• シンボリックリンクを含む社内共通ライブラリ
• 複数モジュールや生成物をリンクで接続するプロジェクト

もちろん、個別のプラグインやツールが独自にWindows側のファイルAPIを使っている場合は、Native modeの恩恵を完全に受けられない可能性があります。この点で重要になるのが、後述するEelApiです。

EelApiがもたらすプラグイン開発の変化

IJentだけでは、IDEのすべてのコードが自動的に環境差を吸収できるわけではありません。そこでJetBrainsは、ローカル環境とWSL、Docker、Dev Containerなどの違いを抽象化するAPIとしてEelApiを導入しています。

EelApiの狙いは、IDE本体やプラグインのコードが、実行対象の環境を直接意識しなくて済むようにすることです。プラグインから見た環境が、Windows上のローカル環境なのか、WSL内なのか、コンテナ内なのかを可能な限り共通のインターフェースで扱います。

プラグイン開発者にとっては、次の観点が重要になります。

• ファイル操作を独自のWindows APIに固定しない
• 実行ファイルや作業ディレクトリの扱いを環境依存にしない
• パスの区切り文字やシンボリックリンクを前提にした処理を見直す
• WSL、Docker、Dev Containerでも成立する処理経路を意識する
• プラグインが利用する外部ツールの実行場所を明確にする

JetBrainsのプラットフォーム側がEelApiに対応していても、すべてのサードパーティープラグインが直ちに同じレベルで対応するとは限りません。WSLをチーム標準にする場合は、利用中のプラグインがファイル操作や外部コマンド実行をどのように実装しているかが、互換性を左右します。

ベンチマークで見るNative modeの効果

JetBrainsが示した性能測定では、Windows 11、WSL 2、Ubuntu 24.04、IntelliJ IDEA Ultimateの環境で、spring-frameworkを比較しています。対象は23サブプロジェクト、8,191個のソースファイルを含む大規模プロジェクトです。

特にプロジェクトツリーの走査とファイル内容の読み込みで大きな差が出ています。これは、ファイル数が多く、IDEが大量のファイルを繰り返し処理するプロジェクトほど効果を感じやすいことを示します。

ただし、この結果は特定のプロジェクトと環境における測定値です。ソースファイルが少ない小規模プロジェクトでは、測定上の明確な差は確認されませんでした。WSL環境全般で一律に同じ短縮幅になると考えるのではなく、プロジェクト規模やファイル構成によって効果が変わると見るべきです。

Java・JavaScript・PHP開発への影響

Java・Spring

SpringやGradle、Mavenを使う大規模なJavaプロジェクトでは、ソースファイルやモジュール数の多さから、初回起動時の走査とインデックス作成が負荷になりやすい領域です。Native modeでは、プロジェクトファイルをWSL側のLinuxファイルシステムとして扱えるため、初回起動や再インデックス時の待ち時間短縮が期待できます。

また、JDKやビルドツールをWSL側に統一しているチームでは、IDEから実行するビルド、テスト、デバッグと、ターミナルで実行するコマンドの環境差を小さくできます。

JavaScript・TypeScript

node_modulesのように大量の小さなファイルを扱うプロジェクトでは、ファイルアクセスの遅延が開発体験に影響します。pnpmワークスペースなど、シンボリックリンクを多用する構成では、従来方式の制約が問題になりやすいため、Native modeのLinux側パス解決は重要です。

ただし、Node.js、パッケージマネージャー、実行構成がWSL側にあるのかWindows側にあるのかは、チーム内で明確にしておく必要があります。IDEだけNative modeに切り替えても、ツールチェーンの配置が混在すると、別のパスや環境変数の問題が発生します。

PHP

PhpStormでComposerのパスリポジトリやシンボリックリンクを利用している場合、Linux側のファイル構造を正しく参照できることは、コード補完やインデックス作成の安定性に関係します。PHP本体、Composer、デバッグ環境をWSL内に置く構成では、Native modeとの相性を検証しやすいでしょう。

既存プロジェクトを移行する際のチェックポイント

Native modeへの移行は、単にIDEを新しいバージョンへ更新するだけで完了するとは限りません。特にチーム開発では、個人のIDE設定とプロジェクト設定、プラグイン、ツールチェーンの組み合わせを確認することが重要です。

1. プロジェクトの保存場所を確認する

Native modeの効果を得るには、プロジェクトがWSL側のファイルシステムに置かれていることが前提になります。Windows側のディレクトリをWSLから参照している構成では、今回のファイルアクセス改善とは異なる特性になります。

2. WSL内のツールチェーンを整理する

次の実行環境がどこにあるかを整理します。

• JDK、Gradle、Maven
• Node.js、npm、Yarn、pnpm
• PHP、Composer
• Git
• デバッガーやプロファイラー
• Docker CLIや関連する開発ツール

IDEの実行構成だけでなく、ターミナルから同じコマンドを実行した場合にも、意図したWSL内のバイナリが使われる状態にしておくと、環境差を抑えられます。

3. プラグインのファイル操作を確認する

コード解析や実行補助を行うプラグインが、IDEの標準API経由でファイルやプロセスを扱っているかは重要です。独自にWindowsパスを生成したり、Windows側の実行ファイルを直接呼び出したりするプラグインでは、Native modeで想定外の動作になる可能性があります。

4. Remote Developmentとの役割を整理する

WSLプロジェクトを開く場合、Native modeが推奨されます。一方、Remote Developmentの入口も引き続き利用できます。既存の運用でRemote Developmentを採用しているチームは、すぐに全面移行するのではなく、次の点を比較するとよいでしょう。

• IDEバックエンドをWSL内に置く必要があるか
• クライアントとバックエンドの分離が運用上メリットになるか
• 利用中のプラグインが分割構成に対応しているか
• IDE起動やバックエンド更新にかかる時間を許容できるか
• WindowsネイティブIDEとしての操作感を重視するか

5. チーム標準の開発手順を更新する

個人がIDEのWelcome画面から異なる入口を選ぶと、同じリポジトリでも実行方式が揃わないことがあります。チームで標準化する場合は、プロジェクトの開き方、WSLディストリビューション、ツールチェーンの配置、利用プラグインをドキュメント化しておくと、環境差による問い合わせを減らせます。

Native modeはWSL専用の改善にとどまらない

IJentとEelApiの設計は、WSLだけを対象にしたものではありません。JetBrainsは同じエージェントモデルをDockerやDev Containerにも適用しています。

これは、開発環境を次のように段階的に変えていくチームにとって意味があります。

• 個人開発ではWSLを利用する
• CIや検証環境ではコンテナを利用する
• プロジェクトごとにDev Containerを定義する
• 将来的に開発環境をクラウドやリモート環境へ広げる

実行環境が変わっても、IDEやプラグインが環境差を直接処理するコードを減らせれば、移行コストを抑えやすくなります。Native modeは、WSLのファイルアクセスを速くするだけでなく、ローカルと非ローカルの開発環境を共通のモデルで扱うための基盤として位置付けられます。

まとめ：まずは大規模プロジェクトから効果を測る

JetBrainsのWSL連携は、複数の実装を経て、Windows上のIDEとWSL内のIJentを組み合わせるNative modeへ整理されます。9P方式で課題になっていたシンボリックリンクやファイルアクセスの遅延を、Linux側での処理と専用プロトコルによって改善する設計です。

実務上のポイントは次のとおりです。

• 2026.2以降、WSLプロジェクトを開く推奨入口はNative mode
• 大規模プロジェクトでは、走査やファイル読み込みの短縮が期待できる
• シンボリックリンクを多用するpnpm、Python、Composer環境で効果を確認しやすい
• プラグインはEelApi対応や独自のファイル・プロセス操作が互換性を左右する
• Remote DevelopmentやWSLgは用途が異なり、Native modeと同一視しない
• WSL、Docker、Dev Containerをまたぐ開発環境標準化の基盤にもなり得る

まずはSpringやフロントエンドの大規模リポジトリなど、現在の起動・インデックス作成に時間がかかっているプロジェクトでNative modeを試すのが現実的です。体感だけで判断せず、初回起動、再インデックス、テスト実行、デバッグ開始までの時間を既存環境と比較すれば、自分たちの開発フローにおける効果を評価しやすくなります。

出典： JetBrains Blog