【実務・中級編】VS Codeの「メモリ使用量」を可視化してボトルネックを特定する：Process Explorer徹底解説 – 軽量・高機能テキストエディタ生産性向上バイブル

VS Codeが「重い」と感じたら疑うべき、本当のボトルネック

開発の最中、ふとファンが唸りを上げ、タイピングのレスポンスがコンマ数秒遅れる。この「ラグ」が開発者のフロー状態をいかに破壊するか、テックリードであるあなたなら痛感しているはずだ。

多くのエンジニアは、動作が重くなった瞬間に「PCのスペック不足」を疑い、VS Codeを再起動してその場を凌ぐ。しかし、これは根本的な解決ではない。VS CodeはElectron製であり、そのアーキテクトの本質は「ブラウザのタブが複数起動している状態」と等しい。つまり、メインプロセス、UIをレンダリングするプロセス、各拡張機能（Extension）がそれぞれ独立したプロセスとしてOSのメモリとCPUを消費している。

真のプロフェッショナルは、感覚で「重い」と嘆くのではなく、内部のメモリ・CPU使用率の構造をデータで可視化し、ボトルネックとなっている特定のプロセスをピンポイントで射撃する。

今回は、VS Codeに標準搭載されている隠れた名機能「Process Explorer（プロセスエクスプローラー）」を極限まで使い倒し、開発環境のパフォーマンスを極限までチューニングする実践的アプローチを伝授する。

—

1. Process Explorerの起動と「内部で何が起きているか」の解剖

Process Explorerを起動するには、コマンドパレット（`Ctrl + Shift + P` または `Cmd + Shift + P`）を開き、以下のコマンドを実行する。

> 隠しコマンド: `Developer: Open Process Explorer`

また、日常の診断スピードを劇的に上げるために、以下のキーボードショートカットを `keybindings.json` に割り当てておくことを強く推奨する。

[
{
“key”: “ctrl+alt+p”,
“command”: “workbench.action.openProcessExplorer”,
“when”: “editorTextFocus”
}
]

プロセスツリーの構造を読み解く

Process Explorerを開くと、OSのタスクマネージャーとは異なり、VS Code内部のどのモジュールがリソースを喰っているかがツリー構造で露わになる。

1. Main Process: VS Code全体のライフサイクルを管理する親プロセス。
2. GPU Process: UIの描画やハードウェアアクセラレーションを処理するプロセス。
3. Shared Process: 拡張機能のホストやバックグラウンド通信を束ねるプロセス。
4. Extension Host: ここが最重要ポイント。インストールされているすべての拡張機能（GitLens, Linter, Formatterなど）が稼働するサンドボックス環境。
5. Window (workspace): 開いているプロジェクトごとのレンダラープロセス。

開発中にメモリリークやCPU使用率の跳ね上がり（100%張り付き）が起きる場合、95以上の確率で犯人は Extension Host 内の特定の拡張機能、あるいは特定の巨大ファイルを読み込んだ Windowプロセス である。

—

2. 犯人を特定し、強制終了させるステップバイステップ診断

メモリリークやハングアップが発生した際、以下のステップで外科手術のように原因を排除する。

Step 1: プロセスエクスプローラーでCPU/メモリの異常値をスキャン

Process Explorer上で、`CPU` カラムや `Memory` カラムをクリックしてソートし、リソースを異常消費しているプロセスを特定する。特に `Extension Host` の配下に展開されている個別の拡張機能名（PIDやUUIDで識別可能）に注目する。

Step 2: 該当プロセスの強制終了（Kill）

暴走しているプロセスを特定したら、その行をダブルクリック、またはコンテキストメニューから 「Kill」 を実行する。

• ※注意: Extension Host内の拡張機能をKillした場合、その拡張機能の機能が一時的に停止するが、VS Code本体がクラッシュすることは稀であるため、安全に切り離せる。

Step 3: 原因拡張機能の特定と恒久対策

もし特定の拡張機能が頻繁にリソースを食い潰す場合、以下の対応をとる。

• 拡張機能のダウングレード（最新版のバグの可能性）
• 設定の見直し（ファイルウォッチャーの対象外設定など）
• 代替の軽量プラグインへの移行

—

3. 開発スピードを底上げする「神プラグイン」選定基準

「拡張機能が多いほど便利になる」という誤解が、VS Codeを重くする最大の元凶だ。プロの現場では、「軽量でありながら、費用対効果（生産性向上率）が圧倒的なもの」だけを厳選する。

以下は、メモリ消費を最小限に抑えつつ、開発体験を劇的に変えるマストバイの神プラグイン群である。

1. Error Lens

• 理由: エラーや警告をコード行の末尾にインライン表示する。問題箇所にマウスオーバーする無駄なアクションを排除し、タイピング中のミスを即座にゼロにする。

2. GitLens (機能の取捨選択が必須)

• 理由: コードの行ごとのBlame表示は強力だが、設定をデフォルトのままにするとリソースを大量消費する。後述の設定ファイルで最適化が必須。

3. Path Intellisense

• 理由: ファイルパスの補完に特化。無駄な重い機能を排除した純粋な高速補完エンジン。

—

4. チーム開発の生産性を統一する設定ファイル（settings.json）ベストプラクティス

個人の環境依存によるメモリリークや、不要なバックグラウンド処理を防ぐため、チーム全体で共有すべき `settings.json` のベストプラクティスを提示する。

プロジェクトルートの `.vscode/settings.json` に配置し、チームメンバー全員のVS Codeの挙動をガバナンスする。

{
// — パフォーマンス・メモリ最適化設定 —

// 巨大なファイル（ログやビルド成果物）を開いた際のメモリ破綻を防ぐ
“editor.largeFileOptimizations”: true,

// 検索対象から除外すべきディレクトリを明示し、ファイルウォッチャー（CPU負荷）を軽減する
“files.watcherExclude”: {
“/.git/objects/“: true,
“/.git/subtree-cache/“: true,
“/node_modules//“: true,
“/dist/“: true,
“/build/“: true,
“/.next/“: true,
“/vendor/“: true
},

// 検索の除外設定（CPUのスパイクを防ぐ）
“search.exclude”: {
“/node_modules”: true,
“/bower_components”: true,
“/.code-search”: true,
“/dist”: true,
“/build”: true,
“/.next”: true
},

// ミニマップは視覚的ノイズであり、レンダラープロセスのメモリを無駄に消費するためオフを推奨
“editor.minimap.enabled”: false,

// 画面描画のフレームレートを制限し、GPUプロセスの負荷を下げる
“window.fps”: 60,

// — 開発効率化・フォーマット設定 —

// 保存時に自動フォーマットを走らせ、コードスタイルの議論を自動化で消滅させる
“editor.formatOnSave”: true,

// 末尾の不要なホワイトスペースを自動削除し、Gitの差分ノイズを完全に防ぐ
“files.trimTrailingWhitespace”: true,

// ファイル末尾に必ず改行を挿入（POSIX標準の遵守）
“files.insertFinalNewline”: true,

// — GitLensの軽量化チューニング（重要） —

// デフォルトでは重いコードレンズ（行ごとのコミット情報表示）を非同期かつ必要最小限に
“gitlens.codeLens.enabled”: false,

// 現在行のインラインBlameは開発体験が高いが、重い場合は “false” にすることを推奨
“gitlens.currentLine.enabled”: true
}

—

5. テックリードが実践すべき「軽快な開発環境」の維持ルール

ツールや設定をいじるだけでは、長期的な環境の健全性は保てない。チーム全体で以下の運用ルールをコードレビューやオンボーディングのプロセスに組み込んでほしい。

1. 「野良拡張機能」の禁止

• 個人の趣味や一時的な検証のために、チーム共有のプロジェクト内で重い拡張機能（特に未検証のAIアシスタント系や巨大な言語パック）をインストールしたままにしない。

2. 定期的な Process Explorer 監査の習慣化

• スプリントレビューの前や、大規模なリファクタリングの合間に、チームメンバーが自身のProcess Explorerを確認し、「どの拡張機能がリソースを食っているか」をSlack等のチャンネルで共有し合う文化を作る。

3. ワークスペースごとのプロファイル活用

• VS Codeの「Profiles（プロファイル機能）」を使い分けよ。フロントエンド開発用、インフラ（Terraform/K8s）用、バックエンド用で拡張機能を完全に分離することで、常時起動する無駄なExtension Hostのメモリ消費を劇的に削減できる。

—

結びにかえて

開発環境とは、いわばエンジニアにとっての「コックピット」である。計器（Process Explorer）の読み方を誤り、ガラクタ（不要なプラグイン）を積み上げれば、最高のパフォーマンスを発揮できるはずがない。

メモリの消費構造をロジカルに把握し、ボトルネックを正確に撃ち抜く。この知見を身につけたあなたなら、今日からチーム全体のビルドスピードと開発体験を一段上のステージへ引き上げることができるはずだ。さあ、今すぐ Process Explorer を開き、あなたのエディタの「本当の姿」を覗いてみよう。