JetBrainsは、Windows上のRiderとReSharperのユーザーが報告していた起動の遅さは、2つのツールのアーキテクチャだけが原因ではなく、起動時にMicrosoft Defenderが実行するスキャン処理と大きく関係していたことを明らかにした。同社の結果によると、ReSharperがVisual Studioの外部で独立したプロセスとして動作する場合、初回起動時にDefenderが数十秒を加えていた一方、ほかのツールではスキャンが1秒未満で完了していた。
この結果は、ReSharperがアウトプロセス実行（Out-of-Process、またはOOP）アーキテクチャを採用した後に得られたものだ。これは、Visual Studioの応答性に対するReSharperの影響に対処するためJetBrainsが開発したアーキテクチャである。同社は前年にOOPモードを一般公開し、ReSharper 2026.2.1ではデフォルトで有効にした。内部測定では全般的な性能向上が示されたものの、ユーザーから起動が遅くなったという報告が寄せられ始めたため、JetBrainsはより詳細な分析を実施した。
遅延はどこで発生したのか？
JetBrainsは、ETW（Event Tracing for Windows）を通じたMicrosoft Defenderのトレースログと、プロセッサー時間の直接測定に焦点を当てた。同社はMicrosoft-Antimalware-Engineプロバイダーのイベント、特に各スキャン処理の開始と終了を記録するStreamScanRequestTaskイベントを使用した。
データからは、書き込み保護されたパスにあるファイルには信頼ルールが適用され、Defenderが起動時により軽い処理を行うことが示された。一方、ReSharperが独立したプロセスとして動作し始めると、ユーザーのインストールフォルダーから読み込まれるDLLライブラリを含め、完全なスキャンを受けた。その結果、スキャン時間はおおむね数秒から、場合によっては数十秒へと増加した。
JetBrainsは数十種類の開発ツールを分析し、ツール間に大きな違いがあることを確認した。JetBrainsのIDEと、その他のエディター系ツールにおけるコールドスキャン時間はおおむね10～40秒だったのに対し、同じテストでMicrosoftのIDEとその他の編集ツールでは1秒未満にとどまった。コマンドラインベースのツールはおおむね2秒未満で完了したが、同社はこれについて、実行ファイルが小さく、DLLライブラリの数が限られているためだと推測した。
テストとMicrosoftとの協力
測定は、16コアのIntel Core Ultra 9 285Hプロセッサーと64ギガバイトのDDR5メモリを搭載したDell Pro Max 16（MA16250）で、Windows 11 Proを使用して実施された。ツールは、8基のvCPUと8ギガバイトの固定メモリを割り当てたHyper-V上の仮想マシン内で実行された。JetBrainsは各ツールを10回測定し、ファイルとメモリのキャッシュの影響を抑え、コールドスタートを再現するため、各試行の前に仮想マシンを再起動した。
利用可能なドキュメントを確認した後も、JetBrainsは当初、すべてのスキャンルールを説明できなかったため、Microsoftのチームに連絡した。この協力により、Defenderがより多くの処理を実行する要因の特定が進み、RiderがIntelliJ IDEAとReSharperを合わせた場合よりも高密度のスキャンを受ける理由も明らかになった。
Microsoftは、書き込み保護されたフォルダー内にインストールされたRiderとReSharper OOPの特殊なケースに対処するため、Defenderのバージョン1.449.454.0で変更をリリースした。しかし、JetBrains Toolboxはデフォルトで%LOCALAPPDATA%\Programsパスにインストールされる。このパスは昇格した権限なしで書き込みが可能であるため、保護されたフォルダーに関連する改善の恩恵を受けない。JetBrainsは、Toolbox経由でのRiderのインストールとMicrosoft Defenderの除外を扱う最善の方法を引き続き評価している。
Defenderの影響を測定するツール
JetBrainsは、開発者や公開者が同じ調査を実施できるよう、Defender Performance Toolを公開した。このツールでは、アプリケーションの起動、プラグインの読み込み、コンパイル処理の実行中にスキャン活動をリアルタイムで監視できる。また、New-MpPerformanceRecordingを使用して事前に記録したスナップショットを開き、後から分析することもでき、複数のスナップショットを扱う際にはCSVデータをエクスポートできる。
JetBrainsは、Microsoft Defenderへのローカルな除外追加が、管理された環境ではシステム管理者によって禁止されている可能性があると指摘している。そのため、これは常に利用できる解決策として提示されておらず、遅さの原因を理解することや、組織のセキュリティポリシーに代わる自動的な手段として扱うべきでもない。
開発者にとって実際に何が変わるのか？
このケースは、開発環境の性能測定が、アプリケーションの実行時間やツール自体のメモリ消費だけに限られないことを示している。遅延はプログラムと並行して動作するセキュリティ層で発生する場合があり、その影響はインストール方法、ファイルの場所、起動時に読み込まれるライブラリの数によって異なる。
JetBrainsは、Microsoft Defenderの定義を最新に保ち、Defenderの性能調査用PowerShellモジュールを使用し、原因不明の遅さに気付いた場合は新しい測定ツールを試すことを推奨している。また、書き込み保護されたフォルダーへのプログラムのインストール、必要に応じてAdd-MpPreferenceコマンドを使用した除外設定、リポジトリとパッケージのキャッシュを保存するためのDev Driveの作成も挙げている。
編集部の見解：最も重要な変化は、RiderやReSharper内部の単なる改善ではなく、開発ツールの設計とセキュリティスキャンの仕組みとの間にある、分かりにくい相互作用が明らかになったことだ。ただし、結果は特定のテスト環境、仮想マシン、限られた測定回数に関連しているため、すべてのWindowsユーザーが同じ差に直面することを証明するものではない。本稿の実務的な価値は、保護設定を変更する前に原因を検証するための方法とツールを提供している点にある。一方、JetBrains Toolboxのインストールへの対応と、システム管理者が課す制限については、依然として未解決の問題として残っている。