# 00_overview/00_05_data_protection.md

# データ保全・バックアップ設計（会計データを除く）

**保存先**: `public_html/docs/00_overview/00_05_data_protection.md`
**作成日**: 2026-10-27
**担当**: Deepseek（5代目）
**状態**: 初版（v1.0）。全体管理者・真柴様の承認前につき、内容は確定ではない

---

## 1. 目的

本システムのデータ消失・改ざん・誤操作による被害を防止し、万一の際に復旧できる状態を保つ。あわせて、権限者による暴走（悪意ある削除等）からデータを守る。

**本書は会計データを対象外とする。** 会計データのバックアップ・リストアは `docs/07_accounting/07_04_export_import.md`（以下「07_04」）を正とし、本書からは参照するのみとする。会計データは税法上の保存義務（10年等）や税務調査対応など、他データとは異なる要件を持つため、独立した仕様として管理する。

## 2. 対象データの分類

本書が対象とするデータは以下の通り。

| 分類 | 保存場所 | 例 |
|---|---|---|
| マスタデータ | `master/*.json`、`data/employees/*.json` | 拠点、部署、職務、契約、権限、従事者（employees.json）、ユーザー（users.json）、顧客区分等 |
| 業務データ | `data/` 配下（会計を除く） | 顧客、案件、名刺、従事者の写真・考課・異動履歴、通知等 |
| ログ | `data/logs/` 配下 | 監査ログ、操作ログ（`00_06_audit_log.md` 参照） |
| 設定ファイル | `config.php` 等 | APIキー等 |

**対象外**：
- 会計データ（`data/accounting/` 配下、仕訳・固定資産・領収書等）→ `07_04` を参照
- 会計書庫（`common/archive/`）→ 会計担当の管轄

## 3. バックアップ方式

### 3.1 バックアップの種類

| 種類 | タイミング | 対象 | 保持期間 |
|---|---|---|---|
| 保存時バックアップ | 各JSONの保存API実行時 | 保存対象のJSON | 30日（既存の従事者バックアップに準拠） |
| 日次バックアップ | 毎日（深夜等） | 全対象JSON | 要確認（30日か90日か） |
| 週次バックアップ | 毎週 | 全対象JSON | 要確認 |
| 月次バックアップ | 毎月 | 全対象JSON | 要確認（1年以上か） |

### 3.2 バックアップの保存場所

- 同一サーバー内：`data/backup/YYYYMMDD/` 等（**ツリー未反映**。仕様書の承認後にツリーへ載せる。既存の `data/employees/backup/` との整合は要確認）
- サーバー外（推奨）：外部ストレージへの退避（要確認：利用可能なストレージサービスの有無）

### 3.3 世代管理

- 直近N世代を保持し、それ以前は削除する（Nは要確認）。
- 月次バックアップは長期保持する（要確認）。

### 3.4 運用方針（`07_04` との整合）

バックアップ頻度・保存場所の考え方は、`07_04` の運用推奨を踏襲する。ただし、会計データと会計以外で要件が異なる場合は、それぞれの仕様に従う。

- `07_04` の推奨頻度：週1回、月末、確定申告前後は必須
- `07_04` の保存先方針：サーバーは作業用、ローカル/USBは最終保存先
- 本書の対象データも、上記に準じた頻度・保存先で運用することを推奨する（具体的な頻度・保持期間は要確認）。

## 4. 削除の制御

### 4.1 物理削除の制御

- マスタ・業務データは、**原則として物理削除を行わない**（論理削除 `active: false` 等）。
- 物理削除が必要な場合は、`supreme_access` 保有者の承認を必須とする（要確認：既存仕様との整合）。

### 4.2 削除前スナップショットの強制取得

- 物理削除・大量更新の前に、対象データのスナップショットを自動取得する（要確認：実装方式）。

### 4.3 削除操作の権限

- マスタの削除（論理削除）は、各マスタの編集権限（`permission_assign` 等）に従う。
- 業務データの削除は、各担当の仕様に従う。

## 5. 復旧手順（リストア）

### 5.1 復旧の判断

- データ消失・破損を検知した場合、`supreme_access` 保有者が復旧を決定する。

### 5.2 復旧手順

1. 対象データの最新バックアップを特定する。
2. バックアップファイルを検証する（JSONとして正しいか）。
3. 現行データを退避する（上書き前に別名で保存）。
4. バックアップから復元する。
5. 復元後の動作確認を行う。
6. 復旧作業の記録を監査ログに残す。

### 5.3 復旧の実施者

- `supreme_access` 保有者、またはその指示を受けた担当者。

### 5.4 会計データの復旧

- 会計データの復旧は `07_04` のインポート手順（上書き／マージ）に従う。本書の手順は適用しない。

## 6. `emergency_override` / `account_suspend` との関係

- アカウント停止（`account_suspend`）は、データ保全の一環として、不正アクセスの疑いがあるアカウントを即時遮断する目的でも使用できる。
- `emergency_override` は、停止されたアカウントのデータを管理者が確認・保全するために使用する。
- 停止・解除の運用は `00_03_login_session.md` および `06_01_permission_design.md` に従う。

## 7. 関連仕様書

| 仕様書 | 内容 |
|---|---|
| `07_accounting/07_04_export_import.md` | 会計データのバックアップ・リストア（本書の対象外） |
| `00_overview/00_06_audit_log.md` | 監査ログ設計（会計・会計以外の両方を対象） |
| `00_overview/00_03_login_session.md` | ログイン・セッション管理、`emergency_override` / `account_suspend` |
| `06_permission/06_01_permission_design.md` | 権限設計（`supreme_access` 等） |

## 8. 未決事項（要確認）

1. 日次・週次・月次バックアップの具体的な頻度と実行時刻。
2. バックアップの保持期間（世代数）。
3. サーバー外への退避の可否と方法。
4. 物理削除の承認フローの詳細。
5. バックアップからの復旧を誰が実行できるか（`supreme_access` のみか、担当者も可か）。
6. 監査ログ（`00_06_audit_log.md`）のドラフトとの整合（記録対象操作の重複確認）。

## 9. 改訂履歴

| 日付 | 版 | 担当 | 内容 |
|------|----|------|------|
| 2026-10-27 | 1.0 | Deepseek（5代目） | 初版作成。会計データを対象外とし、`07_04_export_import.md` を参照する形に整理 |