Visual Studioで「Create an ASP.NET Core app with Angular – Visual Studio (Windows)」を確認している開発者がまず押さえるべき点は、2026年4月24日の公式GitHub履歴上の更新を「アプリ作成手順が大きく変わった」と受け取らないことです。GitHub履歴には2026年4月24日のコミットが2件ありますが、Microsoft Learn本文の表示上の最終更新日は2026年3月24日です。実務では、4月24日の履歴そのものよりも、本文に示されている Visual Studio 2022 17.8以降のテンプレート、Angular 20.x.x利用時の注意、発行時の npm run build、プロキシとDockerのポート確認を重点的に見直すのが安全です。(GitHub)
このチュートリアルは、ASP.NET CoreをAPIバックエンド、AngularをUIとして構成するVisual Studio向けの手順です。個人開発の入門だけでなく、DevOpsエンジニアやプラットフォームチームが「Visual Studioテンプレートを社内標準に使えるか」「CI/CDやコンテナ運用でどこを確認すべきか」を判断する材料としても役立ちます。(Microsoft Learn)
2026年4月更新ポイントの結論
2026年4月24日のGitHub履歴には、「docfxが自動挿入するメタデータの削除」と「所有者情報の更新」に関するコミットが記録されています。一方で、Microsoft Learnの本文側では、ページ末尾のLast updatedが2026年3月24日と表示されています。そのため、4月24日の更新は少なくとも本文手順の大幅変更として読むより、ドキュメント管理上の更新として捉えるのが現実的です。(GitHub)
ただし、本文に含まれる実務上の注意点は重要です。特に、Angular 20.x.xとVisual Studio 2022の「Angular and ASP.NET Core」テンプレートには互換性の問題があると明記されており、Angular 20.x.xを使う場合は、ASP.NET Coreプロジェクトを先に作り、Angularプロジェクトをソリューションへ追加し、ASP.NET Core側からAngularプロジェクトへの参照を追加する方法が推奨されています。(GitHub)
| 確認ポイント | 実務上の意味 | 取るべき対応 |
|---|---|---|
| 2026年4月24日のGitHub履歴 | 本文手順の大幅改訂ではなく、メタデータ・所有者関連の更新として扱うのが妥当 | アプリの設計変更を急がず、本文の要件と既存プロジェクト設定を確認する |
| Learn本文のLast updated | 表示上は2026年3月24日 | 記事や社内資料では「GitHub履歴」と「Learn表示日」を混同しない |
| Visual Studio 2022 17.8以降 | チュートリアルは更新されたテンプレートを前提にしている | 開発端末とビルド環境のVisual Studioバージョンを確認する |
| Angular 20.x.x | 組み合わせテンプレートとの互換性問題が明記されている | Angular 20系では、ASP.NET CoreとAngularを別々に作成して参照を追加する |
| 発行処理 | 発行時に npm run build が呼び出される | CI/CDのビルド時間、Node.js、npm、キャッシュ設定を確認する |
| プロキシ・Docker | APIとAngularのポート不一致で動作しないことがある | launchSettings.json、proxy.conf.js、コンテナのHTTPSポートを照合する |
このチュートリアルが扱う構成
Microsoft Learnの当該記事は、ASP.NET CoreプロジェクトをAPIバックエンド、AngularプロジェクトをUIとして構築する手順を説明しています。Visual StudioにはAngularやReactを扱うASP.NET Core SPAテンプレートが含まれており、記事ではクライアントアプリをASP.NET Coreプロジェクトの外側にある別プロジェクトとして配置する構成が説明されています。(Microsoft Learn)
この構成は、単に「Visual StudioでAngularを動かす」だけではありません。バックエンドとフロントエンドを同じソリューション内で扱いつつ、プロジェクトとしては分けるため、次のような現場に向いています。
- APIチームとフロントエンドチームの責任範囲を分けたい
- Visual Studioで.NET側のデバッグや発行をまとめて扱いたい
- Angular CLIベースのフロントエンド開発を維持したい
- 将来的にCI/CDやコンテナ運用へ広げたい
注意したいのは、AngularのバージョンがVisual Studioだけで決まるわけではない点です。記事では、フロントエンドプロジェクトはローカル環境にインストールされたフレームワークCLIを使って作成されるため、使用されるAngularバージョンはインストール済みのAngular CLIに左右されると説明されています。(Microsoft Learn)
Visual Studio 2022 17.8以降が前提になる
このチュートリアルは、Visual Studio 2022 version 17.8で更新されたテンプレートを使うプロジェクト作成プロセスとして説明されています。前提条件として、Visual Studio 2022 version 17.8以降、ASP.NET and web developmentワークロード、Node.jsに含まれるnpm、Angular CLIが挙げられています。(Microsoft Learn)
社内でこのテンプレートを標準化する場合、開発者のPCだけでなく、次の環境も確認してください。
| 対象 | 確認すべきこと | 見落とした場合の症状 |
|---|---|---|
| 開発PC | Visual Studio 2022のバージョン、ASP.NET and web developmentワークロード | テンプレートが表示されない、手順どおりの構成にならない |
| Node.js/npm | Node.jsの導入状況、npmコマンドの実行可否 | Angularプロジェクト作成やビルドで失敗する |
| Angular CLI | グローバルまたはプロジェクトで使うCLIのバージョン | 想定外のAngularバージョンでプロジェクトが作成される |
| CI/CDエージェント | Node.js、npm、.NET SDK、Visual Studio Build Toolsなど | ローカルでは成功するがビルドパイプラインで失敗する |
| コンテナ環境 | HTTPSポート、証明書、プロキシ設定 | API呼び出しが通らない、ブラウザーにデータが表示されない |
特にプラットフォームチームは、Visual Studioのテンプレートだけを配布するのではなく、Node.jsとAngular CLIのバージョン管理方針まで含めて標準化する必要があります。Angular CLIのバージョンが各開発者でばらつくと、生成されるフロントエンドの構成や依存関係が変わり、レビューやCIで差分が増えやすくなります。
Angular 20.x.xを使う場合は組み合わせテンプレートを避ける判断も必要
今回のチュートリアルで最も実務影響が大きいのは、Angular 20.x.xと「Angular and ASP.NET Core」テンプレートの互換性に関する注意です。Microsoft Learn本文では、Visual Studio 2022でAngular 20.x.xを使う場合、組み合わせテンプレートではなく、ASP.NET Coreプロジェクトを先に作成し、Angularプロジェクトをソリューションに追加し、ASP.NET CoreプロジェクトからAngularプロジェクトへの参照を追加する方法が推奨されています。(GitHub)
判断基準はシンプルです。
| Angularの利用方針 | 推奨される作り方 | 理由 |
|---|---|---|
| Angular 20.x.xを使う | ASP.NET CoreプロジェクトとAngularプロジェクトを別々に作り、参照を追加する | 公式本文で互換性問題と回避策が明記されている |
| Angular 20.x.xにこだわらない | チュートリアルの組み合わせテンプレートを検証してから採用する | 学習用途や小規模検証では手順が分かりやすい |
| 長期運用する業務アプリ | フロントエンドとバックエンドを分離し、CI/CDで個別に管理できる形を優先する | AngularやNode.jsの更新に追随しやすい |
| 既存.NET APIにAngularを追加する | 既存APIを維持し、Angular側を別プロジェクトとして追加する | API設計とUI開発を分離しやすい |
「Visual Studioにテンプレートがあるから、そのまま採用する」と決めるのは危険です。Angularは更新サイクルが速く、Node.jsや依存パッケージの影響も受けます。業務アプリでは、初期作成の簡単さよりも、バージョンアップ、ビルド再現性、テスト、リリース作業の見通しを優先した方が失敗しにくくなります。
作成後に確認すべきファイル
チュートリアルでは、スタンドアロンのAngularテンプレートと比べて、ASP.NET Coreとの統合のために追加・変更されるファイルとして、aspnetcore-https.js、proxy.conf.js、変更済みのpackage.json、変更済みのangular.json、app.components.ts、app.module.tsが挙げられています。(Microsoft Learn)
この一覧は、トラブルシューティング時の入口として使えます。たとえば、Angular画面からAPIに接続できない場合、最初に見るべきなのはコンポーネントではなく、proxy.conf.jsとASP.NET Core側の起動URLです。ビルドや発行で失敗する場合は、package.jsonのスクリプト、依存関係、Visual Studio側の発行処理を確認します。
| ファイル | 主な役割 | 確認する場面 |
|---|---|---|
proxy.conf.js | Angular開発サーバーからASP.NET Core APIへリクエストを中継する設定 | /weatherforecastなどのAPI呼び出しが失敗する |
package.json | npmスクリプトとフロントエンド依存関係を管理する | npm install、npm run build、発行時に失敗する |
angular.json | Angularプロジェクトのビルド設定を管理する | 出力先、ビルド構成、アセット設定を確認したい |
aspnetcore-https.js | ASP.NET CoreとのHTTPS連携に関わる補助スクリプト | HTTPS証明書やローカル開発環境で問題が出る |
app.components.ts / app.module.ts | サンプルUIやモジュール構成 | サンプルから実アプリへ置き換える |
サンプルの天気予報データが表示されることを確認したら、次にやるべきことは「サンプルを増やす」ことではありません。実務では、APIのURL、認証方式、CORSまたはプロキシ方針、ビルド成果物の配置先を早めに決めることが重要です。
デバッグ設定では複数プロジェクト起動を確認する
チュートリアルでは、ASP.NET Core側のプロパティでブラウザー起動をオフにし、ソリューションのスタートアッププロジェクトを複数プロジェクトに設定し、両方のアクションをStartにする手順が示されています。F5で起動すると、ASP.NET Core APIとAngular CLIのng startがそれぞれ動作します。(Microsoft Learn)
ここで失敗しやすいのは、バックエンドとフロントエンドの起動順です。Angular側が先に立ち上がり、API側がまだ準備できていないと、プロキシエラーが出ることがあります。開発者が毎回ブラウザー更新で回避している場合は、スタートアッププロジェクトの順序を確認してください。
実務でのチェック手順は次のとおりです。
| 手順 | 確認内容 |
|---|---|
| ソリューションのプロパティを開く | Startup project settingsがMultiple projectsになっているか確認する |
| ASP.NET Coreプロジェクトを確認する | ActionがStartになっているか確認する |
| Angularプロジェクトを確認する | ActionがStartになっているか確認する |
| 起動順を確認する | ASP.NET Coreプロジェクトが先に起動するように並べる |
| F5で実行する | APIプロセスとAngular CLIの両方が起動するか確認する |
この設定は小さな違いに見えますが、チーム開発では重要です。新しく参加した開発者が初日に起動できない場合、多くはコードの問題ではなく、ローカル環境、起動順、ポート設定の不一致が原因です。
発行時はnpm buildが走ることを前提にする
Visual Studio 2022 version 17.3以降では、統合ソリューションをVisual StudioのPublishツールで発行できます。本文では、ASP.NET CoreプロジェクトからAngularクライアントプロジェクトへの参照を追加し、.csproj内のProjectReferenceにReferenceOutputAssemblyをfalseとして含める手順が示されています。(Microsoft Learn)
重要なのは、発行時にnpm run buildが呼び出される点です。Microsoft Learn本文では、ASP.NET Coreだけのプロジェクトより発行に時間がかかる理由として、発行時にnpm run buildが実行されること、既定のBuildCommandがnpm run buildを実行することが説明されています。(Microsoft Learn)
DevOpsエンジニアは、次の点をパイプライン設計に含めてください。
| 項目 | 推奨チェック |
|---|---|
| Node.jsのバージョン | 開発PCとCI/CDで差が出ないように固定する |
| npm依存関係 | package-lock.jsonなどを使い、再現性を確保する |
| ビルド時間 | フロントエンドビルド分の時間を見込む |
| キャッシュ | npmキャッシュやビルドキャッシュを使えるか検討する |
| 成果物 | Angularのビルド結果がASP.NET Coreの発行フォルダーに期待どおり含まれるか確認する |
| 環境変数 | API URLや本番向け設定をビルド時・実行時のどちらで注入するか決める |
発行が成功しても、アプリとして正しく動くとは限りません。特に本番環境では、開発時のproxy.conf.jsに頼らず、実際のAPIエンドポイント、リバースプロキシ、認証、HTTPS終端の構成を確認する必要があります。
よくある失敗はプロキシ、ポート、Dockerに集中する
Microsoft Learn本文のトラブルシューティングでは、Node.jsやテンプレートが古い場合の更新、プロキシエラー、ポート確認、Docker利用時のHTTPSポート確認が説明されています。プロキシエラーについては、フロントエンドがバックエンドより先に起動した可能性が高いとされ、バックエンド起動後にAngularアプリを更新すること、バックエンドが先に起動するよう設定を確認することが示されています。(Microsoft Learn)
また、天気データが正しく読み込まれない場合は、ASP.NET Core側のlaunchSettings.jsonにあるapplicationUrlのHTTPSポートと、Angular側のproxy.conf.jsのtargetを一致させる必要があります。Dockerサポートを有効にしている場合は、Visual StudioのContainers windowでDockerのHTTPSポートを確認し、proxy.conf.jsのtargetを合わせる手順が示されています。(Microsoft Learn)
| 症状 | ありがちな原因 | 確認箇所 |
|---|---|---|
/weatherforecastが取得できない | Angularが先に起動し、APIがまだ待ち受けていない | スタートアッププロジェクトの順序、バックエンドの起動状態 |
| ブラウザーにデータが表示されない | APIのHTTPSポートとプロキシ設定が不一致 | launchSettings.json、proxy.conf.js |
| Docker利用時だけ失敗する | コンテナのHTTPSポートとAngular側のターゲットが不一致 | Containers window、proxy.conf.js |
| 発行時に時間がかかる | npm run buildが実行されている | Publishログ、package.json、BuildCommand |
| 別の開発者だけ起動できない | Node.js、npm、Angular CLI、Visual Studioの差異 | バージョン一覧、ワークロード、CLI設定 |
トラブル対応では、エラーメッセージだけを見てAngular側のコードを直そうとしないことが大切です。ASP.NET Core + Angularの統合テンプレートでは、問題の原因が「UIコード」ではなく「起動順」「ポート」「プロキシ」「発行設定」にあることがよくあります。
開発者、DevOps、プラットフォームチーム別の確認ポイント
このチュートリアルを現場で活用する場合、読むべきポイントは役割ごとに変わります。開発者は作成手順とデバッグ、DevOpsエンジニアは発行とビルド、プラットフォームチームはテンプレート採用可否と標準化を重視してください。
| 役割 | 重点的に見るポイント | 次のアクション |
|---|---|---|
| 開発者 | Angular 20.x.xの注意、複数プロジェクト起動、プロキシ設定 | ローカルでAPI呼び出しまで動く最小構成を作る |
| DevOpsエンジニア | npm run build、発行フロー、CI/CDのNode.js管理 | ビルド時間と依存関係の再現性を検証する |
| プラットフォームチーム | Visual Studio 2022 17.8以降、Angular CLI、テンプレート標準化 | 社内の推奨バージョンと作成手順を文書化する |
| アーキテクト | フロントエンド分離、API境界、将来のAngular更新 | 組み合わせテンプレートを使う範囲を決める |
特にグローバルチームでは、Visual Studioの表示言語やOS環境よりも、バージョンと手順の統一が重要です。日本語環境のスクリーンショットに依存した手順書より、Visual Studioのメニュー名、プロジェクト名、確認すべき設定ファイルを明記したチェックリストの方が、海外拠点やリモートチームでも再利用しやすくなります。
社内標準として採用する前のチェックリスト
Visual Studioのテンプレートは便利ですが、業務アプリの標準構成にする前に、次の項目を確認しておくと手戻りを減らせます。
| チェック項目 | 判断基準 |
|---|---|
| Angular 20.x.xを使う予定があるか | 使う場合は組み合わせテンプレートではなく、別プロジェクト作成方式を優先する |
| APIとUIを同じリポジトリで管理するか | 同一ソリューションの利便性と、フロントエンド独立運用のしやすさを比較する |
| CI/CDでVisual Studio Publishを使うか | npmビルド、成果物、環境変数、キャッシュの扱いを事前に決める |
| Dockerを使うか | HTTPSポートとプロキシ設定の確認手順を標準化する |
| 開発者ごとにAngular CLIが異ならないか | CLIバージョンを固定するか、プロジェクトローカルで管理する |
| 本番環境でプロキシをどう扱うか | 開発用proxy.conf.jsと本番のリバースプロキシ設定を混同しない |
小規模な検証であれば、チュートリアルどおりに作成して動作を確認するだけでも十分です。しかし、チーム開発や本番運用を前提にするなら、テンプレートは「完成形」ではなく「初期構成」として扱うべきです。認証、API設計、ログ、エラーハンドリング、環境別設定、テスト、パッケージ更新方針を追加して初めて、業務アプリの土台になります。
まとめ：4月更新は履歴を確認しつつ、実務ではAngular 20と発行設定を優先して見直す
「Create an ASP.NET Core app with Angular – Visual Studio (Windows)」の2026年4月更新ポイントを見るときは、GitHub履歴上の2026年4月24日更新と、Microsoft Learn本文のLast updated表示を分けて理解することが重要です。4月24日の履歴はドキュメント管理上の更新として読み、実装や運用に直結する確認事項は本文にあるテンプレート要件、Angular 20.x.xの互換性注意、発行時のnpm run build、プロキシとDockerのポート設定に置くべきです。(GitHub)
次に取るべき行動は、現在のプロジェクトや社内標準がどちらに該当するかを確認することです。Angular 20.x.xを使うなら、ASP.NET CoreとAngularを別々に作成して参照を追加する方式を検討してください。既存のテンプレート構成を使い続ける場合は、Visual Studio、Node.js、Angular CLI、proxy.conf.js、launchSettings.json、Publish設定をチェックリスト化し、開発PCとCI/CD環境で同じ結果になるかを検証しましょう。
コメント