# システム改善提案書（サンプル／架空）

**対象システム**: MediBridge Portal（医療・OTC連携 会員向けポータル）
**提案日**: 2025-12-27
**作成者**: システム診断チーム（架空）
**取扱区分**: Confidential（社外秘）

---

## 1. エグゼクティブサマリー

### 1.1 本提案書の目的

本提案書は、MediBridge Portal の **セキュリティ診断結果**、**非機能要件**、**運用状況（障害・問い合わせ）**、**インフラ設定**を統合的に分析し、以下を実現するための改善施策を提案します。

* セキュリティ強化（脆弱性・設定不備の解消）
* 保守性改善（変更容易性の向上、技術的負債の低減）
* パフォーマンス改善（ピーク時の応答・安定性向上）
* 運用効率・コスト最適化（監視・自動化・支出削減）

### 1.2 診断結果の総合評価

| 評価項目    |     現状評価 |      目標評価 |
| ------- | -------: | --------: |
| セキュリティ  | C（改善が必要） | A（業界標準準拠） |
| コード品質   |        C |         B |
| 保守性     |        D |         B |
| パフォーマンス |        C |         A |
| 運用効率    |        C |         A |

### 1.3 改善提案サマリー（件数）

| 分類      |    緊急 |      高 |      中 |     低 |     合計 |
| ------- | ----: | -----: | -----: | ----: | -----: |
| セキュリティ  |     2 |      5 |      3 |     1 |     11 |
| 保守性     |     0 |      2 |      3 |     2 |      7 |
| パフォーマンス |     0 |      1 |      2 |     2 |      5 |
| 品質保証    |     0 |      1 |      2 |     1 |      4 |
| 運用コスト   |     0 |      1 |      2 |     2 |      5 |
| **合計**  | **2** | **10** | **12** | **8** | **32** |

> ※「緊急・高・中・低」の粒度と集計表は、添付の改善提案書の形式に合わせています。

### 1.4 推奨対応期間と概算工数

| フェーズ           |       期間 |     概算工数 | 優先度    |
| -------------- | -------: | -------: | ------ |
| Phase 1（緊急対応）  |     〜1週間 |      6人日 | 即時対応必須 |
| Phase 2（短期改善）  |     〜1ヶ月 |     22人日 | 高優先度   |
| Phase 3（中長期改善） |     〜3ヶ月 |     55人日 | 計画的対応  |
| **合計**         | **約4ヶ月** | **83人日** | -      |

> 期間・工数の提示形式は、添付例の「Phase 1/2/3」テーブルの形を踏襲しています。

---

## 2. 現状分析の概要

### 2.1 診断対象

| 項目   | 内容                                      |
| ---- | --------------------------------------- |
| 対象範囲 | Webアプリ（フロント/バック）、API、バッチ、IaC、CI設定       |
| 規模   | 約820ファイル（アプリ約600、IaC約120、CI/運用約100）     |
| 解析手法 | 静的コード解析、設定レビュー、依存関係脆弱性確認、運用ヒアリング        |
| 基準   | OWASP Top 10（2021）、CWE Top 25、静的解析品質ゲート |

> 上表の「解析手法」「基準」の書き方は、添付例の記載スタイルに合わせています。

### 2.2 診断で使用したドキュメント（架空）

* セキュリティ診断レポート（2025-12-20）
* 非機能要件定義（SLO/可用性/性能/監査）
* インフラ設計（AWS: ALB/ECS/RDS/CloudFront/WAF）
* 運用手順書（障害対応、リリース、権限管理）
* 障害・問い合わせチケット（直近6ヶ月）

### 2.3 主要な発見事項

#### ✅ 良好な点

1. 認証基盤にOIDC（SSO）が導入済みで、MFAも適用可能
2. 主要な個人情報はDB暗号化（KMS）を利用して保護
3. 監査ログの“器”は存在（ただし活用不足：後述）

#### ⚠️ 改善が必要な点（要約）

* **緊急**: シークレット（APIキー）が一部リポジトリ内に平文で残存（漏洩リスク）
* **緊急**: CSRF対策が一部画面で未適用（アカウント操作の不正実行リスク）
* **高**: Cookie/セッション設定が不十分（Secure/HttpOnly/SameSite/HSTS）
* **高**: 依存パッケージの脆弱性対応が手動で、棚卸しが不完全
* **中**: 自動テスト・CI品質ゲート不足により改修の安全性が低い
* **中**: 監視の粒度不足で、障害の検知・切り分けが遅い（MTTR増）
* **中〜低**: DBのN+1、キャッシュ未整備でピーク時に遅延

---

## 3. 改善提案一覧

> **注意**: 以下の一覧は、緊急度・重要度が高い順に並べています。

| No | カテゴリ    | 提案タイトル                                      | 緊急度 | 重要度 | 影響範囲    |  工数目安 |
| -: | ------- | ------------------------------------------- | --- | --- | ------- | ----: |
|  1 | セキュリティ  | 【緊急】シークレット管理の徹底（リポジトリ追放＋ローテーション）            | 高   | 高   | 全体      | 2.5人日 |
|  2 | セキュリティ  | 【緊急】CSRF対策の完全適用（例外棚卸し＋テスト）                  | 高   | 高   | 会員/申請   | 2.0人日 |
|  3 | セキュリティ  | Cookie/セッション設定の強化（Secure/HttpOnly/SameSite） | 高   | 高   | 認証全体    | 1.0人日 |
|  4 | セキュリティ  | HSTS/CSP等のセキュリティヘッダー標準化                     | 高   | 中   | Web全体   | 1.0人日 |
|  5 | セキュリティ  | 依存関係脆弱性の継続検知（Dependabot + Gate）             | 中   | 高   | 全体      | 2.0人日 |
|  6 | 品質保証    | CI品質ゲート導入（Lint/Unit/DAST最低限）                | 中   | 高   | 全体      | 4.0人日 |
|  7 | 保守性     | 認可（Role/Permission）をサービス層へ集約                | 中   | 中   | 会員/管理   | 6.0人日 |
|  8 | パフォーマンス | DBのN+1解消（トップ5画面）                            | 中   | 中   | 参照画面    | 5.0人日 |
|  9 | 運用効率    | セキュリティ監査ログの整備（専用チャネル＋アラート）                  | 中   | 中   | ログ基盤    | 3.0人日 |
| 10 | 運用コスト   | ログ保持/ストレージのライフサイクル最適化                       | 低   | 中   | 運用      | 2.0人日 |
| 11 | パフォーマンス | キャッシュ戦略導入（マスタ/検索結果/レート制限）                   | 低   | 中   | API/Web | 6.0人日 |
| 12 | 保守性     | モノリス肥大化の分割方針策定（ドメイン境界整理）                    | 低   | 中   | アーキ     | 8.0人日 |
| 13 | 品質保証    | E2Eスモークテスト（重要導線のみ）                          | 低   | 中   | 会員導線    | 4.0人日 |
| 14 | 運用コスト   | ECSのAutoScaling再設計（ピーク追従＋下げ）                | 低   | 低   | インフラ    | 3.0人日 |

---

## 4. 詳細提案

### 4.1 【緊急】シークレット管理の徹底（リポジトリ追放＋ローテーション）

| 項目     | 内容                                                           |
| ------ | ------------------------------------------------------------ |
| 現状     | 一部APIキー/外部連携トークンが設定ファイルに直書き。PRレビューでも見逃しが発生。                  |
| リスク/課題 | 漏洩時に外部サービス悪用・個人情報流出・課金被害。Git履歴に残ると根絶困難。                      |
| 対策     | ①Secrets Manager/Parameter Storeへ移行 ②CIでシークレットスキャン ③既存キー即ローテ |
| 工数     | 2.5人日                                                        |
| 優先度    | 🔴 緊急                                                        |
| 期待効果   | 漏洩リスクの大幅低減、監査対応強化、事故時の被害抑止                                   |

**実装方針（例）**

* `.env`の運用を廃止し、本番はSecrets Manager参照に統一
* Git履歴からの削除（BFG等）と、関係者への再配布手順を整備

---

### 4.2 【緊急】CSRF対策の完全適用（例外棚卸し＋テスト）

| 項目     | 内容                                      |
| ------ | --------------------------------------- |
| 現状     | 一部のフォーム/管理画面でCSRFトークン検証が無い、または例外URLが過剰。 |
| リスク/課題 | ログイン中のユーザーに不正操作（住所変更/申請/退会等）を実行される恐れ。   |
| 対策     | CSRFミドルウェア強制 + 例外URL最小化 + 回帰テスト（重要操作）   |
| 工数     | 2.0人日                                   |
| 優先度    | 🔴 緊急                                   |
| 期待効果   | 不正リクエストの遮断、重大事故の発生確率を低下                 |

---

### 4.3 Cookie/セッション設定の強化（Secure/HttpOnly/SameSite）

| 項目     | 内容                                                               |
| ------ | ---------------------------------------------------------------- |
| 現状     | Secure/HttpOnly/SameSiteが環境によって未統一。                              |
| リスク/課題 | セッションハイジャック、CSRF補助、XSS時のCookie窃取リスクが上昇。                          |
| 対策     | `Secure=true`（HTTPS必須）、`HttpOnly=true`、`SameSite=Lax/Strict`の標準化 |
| 工数     | 1.0人日                                                            |
| 優先度    | 🟠 高                                                             |
| 期待効果   | 認証・セッション周りの耐攻撃性向上                                                |

---

### 4.4 HSTS/CSP等のセキュリティヘッダー標準化

| 項目     | 内容                                   |
| ------ | ------------------------------------ |
| 現状     | ヘッダーの付与がCDN/ALB/アプリで分散し、画面ごとに漏れがある。  |
| リスク/課題 | XSS/MIME sniffing/盗聴への耐性不足。          |
| 対策     | CDN（推奨）に集約し、CSPは段階導入（Report-Only→強制） |
| 工数     | 1.0人日                                |
| 優先度    | 🟠 高                                 |
| 期待効果   | 多層防御の基盤化、セキュリティ設定の属人化排除              |

---

### 4.5 依存関係脆弱性の継続検知（Dependabot + Gate）

| 項目     | 内容                                       |
| ------ | ---------------------------------------- |
| 現状     | 月次棚卸しが形骸化し、脆弱性対応が後追い。                    |
| リスク/課題 | 既知脆弱性の放置により侵害リスクが増大、監査で指摘されやすい。          |
| 対策     | ①自動PR（Dependabot等）②CVSS閾値でマージゲート ③SBOM出力 |
| 工数     | 2.0人日                                    |
| 優先度    | 🟠 高                                     |
| 期待効果   | “気づけない”状態からの脱却、継続的な健全性維持                 |

---

### 4.6 CI品質ゲート導入（Lint/Unit/DAST最低限）

| 項目     | 内容                                        |
| ------ | ----------------------------------------- |
| 現状     | CIが軽量で、テスト未実施でもリリース可能。                    |
| リスク/課題 | 改修のたびに手戻り・障害が発生しやすく、MTTRも延びる。             |
| 対策     | Lint + Unit（薄くても必須）+ 重要画面スモーク + 依存脆弱性チェック |
| 工数     | 4.0人日                                     |
| 優先度    | 🟠 高                                      |
| 期待効果   | 品質の下振れ防止、リリースの心理的安全性向上                    |

---

## 5. 改善ロードマップ

### 5.1 Phase 1: 緊急対応（〜1週間）

```
Phase 1（緊急対応）
├── シークレット追放（Secrets Manager移行）
│   ├── 既存キー棚卸し
│   ├── 移行実装
│   └── キーローテーション
├── CSRF対策の完全適用
│   ├── 例外URL削減
│   └── 重要操作の回帰テスト
└── Cookie/セッション設定の標準化
```

**Phase 1 完了条件**（例）

* [ ] シークレットがリポジトリから除去され、ローテーション完了
* [ ] CSRFが重要操作で必須になり、例外が最小化
* [ ] Cookie設定（Secure/HttpOnly/SameSite）が本番で統一

> 「ツリー形式＋完了条件」の表現は、添付例のロードマップ記載に合わせています。

### 5.2 Phase 2: 短期改善（〜1ヶ月）

```
Phase 2（短期改善）
├── セキュリティヘッダー標準化（HSTS/CSP導入）
├── 依存関係脆弱性の継続検知（PR自動化 + Gate）
├── CI品質ゲート導入（Lint/Unit/DAST最小）
└── 監査ログ整備（専用チャネル + アラート）
```

**Phase 2 完了条件**（例）

* [ ] HSTSが有効、CSPがReport-Only→段階強制へ移行済
* [ ] 依存脆弱性が“検知される”状態になり、対応フローが定着
* [ ] 主要PRが品質ゲートを通過しないとマージできない

### 5.3 Phase 3: 中長期改善（〜3ヶ月）

```
Phase 3（中長期改善）
├── 認可ロジック集約（サービス層統一）
├── DB N+1改善（トップ5画面）
├── キャッシュ戦略導入（マスタ/検索）
├── モノリス分割方針策定（ドメイン境界）
└── AutoScaling/ログ保持最適化（運用コスト）
```

**Phase 3 完了条件**（例）

* [ ] ピーク時p95応答が目標値以内（例: 800ms以下）
* [ ] 主要画面のN+1が解消（監視クエリで再発検知）
* [ ] インフラコストが月次で可視化され、削減施策が反映済

---

## 6. 概算費用（架空）

| フェーズ    |       工数 |    想定単価 |      概算費用 |
| ------- | -------: | ------: | --------: |
| Phase 1 |      6人日 | 12万円/人日 |      72万円 |
| Phase 2 |     22人日 | 12万円/人日 |     264万円 |
| Phase 3 |     55人日 | 12万円/人日 |     660万円 |
| **合計**  | **83人日** |       - | **996万円** |

※単価・費用はサンプルです（体制・契約形態で変動）。

---

## 7. 推奨体制（例）

* PM/推進: 0.3人月（進捗・合意形成・リスク管理）
* Tech Lead: 0.5人月（設計統一・レビュー）
* App Eng: 1〜2名（実装）
* Infra/SRE: 0.5名（WAF/ヘッダー/CDN/監視/コスト）
* QA: 0.3名（テスト設計・スモーク整備）

---

## 8. 次のステップ（推奨アクション）

1. **本日中**: Phase 1（緊急対応）の着手判断（ローテーションの意思決定）
2. **1週間以内**: Phase 1完了・緊急リスクの封じ込め
3. **2週間以内**: Phase 2の詳細WBS確定（環境差分・影響調査）
4. **1ヶ月以内**: Phase 2完了・品質ゲート定着
5. **3ヶ月以内**: Phase 3の実施判断（性能・保守性の投資対効果で取捨選択）

> “次のステップ／ご確認事項”セクションは、添付例の末尾構成に合わせています。

---

## 付録（例）

### A. リスクと留意事項

* CSRF/ヘッダー/Cookieの変更は、ログイン周りの挙動差分が出やすい（段階リリース推奨）
* CSPは最初から強制せず、**Report-Only**でレポートを収集してから適用

### B. 参照ドキュメント（架空）

| ドキュメント       | 格納場所                          |
| ------------ | ----------------------------- |
| セキュリティ診断レポート | `docs/security/assessment.md` |
| 非機能要件定義      | `docs/nfr/requirements.md`    |
| インフラ設計書      | `docs/infra/design.md`        |
| 運用手順書        | `docs/ops/runbook.md`         |