これまでWebアプリ開発では、フロントエンドはJavaScript、バックエンドはC#といったように言語を分けて使うのが当たり前でした。
Blazorを使えば、その常識を覆し、C#だけでフロントとバックの両方を開発できます。
本記事では、ASP.NET CoreにおけるBlazorの位置づけや仕組み、種類を整理し、これからBlazorを学ぶ方が最初に知っておくべきポイントを解説します。
Blazorの特徴
Blazorの大きな特徴はなんといっても、フロントエンドとバックエンドを同じC#で開発できる点です。
従来はフロントエンドにJavaScript、バックエンドにC#という分業が必要でしたが、Blazorを使えば言語を統一して効率的に開発できます。
さらにその他の具体的な特徴として以下があります。
- コンポーネント指向でUIを部品化でき、再利用や保守がしやすい
- 既存の .NET ライブラリ資産をそのまま活用できる
- 必要に応じてJavaScriptと連携が可能
- Microsoftが積極的に開発・改善を続けており、.NETの今後のロードマップの中でも重要な位置づけにある
ASP.NET CoreとBlazorの位置づけ
ASP.NET Coreは、Microsoftが提供するWebアプリ開発フレームワークです。用途に応じて複数の開発モデルが用意されています。
- MVC：サーバーでHTMLを生成して返す従来型のモデル。画面遷移のたびにページ全体を再描画する従来型のWebアプリに向いている。
- Razor Pages：MVCを簡略化してページ単位に整理した軽量モデル。小規模アプリや管理画面に利用されることが多い。
- Web API：バックエンド処理やREST APIを提供するためのモデル。フロントエンドやモバイルアプリからのデータ連携に使われる。
- Blazor：SPA（シングルページアプリケーション）をC#で構築できるモデル。従来JavaScriptで作っていたリッチなUIをC#で記述できる。
ASP.NET Coreの全体像の中で、「C#でフロントエンドを作れる新しい選択肢」 がBlazorであり、近年Microsoftが特に注力している分野でもあります。
Blazorの種類と使い分け
Blazorには複数の実行モデルがあります。
.NET 8 以降はさらにバリエーションが増えて複雑になったので、ここで詳しく説明します。
Blazor Server
Blazor Serverは、サーバー側でC#コードを実行し、その結果をリアルタイムにブラウザへ反映する仕組みです。
ブラウザとサーバーはSignalRで常時接続され、ユーザーの操作はリアルタイムにサーバーでC#コードとして処理され、その結果生じたUIの変更差分だけがブラウザに返されて画面が更新されます。
Blazor WebAssembly（WASM）の仕組み
Blazor WebAssembly は、ブラウザにダウンロードされた WebAssembly 版の .NET ランタイムを利用して C#コードを実行する仕組みです。
C#コードは中間言語（IL）にコンパイルされ、そのコードをランタイムが解釈して実行します。
これにより、サーバーに常時接続する必要がなく、オフライン動作が可能になります。
一方で、初回アクセス時に.NETランタイムやアプリのDLL をまとめてダウンロードするため、読み込みに時間がかかる点が課題となります。
Blazor Web App（.NET 8以降）
Blazor Web Appは、.NET 8以降で導入された新しいBlazorの標準テンプレートです。
従来のBlazor ServerやBlazor WebAssemblyを統合し、1つのプロジェクトの中で「サーバーで実行するのか」「ブラウザで実行するのか」をページ単位で選択できるようになりました。
この柔軟な仕組みを実現するために導入されたのが「レンダーモード」です。
Blazor Web Appには次の4種類のレンダーモードが用意されており、アプリの特性に合わせて選択できます。
- 静的サーバーレンダリング (静的SSR)
サーバーでHTMLを生成して返すだけのモード。JavaScript も SignalR も使わない静的なサイトに向いています。 - 対話型Server (Interactive Server)
従来の Blazor Server に相当するモード。サーバーで .NET コードを実行し、UI 更新を SignalR 経由でブラウザに反映します。 - 対話型WebAssembly (Interactive WebAssembly)
従来の Blazor WASM に相当するモード。ブラウザに .NET ランタイムを読み込み、C# コードを直接実行します。オフライン対応も可能です。 - 対話型Auto (Interactive Auto)
初回はサーバー側でレンダリング（SSR）して素早くページを表示し、WebAssemblyのダウンロードが完了したらクライアント側実行に切り替えるモード。表示の速さとクライアント実行の両立が狙えます。
これにより、例えば「一覧ページは対話型WASMで高速に表示し、複雑なダッシュボードは対話型Serverでリアルタイム性を確保する」といった柔軟な構成が可能になりました。
Blazor Web App テンプレート作成時の「インタラクティビティ型」からレンダーモードを選択することができます。
（補足）Blazorテンプレートについて
.NET 8 以降、Visual Studio上で選択できるBlazorテンプレートが複数になって紛らわしいので整理します。
Blazor Server
Blazor Server アプリのテンプレートは.NET 7までしか対応していないので、.NET 8以降の場合はBlazor Web Appテンプレートを選び、インタラクティビティの種類で「サーバー」を指定します。
Blazor WASM
Blazor WebAssemblyの場合、選べるテンプレートは大きく2種類あります。
- Blazor WebAssembly スタンドアロン アプリ
クライアント専用のプロジェクトを生成します。サーバーを含まず、API 呼び出し前提で「純粋な SPA」として動かすシンプルな構成です。
- Blazor Web App（インタラクティビティ型＝WebAssembly）
サーバーとクライアント両方のプロジェクトを生成します。サーバー側でMinimal APIや認証を統合でき、さらにページごとに「Server」「WASM」「SSR」を切り替えることが可能です。将来性や拡張性を考えるなら、基本の選択肢となります。
どちらを選んでも「C#をWebAssembly上で動かす」という仕組みは同じですが、アプリの構成や拡張性に違いがある点は押さえておきましょう。
実行モデルの使い分け
最後に、Blazor Web Appテンプレートをベースに、どの種類を選ぶべきかの目安を整理します。
- 静的サーバーレンダリング (静的SSR)
- ブログや企業サイトなど動的処理を必要としないページに適している
- 対話型Server (Blazor Server)
- リアルタイム性が求められる 業務システムやダッシュボードに向いている
- 社内システムなど、常時接続が前提の環境にも向いている
- 対話型WebAssembly (Blazor WebAssembly)
- オフライン対応やPWAを前提にしたアプリに適している
- Web AppのWASMモード：APIや認証も含む実務的なアプリに適する
- スタンドアロンWASM：小規模アプリや、既にAPIが存在する場合に適する
- オフライン対応やPWAを前提にしたアプリに適している
- 対話型Auto
- 画面によって「速さ」と「スケーラビリティ」の両方を求めるケースに有効
Blazorの学習方法
ここまでで、Blazorには複数の実行モードがあることを見てきました。
色々あって何から始めていいかわからないかもしれませんが、まずは Blazor Web App（対話型Serverモード） でプロジェクトを作成し、簡単なCRUDアプリを作ってみることをおすすめします。
Serverモードはサーバー側で処理を行う仕組みのため、データベースアクセスがシンプルで、アプリ全体の構成も分かりやすいためです。
入門向けの具体的な手順は、以下の記事で解説しているので、ぜひ参考にしてみてください。
さらに理解を深めるには、市販の書籍を活用するのも効果的です。
以前は日本語教材が少なかったのですが、近年は良質な解説書が増えつつあります。
特におすすめの1冊はこちらです。
ポチップ
まとめ
Blazorは、ASP.NET Coreに含まれる C#でSPAを構築できるフレームワーク です。
.NET 8以降は「Blazor Web App」が新しい標準となり、静的SSR・Server・WebAssembly・Autoといったレンダーモードを用途に応じて選べるようになりました。
特に学習の最初のステップとしては、Blazor Web AppのServerモード が最もシンプルで分かりやすく、データベース連携や基本的なWebアプリの構築を体験するのに最適です。
まずは小さなプロジェクトから始めて、Blazorに触れていってみてください。