こんにちは！
クラウドソリューション開発部の大川です。
以前投稿した「汎用的に使える VSCode のおすすめ拡張機能 17 選」の続編です。
今回は対象を絞って、複数プロジェクトを同時並行で進める人向けの拡張機能と設定をまとめました。
この記事を読むと得られること
この記事の設定をひと通り入れると、複数案件の掛け持ちによる「誤コミットゼロ」「切り替えストレスゼロ」 に近づけます。具体的には次の状態がゴールです。
- ウィンドウを見た瞬間に「今どの案件を触っているか」が分かる
- 保護ブランチや別案件へのうっかりコミットが仕組みで止まる
- 案件ごとにフォーマッタ・Lint・拡張機能が自動で切り替わる
- ウィンドウを 5 枚開いても VSCode が重くならない
所要時間は 15 分程度、設定ファイルをコピペするだけで導入できます。「まずは最低限だけ」という方は、2 章の色分けと 4 章の Git 設定の 2 つから試してみてください。
前提：同時並行で起きる「あるある」
複数案件を並行していると、だいたい次の 4 つで事故ります。
- どのウィンドウがどの案件か分からなくなる
見た目が全部同じなので、Alt+Tab で切り替えた瞬間に迷子になります。 - A 案件のつもりで B 案件のブランチにコミットしていた
最悪の場合、他案件の main に混入してレビューと revert のコストが発生します。 - プロジェクトごとにフォーマッタ設定が違って差分が荒れる
実質 1 行の修正なのに、保存時整形でファイル全体が差分になりレビューが破綻します。 - 検索が別案件のファイルまで拾ってしまう
node_modulesや別リポジトリのヒットに埋もれて、目的のコードに辿り着けません。
これらは「気をつける」で解決しません。設定で機械的に潰すのが唯一の対策です。以下はそのための構成です。
1. マルチルートワークスペースで「案件単位」にまとめる
複数リポジトリを 1 ウィンドウに束ねられます。.code-workspace を案件ごとに作るのがおすすめです。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
{ "folders": [ { "path": "../frontend", "name": "frontend" }, { "path": "../api", "name": "api" }, { "path": "../infra", "name": "infra" } ], "settings": { // このワークスペースだけに効く設定 "window.title": "【A案件】${activeEditorShort} - ${rootName}", "search.exclude": { "**/node_modules": true, "**/dist": true } }, "extensions": { "recommendations": ["esbenp.prettier-vscode", "dbaeumer.vscode-eslint"] } } |
なぜ必要か
フロント・API・インフラが別リポジトリに分かれている案件では、ウィンドウを 3 枚開くと管理不能になります。マルチルートなら 1 案件＝1 ウィンドウに統一でき、横断検索も一括でできます。
search.exclude を書いておくと、node_modules や dist のノイズが検索結果から消えます。これは地味ですが、1 日に何十回も検索することを考えると効果は大きいです。
extensions.recommendations を入れておくと、新しくジョインしたメンバーがワークスペースを開いた瞬間に「推奨拡張機能をインストールしますか？」と案内されます。オンボーディング用のドキュメントを書く手間が減ります。
ポイント
- 設定・推奨拡張機能をワークスペースに閉じ込められる
- フォルダごとに別々の
.vscode/settings.jsonも併用できる（.code-workspaceのsettingsより、各フォルダ側の設定が優先されます）
2. ウィンドウを見分ける（誤操作防止の最重要設定）
|
1 2 3 4 5 6 7 8 9 10 11 12 |
{ // タイトルバーにリポジトリ名とブランチ名を出す "window.title": "${rootName} [${activeRepositoryBranchName}] - ${activeEditorShort}", // 案件ごとに色を変える（各プロジェクトの .vscode/settings.json に書く） "workbench.colorCustomizations": { "titleBar.activeBackground": "#1f6feb", "titleBar.activeForeground": "#ffffff", "activityBar.background": "#1f6feb" } } |
※ ${activeRepositoryBranchName} は VSCode 1.83 以降で利用できます。また、タイトルバーの色を反映するには window.titleBarStyle が custom（既定）である必要があります。
なぜ必要か
事故の大半は「今どの案件かの認識ズレ」から始まります。タイトルバーにブランチ名まで出しておけば、main に直接コミットしようとした瞬間に違和感で気づけます。
色分けはさらに強力です。人間はテキストより色を先に認識するため、ウィンドウを切り替えた瞬間、無意識に案件を判別できるようになります。私は「A 案件＝青／B 案件＝緑／本番作業用＝赤」のように運用しており、赤いウィンドウでは自然と手が慎重になります。
色は .vscode/settings.json に書いて Git 管理すると、チーム全員で同じ色になり「あの緑のやつ」で会話が通じるようになります。
3. 新規ウィンドウで開く / 誤って上書きしないための設定
|
1 2 3 4 5 6 7 8 9 10 11 |
{ // フォルダを開く時は必ず新しいウィンドウ "window.openFoldersInNewWindow": "on", // 再起動時に前回のウィンドウをすべて復元 "window.restoreWindows": "all", // プレビュータブ（斜体タブ）を無効化。開いたファイルが勝手に置き換わらない "workbench.editor.enablePreview": false, // ピン留めしたタブをコンパクト表示にする "workbench.editor.pinnedTabSizing": "compact" } |
なぜ必要か
既定では、フォルダを開くと今開いている案件のウィンドウが置き換わります。作業中のコンテキストが吹き飛ぶので、openFoldersInNewWindow は必須級です。
restoreWindows: "all" は、PC 再起動後に全案件のウィンドウが元通り復活する設定です。朝の「どの案件をどこまで開いていたっけ」がなくなります。
プレビュータブの無効化は、複数案件で特に効きます。ファイルをクリックするたびにタブが置き換わると、案件を跨いだ比較作業ができません。常に把握しておきたいファイルは Ctrl+K Shift+Enter でピン留めしておくと、タブが増えても迷いません。
4. Git 事故を防ぐ
|
1 2 3 4 5 6 7 8 9 10 |
{ "git.autofetch": true, "git.branchProtection": ["main", "develop"], "git.branchProtectionPrompt": "alwaysPrompt", // Sync（pull & push）実行前に必ず確認ダイアログを出す "git.confirmSync": true, // ステージしていない変更を自動でコミットに含めない "git.enableSmartCommit": false } |
なぜ必要か
git.branchProtection は、指定したブランチにコミットしようとすると確認ダイアログを出す機能です。GitHub 側のブランチ保護と違い、push する前（コミットの瞬間）に止まるのがポイント。手元でのやり直しコストが最小で済みます。
git.enableSmartCommit: false は、複数案件を跨いで作業しているときこそ重要です。有効になっていると「ステージしていない変更まで巻き込んでコミット」されるため、デバッグ用の一時コードや別対応の変更が混入します。少し手間でも、明示的にステージする運用に倒すのが安全です。
git.confirmSync は、意図しないブランチへの push を最後の砦として止めてくれます。autofetch はリモートの更新を自動取得し、久々に戻ってきた案件でも古い状態のまま作業を始めずに済みます。
5. 設定は「User」と「Workspace」を使い分ける
| 置き場所 | 書くべき内容 |
|---|---|
User settings.json |
キーバインド、フォント、テーマなど個人の好み |
.code-workspace |
案件横断の検索除外、ウィンドウタイトル |
<repo>/.vscode/settings.json |
フォーマッタ、Lint、色（チームで Git 管理） |
なぜ必要か
判断基準はシンプルで、「他の人の環境でも同じであるべきか？」です。Yes ならリポジトリの .vscode/settings.json、No なら User 設定に置きます。
よくある失敗が、User 設定に "editor.defaultFormatter": "esbenp.prettier-vscode" を書いてしまうケースです。Prettier を使っていない別案件を開いた瞬間、保存時に全ファイルが整形され、レビュー不能な巨大 PR ができあがります。プロジェクト固有の設定は必ずリポジトリ側へ。ここの分離が同時並行運用の肝です。
6. Profiles でエディタ環境ごと切り替える
VSCode 標準の Profiles（プロファイル）を使うと、設定・拡張機能・キーバインド・UI レイアウト・スニペットをまるごとワンセットで切り替えられます。
Ctrl+Shift+P →「Profiles: Create Profile」で作成し、プロファイルごとにアイコンを設定できます。アイコンはアクティビティバー下部に表示されるため、視覚的な識別にもなります。
|
1 2 3 4 |
Frontend プロファイル : ESLint / Prettier / Tailwind IntelliSense / Vue Python プロファイル : Pylance / Jupyter / Ruff Infra プロファイル : Terraform / Docker / YAML |
なぜ必要か
5 章の Workspace 設定は「設定の切り替え」はできますが、拡張機能そのものは全プロファイル共通でロードされます。Python 分析案件を開いているのに Vue や Terraform の拡張機能が常駐していると、起動が遅くなるうえ、無関係な補完候補がノイズになります。
Profiles なら不要な拡張機能をそもそも読み込まないため、起動時間が明確に改善します。フォルダやワークスペースにプロファイルを紐づけておけば、開いた瞬間に自動で切り替わります。作成したプロファイルは GitHub Gist にエクスポートして共有できるので、チームの標準開発環境をプロファイルとして配布する使い方もおすすめです。
使い分けの目安は次のとおりです。
- 技術スタックが違う（フロント / Python / インフラ）→ Profiles
- 同じスタックで案件だけ違う → Workspace 設定＋色分け
7. パフォーマンス対策（ウィンドウを何枚も開くので効きます）
|
1 2 3 4 5 6 7 8 9 10 11 |
{ "files.watcherExclude": { "**/node_modules/**": true, "**/.git/objects/**": true, "**/dist/**": true }, "search.followSymlinks": false, // 有効化している拡張機能だけを自動更新の対象にする "extensions.autoUpdate": "onlyEnabledExtensions" } |
なぜ必要か
VSCode はファイル変更を検知するために監視プロセスを常駐させています。node_modules のような数万ファイル規模のディレクトリを監視対象にしていると、それだけで CPU とメモリを大きく消費します。ウィンドウを 5 枚開けば、その負荷も 5 倍です。
search.followSymlinks: false は、シンボリックリンクを辿らないことで検索を高速化します。モノレポやリンクを多用する構成では体感で分かるほど変わります。
さらに、案件ごとに不要な拡張機能は 「このワークスペースで無効にする」 を活用すると、起動が目に見えて速くなります（6 章の Profiles と併用すると、より徹底できます）。
拡張機能（同時並行運用に効くもの）
| 拡張機能 | ひとこと要約 |
|---|---|
| Project Manager | 登録したプロジェクトをワンアクションで切り替え |
| Peacock | ワークスペースごとにウィンドウ色をコマンド一発で設定 |
| GitLens | 案件を跨いでも実装経緯をすぐ追える |
| EditorConfig | プロジェクト間のインデント・改行差を吸収 |
| Todo Tree | 案件ごとのやり残しを一覧化 |
| Dev Containers | ランタイムのバージョン差をプロジェクト単位で隔離 |
|
1 2 3 4 5 6 7 |
code --install-extension alefragnani.project-manager code --install-extension johnpapa.vscode-peacock code --install-extension eamodio.gitlens code --install-extension EditorConfig.EditorConfig code --install-extension Gruntfuggly.todo-tree code --install-extension ms-vscode-remote.remote-containers |
特に効く 3 つを補足
Peacock は、2 章の colorCustomizations をコマンドパレットから対話的に設定してくれる拡張機能です。手で JSON を書く必要がなく、Peacock: Change to a Favorite Color を実行するだけ。実際に色分けすると、下のように一目で案件を判別できます。
タイトルバーとアクティビティバーの色で瞬時に判別できる
Dev Containers は、Node 18 と Node 22 のように案件間でランタイムのバージョンが違う場合の決定版です。ローカルにバージョン管理ツールを入れて切り替える運用より事故が起きにくく、環境構築手順もリポジトリに残せます。
Todo Tree は、TODO / FIXME コメントをツリー表示してくれます。マルチルートワークスペースと組み合わせると、案件配下のやり残しを横断で一覧でき、differ 前のセルフチェックに便利です。
まとめ
| やること | 効果 |
|---|---|
.code-workspace を案件ごとに用意 |
設定と拡張機能を案件単位で閉じ込める |
window.title ＋ 色分け |
どのウィンドウがどの案件か一目で分かる |
git.branchProtection |
別案件・保護ブランチへの誤コミットを防ぐ |
| User / Workspace 設定の分離 | 案件を切り替えても設定が壊れない |
| Profiles | 技術スタックごとに拡張機能ごと切り替えて軽量化 |
| watcher / search の除外 | ウィンドウを複数開いても軽い |
同時並行で一番怖いのは「間違った案件に手を入れる」ことです。
まずは ウィンドウの色分け と window.title の 2 つだけでも入れてみてください。設定ファイルに数行足すだけで、精神的な負荷がかなり軽くなるはずです。
終わりに
こうした開発環境の改善は、一見すると地味な取り組みかもしれません。しかしエコモットでは、「日々のちょっとした無駄をなくすこと」もチーム全体の生産性を上げる立派な仕事だと考えています。今回紹介した設定も、社内で「これ便利だよ」と共有し合う中でブラッシュアップされてきたものです。
新しいツールや設定を試して、良かったものをチームに還元する。そんな文化の中で、一緒にモノづくりを楽しみませんか？
エコモットでは一緒に働く仲間を募集中です。少しでも興味を持っていただけた方は、ぜひ下記の採用ページをご覧ください！
