IDEの起動時間を左右する「アプリの外側」の処理
RiderやReSharperの起動が遅いとき、まず疑うのはプラグインの初期化、DLLのロード、インデックス作成、あるいはCPUやストレージの性能です。しかし、JetBrainsの調査では、Windows上の起動遅延にMicrosoft Defenderのスキャン処理が大きく影響しているケースが明らかになりました。
特に、ReSharperのアウト・オブ・プロセス（OOP）アーキテクチャでは、Visual Studioとは別プロセスとして動作するようになったことで、Defenderから従来とは異なる扱いを受け、初回起動に数十秒規模の遅延が発生する場合がありました。
この事例は、開発環境の性能問題を調査するときに、アプリケーション本体だけでなく、OSのセキュリティ機能やファイル配置まで含めて考える必要があることを示しています。
OOP化で性能は改善したのに、起動だけ遅くなった
ReSharperでは、Visual Studioの応答性を改善するため、解析機能などを別プロセスで動作させるOOPアーキテクチャが開発されました。JetBrainsのテレメトリーでは全体的な性能改善が確認された一方、ユーザーからは起動時間が遅くなったという報告が寄せられました。
プロファイリングを進めた結果、想定外のボトルネックとして浮上したのがMicrosoft Defenderです。
JetBrainsの説明によると、書き込み保護されたディレクトリにあるファイルやプロセスは、Defenderによるスキャンが比較的短時間で済む場合があります。一方、ユーザーが書き込み可能なインストール先からDLLを読み込む別プロセスでは、起動時により広範なスキャンが実行され、初回起動の壁時計時間を大きく押し上げることがありました。
つまり、同じ機能を持つツールでも、次のような条件によって起動時間が変わる可能性があります。
- プロセスがインプロセスかアウト・オブ・プロセスか
- 実行ファイルやDLLが保存されているディレクトリ
- 起動時にロードするファイル数や構成
- Defenderの定義ファイルやバージョン
- ファイルやメモリのキャッシュ状態
ツールごとにスキャン時間は大きく異なる
JetBrainsは、複数の開発ツールを対象にMicrosoft Defenderの挙動を測定しました。報告された傾向は次の通りです。
- JetBrains IDEや一部のエディター系ツールでは、コールドスタート時におよそ10～40秒のスキャン時間が発生
- Microsoft製IDEや一部のエディターでは、スキャン時間が比較的小さく、1秒未満のケースも存在
- CLIベースのツールでは、実行ファイルやDLLの構成が比較的小さいため、概ね2秒未満
- JetBrains Riderは、IntelliJ IDEAとReSharperを組み合わせた場合よりも集中的なスキャンを受けるケースがあった
ただし、これは特定の測定環境における結果です。JetBrainsは、Intel Core Ultra 9 285H、64GBメモリ、Windows 11 Proを搭載したホスト上のHyper-V仮想マシンで、8 vCPU、8GBメモリの構成を使い、各ツールを10回測定しました。コールドスタートを再現するため、測定ごとに仮想マシンを再起動しています。
実際の環境では、Defenderの設定、ストレージ性能、仮想化の有無、キャッシュ状態などによって結果は変わります。重要なのは、「IDEの起動が遅い」という体感を、OSのバックグラウンド処理も含めて測定することです。
ETWログでDefenderの処理時間を確認する
Windowsでは、さまざまなシステムコンポーネントがETW（Event Tracing for Windows）を使ってイベントを出力しています。Microsoft Defenderも例外ではなく、Microsoft-Antimalware-Engineプロバイダーを通じてスキャン関連のイベントを記録します。
JetBrainsの調査では、特にStreamScanRequestTaskイベントの開始時刻と終了時刻を利用し、Defenderが各ストリームのスキャンに費やした実時間を確認しました。
Defenderには、性能調査向けのPowerShellコマンドレットが用意されています。代表的なものは次の2つです。
New-MpPerformanceRecording：Defenderの動作をトレースとして記録Get-MpPerformanceReport：記録したトレースを分析
基本的な調査の流れは、次のようになります。
- 起動前にパフォーマンス記録を開始する
- RiderやReSharperなど、対象ツールを起動する
- プラグインの読み込みやビルドなど、問題が発生する操作を再現する
- 記録を停止し、Defenderのスキャン時間を分析する
- アプリケーションのプロファイリング結果と時系列で突き合わせる
実際のコマンドやオプションは、利用しているWindows環境のDefender PowerShellモジュールに合わせて運用します。管理端末ではPowerShellの実行やDefender設定が制限されている場合もあるため、個人の判断で設定変更するのではなく、組織の端末管理ポリシーに従う必要があります。
インストール先が性能に影響する理由
今回の調査で特に重要なのが、アプリケーションをどのディレクトリにインストールするかという点です。
JetBrains Toolboxは、ソフトウェアを%LOCALAPPDATA%\\Programsにインストールします。この場所はユーザー権限で更新しやすく、Toolboxがシームレスにアップデートできる利点があります。一方で、書き込み保護されたディレクトリと同じスキャン上の最適化を受けられない可能性があります。
これは、開発ツールの配布・更新方式とセキュリティ製品の信頼モデルが衝突する例です。
- ユーザーが更新しやすい場所は、書き換え可能である
- 書き換え可能な実行ファイルは、セキュリティ上より慎重に検査される可能性がある
- 書き込み保護された場所は、管理者権限や更新方式とのトレードオフがある
- 同じアプリケーションでも、インストール先によって起動時間が変わる場合がある
JetBrainsはMicrosoftと調査を進め、特定のケースに対するDefender側の最適化がバージョン1.449.454.0で提供されたと説明しています。また、書き込み保護されたディレクトリにインストールしたRiderやReSharper OOPでは、スキャン性能の改善が得られるとしています。
Defenderの除外設定は効果とリスクを分けて考える
Defenderの除外設定によって、Riderの初回起動時に発生するオーバーヘッドを軽減できる場合があります。JetBrainsは、Riderのインストール時に一部のディレクトリをDefenderの除外対象に追加する仕組みを説明しており、Add-MpPreferenceコマンドレットが利用されています。
ただし、除外設定は単純な高速化スイッチではありません。対象ディレクトリに悪意のあるファイルが置かれた場合、リアルタイム保護による検出機会が減る可能性があります。
運用では、次の点を明確にすることが重要です。
- 除外対象を必要最小限のディレクトリに限定する
- ソースコード全体ではなく、用途を限定したキャッシュや特定のインストール先を対象にする
- 除外を設定したユーザー、理由、対象パスを記録する
- 端末のセキュリティポリシーや監査要件と整合させる
- 管理者が設定を禁止している端末では、無理に回避しない
企業の管理端末では、ローカルユーザーが除外設定を追加できないよう制御されている場合があります。その場合は、エンドポイント管理者がリスク評価を行い、組織全体のポリシーとして設定する必要があります。
Dev Driveも開発環境の選択肢になる
JetBrainsが挙げる実務上の対策の一つが、リポジトリやパッケージキャッシュをWindowsのDev Driveに保存することです。
Dev Driveは開発用途を想定したストレージ領域で、ソースコード、依存パッケージ、ビルド中間生成物などを置く場所として利用できます。IDE本体の起動遅延を直接すべて解決するものではありませんが、ファイルI/Oが多い開発作業では、保存場所を整理する手段になります。
導入を検討する場合は、次のように役割を分けると整理しやすくなります。
- IDE本体やプラグインのインストール先
- Gitリポジトリの保存先
- NuGet、npm、Mavenなどのパッケージキャッシュ
- ビルド成果物や一時ファイルの保存先
- Defenderの除外対象とする範囲
開発者・IT管理者が取るべき調査手順
起動の遅いツールに遭遇した場合、いきなりDefenderを無効化するのではなく、再現条件を固定して原因を切り分けます。
1. コールドスタートと2回目の起動を分ける
再起動直後の初回起動だけが遅いのか、2回目以降も遅いのかを確認します。初回だけ遅い場合は、ファイルやメモリのキャッシュ、Defenderの初回スキャンが関係している可能性があります。
2. 起動時間を処理単位で分解する
IDEのログやプロファイラーを使い、次の処理を分けて測定します。
- プロセスの生成
- DLLやプラグインのロード
- プロジェクトの読み込み
- インデックス作成
- ネットワークアクセス
- Defenderなど外部コンポーネントのスキャン
3. ETWとアプリケーションログを突き合わせる
Defenderのスキャンイベントと、IDE側の起動ログを同じ時間軸で比較します。アプリケーションがCPUを使っていない時間帯に、Defenderのスキャンが連続していれば、起動遅延との関係を検証しやすくなります。
4. インストール先を比較する
可能であれば、書き込み保護の扱いが異なるインストール先で、同じバージョンのツールを比較します。ただし、企業端末ではソフトウェアの配置変更が管理ポリシーに抵触しないかを確認します。
5. 設定変更は最後に行う
除外設定を試す場合は、変更前後の測定結果を残し、対象範囲を限定します。性能改善が確認できなければ、セキュリティ上の例外だけが残るため、設定を維持する合理性はありません。
調査ツールも公開へ
JetBrainsは、今回の調査に利用した「Defender Performance Tool」を公開しています。このツールでは、次のような操作が可能です。
- アプリケーションの起動中に、Defenderのスキャン活動をリアルタイムで確認する
New-MpPerformanceRecordingで取得したオフラインのスナップショットを開く- 複数のスナップショットを読み込み、CSVとして出力する
自社製のIDE、ビルドツール、エージェント、プラグインなどで起動遅延を調査する場合にも利用できます。特に、ユーザーから「環境によって起動時間が大きく違う」という報告を受けたツールベンダーにとって、OS側のスキャン時間を共通の指標で確認できる点は有用です。
まとめ：性能問題はセキュリティ境界の中で起きる
RiderやReSharperの事例から得られる最大の教訓は、開発ツールの性能はアプリケーションのコードだけで決まらないということです。
プロセスの分離、インストール先、ファイルの書き込み権限、Defenderのバージョン、キャッシュ状態といった要素が組み合わさり、ユーザーが感じる起動時間を形作ります。
実務では、次の優先順位で対策するとよいでしょう。
- Microsoft Defenderの定義ファイルと関連コンポーネントを最新状態に保つ
- ETWやPowerShellの記録を使ってスキャン時間を測定する
- IDEやツールのインストール先を見直す
- リポジトリやパッケージキャッシュにDev Driveを活用する
- Defenderの除外設定は範囲とリスクを評価したうえで適用する
- 管理端末では、個別の回避策ではなく組織のポリシーとして運用する
なお、JetBrainsはReSharper2026.2.1でOOPをデフォルトで有効化したと説明しています。OOPによる応答性向上を活かすためにも、起動時のセキュリティスキャンを含めた総合的な環境設計が重要になります。
出典： JetBrains Blog