docs: add session management future roadmap to Phase 5

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

CLAUDE.md

@@ -668,6 +668,95 @@ content パススルーで解消されるのは `ReadLongTerm()` の多重呼び
 
 ---
 
+### セッション管理の発展的展望
+
+> 現状の設計は「正確性」は成熟しているが「ライフサイクル」が欠落している。
+> 以下は実装コスト・実用価値の観点で3段階に整理した将来の発展方向。
+
+#### 近期: 運用上の成熟
+
+**セッションライフサイクルの明示化**
+
+現在 `Session.Created` / `Session.Updated` はフィールドに存在するが使われていない。`Delete()` API と TTL 付きエビクションを加えるだけで「セッションを意識的に管理できる」状態になる。
+
+```go
+type Session struct {
+    // 既存フィールド ...
+    Name      string    // 「project-x」などの名前付け
+    Tags      []string  // タグによる分類
+    Archived  bool      // アーカイブ済みフラグ
+    ParentKey string    // 親セッション (subagent chain の明示化)
+}
+```
+
+- `SessionManager.Delete(key)` の追加
+- `sessionLocks sync.Map` (loop.go) の GC — 現状ユニークキーが増えると未回収で膨れる
+- 起動時の `loadSessions()` を遅延ロード化 (セッションファイル数が増えた場合の起動時間対策)
+
+#### 中期: 会話の構造化
+
+**チェックポイント / ロールバック**
+
+```
+[turn 1] → [turn 2] → [turn 3 : checkpoint A] → [turn 4] → [turn 5]
+                                ↑
+                        「turn 3 に戻る」= turn 4, 5 を捨てて再開
+```
+
+LLM が方向を間違えた時点に戻るユースケースは個人利用でも頻繁に発生する。
+`Session.Messages` を append-only immutable にする (D-5 COW) と自然につながる。
+
+**名前付きセッション / 意図的な切り替え**
+
+現在セッションキーは「どこから来たか」(チャンネル+ピア) で決まる。これを「何の文脈か」でも切り替えられるようにする:
+
+```
+/new-session "refactoring-auth"    → 新しいセッションを明示的に開始
+/switch-session "refactoring-auth" → 過去の名前付きセッションに戻る
+/list-sessions                     → セッション一覧
+```
+
+`routing/session_key.go` の `BuildAgentPeerSessionKey()` はすでに柔軟な構造なので、セッション名を key の一部として持つことは設計上無理がない。
+
+#### 長期: セッション間の関係
+
+**サブエージェントセッションのグラフ化**
+
+現在、サブエージェントセッションは `IsSubagentSessionKey()` で判定できるが、「どの親セッションから生まれたか」という親子関係は key の命名規則に暗黙的に埋め込まれているだけ:
+
+```
+agent:main:main
+  └─ subagent:abc123:main   ← 親が main:main とは構造的に管理されていない
+  └─ subagent:def456:main
+```
+
+`Session.ParentKey` を追加してセッションをグラフとして持てると、「このサブエージェントが何をやったか」を親セッションから遡れるようになる。
+
+**クロスセッション検索**
+
+`loadSessions()` が全履歴をメモリに展開するため、全セッションはすでに検索可能な状態にある。これを活用したコンテキスト注入:
+
+```
+「以前 auth について話したとき何を決めたっけ」
+→ セッション横断でキーワード検索 → 関連ターンを抽出してプロンプトに注入
+```
+
+`MEMORY.md` は現状「プラン専用の永続メモリ」だが、クロスセッション検索はその補完として機能する。
+
+#### 設計上の選択肢
+
+現在の構造は2つの哲学の中間に位置している:
+
+| 哲学A: 履歴中心 | 哲学B: 知識中心 |
+|----------------|----------------|
+| `Session.Messages` が唯一の真実 | 重要な情報を `MEMORY.md` 等に蒸留 |
+| 会話を「再生」してコンテキスト再現 | 構造化知識を「注入」してコンテキスト構築 |
+| ロールバック・ブランチが自然な拡張 | クロスセッション検索が自然な拡張 |
+
+このコードベースはすでに `Session.Messages` (哲学A) と `MEMORY.md` (哲学B) が共存しており、Phase 5 の `ParsedPlan インメモリモデル` は哲学B 方向への布石になる。
+
+---
+
 ### 実装順サマリー
 
 ```