docs: fix session roadmap — clarify lazy loading vs cross-session search tradeoff inline

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

CLAUDE.md

@@ -734,8 +734,6 @@ agent:main:main
 
 **クロスセッション検索**
 
-`loadSessions()` が全履歴をメモリに展開するため、全セッションはすでに検索可能な状態にある。これを活用したコンテキスト注入:
-
 ```
 「以前 auth について話したとき何を決めたっけ」
 → セッション横断でキーワード検索 → 関連ターンを抽出してプロンプトに注入
@@ -743,6 +741,12 @@ agent:main:main
 
 `MEMORY.md` は現状「プラン専用の永続メモリ」だが、クロスセッション検索はその補完として機能する。
 
+> **注意: 遅延ロードとの競合**
+> 近期の「遅延ロード化」を実装すると、起動時に全セッションがメモリにある前提が崩れる。
+> 両方を採用する場合は以下のいずれかを選択する必要がある:
+> - **検索時フルスキャン**: 検索リクエストのたびに `sessions/` ディレクトリの全 JSON を読む (低頻度なら許容)
+> - **バックグラウンドインデックス**: 起動後にゴルーチンで全ファイルを非同期スキャンし、キーワードインデックスを構築・維持する
+
 #### 設計上の選択肢
 
 現在の構造は2つの哲学の中間に位置している:
@@ -773,28 +777,3 @@ Phase 0 ──→ Phase 1 ──→ Phase 2 ──→ Phase 3 ──→ Phase 4
 
 ---
 
-## FEEDBACK — 第13回レビュー (ラウンド R)
-
-### R-1: セッション管理ロードマップの内部矛盾 — 遅延ロードとクロスセッション検索が競合
-
-**近期**と**長期**の提案が前提を共有できていない。
-
-| 項目 | 提案内容 |
-|------|---------|
-| 近期 (運用成熟) | `loadSessions()` を**遅延ロード化** — 起動時に全セッションをメモリに載せない |
-| 長期 (クロスセッション検索) | **「`loadSessions()` が全履歴をメモリに展開するため、全セッションはすでに検索可能」**を前提にする |
-
-遅延ロードを実装すると長期項目の前提が崩れる。検索のたびに全 JSON ファイルをスキャンするか、別途インデックスを維持する必要が生じる。
-
-長期「クロスセッション検索」の記述を修正し、遅延ロード後の実装パスを明示すること:
-
-```
-遅延ロードあり:
-  セッション検索 = 起動後に検索用スキャンゴルーチンが全 JSON を読み込む
-                  or 別途キーワードインデックスファイルを管理
-遅延ロードなし (現状維持):
-  セッション検索 = 全セッションがすでにメモリにあるため自明
-```
-
-近期と長期を同時採用する場合は「遅延ロード + 検索時フルスキャン」か「遅延ロード + インデックス」のどちらかを選択する必要がある旨を注記すべき。
-