パフォーマンス計測＆改善

ARCHITECTURE.en.md

@@ -2222,6 +2222,18 @@ Unity6Portfolio/
 | **Impact** | High-frequency events (collisions, etc.) have been changed to direct calls |
 | **Status** | Adopted and improvement completed |
 
+#### ADR-005: Deferring ECS (DOTS) Production Deployment
+
+| Item | Details |
+|------|---------|
+| **Decision** | The ECS (Entities + Burst Job) foundation for enemy AI / movement / steering is implemented but its production deployment is deferred to a future scaling milestone. The shipped game runs on the MonoBehaviour-based MVP implementation |
+| **Context** | ECS + Burst Job parallelization was prototyped as preparation for a future enemy-count scaling target (N=2000+). Meanwhile, current production stages run at tens to low-hundreds of enemies, and the existing C# + MonoBehaviour implementation stays within stable alloc / CPU budgets |
+| **Alternatives** | A) Full ECS migration (Entity-ize all enemies, retire MonoBehaviour) B) Keep MVP and apply thorough optimization patterns (Object Pool / NonAlloc physics / struct value types / hash caches, etc.) C) Hybrid: ship MVP in production while keeping ECS systems in place, bridged through `HybridSyncSystem` for a future switch-over |
+| **Rationale** | At the current scale, the MVP-side optimizations deliver sufficient headroom (measured GC Alloc < 50 KB/frame). Promoting ECS to production would incur significant additional cost in VContainer DI integration, Fusion server-authority bridging, and Editor debug/iterate workflow adaptation — a cost that **outweighs the performance upside at the current scale**. Option C retains the ECS layer as "prepared but inactive," preserving a switch-over path for future N scaling |
+| **Impact** | `EnemyMovementSystem` / `EnemySteeringSystem` / `EnemyAIStateSystem` / `EnemyDamageSystem` and 9 `IComponentData` structs (`EnemyData` / `EnemyAIState` / `ChaseTarget`, etc.) are implemented. `HybridSyncSystem` provides the bridge to MVP-side `SurvivorEnemyController`. DI registration is disabled, so the code is effectively dead-code for now |
+| **Reevaluation Trigger** | When a production stage exceeds ~1,000 concurrent enemies, or when Profiler measurements on the MVP implementation show sustained GC spikes / Main Thread saturation |
+| **Status** | Prepared but inactive (retained as a future-scaling option) |
+
 #### ADR-006: MagicOnion Selection (Realtime Communication)
 
 | Item | Details |
@@ -2317,7 +2329,7 @@ Unity6Portfolio/
 | **Decision** | Integrate RetryPolicy + CircuitBreakerPolicy + cache fallback into UnityApiClient |
 | **Context** | Fault tolerance needed for unstable mobile network connections. Maintain user experience during outages |
 | **Alternatives** | A) Simple UnityWebRequest retry B) Port Polly (.NET standard) C) Custom policy layer |
-| **Rationale** | Polly unavailable in Unity environment, so custom implementation. 3-layer separation of concerns: RetryPolicy (exponential backoff) + CircuitBreakerPolicy (Closed/Open/HalfOpen state transitions) + RequestOptions (builder pattern). Cache fallback with expired cache tolerance for offline resilience |
+| **Rationale** | Avoided the cost of adding a non-UPM NuGet dependency, integrating `Task`-based Polly with the UniTask-centric async stack, and validating IL2CPP AOT behavior. Built a thin, project-specific layer tightly integrated with UniTask / UnityWebRequest / diagnostic logging. RetryPolicy (exponential backoff) + CircuitBreakerPolicy (Closed/Open/HalfOpen 3-state transition) + RequestOptions (builder pattern) separate concerns across three layers. Circuit-open cache fallback (stale-if-error) ensures offline resilience |
 | **Impact** | All API calls share unified error handling. Presets (Default/Aggressive/Sensitive) minimize caller configuration burden |
 | **Status** | Adopted |
 
@@ -2332,7 +2344,6 @@ Unity6Portfolio/
 | ~~Network features~~ | ~~Server communication not implemented~~ | ~~High~~ | Ranking and auth completed |
 | ~~Multiplayer~~ | ~~Multiplayer not implemented~~ | ~~High~~ | Lobby and matchmaking completed |
 | ~~Server authority~~ | ~~Client-authoritative game logic~~ | ~~High~~ | Fusion FSM + [Networked] migration completed |
-| P3 feature additions | Localization, in-app purchase system, etc. | Low | Not started (optional) |
 
 **Resolved Items**:
 - MessageBroker: Changed to direct calls via IPlayerCollisionHandler

ARCHITECTURE.md

@@ -2285,6 +2285,18 @@ Unity6Portfolio/
 | **影響** | 高頻度イベント（衝突等）は直接呼び出しに変更済み |
 | **状態** | 採用済み・改善完了 |
 
+#### ADR-005: ECS (DOTS) 本番稼働の将来延期
+
+| 項目 | 内容 |
+|-----|------|
+| **決定** | DOTS (Entities + Burst Job) を用いた敵 AI / 移動 / ステアリング基盤は整備するが、本番稼働は将来スケール時まで延期。現行ゲームは MonoBehaviour ベースの MVP 実装で運用する |
+| **背景** | サバイバーゲームの将来的な敵数スケール（N=2000+ 想定）に備え、ECS + Burst Job による並列化の実装可能性を検証する必要があった。一方、現行の本番ステージは敵数が数十〜百数十体規模で、既存の C# + MonoBehaviour 実装でも alloc/CPU ともに安定している |
+| **選択肢** | A) ECS 本格稼働（全敵を Entity 化、MonoBehaviour 廃止） B) MVP 継続 + 最適化パターン徹底（Object Pool / NonAlloc 物理 / struct 値型 / Hash キャッシュ 等） C) ハイブリッド構成（ECS システム整備 + MVP 本番稼働 + `HybridSyncSystem` で切替経路を保持） |
+| **判断理由** | 現行の敵数規模では MVP 本番の最適化蓄積で十分（GC Alloc < 50 KB/frame を計測確認）。ECS を本番導入すると VContainer DI 統合 / Fusion サーバー権威モデルとの橋渡し / Editor デバッグフローの適応コストが大きく、**実装コストに対する性能改善の期待値が低い**。C 案のハイブリッドで ECS レイヤーを「整備済・非稼働」として保持し、将来の N スケール時に切替可能な経路を温存する |
+| **影響** | `EnemyMovementSystem` / `EnemySteeringSystem` / `EnemyAIStateSystem` / `EnemyDamageSystem` 等のシステムと `EnemyData` / `EnemyAIState` / `ChaseTarget` 等の `IComponentData` struct（9 個）を実装済み。`HybridSyncSystem` で MVP 側 `SurvivorEnemyController` との橋渡し経路を用意。DI 登録は無効化状態で dead code 扱い |
+| **再評価トリガー** | 本番ステージで敵同時数が 1,000 体を超える、または MVP 実装で Profiler 計測上 GC spike / Main Thread 飽和が継続的に観測された場合 |
+| **状態** | 整備済み・非稼働（将来スケール対応として温存） |
+
 #### ADR-006: MagicOnion選定（リアルタイム通信）
 
 | 項目 | 内容 |
@@ -2380,22 +2392,21 @@ Unity6Portfolio/
 | **決定** | UnityApiClient に RetryPolicy + CircuitBreakerPolicy + キャッシュフォールバックを統合 |
 | **背景** | モバイル環境での不安定なネットワーク接続に対する耐障害性が必要。障害時にもユーザー体験を維持したい |
 | **選択肢** | A) UnityWebRequest の単純リトライ B) Polly（.NET標準）移植 C) 自作ポリシー層 |
-| **判断理由** | Unity環境ではPollyが使えないため自作。RetryPolicy（指数バックオフ）+ CircuitBreakerPolicy（Closed/Open/HalfOpen 3状態遷移）+ RequestOptions（ビルダーパターン）の3層構成で関心を分離。サーキットOpen時のキャッシュフォールバック（期限切れ許容）でオフライン耐性を確保 |
+| **判断理由** | UPM 外の NuGet 依存追加コストと UniTask ベース async との統合コスト、IL2CPP AOT での動作検証コストを避け、プロジェクト固有要件（UniTask / UnityWebRequest / 診断ログ統合）に密着した薄い自作レイヤーを選択。RetryPolicy（指数バックオフ）+ CircuitBreakerPolicy（Closed/Open/HalfOpen 3状態遷移）+ RequestOptions（ビルダーパターン）の3層構成で関心を分離。サーキットOpen時のキャッシュフォールバック（期限切れ許容）でオフライン耐性を確保 |
 | **影響** | 全API呼び出しが統一されたエラーハンドリングを持つ。プリセット（Default/Aggressive/Sensitive等）で呼び出し元の設定負担を最小化 |
 | **状態** | 採用済み |
 
 ### 11.2 既知の技術的負債
 
-| 項目 | 内容 | 優先度 | 状態 |
-|-----|------|-------|------|
+| 項目                | 内容 | 優先度 | 状態 |
+|-------------------|------|-------|------|
 | ~~MessageBroker過剰使用~~ | ~~OnTriggerEnter等でのPublish~~ | ~~中~~ | ✅ 改善完了 |
 | ~~テストカバレッジ~~ | ~~現状約20%~~ | ~~高~~ | ✅ 1148テスト達成 |
 | ~~XMLドキュメント~~ | ~~一部未記載~~ | ~~低~~ | ✅ 主要IF完了 |
 | ~~アセット配信~~ | ~~ローカルのみ対応~~ | ~~中~~ | ✅ ローカル/リモート自動切替 |
 | ~~ネットワーク機能~~ | ~~サーバー通信未実装~~ | ~~高~~ | ✅ ランキング・認証完了 |
 | ~~マルチプレイ~~ | ~~マルチプレイ未実装~~ | ~~高~~ | ✅ ロビー・マッチメイキング完了 |
 | ~~サーバー権威~~ | ~~クライアント権威のゲームロジック~~ | ~~高~~ | ✅ Fusion FSM + [Networked] 移行完了 |
-| P3機能追加 | ローカライズ、課金システム等 | 低 | 未着手（オプション） |
 
 **改善完了項目**:
 - MessageBroker: IPlayerCollisionHandlerによる直接呼び出しに変更