依存性注入（Dependency Injection、略称DI）はAngularフレームワークの中核を成す設計パターンであり、その理解は大規模フロントエンドアプリケーションの保守性とテスト容易性を高める上で欠かせません。

DIの本質：クラスの依存関係を外部管理

あるデータ取得コンポーネントを考えてみましょう。このコンポーネントが内部で直接HTTPクライアントを生成し、エンドポイントURLをハードコードしていると、テスト時や環境変更のたびに修正が必要になります。DIでは、コンポーネントは「私はデータ取得機能を必要とする」と宣言するだけで、実際のクライアント実装や設定は外部の注入器（Injector）が提供します。これにより、本番環境では実際のAPIと通信し、テスト環境ではモックデータを返す、といった切り替えが容易になります。

技術的には、AngularのDIはクラスが依存するオブジェクトの生成とライフサイクル管理を、クラス自身から分離し、フレームワークの注入器システムに委譲する仕組みです。クラスは「何が必要か」だけを記述し、「それがどこから来るか」「どのように生成されるか」には関与しません。

DIがもたらす3つの恩恵

1. 疎結合による保守性向上
   例えばOrderComponentがOrderServiceに依存する場合、コンポーネントはサービスの実装詳細を知る必要がありません。データソースをREST APIからGraphQLに変更する場合でも、コンポーネント側のコードは一切変更せず、サービス実装のみを差し替えれば済みます。
2. テスト容易性の飛躍的向上
   テスト環境では、実際のAPIコールを伴うOrderServiceの代わりに、固定データを返すモックオブジェクトを注入できます。これにより、外部環境に依存しない、安定した単体テストが実現します。
3. コードの再利用と共有
   グローバルなシングルトンサービス（例：認証状態管理、エラーログ記録）をDIで提供すれば、アプリケーション全体のコンポーネントが同一インスタンスを参照できます。各コンポーネントで個別にサービスを生成する必要がなくなり、一貫した振る舞いが保証されます。

DIの実践手順：提供・宣言・注入

AngularでのDIは、以下の3ステップで構成されます。

1. 注入可能なサービスの定義

//  audit.service.ts
import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root', // ルートインジェクターで提供 → アプリ全体でシングルトン
})
export class AuditService {
  record(action: string): void {
    console.log(`[Audit] ${action} at ${new Date().toISOString()}`);
  }
}

@Injectable()デコレータは、このクラスがDIコンテナによって管理されることを宣言します。providedIn: 'root'は最も一般的な指定で、アプリ起動時にルートインジェクターがサービスのインスタンスを1つ生成し、全コンポーネントで共有します。

2. コンポーネントや他サービスへの注入

//  dashboard.component.ts
import { Component, OnInit } from '@angular/core';
import { AuditService } from './audit.service';

@Component({
  selector: 'app-dashboard',
  template: `<h1>ダッシュボード</h1>`
})
export class DashboardComponent implements OnInit {
  // コンストラクタで依存関係を宣言
  constructor(private auditor: AuditService) {}

  ngOnInit(): void {
    this.auditor.record('Dashboard loaded');
  }
}

コンストラクタのパラメータにサービス型を指定するだけで、Angularの注入器が自動的に適切なインスタンスを解決して注入します。privateキーワードにより、注入されたインスタンスはクラス内のthis.auditorとして利用可能になります。

3. 提供スコープの選択

providedIn: 'root'以外にも、以下の提供方法があります。

• モジュールレベル：特定のNgModuleのproviders配列で宣言。そのモジュールと、インポートする全モジュールで共有されるシングルトンになります。
• コンポーネントレベル：コンポーネントの@Componentデコレータ内のproviders配列で宣言。そのコンポーネントと子孫コンポーネントでのみ有効な、独立したインスタンスが生成されます。フォームエディタの一時状態管理など、コンポーネントのライフサイクルに紐づいたデータ保持に適しています。

ベストプラクティス集

• 全サービスに@Injectable()を付与する
  現在依存関係がなくても、将来の拡張に備えて常に付与します。これにより、コードスタイルが統一され、依存関係追加時の修正漏れを防げます。
• 可能な限りprovidedIn: 'root'を優先
  ユーティリティ系サービス（ロガー、日付フォーマッタ、APIラッパーなど）は、アプリ全体で共有するのが妥当です。この設定により、未使用サービスのツリーシェイク（バンドルからの自動除外）も有効になります。
• スコープを意識的に設計する
  サービスの寿命とデータの共有範囲を明確にします。特定フィーチャー内でのみ必要なサービスは、フィーチャーモジュールレベルで提供します。コンポーネントごとに異なる状態を持つべきサービス（例：ウィザードの進行状態）は、コンポーネントレベルで提供します。
• DOM関連オブジェクトの直接注入を避ける
  ElementRefやRenderer2などをサービスに直接注入すると、テスト困難になり、サーバーサイドレンダリング時に問題を引き起こします。DOM操作は可能な限りコンポーネントやディレクティブに閉じ込めます。
• 抽象化にはInjectionTokenを活用
  同じインターフェースに対して複数の実装が存在する場合（例：本番用APIサービスと開発用モックサービス）、InjectionTokenを使用して抽象化します。

//  api-token.ts
import { InjectionToken } from '@angular/core';

export interface ApiService {
  fetch(path: string): Promise<any>;
}

export const API_SERVICE = new InjectionToken<ApiService>('ApiService');

//  app.module.ts
import { API_SERVICE } from './api-token';
import { RealApiService } from './real-api.service';
import { MockApiService } from './mock-api.service';

@NgModule({
  providers: [
    { provide: API_SERVICE, useClass: environment.production ? RealApiService : MockApiService }
  ]
})
export class AppModule { }

他のフレームワークとの比較

DIはAngular独自の機能ではなく、Springや.NET Coreなどのバックエンドフレームワークでも広く採用されています。フロントエンド領域では、ReactのContextとPropsが類似の目的を果たします。

この比較から、Angular DIは「自動化された中央給食システム」に例えられます。各シェフ（コンポーネント/サービス）は注文票（コンストラクタ）に必要な食材（依存関係）を記入するだけで、コンベア（注入器）が正確に届けます。ReactのProps/Contextは「手作りの家庭料理」に近く、食材（データ）を冷蔵庫（親コンポーネント）から取り出し、何人もの手（中間コンポーネント）を経て最終的に調理者（子コンポーネント）に届けます。買い物袋（Context）でまとめて運べますが、基本的には手作業です。

結論として、Angularの依存性注入は強力で体系化された設計パターンです。オブジェクトの生成と利用を分離することで、疎結合でテストしやすく、保守性の高いコードを強制的に促進します。初期の学習投資は必要ですが、堅牢なエンタープライズ向けフロントエンドアプリケーションを構築するための、確固たるアーキテクチャ基盤を提供します。