なぜIntelliJでCopilotを使うとMacが火を噴くのか？VS Codeが軽い本当の理由

この記事はAIを使用して作成されています。投稿者側でエビデンスに基づいた正確性の確認を行っていますが、誤りが含まれている可能性があります。もし誤った情報を見つけられましたら、コメントでご指摘いただけますと幸いです。

🎯 結論：最適な解決策はハイブリッド戦略

3行でわかる結論

• 💡 Copilotを使うならVS Code：応答速度が200-400ms、メモリ消費500MB-1.5GBで安定
• 🛠️ IDE機能を使うならIntelliJ：強力なリファクタリング、型推論、統合ツールが優秀
• ⚡ 両方使い分けるのがベスト：Copilotで爆速コーディング → IntelliJで精密な開発

なぜこの戦略が最適なのか？

IntelliJ IDEAでCopilotを使うと、チャットウィンドウを開いただけでCPU使用率が100%に跳ね上がり、メモリが6-15GBまで膨張します。一方、VS Codeなら同じ作業が500MB-1.5GBの安定したメモリで快適に動作します。

根本原因はアーキテクチャの不一致です。IntelliJのJVMベース設計とPSI/インデックスシステムは高度な開発機能には最適ですが、リアルタイム性が求められるCopilotには不向きです。対して、VS CodeのマルチプロセスアーキテクチャはAI時代に最適化されています。

つまり、「完璧な1つのツール」を求めるより、それぞれの強みを活かす使い分けが最も生産的ということです。以下で、この問題の技術的背景を詳しく解説します。

---

IntelliJ IDEAでGitHub Copilotを使うと動作が重く、時々フリーズする一方で、VS Codeでは快適に動作する。この現象は2023年以降、数百件の報告があり、技術的な根本原因が明らかになっています。結論から言えば、JVMのオーバーヘッド、プラグインアーキテクチャの制約、PSI/インデックスシステムとの競合、そしてwebviewベースのチャット実装が主な原因です。この記事では、両IDE間のパフォーマンス差を技術的に深掘りします。

⚠️ なぜIntelliJ IDEAだけが重いのか

IntelliJ IDEAでCopilotが重くなる根本原因は、アーキテクチャの不一致にあります。VS Codeのサジェスト応答が200-400msなのに対し、IntelliJは1-2秒かかります。さらに深刻なのは、Copilotチャットウィンドウを開くだけでCPU使用率が100%に跳ね上がり、メモリ消費が6-15GBに達する報告が多数存在することです。

最も重大な問題は3つあります：

1. 💾 メモリリーク: CopilotTextInputTextAreaクラスがヒープの67%を占有し、最悪55GBまでメモリが膨張
2. 🧵 スレッド管理の失敗: プロジェクトファイル反復のために数百のスレッドを生成し、インデックス中のReadActionで全てブロック
3. 🔒 UIスレッドでのI/O操作: CopilotチャットがAWT-EventQueue-0（UIスレッド）でI/O処理を実行し、IDE全体をフリーズさせる

一方、VS Codeはこれらの問題がほとんど発生せず、500MB-1.5GBの安定したメモリ消費で動作します。

🏗️ アーキテクチャの決定的な違い

IntelliJ IDEA：重厚な設計の代償 ⚙️

IntelliJ IDEAはIntelliJ Platform上に構築され、Java/Kotlinで実装されています。この設計には高度な機能がある一方で、Copilotのようなリアルタイム性が求められる拡張機能には不利に働きます。

JVMベースの制約:

IntelliJはJVM上で動作するため、以下のオーバーヘッドが避けられません：

• ヒープメモリ管理: デフォルト設定では-Xmx2048m（最大2GB）ですが、Copilot有効時は4-8GB必要
• ガベージコレクション: G1GCを使用していますが、大きなヒープサイズではGCポーズが長くなる
• クラスローダー分離: 各プラグインが専用クラスローダーを持ち、メモリを圧迫

PSI（Program Structure Interface）の二面性:

IntelliJの最強の武器であるPSIは、ソースコードの構文・意味論的モデルを構築します。これはコード補完や検査に威力を発揮しますが：

• ASTノードはメモリ集約的
• PSIツリーへのアクセスはReadAction取得が必要
• Copilotがコンテキスト収集時に複数ファイルのPSIにアクセスすると、大量のメモリを消費

⚡ インデックスシステムとの競合:

IntelliJは2層のインデックスシステム（ファイルベースインデックスとスタブインデックス）を持ちます。バックグラウンドインデックス中は「Dumb Mode」に入り、多くの機能が制限されます。この時、Copilotのスレッドが全てReadActionでブロックされ、IDE全体がフリーズします。

プラグインアーキテクチャの制約:

Copilotは以下のように動作します：

エディタ → プラグインレイヤー → LSP Adapter → copilot-language-server → OpenAI API

このプラグインレイヤーが追加のレイテンシを生み出し、VS Codeの直接的な統合と比較して100-500msのオーバーヘッドが発生します。

VS Code：AI時代に最適化されたアーキテクチャ 🚀

VS CodeはElectronベース（Chromium + Node.js + V8）で、マルチプロセスアーキテクチャを採用しています。

プロセス分離の利点:

VS Codeは5種類のプロセスを使い分けます：

1. Mainプロセス: アプリケーション管理
2. Rendererプロセス: UI描画（サンドボックス化）
3. Extension Hostプロセス: 全ての拡張機能がここで実行（重要）
4. Sharedプロセス: リソース集約的操作（ファイル監視、拡張機能インストール）
5. Utilityプロセス: 言語サーバーなど専用プロセス

この設計により、Copilotの処理がUIをブロックすることが物理的に不可能です。Extension Hostプロセスがクラッシュしても、VS Codeは自動的に再起動するだけです。

通信効率の追求:

VS CodeはMessage Portsを使用した高速なIPCを実現しています：

Renderer → Message Port → Extension Host → copilot-language-server

メインプロセスを経由しないため、オーバーヘッドがゼロです。IntelliJのプラグインAPIを経由する方式と比較して、2.5-5倍高速です。

TypeScript/JavaScriptエコシステムの優位性:

copilot-language-serverはNode.js/TypeScriptで実装されており、VS CodeのExtension Host（同じくNode.js）とランタイムを共有します。これにより：

• シリアライゼーションのオーバーヘッドがない
• 直接的なAPI呼び出しが可能
• JVMブリッジのような中間層が不要

🔧 GitHub Copilot拡張機能の実装方法の違い

両IDEとも同じcopilot-language-serverを使用していますが、統合方法が全く異なります。

共通基盤：Language Server Protocol 📡

Copilotは標準LSPに加えて、独自の拡張を実装しています：

• 標準LSP: initialize, textDocument/didOpen, textDocument/didChange
• Copilot独自: textDocument/inlineCompletion, textDocument/didFocus, textDocument/didShowCompletion

このJSON-RPC 2.0ベースの通信は、stdio経由で行われます。

IntelliJ IDEAの実装：webviewの重み 🐢

致命的な設計選択: IntelliJのCopilotチャットはJCEF（Java Chromium Embedded Framework）webviewを使用しています。

これが以下の問題を引き起こします：

• webviewがDOM、JavaScriptランタイムを保持し、大量のメモリを消費
• CopilotTextInputTextAreaクラスで深刻なメモリリークが報告（ヒープの67%）
• webviewベースUIとネイティブJava Swingコンポーネント間の橋渡しでオーバーヘッド

スレッド管理の失敗:

microsoft/copilot-intellij-feedbackのIssue #298で報告されているように、Copilotは：

プロジェクトファイルを反復するために数百のスレッドを作成
→ 全てのスレッドがインデックス中のReadActionで待機
→ IDE完全フリーズ

この問題により、IDE全体が応答不能になることがあります。

VS Codeの実装：ネイティブ統合の威力 ⚡

VS Codeはハイブリッドアーキテクチャを採用：

1. Copilot Extension（TypeScript）: Extension Hostで実行、VS Code APIと直接統合
2. Copilot Language Server（Node.js）: 別プロセスで実行、JSON-RPC通信
3. UIコンポーネント: インラインサジェスト（ゴーステキスト）、チャットビュー（webview）、インラインチャット

最適化の数々:

• ⏱️ 75-120msデバウンス: 無駄なリクエストを防止
• ❌ キャンセル戦略: 新しいリクエストが来たら、前のリクエストを自動キャンセル
• 📊 ストリーミングレスポンス: サーバーサイドイベント（SSE）でインクリメンタルレンダリング
• 🎯 コンテキスト収集の効率化: ワークスペースAPI、Git API、シンボルプロバイダーAPIに同期的にアクセス可能

2025年の最新最適化:

GitHubは2025年9月に新しい埋め込みモデルをデプロイしました：

• 取得品質が37.6%向上（0.362 → 0.498スコア）
• スループットが2倍に
• インデックスサイズが8分の1に縮小
• C#コード受け入れ率が110.7%向上

この改善により、VS Codeでのメモリフットプリントがさらに削減されました。

💾 メモリ使用量の実測値比較

IntelliJ IDEA：深刻なメモリ問題 📈

通常使用時:

• Copilot無効: 2-4GB
• Copilot有効（チャット閉じた状態）: 4-8GB
• Copilotチャット開いた状態: 8-15GB 😱

極端な例（実際の報告）:

• 55GBまでメモリが膨張（プランニングセッション中）
• copilot-language-serverプロセス単体で6-15GB消費
• 仮想メモリ121.4GB（Linuxシステム）

メモリリークの証拠:

GitHub Community Discussion #84695のヒープダンプ分析によると：

メモリオフェンダーの67%が単一クラスから発生
→ CopilotTextInputTextArea

これは明確なメモリリークです。バージョン1.4.6.4092以降で特に深刻です。

VS Code：安定したメモリ管理 ✅

通常使用時:

• Copilot Extension: 100-300MB
• copilot-language-serverプロセス: 500MB-1.5GB
• 合計: 500MB-1.5GBで安定 🎉

時系列での安定性:

• 長時間使用してもメモリ使用量が一定
• メモリリーク報告は非常に稀

8分の1インデックスサイズ:

2025年の埋め込みモデル改善により、Extension Hostのメモリ圧力がさらに軽減されました。

🔥 CPU使用率の実測値比較

IntelliJ IDEA：常時高負荷 💻

深刻な事例（実際の報告）:

microsoft/copilot-intellij-feedback Issue #529より：

PhpStorm 2025.2 + M4 MacBook Pro
チャットウィンドウ開いた状態: 900%+ CPU使用率 🔥
チャットウィンドウ閉じた状態: 30-40% CPU使用率

GitHub Community Discussion #154926より：

「チャットウィンドウを開いた瞬間にCPUが100%に跳ね上がる」
「ウィンドウを閉じると即座に5-30%に戻る」
Linux、macOS、Windows全てで報告あり

根本原因:

1. 🔄 継続的な解析処理: チャットが開いているだけで、IDEがコード提案を継続的に解析
2. ⚔️ スレッド競合: 数百のスレッドが同時にReadActionを取得しようと競合
3. 📚 インデックスとの競合: バックグラウンドインデックスとCopilotの処理が同時実行

VS Code：効率的なリソース管理 🌟

通常使用時:

• アイドル: 5%未満
• アクティブなサジェスト生成中: 10-20%
• チャット使用中: 15-25%

プロセス分離の効果:

Extension Hostプロセスで処理が完結するため、Rendererプロセス（UI）には影響しません。ユーザーは常にスムーズなエディタ操作が可能です。

📚 インデックス処理などの技術的要因

IntelliJ IDEAのインデックス地獄 🌀

IntelliJの高度なインデックスシステムは、通常は強力な武器ですが、Copilotとの組み合わせでは弱点になります。

インデックス中の動作（Dumb Mode）:

1. プロジェクトを開くと、バックグラウンドでインデックス構築開始
2. インデックス中はDumb Modeに入り、多くの機能が制限される
3. Copilotがコンテキスト収集のためにReadActionを要求
4. ReadActionはインデックス完了まで取得できない
5. 数百のCopilotスレッドが全てブロックされる
6. IDE全体がフリーズ 💀

microsoft/copilot-intellij-feedbackのIssue #298で報告されたスタックトレース：

"Thread-XXX" prio=0 tid=0x0 nid=0x0 waiting on condition
at com.intellij.openapi.application.impl.ApplicationImpl.runReadAction
... (Copilotのコンテキスト収集処理)

大規模プロジェクトでの影響:

• Gradleプロジェクト（1000+ファイル）: インデックスに5-10分
• この間、Copilotは実質的に使用不可
• インデックス完了後も、ファイル変更のたびに増分インデックスが走る

VS Codeの軽量インデックス 🪶

VS Codeのインデックスアプローチは根本的に異なります：

言語サービスベースのインデックス:

• 各言語拡張が独自にインデックスを管理
• TypeScript/JavaScript言語サービスは既にVS Coreコアに常駐
• Copilotは既存のシンボルインデックスを活用
• 重複した処理がない

非ブロッキング設計:

• インデックス処理が進行中でも、エディタ機能は完全に使用可能
• Copilotは利用可能な情報だけでサジェストを生成
• インデックス完了を待たない

🐛 既知の問題とバージョン別の状況

2023年以降の主要問題トラッキング

💾 メモリリーク:

• GitHub Community Discussion #84695: 「Copilotが異常な量のメモリを使用」（2023年〜現在）
• 10GB+のメモリ消費、55GBまで膨張する報告
• 2025年11月時点でも未解決

❄️ IDE フリーズ:

• microsoft/copilot-intellij-feedback Issue #298: 「CopilotがIDEをフリーズさせる」
• 数百のスレッド生成、全てReadActionで待機
• ユーザーがサブスクリプションをキャンセルする原因に

🔥 CPU 100%問題:

• microsoft/copilot-intellij-feedback Issue #529: 「チャット開いた状態で異常なCPU使用率」
• M4 MacBookで900%+ CPU使用率
• GitHub Community Discussion #154926: 複数のJetBrains IDE（IntelliJ、PhpStorm、WebStorm、PyCharm）で確認

🐌 リンティングパフォーマンス低下:

• microsoft/copilot-intellij-feedback Issue #291: 「Copilotチャット使用時にリンティングが極端に遅延」
• コード変更を認識するまで数分かかる
• チャットを閉じると即座に正常化

JetBrains YouTrackでの追跡

公式バグトラッカーにも多数報告：

• IDEA-374025: Copilotプラグインによるフリーズ問題
• RUBY-34695: コード解析が極端に遅くなる
• RIDER-128167: ツールウィンドウが極端に遅くUIをフリーズ

プラグインバージョン別の問題

バージョン	主な問題
1.4.6.4092	CopilotTextInputTextAreaのメモリリーク 💾
1.5.19-1.5.23	深刻なフリーズ問題 ❄️
1.5.29.7524	Linuxで極端なメモリ消費 📈
1.5.43-243	IDEフリーズ（Issue #151） 🔒
1.5.46-243	リンティングパフォーマンス低下 🐌
2025.2.x系	チャット開いた状態で100% CPU 🔥

最新情報（2025年11月時点）:

バージョン1.5.55-243（2025年9月リリース）で一部のCPU問題が修正されたと報告がありますが、根本的な問題は解決していません。

🎯 まとめ：技術的背景の理解が解決の第一歩

IntelliJ IDEAでのGitHub Copilotパフォーマンス問題は、単一の原因ではなく、複数の技術的要因の複合的結果です：

主要な技術的原因:

1. ⚙️ JVMアーキテクチャのオーバーヘッド: ヒープ管理、GCポーズ、クラスローダー分離
2. 🔌 プラグイン実装の制約: webviewベースのチャットUI、メモリリーク、スレッド管理の失敗
3. 📚 PSI/インデックスシステムとの競合: ReadActionブロック、Dumb Mode、UIスレッドでのI/O
4. 🔄 統合の成熟度不足: VS Codeに比べて1-2年遅れている機能、最適化不足

VS Codeが優れている理由:

• 🏗️ マルチプロセスアーキテクチャによる完全な分離
• 🔗 TypeScript/Node.jsエコシステムとの親和性
• ⚡ ネイティブ統合による低レイテンシ（200-400ms vs 1-2秒）
• 💾 効率的なリソース管理（500MB-1.5GB vs 6-15GB）

現実的な選択肢:

• 🤖 Copilot中心の開発: VS Codeを検討
• 🛠️ IntelliJエコシステム重視: パフォーマンス問題を受け入れる
• ⚡ ハイブリッド戦略: 両方使い分ける（最推奨！）

今後の展望:

JetBrainsとGitHubの協力により改善が期待されますが、根本的なアーキテクチャの違いは変わりません。IntelliJの強力な機能（PSI、高度な検査、リファクタリング）を必要とするなら、Copilotのパフォーマンストレードオフは避けられないコストと言えるでしょう。

この記事が、IntelliJ IDEAでCopilotを使う際のパフォーマンス問題の理解と対策に役立てば幸いです。🎉