Claude Codeのコンテキストとは？ トークン節約方法とセッション管理を徹底解説
Claude Code のコンテキストウィンドウが何か、なぜセッションごとに文脈が失われるのかを原理から解説。CLAUDE.md・仕様書チェックリスト・引き継ぎメモ・git 運用の4つの手動対策と、MCP ベースの自動化手法を体系的に整理します。
この記事で分かること
Claude Code をはじめとする AI コーディングアシスタント (Cursor、GitHub Copilot など) は、新しいセッションを開くと前回までの文脈を失う。昨日「この設計でいこう」と決めたのに、今朝セッションを開くとAIが何も覚えていない。毎回同じプロジェクトの説明をやり直すことになる。
本記事では、Claude Code のコンテキストウィンドウの仕組みを原理から解説した上で、コンテキストを節約し、セッションをまたいで作業を積み上げる4つの手動対策とMCP ベースの自動化手法を体系的に整理する。「どの対策がどの原因を塞ぐのか」まで踏み込むことで、新しいツールが出てきたときに自分で評価できるようにする。
Claude Code のコンテキストウィンドウとは
LLM (大規模言語モデル) の推論には状態がない。Claude Code のチャットが「会話」に見えるのは、過去のやり取り全文がリクエストのたびにモデルへ入力されているからである（実際の API 通信ではプロンプトキャッシュにより変更のないプレフィックス部分の転送は省略されるが、モデルが全文を読んで処理する点は同じ）。
[リクエスト1] system + CLAUDE.md + あなたの発言1
[リクエスト2] system + CLAUDE.md + 発言1 + 応答1 + 発言2
[リクエスト3] system + CLAUDE.md + 発言1 + 応答1 + 発言2 + 応答2 + 発言3
...
モデルが一度に読める量の上限が「コンテキストウィンドウ」である。Claude Code ではモデルにより 200K〜1M トークン（日本語で約15万〜75万字）が上限となる。会話が長くなると古いやり取りが自動圧縮され、セッションを閉じれば履歴そのものが次のリクエストに含まれなくなる。
つまりコンテキストを節約する = コンテキストウィンドウの枠をなるべく本来の作業に使えるようにすることである。
文脈が失われる5つの構造的原因
コンテキスト喪失は以下の5要因に分解できる。
| # | 原因 | 内容 |
|---|---|---|
| 1 | モデル重みの固定 | 学習済みモデルは個々のプロジェクトを知らない |
| 2 | ステートレスな推論 | 会話履歴はリクエストごとにモデルへ入力され、サーバー側に保持されない |
| 3 | コンテキストウィンドウの上限 | 一度に読める量に上限があり、古い内容から消える |
| 4 | 永続ストレージの欠如 | セッション終了で会話履歴が次の推論に含まれなくなる |
| 5 | 検索と理解の分離 | コード検索インデックスは残っても、判断の文脈は残らない |
すべての対策は「次のリクエストに必要な情報を再注入する仕組み」に帰着する。この視点を持つと、個々の手法やツールを統一的に評価できる。
原因と対策の対応表
| # | 構造的原因 | 効く対策 |
|---|---|---|
| 1 | モデル重みは学習後固定 (あなたのPJを知らない) | コンテキストファイル (CLAUDE.md 等) |
| 2 | 推論はステートレス (会話履歴を毎回まるごとモデルに入力) | 引き継ぎメモ / セッション永続化ツール |
| 3 | コンテキストウィンドウ溢れ (古い発言から消える) | 情報の絞り込み (「判断の結論」だけ残す) |
| 4 | 永続ストレージの欠如 (セッション終了で消滅) | ファイルへの書き出し (git / メモ / ツール) |
| 5 | 検索インデックスと「理解」の分離 | 構造化された状態ファイル |
手法1: CLAUDE.md (コンテキストファイル) — 原因1を塞ぐ
概要
セッション開始時に自動で読み込まれるファイルに、プロジェクトの「変わりにくい情報」を記述する手法。原因1 (モデルはプロジェクトを知らない) を直接塞ぐ。
Claude Code なら CLAUDE.md、汎用仕様の AGENTS.md、Cursor なら .cursorrules、GitHub Copilot なら .github/copilot-instructions.md をプロジェクトのルートに置く。AIはセッション開始時にこのファイルを自動で読み込む。
コンテキスト節約効果
CLAUDE.md がない場合、Claude Code はセッション開始のたびにプロジェクト構成を自力で探索する。ファイルを片っ端から読み、依存関係を調べ、設定ファイルを解析する。この探索だけでコンテキストウィンドウの一定割合を消費する。
CLAUDE.md がある場合、Claude Code はプロジェクトの前提を最初から把握した状態で作業を開始する。探索にコンテキストを消費せず、本来の作業に割り当てられる。
記述内容
最初は使っている技術の一覧 (技術スタック) だけで十分である。
// filename: CLAUDE.md
# 家計簿アプリ
## プロジェクト概要
個人開発の家計簿アプリ。Next.js + Supabase。
## 技術スタック
- フロント: Next.js 14 (App Router)
- DB: Supabase (PostgreSQL)
- 認証: Supabase Auth
- デプロイ: Vercel
## コーディング規約
- コンポーネントは関数コンポーネントのみ
- スタイリングは Tailwind CSS
- テストは Vitest + Testing Library
## 現在の状態
- 基本的なデータの追加・表示・編集・削除は完成
- 認証機能を実装中
- カテゴリ別の集計機能は未着手
AIに同じことを2回以上説明した場合、それは CLAUDE.md に書くべき内容である。説明直後に「今の説明を CLAUDE.md に追記して」とAIに伝えれば、自分で書く手間はかからない。
アンチパターンと対策
| アンチパターン | 症状 | 原因 | 対策 |
|---|---|---|---|
| コンテキストファイルの肥大化 | AIの応答精度が下がる、長い会話で古い指示が無視される | 変更履歴やタスクリストなど全てを1ファイルに書き込み、200行を超過 | 4セクション (概要・スタック・規約・現状) で50行以内に抑える。変わりやすい情報は手法2・3に分離する |
| 陳腐化した情報の放置 | AIが古い前提 (廃止済みのAPI、変更済みの規約) で作業する | 「今日のタスク」のような変わりやすい情報を書いたまま更新しない | 変わりにくい情報のみを記載する。更新頻度が週1回を超える情報は別ファイルに管理する |
| ファイル名の誤り | AIがセッション開始時にファイルを読み込まない | Claude Code は CLAUDE.md (大文字)、Cursor は .cursorrules (ドット始まり) など、ツールごとに固有の命名規則がある | 各ツールのドキュメントで正確なファイル名を確認する |
なぜ効くのか — Claude Code 内部の仕組み
CLAUDE.md はセッション開始時にプロンプトに自動注入される。Claude Code は起動時にホームディレクトリの ~/.claude/CLAUDE.md（全プロジェクト共通設定）→ プロジェクトルートの CLAUDE.md → .claude/ 配下のプロジェクト設定の順に読み込み、システムプロンプトに結合する。毎回のリクエストにプロジェクトの基本情報が含まれた状態で推論が始まるため、AIが自力で調査する必要がなくなる。
限界
プロジェクトの前提は伝わるが、「昨日どこまで進んだか」「なぜこの設計にしたか」のような日々の判断の積み重ねは伝えられない。CLAUDE.md は「変わらない情報」に適しており、「毎日変わる情報」には別の手法が必要になる。
手法2: 仕様書と進捗チェックリスト — 原因4を塞ぐ
概要
プロジェクトの機能を仕様書として書き出し、各項目にチェックをつけていく手法。セッションをまたいで「どこまで終わったか」を正確に伝えることができる。
コンテキスト節約効果
仕様書がない場合、セッション再開時に Claude Code はプロジェクトの状態を自力で調査する。コード上に現れない情報 — 検討して却下した案、次に着手する予定だった機能 — は復元できない。
チェックリスト付きの仕様書がある場合、Claude Code に「SPEC.md を読んで、未完了の項目から再開して」と伝えるだけで正確に再開できる。
記述内容
全機能を網羅する必要はない。「次にやりたいこと」を3つ書けば開始できる。
// filename: SPEC.md
# 家計簿アプリ 機能仕様書
## 認証
- [x] ログイン
- [x] パスワードリセット
- メール送信は Resend を使用 (SendGrid より API がシンプルだった)
- トークン有効期限は1時間に設定
- [ ] ソーシャルログイン (Google)
## 支出記録
- [x] 手動入力
- [x] カテゴリ選択
- [ ] レシート自動入力
## 集計
- [ ] カテゴリ別の月次集計
作業完了のたびに「SPEC.md のチェックを更新して」とClaude Code に伝えれば、チェックリストの更新もAIに委譲できる。
アンチパターンと対策
| アンチパターン | 症状 | 原因 | 対策 |
|---|---|---|---|
| 仕様書とコードの乖離 | AIが古い前提で作業する (完了済みの項目を未着手と認識する等) | 仕様書のチェックを更新しないまま数日が経過し、実際のコードと不整合が生じる | 作業完了のたびにAIにチェック更新を指示する。更新を忘れた場合は次のセッション冒頭で同期する |
| 粒度の不統一 | 進捗が実態と合わない (大項目1つ完了で50%に見えるが実質は10%) | 「認証機能を実装する」のような大項目と「ボタンの色を変える」のような小項目が混在 | 「1時間以内に完了する」程度の粒度に統一する |
| 判断理由の欠落 | 「何をやったか」は分かるが「なぜそうしたか」が追跡できない | チェックのON/OFFだけで、設計判断のメモを付記しない | 各項目の下に採用理由・却下した代替案を1行ずつ記録する |
なぜ効くのか
チェックリストは「何が完了して何が未着手か」を外部ファイルに書き出す仕組みである。原因4 (セッション終了で進捗が消える) を、ファイルシステム上の永続化された状態として塞ぐ。
限界
仕様書の作成と更新に手間がかかる。また、仕様書に書ききれない「検討したが却下した案」のような暗黙知は抜け落ちやすい。
手法3: セッション終了時の引き継ぎメモ — 原因2・4を塞ぐ
概要
セッションの最後に「今日やったこと」「次にやること」「判断したこと」をメモに残す手法。手法1 (CLAUDE.md) がプロジェクト全体の「変わらない情報」を渡すファイルなら、手法3は「今日のセッションで変わったこと」を渡すファイルである。
コンテキスト節約効果
引き継ぎメモがない場合、Claude Code はコードを読んで「何があるか」は把握できるが、「なぜその実装を選んだか」「テスト用モックはどこまで完成しているか」はコードに書かれていない。間が空くほど人間自身もこれらを忘れる。
引き継ぎメモがある場合、前回の判断の結論・注意事項・次のアクションが構造化されたファイルとして残り、次のセッション冒頭で読み込むだけで文脈を復元できる。
記述内容
セッションの最後にClaude Code に「引き継ぎメモを書いて」と伝えれば生成される。フォーマットは4セクション構成が推奨される。
// filename: docs/handoff/2026-07-17.md
# 引き継ぎメモ 2026-07-17
## 今日やったこと
- 認証機能のパスワードリセットを実装
- メール送信には Resend を使用 (SendGrid と比較して API がシンプルだった)
## 決めたこと
- パスワードリセットのトークン有効期限は 1時間に設定
- リセットメールのテンプレートは react-email で作成
## 次にやること
- ソーシャルログイン (Google OAuth) の実装
- Supabase Auth の Google Provider 設定から始める
## 詰まったこと / 注意点
- Resend の無料枠は月 100通。開発中のテストで消費しないよう、
開発環境では console.log に出力するモックに切り替え済み
次のセッション開始時は docs/handoff/2026-07-17.md を読んでから作業を始めて と伝える。
アンチパターンと対策
引き継ぎメモは書き出しタイミングを誤ると、最も重要な情報が失われるリスクがある。特に「セッション末尾に一括で書く」運用では、セッションが途中で終了した場合に何も残らない。
| アンチパターン | 症状 | 原因 | 対策 |
|---|---|---|---|
| 引き継ぎメモの形骸化 | メモは存在するが次のセッションで読まれない、または読んでも文脈が復元できない | 会話ログをそのまま貼り付けている (判断が構造化されていない) | 「判断の結論」のみを記録する。「Resend を使った」ではなく「Resend を採用 — 理由: SendGrid より API がシンプル」のように判断と根拠をセットで記述する |
| 書き忘れ | 翌日のセッションで文脈がリセットされ、同じ説明を繰り返す | 作業に集中してセッション終了時に書く余裕がない | セッション開始時に「最後にメモを書いて」と先にAIに伝えておく。または作業の節目ごとに書き出す |
| 保存場所の散逸 | 次のセッションでAIがメモファイルを発見できない | プロジェクトルートやデスクトップなど、場所が統一されていない | docs/handoff/ のようなディレクトリを固定し、日付ファイル名 (YYYY-MM-DD.md) で統一する |
なぜ効くのか
引き継ぎメモは原因2 (ステートレスな推論) と原因4 (永続ストレージの欠如) を同時に塞ぐ。ステートレスな推論に対して、外部ファイル経由で状態を持ち回る仕組みである。
会話の全文ではなく「判断の結論」だけを残すのが要点である。全文を再注入するとコンテキストウィンドウ (原因3) をすぐに消費する。記録すべきは「なぜそうしたか」と「次に何をするか」に絞る。
限界
3つの壁がある。(1) 書き忘れる。(2) 何を書けばいいか判断しにくい。(3) 毎セッション「このファイルを読んで」と伝える手間がある。これらは手法5 (自動化ツール) で解決される。
手法4: git のコミットメッセージとブランチ戦略 — 原因4の補完
概要
git を使っているなら、コミットメッセージに「なぜ」を書くだけでClaude Code への文脈の渡し方が大きく変わる。git log がそのまま Claude Code が読める判断履歴になる。
アンチパターン → 推奨パターン
| 観点 | アンチパターン | 推奨パターン |
|---|---|---|
| コミットメッセージ | fix bug / update / WIP | fix: 期限切れトークンで500エラー — UTC/JST比較の不一致を修正 |
| コミット粒度 | 1コミットに100ファイル変更 | 「1つの判断 = 1つのコミット」 |
| ブランチ運用 | main のみ、WIP ブランチが放置される | 機能単位でブランチを切り、完了後にマージ。WIP は翌日に再開か削除 |
具体的な記述例:
❌ fix bug
❌ update auth
✅ fix: パスワードリセットで期限切れトークンを使うと500エラーになる問題を修正
- 原因: token_expires_at のタイムゾーンが UTC で保存されているのに
JST で比較していた
- 対処: 比較時に UTC に統一
ブランチ名をタスクの進捗表として活用する:
main
├── feat/auth-password-reset ← 完了、マージ済み
├── feat/auth-social-login ← 作業中
└── feat/analytics-monthly ← 次に着手予定
なぜ効くのか
セッション開始時に git status と git log --oneline -10 を Claude Code に読ませるだけで、コード変更の経緯をかなりの精度で復元できる。git に記録された変更履歴は外部の永続ストレージとして機能し、原因4を補完する。
限界
git に残るのはコードの変更履歴のみである。「来週やるべきこと」「この機能を後回しにした理由」のような、コードに直接現れないプロジェクト運営の判断は残らない。手法2・3との併用で穴が埋まる。
手法5: MCP ツールによるセッション永続化 — 手動運用の壁を越える
概要
手法2〜4で手動で行っていた「進捗の記録」「判断の記録」「引き継ぎメモ」を自動化する手法。MCP (Model Context Protocol = AIが外部ツールを呼び出すための共通規格) を利用して、セッションの引き継ぎを丸ごと自動化するツールが登場している。
手動との構造的な違い
手動の引き継ぎでは、セッション終了時に「メモを書いて」、翌日に「このファイルを読んで」と毎回伝える必要がある。自動化ツールは、この「書き出し」と「読み込み」の両方をAI自身が実行する。
手動運用で発生する3つの壁 — (1) 書き忘れ、(2) 何を書くかの判断、(3) 読み込みの手間 — が構造的に解消される。
代表的なツール
Claude Code のビルトイン機能 (--continue)
claude --continue で前回のセッションを引き継げる (2026年7月時点)。直前の会話ログをそのまま復元する仕組みで、短いセッションには有効だが、会話全文を復元するため長いセッションではコンテキストウィンドウの上限に達する。
handoff-mcp (v0.24.9)
handoff-mcp は筆者 (AlphaElements) が開発するオープンソースツールである。以下は設計思想と機能の事実記述であり、他ツールとの優劣比較ではない。
手法3の引き継ぎメモ + 手法2のチェックリストを自動化した MCP サーバー。会話の全文ではなく「判断の結論」「タスクの進捗」「次にやること」だけを .handoff/ ディレクトリに構造化データとして保存する。クラウド不要、データはローカルのテキストファイルに完結する。
「プロジェクトの記憶」機能により、過去の判断の経緯がキーワード検知で自動的にAIの文脈に注入される。
VSCode拡張 (handoff-vscode v0.9.0) を導入すると、タスク一覧・セッション履歴・進捗率をGUIで確認できる。
Cline Memory Bank / Roo Code Memory Bank
Cline / Roo Code 向けのメモリ管理ツール。プロジェクトの技術スタック・現在の状態・進行中のタスクを構造化して保存する。CLAUDE.md を自動更新するイメージに近い。
ツール選定の軸
| ツール | 残す情報 | 特徴 | 開発元 |
|---|---|---|---|
claude --continue | 会話全文 | 手軽だが長いセッションでウィンドウ溢れ | Anthropic |
| handoff-mcp | 判断の結論 + タスク進捗 | ローカルファイル完結、構造化データ | AlphaElements (本サイト運営) |
| Cline Memory Bank | プロジェクト状態スナップショット | CLAUDE.md 自動更新に近い | Cline コミュニティ |
選定で見るべき軸は「何を残す設計か」である。原因3 (コンテキストウィンドウ溢れ) をどう扱うかの設計思想の違いがそのまま製品の違いになっている。
アンチパターンと対策
| アンチパターン | 症状 | 原因 | 対策 |
|---|---|---|---|
| ツールへの過信 | ツールを入れたが何が自動化されているか把握できていない | 手法2〜4の手動運用を経験せずに自動化ツールを導入 | 手法1〜3を手動で試してから自動化を導入する |
| 設計思想の不一致 | ツールが残す情報と自分が必要とする情報にギャップがある | ツールの「何を残すか」を確認せずに導入 | 上記の比較表で設計思想を確認し、ワークフローに合ったツールを選定する |
いずれのツールでも、書き出しは「セッションの最後に一括」ではなく作業の節目ごとに行うのが重要である。セッションが途中で終了した場合、末尾一括方式では何も残らない。
手法の比較と導入順序
| 手法 | 塞ぐ原因 | 得意なこと | 手間 |
|---|---|---|---|
| 1. CLAUDE.md | 1 | プロジェクト前提の伝達 | 低 (一度書けば済む) |
| 2. 仕様書 + チェックリスト | 4 | 進捗の把握 | 中 (初期作成の手間) |
| 3. 引き継ぎメモ | 2, 4 | 日々の判断の記録 | 高 (毎セッション) |
| 4. git 活用 | 4 | コード変更の経緯と判断理由 | 低 (既存ワークフローの延長) |
| 5. MCP 永続化ツール | 2, 3, 4 | 手法2〜4の自動化 | 低 (初期設定のみ) |
推奨する導入順序
即日 (10分):
- プロジェクトのルートに
CLAUDE.mdを作成し、技術スタックを記述する - 以降のコミットから「なぜそうしたか」をコミットメッセージに記述する
1週間以内:
- セッション終了時にClaude Code に引き継ぎメモの作成を指示する
- プロジェクトの主要機能を
SPEC.mdにチェックリストとして書き出す
手動運用が定着した後:
- MCP ベースの永続化ツールを導入する
CLAUDE.md (手法1) と引き継ぎメモ (手法3) だけでも、翌朝の Claude Code とのセッション開始時の効率が大きく変わる。手動の手法で「何を残すべきか」の感覚を掴んでからツールを導入する方が、ツールの挙動を理解して活用できる。
まとめ
Claude Code の「作業が積み上がらない」問題は、ステートレスな推論という構造に起因する。モデルの進化を待つのではなく、コンテキストの再注入を設計することで解決できる。
対策はすべて「次のリクエストに何を再注入するか」の設計である。この視点を持てば、新しいツールが出てきたときに対応表のどの穴を塞ぐものか自分で評価できる。