Blazorアプリ作成時の各設定項目

Posted at — Jul 14, 2025

概要

BlazorアプリをVisual Studio 2022（以下、VS2022）を使って開発する際、そのアプリの仕様について設定する必要があります。

この記事では、これらの項目をどのように設定すればいいか、作成したいアプリケーションとともに考えます。

入力項目

フレームワーク (Framework)

アプリが動作する基盤となる.NETのバージョンを選択します。

.NET 8.0 (長期的なサポート - LTS): Long-Term Supportの略で、長期間にわたってセキュリティパッチやバグ修正が提供される安定バージョンです。商用プロジェクトや長期間運用するシステムでは、こちらを選択するのが一般的です。
その他のバージョン (例: .NET 9.0): Standard-Term Support (STS) やプレビュー版が含まれます。最新の機能を試したい場合や、短いライフサイクルのプロジェクトに適していますが、サポート期間はLTSより短くなります。

なお、現状ではサポート期間は以下の通り設定されています。

バージョン	開始日	終了日
.NET 9	2024年11月12日	2026年5月12日
.NET 8 (LTS)	2023年11月14日	2026年11月10日

基本的に.NETのLTSは偶数バージョンに設定されており、奇数バージョンはSTSです。そのため、直近の偶数バージョンを選択することで自動的にLTSを選択できます。

認証の種類 (Authentication type)

ユーザー認証の方式を選択します。

なし (None): 認証機能を組み込みません。
個別のアカウント (Individual Accounts): ASP.NET Core Identityを使用し、ユーザー名とパスワードによる独自のユーザー管理システムをアプリ内に構築します。

この項目は、ユーザー認証を実装する必要があるとき以外は基本的に「None」を設定すればいいでしょう。

HTTPS 用の構成 (Configure for HTTPS)

チェックを入れると、開発用の自己署名証明書が設定され、HTTPSでのアクセスが有効になります。

インタラクティビティの種類 (Interactivity Type / Render Mode)

コンポーネントをどのようにインタラクティブ（対話的）にするか、その既定の方式（レンダリングモード）を定義します。この項目と次の項目が、Blazorアプリを構築するうえで重要なオプションです。なぜなら、実装したいアプリのタイプによって、選択肢が変わってくるためです。

なし (None): 既定では全てのページが静的サーバーサイドレンダリング (Static SSR) となります。サーバー上でHTMLを生成してクライアントに返すだけで、JavaScriptによる対話的な動作は行いません。高速な表示とSEOに優れています。
サーバー (Server): Blazor Server モデルを既定にします。UIの更新はサーバー上で行われ、差分がSignalRという技術を使ってリアルタイムにクライアントに送信されます。サーバーとの常時接続が必要ですが、クライアント側の負荷が低く、.NETの全機能を利用できます。
WebAssembly: Blazor WebAssembly モデルを既定にします。初回アクセス時に.NETランタイムとアプリ全体がブラウザにダウンロードされ、以降はクライアントサイド（ブラウザ内）で完結して動作します。オフライン動作やPWA（プログレッシブウェブアプリ）化が可能です。
自動 (Auto): 初回アクセス時はサーバーモードで高速に表示し、バックグラウンドでWebAssembly用のデータをダウンロードします。ダウンロード完了後の次回以降のアクセスではWebAssemblyモードで動作します。両者の「良いとこ取り」をしたモードです。

インタラクティビティの場所 (Interactivity Location)

上記の「インタラクティビティの種類」をどこに適用するかを決定します。

ページ/コンポーネントごと (Per page/component): アプリ全体で特定のインタラクティビティモードを強制せず、ページやコンポーネント単位で @rendermode ディレクティブを使って個別に指定します。非常に柔軟性が高く、ほとんどのケースでこの設定が推奨されます。
グローバル (Global): アプリケーション全体に、上で選択した「インタラクティビティの種類」を一律で適用します。

サンプルページを含める (Include sample pages)

カウンターや天気予報などのサンプルコードを含むプロジェクトを作成します。Blazorの基本的な使い方を学ぶのに役立ちます。

最上位レベルのステートメントを使用しない (Do not use top-level statements)

Program.cs ファイルを、従来の Main メソッドを持つクラシックなC#の形式で生成します。チェックを外すと、より簡潔な記法（トップレベルステートメント）になります。

.NET Aspire オーケストレーションへの参加 (.NET Aspire orchestration)

.NET Aspire という、クラウドネイティブな分散アプリケーションの構築を簡素化するための新しいスタックにプロジェクトを追加します。マイクロサービス開発などで利用します。

開発したいアプリ別のおすすめ設定

開発したいアプリケーションの要件に応じて、最適な設定は異なります。以下に代表的なシナリオごとのおすすめ設定を提案します。

シナリオ1: ダッシュボード（リアルタイム更新）

一定時間ごと、あるいはイベント発生時に画面を自動で更新し続ける必要があるダッシュボードを開発する場合の設定です。

インタラクティビティの種類: サーバー (Server)
インタラクティビティの場所: ページ/コンポーネントごと (Per page/component)

サーバーモードは、SignalRによるリアルタイム通信が特徴です。これにより、サーバー側のデータ変更を即座にUIへ反映させることができ、ダッシュボードの実装に非常に適しています。場所をページ/コンポーネントごとに設定し、ダッシュボードのコンポーネントにのみ @rendermode InteractiveServer を指定することで、アプリの他の静的なページ（例：「設定画面」や「ヘルプ」）は高速な静的SSRのままとし、リソースを効率的に利用できます。

シナリオ2: ブログや製品紹介サイト（静的コンテンツ中心）

コンテンツの大部分が静的で、高速な表示と検索エンジン最適化（SEO）を最優先したいブログのようなサイトを開発する場合の設定です。

インタラクティビティの種類: なし (None)
インタラクティビティの場所: ページ/コンポーネントごと (Per page/component)

既定をなしにすることで、全てのページが高速な静的SSRになります。これにより、ユーザーは素早くコンテンツを閲覧でき、検索エンジンのクローラーも内容を効率的にインデックスできます。インタラクティビティの場所をページ/コンポーネントごとにしておくことで、将来的に「コメント投稿フォーム」のような対話的な機能を追加したくなった場合でも、そのコンポーネントにだけ @rendermode InteractiveServer などを追加して柔軟に対応できます。

シナリオ3: オフライン対応の業務アプリ (PWA)

一度読み込めばオフラインでも動作し、PCやスマートフォンのホーム画面にインストールできるような高機能な業務アプリケーション（PWA）を開発する場合の設定です。

インタラクティビティの種類: WebAssembly または自動 (Auto)
インタラクティビティの場所: グローバル (Global)

WebAssemblyモードは、アプリ全体がブラウザ上で動作するため、オフライン機能の実現に必須です。アプリ全体がリッチな対話性を持つことが多いため、場所はグローバルで一括適用するのが効率的です。自動 (Auto) モードを選択すれば、初回起動の高速化も図れるため、ユーザー体験が向上します。

シナリオ4: 複雑な入力フォームを持つ基幹システム

イントラネットで利用するような、複雑なデータ検証やデータベースとの連携が頻繁に発生する基幹業務システムを開発する場合の設定です。

インタラクティビティの種類: サーバー (Server)
インタラクティビティの場所: グローバル (Global)

サーバーモードでは、ビジネスロジックやデータアクセスを全てサーバーサイドに集約できます。クライアントにロジックをダウンロードする必要がないため、初期表示が速く、セキュリティ面でも有利です。複雑なフォームの入力状態や検証ロジックをサーバー側で一元管理できるため、開発と保守が容易になります。このようなアプリは全体がインタラクティブであることが一般的なため、場所はグローバルで問題ないでしょう。

頑張らないために頑張る

ゆるく頑張ります