C#のDI（依存性注入）サービス設計入門：テストしやすく拡張性の高い構成とは

C#やASP.NET Coreで開発していると「依存性注入（Dependency Injection）」を避けて通ることはできません。しかし、DIされたサービスの設計やスコープの使い分け、テストのしやすさを意識した構成に悩んだことはありませんか？この記事では、C#におけるDIの基本から、DIされたサービスの設計ポイント、ライフサイクルの違い、テスト戦略まで、現場で役立つ実践的な知識をわかりやすく整理します。

依存性注入（DI）とは？ C#における基礎知識
サービス登録とスコープ：DIの基本操作
DIされたサービスの設計ポイント
テストしやすいDI構成のサンプル
よくある落とし穴とベストプラクティス
まとめ：DIは構造を支える土台、設計で差が出る

依存性注入（DI）とは？ C#における基礎知識

DI（Dependency Injection：依存性注入）は、オブジェクトが必要とする依存関係（他のクラスやサービス）を外部から提供する設計パターンです。特にC#やASP.NET Coreでは、アプリケーションの設計において中核をなす機能であり、保守性やテストのしやすさを高めるために欠かせません。

✅ ポイント

クラス自身が依存オブジェクトを生成するのではなく、外部（通常はDIコンテナ）から注入されることで、疎結合な設計になります。
コンストラクタ、プロパティ、またはメソッド引数を通じて依存関係を注入できます。
ASP.NET Coreでは、組み込みのDIコンテナが用意されており、特別なライブラリを使わずに標準で利用可能です。

たとえば、UserService が IEmailSender に依存している場合、以下のようにコンストラクタで依存性を受け取る設計が一般的です。

✅ ASP.NET Coreの例

public interface IEmailSender
{
    void Send(string email, string message);
}

public class EmailSender : IEmailSender
{
    public void Send(string email, string message)
    {
        // メール送信処理
    }
}

public class UserService
{
    private readonly IEmailSender _emailSender;

    public UserService(IEmailSender emailSender)
    {
        _emailSender = emailSender;
    }

    public void RegisterUser(string email)
    {
        // 登録処理
        _emailSender.Send(email, "ようこそ！");
    }
}

このように設計することで、UserService は EmailSender の具象クラスに依存せず、インターフェースに依存するため、テスト時にはモックを差し替えることも容易になります。

✅ メリット

テストの容易化（モックによる単体テストが可能）
依存関係の明確化と管理の一元化
実装の柔軟な切り替え（設定ファイルや環境に応じて）

依存性注入の理解は、今後の開発において設計品質を左右する重要な基礎知識です。まずはこの概念をしっかり押さえておきましょう。

サービス登録とスコープ：DIの基本操作

C#やASP.NET Coreで依存性注入（DI）を活用するためには、サービスをあらかじめDIコンテナに登録しておく必要があります。登録時にはスコープ（ライフタイム）を明示し、インスタンスの生成タイミングや共有方法を制御します。正しいスコープ設定は、リソース効率やアプリの動作安定性に直結します。

✅ サービス登録はどこで行う？ ASP.NET Core アプリでは、Program.cs または古い構成では Startup.cs の中でサービスを登録します。以下のように、IServiceCollection 拡張メソッドを使って登録します。

✅ ASP.NET Coreの例

builder.Services.AddSingleton<IMyService, MyService>();
builder.Services.AddScoped<IUserService, UserService>();
builder.Services.AddTransient<ILogService, LogService>();

✅ スコープ（ライフタイム）の種類と特徴

ライフタイム	説明	主な用途
Singleton	アプリケーション全体で1インスタンスを共有	設定情報やスレッドセーフなユーティリティ
Scoped	HTTPリクエストごとに1インスタンス	Webアプリケーションのサービス層に最適
Transient	注入のたびに新しいインスタンス生成	軽量で状態を持たない処理クラス向き

✅ ポイント

Singleton はメモリ消費が少なく効率的ですが、状態を持つオブジェクトやリクエスト固有の情報には不向きです。
Scoped はWebアプリでは最も一般的で、1リクエスト内でサービスが共有されます。
Transient は状態を持たない軽量クラス向けで、毎回インスタンスが生成されるため、依存関係が多い場合は注意が必要です。

✅ 注意点

Singleton から Scoped サービスに依存すると例外が発生します（不正なライフタイム依存）。
適切なスコープを選ばないと、パフォーマンス低下や意図しないバグの原因になります。

このように、DIの基本は「登録」と「スコープ設定」にあります。まずはこの操作を正しく理解し、アプリケーションの構成に適したライフタイムを選択することが、堅牢な設計への第一歩です。

DIされたサービスの設計ポイント

依存性注入を正しく使うためには、サービスそのものの設計が非常に重要です。単にインターフェースを使えば良いというわけではなく、疎結合でテストしやすく、拡張性のある設計を意識することで、より保守性の高いコードになります。ここでは、そのために押さえておきたい具体的な設計ポイントを紹介します。

✅ インターフェース分離の徹底

実装に依存せず、抽象（インターフェース）に依存することで、柔軟な切り替えとテストが可能になります。
たとえば IUserService、IProductRepository のように用途ごとに明確な役割を持たせます。

✅ SRP（単一責任原則）の遵守

1つのクラスは1つの責務に集中させるべきです。
ロジックが複雑になると、変更時に他の処理へ影響が波及するリスクが高まります。

✅ 設定の注入には IOptions パターンを使う

アプリ設定ファイル（appsettings.json）の情報をクラスとして扱いたい場合は IOptions<T> を使うと便利です。

✅ ASP.NET Coreの例：設定クラスの注入

public class EmailSettings
{
    public string SmtpServer { get; set; }
}

public class EmailSender : IEmailSender
{
    private readonly EmailSettings _settings;

    public EmailSender(IOptions<EmailSettings> options)
    {
        _settings = options.Value;
    }
}

✅ ファクトリパターンとの併用

ランタイムで実装を切り替えたいケース（例：ユーザー種別ごとに異なる処理）では、IServiceProvider を介したファクトリを使うと柔軟に対応できます。
ただし多用するとサービスロケーターパターンに陥りやすいため、使い方には注意が必要です。

✅ ポイント

サービスの設計は、テスト戦略・拡張性・保守性にすべて関わってきます。
明確な責務とインターフェース分離により、変更に強く、再利用しやすいコードを実現できます。

このような設計上の工夫をすることで、DIを活かした堅牢なシステムアーキテクチャが構築可能になります。次に進む際には、この設計原則が守られているかを見直してみるのがおすすめです。

テストしやすいDI構成のサンプル

依存性注入の大きなメリットのひとつは、「ユニットテストのしやすさ」です。サービスの依存先を外部から注入できるため、実際の処理を呼び出さずにモック（偽物）を使ってテストを行うことができます。ここでは、テストを前提としたDI構成の実例を紹介します。

✅ ASP.NET Coreの例：UserServiceとEmailSender

以下の例では、UserService が IEmailSender に依存しています。コンストラクタインジェクションを使うことで、テスト時にモックへ差し替え可能な構成になっています。

public interface IEmailSender
{
    void Send(string email, string message);
}

public class EmailSender : IEmailSender
{
    public void Send(string email, string message)
    {
        Console.WriteLine($"メール送信: {email}, 内容: {message}");
    }
}

public class UserService : IUserService
{
    private readonly IEmailSender _emailSender;

    public UserService(IEmailSender emailSender)
    {
        _emailSender = emailSender;
    }

    public void Register(string email)
    {
        // ユーザー登録処理（省略）
        _emailSender.Send(email, "ようこそ！");
    }
}

このようにしておくと、テスト時には IEmailSender の代わりにテスト専用のモック実装を注入できます。

✅ テストコード例（NSubstituteを使用）

[Fact]
public void Register_ShouldSendWelcomeEmail()
{
    var mockEmailSender = Substitute.For<IEmailSender>();
    var service = new UserService(mockEmailSender);

    service.Register("test@example.com");

    mockEmailSender.Received(1).Send("test@example.com", "ようこそ！");
}

✅ ポイント

コンストラクタインジェクションを利用することで、依存先を自由に差し替え可能にする。
モックライブラリ（NSubstitute、Moqなど）と組み合わせることで、動作検証が簡単になる。
実装ロジックとインフラ処理（メール送信など）を切り離せるため、テストの信頼性が向上。

このような設計にしておくことで、ユニットテストの品質と効率が大きく向上します。本番環境で動作確認する前に、ロジックの正当性を確実に担保できるのがDI構成の強みです。

よくある落とし穴とベストプラクティス

依存性注入は非常に強力な設計パターンですが、使い方を誤ると保守性を損ない、予期せぬバグの温床にもなります。ここでは、C#やASP.NET CoreでDIを使う際によくある落とし穴と、それを避けるためのベストプラクティスを紹介します。

✅ 落とし穴1：ServiceLocatorの乱用

IServiceProvider.GetService<T>() をサービス内部で多用するのは、DIの原則に反するアンチパターンです。
コンストラクタインジェクションではなく、動的な解決に頼ると依存関係が不透明になります。

➜ ベストプラクティス

依存関係はできるだけコンストラクタで受け取るように設計する。
どうしても動的解決が必要な場合は、専用のファクトリクラスに責任を分離する。

✅ 落とし穴2：循環依存

AがBに依存し、BがAに依存するような構成はDIコンテナで例外を引き起こします。
設計が複雑化し、テストも困難になります。

➜ ベストプラクティス

責務を明確に分け、クラス設計を見直す。
間にインターフェースやイベント、デリゲートを挟んで依存を解消する。

✅ 落とし穴3：ライフタイムの不整合

SingletonサービスからScopedサービスを参照しようとすると例外が発生します。
これは、DIコンテナがライフタイムを跨いでの解決を許容しないためです。

➜ ベストプラクティス

ライフタイム間の依存関係は「同等」または「短命 → 長命」になるように設計する。
必要であれば IServiceScopeFactory を使ってスコープを明示的に作成する。

✅ その他の推奨事項

小さく保つ： 大きなサービスより、小さく単純なサービスの集合体の方がテストしやすく再利用性も高いです。
自動登録の活用： Scrutorなどのライブラリを使って、アセンブリスキャンによる自動登録を導入すると、保守コストを削減できます。

依存性注入は使い方ひとつで、コードベース全体の安定性や拡張性に大きく影響します。よくある失敗を事前に知り、設計段階からベストプラクティスを意識しておくことが、質の高い開発のカギです。

まとめ：DIは構造を支える土台、設計で差が出る

依存性注入（DI）は、単なる技術要素ではなく、C#やASP.NET Coreアプリケーションにおける設計の品質を左右する中核的な仕組みです。DIを正しく理解し、活用することができれば、テストしやすく、拡張性の高いコードが自然と実現されます。

➜ 疎結合な設計により、変更に強く、再利用可能なコードベースを作ることができます。

➜ ライフタイムの適切な設定は、スレッド安全性やパフォーマンスにも直結します。

➜ テスト性の向上により、品質保証のしやすいプロジェクト運営が可能になります。

✅ DI活用で得られるメリット

保守・運用がしやすいコードになる
チームでの開発効率が上がる
リファクタリングがしやすくなる
開発初期から将来の拡張を見据えた設計が可能

⚠ 注意すべき点

DI自体が魔法の杖ではなく、「設計の意図」と「責務の分離」が伴わないと逆効果になりえます。
無秩序なDI、ライフタイムの乱用、循環依存などは、逆に技術的負債を生む原因になります。

💡最終的に、DIは「構造を支える見えない柱」のようなものです。しっかりと設計すれば、チーム開発でもソロ開発でも、大規模・中規模問わず、アプリケーションの土台が安定します。

これを機に、DIを「使うもの」から「活かすもの」へと昇華させていきましょう。設計の精度がそのままプロダクトの品質につながります。