コンテキスト切れ219回の教訓：AIとの長時間セッションで何が壊れるか

1
session_stats = {
2
    "total_sessions": 108,
3
    "total_context_overflows": 219,
4
    "avg_overflows_per_session": 2.03,
5
    "avg_session_size_mb": 3.7,
6
    "median_session_size_mb": 1.9,
7
    "max_session_size_mb": 81.1,
8
    "max_session_messages": 473,
9
}

1
サイズ帯        セッション数   コンテキスト切れ率
2
─────────────────────────────────────────────
3
< 1MB           32件          0.1回/セッション
4
1-2MB           28件          0.8回/セッション
5
2-5MB           25件          2.1回/セッション
6
5-10MB          14件          4.3回/セッション
7
10-50MB          7件          8.6回/セッション
8
> 50MB           2件         15.0回/セッション

1
1. AIが自動でコンテキストを圧縮
2
   → 古いメッセージが要約に変換される
3
   → 直近のメッセージは保持される
4

5
2. CLAUDE.mdは常に保持される
6
   → セッション冒頭で読み込まれた指示は維持
7
   → 「絶対に破ってはいけないルール」は残る
8

9
3. 中間の意思決定が消失する
10
   → 「なぜこの設計にしたか」の議論が失われる
11
   → ファイルの内容を読んだ結果が失われる
12
   → 部分的な進捗状況が失われる

1
セッション継続時にAIが受け取る情報:
2
  CLAUDE.md（常に読み込み）
3
  直前の数メッセージ
4
  システムが生成したセッション要約
5
  ----
6
  30分前の設計議論の詳細 → 消失
7
  途中で読んだファイルの内容 → 消失
8
  検討して却下した代替案 → 消失
9
  「なぜそうしたか」の理由 → 消失

1
セッション前半（コンテキスト切れ前）:
2
  ユーザー: 「この関数はリトライを3回までにして」
3
  AI: 「了解。max_retries=3 で実装します」
4
  → 実装完了
5

6
  ...（30分後、コンテキスト切れ発生）...
7

8
セッション後半（コンテキスト切れ後）:
9
  ユーザー: 「同じ処理を別のモジュールにも追加して」
10
  AI: 「リトライロジックを追加しました」
11
  → max_retries=5 で実装（3回の制約を忘れている）

1
セッション前半:
2
  AI: 「Strategyパターンで実装する案を提案します」
3
  ユーザー: 「この規模ではオーバーエンジニアリング。
4
            関数ベースでシンプルに」
5
  AI: 「了解。関数ベースで実装します」
6

7
  ...（コンテキスト切れ発生）...
8

9
セッション後半:
10
  AI: 「ここはStrategyパターンが適切だと思います」
11
  → すでに却下された案を再提案

1
セッション前半:
2
  AI: config.py を修正（パラメータ追加）
3
  AI: engine.py を修正（configの参照追加）
4

5
  ...（コンテキスト切れ発生）...
6

7
セッション後半:
8
  AI: test_engine.py を修正
9
  → config.py の変更を考慮せず、古い構造でテストを書く
10
  → テストが失敗

1
実際の議論:
2
  「外部メトリクスAPIのタイムアウトを60秒にした。
3
   理由: 無料枠のレート制限（1分5回）に対応するため。
4
   30秒では間に合わないケースがあった。
5
   ただし120秒以上にすると他の処理がブロックされる」
6

7
セッション要約での情報:
8
  「外部メトリクスAPIのタイムアウトを60秒に変更した」
9

10
失われた情報:
11
  - なぜ60秒なのか（30秒と120秒がダメな理由）
12
  - 無料枠の制約という背景
13
  - 他の処理への影響の考慮

1
セッション開始: /sc:analyze でコード品質分析
2
  ↓
3
分析結果を受けて修正を開始
4
  ↓
5
修正中に別の問題を発見
6
  ↓
7
問題の修正→テスト→分析→修正→テスト...
8
  ↓
9
473メッセージ、81.1MB、15回のコンテキスト切れ

1
monster_session_analysis = {
2
    "initial_task": "コード品質分析",
3
    "scope_creep": [
4
        "分析 → 修正",           # 分析だけのはずが修正まで拡大
5
        "修正 → 新たな問題発見",  # 修正中に別の問題を見つける
6
        "問題 → 追加修正",       # 見つけた問題をその場で修正
7
        "修正 → 再分析",         # 修正後にまた分析
8
    ],
9
    "total_messages": 473,
10
    "context_overflows": 15,
11
    "should_have_been": "4-5 separate sessions",
12
}

1
本来あるべきセッション分割:
2
  Session 1: コード品質分析（/sc:analyze）→ 問題一覧の作成
3
  Session 2: 優先度Highの問題を修正
4
  Session 3: 優先度Mediumの問題を修正
5
  Session 4: 修正後の再分析と検証
6
  Session 5: ドキュメント更新とコミット

1
セッションサイズ → 品質への影響
2

3
< 2MB:  ■■■■■ 高品質
4
  - AIの記憶が完全に保持される
5
  - コンテキスト切れはほぼ発生しない
6
  - 集中したタスクに最適
7

8
2-5MB:  ■■■■□ 良好
9
  - 標準的な開発セッション
10
  - コンテキスト切れは1-2回
11
  - 適切なサイズ
12

13
5-10MB: ■■■□□ 品質低下の兆候
14
  - AIが以前の議論を忘れ始める
15
  - 同じ質問を繰り返す可能性
11 collapsed lines
16
  - 分割を検討すべき
17

18
10-30MB: ■■□□□ 明確な品質低下
19
  - コンテキスト圧縮が頻繁に発生
20
  - 中間的な意思決定が大量に消失
21
  - セッション分割を強く推奨
22

23
> 30MB: ■□□□□ 深刻な品質問題
24
  - AIの応答が不整合になる
25
  - 以前の変更と矛盾する修正
26
  - 即座にセッション分割すべき

1
quality_indicators = {
2
    "under_2mb": {
3
        "rework_rate": "5%",     # 手戻り率
4
        "constraint_miss": "2%",  # 制約忘れ率
5
        "file_conflict": "1%",   # ファイル矛盾率
6
    },
7
    "2_to_5mb": {
8
        "rework_rate": "10%",
9
        "constraint_miss": "8%",
10
        "file_conflict": "3%",
11
    },
12
    "5_to_10mb": {
13
        "rework_rate": "22%",
14
        "constraint_miss": "18%",
15
        "file_conflict": "12%",
7 collapsed lines
16
    },
17
    "over_10mb": {
18
        "rework_rate": "40%",
19
        "constraint_miss": "35%",
20
        "file_conflict": "25%",
21
    },
22
}

1
1セッションで複数施策:
2
  施策A設計 → 施策A実装 → 施策B設計 → 施策B実装 → ...
3
  → セッション肥大化、コンテキスト切れで施策Aの設計が消失
4

5
1セッション1施策:
6
  Session 1: 施策A設計
7
  Session 2: 施策A実装
8
  Session 3: 施策Aテスト・QA
9
  → 各セッションが小さく保たれる

1
CLAUDE.mdに書いた情報はセッションをまたいで保持される。
2

3
常に保持される情報:
4
  - ビルド・テスト手順
5
  - アーキテクチャの概要
6
  - 絶対に破ってはいけないルール
7
  - よくあるエラーと対処法
8

9
セッション固有の情報は.tmp/に退避:
10
  - 施策の設計ドキュメント
11
  - 中間的な意思決定の記録
12
  - WBSの進捗状態

1
# CLAUDE.mdの構造（概念的な表現）
2
persistent_memory = {
3
    "always_loaded": [
4
        "Quick Start",
5
        "Architecture Overview",
6
        "Critical Rules",
7
        "Module Reference Table",
8
    ],
9
    "session_specific": [
10
        ".tmp/design.md",      # 現在の施策の設計
11
        ".tmp/tasks.md",       # 現在のタスクリスト
12
        ".tmp/requirements.md", # 現在の要件定義
13
    ],
14
}

1
セッション終了前:
2
  /sc:save → 現在の進捗と未完了タスクを .tmp/ に保存
3

4
次セッション開始時:
5
  AIが .tmp/ の内容を読み込み
6
  → 前セッションの続きから再開できる

1
# .tmp/session_state.md（/sc:save の出力例）
2

3
## 完了タスク
4
- [x] config.py にパラメータ追加
5
- [x] engine.py で新パラメータを参照
6

7
## 未完了タスク
8
- [ ] test_engine.py のテスト追加
9
- [ ] CLAUDE_03_ARCHITECTURE.md 更新
10

11
## 重要な意思決定
12
- タイムアウトは60秒（30秒では不足、120秒ではブロッキング）
13
- リトライは3回まで（API制限との兼ね合い）

1
実用的な目安:
2
  2MB以下  → そのまま続行
3
  2-5MB   → 残りタスクを確認、必要なら次セッションへ
4
  5MB超え  → 現在のタスクを完了させて分割
5
  10MB超え → 即座に区切りをつけて分割

1
1回のコンテキスト切れで発生するコスト:
2
  - AIがファイルを再読み込み: 1-2分
3
  - 消失した制約による手戻り: 5-15分
4
  - 却下案の再議論: 3-5分
5
  - 合計: 10-20分のロス
6

7
219回 × 平均15分 = 約55時間のロス（108セッション通算）

1
1回のセッション分割で発生するコスト:
2
  - .tmp/への状態保存: 1分
3
  - 新セッションでの状態読み込み: 2分
4
  - コンテキスト再構築: 3分
5
  - 合計: 5-6分のコスト
6

7
適切な分割を行っていれば:
8
  219回 → 推定50回程度に削減可能
9
  50回 × 6分 = 5時間のコスト
10
  差し引き: 約50時間の節約