Visual StudioでASP.NET Core + Reactアプリを作る場合、2026年4月時点で押さえるべき結論はシンプルです。現在の公式チュートリアル「Create an ASP.NET Core app with React – Visual Studio (Windows)」は、ASP.NET CoreをAPIバックエンド、ReactをUIとして分離した構成を前提にし、React側はVite CLIを使う流れになっています。特に、Visual Studio 2022 version 17.11以降、Node.js/npm、vite.config.js、複数スタートアッププロジェクト、発行時のnpm run buildが重要な確認ポイントです。(Microsoft Learn)
なお、GitHub上の履歴では2026年4月24日に2件の変更が確認できますが、内容は「自動挿入されるメタデータの削除」と「ownership updates for bill」で、本文の手順そのものを大きく変える機能追加ではありません。一方、Microsoft Learnのページ本文とGitHub上のms.dateは2026年3月24日表記です。したがって、実務上は「4月24日に公式ソースの管理更新はあったが、開発者が見るべき技術的な更新ポイントは3月時点のVite対応・トラブルシューティング・発行手順にある」と理解するのが安全です。(GitHub)
Visual Studioの最新動向: Create an ASP.NET Core app with React – Visual Studio (Windows)で何が変わったか
今回の公式チュートリアルで最も重要なのは、「ASP.NET Coreプロジェクトの中にReactを単純に同居させる」理解から、「バックエンドとフロントエンドを分離し、Visual Studio上で統合して扱う」理解へ切り替えることです。
公式ページでは、ASP.NET CoreプロジェクトをAPIバックエンド、ReactプロジェクトをUIとして構築する手順が説明されています。Visual StudioにはAngularとReactをサポートするASP.NET Core SPAテンプレートが含まれており、この手順ではクライアントアプリをASP.NET Coreプロジェクトの外側にある別プロジェクトとして配置できます。(Microsoft Learn)
開発者にとっては、単なる新規作成チュートリアルではありません。チーム開発、CI/CD、Docker、Azureへの発行、Node.jsのバージョン管理まで含めて、フロントエンドとバックエンドをどう統合管理するかを見直す材料になります。
| 確認ポイント | 2026年4月時点での見方 | 実務上の影響 |
|---|---|---|
| 更新日 | GitHub履歴では2026年4月24日の管理更新、ページ本文のms.dateは2026年3月24日 | 4月24日を「大きな手順変更」と断定しない |
| テンプレート | Visual Studio 2022 version 17.11以降の更新テンプレート | 古いVisual Studioでは同じ手順にならない可能性がある |
| React側のツール | Vite CLIを使用 | CRA前提の古い知識をそのまま使わない |
| 構成 | ASP.NET Core API + React UIの分離構成 | DevOpsや基盤チームがビルド・発行設計を確認しやすい |
| 発行 | ASP.NET Core発行時にnpm run buildが実行される | CI/CDの所要時間とNode.js環境を考慮する |
今回の記事で押さえるべき最大のポイントはVite対応
公式チュートリアルでは、Visual Studio 2022 version 17.11の更新テンプレートがVite CLIを使用すると説明されています。ViteはReactのバージョンを直接固定するものではなく、package.jsonなどのプロジェクト依存関係からReactのバージョンが決まるという説明も含まれています。(Microsoft Learn)
これは、過去にCreate React App（CRA）前提でASP.NET Core + Reactを理解していた開発者ほど注意すべき点です。Viteベースになると、開発サーバー、プロキシ設定、ビルドコマンド、依存関係管理の見方が変わります。
たとえば、以前のReact SPAテンプレートの知識だけで「ClientAppフォルダーを探す」「CRAの起動方法を前提にする」と、現在のVisual Studioテンプレートでは混乱しやすくなります。最新のASP.NET Core SPAテンプレートは、フロントエンドとバックエンドのクリーンな分離、Viteなどの最新フロントエンドCLIとの統合、JavaScriptビルドツールと.NETビルドの統合を利点として説明しています。(Microsoft Learn)
対象読者別に見る実務インパクト
この更新ポイントは、単に「Visual StudioでReactアプリを作る手順が変わった」という話ではありません。開発者、DevOpsエンジニア、プラットフォームチームで見るべき観点が異なります。
| 読者 | 注目すべきポイント | 次に確認すべきこと |
|---|---|---|
| アプリ開発者 | ReactとASP.NET Coreが別プロジェクトとして扱われる | vite.config.jsとAPI呼び出し先の設定を確認する |
| DevOpsエンジニア | 発行時にnpm run buildが実行される | CI/CD環境にNode.js/npmを用意する |
| プラットフォームチーム | Visual Studio、Node.js、テンプレートのバージョン差異が影響する | 標準開発環境のバージョンを明文化する |
| テックリード | SSR向けテンプレートではない | Next.jsなどが必要な要件か事前に判断する |
| グローバルチーム | Microsoft Learnの英語版と日本語版で表現差がある | 原文とGitHub履歴を併用して確認する |
特にDevOpsでは、ASP.NET Coreだけをビルド・発行すれば完了するという前提が危険です。公式チュートリアルでは、発行プロセスでnpm run buildが呼び出されるため、通常のASP.NET Coreプロジェクトより時間がかかると説明されています。(Microsoft Learn)
Visual StudioでASP.NET Core + Reactアプリを作る基本手順
公式手順の流れは、Visual Studio上でテンプレートを選択し、ASP.NET Core APIバックエンドとReact UIを含むソリューションを作成するものです。
前提条件を確認する
まず、Visual Studio 2022 version 17.11以降と「ASP.NET and web development」ワークロードが必要です。また、npmが必要で、npmはNode.jsに含まれます。(Microsoft Learn)
実務では、次のようにチーム標準を決めておくとトラブルを減らせます。
| 項目 | 推奨する確認方法 | よくある失敗 |
|---|---|---|
| Visual Studio | Visual Studio Installerでバージョンとワークロードを確認 | テンプレートが表示されない |
| Node.js/npm | node -v、npm -vで確認 | Vite起動時にバージョン警告が出る |
| HTTPS設定 | プロジェクト作成時にHTTPS構成を有効化 | API呼び出しや証明書でつまずく |
| ブラウザー | EdgeまたはChromeをデバッグ対象にする | 未インストールのブラウザーを選んで起動できない |
React and ASP.NET Coreテンプレートを選ぶ
Visual Studioのスタート画面から「Create a new project」を選び、検索バーでReactを検索します。その後、「React and ASP.NET Core」を選択します。公式チュートリアルでは、このテンプレートはJavaScriptテンプレートとして説明されています。(Microsoft Learn)
プロジェクト名の例としてはReactWithASPが使われていますが、実務では命名規則を事前に決めておくことをおすすめします。たとえば、バックエンドがProductApi.Server、フロントエンドがProductPortal.Clientのように分かる名前にすると、CI/CDやログ設計でも扱いやすくなります。
作成後に見るべきファイル
公式チュートリアルでは、スタンドアロンReactテンプレートと比較して、ASP.NET Coreとの統合用にvite.config.jsと変更済みのApp.jsxが確認できると説明されています。(Microsoft Learn)
特にvite.config.jsは重要です。APIバックエンドへのプロキシ設定やポートの不一致があると、Reactの画面は開いているのにAPIデータが表示されない状態になります。
起動設定で重要なのは複数プロジェクトの開始順序
ASP.NET Core + React構成では、バックエンドとフロントエンドの両方を起動する必要があります。公式チュートリアルでは、ソリューションのプロパティでスタートアッププロジェクトを「Multiple projects」にし、両方のプロジェクトのActionをStartに設定することを確認するよう説明しています。(Microsoft Learn)
ここで起きやすい問題は、フロントエンドが先に起動し、まだ立ち上がっていないASP.NET Core APIにアクセスしてプロキシエラーになるケースです。
実務では、次の順序で確認すると効率的です。
| 順番 | 確認する場所 | 判断基準 |
|---|---|---|
| 1 | ソリューションのプロパティ | 複数プロジェクト起動になっている |
| 2 | 起動順序 | ASP.NET Core ServerがReact Clientより先 |
| 3 | デバッグプロファイル | 不要なブラウザー起動が無効化されている |
| 4 | コンソール出力 | ASP.NET Core APIとVite CLIの両方が起動している |
| 5 | ブラウザー | React画面にAPI由来のデータが表示される |
F5またはStartボタンで起動すると、ASP.NET Core APIプロジェクトとVite CLIの2つのコマンドプロンプトが表示されます。ReactアプリはAPI経由でデータを取得するため、画面だけでなくAPI通信まで確認することが大切です。(Microsoft Learn)
発行時はASP.NET CoreだけでなくReactビルドも見る
このチュートリアルで見落としやすいのが発行手順です。
公式チュートリアルでは、ASP.NET Coreプロジェクト側にReactクライアントプロジェクトへの参照を追加し、.csproj内のProjectReferenceに<ReferenceOutputAssembly>false</ReferenceOutputAssembly>を含める手順が示されています。さらに、Program.csにapp.UseDefaultFiles();とapp.UseStaticFiles();が存在することも確認対象です。(Microsoft Learn)
<ProjectReference Include="..\reactwithasp.client\reactwithasp.client.esproj">
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>この設定は、Reactクライアントを.NETアセンブリとして参照するのではなく、発行プロセスの一部として扱うためのものです。ここを理解せずに削除すると、ローカル開発では動くのに発行後に静的ファイルが含まれない、という問題につながります。
app.UseDefaultFiles();
app.UseStaticFiles();UseDefaultFilesとUseStaticFilesは、発行後にReact側の静的ファイルを配信するうえで重要です。APIだけを提供する構成に変更する場合でも、同一ホストでReactを配信するなら確認しておくべきポイントです。
CI/CDで注意すべきポイント
DevOpsエンジニアやプラットフォームチームが見るべきなのは、「Visual Studioから発行できるか」だけではありません。パイプライン上で同じ結果を再現できるかが重要です。
特に、発行時にnpm run buildが呼び出される点は、ビルドエージェントの設計に直結します。Node.jsが入っていないWindowsビルドエージェント、npmキャッシュが使えない環境、社内プロキシでnpmレジストリに到達できない環境では、ASP.NET Core側に問題がなくても発行に失敗します。
| CI/CD項目 | 確認内容 | 失敗しやすい例 |
|---|---|---|
| Node.js | ビルドエージェントにインストールされているか | ローカルでは成功、パイプラインで失敗 |
| npm install | 社内プロキシ・証明書・レジストリ設定 | npmパッケージ取得でタイムアウト |
| npm run build | React側のビルドが通るか | TypeScript/ESLint/環境変数で失敗 |
| .NET publish | Reactビルド成果物が含まれるか | APIだけ発行されUIが表示されない |
| キャッシュ | npmキャッシュやNuGetキャッシュ | 毎回ビルドが遅い |
| 環境変数 | API URLやモードが正しいか | 本番でlocalhostを参照する |
ローカルのVisual Studio操作だけで完結させず、早い段階でCI上のdotnet publishまで確認するのが安全です。特にグローバルチームでは、開発者のPC環境差よりも、標準化されたビルドエージェント上で再現できるかを優先してください。
トラブルシューティングで見るべき3つの症状
公式チュートリアルには、Node.jsまたはテンプレートが古い場合、プロキシエラー、ポート不一致、証明書エラー、Docker利用時のHTTPSポート確認といったトラブルシューティングが含まれています。(Microsoft Learn)
Node.jsまたはテンプレートが古い
チュートリアルでは、他の箇所で説明されていない問題が起きる場合、Node.jsを現在のバージョンに更新し、Visual Studioを更新して最新テンプレートを取得することが推奨されています。(GitHub)
ただし、実務では「全員が即最新にする」よりも、チームで検証済みのバージョンを決める方が安全です。フロントエンド依存関係は更新で挙動が変わることがあるため、Node.jsのLTS系を基準にし、package-lock.jsonをリポジトリで管理する運用が現実的です。
プロキシエラーが出る
公式チュートリアルでは、/weatherforecastへのプロキシ要求でECONNREFUSEDが出る例が示されています。この場合、フロントエンドがバックエンドより先に起動した可能性が高く、バックエンド起動後にブラウザーを更新する、またはバックエンドが先に起動するよう起動順序を確認する流れです。(Microsoft Learn)
このエラーを見たときに、すぐCORS設定を疑うのは早計です。まずは次の順番で切り分けます。
| 症状 | 先に確認すること | 次に確認すること |
|---|---|---|
ECONNREFUSED | ASP.NET Core APIが起動しているか | 起動順序 |
| データだけ表示されない | vite.config.jsのtarget | launchSettings.jsonのHTTPS URL |
| 404が返る | APIエンドポイント名 | React側のfetchパス |
| CORSエラー | 同一プロキシ経由か | API側のCORS設定 |
ポートが一致しない
公式チュートリアルでは、天気データが正しく読み込まれない場合、ASP.NET CoreプロジェクトのlaunchSettings.jsonにあるapplicationUrlと、Reactプロジェクトのvite.config.jsにあるtargetを一致させるよう説明されています。(Microsoft Learn)
たとえば、launchSettings.jsonが次のような値を持っている場合です。
"applicationUrl": "https://localhost:7183"vite.config.js側のtargetも同じHTTPSポートに合わせます。
target: 'https://localhost:7183/'ここでHTTPとHTTPS、末尾スラッシュ、ポート番号の差異があると、画面表示とAPI呼び出しのどちらかだけが失敗することがあります。
Docker利用時はHTTPSポートを必ず確認する
Dockerサポートを有効にしてプロジェクトを作成した場合、公式チュートリアルではVisual StudioのContainersウィンドウでDocker HTTPSポートを取得し、vite.config.jsのtarget変数をそのポートに合わせるよう説明されています。(Microsoft Learn)
Docker利用時にありがちな失敗は、ローカル実行時のポートとコンテナー実行時のポートを混同することです。特に、ASPNETCORE_HTTPS_PORTが見つからない場合は、launchSettings.jsonにsslPortを手動で追加する説明もあります。(Microsoft Learn)
プラットフォームチームは、テンプレートから作成したアプリをそのまま本番Docker化するのではなく、次の項目を標準化しておくとよいでしょう。
| 項目 | 標準化する理由 |
|---|---|
| コンテナー内外のポート設計 | 開発環境とCI環境で接続先がずれないようにする |
| HTTPS証明書の扱い | ローカル証明書と本番証明書を混同しない |
| 環境変数名 | Vite側とASP.NET Core側で参照値をそろえる |
| ヘルスチェック | UI表示だけでなくAPI疎通も確認する |
| ログ出力 | Reactビルド失敗とAPI起動失敗を切り分ける |
SSRや本格的なフロントエンド基盤には向かない場合がある
ASP.NET Core + Reactテンプレートは便利ですが、すべてのReactアプリに最適ではありません。
公式のASP.NET Core SPA関連ドキュメントでは、Reactテンプレートはサーバーサイドレンダリング（SSR）向けではなく、SSRが必要な場合はNext.jsなどを検討する説明があります。(Microsoft Learn)
そのため、次のような要件がある場合は、Visual Studioテンプレートをそのまま使うか慎重に判断してください。
| 要件 | テンプレート適性 | 判断 |
|---|---|---|
| 社内業務アプリ | 高い | API + React UI構成で始めやすい |
| 管理画面 | 高い | 認証・API・画面を分離しやすい |
| 小規模PoC | 高い | Visual Studioだけで初期構成を作りやすい |
| SEO重視の公開サイト | 低〜中 | SSR/SSGが必要ならNext.jsなどを検討 |
| 大規模フロントエンド組織 | 中 | フロントエンドを完全独立リポジトリにする選択肢もある |
| マイクロフロントエンド | 低〜中 | 専用の設計方針が必要 |
Visual Studioテンプレートは「ASP.NET Coreを中心にReact UIを統合する」には便利です。一方で、フロントエンド主導のプロダクトやSEO重視のWebサイトでは、Next.jsなどを別に採用し、ASP.NET CoreはAPI専用にする構成の方が適している場合があります。
古いASP.NET Core SPAテンプレートとの違い
Microsoft LearnのASP.NET Core SPAテンプレート関連ページでは、以前の.NET SDKに含まれていたSPAテンプレートはレガシ扱いとして説明されています。現在のVisual Studioテンプレートは、JavaScript/TypeScriptフロントエンドを使うASP.NET Coreアプリ向けに、フロントエンドとバックエンドの分離、最新CLIとの統合、npm依存関係管理UIなどを利点として示しています。(Microsoft Learn)
古い記事や社内ナレッジを参照している場合は、次の点を見直してください。
| 古い前提 | 現在確認すべき前提 |
|---|---|
| CRAベースで考える | Viteベースのテンプレートか確認する |
ClientApp配下だけを見る | 別プロジェクト構成か確認する |
| .NET SDKのSPAテンプレートを前提にする | Visual StudioのReact and ASP.NET Coreテンプレートを確認する |
| APIとUIを単一プロジェクト感覚で扱う | APIバックエンドとReact UIを分離して管理する |
| 発行は.NETだけと考える | npm run buildを含めて設計する |
この違いを理解せずに移行すると、プロキシ設定、ビルド、発行、Dockerで問題が起きやすくなります。
実務でおすすめの導入手順
新規プロジェクトでこのテンプレートを使う場合は、公式チュートリアルをなぞるだけで終わらせず、最初の1日で運用に必要な確認まで済ませるのがおすすめです。
| フェーズ | 実施内容 | 完了条件 |
|---|---|---|
| 環境準備 | Visual Studio、Node.js/npm、ワークロードを確認 | テンプレートが表示される |
| プロジェクト作成 | React and ASP.NET Coreを選択 | Server/Client構成を確認できる |
| ローカル起動 | F5でAPIとViteを起動 | React画面にAPIデータが表示される |
| 設定確認 | launchSettings.jsonとvite.config.jsを確認 | HTTPSポートが一致する |
| 発行確認 | フォルダー発行またはAzure発行を試す | Reactビルド成果物が含まれる |
| CI確認 | パイプラインでdotnet publishを実行 | Node/npm込みで成功する |
| チーム標準化 | バージョン、ポート、環境変数を文書化 | 新メンバーが再現できる |
小さなPoCでも、発行まで試しておくことが重要です。ローカルでF5起動できても、発行時にnpmビルドが失敗するケースは珍しくありません。
2026年4月更新ポイントを踏まえたチェックリスト
最後に、今回の公式ソース更新を踏まえて、開発チームが確認すべき項目を整理します。
| チェック項目 | 確認済み |
|---|---|
| Microsoft Learnページの本文更新日とGitHub履歴の差を理解している | □ |
| Visual Studio 2022 version 17.11以降を使っている | □ |
| 「ASP.NET and web development」ワークロードが入っている | □ |
| Node.js/npmがチーム標準バージョンでそろっている | □ |
| React側がVite CLI前提であることを理解している | □ |
vite.config.jsのAPIターゲットを確認した | □ |
launchSettings.jsonのHTTPSポートを確認した | □ |
| 複数スタートアッププロジェクトの順序を確認した | □ |
発行時にnpm run buildが実行されることを確認した | □ |
| CI/CD環境にNode.js/npmを用意した | □ |
| Docker利用時のHTTPSポートを確認した | □ |
| SSRが必要な場合にNext.jsなど別構成を検討した | □ |
Visual Studioの「Create an ASP.NET Core app with React – Visual Studio (Windows)」は、ASP.NET CoreとReactを素早く統合するための実用的な入口です。ただし、2026年4月時点で見るべき本質は、4月24日の管理更新そのものではなく、Viteベースの分離構成、起動順序、ポート設定、発行時のReactビルドを正しく理解することです。
まずは公式テンプレートで最小構成を作成し、F5起動、API疎通、フォルダー発行、CI上のdotnet publishまで一通り確認してください。そこまで通れば、開発者だけでなくDevOpsエンジニアやプラットフォームチームも、ASP.NET Core + React構成をチーム標準として扱いやすくなります。
コメント