今回はBlazor WebAssembly（WASM）のスタンドアロンアプリを作成し、Blazor WASMの特徴と活用方法について学びます。
本記事では、以下について説明します。
- Blazorのホスティングモデル整理とWASMの位置づけ
- WASM活用のユースケース
- スタンドアロンWASMアプリの作成とデバッグ
- WASMアプリをWebサーバで公開する方法（ローカルでお試し）
この記事を読むことで、Blazor WASMアプリの特性を理解し適切な場面で活用できるようになります。
Blazor WASMは、サーバ不要でブラウザ上で完結するアプリを作れます。
静的ホスティングで配信できるため、インフラコストを抑えられるのも魅力です！
前回までの記事では、ServerモードのBlazorアプリを扱ってきました。今回は純粋なWASMアプリに焦点を当てます。
講義：Blazor WASMの基本
Blazor WASMアプリを作る前に、WASMの位置づけと活用方法について簡単に整理しておきます。
WASMとは？
WASM（WebAssembly）は、ブラウザ上で動作する軽量な仮想マシンの仕組みで、
C#などで書かれたコードをコンパイルしてブラウザ上で直接実行できます。
Blazorでは、この仕組みを使うことで、サーバを介さずに.NETコードをクライアント側（ブラウザ）で動かすことができます。
C#でそのままブラウザアプリを作れるのが大きな魅力で、既存の.NETスキルをそのままWeb開発に活かせます。
BlazorのホスティングモデルとWASMの位置づけ
Blazorには以下の3系統のホスティングモデルがあります。
- United系
- スタンドアロンWASM
- Blazorハイブリッド (.NET MAUI等)
①United系
.NET 8+の標準です（元々はBlazor Unitedと呼ばれていました）。
Serverモード / WASMモード / SSR(Static Server-side Rendering) など様々なモードを組み合わせて使えるようになっています。
以下の記事でUnited系（及びBlazor自体の.NETにおける位置づけ）について、詳しく解説しています。
最も柔軟性が高いですが、実装はやや複雑になります。
「Blazor Webアプリ」のプロジェクトテンプレートで作成します。
.NET7以前にあった「ホステッドWASM」はこのUnited系に統合されています。
②スタンドアロンWASM
スタンドアロンで動作するWASMアプリを作成します。静的配信が可能であり、オフライン動作を重視するときに利用します。シンプルなWASMのみのアプリです。
「Blazor WebAssembly スタンドアロン アプリ」のプロジェクトテンプレートで作成します。
こちらも.NET7以前からありましたが、United系には吸収されず別系統として存続しています。
（United系ではスタンドアロンのWASMは作れません。）
今回、演習ではこのホスティングモデルを使います！
③Blazorハイブリッド (.NET MAUI等)
WebのServer/WASMではなく、ローカルの .NETで実行を行います。WinForms/WPF/.NET MAUIなどで使うことができます。
Webじゃなくて、ネイティブアプリで動作するってこと！？
その通りです。Blazor・Web技術でネイティブアプリを作れるようになります！
詳しくは、以下の記事も参考にしてください。WinFormsにおけるBlazorハイブリッドの使い方を紹介しています。
WASM活用のユースケース
Blazor WASMは、その特性を活かして様々な場面で活用できます。代表的なユースケースを紹介します。
- (1)静的ホスティングでのWebアプリ配信
- (2)オフライン対応が必要なアプリ
- (3)クライアント側での高度な処理
(1)静的ホスティングでのWebアプリ配信
サーバサイド処理が不要で、GitHub Pages、Azure Static Web Appsなどで配信できます。サーバコストを大幅に削減でき、CDN配信により高速アクセスが可能です。
向いているアプリ例： ポートフォリオサイト、多少動きのあるドキュメントサイト、計算アプリなどのシンプルな業務ツール
(2)オフライン対応が必要なアプリ
PWA（Progressive Web App）と組み合わせることで、オフライン環境でも動作します。ローカルストレージ等でデータを保存できます。
向いているアプリ例： 現場作業用の記録アプリ、旅行ガイドアプリ、メモ・Todo管理アプリ
(3)クライアント側での高度な処理
ブラウザ上で.NETライブラリを活用した複雑な処理を実行できます。サーバ負荷を軽減し、即座にレスポンスが返ります。
向いているアプリ例： データ可視化ツール、画像編集ツール、シミュレーションアプリ
要件に応じて最適なホスティングモデルを選ぶことが重要ですね。
演習では、実際にスタンドアロンのWASMアプリを作成してみましょう！
Blazor WASMの注意点
初回ロード時の重さ
Blazor WASMアプリは、初回アクセス時に.NETランタイムとアプリケーションのDLLファイルをすべてダウンロードする必要があります。
そのため、初回ロード時間が数秒かかることがあります。(2回目以降はブラウザキャッシュにより高速になります)
対策としては、「プログレスバーやローディング画面を表示」や「遅延読み込み（必要に応じて必要なDLLを読み込む）」といった方法があります。
(2) セキュリティの考慮
Blazor WASMはクライアント側（ブラウザ）で実行されるため、すべてのコードがユーザーに見える状態になりますので、以下の点を注意しましょう。
- APIキーやシークレット情報を直接埋め込まない ようにしましょう
- 認証・認可はサーバ側で行い、クライアント側の検証だけに頼らない
- 重要なビジネスロジックはサーバ側APIに配置することを検討しましょう
「ブラウザ側のコードは見られる」ことを前提に、コードを書いていかないといけないってことだね！
演習：スタンドアロンWASMアプリの作成
実際にBlazor WASMのスタンドアロンアプリのひな型アプリ（サンプルアプリ）作成し、中身を確認します。
そして、ローカル上のWebサーバを使ってブラウザで表示してみましょう。
新規プロジェクト作成
Visual Studioで新規プロジェクトとして「Blazor Web Assembly スタンドアロン アプリ」を選び作成します。今回、以下のような設定にします。
以下のようにスタンドアロンWASMの新規プロジェクトが開きます。
以下のように、CLIでdotnetコマンドを使って作成することも可能です。
dotnet new blazorwasm -n BlazorApp1 -o BlazorApp1 -f net9.0以下の記事も参考にしてください。
プロジェクトの構造を確認
スタンドアロンWASMのプロジェクト構成をざっくりみてみましょう。
wwwroot配下のindex.htmlがエントリーポイントになります。wwwrootフォルダがWebサーバで公開されるというイメージです。index.htmlを少し見てみましょう。
<!DOCTYPE html>
<html lang="en">
<head>
...
</head>
<body>
<div id="app">
...
</div>
<div id="blazor-error-ui">
...
</div>
<script src="_framework/blazor.webassembly.js"></script>
</body>
</html>
「<script src=”_framework/blazor.webassembly.js”></script>」の部分がBlazor WASMコードの呼び出し部分ですね。
アプリの動作イメージは以下になります。
- ブラウザがindex.htmlを読み込み
- blazor.webassembly.jsが起動
- Program.csを実行（WebAssemblyHostを構築、実行）
- App.razorが#appにマウント
- App.razorがルーティング開始
- URLに基づいてページを特定し表示（繰り返し）
デバッグ実行
デバッグ実行をしてみましょう。
Counter、Weatherページで動作を確認できます。これらはすべてブラウザ上で動作しています。
Serverモードでも同じようなサンプルがあって、あれはサーバ側で動作していたね。WASMアプリはブラウザ側で動作しているんだね。
そうですね。Serverモード/WASMモードではコードの書き方や見た目は同じですが、処理を行う場所（サーバ側/ブラウザ側）が異なるのですね。
ブラウザで動いていることを実感するため、以下のようにCounter.razorへコンソール出力を追記してみましょう。
@page "/counter"
<PageTitle>Counter</PageTitle>
<h1>Counter</h1>
<p role="status">Current count: @currentCount</p>
<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>
@code {
private int currentCount = 0;
private void IncrementCount()
{
currentCount++;
//★ここでコンソール出力を追加
Console.WriteLine($"Current count is now {currentCount}");
}
}
これでデバッグ実行してみましょう。ブラウザの開発者モードを使うと、ブラウザのコンソールへ出力されていることがわかります。
これがServerモードですと、Console.WriteLine(…)は、OS（例えばWindows）のコンソール画面へ出力されますね。
WASMアプリをデプロイ
次にこのサンプルアプリをデプロイしてみましょう。
今回はローカル環境へデプロイし、それをローカル上で簡易なWebサーバを使って確認してみます。
まずは、アプリを発行します。
発行先としてフォルダを選択します。
出力先フォルダを指定します。
実行プロファイルが作成されるので、「閉じる」を押します。
そのまま、以下の画面で「発行」を押しましょう。
発行の処理が開始されます。出力ログで最後に「Web Appは正常に公開されました」となればOKです。
この公開の処理についても、プロジェクトファイル（*csproj）があるフォルダで以下のコマンドを実行して行うことも可能です。
dotnet publish出力先のpublishフォルダは以下のような構成になっています。「wwwroot」をルートフォルダとしてWebサーバで公開をします。
.
└── publish
├── BlazorApp1.staticwebassets.endpoints.json
├── web.config
└── wwwroot
├── BlazorApp1.styles.css
├── BlazorApp1.styles.css.br
├── BlazorApp1.styles.css.gz
├── css
├── favicon.png
├── icon-192.png
├── index.html
├── index.html.br
├── index.html.gz
├── lib
└── sample-dataWebサーバで公開
簡易に使えるWebサーバはいろいろとありますが、今回はdotnetコマンドでインストールできる「dotnet-serve」を使ってみます。まずはインストールしましょう。
dotnet tool install --global dotnet-servewwwrootフォルダへ移動し、以下のコマンドでWebサーバを起動します。（ポートは8080を指定しています）
dotnet-serve -p 8080以下のようにWebサーバが起動します。
❯ dotnet-serve -p 8080
Starting server, serving .
Listening on:
http://localhost:8080「http://localhost:8080」へアクセスしてみましょう。
Blazor WASMアプリが表示されたよ！
とても簡単なものですが、Blazor WASMのHello Worldができましたね！
これを応用すると、静的ホスティング（GitHub Pages、Azure Static Web App等）で比較的に簡単にインターネット公開も可能ですよ！
まとめ
本記事では、Blazor WASMのスタンドアロンアプリの作成と、その特性について学びました。
Blazor WASMには以下の特徴と利点があります。
- 静的ホスティング対応： サーバサイド処理が不要なため、GitHub PagesやAzure Static Web Appsなどで配信でき、インフラコストを大幅に削減できる
- オフライン動作： PWAと組み合わせることで、ネットワーク接続がない環境でもアプリが動作し続ける
- クライアント側での高度な処理： ブラウザ上で.NETライブラリを活用した複雑な処理を実行でき、サーバ負荷を軽減できる
スタンドアロンWASMアプリは、「Blazor WebAssembly スタンドアロン アプリ」のテンプレートから作成でき、wwwroot配下のindex.htmlがエントリーポイントです
演習を通じて、実際にWASMアプリを作成し、ローカルでのデバッグやデプロイ、Webサーバでの公開方法を体験しました。
ブラウザのコンソールへの出力確認により、コードがブラウザ側で実行されていることを実感できたと思います。
Blazor WASMは用途に応じて強力な選択肢になります！
引き続き、一緒にBlazorアプリ開発を学んでいきましょう。
