VS Code ワークスペースとは？知っておきたい基本と活用法

はじめに

今日、ソフトウェア開発において、Visual Studio Code（VS Code）は最も人気のあるエディタの一つとして確固たる地位を築いています。その人気の理由の一つは、豊富な拡張機能によるカスタマイズ性と、プロジェクト管理を効率化するための強力な機能が標準で備わっている点にあります。特に、複数のファイル、ディレクトリ、さらには関連する複数のプロジェクトをまとめて扱い、それぞれのプロジェクトに最適な開発環境を迅速に構築・維持するための仕組みとして、「ワークスペース」は非常に重要な概念です。

しかし、「VS Codeを使っているけれど、ワークスペースの概念を深く理解していない」「フォルダを開くだけで十分だと思っていた」「マルチルートワークスペースって何が便利なの？」といった疑問を持っている方も少なくないかもしれません。

プロジェクトの種類や規模が多様化する現代において、単にフォルダを開いてコードを編集するだけでは、開発効率やチームでの共同作業に限界が生じることがあります。プロジェクト固有の設定（コードスタイル、リンター、フォーマッター、デバッグ構成、タスクなど）が散逸したり、異なるプロジェクト間で頻繁に設定を切り替える必要が生じたりすると、開発体験は大きく損なわれかねません。

VS Codeのワークスペースは、これらの課題を解決するための強力なソリューションを提供します。ワークスペースを活用することで、プロジェクトごとに独立した設定を管理し、関連する複数のフォルダをまとめて扱い、開発に必要なツールや設定を一つのまとまりとして扱うことができるようになります。これは、個人の生産性を向上させるだけでなく、チーム全体の開発環境を統一し、オンボーディングをスムーズにする上でも非常に有効です。

この記事では、VS Codeのワークスペースとは何かという基本的な概念から始まり、なぜワークスペースを使うべきなのか、どのような種類があり、どのように作成・設定するのか、そしてマルチルートワークスペースの具体的な活用法に至るまで、詳細かつ網羅的に解説します。ワークスペースの設定ファイル（.code-workspace）の構造や、ワークスペースレベルでの各種設定（settings.json, launch.json, tasks.json, extensions.json）の記述方法についても、具体的な例を交えながら掘り下げていきます。

この記事を通じて、VS Codeワークスペースの強力な機能を理解し、日々の開発ワークフローに効果的に取り入れるための知識を得ていただければ幸いです。対象読者は、VS Codeを日常的に使用している開発者、チームリーダー、あるいはより効率的な開発環境を構築したいと考えているすべての方々です。さあ、VS Codeワークスペースの世界へ深く潜っていきましょう。

VS Code ワークスペースとは？ – 基本概念の理解

まず、VS Codeワークスペースの基本的な概念を明確に理解することから始めましょう。ワークスペースとは、一言でいうと「VS Codeで開発を行う上で関連するファイルや設定をまとめた単位」です。

フォルダとワークスペースの違い

VS Codeで最も基本的な操作は、「フォルダを開く」ことです。単一のプロジェクトやリポジトリを開発する場合、そのルートフォルダをVS Codeで開くだけで、ファイルエクスプローラーにファイルツリーが表示され、コードの編集を開始できます。この「フォルダを開いた状態」も、広義には「単一ルートワークスペース（Single-Root Workspace）」と呼ばれます。この場合、ワークスペースに関する設定は、開いているフォルダ直下の.vscodeディレクトリ内に保存されます。

しかし、VS Codeで「ワークスペース」という言葉を使う場合、多くの場合、単一のフォルダだけでなく、複数の関連するフォルダや、それら全体に適用される設定をまとめたものを指します。これは「マルチルートワークスペース（Multi-Root Workspace）」と呼ばれ、.code-workspaceという拡張子を持つ特別なファイルによって定義されます。

重要な点は、ワークスペースは単なるフォルダの集まりではないということです。ワークスペースは、開いているフォルダ群に加えて、以下のようなプロジェクト固有の設定や状態を含んでいます。

ワークスペースレベルの設定: VS Codeのエディタ設定、リンター/フォーマッターの設定、言語固有の設定など、特定のワークスペースを開いている間だけ適用される設定。
デバッグ構成 (launch.json): アプリケーションの起動、デバッグに関する設定。
タスク定義 (tasks.json): ビルド、テスト、デプロイなどのタスクに関する設定。
推奨拡張機能 (extensions.json): そのワークスペースで開発を行う上で推奨される、あるいは必須となる拡張機能のリスト。
開いているファイルやエディタグループの状態: 前回ワークスペースを閉じたときに開いていたファイル、エディタのレイアウトなど（デフォルト設定）。

これらの設定や状態は、通常、ワークスペースを定義する.code-workspaceファイル（マルチルートの場合）または開いているフォルダ直下の.vscodeディレクトリ（単一ルートの場合）に保存されます。これにより、VS Codeを再起動したり、別のプロジェクトに切り替えてから戻ってきたりしても、開発環境を素早く復元することができます。

ワークスペースファイル (`.code-workspace`) の役割と内容

マルチルートワークスペースを定義する.code-workspaceファイルは、JSON形式で記述されます。このファイルは、ワークスペースに含まれるフォルダのパス、そしてワークスペース全体に適用される設定などを記述するためのものです。

基本的な.code-workspaceファイルの構造は以下のようになります。

json { "folders": [ { "path": "folder1" // ワークスペースに含めるフォルダのパス（相対パスまたは絶対パス） }, { "name": "Backend", // エクスプローラーに表示するフォルダ名（省略可、デフォルトはフォルダ名） "path": "folder2" }, { "name": "Common Lib", "path": "../common-library" // 相対パスで親ディレクトリや他の場所も指定可能 } ], "settings": { // ワークスペース固有の設定をここに記述 "editor.tabSize": 2, "editor.formatOnSave": true, "files.exclude": { "**/.git": true, "**/node_modules": true } // ...その他のワークスペース設定 }, "launch": { // ワークスペース固有のデバッグ設定をここに記述 }, "tasks": { // ワークスペース固有のタスク設定をここに記述 }, "extensions": { // ワークスペース固有の推奨拡張機能設定をここに記述 } }

folders：ワークスペースに含めるフォルダのリストです。各要素は、そのフォルダへのパスを指定するpathプロパティを必須として持ちます。nameプロパティを指定すると、VS Codeのファイルエクスプローラーで表示されるフォルダ名を変更できます。パスは、.code-workspaceファイルからの相対パス、または絶対パスで指定可能です。
settings：このワークスペース全体に適用されるVS Codeの設定を記述します。ここに記述された設定は、ユーザー設定やデフォルト設定よりも優先されます（フォルダ固有の設定がある場合は、そちらがさらに優先されます）。
launch：このワークスペースで使用するデバッグ構成を記述します。これは、通常、開いているフォルダの.vscode/launch.jsonの内容とマージされますが、ここに直接記述することも可能です。
tasks：このワークスペースで使用するタスク定義を記述します。これも、通常、開いているフォルダの.vscode/tasks.jsonの内容とマージされますが、ここに直接記述することも可能です。
extensions：このワークスペースで推奨される拡張機能や、無効化すべき拡張機能を記述します。

この.code-workspaceファイルを保存し、VS Codeでこのファイルを開くことで、定義されたフォルダ群とそのワークスペース固有の設定が読み込まれた状態になります。

マルチルートワークスペースの概念

先述の通り、マルチルートワークスペースは、複数の独立したフォルダを同時にVS Codeのサイドバー（ファイルエクスプローラー）に表示し、それらを一つのまとまりとして扱う概念です。これは、以下のようなシナリオで非常に有効です。

モノレポ（Monorepo）構成: 複数の関連するプロジェクトやパッケージが単一のリポジトリで管理されている場合。各サブディレクトリをワークスペースに追加することで、リポジトリ全体を俯瞰しつつ、特定のプロジェクトに焦点を当てた作業がしやすくなります。
マイクロサービス構成: 複数の小さなサービスが連携して一つのシステムを構成している場合。開発中のサービスや、それに関連するサービスをワークスペースに追加して、サービス間の連携を確認しながら開発できます。
フロントエンドとバックエンドの分離: フロントエンドとバックエンドが別々のリポジトリやフォルダで管理されているが、同時に開発する必要がある場合。それぞれのルートフォルダをワークスペースに追加することで、一つのVS Codeウィンドウで両方のコードを編集・デバッグできます。
ライブラリ開発とアプリケーション開発の連携: 開発中の共通ライブラリと、そのライブラリを使用するアプリケーションプロジェクトを同時に開いて、ライブラリの変更がアプリケーションに与える影響を確認しながら開発する場合。

マルチルートワークスペースでは、ファイルエクスプローラーに複数のルートフォルダが表示され、それぞれのフォルダに対して個別の.vscode設定（そのフォルダにのみ適用される設定）を持つことができます。同時に、.code-workspaceファイルで定義された設定は、ワークスペース全体（含まれるすべてのフォルダ）に適用されます。これにより、全体に共通の設定と、各フォルダ固有の設定を適切に分離して管理できます。

単一のフォルダを開くだけの状態と比較して、マルチルートワークスペースはより複雑なプロジェクト構成に対応し、開発に必要なすべての要素を一つのVS Codeウィンドウ内に集約できるという大きな利点があります。

なぜワークスペースを使うべきなのか？ – ワークスペースのメリット

VS Codeでワークスペース（特にマルチルートワークスペース）を活用することには、多くのメリットがあります。単にフォルダを開いて開発するだけでは得られない、生産性や効率の向上、開発環境の統一といった利点を見ていきましょう。

1. プロジェクト固有の設定を一元管理できる

開発プロジェクトはそれぞれ異なる技術スタック、コーディング規約、ツールチェインを持っています。ワークスペースを使用すると、これらのプロジェクト固有の設定を.vscodeディレクトリ内（単一ルートの場合）または.code-workspaceファイル内（マルチルートの場合）に集約して管理できます。

エディタ設定: インデントのサイズやスタイル（スペースかタブか）、ファイルのエンコーディング、改行コード、ファイルの末尾に改行を追加するかどうかなど、プロジェクトで定められたコーディング規約に合わせたエディタ設定をワークスペースに保存できます。これにより、個人のユーザー設定とは別に、プロジェクト推奨の設定を強制的に適用できます。
リンター/フォーマッター設定: ESLint, Prettier, Black, isort などのリンターやフォーマッターの設定ファイルは各プロジェクトに存在しますが、VS Codeの拡張機能がそれらをいつ、どのように実行するか（例: ファイル保存時にフォーマットを実行するか）といった設定もワークスペースに保存できます。
デバッグ設定: アプリケーションを特定の構成で起動してデバッグするための設定（起動コマンド、環境変数、ポート番号など）をlaunch.jsonに記述し、ワークスペースの一部として管理できます。複数のデバッグ構成が必要な場合も、まとめて管理できます。
タスク設定: ビルド、テスト実行、コード生成、デプロイといった、開発に必要な定型タスクをtasks.jsonに定義できます。これにより、開発者は複雑なコマンドを手動で実行するのではなく、VS Codeのコマンドパレットから簡単にタスクを実行できるようになります。
拡張機能の設定: 特定のワークスペースでのみ有効にしたい、あるいは設定を上書きしたい拡張機能がある場合、ワークスペース設定で制御できます。さらに、そのワークスペースで開発を行う上で推奨される拡張機能のリストをextensions.jsonで指定できます。

これらの設定をワークスペースに保存し、バージョン管理システム（Gitなど）で共有することで、チームメンバー全員が同じ開発環境設定をすぐに利用できるようになります。新しいメンバーのオンボーディングもスムーズになり、”私の環境では動くのに…”といった問題を減らすことができます。

2. 関連する複数のプロジェクト/フォルダをまとめて管理できる（マルチルート）

これがマルチルートワークスペースの最も顕著なメリットです。前述の通り、モノレポ、マイクロサービス、フロントエンド/バックエンド分割など、複数の独立したコードベースを同時に扱う必要がある場合に絶大な効果を発揮します。

モノレポ構成: モノレポ内の複数のパッケージやアプリケーションを同時に開くことで、コード間の参照を追跡したり、依存関係を視覚的に把握したりするのが容易になります。共通ライブラリを変更しながら、それを使用する複数のアプリケーションの挙動を確認するといった開発スタイルが可能になります。VS Codeの検索機能もワークスペース全体を対象に実行されるため、広範囲なコード検索や置換が効率的に行えます。
マイクロサービス構成: 開発中のサービスと、そのサービスが依存する他のサービスや、あるいはAPIゲートウェイなどの関連サービスを同時に開くことで、サービス間のインターフェースやデータフローを確認しながら開発できます。複数のサービスを連携させてデバッグすることも容易になります。
フロントエンド/バックエンド構成: フロントエンドとバックエンドが別々のフォルダにある場合、それらを一つのワークスペースにまとめることで、VS Codeウィンドウを複数開く必要がなくなります。コードの編集、ターミナルの利用、デバッグなど、すべての作業を一つのウィンドウ内で完結できます。例えば、バックエンドAPIを変更したら、すぐにフロントエンドからその変更をテストするといったスムーズな開発フローを実現できます。

複数のフォルダを一つのワークスペースにまとめることで、開発に必要なコード資産全体を俯瞰し、フォルダ間の移動や操作を効率的に行えます。

3. プロジェクト間のコンテキスト切り替えが容易になる

ワークスペースは、プロジェクト固有の設定や開いているファイルの状態を保存します。そのため、あるプロジェクトのワークスペースを閉じて別のプロジェクトのワークスペースを開く際に、VS Codeは以前の状態を正確に復元します。これにより、開発者は瞬時に異なるプロジェクトのコンテキストに切り替えることができます。

例えば、ある顧客プロジェクトの作業中に、急ぎで別の社内ツールのバグを修正する必要が生じたとします。社内ツールのワークスペースを開くと、そのプロジェクト固有のエディタ設定、必要なファイル、デバッグ構成などがすぐにロードされ、スムーズに作業を開始できます。作業終了後、顧客プロジェクトのワークスペースに戻れば、以前の作業状態がそのまま復元されています。複数のプロジェクトを並行して担当する場合や、緊急対応が多い場合に、このコンテキスト切り替えの容易さは大きなメリットとなります。

4. チーム開発での設定共有が容易になる

ワークスペース設定（.vscodeディレクトリや.code-workspaceファイル）をバージョン管理システム（Gitなど）にコミットして共有することで、チームメンバー全員が同じ開発環境設定をすぐに利用できます。

オンボーディングの効率化: 新しいメンバーがプロジェクトに参加した際に、リポジトリをクローンしてVS Codeでワークスペースファイルを開くだけで、推奨される拡張機能のインストールを促されたり、正しいコードスタイルやリンター設定が適用されたり、すぐにデバッグやタスクの実行が可能になったりします。セットアップにかかる時間を大幅に短縮できます。
環境差異による問題の削減: メンバー間でエディタ設定やツール設定が異なることに起因する問題を減らすことができます。例えば、インデント設定が異なるためにPull Requestで不要な差分が発生するといった状況を防げます。
プロジェクト固有のベストプラクティスの共有: プロジェクトで推奨されるデバッグ方法や、よく使うタスク（ビルド、テスト、デプロイなど）をlaunch.jsonやtasks.jsonとして共有することで、チーム全体の開発効率と品質を向上させることができます。

5. パフォーマンスの向上（場合による）

マルチルートワークスペースの場合、VS Codeはワークスペースに含まれるフォルダのみを対象にインデックス作成やファイル監視を行います。これにより、関連性のない巨大なフォルダ（例えば、ホームディレクトリ全体や、多数のプロジェクトを含む親ディレクトリ）を誤って開いてしまい、VS Codeの動作が遅くなる、といった状況を防ぐことができます。特に、リポジトリ内に多数のサブプロジェクトがあるモノレポ構成などで、特定のサブプロジェクトのみをワークスペースに含める場合に有効です。

6. VS Codeの機能を最大限に活用できる

多くのVS Code拡張機能や組み込み機能（例えば、デバッガー、タスクランナー、検索・置換機能、ソースコントロール機能など）は、ワークスペースの概念に基づいて設計されています。ワークスペースを適切に活用することで、これらの機能をプロジェクト固有の設定でカスタマイズし、そのポテンシャルを最大限に引き出すことができます。

これらのメリットを理解すれば、VS Codeワークスペースが単なるファイルの集まりではなく、プロジェクト全体の開発環境を定義・管理するための強力なツールであることがわかるでしょう。

ワークスペースの種類と作成方法

VS Codeのワークスペースには、主に「単一ルートワークスペース」と「マルチルートワークスペース」の2種類があります。それぞれの特徴と作成方法を見ていきましょう。

単一ルートワークスペース (フォルダを開く)

これがVS Codeで最も一般的なワークスペースの形態です。一つのプロジェクトのリポジトリやフォルダを開いた状態を指します。

特徴: 一つのルートフォルダのみを扱います。ワークスペースに関する設定は、開いているフォルダ直下の.vscodeディレクトリ内に保存されます。
作成方法:
1. VS Codeを起動します。
2. メニューから「ファイル」 > 「フォルダを開く…」を選択します。
3. 開きたいプロジェクトのルートフォルダを選択し、「フォルダを選択」ボタンをクリックします。

これで、選択したフォルダがVS Codeのサイドバーに表示され、単一ルートワークスペースとして開かれます。この状態で、エディタ設定、デバッグ設定、タスク設定などをワークスペース固有に保存したい場合は、以下の場所にファイルを作成・編集します。

ワークスペース設定: YOUR_PROJECT_ROOT/.vscode/settings.json
デバッグ設定: YOUR_PROJECT_ROOT/.vscode/launch.json
タスク設定: YOUR_PROJECT_ROOT/.vscode/tasks.json
推奨拡張機能: YOUR_PROJECT_ROOT/.vscode/extensions.json

これらのファイルは、そのフォルダを開いている単一ルートワークスペースでのみ有効な設定を定義します。

マルチルートワークスペース

複数の独立したフォルダを一つのVS Codeウィンドウでまとめて扱いたい場合に利用します。.code-workspaceファイルによって定義されます。

特徴: 複数のルートフォルダを扱います。ワークスペース全体の設定や、含まれるフォルダのリストは、.code-workspaceファイルに保存されます。各フォルダ自体も、そのフォルダ固有の設定を.vscodeディレクトリ内に持つことができます。設定の優先順位は、「フォルダ設定（.vscode内） > ワークスペース設定（.code-workspace内） > ユーザー設定」となります。
作成方法 (GUIを使用):
1. VS Codeを起動します。
2. メニューから「ファイル」 > 「ワークスペースにフォルダを追加…」を選択します。
3. ワークスペースに追加したい最初のフォルダを選択し、「追加」ボタンをクリックします。
4. 必要に応じて、手順2-3を繰り返して他のフォルダを追加します。追加されたフォルダは、VS Codeのサイドバーに表示されます。
5. すべてのフォルダを追加したら、メニューから「ファイル」 > 「ワークスペースをファイルとして保存…」を選択します。
6. .code-workspaceファイルの名前（例: my-complex-project.code-workspace）を入力し、保存場所を選択して「保存」ボタンをクリックします。通常は、関連するプロジェクトフォルダ群の親ディレクトリなどに保存します。

これで、指定したフォルダ群を含むマルチルートワークスペースが定義された.code-workspaceファイルが作成されました。次回からは、この.code-workspaceファイルを開くだけで、同じフォルダ構成と設定でVS Codeが起動します。

作成方法 (JSONを直接編集):
1. 空の.code-workspaceファイルを任意の場所に作成します（例: my-workspace.code-workspace）。
2. VS Codeでこのファイルを開きます（または、テキストエディタで開きます）。
3. 以下のJSON構造に基づいて内容を記述します。
json { "folders": [ { "path": "relative/path/to/folder1" }, { "path": "/absolute/path/to/folder2" // 絶対パスも可能 }, { "name": "My App", // 表示名 "path": "relative/path/to/app/folder" } ], "settings": { // ワークスペース全体に適用したい設定 }, "launch": { // デバッグ設定 }, "tasks": { // タスク設定 } }
4. ファイルを保存します。

この方法で作成した.code-workspaceファイルをVS Codeで開けば、ワークスペースが起動します。フォルダのパスは、.code-workspaceファイルからの相対パス、または絶対パスで指定できます。相対パスを使う場合は、.code-workspaceファイルをプロジェクトフォルダ群のルートディレクトリや、共通の親ディレクトリに配置するのが一般的です。

GUIでフォルダを追加した後、.code-workspaceファイルを直接編集して、フォルダの表示名を変えたり、順序を並べ替えたり、ワークスペース固有の設定を追加したりすることもよく行われます。

ワークスペースを開く・閉じる

開く:
- メニューから「ファイル」 > 「ワークスペースを開く…」を選択し、.code-workspaceファイルを選択します。
- 最近開いたワークスペースは、「ファイル」 > 「最近開いたもの」メニューから選択できます。
- OSのエクスプローラー/Finderで.code-workspaceファイルをダブルクリックしてVS Codeで開くように設定することも可能です。
- コマンドラインから code /path/to/your-workspace.code-workspace と実行します。
閉じる:
- メニューから「ファイル」 > 「ウィンドウを閉じる」を選択します。ワークスペースは閉じられますが、VS Codeウィンドウ自体は閉じない場合があります。
- メニューから「ファイル」 > 「VS Codeを終了」を選択すると、VS Code全体が閉じられます。
- 開いているワークスペースをフォルダとして再度開きたい場合は、「ファイル」>「フォルダを開く…」を選択し、ワークスペースに含まれるいずれかのフォルダを選択します。これにより、そのフォルダが単一ルートワークスペースとして開かれます。

ワークスペースを使い始めるのは非常に簡単ですが、その真価を発揮するのは、ワークスペース固有の設定を適切に構成し、マルチルートワークスペースを活用する場面です。

ワークスペース設定の詳細

VS Codeのワークスペース設定は、ユーザー設定、フォルダ（単一ルートワークスペース）設定、そしてワークスペース（マルチルートワークスペース）設定の3つのレベルで管理できます。これらの設定は、適用範囲と優先順位が異なります。

ユーザー設定 (User Settings): VS Code全体に適用される設定です。どのワークスペースを開いていても有効です。settings.jsonは、OSのユーザーディレクトリ配下のVS Code設定フォルダに保存されます。
ワークスペース設定 (Workspace Settings): マルチルートワークスペースの.code-workspaceファイル内のsettingsセクションに記述されるか、または単一ルートワークスペースの場合は開いているフォルダの.vscode/settings.jsonに記述される設定です。そのワークスペースを開いている間のみ有効です。
フォルダ設定 (Folder Settings): マルチルートワークスペースに含まれる個々のフォルダの.vscode/settings.jsonに記述される設定です。その特定のフォルダ内のファイルを開いている場合にのみ有効です。

設定の優先順位は、フォルダ設定 > ワークスペース設定 > ユーザー設定 > デフォルト設定 となります。最も狭いスコープ（フォルダ）の設定が最も優先され、次にワークスペース全体の設定、そしてVS Code全体の設定、最後にVS Codeのデフォルト設定が適用されます。

ここでは、ワークスペースレベル（.code-workspaceのsettingsセクション、または単一ルートの.vscode/settings.json）でよく利用される設定や、デバッグ・タスク・拡張機能に関する設定ファイルについて詳しく見ていきます。

`settings.json` (ワークスペースレベル)

プロジェクト固有のエディタ挙動、ファイルの表示/非表示、検索対象の除外などを設定するのに使われます。単一ルートの場合は.vscode/settings.jsonに、マルチルートの場合は.code-workspaceファイルのsettingsセクションに記述します。

よく使うワークスペース設定例:

“`json
{
“settings”: { // マルチルートワークスペースの場合、このオブジェクトの中に記述
// エディタの基本設定
“editor.tabSize”: 4, // タブのサイズ（スペース数）
“editor.insertSpaces”: true, // タブキーでスペースを挿入
“editor.formatOnSave”: true, // ファイル保存時に自動フォーマット
“editor.codeActionsOnSave”: {
“source.fixAll.eslint”: true // 保存時にESLintの自動修正を実行（ESLint拡張機能が必要）
},
“editor.wordWrap”: “on”, // 自動折り返しを有効にする
“files.encoding”: “utf8”, // ファイルエンコーディング
“files.eol”: “\n”, // 改行コード LF または CRLF
“files.autoSave”: “afterDelay”, // 自動保存設定 (“off”, “afterDelay”, “onFocusChange”, “onWindowChange”)

    // ファイルエクスプローラーで表示しないファイル/フォルダ
    "files.exclude": {
        "**/.git": true, // .gitディレクトリを非表示
        "**/.DS_Store": true, // macOSの隠しファイルを非表示
        "**/node_modules": true, // node_modulesディレクトリを非表示
        "**/dist": true, // ビルド出力ディレクトリを非表示
        "**/build": true // ビルド出力ディレクトリを非表示
    },

    // 検索対象から除外するファイル/フォルダ
    "search.exclude": {
        "**/node_modules": true,
        "**/bower_components": true,
        "**/dist": true
    },

    // 言語固有の設定
    "[javascript]": {
        "editor.tabSize": 2 // JavaScriptファイルではタブサイズを2にする（ワークスペース設定を上書き）
    },
    "[typescript]": {
        "editor.defaultFormatter": "vscode.typescript-language-features" // TypeScriptファイルのデフォルトフォーマッター
    },
    "[python]": {
        "editor.formatOnType": true, // Pythonでは入力中にフォーマット
        "editor.defaultFormatter": "ms-python.black-formatter" // Pythonのデフォルトフォーマッター（Black拡張機能が必要）
    },

    // 拡張機能固有の設定例 (ESLint, Prettierなど)
    "eslint.validate": [
        "javascript",
        "typescript"
    ], // ESLintを適用する言語
    "prettier.singleQuote": true, // Prettierでシングルクォートを使用
    "prettier.semi": false // Prettierでセミコロンを省略

    // ...その他のVS Code設定
}

}
“`

コメント: JSONファイルには、// または /* ... */ でコメントを記述できます。設定の意図などをメモしておくと、後で見返したときに分かりやすいです。
言語固有の設定: 特定の言語のファイルを開いている場合にのみ適用される設定は、"[language_id]": { ... } の形式で記述します。これにより、プロジェクト内の異なる言語に対して異なる設定を適用できます。
拡張機能固有の設定: インストールされている拡張機能は、多くの場合VS Codeの設定メカニズムを利用します。ワークスペースレベルでこれらの設定を記述することで、プロジェクト推奨の拡張機能設定を強制できます。

これらの設定を適切に構成することで、プロジェクトメンバー全員が同じエディタ設定、フォーマット設定、リンター設定で開発を進められるようになり、コードの一貫性を保つことができます。

`launch.json` (デバッグ設定)

VS Codeの強力な機能の一つにデバッガーがあります。launch.jsonファイルは、アプリケーションを特定のランタイム（Node.js, Python, Javaなど）で起動したり、実行中のプロセスにアタッチしたりするためのデバッグ構成を定義します。これは通常、単一ルートワークスペースの場合は.vscode/launch.jsonに、マルチルートワークスペースの場合は.code-workspaceファイルのlaunchセクションに記述します。

launch.json の基本構造:

json { // Use IntelliSense to learn about possible attributes. // Hover to view descriptions of existing attributes. // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387 "version": "0.2.0", // launch.jsonのバージョン "configurations": [ // デバッグ構成のリスト { // 個々のデバッグ構成 "type": "node", // デバッガーのタイプ (node, python, java, chromeなど) "request": "launch", // リクエストタイプ (launch or attach) "name": "Launch Program", // デバッグ構成の名前 (VS CodeのUIに表示される) "program": "${workspaceFolder}/src/index.js", // 起動するプログラムのパス "cwd": "${workspaceFolder}", // プログラムを実行する作業ディレクトリ "outFiles": [ "${workspaceFolder}/dist/**/*.js" // JavaScriptのソースマップ設定など ], "skipFiles": [ "<node_internals>/**" // デバッグ時にスキップするファイル ], "env": { "NODE_ENV": "development" // 環境変数 }, "console": "integratedTerminal" // デバッグコンソールのタイプ }, { // 別のデバッグ構成例 (特定の引数付きで起動) "type": "node", "request": "launch", "name": "Launch with Arguments", "program": "${workspaceFolder}/src/cli.js", "args": [ "--verbose", "input.txt" ] // プログラムに渡す引数 }, { // 別のデバッグ構成例 (リモートプロセスにアタッチ) "type": "node", "request": "attach", "name": "Attach to Process ID", "processId": "${command:PickProcess}", // アタッチするプロセスIDを選択 "skipFiles": [ "<node_internals>/**" ] } // ...必要に応じて他のデバッグ構成を追加 ] }

version: launch.jsonのバージョンを指定します。
configurations: デバッグ構成を複数定義するための配列です。
各構成オブジェクト:
- type: 使用するデバッガーを指定します。インストールされている拡張機能によって様々なタイプが利用可能です（例: node, python, chrome, java, go など）。
- request: launch（プログラムを起動してデバッグ）またはattach（実行中のプログラムにアタッチしてデバッグ）を指定します。
- name: デバッグサイドバーのドロップダウンに表示される、この構成の名前です。分かりやすい名前をつけましょう。
- その他のプロパティは、選択したtypeとrequestによって異なります。プログラムのパス、ポート番号、環境変数、コマンドライン引数などを指定できます。"${workspaceFolder}"のような変数を使用すると、ワークスペースのルートディレクトリを基準にしたパスを指定できます。

マルチルートワークスペースの場合、.code-workspaceファイルのlaunchセクションにデバッグ構成を記述すると、そのワークスペース全体で利用可能なデバッグ構成となります。例えば、フロントエンドとバックエンドを両方含むワークスペースで、フロントエンドのデバッグ構成とバックエンドのデバッグ構成を両方定義しておき、必要に応じて切り替えて使用するといったことが可能です。

特定のフォルダの.vscode/launch.jsonにデバッグ構成が存在する場合、それらの構成はワークスペースのlaunchセクションで定義された構成とマージされます。

`tasks.json` (タスク設定)

ビルド、テスト、コード分析、あるいはシェルコマンドの実行など、プロジェクトに関連する定型的なタスクを定義します。これにより、開発者はVS Codeのコマンドパレットやターミナルから簡単にこれらのタスクを実行できるようになります。tasks.jsonは通常、単一ルートワークスペースの場合は.vscode/tasks.jsonに、マルチルートワークスペースの場合は.code-workspaceファイルのtasksセクションに記述します。

tasks.json の基本構造:

json { // See https://go.microsoft.com/fwlink/?LinkId=733558 // for the documentation about the tasks.json format "version": "2.0.0", // tasks.jsonのバージョン "tasks": [ // タスク定義のリスト { // 個々のタスク定義 "label": "Build Frontend", // タスクの名前 (VS CodeのUIに表示される) "type": "shell", // タスクのタイプ (shell, process, custom, gulp, grunt, npm, vscodeなど) "command": "npm run build", // 実行するコマンド "problemMatcher": "$eslint-compact", // 問題マッチャー (ビルドエラーなどをVS Codeの「問題」パネルに表示) "group": { "kind": "build", "isDefault": true // デフォルトのビルドタスクとして登録 }, "presentation": { "reveal": "always", // タスク実行時にターミナルを表示 "panel": "new" // 新しいターミナルパネルで実行 }, "options": { "cwd": "${workspaceFolder}/frontend" // このタスクを実行する作業ディレクトリ } }, { // 別のタスク定義例 (バックエンドのテスト実行) "label": "Run Backend Tests", "type": "shell", "command": "npm test", "problemMatcher": [], // 問題マッチャーは使用しない "group": "test", // テストグループに属するタスクとして登録 "options": { "cwd": "${workspaceFolder}/backend" } } // ...必要に応じて他のタスクを追加 ] }

version: tasks.jsonのバージョンを指定します。
tasks: タスク定義を複数定義するための配列です。
各タスクオブジェクト:
- label: タスクの名前です。コマンドパレット（Cmd+Shift+P or Ctrl+Shift+P）から「タスクの実行」を選んだ際に表示されます。
- type: タスクの種類です。shellはシェルコマンドを実行、processはプログラムを直接実行、npm, gulp, grunt はそれぞれのツールを統合したタスクタイプです。
- command: 実行するコマンドです。typeがshellの場合はシェルコマンド文字列、typeがprocessの場合は実行ファイル名とその引数を指定します。
- problemMatcher: コマンドの出力（コンパイラエラー、リンター警告など）を解析し、VS Codeの「問題」パネルに表示するための設定です。組み込みのマッチャー（$eslint-compact, $tscなど）やカスタムマッチャーを定義できます。
- group: タスクを特定のグループ（build, testなど）に分類します。isDefault: true を指定すると、そのグループのデフォルトタスクとして登録され、特定のキーバインド（例: Cmd+Shift+B でデフォルトのビルドタスクを実行）で実行できるようになります。
- presentation: タスク実行時のターミナルの表示方法などを制御します。
- options: cwd（作業ディレクトリ）やenv（環境変数）など、コマンド実行時のオプションを設定します。マルチルートワークスペースの場合、cwdで特定のフォルダを指定することがよくあります。

マルチルートワークスペースの.code-workspaceファイル内のtasksセクションにタスクを記述すると、ワークスペース全体で利用可能なタスクとなります。特定のフォルダの.vscode/tasks.jsonにタスクが存在する場合、それらのタスクはワークスペースのtasksセクションで定義されたタスクとマージされます。ただし、同じlabelを持つタスクが複数存在した場合の挙動には注意が必要です。一般的には、ワークスペース全体に関わるタスク（例: 全体をビルドするタスク）を.code-workspaceに、特定のフォルダ（プロジェクト）内でのみ必要なタスク（例: そのプロジェクトの単体テスト実行タスク）をそのフォルダの.vscode/tasks.jsonに定義するのが良いプラクティスです。

`extensions.json` (推奨拡張機能)

ワークスペースで開発を行う上で推奨される、あるいは必須となるVS Code拡張機能のリストを定義します。このファイルは通常、単一ルートワークスペースの場合は.vscode/extensions.jsonに記述します。マルチルートワークスペースの場合は、ワークスペース全体に推奨拡張機能を適用したいなら、.code-workspaceファイルのextensionsセクションに記述します。または、ワークスペース内の特定のフォルダでのみ推奨したい場合は、そのフォルダの.vscode/extensions.jsonに記述します。

extensions.json の基本構造:

json { // See https://go.microsoft.com/fwlink/?LinkId=827846 // for the documentation about the extensions.json format "recommendations": [ // 推奨拡張機能のリスト (publisher.extension-name 形式) "dbaeumer.vscode-eslint", // ESLint 拡張機能 "esbenp.prettier-vscode", // Prettier 拡張機能 "ms-python.python", // Python 拡張機能 "ms-python.black-formatter", // Black Formatter 拡張機能 "editorconfig.editorconfig" // EditorConfig for VS Code 拡張機能 ], "unwantedRecommendations": [ // このワークスペースでは推奨しない（非表示にしたい）拡張機能のリスト "some.unwanted-extension" ] }

recommendations: このワークスペースで推奨する拡張機能のID（publisher.extension-name 形式）のリストです。このリストが存在する場合、VS Codeはそのワークスペースを開いた際に、推奨されているがまだインストールされていない拡張機能があることを通知し、インストールを促します。
unwantedRecommendations: このワークスペースでは推奨しない（つまり、他の場所で推奨されていても、このワークスペースでは推奨リストに表示しない）拡張機能のリストです。

このファイルをGitで共有することで、チームメンバーがプロジェクトに参加した際に、どのような拡張機能が必要なのかを一目で確認し、簡単にインストールできるようになります。これにより、開発環境のセットアップ時間を短縮し、チーム全体の開発環境の統一性を保つことができます。

その他の設定ファイル (`.vscode` ディレクトリ内のファイル)

.vscodeディレクトリには、上記以外にも、特定の拡張機能が独自の構成ファイルを保存したり、VS Codeが内部的な状態を保存したりすることがあります。例えば、拡張機能によっては、独自のJSONファイルや設定ファイルをこのディレクトリ内に作成することがあります。これらのファイルもワークスペースの一部として管理されることがありますが、その内容は使用している拡張機能に依存します。Gitで共有するかどうかは、そのファイルの内容（ユーザー固有の情報が含まれるか、プロジェクト共通の設定かなど）によって判断する必要があります。

マルチルートワークスペースの活用法

マルチルートワークスペースは、複数のフォルダをまとめて扱うことで、複雑なプロジェクト構成や開発ワークフローに柔軟に対応できます。ここでは、具体的な活用シナリオと、それぞれのシナリオでどのようにマルチルートワークスペースが役立つのかを見ていきます。

モノレポ開発での利用例

複数の独立したパッケージやアプリケーションが単一のGitリポジトリで管理されているモノレポ構成は、近年よく採用されています。このような構成では、各パッケージが独自のフォルダを持ち、それぞれが独自の依存関係やビルドプロセスを持つ場合があります。

ワークスペースの構成: モノレポのルートディレクトリにある.code-workspaceファイルに、開発対象となる主要なパッケージやアプリケーションのフォルダを追加します。共通ライブラリフォルダなども含めると良いでしょう。
json { "folders": [ { "name": "App A", "path": "packages/app-a" }, { "name": "App B", "path": "packages/app-b" }, { "name": "Common Lib", "path": "packages/common-lib" }, { "name": "Docs", "path": "docs" } // 文書フォルダなども追加 ], "settings": { // モノレポ全体に適用される設定（例: ファイル除外、検索除外） "files.exclude": { "**/node_modules": true, "**/.turbo": true // Turborepo などのキャッシュディレクトリ }, "search.exclude": { "**/node_modules": true }, // ...モノレポ共通のESLint, Prettier, TypeScript設定など }, "tasks": { "tasks": [ { "label": "Build All", "type": "shell", "command": "npx turbo run build", // Turborepo や Lerna などを使った全体ビルドコマンド "group": "build" }, { "label": "Test App A", "type": "shell", "command": "npm test", "options": { "cwd": "${workspaceFolder:App A}" } // 特定のフォルダを作業ディレクトリに指定 } ] } }
メリット:
- 全体把握と移動の容易さ: サイドバーにすべての関連フォルダが表示されるため、モノレポ全体の構造を把握しやすく、フォルダ間の移動が容易です。
- クロスプロジェクト操作: ワークスペース全体を対象にしたファイル検索、置換、シンボル検索、リファクタリングなどが可能になります。共通ライブラリの変更が各アプリケーションに与える影響を確認しながら作業できます。
- 一元化された設定: モノレポ全体に適用したいコードスタイルやリンター設定、TypeScript設定などをワークスペース設定で一元管理できます。
- 連携デバッグ: 複数のアプリケーションやライブラリを同時に起動してデバッグする必要がある場合、launch.jsonで複数のデバッグ構成を定義し、連携してデバッグすることが可能になります。
- タスク管理: モノレポ全体をビルドするタスクや、特定のパッケージのテストを実行するタスクなどをtasks.jsonで定義しておくと便利です。${workspaceFolder:<FolderName>}のように、特定のフォルダを作業ディレクトリとして指定できます。

マイクロサービス開発での利用例

複数の独立したマイクロサービスが協調して動作するシステムを開発する場合、開発対象のサービスに加えて、そのサービスが依存する他のサービスや、関連性の高いサービスを同時に開いて作業することがよくあります。

ワークスペースの構成: 開発中の主要なサービスフォルダに加えて、APIゲートウェイ、認証サービス、あるいは特定の連携先となるサービスなどのフォルダをワークスペースに追加します。
json { "folders": [ { "name": "User Service", "path": "../user-service" }, { "name": "Order Service", "path": "." }, // 現在のディレクトリを Order Service として追加 { "name": "Auth Service (Read Only)", "path": "../auth-service", "allowIndexing": false } // 検索対象から除外 ], "settings": { // ワークスペース全体に適用される一般的な設定 }, "launch": { "configurations": [ { "name": "Launch Order Service", "type": "node", // またはサービスの種類に応じたデバッガー "request": "launch", "program": "${workspaceFolder:Order Service}/src/index.js", "cwd": "${workspaceFolder:Order Service}", "env": { "PORT": "3001" } }, { "name": "Launch User Service", "type": "node", "request": "launch", "program": "${workspaceFolder:User Service}/src/index.js", "cwd": "${workspaceFolder:User Service}", "env": { "PORT": "3002" } } ] } }
メリット:
- サービス連携の確認: 複数のサービスコードを並べて確認しながら開発できます。API仕様やデータ構造の確認などが容易になります。
- 分散デバッグ: 複数のサービスを同時に起動し、サービス間連携を含めたデバッグが可能になります。.code-workspaceのlaunchセクションで、各サービスを起動するためのデバッグ構成を定義しておくと便利です。
- 関連ファイルの素早いアクセス: 特定のサービスフォルダ内のファイルだけでなく、関連する他のサービスフォルダ内のファイルにも素早くアクセスできます。
- 全体像の把握: マイクロサービスシステム全体の一部をワークスペースとして開くことで、開発中の部分がシステム全体の中でどのように位置づけられているかを意識しやすくなります。

フロントエンド + バックエンド構成での利用例

フロントエンドとバックエンドが別々のフォルダ（あるいは別々のリポジトリをサブモジュールなどで管理している場合）で管理されている構成はよくあります。これらを同時に開発する場合にマルチルートワークスペースが役立ちます。

ワークスペースの構成: フロントエンドのルートフォルダとバックエンドのルートフォルダをワークスペースに追加します。
json { "folders": [ { "name": "Frontend", "path": "./frontend" }, { "name": "Backend", "path": "./backend" } ], "settings": { // ワークスペース全体に適用される一般的な設定 }, "launch": { "configurations": [ { "name": "Launch Frontend (Debug)", "type": "chrome", // またはその他のフロントエンドデバッガー "request": "launch", "url": "http://localhost:3000", "webRoot": "${workspaceFolder:Frontend}/src" }, { "name": "Launch Backend (Debug)", "type": "node", // またはその他のバックエンドデバッガー "request": "launch", "program": "${workspaceFolder:Backend}/src/index.js", "cwd": "${workspaceFolder:Backend}", "envFile": "${workspaceFolder:Backend}/.env" // 環境変数ファイル } ], // Compound Launch Configuration: フロントエンドとバックエンドを同時に起動・デバッグ "compounds": [ { "name": "Debug Fullstack", "configurations": [ "Launch Frontend (Debug)", "Launch Backend (Debug)" ] } ] }, "tasks": { "tasks": [ { "label": "Start Dev Servers", "dependsOrder": "sequence", // タスクの実行順序を保証 "dependsOn": [ "Start Backend Dev", "Start Frontend Dev" ], "problemMatcher": [] }, { "label": "Start Frontend Dev", "type": "shell", "command": "npm start", // フロントエンドの開発サーバー起動コマンド "isBackground": true, // バックグラウンドで実行 "presentation": { "group": "devServers" }, "options": { "cwd": "${workspaceFolder:Frontend}" }, "problemMatcher": [] }, { "label": "Start Backend Dev", "type": "shell", "command": "npm run dev", // バックエンドの開発サーバー起動コマンド "isBackground": true, "presentation": { "group": "devServers" }, "options": { "cwd": "${workspaceFolder:Backend}" }, "problemMatcher": [] } ] } }
メリット:
- 単一ウィンドウでの開発: フロントエンドとバックエンドのコードを一つのVS Codeウィンドウで扱えるため、ウィンドウ切り替えの手間が省け、集中して開発できます。
- 連携デバッグ: Compound Launch Configurationを利用して、フロントエンドとバックエンドを同時に起動し、両方のコードに対してブレークポイントを設定してデバッグできます。これにより、フルスタックな開発体験が向上します。
- 共通タスク: 開発サーバーの起動、ビルド、テストなど、フロントエンドとバックエンドの両方に関連するタスクをtasks.jsonで定義し、簡単に実行できます。タスクの依存関係を設定して、バックエンド起動後にフロントエンドを起動するといった順序付けも可能です。
- コード間の参照: フロントエンドコードからバックエンドAPIの定義（例えばSwagger/OpenAPI仕様のファイル）を参照したり、共通のモデル定義ファイルを両方のプロジェクトで使用したりする場合に、ファイルアクセスが容易になります。

各フォルダ固有の設定とワークスペース全体の共通設定

マルチルートワークスペースでは、各フォルダ直下の.vscodeディレクトリにフォルダ固有の設定（settings.json, launch.json, tasks.jsonなど）を持つことができます。同時に、.code-workspaceファイル内でワークスペース全体に適用される設定を定義できます。

ワークスペース設定 (.code-workspace の settings セクション):
- ワークスペース全体に適用したい、一般的なエディタ設定（タブサイズ、フォーマット設定など）。
- ワークスペース内のすべてのフォルダに適用される、ファイルやフォルダの除外設定（files.exclude, search.exclude）。
- ワークスペース全体で共有される、共通のリンターやフォーマッターの設定（プロジェクトによってはモノレポのルートに設定ファイルがあり、それをVS Code設定で参照する場合など）。
- ワークスペース全体で利用できるデバッグ構成やタスク定義（例: モノレポ全体のビルドタスク、連携デバッグ構成）。
フォルダ設定 (各フォルダの .vscode ディレクトリ):
- 特定のフォルダ（プロジェクト）にのみ適用したい、そのプロジェクト固有のエディタ設定（例: フロントエンドはタブサイズ2、バックエンドはタブサイズ4など、ワークスペース設定を上書きしたい場合）。
- そのプロジェクトに固有のデバッグ構成やタスク定義（例: 特定のサービスの起動・デバッグ構成、特定のパッケージのテストタスク）。
- そのプロジェクトにのみ推奨される拡張機能（.vscode/extensions.json）。

設定の優先順位は「フォルダ設定 > ワークスペース設定 > ユーザー設定」であるため、特定のフォルダに対してワークスペース全体の設定を上書きしたい場合は、そのフォルダの.vscode/settings.jsonに設定を記述します。

例えば、ワークスペース全体ではインデントをスペース4に設定しているが、特定のフロントエンドフォルダ内ではスペース2にしたい場合、.code-workspaceには"editor.tabSize": 4と記述し、フロントエンドフォルダ内の.vscode/settings.jsonには"editor.tabSize": 2と記述します。これにより、フロントエンドフォルダ内のファイルを開いているときはタブサイズ2が適用され、その他のフォルダのファイルを開いているときはタブサイズ4が適用されます。

このように、ワークスペース設定とフォルダ設定を適切に使い分けることで、全体的な統一性を保ちつつ、プロジェクトごとの個別のニーズにも対応できる柔軟な開発環境を構築できます。

ワークスペースの管理と操作

ワークスペースを作成・設定するだけでなく、日々の開発で効率的にワークスペースを管理・操作する方法を知っておくことも重要です。

ワークスペースの開く/閉じる方法

前述の「ワークスペースの種類と作成方法」セクションで触れましたが、改めて重要な操作を確認します。

開く:
- メニュー: 「ファイル」 > 「ワークスペースを開く…」
- 最近開いたもの: 「ファイル」 > 「最近開いたもの」 > ワークスペース名を選択
- コマンドパレット: Cmd+Shift+P (Ctrl+Shift+P) を開き、「Workspaces: Open Workspace」または「Workspaces: Open Recent Workspace」と入力して選択
- コマンドライン: code /path/to/your-workspace.code-workspace
- OSのファイルエクスプローラー: .code-workspaceファイルをダブルクリック（関連付けされている場合）
閉じる:
- メニュー: 「ファイル」 > 「ウィンドウを閉じる」（ワークスペースを閉じ、VS Codeウィンドウを残す）
- メニュー: 「ファイル」 > 「VS Codeを終了」（ワークスペースを閉じ、VS Code全体を終了する）
- コマンドパレット: 「Workspaces: Close Workspace」

最近開いたワークスペースの利用

VS Codeは最近開いたワークスペースやフォルダの履歴を保持しています。「ファイル」 > 「最近開いたもの」メニューや、コマンドパレットの「Workspaces: Open Recent Workspace」コマンドから、以前のワークスペースに素早くアクセスできます。これにより、複数のプロジェクトを並行して開発している場合に、コンテキストを素早く切り替えることができます。

履歴リストは、VS Codeのユーザー設定で管理することも可能です。"window.reopenFolders": "all" や "window.restoreWindows": "all" などの設定を確認してみてください。

ワークスペースの切り替え

厳密には「ワークスペースを切り替える」という独立したコマンドはありません。通常は、現在開いているワークスペースを閉じ、別のワークスペースを開くという操作になります。しかし、上記の「最近開いたワークスペース」機能を使えば、実質的に素早い切り替えが可能です。

また、複数のVS Codeウィンドウを開いて、それぞれ異なるワークスペースで作業するというスタイルをとることもできます。新しいウィンドウを開くには、「ファイル」 > 「新規ウィンドウ」を選択します。

ワークスペースファイルの編集

マルチルートワークスペースの定義ファイルである.code-workspaceファイルは、VS Codeで直接編集できます。

GUIで編集:
1. ワークスペースを開きます。
2. サイドバーのファイルエクスプローラーに表示されているフォルダ群の上部にあるワークスペース名をクリックします。
3. 表示されるコンテキストメニューから「ワークスペース設定 (JSON) を編集」を選択します。これにより、.code-workspaceファイルがエディタで開かれ、JSON形式で編集できます。
4. 「ワークスペースにフォルダを追加…」や、エクスプローラーでフォルダを右クリックして「ワークスペースからフォルダを削除」といったGUI操作でも、.code-workspaceファイルの内容が変更されます。
JSONを直接編集: .code-workspaceファイルをVS Codeや他のエディタで開き、JSONを手動で編集することももちろん可能です。フォルダの順序を並べ替えたり、nameプロパティを追加したり、settingsセクションに設定を直接記述したりする場合に便利です。VS Codeで開けば、JSONスキーマによる補完やエラーチェックが利用できます。

.code-workspaceファイルを編集して保存すると、変更が即座に、あるいはVS Codeを再起動した際に反映されます。

ワークスペース内のフォルダの追加/削除/並べ替え

マルチルートワークスペースを開いている状態で、ワークスペースに含まれるフォルダをGUI操作で変更できます。

追加:
- メニュー: 「ファイル」 > 「ワークスペースにフォルダを追加…」
- コマンドパレット: 「Workspaces: Add Folder to Workspace」
削除:
- サイドバーのファイルエクスプローラーで、削除したいルートフォルダを右クリックし、「ワークスペースからフォルダを削除」を選択します。
並べ替え:
- サイドバーのファイルエクスプローラーで、ルートフォルダをドラッグ＆ドロップして順序を並べ替えることができます。この変更は.code-workspaceファイルに自動的に保存されます。

これらの操作を行うと、VS Codeは自動的に.code-workspaceファイルを更新します。

効率的なワークスペース管理は、特に複数のプロジェクトや複雑な構成を扱う開発者にとって、開発体験を大きく左右します。VS Codeのこれらの管理・操作機能を習得することで、ワークフローをよりスムーズに進めることができます。

ワークスペースと拡張機能

VS Codeの拡張機能は、その機能をワークスペース単位で調整できる場合があります。これは、特定のプロジェクトでのみ特定の拡張機能を有効にしたい、あるいは拡張機能の設定をプロジェクト固有に上書きしたい場合に非常に便利です。

ワークスペースレベルで有効/無効にできる拡張機能

多くの拡張機能は、ユーザーレベルだけでなく、ワークスペースレベルで有効/無効を切り替えることができます。

VS Codeの拡張機能ビュー（サイドバーのアイコン、またはCmd+Shift+X / Ctrl+Shift+X）を開きます。
管理したい拡張機能を選択します。
拡張機能の詳細ビューが表示されます。ここで、拡張機能のアイコンの右にある歯車アイコンをクリックし、「有効にする (ワークスペース)」または「無効にする (ワークスペース)」を選択します。
「無効にする (ワークスペース)」を選択した場合、そのワークスペースを開いている間、その拡張機能は機能しません。
「有効にする (ワークスペース)」は、ユーザー設定で拡張機能を無効にしているが、特定のワークスペースでは有効にしたい場合に利用します。

この設定は、マルチルートワークスペースの場合は.code-workspaceファイル内に、単一ルートワークスペースの場合は.vscode/settings.jsonファイル内に、"extensions.enabledWithoutWorkspace": [...] や "extensions.disabledInWorkspace": [...] といった設定として保存されます。

これは、特定のワークスペースで競合する拡張機能がある場合や、プロジェクトに関係のない拡張機能を無効にしてVS Codeの起動速度やパフォーマンスを向上させたい場合に役立ちます。

ワークスペース固有の設定を持つ拡張機能の例

多くの拡張機能は、VS Codeの標準設定メカニズムを利用しており、ワークスペースレベルでその設定を上書きできます。前述のsettings.jsonの項目で触れたように、.code-workspaceのsettingsセクションや.vscode/settings.jsonに、拡張機能固有の設定を記述できます。

例:

リンター/フォーマッター: ESLint, Prettier, Black, GoFmt などの拡張機能は、フォーマット実行タイミング（保存時など）、使用する設定ファイルのパス、適用するルールなどをワークスペース設定で定義できます。これにより、プロジェクトで採用しているコードスタイルや規約をチームメンバー間で統一できます。
デバッガー: 特定の言語やフレームワークのデバッガー拡張機能は、launch.jsonでそのデバッガー固有の設定プロパティ（ポート、プログラムパス、環境変数など）を定義します。
言語サポート: TypeScript, Python, Java などの言語拡張機能は、コンパイラオプション、パス設定、リンティング設定などをワークスペース設定で上書きできます。
Docker: Docker拡張機能は、特定のDockerfileやdocker-composeファイル、コンテナ起動設定などをワークスペースに関連付けて管理できます。
Remote Development: Remote – SSH, Remote – Containers などの拡張機能は、接続先やコンテナに関する設定をワークスペースに関連付けられます。ワークスペースを開く際に自動的にリモート環境に接続するといった設定が可能です。

これらの拡張機能設定をワークスペースファイルや.vscodeディレクトリに含めてGitで管理することで、チームメンバーはプロジェクトをクローンし、ワークスペースを開くだけで、開発に必要なツールや設定がすぐに整った状態になります。

`extensions.json` による推奨拡張機能の活用

.vscode/extensions.jsonまたは.code-workspaceファイルのextensionsセクションに推奨拡張機能のリストを記述することは、チーム開発において非常に有効です。

プロジェクトに必要な拡張機能を明示的にリストアップすることで、新しいチームメンバーがどのような拡張機能をインストールすれば良いか迷うことがなくなります。VS Codeは、ワークスペースを開いた際に、このリストに記載されている拡張機能で、まだインストールされていないものや無効になっているものを検出し、右下にポップアップ通知を表示してインストールや有効化を促します。

この機能は、特にプロジェクトごとに要求される技術スタックが大きく異なる場合に、環境構築の手間を削減し、チーム全体の開発環境の統一性を高めるのに役立ちます。

ワークスペースとGit/バージョン管理

VS Codeワークスペースの設定ファイル（.vscodeディレクトリ全体や.code-workspaceファイル）は、プロジェクトのコードと同様にバージョン管理システム（Gitなど）で管理することが強く推奨されます。

ワークスペース設定ファイルをGitで管理するメリット

チームメンバー間での設定共有: 前述の通り、ワークスペース設定をGitリポジトリに含めることで、チームメンバー全員が同じ開発環境設定を共有できます。これは、オンボーディングの効率化、環境差異による問題の削減、コードスタイルや開発プラクティスの統一に大きく貢献します。
環境の再現性: 特定のコミット時点でのプロジェクトコードと、それに合わせたVS Codeの設定をセットで管理できます。過去のバージョンに戻って作業する必要が生じた際にも、当時の開発環境設定を再現しやすくなります。
設定変更の追跡: ワークスペース設定ファイルの変更履歴をGitで追跡できるため、誰が、いつ、どのような設定変更を行ったかを確認できます。問題が発生した場合の原因特定にも役立ちます。
プルリクエストによる設定のレビュー: 新しい設定の追加や既存設定の変更をプルリクエストを通じて行うことで、チーム内でレビューし、合意形成を図ることができます。

`.vscode` フォルダや `.code-workspace` ファイルをコミットする際の注意点

ワークスペース設定ファイルをGitで管理する際には、いくつか注意すべき点があります。

秘匿情報を含めない: パスワード、APIキー、秘密鍵などの秘匿情報は、絶対に設定ファイルに直接記述してGitリポジトリにコミットしないでください。これらの情報は、環境変数や、VS Codeのシークレットストレージ、またはプロジェクト固有の安全な方法（例: AWS Secrets Manager, HashiCorp Vault などから取得して環境変数に設定）で管理すべきです。もし、やむを得ず一時的にテスト目的などで設定ファイルに含めた場合は、コミットする前に必ず削除してください。
絶対パスに注意: .code-workspaceファイルでフォルダのパスを絶対パスで指定した場合、そのワークスペースは他の開発者の環境では正しく機能しない可能性が高いです。特別な理由がない限り、相対パスを使用するようにしてください。相対パスは.code-workspaceファイルが置かれているディレクトリからの相対パスとなります。
ユーザー固有の設定を除外: .vscodeディレクトリには、デバッグ履歴やワークスペース状態など、ユーザー固有の情報が保存されるファイルが含まれる場合があります。これらのファイルはチームで共有すべきではないため、.gitignoreに追加してバージョン管理の対象から除外する必要があります。
ファイルサイズの大きなものに注意: 拡張機能によっては、.vscodeディレクトリ内にキャッシュや大きなファイルを生成する場合があります。これらを誤ってコミットしないように注意が必要です。

`.gitignore` の設定例

ワークスペース設定ファイルをGitで管理する場合、通常は.code-workspaceファイル自体はコミットし、単一ルートワークスペースやマルチルートワークスペースに含まれる各フォルダの.vscodeディレクトリもコミットします。ただし、.vscodeディレクトリ内の一部のファイルはコミットから除外すべきです。

一般的な.gitignoreファイルにおける.vscode関連の記述例は以下のようになります。

“`gitignore

VS Code specific files

.vscode/*

Keep specific settings files

!.vscode/settings.json
!.vscode/launch.json
!.vscode/tasks.json
!.vscode/extensions.json

Exclude files that often contain user-specific or transient data

.vscode/.code-workspace # マルチルートワークスペースファイルをリポジトリ直下に置く場合は除く
.vscode/launch.json.backup # デバッグ設定のバックアップなど
.vscode/settings.json.backup
.vscode/keybindings.json # キーバインドは通常ユーザー設定
.vscode/snippets/ # スニペットは通常ユーザー設定またはプロジェクト固有で管理
.vscode/vsImplicitProj.json # TypeScriptなどが生成する一時ファイル
.vscode/.debug/.history
.vscode/ipch/ # C++などでのIntelliSenseキャッシュ
.vscode/.log # 拡張機能が生成するログファイル
“`

この例では、.vscodeディレクトリ内のすべてのファイルをデフォルトで無視し、その後、チームで共有したい特定のファイル（settings.json, launch.json, tasks.json, extensions.json）のみを例外としてバージョン管理の対象に含めています。.code-workspaceファイルは、リポジトリのルートに置く場合は.gitignoreから除外（あるいは .gitignore自体に含めない）必要があります。

プロジェクトやチームの運用方針に合わせて、どのファイルを共有し、どのファイルを除外するかを決定し、.gitignoreを適切に設定することが重要です。

ワークスペース利用におけるベストプラクティス

VS Codeワークスペースを効果的に活用するためのベストプラクティスをまとめます。

ワークスペース設定とユーザー設定の使い分け

設定の優先順位は「フォルダ設定 > ワークスペース設定 > ユーザー設定 > デフォルト設定」です。これを踏まえて、どの設定をどこに記述するかを判断しましょう。

ユーザー設定: どのプロジェクトでも共通して使用したい、個人的なエディタ設定（テーマ、フォント、キーバインドなど）、よく使う拡張機能の全体的な設定はユーザー設定に記述します。これは個人の好みに合わせて自由に設定できる部分です。
ワークスペース設定 (またはフォルダ設定): プロジェクト固有のルールや、チームで統一したい設定（インデントサイズ、改行コード、保存時の自動フォーマット、リンター/フォーマッターの設定、デバッグ構成、タスクなど）は、ワークスペース設定またはフォルダ設定に記述します。これにより、他の開発者と設定を共有し、プロジェクトの標準を維持できます。

原則として、プロジェクト固有の設定やチームで共有すべき設定はワークスペースレベルで管理し、個人の開発スタイルや好みに合わせた設定はユーザーレベルで管理するのが良いでしょう。

秘匿情報は設定ファイルに含めない

これはセキュリティ上の最も重要な注意点です。APIキー、パスワード、データベース接続文字列などの秘匿情報は、Git管理されるワークスペース設定ファイルには絶対に含めないでください。代わりに、以下の方法を検討してください。

環境変数: アプリケーションの起動スクリプトやデバッグ構成で環境変数を設定ファイルから参照するのではなく、シェルの環境変数として設定するか、.env ファイル（ただし、.env ファイル自体は.gitignoreで除外）を使用します。VS Codeのlaunch.jsonやtasks.jsonでは、${env:VAR_NAME} のように環境変数を参照できます。
VS Codeのシークレットストレージ: 一部の拡張機能はVS CodeのCredential Management API（シークレットストレージ）を利用して秘匿情報を安全に保存・管理できます。
クラウドサービスのシークレット管理: AWS Secrets Manager, Azure Key Vault, Google Secret Manager, HashiCorp Vault など、専用のシークレット管理サービスを利用し、実行時に安全に秘匿情報を取得する仕組みを導入します。

`.vscode` ディレクトリや `.code-workspace` ファイルをGitで管理する際の考慮事項

前述の注意点と重複しますが、改めて重要な点を強調します。

チームで共有すべき設定ファイル（settings.json, launch.json, tasks.json, extensions.json）はコミットする。
ユーザー固有のファイルや一時ファイルは.gitignoreで除外する。
.code-workspaceファイルは、ワークスペースの構造を定義するため、通常はコミットする。リポジトリのルートや共通の場所に配置し、相対パスでフォルダを指定するのが一般的。
Gitリポジトリに含める前に、秘匿情報が誤って含まれていないかを必ず確認する。

コメントを活用して設定意図を記述する

.code-workspace, settings.json, launch.json, tasks.json といった設定ファイルはJSON形式ですが、VS CodeではJSON with Comments (JSONC) 形式として、コメント（// や /* ... */ */）を記述することが許可されています。

なぜその設定が必要なのか、どのような意図で記述されているのか、特定のパスや引数が何を意味するのか、といった補足情報をコメントとして記述することで、設定ファイルの可読性が向上し、他の開発者が理解しやすくなります。特に複雑なデバッグ構成やタスク定義には、丁寧なコメントを付加することを強く推奨します。

小規模プロジェクトではフォルダを開く、大規模/複雑な場合はマルチルートワークスペースを使う

必ずしもすべてのプロジェクトでマルチルートワークスペースが必要なわけではありません。単一のコードベースで構成されるシンプルなプロジェクトであれば、フォルダを開くだけの単一ルートワークスペースで十分です。この場合でも、.vscodeディレクトリにプロジェクト固有のsettings.json, launch.json, tasks.json, extensions.jsonを置いてGitで管理することで、プロジェクト固有の設定共有というメリットは享受できます。

一方、複数の関連するコードベースを扱う場合、モノレポ、マイクロサービス、FE/BE分離といった構成の場合は、迷わずマルチルートワークスペースの利用を検討すべきです。これにより、開発効率、管理の容易さ、チームでの連携といった面で大きなメリットが得られます。プロジェクトの規模や複雑さ、チーム構成を考慮して、最適なワークスペースの形態を選択しましょう。

トラブルシューティング

VS Codeワークスペースを扱う上で発生しがちな問題と、その解決策について説明します。

設定が反映されない場合の確認ポイント

「ワークスペース設定を変更したのに、エディタの挙動が変わらない」といった場合、設定の適用順序や記述ミスが原因であることが多いです。

設定ファイルを確認: 編集した設定ファイル（.code-workspace, .vscode/settings.jsonなど）を開き、JSONの構文エラーがないか確認します。VS Codeのエディタがエラーや警告を表示しているはずです。
設定のスコープと優先順位を確認: 変更した設定が、どのレベル（ユーザー、ワークスペース、フォルダ）に記述されているかを確認します。そして、現在開いているファイルのパスが、その設定のスコープに含まれているか、より優先順位の高い設定で上書きされていないかを確認します。
- 例えば、特定のファイルで設定が反映されない場合、そのファイルが属するフォルダの.vscode/settings.jsonに、ワークスペース設定よりも優先される同じ設定項目がないか確認します。
- コマンドパレットから「Settings: Open Settings (UI)」または「Settings: Open Workspace Settings (JSON)」などを開き、目的の設定項目を検索してみてください。設定が定義されているスコープ（ユーザー、ワークスペース、フォルダ）と、どのファイルで定義されているかが表示されます。
VS Codeの再起動: 設定変更がすぐに反映されない場合があります。VS Codeを完全に終了して再起動すると、設定が正しく読み込まれることがあります。
拡張機能との競合: インストールされている拡張機能が、VS Codeの組み込み設定や他の拡張機能の設定と競合している可能性があります。特定の拡張機能を一時的に無効にして、問題が解決するか試してみてください。

拡張機能の問題

「推奨拡張機能がインストールされない」「拡張機能がワークスペースで正しく動作しない」といった問題が発生することがあります。

extensions.json の構文とIDを確認: .vscode/extensions.jsonまたは.code-workspaceファイルのextensionsセクションを開き、JSONの構文が正しいか、推奨拡張機能のID（publisher.extension-name）が正確かを確認します。IDは拡張機能マーケットプレイスや拡張機能ビューで確認できます。
拡張機能がインストールされているか確認: 拡張機能ビューで、該当の拡張機能がインストールされているか、有効になっているかを確認します。ワークスペースレベルで無効になっていないかも確認します。
出力チャンネルを確認: 多くの拡張機能は、問題発生時にVS Codeの「出力」パネルにログを出力します。問題のある拡張機能に関連する出力チャンネル（例: ESLint, Prettier, Python Language Serverなど）を選択し、エラーメッセージがないか確認します。
拡張機能の再インストール/アップデート: 拡張機能自体に問題がある可能性もゼロではありません。拡張機能を一度アンインストールし、再度インストールするか、最新バージョンにアップデートしてみてください。

ワークスペースファイルが見つからない/壊れている場合

.code-workspaceファイルが誤って削除された、移動された、あるいは内容が壊れてJSONとして不正になってしまった場合、そのワークスペースを開けなくなることがあります。

バックアップからの復元: もしバージョン管理システムで.code-workspaceファイルを管理しているなら、過去のコミットからファイルを復元します。
手動での再作成: ファイルの内容が分かっている場合は、新しいファイルを作成してJSONを記述し直します。JSONの構文エラーがないかVS Codeなどで確認しながら編集します。
GUIでの再作成: ファイルの内容が不明な場合でも、GUIでフォルダをワークスペースに追加し、「ワークスペースをファイルとして保存」することで、再作成できます。設定内容は失われますが、フォルダ構成だけでも復元できます。

デバッグやタスクが実行できない

launch.jsonやtasks.jsonで定義したデバッグ構成やタスクが正しく実行されない場合、以下の点を確認します。

JSONの構文と設定を確認: launch.jsonやtasks.jsonを開き、JSONの構文エラーがないか、設定内容（プログラムパス、コマンド、引数、作業ディレクトリなど）が正しいかを確認します。特に、${workspaceFolder} のような変数が正しく使用されているか、マルチルートワークスペースの場合は${workspaceFolder:<FolderName>} で正しいフォルダが指定されているかを確認します。
作業ディレクトリとコマンド: tasks.jsonのoptions.cwdやlaunch.jsonのcwdで指定された作業ディレクトリが存在するか、またそのディレクトリで指定されたcommandやprogramが実行可能かを確認します。
環境変数: タスクやデバッグの実行に必要な環境変数（env プロパティ）が正しく設定されているか確認します。.env ファイルを使用している場合は、そのパスが正しいか、ファイルが読み込まれているか確認します。
ターミナル/デバッグコンソールの出力: タスク実行時やデバッグ開始時に、VS Codeのターミナルパネルやデバッグコンソールにエラーメッセージが表示されていないか確認します。
拡張機能の依存関係: 特定のデバッガーやタスクタイプを使用する場合、関連する拡張機能がインストールされ、有効になっている必要があります。
問題マッチャー: tasks.jsonでproblemMatcherを使用している場合、その設定が正しいか確認します。問題マッチャーの設定ミスが、ビルドエラーなどが「問題」パネルに表示されない原因となることがあります。

これらのトラブルシューティングのヒントは、ワークスペースに限らずVS Code全般の問題解決にも役立ちます。問題が発生した際は、慌てずにエラーメッセージを確認し、関連する設定ファイルや出力パネルをチェックすることから始めましょう。

まとめ

この記事では、VS Codeワークスペースとは何かという基本的な概念から、なぜワークスペースを使うべきなのか、その種類と作成方法、詳細な設定方法、マルチルートワークスペースの具体的な活用例、管理・操作方法、拡張機能との連携、Gitでの管理、そしてトラブルシューティングに至るまで、VS Codeワークスペースに関する詳細な解説を行いました。

ワークスペースは単なるフォルダの集まりではなく、プロジェクト固有の設定、デバッグ構成、タスク定義、推奨拡張機能などを一つのまとまりとして管理するための強力な仕組みです。特に、複数の関連するフォルダやコードベースを扱う複雑なプロジェクト構成（モノレポ、マイクロサービス、FE/BE分割など）においては、マルチルートワークスペースを活用することで、開発効率、プロジェクト間のコンテキスト切り替え、チームでの開発環境統一といった面で計り知れないメリットが得られます。

単一ルートワークスペース (.vscode ディレクトリ) は、一つのプロジェクトフォルダに対して固有の設定を適用する基本的な方法です。
マルチルートワークスペース (.code-workspace ファイル) は、複数のフォルダをまとめて扱い、ワークスペース全体の設定とフォルダ固有の設定を組み合わせて管理できる高度な方法です。

ワークスペース設定（.code-workspace や .vscode/settings.json）を適切に構成し、launch.json、tasks.json、extensions.json といったファイルを活用することで、開発に必要なすべてのツールや設定をVS Code内に統合し、スムーズで効率的な開発ワークフローを構築できます。これらの設定ファイルをGitでバージョン管理し、チームメンバーと共有することは、チーム全体の生産性向上と開発環境の統一に不可欠です。

この記事で解説した知識と活用法を、ぜひ皆様のVS Codeでの開発に取り入れてみてください。最初は慣れない操作や設定に戸惑うことがあるかもしれませんが、一度ワークスペースの概念を理解し、その便利さを体験すれば、もうフォルダを開くだけの開発環境には戻れないと感じるはずです。

VS Codeは常に進化しており、ワークスペースに関する機能も今後さらに強化されていく可能性があります。ぜひ最新の情報に注意を払いながら、VS Codeワークスペースの力を最大限に引き出し、より快適で生産的な開発ライフを実現してください。

Happy Coding!

VS Code ワークスペースとは？ 知っておきたい基本と活用法