Visual StudioでJavaScript/TypeScriptを開発しているチームが2026年4月時点で押さえるべきポイントは、単なるIDE機能の追加ではありません。TypeScriptベースの言語サービスを前提にし、TypeScriptのバージョンをプロジェクト単位で管理し、SPA開発では.esprojとASP.NET Core連携を標準ルートとして見直すことが重要です。
Microsoft Learnの「JavaScript and TypeScript in Visual Studio」は、Visual Studio 2022におけるJavaScript/TypeScript開発の基本方針を整理した公式情報です。あわせて、2026年4月24日に更新されたASP.NET Core SPA関連の公式ページでは、Visual Studioテンプレート、.esproj、Vite連携、フロントエンドとバックエンドの分離といった実務上の確認ポイントが補足されています。なお、対象ページ自体の表示上の最終更新日は2025年10月30日で、SPA関連ページは2026年4月24日更新として表示されています。この記事では、両方の公式情報をもとに、開発者、DevOpsエンジニア、プラットフォームチームが今すぐ確認すべき点を実務目線で整理します。 (Microsoft Learn)
Visual Studioの最新動向: JavaScript and TypeScript in Visual Studioで何が変わったか
今回の読みどころは、「Visual StudioでJavaScriptもTypeScriptも書ける」という紹介ではありません。実務で見るべきなのは、Visual Studioがフロントエンド開発をどの方向に整理しているかです。
特に重要なのは次の3点です。
| 確認ポイント | 公式情報上の要点 | 実務での意味 |
|---|---|---|
| JavaScript言語サービス | JavaScriptの編集体験はTypeScriptサポートと同じエンジンで提供され、レガシーJavaScript言語サービスへ戻す選択肢はなくなっています。 | JavaScriptプロジェクトでも型定義、JSDoc、jsconfig.jsonの整備が効きやすくなります。 |
| TypeScriptサポート | TypeScriptのコンパイルでは、プロジェクト単位で使用バージョンを選べます。MSBuild系ではTypeScript NuGetパッケージ、npm系ではTypeScript npmパッケージの利用が推奨されています。 | IDE、ローカル開発、CI/CDでTypeScriptのバージョン差異を減らす設計が必要です。 |
| プロジェクトテンプレート | Visual Studio 2022では.esprojを使うJavaScript Project Systemが用意され、Angular、React、Vueのスタンドアロンプロジェクト作成に対応しています。 | 新規SPAやASP.NET Core連携プロジェクトでは、古いテンプレートや独自構成を惰性で使わない判断が必要です。 |
Visual Studio 2022では、JavaScriptの編集体験がTypeScriptの言語サービスをベースにしており、静的解析によるIntelliSenseや型定義を活用した補完が前提になっています。Microsoftは、新しいサービスについて、従来より軽量で大規模プロジェクトにも対応しやすいと説明しています。 (Microsoft Learn)
JavaScript開発でも「型情報の整備」が重要になる
Visual StudioのJavaScriptサポートは、もはや単なる構文ハイライトや補完ではありません。TypeScriptベースの言語サービスによって、JavaScriptファイルでも型定義を使った補完やエラー検出の恩恵を受けられます。
そのため、JavaScriptだけで書いているプロジェクトでも、次の整備をしておくと効果が出やすくなります。
jsconfig.jsonを置き、Visual Studioが解析すべき範囲を明確にするnode_modules、dist、coverageなどを解析対象から外す- npmパッケージに対応する
@types/*が必要な場合は追加する - 関数やオブジェクトにJSDocを付け、補完や警告の精度を上げる
たとえば、大きなJavaScriptプロジェクトでVisual Studioの補完が遅い、不要なファイルまで解析される、型情報が出ないという場合は、まず設定ファイルを確認します。
{
"compilerOptions": {
"allowJs": true,
"checkJs": false
},
"exclude": [
"node_modules",
"dist",
"coverage"
]
}checkJsをtrueにするとJavaScriptファイルにも型チェックが強く効くため、既存プロジェクトでは一気に有効化しない方が安全です。まずは一部ディレクトリや新規コードから試し、警告量を見て段階的に広げるのが現実的です。
TypeScriptはVisual Studio任せではなくプロジェクトで管理する
TypeScriptを使うチームにとって最も重要なのは、Visual Studioに入っているTypeScriptではなく、プロジェクトがどのTypeScriptを使うかを明確にすることです。
Microsoft Learnでは、Visual Studio 2022がJavaScript/TypeScriptファイルに対して特別なプロジェクト設定なしでIntelliSenseを提供する一方、TypeScriptのコンパイルではプロジェクト単位でバージョンを選べると説明しています。MSBuildシナリオではTypeScript NuGetパッケージ、npm構成のプロジェクトではTypeScript npmパッケージを使う方法が示されています。また、Visual Studio 2022ではTypeScript SDKが非推奨となっており、既存プロジェクトはNuGetパッケージへ移行すべきとされています。 (Microsoft Learn)
| プロジェクトの種類 | 推奨される管理方法 | 確認すべきこと |
|---|---|---|
| ASP.NET CoreなどMSBuild中心 | TypeScript NuGetパッケージ | .csprojまたは中央パッケージ管理でバージョンを固定する |
| Node.js、React、Vue、Viteなどnpm中心 | typescript npmパッケージ | package.jsonとロックファイルでバージョンを固定する |
| 古いVisual Studioプロジェクト | TypeScript SDK依存を見直す | SDK依存が残っていないか確認し、NuGetまたはnpmへ移行する |
DevOpsエンジニアが特に注意すべきなのは、ローカルではビルドが通るのにCIで落ちるケースです。原因の一つは、Visual Studio、ローカルのnpm、CI環境で使っているTypeScriptバージョンがずれていることです。
npm中心のプロジェクトなら、次のようにプロジェクト内でTypeScriptを明示的に持たせます。
npm install --save-dev typescript
npx tsc --noEmitMSBuild中心のプロジェクトなら、TypeScriptのコンパイルをNuGetパッケージに寄せます。バージョン番号はチームで検証済みのものを指定し、複数プロジェクトでばらつかないようにします。
<ItemGroup>
<PackageReference Include="Microsoft.TypeScript.MSBuild" Version="x.y.z" PrivateAssets="all" />
</ItemGroup>ここで大切なのは、常に最新バージョンへ上げることではありません。ローカル開発、Visual Studio上の警告、CIの型チェック、リリースビルドで同じ判断ができる状態にすることです。
.esprojとJSPSは新規SPA開発の標準候補になる
Visual Studio 2022では、JavaScript/TypeScript向けの新しいプロジェクト種類として.esprojが用意されています。これはJavaScript Project System、略してJSPSと呼ばれ、Angular、React、VueのスタンドアロンプロジェクトをVisual Studio内で作成できます。作成時にはローカルにインストールされた各フレームワークのCLIツールが使われるため、テンプレートのバージョンは開発環境側のCLIに依存します。 (Microsoft Learn)
この点は、プラットフォームチームにとって重要です。Visual Studioのテンプレートを使えば常に同じReact/Vue/Angular構成になる、とは限りません。各メンバーのNode.js、npm、フレームワークCLIの状態によって初期生成物が変わる可能性があります。
そのため、社内標準テンプレートとして使う場合は、次のようなルールを決めておくと安全です。
| 管理対象 | 決めておきたいルール |
|---|---|
| Node.js | 推奨バージョンをREADMEや開発環境セットアップ手順に明記する |
| npm/pnpm/yarn | 使うパッケージマネージャーを統一する |
| フレームワークCLI | グローバルCLIに頼りすぎず、プロジェクト内スクリプトで再現できるようにする |
| TypeScript | npmまたはNuGetでプロジェクト単位に固定する |
| テスト | Visual StudioのTest Explorerで扱うか、CI上のnpm scriptを正とするか決める |
.esprojの利点は、Visual Studio内でフロントエンドプロジェクトを扱いやすくしながら、ASP.NET Core APIプロジェクトとの接続、npmモジュール管理、JavaScript/TypeScriptの単体テスト実行などを統合しやすい点です。Microsoft Learnでは、.esprojテンプレートがASP.NET SPAテンプレートよりnpm依存関係管理、ビルド、発行サポートの面で改善されていると説明されています。 (Microsoft Learn)
ASP.NET Core連携ではフロントエンドとバックエンドの分離を前提にする
2026年4月24日に更新されたASP.NET Core SPA関連のMicrosoft Learnでは、Visual StudioのSPAテンプレートが、フロントエンドに.esproj、バックエンドにASP.NET Coreプロジェクトを使う構成として説明されています。テンプレートはAngular、React、VueなどのJavaScript技術を使ったSPAとASP.NET Coreバックエンドを組み合わせ、フロントエンドプロジェクトとバックエンドプロジェクトを分けたソリューションを作成します。 (Microsoft Learn)
この構成のメリットは、役割分担が明確になることです。
- フロントエンドチームはReact、Vue、Angular、Vite、npmを中心に開発できる
- バックエンドチームはASP.NET Core API、認証、データアクセスに集中できる
- DevOpsチームはフロントエンドビルドと.NETビルドをパイプライン上で分離・統合しやすい
- プラットフォームチームはテンプレート、Node.js、TypeScript、CI設定を標準化しやすい
Visual StudioのSPAテンプレートは、Visual Studio 2022 version 17.8以降と「ASP.NET and web development」ワークロードを前提に説明されています。また、Viteなど最新のフロントエンドCLIツールとの統合、npm依存関係管理UI、Test Explorerでのフロントエンド単体テスト実行、Visual Studio Codeデバッグ設定との互換性などが利点として挙げられています。 (Microsoft Learn)
既存プロジェクトで見直すべきポイント
既存のJavaScript/TypeScriptプロジェクトでは、すぐに.esprojへ移行する必要があるとは限りません。重要なのは、いまの構成がチームの開発・ビルド・運用に合っているかを確認することです。
| 状況 | 見直し方 |
|---|---|
| 古いNode.jsプロジェクトをVisual Studioで開いている | .njsprojや独自構成のまま維持する理由があるか確認する |
| ASP.NET CoreとSPAが1プロジェクト内で強く結合している | フロントエンドとバックエンドを分離した構成にできないか検討する |
| TypeScript SDKに依存している | Visual Studio 2022ではSDKが非推奨のため、NuGetまたはnpm管理へ移行する |
| IntelliSenseや型チェックが不安定 | tsconfig.json、jsconfig.json、TypeScriptバージョン、除外ディレクトリを確認する |
| CIとローカルでビルド結果が違う | tsc、npm script、MSBuild、NuGet/npmのバージョン固定を見直す |
特に注意したいのは、SPAフレームワークのライフサイクルです。Microsoft Learnでは、SPAフレームワークは.NETよりリリースサイクルが短いため、.NETのサポート期間内であっても、テンプレートが参照するSPAフレームワークのメジャーバージョンがサポート外になる可能性があると説明されています。ASP.NET Core SPAテンプレートは、安全な状態を保つためにパッチリリースで新しいSPAフレームワーク版へ更新される場合があります。 (Microsoft Learn)
つまり、Visual Studioテンプレートで作ったから安心、ではありません。フロントエンド側のReact、Vue、Angular、Vite、TypeScript、ESLint、テストフレームワークは、.NETとは別に更新計画を持つ必要があります。
DevOpsとプラットフォームチーム向けの実務チェックリスト
Visual StudioのJavaScript/TypeScriptサポートをチームで安定運用するなら、IDE設定だけでなく、プロジェクト標準とCI/CDの整備が欠かせません。
| チェック項目 | 推奨アクション |
|---|---|
| Visual Studioのバージョン | チームでサポート対象バージョンを決め、古い環境を放置しない |
| Node.js | LTS系など、チームで利用するバージョンを明記する |
| TypeScript | npmまたはNuGetでプロジェクト単位に固定する |
tsconfig.json | include、exclude、strictの方針を決める |
| CIの型チェック | npx tsc --noEmitまたはMSBuildで再現できるようにする |
| SPAテンプレート | 新規案件では.esproj構成を候補に入れる |
| テスト | Visual StudioのTest Explorerだけに依存せず、CIで実行できるnpm scriptを用意する |
| 発行・デプロイ | フロントエンド成果物とASP.NET Coreの発行手順を明文化する |
グローバルチームで開発している場合は、特にNode.jsとTypeScriptのバージョン差が問題になりやすいです。日本拠点、海外拠点、CI環境で違う結果が出ないよう、README、.nvmrc、package-lock.json、Directory.Packages.propsなどを使って、再現性を優先しましょう。
ReactやSSRを使う場合の注意点
Visual StudioやASP.NET Coreのテンプレートは便利ですが、すべてのフロントエンド要件を満たすわけではありません。
たとえば、ReactテンプレートについてMicrosoft Learnでは、サーバーサイドレンダリング、つまりSSRはテンプレートのサポート対象ではないと説明されています。SSRが必要な場合は、テンプレート任せではなく、Next.jsなどの別構成を検討する必要があります。 (Microsoft Learn)
判断基準はシンプルです。
| 要件 | 向いている構成 |
|---|---|
| ASP.NET Core APIと通常のSPAを組み合わせたい | Visual StudioのSPAテンプレート、.esproj、React/Vue/Angular |
| SEOや初回表示速度のためSSRが必要 | Next.jsなどSSR対応フレームワークを別途検討 |
| フロントエンドだけ独立して頻繁にデプロイしたい | ASP.NET Coreとは別リポジトリまたは別パイプライン |
| 社内業務アプリでIDE統合を重視したい | Visual StudioテンプレートとASP.NET Core連携 |
「Visual Studioで作れるか」ではなく、「要件に合った構成か」で判断することが大切です。
まず何をすべきか
Visual StudioでJavaScript/TypeScriptを使っているチームは、次の順番で確認すると失敗しにくくなります。
まず、既存プロジェクトがTypeScript SDKに依存していないか確認します。依存している場合は、Visual Studio 2022の方針に合わせてNuGetまたはnpm管理へ移行する計画を立てます。
次に、TypeScriptのバージョンをプロジェクト側で固定します。npmプロジェクトならpackage.json、MSBuildプロジェクトならNuGetパッケージを確認し、CIでも同じバージョンを使うようにします。
そのうえで、新規SPAでは.esprojとASP.NET Core分離構成を検討します。React、Vue、Angularを使う場合は、Visual Studioテンプレートが便利な出発点になりますが、Node.js、フレームワークCLI、TypeScript、テスト、デプロイの標準化までセットで考えるべきです。
Visual StudioのJavaScript/TypeScript対応は、単に「書きやすいIDE」から、フロントエンドと.NETバックエンドをチーム開発で扱うための統合基盤へ整理されています。開発者は型情報と設定ファイルを整え、DevOpsはCIで再現性を担保し、プラットフォームチームは.esproj、TypeScript管理、SPAテンプレートの標準ルールを決める。これが、2026年4月時点で最も実務に効く対応です。
コメント