# 00_overview/00_03_login_session.md
# ログイン認証・セッション管理設計書

**保存先**: `public_html/docs/00_overview/00_03_login_session.md`
**作成日**: 2026-03-30
**バージョン**: 3.0
**実装の状況**: `work_order_db_migration.md`（作業書）を見る
**担当**: マスタ管理担当（初代）／改訂: 全体管理者（14代目）

---

## 1. 概要・方針

### 1.1 基本方針
- 認証処理はすべてサーバーサイド（PHP）で行う
- クライアント側（JavaScript）でのユーザー情報・権限の保持は **sessionStorage / localStorage を使用しない**
- セッション管理は PHPネイティブセッション（`$_SESSION`）を使用する
- 権限情報が必要な画面は `get_session.php` に問い合わせて取得する

### 1.2 クライアント側の禁止事項
| 禁止 | 内容 |
|------|------|
| sessionStorage / localStorage の使用 | 作業ルール⑥ |
| 権限のハードコード | 特定ユーザーの権限をJSに直書きしない |
| データの直接取得 | ユーザー情報・従事者情報を、画面がファイルやDBから直接読まない。すべて API 経由 |

### 1.3 権限の保存と参照
- 権限は、DBの `employee_permissions`（従事者ごと・権限キーごとに1行）に保存する（`00_07_database.md` 5.2節）。
- `login.php` / `get_session.php` は、`employee_permissions` を読んで `$_SESSION` に入れる。
- 権限IDと表示名の定義マスタは、DBの `permissions`（`00_07` 5.1節）。`employees/edit.html` のチェックボックス生成に使用する。
- 権限の付与・変更は、`employees/edit.html` で行う。権限の変更は、別の権限者の承認後に反映する（`00_10_change_history.md` 区分B）。

### 1.4 名称（2026-10-28 決定）

下記は、真柴さんの決定による名称。過去の資料に旧名が出てきたときは、この表で読み替える。

| 旧名 | 名称 | 内容 |
|------|------|------|
| `master_access`（従事者の「権限」内） | `supreme_access` | 全権キー。持つ人はすべての権限キーを持つものとして扱う |
| `isAdmin`（users） | `emergency_override` | 稼働状況チェックを免除する緊急用フラグ（4節） |
| 緊急ロック（機能名・権限） | `account_suspend` | アカウント停止（6節）。停止・解除は2名承認 |

- `admin_flag_assign`（4.3節）の名称の改名の要否は未決。

---

---

## 2. ログイン認証フロー

```
[login.html]
  ユーザーID・パスワード入力
        ↓ fetch POST
[/master/api/login.php]
  ① `users` テーブルから userId + password を照合
  ② status !== 'active' → 401 エラー返却
  ③ emergency_override フラグを確認（→ 4節参照）
  ④ `employees` テーブルから、同一SPS_IDのレコードと、`employee_permissions` の権限を取得
  ⑤ 稼働状況チェック（→ 3節参照）
     emergency_override: true の場合はスキップ
  ⑥ session_regenerate_id(true) でセッション固定化防止
  ⑦ $_SESSION にユーザー情報・権限・emergency_override・forceChange をセット
  ⑧ ログイン成功時にセッションIDを `active_sessions` に記録
  ⑨ 成功レスポンス（200）を返却（forceChange が true の場合は、変更画面を指す）
        ↓ 成功
[login.html]
  forceChange: false → window.location.href = 'index.html' に遷移
  forceChange: true  → パスワード変更画面（11.5節）に遷移
```

### 2.1 login.php リクエスト仕様

| 項目 | 内容 |
|------|------|
| メソッド | POST |
| エンドポイント | `/master/api/login.php` |
| Content-Type | `application/json` |
| ボディ | `{ "userId": "SPS01-99999", "password": "xxx" }` |

### 2.2 login.php レスポンス仕様

**成功時（200）**
```json
{
  "success": true,
  "name": "テスト 太郎",
  "forceChange": false,
  "redirect": "index.html"
}
```

**初期・仮パスワードでのログイン時（200）**：`force_change` が真 を返し、`redirect` はパスワード変更画面を指す（11.5節）。

**失敗時（401）**
```json
{
  "success": false,
  "message": "ユーザーIDまたはパスワードが違います"
}
```

- ログイン失敗の回数制限は未決（11.11節）。

---

## 3. ログイン拒否ルール

`employees` テーブルの `稼働状況`（`work_status`）で判定する。

| 稼働状況 | ログイン | 備考 |
|---------|---------|------|
| 常勤 | 許可 | |
| 非常勤 | 許可 | |
| 在籍 | 許可 | |
| 休職 | 許可 | |
| 休業中 | 許可 | |
| 臨時 | 許可 | 退職者等へのテンポラリ付与用。作業完了後は退職等に戻す |
| 退職 | **拒否** | |
| 契約終了 | **拒否** | |
| 契約解除 | **拒否** | |
| 解雇 | **拒否** | |
| 緊急ロック | **拒否** | 一時的措置。解除可能（→ 6節参照）。この値の内部値・表示名は、改名後の扱いが未決（アカウント停止との対応） |
| （employeesに存在しない） | **拒否** | |

拒否時のメッセージ：「このアカウントは無効です」（理由は区別しない）

**emergency_override: true のユーザーは稼働状況チェックをスキップする（→ 4節参照）**

※稼働状況の値は、内部値と表示名を分けるかが未決。

---

## 4. 緊急用フラグ（emergency_override。旧名 isAdmin）

### 4.1 概要
- `users` テーブルの `emergency_override` 列で表す
- `emergency_override` が真のユーザーは、`employees` の稼働状況チェックをスキップしてログイン可能
- アカウント停止・退職・解雇の状態でも、緊急用としてシステムに入れる
- 初期状態では、初期の全権保持者（オーナー）のみ `true`
- 全権キー（`supreme_access`）とは別のもの。`supreme_access` は権限、`emergency_override` はログイン可否の免除

### 4.2 users テーブル

| 列 | 内容 |
|------|------|
| user_id | ユーザーID（= SPS_ID）。主キー |
| password | 平文（10節。変更禁止） |
| name | 氏名 |
| status | `active` / `inactive` |
| emergency_override | 緊急用フラグ（真偽） |
| force_change | 真の間は、パスワード変更以外の操作ができない（11.5節） |
| password_kind、password_issued_at、password_issued_by | 11.2節 |

- 例（テスト用）：`SPS01-99999`（テスト 太郎。emergency_override 真）、`SPS01-99998`（テスト 花子。偽）。

### 4.3 emergency_override の付与・剥奪
- `admin_flag_assign` 権限を保有するユーザーのみ操作可能
- `admin_flag_assign` は通常業務権限（権限マスタ `permissions`）とは別枠の特別権限
- 操作画面は `employees/edit.html`（専用セクションとして分離）
- 初期状態では、初期の全権保持者（オーナー）のみ `admin_flag_assign` を保有

### 4.4 管理者自身がロックされた場合の救済
- phpMyAdmin で、`employees` の稼働状況を元に戻す。
- または `users` の `emergency_override` を確認・修正する。
- 手順の詳細は `manual/database_manual.md` に従う。

---

## 5. セッション管理方針

### 5.1 $_SESSION 保持内容

```php
$_SESSION['sps_user'] = [
    'userId'          => 'SPS01-99999',
    'name'            => 'テスト 太郎',
    'primary_company' => 'SPS',
    '所属'            => ['SPS', 'SCSPS'],
    'contractCode'    => 'C01',
    'emergency_override' => true,
    'forceChange'     => false,     // true の間は、パスワード変更以外の操作ができない（11.5節）
    'permissions'     => [
        'company_access_sps'  => true,
        'permission_assign'   => true,
        'supreme_access'      => true,
        // ... employee_permissions の付与済みの権限を格納
    ]
];
```

### 5.2 セッション有効期限・タイムアウト

#### サーバー側
- `session.gc_maxlifetime`: **3600秒（60分）**
- 各PHPファイル（login.php / get_session.php / logout.php）の `session_start()` 前に `ini_set('session.gc_maxlifetime', 3600)` を設定する
- セッションクッキーの `lifetime: 0`（ブラウザ完全終了でクッキー消去）は維持する

#### クライアント側（session.js）
- **無操作タイムアウト**: スマホ（iPhone/Android）30分 / PC・Safari 60分
- タイムアウト計測は `click` / `keydown` / `scroll` / `touchstart` で都度リセット
- タイムアウト時は `logout.php` を呼び出してから `login.html` へリダイレクト

#### タイムアウト警告帯（クライアント完結）
- タイムアウト **60秒前** に画面上部に警告帯を表示する
- `get_session.php` への `last_access` 管理追加は行わない（クライアント完結）
- 複数タブ間のタイマー同期は行わない（タブごとに独立して動作）。サーバー側の `session.gc_maxlifetime=3600` が最終的なセーフティネット

| 残り時間 | 背景色 | 文字色 |
|---------|--------|--------|
| 60〜31秒 | 黄色（#ffff00） | 赤（#cc0000） |
| 30秒以下 | 赤（#cc0000） | 白（#ffffff） |

- 帯の文言：「セッションが間もなく終了します。残り XX 秒」
- 「作業を継続する」ボタン押下でタイマーリセット・警告帯消去
- 60秒カウントダウン終了で `logout.php` 呼び出し → `login.html` へリダイレクト

#### タブ閉じ動作について
- タブを閉じても同一ブラウザが起動中であればセッションクッキーは残る（ブラウザ仕様）
- `beforeunload` + `sendBeacon` によるタブ閉じ自動ログアウトは調査の結果、Xserver環境・複数タブ運用と両立できないため廃止した
- 複数タブ運用（indexを常駐させながら各サブシステムを別タブで使用）を優先した設計とする

### 5.3 セッションの保存場所
- PHPデフォルトのセッションストレージ（サーバー上の一時ファイル）
- Xserverの標準設定に従う

### 5.4 アクティブセッション管理（active_sessions テーブル）

ログイン成功時にセッションIDを記録し、権限変更・アカウント停止時の強制破棄、および仮パスワード発行時の強制破棄に使用する。

**保存先**: `active_sessions` テーブル（`user_id`、`session_id`、`logged_in_at`。1人1行）

- ログイン成功時：対象ユーザーのセッションIDを記録・上書き
- ログアウト時：対象ユーザーのエントリを削除
- セッションタイムアウト時：PHPが自動でセッションファイルを削除するが、`active_sessions` の行は残る場合がある（ログイン時に上書きされるため実害なし）

---

## 6. アカウント停止機能（旧名 緊急ロック。権限キー account_suspend）

### 6.1 概要
不祥事・情報漏洩リスク等の緊急時に、対象ユーザーを即時締め出す機能。権限キーは `account_suspend`（旧「緊急ロック」）。

### 6.2 停止の手順
```
① employees/edit.html で対象者の稼働状況を「緊急ロック」（停止状態）に変更する依頼を行う
② 承認（6.5節）が成立したら実行
  → `employees` の稼働状況を「緊急ロック」に更新
  → 従事者の「権限」は消さない（解除後に元の権限で復帰できるようにする）
  → `active_sessions` から対象者のセッションIDを取得し、サーバー上のセッションファイルを強制削除
③ 対象者は操作中でも次のリクエスト時に get_session.php が 401 を返す
④ login.html にリダイレクト
⑤ ログインしようとしても稼働状況チェックで拒否される
```

### 6.3 解雇との違い

| 区分 | 性質 | 解除 | 権限 |
|------|------|------|------|
| アカウント停止 | 一時的措置 | 2名承認（6.5節）で、稼働状況を元に戻す | 残す |
| 解雇 | 恒久的措置 | 原則解除なし | 消す（退職・契約終了・契約解除・解雇のとき） |

### 6.4 停止の解除
- `account_suspend` を持つ人が、`employees/edit.html` で稼働状況を「常勤」等に戻す依頼を行う。承認（6.5節）が成立したら実行
- 対象者は通常通りログイン可能になる

### 6.5 2名承認（2026-10-28 決定）
- アカウントの停止・解除は、`account_suspend` を持つ人2名の承認で実行する。
  - 1人目：依頼する人。
  - 2人目：依頼者とは別の `account_suspend` 保持者が承認する。
- **`supreme_access` を持つ人は、単独で実行できる。**
- 承認・実行の記録（誰が、誰を、いつ、依頼・承認したか）は、`audit_logs`（00_07）に残す。
- マスタ・従事者などの「値の変更」の確認（Wチェック。自己確認の禁止、全権者の単独許可を明記して記録）は、`00_10_change_history.md` に定める。考え方は本節と同じ。権限の変更そのものは、00_10 の区分 B（確認者の承認後に反映）。
- 承認の画面・通知の方法、承認待ちの期限は未決。05_xx の画面仕様で決める。

### 6.6 権限変更時のセッション強制破棄
- アカウント停止に限らず、`employees/edit.html` で権限変更・保存した場合も対象ユーザーのセッションを強制破棄する
- 対象者は次のリクエスト時に再ログインを求められ、新しい権限が即時反映される

---

## 7. 各画面の権限取得フロー（get_session.php）

```
[各HTML画面 DOMContentLoaded]
  session.js が自動的に get_session.php へ問い合わせ
        ↓ fetch GET
[/master/api/get_session.php]
  ① session_start()
  ② $_SESSION['sps_user'] の存在確認
  ③ 未ログイン → 401 返却 → login.html にリダイレクト
  ④ ログイン済み → ユーザー情報・権限・emergency_override・forceChange をJSONで返却
        ↓
[session.js]
  window.spsUser にセット
  spsSessionReady イベントを発火
        ↓
[各HTML画面]
  spsSessionReady イベントを受けて初期化処理実行
  権限に応じてメニュー表示制御
```

### 7.1 get_session.php リクエスト仕様

| 項目 | 内容 |
|------|------|
| メソッド | GET |
| エンドポイント | `/master/api/get_session.php` |

### 7.2 get_session.php レスポンス仕様

**ログイン済み（200）**
```json
{
  "success": true,
  "userId": "SPS01-99999",
  "name": "テスト 太郎",
  "primary_company": "SPS",
  "所属": ["SPS", "SCSPS"],
  "contractCode": "C01",
  "emergency_override": true,
  "forceChange": false,
  "permissions": {
    "company_access_sps": true,
    "permission_assign": true,
    "supreme_access": true
  }
}
```

- `force_change` が真 の場合、session.js はパスワード変更画面以外から、変更画面へ移動させる（11.5節）。

**未ログイン（401）**
```json
{
  "success": false,
  "message": "未ログイン"
}
```

### 7.3 各画面での実装パターン（共通）

```javascript
// session.js を読み込んで spsSessionReady イベントを待つ
window.addEventListener('spsSessionReady', function() {
    const permissions = window.spsUser?.permissions || {};
    // 権限に応じた初期化処理
});
```

---

## 8. ログアウト処理

### 8.1 ログアウトAPI
- エンドポイント: `POST /master/api/logout.php`
- 処理: `session_destroy()` を実行してセッションを完全破棄 + `active_sessions` から対象の行を削除
- レスポンス: `{ "success": true }` → クライアントが `login.html` にリダイレクト

### 8.2 ログアウトの発生タイミング
- 各画面ヘッダーのユーザードロップダウン「ログアウト」ボタンから手動実行
- 無操作タイムアウト（スマホ30分 / PC・Safari 60分）で自動実行

---

## 9. エラーレスポンス定義

| HTTPステータス | 原因 | メッセージ |
|--------------|------|-----------|
| 400 | リクエストパラメータ不足 | 必須パラメータが不足しています |
| 401 | 認証失敗（ID/PW不一致） | ユーザーIDまたはパスワードが違います |
| 401 | 退職・緊急ロック・無効アカウント | このアカウントは無効です |
| 401 | 未ログイン（get_session） | 未ログイン |
| 403 | 権限がない | この操作を行う権限がありません |
| 403 | パスワード変更が必要（forceChange: true） | パスワードの変更が必要です |
| 500 | DB接続・クエリの失敗 | システムエラーが発生しました |

---

## 10. ログ履歴・パスワードの保存方針

- ログイン履歴は `login_logs`（`00_07` 5.6節）に記録する。項目・保管期間は未決（`00_08_security_operations.md`）
- パスワード平文保存は意図的設計。変更禁止。理由：会社のシステム内のデータは原則会社のものとする方針。解雇相当の従事者のアカウントを停止したあと、内部確認のために、全権保持者がパスワードを確認できるようにしておく。平時は個人を優先する

---

## 11. パスワード運用（初期パスワード・仮パスワード・パスワード通知待ち一覧）

2026-10-28 に真柴さんが決定。

### 11.1 用語

| 用語 | いつ | 誰が発行 |
|------|------|---------|
| **初期パスワード** | 従事者の新規登録時 | 自動生成。登録を行う人が、書類を発行して、紙で本人へ渡す |
| **仮パスワード** | 従事者がパスワードを忘れたとき | `password_reissue` を持つ人が、従事者の詳細画面のボタンから発行 |
| 変更後のパスワード | 本人が初回ログイン後に決める | 本人 |

### 11.2 users テーブルのパスワード関連の項目

| フィールド | 型 | 説明 |
|-----------|-----|------|
| password | string | **平文**で保存する（10節） |
| force_change | boolean | `true` の間は、パスワード変更以外の操作ができない。初期・仮パスワードの発行時に真、本人が変更したら `false` |
| password_kind | string | `initial`（初期）／`temp`（仮）／`user`（本人が設定） |
| password_issued_at | datetime | 初期・仮パスワードの発行日時（`user` のときは空） |
| password_issued_by | string | 発行した人のSPS-ID（`user` のときは空） |

### 11.3 初期パスワード
- 新規登録の保存時に、システムが自動生成して、`password_kind: initial`、`force_change` が真 で保存する。
- 生成規則（文字種・長さ）は未決。推測されにくい文字列にする。
- 登録を行う人は、「パスワード通知待ち一覧」から書類（PDF）を発行し、紙で本人に渡す。
- 紙は、本人が変更したあとに破棄する（書類にも明記する）。

### 11.4 仮パスワード
- 従事者がパスワードを忘れたときは、`password_reissue` を持つ人が、従事者の詳細画面の「仮パスワードを発行する」ボタンを押す。
- ボタンは、`password_reissue` を持つ人にだけ表示する。サーバー側でも同じ権限を確認する。
- 自動生成して、`password_kind: temp`、`force_change` が真 で保存する。以前のパスワードは使えなくなる。
- 対象者のセッションを強制破棄する（5.4節）。
- 本人からの「忘れた」の自己申告（メールによる自己リセット等）は、当面は作らない。権限者に依頼する運用とする。

### 11.5 初回ログインとパスワード変更
- 初期・仮パスワードでログインすると、`force_change` が真 を返す。画面は、パスワード変更画面に移る。
- パスワード変更画面は、`common/password_change.html`（案。マイページは未作成のため）。仕様は別に定める。
- `force_change` が真 のセッションは、パスワード変更APIとログアウト以外のAPIを、すべて拒否する（403「パスワードの変更が必要です」）。共通のログイン確認（`require_login.php`）で行う。
- 変更後は、`force_change` が偽、`password_kind: user` に更新し、発行日時・発行者を空にする。

### 11.6 パスワード通知待ち一覧
- 対象：`force_change` が真 のアカウント（初期・仮の両方）。
- 一覧の主な目的は、新規従事者が正しく登録されたかの確認。
- 表示項目：氏名、SPS-ID、種別（初期／仮）、発行日時、発行者。**パスワードの値は、一覧には表示しない。**
- 「書類を発行」ボタンは、`password_document_issue` を持つ人にだけ表示する（一覧を見るだけの人には、ボタンを出さない）。
- 書類（PDF）に載せる内容：BackofficeのURL、SPS-ID（ログイン名）、初期（仮）パスワード、初回ログイン後に変更すること、紙は変更後に破棄すること。
- 書類（PDF）の上だけに、パスワードの値が載る。PDFは、`generate_pdf.php` で、その場で作る。サーバーには保存しない。
- 本人がパスワードを変更すると、一覧から消える。
- 書類の発行は、`audit_logs` に記録する（発行者・対象者・日時。パスワードの値は記録しない）。
- 「発行したのにログインされていない人」が一覧に残るので、運用で気づける。

### 11.7 権限

権限は、原則として、ボックス（メニュー・画面の入口）単位で付ける。ボタン単位の権限は、特殊なものだけに設ける。閲覧専用の画面には、操作のボタンを置かない。

| 権限キー | 名前 | 種類 | 内容 |
|---------|------|------|------|
| `password_pending_view` | パスワード通知待ち一覧を閲覧する | ボックス | 人事メニューの「ボックス」と一覧の閲覧。権限のない人には、ボックスも表示しない |
| `password_document_issue` | パスワード通知書類を発行する | ボタン（特殊） | 一覧の「書類を発行」ボタン。限定して付与する |
| `password_reissue` | パスワードを再発行する | ボタン（特殊） | 従事者の詳細画面の「仮パスワードを発行する」ボタン |

- いずれも個人に付与する（人事など、上級者）。権限マスタ（`permissions`）に登録する。
- 全権（`supreme_access`）の人は、すべての権限を持つものとして扱う。
- 画面の表示だけでなく、APIでも同じ権限を確認する（一覧のAPIは `password_pending_view`、書類発行のAPIは `password_document_issue`、仮パスワード発行のAPIは `password_reissue`）。

### 11.8 パスワードの見え方
- `force_change` が真 の間：書類（PDF）の上で、書類の発行権限（`password_document_issue`）を持つ人に見える。一覧には、値は出ない。
- 本人が変更したあと：権限者を含め、他の人には見えない。全権保持者が確認できる（10節）。確認の方法（画面を作るか）は未決。

### 11.9 パスワードの更新方針（2026-10-28 真柴さんの方針）
- **定期的なパスワード変更は、行わない。** 理由：何事もなければ、触らないほうが安全という考え方。
- 更新は、個人に任せる（本人が、マイページ等のパスワード変更画面から、いつでも変更できる）。
- 何らかの事態が発生した場合に限り、緊急でパスワードの変更を指示する（対象の `forceChange` を `true` にする）。指示の操作と、権限は未決。
- 必要なのは、パスワードの値の一覧ではなく、**発行・更新の履歴**（誰が、誰に、いつ、何を行ったか。パスワードの値は残さない）。履歴は `audit_logs`（00_07）に記録する。

### 11.10 パスワード管理画面（未決）
- 「パスワード管理」の画面は、まだ打ち合わせていない。次の事項を、打ち合わせて決める。
  - 画面の構成（通知待ち一覧、発行・更新履歴、各ボタンの置き場所）
  - 仮パスワードの発行ボタンの置き場所（従事者の詳細画面か、パスワード管理画面か）
  - 緊急の変更指示の操作と権限
- 決まるまでは、11.6〜11.7節の内容を、暫定の仕様とする。
- 緊急時の手順（変更の緊急指示、全員の締め出しと一括発行）、検知（ログイン履歴等）は、`00_08_security_operations.md` に定める。

### 11.11 未決事項
- 初期・仮パスワードの有効期限（発行したのにログインされない場合）。一覧で気づける運用とし、期限は設けない。必要になれば決める。
- パスワード管理画面の構成（11.10節）。
- 自動生成するパスワードの規則（文字種・長さ）。
- ログイン失敗の回数制限。

---

## 12. API認証規則

- すべてのAPIは、ログイン確認から始める（ログイン確認のないAPIは作らない）。詳細は `00_07_database.md` 8.1節を参照。
- 共通処理は `master/api/require_login.php`。未ログインは 401、権限なしは 403。
- 操作者のIDは、セッションから取る。リクエストの値は使わない。

---

## 13. 改訂履歴

| 日付 | 版 | 担当 | 内容 | 理由・影響範囲 |
|------|----|------|------|--------------|
| 2026-03-30 | 1.0 | マスタ管理担当（初代） | 初版作成 | login.htmlのsessionStorage除去・PHPセッション移行に伴う設計書新規作成 |
| 2026-04-04 | 1.1 | マスタ管理担当（2代目） | 1.3節追加（権限移行フェーズ）、2節フロー改訂、3節に緊急ロック追加、4節新設（isAdmin）、5.4節新設（active_sessions.json）、6節新設（緊急ロック機能）、7節旧5節を改訂（isAdmin追加）、8節旧6節を改訂、9節旧7節を改訂、10節旧8節を改訂 | 打ち合わせ確定事項の反映：緊急ロック・isAdmin・セッション強制破棄・権限移行フェーズ |
| 2026-04-06 | 1.2 | マスタ管理担当（3代目） | 3節に「臨時」追加。5.2節を全面改訂（タイムアウト設計確定）。7節フロー改訂（spsSessionReady方式に統一）。8.2節改訂（タイムアウト自動ログアウト追加）。beforeunload+sendBeacon廃止を記録 | アクセスログ調査でsendBeaconが機能しないことを確認。複数タブ運用優先・無操作タイムアウト方式に変更。スマホ30分/PC60分に確定 |
| 2026-08-06 | 1.3 | マスタ管理担当（4代目） | 5.2節にタイムアウト警告帯仕様を追記（クライアント完結方針・カラー仕様・文言確定） | タイムアウト警告帯実装に伴う設計書反映。get_session.phpへのlast_access追加はしないクライアント完結方針を明記 |
| 2026-08-06 | 1.4 | マスタ管理担当（4代目） | 2節フロー・4.4節のファイルパスをv2.6対応に修正（data/employees/配下に変更） | フォルダ構成v2.6のファイル移動完了に伴う反映 |
| 2026-10-08 | 1.5 | 全体管理者（12代目） | ファイル名規則を「フォルダ番号＋ファイル番号」形式に変更したことに伴い、参照名と保存先表記を機械的に置換（内容の変更なし） | ファイル名規則変更（2026-10-08）。影響範囲：他設計書への参照名・保存先表記のみ |
| 2026-10-28 | 2.0 | 全体管理者（14代目） | 1.4節新設（改名：master_access→supreme_access、isAdmin→emergency_override、緊急ロック→account_suspend）。2〜4節・5.1・7・9節を改名に合わせて修正。6節を「アカウント停止機能」に改訂（2名承認）。10節のパスワード平文保存の理由を追記。11節（パスワード運用。権限は password_pending_view／password_document_issue／password_reissue の3つ）、12節（API認証規則）を新設 | 真柴さんの決定（権限キー改名、2名承認、初期パスワード・仮パスワード、パスワード通知待ち一覧）の反映。影響範囲：01_05、02_01、05_09、06_01、permissions.json、login.php、get_session.php、session.js、save_employee.php |
| 2026-10-29 | 2.1 | 全体管理者（14代目） | 6.5節に、値の変更の確認（00_10）との関係を追記。例の人名・IDをテスト用（テスト 太郎、`SPS01-99999`）に差し替え、初期の全権保持者の記述を「オーナー」に言い換え（公開サイトに実名を出さないため） | 変更履歴仕様（00_10）の承認に伴う整合。影響範囲：本書6.5節のみ |
| 2026-10-28 | 2.0 | 全体管理者（14代目） | 11.9節（パスワードの更新方針：定期変更は行わない、更新は個人に任せる、緊急時のみ変更を指示）、11.10節（パスワード管理画面は未決）を追記 | 真柴さんの方針の記録 |
| 2026-10-29 | 2.2 | 全体管理者（14代目） | 画面名 employee_edit.html を employees/edit.html に統一（本文のみ。履歴の記載は変更しない） | 権限キー・画面名の改名（真柴さん決定）に伴う整合。内容の変更なし |
| 2026-10-29 | 3.0 | 全体管理者（14代目） | DB前提の完成形に書き直し。1.2「移行背景」を「クライアント側の禁止事項」に、1.3「権限の移行フェーズ」を「権限の保存と参照」に置き換え。保存先を、JSONファイルから `users`・`employees`・`employee_permissions`・`active_sessions` テーブルに。`isAdmin`・`master_access` の併読の記述を削除し、1.4節は旧名の読み替え表に。4.2節をテーブル定義に。API認証規則の参照節を `00_07` 8.1節に | 仕様書をDB前提に統一（作業書 J-02）。コードの名称切り替えは作業書 B-11 |