第 5 章：セッション管理と生存検知

本章は Session の状態機械、ライフサイクルイベント、Terminal_Resource とのバインディング規則、および Liveness_Detection（生存検知）メカニズムを定義する。本章はブループリント §2.3 の設計意図に対応する。

5.1 Session 状態機械

各 Session はそのライフサイクル内で有限状態機械の複数の状態を経る。

5.1.1 状態定義

SessionState = enum[
  "creating",
  "active",
  "handover_pending",
  "terminating",
  "terminated"
]

状態	説明
creating	認可検証通過、Session が初期化中（リソース割り当て、OS アクセス制御設定等）
active	Session がアクティブ状態、Fay は認可範囲内の操作を実行できる
handover_pending	Session が制御権ハンドオーバーに参加中（第 6 章を参照）、結果未確定
terminating	Session が終了中、リソース回収中、新規要求は拒否される
terminated	Session が完全に終了、session_id は履歴記録に入る

5.1.2 状態遷移図

              ┌─────────────┐
              │   (start)   │
              └──────┬──────┘
                     │ 認可検証通過
                     ▼
              ┌─────────────┐
              │  creating   │
              └──────┬──────┘
                     │ リソース初期化完了
                     ▼
              ┌─────────────┐  ハンドオーバー発動 ┌──────────────────┐
              │   active    │────────────────────→│ handover_pending │
              └──────┬──────┘                     └──────┬───────────┘
                     │  ↑                                │
              終了条件│  │ハンドオーバータイムアウトロールバック │ハンドオーバー完了
                     ▼  │                                ▼
              ┌─────────────┐                    ┌─────────────┐
              │ terminating │←───────────────────┤ (handed off)│
              └──────┬──────┘                    └─────────────┘
                     │ リソース回収完了
                     ▼
              ┌─────────────┐
              │ terminated  │
              └─────────────┘

5.1.3 状態遷移規則

端末は MUST 以下の表で許可された遷移のみで Session 状態を更新する：

現在の状態	目標状態	発動条件
creating	active	リソース初期化完了
creating	terminating	初期化失敗（リソースが他の Session に占有される等）
active	handover_pending	当該 Session に対するハンドオーバー要求受領
active	terminating	主動解放、ハートビートタイムアウト、失効終了、リソース利用不可
handover_pending	terminating	ハンドオーバー成功（元 Session は MUST 終了する）またはハンドオーバータイムアウト取り消し
handover_pending	active	ハンドオーバーが新制御者により拒否（元の状態へロールバック）
terminating	terminated	リソース完全解放、状態永続化完了

実装は MUST NOT 列挙されていない状態遷移を行う。

5.1.4 状態遷移の原子性

各状態遷移は MUST 以下の原子性要件を満たす：

1. 状態の読み取り、判定、書き込みは MUST クリティカルセクション内で完了し、外部観察者は中間状態を見ない
2. 状態遷移と対応するリソース操作（OS アクセス制御の下発等）は MUST 1 つのトランザクションとして実行され、すべて成功するかすべてロールバックする

5.2 Session 作成

5.2.1 作成発動

Session は以下のシナリオで作成される：

1. iFay_Runtime が AuthRequest を発信し、認可検証通過（§3.3、§4.3 を参照）
2. 制御権ハンドオーバー成功後、新制御者のために新 Session を作成（第 6 章を参照）

5.2.2 作成ステップ

端末は MUST 以下のステップで Session を作成する：

1. リソース占有事前チェック：対象 resource_id が access_mode で占有可能かチェック（§5.3 と第 7 章読み書きロック規則を参照）
2. Session_ID 生成：新しい UUID v7 を割り当てる
3. 初期状態設定：state = "creating"
4. Session オブジェクト構築：§2.5 で定義されたフィールドを埋める
5. OS アクセス制御下発：§1.3.2 インタフェースを通じて、当該 Fay プロセスが指定モードでリソースにアクセスすることをオペレーティングシステムに告知
6. 状態切り替え：state: creating → active、created_at と last_heartbeat_at を記録
7. AuthResult 返却：session_id を AuthResult を通じて iFay_Runtime に返却

5.2.3 作成失敗処理

任一ステップ失敗時：

1. 既割り当てのリソース（OS アクセス制御エントリ等）は MUST ロールバックされる
2. Session 状態は terminating に切り替えられた後、直ちに terminated へ
3. 対応するエラーコード（E_RESOURCE_BUSY、E_OS_INTEGRATION_FAILED 等）を返却

5.3 Session と Terminal_Resource のバインディング

5.3.1 一対一バインディング

各アクティブ Session は MUST ちょうど 1 つの Resource_ID にバインドされる。端末は (resource_id, access_mode) を通じてリソースの占有関係を維持する。

5.3.2 排他性と共有性規則

詳細は第 7 章 §7.2 読み書きロックマトリクスを参照。本節はセッションレベルの簡略規則を示す：

リソース現アクティブ Session	新 Session 要求	処理
なし	任意モード	作成許可
≥1 個の read	read	作成許可
≥1 個の read	write/execute/configure	拒否（E_RESOURCE_BUSY）
1 個の write/execute/configure	任意モード	拒否（E_RESOURCE_BUSY）

5.3.3 リソース利用不可時の連鎖終了

Resource_ID に対応するリソースが利用不可となる場合（ハードウェア切断、ソフトウェアプロセスクラッシュ、オペレーティングシステムがリソース消失を報告等）：

1. 端末は MUST 当該リソースにバインドされたすべての Session を直ちに terminating に切り替える
2. 端末は MUST 影響を受けたすべての iFay_Runtime に SessionStateChanged 通知をプッシュする、reason は "resource_unavailable"
3. リソース復旧後、終了済みの Session は MUST NOT 自動復元、iFay_Runtime は AuthRequest を再発信して新 Session を作成する必要がある

5.4 Liveness_Detection（生存検知）

生存検知は持続接続維持とアプリケーション層ハートビートの 2 つの独立信号によって Session が依然アクティブかを判定する。

5.4.1 持続接続維持

iFay_Runtime と端末の間は MUST 1 本の持続接続チャネル（WebSocket、HTTP/2 stream、gRPC stream 等）を維持する。

端末は MUST 当該持続接続の状態を監視する：

• 接続確立：持続接続信号有効
• 接続断絶：持続接続信号無効（TCP RST、タイムアウト無応答等を含む）

持続接続断絶は MAY 一時的なネットワーク変動の結果である可能性があるため、MUST NOT 単独で Session 終了の根拠としない（§5.4.3 二重判定を参照）。

5.4.2 アプリケーション層ハートビート

iFay_Runtime は MUST 持続接続上で各アクティブ Session に対し周期的に Heartbeat メッセージを送信する：

Heartbeat (body of ProtocolMessage) {
  required session_id      : Session_ID
  required sequence_number : uint64
}

HeartbeatAck (body of ProtocolMessage) {
  required session_id      : Session_ID
  required sequence_number : uint64
}

パラメータ	デフォルト値	範囲
ハートビート間隔	10 秒	1–60 秒
ハートビートタイムアウト閾値	30 秒	ハートビート間隔 × 2 から ハートビート間隔 × 6

sequence_number は各 Session 内で単調増加し、0 から始まる。

端末は MUST：

1. Heartbeat 受領後直ちに HeartbeatAck を返却（sequence_number は要求と一致）
2. 当該 Session の last_heartbeat_at を更新
3. sequence_number が記録済み最大値より小さい Heartbeat を拒否（リプレイ防止）

5.4.3 二重判定

端末は MUST 以下の 2 つの条件を同時に満たす場合のみ Session 失効を判定する：

1. 持続接続断絶がハートビートタイムアウト閾値を超過
2. last_heartbeat_at からの経過時間がハートビートタイムアウト閾値を超過

この二重判定の設計意図：

• 持続接続の短期変動期間中、アプリケーション層ハートビートは依然正常な可能性がある（失効と誤判定すべきでない）
• アプリケーション層ハートビート停止だが持続接続が依然存在（Fay スタック等）はハートビートタイムアウトで検出する必要がある
• 両者同時発生こそ高信頼度の失効信号

5.4.4 失効後の処理

失効判定後、端末は MUST：

1. Session 状態切り替え：active → terminating
2. 占有していた Terminal_Resource を解放
3. OS インタフェースを通じて当該 Fay のリソースアクセス権限を取り消し
4. 持続接続復旧またはハートビート復旧待機期間中、当該 Session に対するすべての要求は E_SESSION_TERMINATED を返却
5. 端末は MAY 持続接続復旧後 iFay_Runtime に 1 度 SessionStateChanged 通知をプッシュするが、この時点で Session は復元不可

5.4.5 ハートビートのオプションモード

実装は MAY 以下のハートビート最適化モードをサポートする（明示的サポート宣言が必要）：

1. 集約ハートビート：iFay_Runtime が 1 つの Heartbeat メッセージ内で複数の Session を同時報告（1 つの runtime が大量の Session を管理するシナリオに適用）
2. 降頻ハートビート：Session が長期間リソースアクセスを発信していない場合、ハートビート間隔は最長 60 秒まで拡大可能

集約ハートビートの具体的形式はオプション拡張として、schema.json 内でオプションフィールドとして定義される。

5.5 Session 終了

5.5.1 終了発動条件

発動原因	reason フィールド値	発動者
主動解放	"client_release"	iFay_Runtime
ハートビートタイムアウト	"liveness_timeout"	端末 Liveness_Detection
失効終了	"credential_revoked"	端末失効リスト更新
リソース利用不可	"resource_unavailable"	端末 OS 統合層
クレデンシャル期限切れ	"credential_expired"	端末定期チェック
ハンドオーバー完了	"handed_over"	端末ハンドオーバーフロー
強制終了	"forced"	端末管理インタフェース（管理者操作等）

5.5.2 終了ステップ

端末は MUST 以下のステップで終了を実行する：

1. 状態切り替え：{active|handover_pending} → terminating
2. OS リソース回収：§1.3.2 インタフェースを通じて Fay プロセスのリソースアクセス権限を取り消し
3. 並行制御解放：(resource_id, access_mode) を占有リストから削除（第 7 章読み書きロック更新を参照）
4. iFay_Runtime 通知：SessionStateChanged メッセージを送信、状態 terminated、reason 付き
5. 状態切り替え：terminating → terminated
6. 永続化：MAY Session 履歴記録を監査ログに書き込み

5.5.3 終了の冪等性

iFay_Runtime が発信する SessionRelease メッセージは MUST 冪等：

• Session が既に terminating または terminated の場合、再解放は MUST 成功を返却（エラーとみなさない）
• Session が存在しない（既に回収済み）場合、E_SESSION_NOT_FOUND を返却

5.5.4 終了の可観測性

端末は MUST 少なくとも以下に Session 終了を通知する：

1. 当該 Session に関連する iFay_Runtime（SessionStateChanged 経由）
2. 端末ローカルのリソース管理サブシステム（可用性状態更新用）

端末は MAY 以下の通知を選択する：

• 当該リソースを待機中の他の iFay_Runtime（§6 ハンドオーバー通知メカニズム経由）
• 監査ログ（端末実装の監査ポリシー次第）

5.6 状態変更通知

SessionStateChanged (body of ProtocolMessage) {
  required session_id : Session_ID
  required new_state  : SessionState
  optional reason     : string
  optional details    : map<string, string>
}

端末は MUST 以下の状態遷移発生時に iFay_Runtime に SessionStateChanged を送信する：

1. creating → active：Session 作成成功（AuthResult を通じて直接告知することも可、二者択一）
2. active → handover_pending：Session がハンドオーバーフローに進入
3. handover_pending → active：ハンドオーバー取り消しまたは拒否
4. * → terminating と terminating → terminated：終了プロセスの開始と終了

5.7 Session とクレデンシャルライフサイクルの関係

Session のライフサイクルはクレデンシャルライフサイクルから独立しているが、端末は MUST クレデンシャル状態変化を監視する：

クレデンシャルイベント	Session への影響
クレデンシャル not_after 到達	関連 Session は直ちに credential_expired で終了
クレデンシャル失効（失効声明が端末に到達）	関連 Session は直ちに credential_revoked で終了
クレデンシャルが同 ID で再発行（理論的に不可能、descriptor_id は再利用不可）	適用なし
クレデンシャルが新版で上書き（更新フロー）	Session 影響なし（依然元の credential_ref で検証）

5.8 Session 数量制限

端末は SHOULD リソース枯渇防止のため Session 数量制限を実装する：

次元	デフォルト制限	備考
単一端末総アクティブ Session	1024	端末ポリシーで調整可
単一 Fay アクティブ Session	64	単一 Fay によるシステムリソース占有を防止
単一 Resource_ID アクティブ read Session	32	read 共有の濫用防止

制限超過時、端末は MUST E_SESSION_LIMIT_EXCEEDED を返却する。