Blazor のレンダリングモード選定ガイド — Server / WebAssembly / Auto

.NET 8 で統合された Blazor Web App では、1 つのプロジェクトの中でコンポーネントごとに描画方式を選べるようになりました。選択肢は Static SSR（静的サーバーレンダリング）、Interactive Server（SignalR 経由でサーバー上で実行）、Interactive WebAssembly（ブラウザ上で .NET を実行）、Interactive Auto（初回は Server、WASM のダウンロード完了後は WASM）の 4 つで、この選定を誤ると初期表示・対話性・サーバー負荷のいずれかで想定外のコストを払うことになります。本記事では .NET 10 時点での各モードの特性と、ケース別の選び方を整理します。

統合された Blazor Web App とレンダリングモード

.NET 7 までの Blazor は「Blazor Server」か「Blazor WebAssembly」かをプロジェクト単位で選ぶ二者択一でした。.NET 8 以降の Blazor Web App では両者が 1 つのホスティングモデルに統合され、ページ全体は既定でサーバー上で静的にレンダリングしつつ、対話性が必要なコンポーネントだけ Server や WebAssembly を割り当てる、という混在構成が標準になりました。モードの指定は @rendermode ディレクティブで行い、アプリ全体・ページ単位・コンポーネント単位のいずれの粒度でも設定できます。

Blazor の4つのレンダリングモードの比較 — Static SSR / Server / WebAssembly / Auto の特性を理解して使い分ける。

4 つのレンダリングモードの特性

各モードは初期表示速度、対話性が効き始めるまでの遅延、オフライン可否、サーバー負荷、状態の持ち方が大きく異なります。

Static SSR — サーバーで HTML を生成して返すだけで、クライアント側に .NET ランタイムを送りません。初期表示が最速でサーバー負荷も最小ですが、ボタンクリックなどの対話性はなく、更新はフォーム送信やページ遷移で行います。公開ページや読み取り中心の画面に向きます。
Interactive Server — UI の状態と実行はサーバー上にあり、DOM の差分だけを SignalR（WebSocket）で往復させます。ダウンロード量が小さく初期対話性が早い一方、ユーザーごとに常時接続とサーバーメモリ上の状態を保持するため、同時接続数がそのままサーバー資源に効きます。ネットワーク遅延が操作のレイテンシに直結し、接続が切れると状態を失います。
Interactive WebAssembly — .NET ランタイムとアセンブリをブラウザにダウンロードし、クライアント上で実行します。初回ロードは重いものの、ダウンロード後はサーバー往復なしで動作し、レイテンシが低く、静的ホスティングやオフライン動作も可能です。サーバー側に UI 状態を持たないためスケールしやすい反面、初期表示までの体感が遅くなりがちです。
Interactive Auto — 初回アクセスでは Interactive Server として即座に対話性を提供しつつ、裏で WebAssembly のアセットをダウンロードし、次回以降は WebAssembly で動作します。Server の初期表示の速さと WebAssembly のスケーラビリティを両取りする折衷案です。ただし Server と WASM の両方で動く前提になるため、コンポーネントの依存関係やサービス設計に制約が生まれます。

プリレンダリングの扱い

Interactive Server / WebAssembly / Auto はいずれも既定でプリレンダリングが有効です。プリレンダリングとは、対話性が有効になる前に一度サーバー側で HTML を生成して返す仕組みで、初期表示が速くなり SEO にも有利になります。一方で、コンポーネントの OnInitializedAsync がプリレンダリング時とインタラクティブ化後の 2 回呼ばれる点、プリレンダリングで生成した状態が引き継がれない点には注意が必要です。状態を引き継ぐには PersistentComponentState を使います。プリレンダリングを無効化したい場合は次のように指定します。

@rendermode @(new InteractiveServerRenderMode(prerender: false))

@rendermode の指定方法

モードはコンポーネントのインスタンスに対して指定します。呼び出し側で属性として付ける方法と、コンポーネント定義の先頭で宣言する方法があります。

@* 親から子コンポーネントにモードを割り当てる *@
<Counter @rendermode="InteractiveServer" />

@* コンポーネント自身にモードを宣言する場合（Counter.razor の先頭） *@
@rendermode InteractiveWebAssembly

アプリ全体に既定モードを与えたい場合は、App.razor の <Routes> や <HeadOutlet> にモードを付与します。指定しない限りページは Static SSR で描画されるため、対話性が必要な箇所を明示的に「インタラクティブの島」として切り出す設計になります。

@* App.razor でアプリ全体を Interactive Auto にする例 *@
<Routes @rendermode="InteractiveAuto" />

ケース別の選び方

要件を「誰が使い、どれだけ対話性が要るか」で切り分けると選定しやすくなります。

公開サイト・コーポレート・オウンドメディア — 大半は Static SSR で十分です。初期表示が最速で、クローラビリティも高く、サーバー負荷が小さい。フォーム送信程度の対話は SSR のまま扱えます。
社内管理画面・業務システム — 同時接続数が読めてネットワークが安定しているなら Interactive Server が実装も運用もシンプルです。ダウンロードが軽く、サーバー側のリソースやデータベースへ直接アクセスできます。
不特定多数が使う対話的アプリ・低レイテンシ重視 — Interactive WebAssembly か Interactive Auto を選びます。サーバーに常時接続を張らないためスケールしやすく、操作レイテンシも安定します。初回ロードの重さは Auto で緩和できます。
オフライン動作や PWA が要件 — Interactive WebAssembly 一択です。サーバー往復に依存しないため、ネットワークが不安定な現場や PWA として動かす用途に適します。

SignalR 常時接続とスケールの注意点

Interactive Server（および Auto の初回セッション）は、ユーザーごとに SignalR の常時接続と「回路（circuit）」と呼ばれるサーバー側の状態を保持します。これはスケール設計上、次の点に直結します。

同時接続数が資源の上限を決める — 各回路がサーバーメモリを消費するため、想定同時接続数からメモリを見積もり、上限（MaxRetainedDisconnectedCircuits など）を調整します。
スケールアウトにはバックプレーンが要る — 複数インスタンスへ分散する場合、Azure SignalR Service などのバックプレーンで接続を捌く構成が現実的です。ロードバランサはスティッキーセッション（またはそれに代わる仕組み）が前提になります。
切断からの復帰 — モバイルやスリープで接続が切れると回路が失われ、再接続に失敗すれば状態が飛びます。重要な入力途中の状態はサーバー回路だけに依存させない設計が安全です。

これらの運用コストを避けたい、あるいはユーザー数が大きく伸びる見込みなら、WebAssembly / Auto を早めに検討する価値があります。

.NET 10 での改善

.NET 10 では Blazor のインタラクティブ体験と WebAssembly まわりが継続的に強化されています。WebAssembly のランタイム・アセット配信の最適化（プリロードや事前圧縮を含む）により初回ロードのボトルネックが軽減され、Auto モードで WASM へ切り替わるまでの体感が改善しています。加えて、Interactive Server の再接続時のユーザー体験や、コンポーネント間のナビゲーション・状態の扱いに関する細かな改善が入っており、統合モデルの実運用がより安定して行えるようになっています。導入時は、対象の .NET 10 リリースノートで WebAssembly の配信最適化と再接続まわりの変更点を確認しておくと、モード選定と合わせて初期表示の調整がしやすくなります。

まとめ

Blazor Web App の要点は「ページは Static SSR を既定とし、対話性が必要な島だけにモードを割り当てる」という考え方に集約されます。社内向けで接続数が読めるなら Interactive Server、不特定多数・低レイテンシ・オフラインが絡むなら WebAssembly、その折衷が Interactive Auto です。SignalR の常時接続がスケールの制約になる点を押さえておけば、選定の大半は要件から機械的に導けます。Web Forms からの移行でこれらのモードを検討している場合は ASP.NET Web Forms から Blazor への移行ガイドを、API を別基盤に分離する構成では ASP.NET Core × Next.js の BFF パターンも併せて参考にしてください。

このテーマの全体像は .NET モダナイゼーション完全ガイドにまとめています。

エンハンスド株式会社では、Blazor / Next.js を用いたモダンな Web 開発を支援しています。