はじめに
Claude Code MAXを実務で毎日使い倒している現役CTO（ベンチャー10年）です。
最近、Qiitaで「Claude Codeが途中で議論を忘れる問題」が話題になっています。実際、長丁場のタスクや複雑な意思決定を伴う作業で、前半の議論が後半で消える 問題は現場でも頻発しています。
この記事では、自分が実務で運用している3つの対処パターンを紹介します。
なぜ Claude Code は議論を忘れるのか
直接的な原因は コンテキストウィンドウの限界 です。
Claude Code（Opus 4.7）の context window は1M tokenまで拡張されたとはいえ、
- 長時間セッションで context が溜まりすぎ
- compaction（自動圧縮）で議論の細部が落ちる
- ツール実行結果が context を圧迫
これらが組み合わさり、前半の合意事項や設計意図が薄まっていきます。
特に問題なのは、「忘れた」と Claude 自身が認識しないまま、別の方向で進めてしまう ことです。
パターン1: Checkpoint ファイルで意思決定を外部化する
最も簡単で効果が大きいのがこれです。
セッション中に重要な意思決定が出たら、ファイルに書き出す ことを CLAUDE.md でルール化します。
# CLAUDE.md（プロジェクト共通）
## 重要な意思決定の記録ルール
セッション中に以下の意思決定が出たら、即座に `.claude/checkpoints/YYYY-MM-DD.md` に追記する：
- 設計判断（A案 vs B案で A を選んだ等）
- アーキテクチャ変更
- ライブラリ選定
- ユーザー要件の変更
- 「やらないことリスト」への追加
.claude/checkpoints/ フォルダを Plan / Skills 経由で参照可能にしておくと、コンテキストが圧迫されても意思決定が消えなくなります。
.claude/
├── checkpoints/
│ ├── 2026-04-25.md # その日の意思決定ログ
│ └── 2026-04-26.md
└── CLAUDE.md
パターン2: 構造化引継ぎテンプレ
セッションが長引きそうな場合、自分は次の引継ぎテンプレを使います。
# Session Handoff: 2026-04-27
## 現在のゴール
（1文で）
## これまでの合意事項
- 採用した設計: ...
- 却下した案: ...
- 残課題: ...
## 次のセッションでやること
1. ...
2. ...
## 参照すべきファイル
- @.claude/checkpoints/2026-04-26.md
- @docs/architecture.md
## 触ってはいけない箇所
- ...
これを /clear 直前に書き出して、新セッションの最初に @Session Handoff: 2026-04-27 で読み込ませます。
新しい Claude セッションでも、重要な合意と禁止事項が明示的に渡るので、議論の齟齬がほぼゼロになります。
パターン3: Plan persistence（計画の永続化）
実装系のタスクで強力なのは、Plan を実行可能なファイルとして保存することです。
# .claude/plans/feature-auth.yaml
goal: ユーザー認証機能を Supabase で実装する
decisions:
- id: D1
statement: 認証は OAuth ではなくメール+パスワードで実装
rationale: MVP優先、OAuth は次フェーズ
- id: D2
statement: セッション管理は cookie ベース
rationale: SSR 対応のため
tasks:
- id: T1
title: Supabase Auth 初期化
status: completed
completed_at: 2026-04-26
- id: T2
title: ログインフォーム実装
status: in_progress
notes: バリデーションは zod を使用
- id: T3
title: セッション管理
status: pending
dependencies: [T1, T2]
セッションが切れても、このファイルを開けば どの判断でなぜ進めていたか / 次に何をすべきか が一目で分かります。
Claude Code に「この plan ファイルを読んで、続きから実装してください」と渡せば、議論を忘れていても元の文脈に復帰できます。
3つを組み合わせる運用
実務で安定するのは、3つすべてを使い分ける運用です。
| 状況 | 使うパターン |
|---|---|
| 重要な意思決定が出た瞬間 | Checkpoint に書く |
長丁場で /clear する直前 |
構造化引継ぎ を書く |
| 実装タスクが3日以上続く | Plan persistence を作る |
これらを CLAUDE.md と Skills でルール化しておくと、Claude 自身が 自発的に書き出してくれる ようになります。
まとめ
「Claude Code が議論を忘れる」問題は、
- 意思決定 → Checkpoint で外部化
- セッション切替時の文脈 → 構造化引継ぎテンプレで明示
- 長期タスクの状態 → Plan persistence で構造化
の3層で対処すると、長丁場のプロジェクトでも合意の崩壊が起きにくくなります。
ポイントは、「Claude に覚えさせる」のではなく「Claude が読める形でファイル側に残す」 こと。
モデルの記憶力に頼らず、外部記憶を設計する側に回る のが、AI エージェント時代の運用設計です。
この設計を実装した個人開発・実務サポートを MENTA でも提供しています → https://menta.work/plan/20251
Claude Code活用の発信は YouTube でも → https://www.youtube.com/channel/UC1rXVD9WYsQPQEWZyd-A1KA/