ネクストリードの技術スタック（Angular 編）— 標準化とアップデート戦略で選んだ理由

はじめに

前回の記事 では私たちがバックエンドに C# を採用した理由をまとめました。
そこでも触れましたが、ネクストリードではフロントエンドに Angular を採用しています。

私たちがなぜ Angular を採用したのか。
理由は、突き詰めると次の 2 点に集約されます。

• 標準化（組織としての再現性）
• アップデート戦略（ライフサイクルの予測可能性）

長期運用・チーム増・複数案件を前提とする場合、「技術の好み」よりも 運用コストの見通し が重要になります。
本記事ではなぜ私たちが数ある選択肢の中から Angular を選んだのか、その背景を整理して共有します。
「モダンな技術選定に悩んでいる」「今 Angular を選ぶ価値はあるのか？」と考えている方の参考になれば幸いです。

（補足）「Angular は下火？」と言われる理由と、実際の利用状況

Angular は「下火になった」「もう選ばれない」と言われることがあります。
ただ、エンタープライズ用途は社外に事例が出にくいことも多いです。
さらに Angular は公式ドキュメント／チュートリアルが整備されているぶん、「やってみた」「入門を解説した」といった記事が相対的に増えづらい傾向があると感じています。

その結果、認知機会が少ない状態になり、「下火」という印象につながっている可能性があると考えています。

Angular はブラウザ上で進められる公式 Tutorials も用意されています。
日本語版もあります。

例えば、利用状況をざっくり把握する指標として npm trends を見ると、@angular/core のダウンロード数は svelte より多い状況が確認できます（例：週次ダウンロードの比較）
また、Nuxt と比べても @angular/core のほうが多い傾向です。

Vue 本体を比較に入れないのは、エンタープライズでは Nuxt 等のフレームワークまで含めて採用判断することが多く、今回は「フレームワーク同士」で比較したかったためです。
もちろん、React（やその周辺エコシステム）の Next.js と比べると規模が大きく違う点は認めます。

npm trends のダウンロード数は採用数を完全に表すものではありません（CI や依存関係の影響も受けます）。
ただ、「少なくとも継続的に利用されている」ことを確認する材料としては有用だと考えています。

このように「話題に上がる頻度」と「実際の利用数」は必ずしも一致しません。
私は、Angular は「認知機会が少ないだけ」で、今でも十分に利用されているフレームワークだと考えています。

技術選定の前提（エンタープライズの現実）

前回の記事と重なる部分もありますが、Angular 選定の文脈に合わせて前提を整理します。
私たちが携わるプロジェクトは、長期運用を前提としたエンタープライズ向けサービスが中心です。
そのため、当初から大規模化（機能増・ユーザー増・チーム増）が起きることを想定して設計・運用できることが重要となります。

私たちが重視したのは次の点です。

• 開発スピードと品質の両立（属人化しない）
• 将来的なスケール（ユーザー・機能・チームの増加等）
• 強固なセキュリティ
• Azure / コンテナ環境 / CI/CD 前提の運用

そして、フロントエンドでは特に、次の点を重視しました。

• 型安全性（バグ予防）
• 設計の規律（実装のばらつきが増えにくい）
• アップデート戦略（依存関係やアップデートで破綻しにくい）
• 親和性（C# バックグラウンドのメンバーでも移行しやすい）

TypeScript を前提にする理由

フロントエンドでも TypeScript が普及した現在、価値を実感している方は多いと思います。
私たちが静的型付けを重視した理由は、安心感と長期的な保守コストの削減です。

• 型チェックにより、実行時に起きうる不具合の一部を事前に潰せる
• IDE 支援（補完・参照解析・リファクタリング）が効き、大規模化しても安全に変更可能

もちろん、実行環境は JavaScript となるため、null や外部入力、状態不整合など「型だけでは防げない」実行時エラーが残ることはあります。
それでも、生の JavaScript と比べれば事前に検知できる不具合の範囲は大きく広がります。

そして、Angular は TypeScript 前提であることに加え、大規模開発に必要な規約と仕組みがフレームワークとして最初から揃っている点が特徴です。
また、テンプレートも型情報を前提に検査でき、テンプレート起因のミスを早期に検知できるため、開発の安心感につながっています。

Angular を選んだ理由（技術的観点）

標準化（組織としての再現性）

Angular は、いわゆる「フレームワークが道を決める（規約駆動）」というタイプの設計をしています。
好みは分かれるところになりますが、長期運用・複数チーム開発が前提のエンタープライズ領域では、この性質が強く効いてきます。

例えば、ビルド・テスト・配信といった複雑な工程は Angular CLI を中心に標準化できます。
チームが増えても「プロジェクトごとに手順や構成が違う」という状況になりにくく、オンボーディングやレビューのコストを下げられます。

また、依存性注入（DI）やルーティングなど、アプリの骨格に関わる要素がフレームワークの中心にあるため、
“場当たり的にライブラリを継ぎ足していく”よりも、設計の一貫性を保ちやすいと感じています。

特に DI についてはバックエンド（ASP.NET Core）でも中核の概念であり、C# バックグラウンドのメンバーが理解しやすい点も実務上のメリットでした。

標準化の価値は「技術的に気持ちいい」よりも、
人が増えたときに崩れにくい／複数案件で運用できる という“経営的なコスト”に直結します。

そして、 Angular は基本的に class ベースのスタイルで（Component / Service など）構造を組み立てていくため、C# に慣れているメンバーにとって学習のとっかかりが作りやすいと感じています。

ネクストリードではフロントエンド・バックエンドで要員が完全に分かれているわけではないため、同じ class ベースの発想で行き来できることはコンテキストスイッチを減らし、結果としてチーム全体の生産性にも効いてきます。
これは、関数ベースが悪いという意味ではなく、組織の前提（C# バックグラウンドが多い）だと立ち上がりが速い、という話です。

（補足）「大規模向け＝小規模には過剰？」について

Angular のデメリットとして「大規模開発に向く（＝小規模では重い）」と言われることがあります。
ただ、実際に運用してみると 小規模でも十分書きやすい と感じています。

確かに、TypeScript / DI / RxJS / CLI など 前提となる技術要素が多く、採用ハードル（学習コスト）は高め です。
一方で、いったん土台に乗れば 規約で揃う分、迷いが少なく、小規模でも「構成が散らからない」「やり方がブレない」メリットが確実に効いてきます。

そして何より、大規模に向く設計だからこそ 後からスケールしたときに選び直しが起きにくい。
最初から同じ選択肢で走り続けられる、というのは長期運用では大きな価値だと考えています。

ただし、開発期間が極端に短いのに経験者がいない、といった状況では別解のほうが初速が出る場合もあります。

Angular は「組織で同じ作法に揃えやすい」こと自体が強みで、長期運用のコストに効きます。

アップデート戦略（ライフサイクルの予測可能性）

長期運用では「更新できること」そのものが重要です。
更新の見積もりが立つ＝予算化・人員計画がしやすい、という意味で経営的にも効いてきます。
Angular は安定性を重視しており、変更は予測可能な形で導入されます。
破壊的変更が必要な場合でも、非推奨（deprecation）期間を設けた上でできる限り移行を容易にする方針が明文化されています。

実際のアップデートでも、公式の Update Guide が手順をガイドしてくれる¹ほか、
ng update による更新と移行（migrations）が整備されています。

また、Angular チームが公式にメンテしている Angular Material / CDK でも ng update による移行支援が整備されており、追従コストを下げる工夫がされています。

そして、新機能については Developer Preview / Experimental といった段階的な扱いもあり、
本番投入の判断をしやすい点も安心材料です。

これらのライブラリはリリースサイクルが統一されており、ほぼ同時にリリースされています。
新しいバージョンが出て試したいけど、このライブラリが対応していないからまだ上げられない、といった事態を抑えることが可能です。

もちろん、サードバーティライブラリを利用している場合はこの限りではありません。
しかし、Angular 周辺は公式のリリースサイクルを前提に追従するエコシステムが多く、少なくとも「移行手段が見つからず詰む」状況になりにくいと感じています。

開発効率：複数案件でも“同じ作法”で回せる

Angular の強みは、単に開発が速いというより 「増員・引き継ぎ・複数案件」に耐える開発効率 だと考えています。

例えばルーティングは Angular Router が公式に提供され、Angular CLI で作成したプロジェクトにはデフォルトで組み込まれます。
そのため「ルータは何を使うか」「ルーティングの流儀をどう統一するか」といった前提が案件ごとにブレにくく、
別プロジェクトに入っても構造を読みやすいです。

フォームについても Reactive forms などの公式機能が整備²されており、業務アプリで複雑化しがちな入力を設計として統一しやすいと感じています。

もちろん React/Vue でも統一は可能ですが、組織として標準化する際に「採用する周辺ライブラリや作法の選定・統制」が必要になりやすく、そのコストをどこで払うか（各プロジェクトか、フレームワーク側か）といった違いがでます。

クラウド運用：SPA中心なら構成がシンプル

エンタープライズ用途では、SEO や OGP、初期表示最速が常に必須となるケースは相対的に多くありません。
そのため私たちは、Angular を主に SPA として利用し、運用をシンプルに保つ方針を取っています。

SPA の場合、ビルド成果物は基本的に静的ファイルとして配信できるため、CDN / 静的ホスティングを中心とした構成に乗せやすく、スケールやデプロイの設計が単純化しやすいと考えています。

もちろん SSR が必要になるケースもありますが、「常に SSR が必要」というよりは、要件に応じて選択します。

（比較）バックエンドが C# のとき、Blazor を選ばなかった理由

最近では、バックエンドが C# であれば Blazor も有力な選択肢になりえます。
特に「言語や開発体験を C# に寄せたい」「フロントとバックの境界を薄くしたい」という文脈では魅力があります。

一方で私たちの前提（長期運用・複数案件・チーム増）では、現時点では Angular を優先しました。
理由は大きく 2 つです。

• リリースサイクルの見通し
• 初期ロード（ペイロード）の懸念

Blazor は .NET のリリースサイクル（毎年 11 月に年次でメジャーリリース³）の影響を強く受けるため、フロントエンドとしてみると更新の「粒度」がやや大きくなりがちです。
また、機能の改善にも次のリリースサイクルまで待つ必要が出てきます。
一方、 Angular はメジャーリリースがおおむね 6 か月ごとであり、マイナーリリースは各メジャーに対して 1 ~3 回あります⁴。
機能の改善はこのマイナーバージョンでも行われており、比較的短いサイクルで改善されていきます。

また、Blazor WebAssembly は、クライアント側に .NET ランタイム等を含む実行環境を配布する構造のため、初期ロードが重くなりやすい点も気になっています。もちろんトリミングや圧縮、Lazy load などで緩和は可能ですが、私たちのユースケースでは「初期体験の設計」が重要論点になりやすいと判断しました。⁵

Blazor Server⁶ は初期ロードが軽い一方で、UI 更新やイベント処理が SignalR 接続を前提にサーバ側で実行されます。
また、クライアントごとにサーバ側状態（circuit）を持つため、同時接続数やネットワーク品質を踏まえたスケール設計が重要になります。

もちろん要件によっては Blazor が最適になるケースもあります。
ただ私たちのユースケースでは、最初からフロントエンドを出発点に設計されたフレームワーク（Angular）を採用する方が、ツールチェーンやエコシステムの恩恵を受けやすいと判断しています。

「.NET だから Blazor」も十分な選択肢ですが、今回は フロントエンド起点のエコシステムと更新の見通しを優先して Angular を選びました。

（補足）Capacitor によるスマホアプリ化（React Native との棲み分け）

フロントエンドのスマホアプリ化と言えば、React Native を用いた手法が多く語られます。
ただし、これが Angular でできないのかというとそうではありません。

あまり馴染みがないかもしれませんが、Web アプリを iOS/Android で動かすためのクロスプラットフォームなネイティブランタイムとして Capacitor があります。

Capacitor は既存の Web アプリをネイティブコンテナ（WebView）上で動かしつつ、プラグイン経由でカメラや位置情報などのネイティブ機能にもアクセスできます。

Angular 向けにも ng add @capacitor/angular の導線があり、既存プロジェクトへ導入しやすい点が魅力です。

React Native は React を使ってネイティブアプリを構築するためのフレームワークで、UI もネイティブコンポーネントとして描画されます。
そのため、ネイティブ UI/体験を強く求めるケースでは React Native が有利になることがあります。

一方で、すでに Web（Angular）でプロダクトを運用している場合、
Capacitor を採用することで「Web の資産をそのまま活かしつつ、配布チャネルとしてアプリストアも選べる」状態を作りやすいと考えています。
React Native のような改めてそれを理解する必要なく、Web で動いている資産をほぼそのままにスマホアプリ化できることは強みです。

もちろん、React でも Capacitor を採用した場合は Angular と同じメリットが生まれます。

Angular を選んだ理由（個人的背景）

私は angular.js（v1）から Angular を触ってきましたが、v2 のタイミングでは書き方が大きく変わり、当時は追従コストの高さにとても苦労しました。
しかし、フレームワーク一式を公式がメンテしており、ライブラリとフレームワークのリリースサイクルが揃うという点ではとても魅力です。
この点は、C# と ASP.NET Core も同様のことが言えます。

v4 がリリースされる頃までは angular.js の利用を継続していましたが、このころに意を決して移行を断行しています。（当時の 記事）

これ以降は、Angular が明文化しているとおり、サポート期間や非推奨の方針、更新の推奨パスによって予測可能なアップデート体験となり、長期運用での見通しが立てやすくなったと感じています。

また、大半の関連ライブラリのリリースサイクルが揃うという点が気に入っています。
これは .NET も同様であり、基盤が更新されたらすぐに利用できるというのはかなりのアドバンテージだと感じています。
「周辺ライブラリを調べて更新を追いかけ、新規ライブラリとの差し替えをするかどうかの判断をする」というタスクがなくなるだけでかなり楽になります。

個人的には、Angular（および公式周辺）の「更新が運用として回る」というこの部分がとても大きいなと感じています。

まとめ

私たちが Angular を選んだ決め手は、標準化（組織としての再現性） と アップデート戦略（ライフサイクルの予測可能性） でした。

• チーム増・複数案件・引き継ぎを前提にするなら、Angular の「規約で揃う」性質は強力
• 長期運用では、更新計画を立てられることが重要。Angular はサポート期間や非推奨方針を明文化し、Update Guide / ng update など移行支援も公式に整備

一方で、SEO 最優先で SSR が常に必要なプロダクトや、極端な軽量性・自由度を求めるケースでは、別解（Next/Nuxt等）が第一候補になることもあります。
技術選定は流行や好みではなく、**運用の勝ち筋（ガバナンスと更新可能性）**から逆算するのが最も再現性が高いと考えています。

1. Update Guide の提供範囲や形は将来変わる可能性があるため、公式注記も合わせてご確認ください。 ↩

2. 執筆時点で最新版である Angular v21 では Signal ベースの Signal Forms という仕組みが Developer Preview で導入されています。今後の Form 開発はこちらが主流になっていくものと思われます。 ↩

3. .NET は年次でメジャーリリース（毎年11月）: https://github.com/dotnet/core/blob/main/releases.md ↩

4. Angular のリリース方針（Versioning & Releases）: https://angular.dev/reference/releases ↩

5. Blazor WebAssembly のダウンロードサイズ最適化: https://learn.microsoft.com/aspnet/core/blazor/performance/app-download-size?view=aspnetcore-10.0 ↩

6. Blazor の hosting model（Server / WebAssembly など）: https://learn.microsoft.com/aspnet/core/blazor/hosting-models?view=aspnetcore-10.0 ↩