BlazorのScopedとSingletonの違いとは？正しい使い分けを理解しよう｜ASP.NET×Blazor入門 8.2
8.2 Scoped vs Singleton の違い
Blazorアプリケーションで依存性注入（DI）を活用する際に重要なのが、「ライフタイムの違い」です。 特に Scoped と Singleton は、同じように「状態を共有する」ように見えて、 実は全く異なる挙動をします。
Singleton：アプリ全体で1つのインスタンス
AddSingleton<T>() で登録されたサービスは、アプリケーションが起動してから終了するまで、 ずっと同じインスタンスが使われ続けます。つまり、全ユーザー間で共通のインスタンスになります。
これは以下のような用途に適しています：
- 設定値など、変更されない共通データ
- ログ出力など、ステートを持たないユーティリティ
Scoped：ユーザー単位のインスタンス
一方、AddScoped<T>() で登録されたサービスは、ユーザーごとにインスタンスが分かれます。 特に Blazor Server アプリでは、ユーザーごとに独立した「回線（SignalR接続）」が張られ、それぞれにスコープが作られます。
Scopedが適しているケース：
- ログイン中のユーザーの状態管理
- セッションごとのデータの保持（例：一時的なフォーム入力）
注意：Blazor WASMではScopedは「疑似Scoped」
Blazor WebAssemblyでは、サーバーとの接続が存在しないため、Scopedは内部的にTransientと同等の動きになります。 つまり、呼び出しごとに新しいインスタンスが作られます。状態を保持したい場合は、Singletonの使用を検討する必要があります。
比較まとめ
| ライフタイム | インスタンスの範囲 | 用途の例 |
|---|---|---|
| Singleton | 全アプリで1つ | 設定情報、ログユーティリティ |
| Scoped | ユーザー単位（Blazor Server） | ユーザーの状態、セッション管理 |
| Transient | 呼び出しごと | 一時的な計算・処理 |
次のセクションでは、実際に 状態管理サービスをどう設計するか を見ていきます。 8.3「状態管理サービスの設計例」へと進んでみましょう。
下田 昌平
開発に関するインプットをアウトプットしています。検索ログ
開発・技術相談
システム開発や技術検証、要件定義の作成、アーキテクチャ設計、 テスト設計、運用設計まで、一気通貫で支援しています。 企画段階の「まず相談したい」レベルから、実装・運用まで 幅広く対応できますので、お気軽にお問い合わせください。
お問い合わせ