Chapter 4: コンテキストウィンドウ管理 ── 精度を維持する最重要スキル
Claude Codeを使い始めてしばらく経つと、ほぼ全員が同じ体験をする。セッションの序盤では的確な提案をしていたClaudeが、1時間後には的外れな修正を繰り返したり、「先ほど説明したルールに従ってください」と伝えても無視されたりする。これはClaudeの「気まぐれ」ではない。コンテキストウィンドウが限界に近づいているサインだ。
コンテキストウィンドウの管理を理解しているかどうかで、Claude Codeの実用性は劇的に変わる。これは単なるテクニックではなく、AIとの長時間の協働において精度を維持するための根本的なスキルだ。
コンテキストウィンドウとは何か
コンテキストウィンドウは、Claude Codeの「作業メモリ」だと考えると分かりやすい。人間が作業中に頭の中に保持できる情報量には限りがあるように、Claude Codeがある時点で「見えている」情報には上限がある。
重要なのは、このメモリに何が含まれるかだ。会話の履歴、読み込んだファイルの内容、実行したコマンドの出力、ツール呼び出しの結果、CLAUDE.mdの内容——これらすべてがコンテキストウィンドウという一つの器に収まっている。
graph TB
subgraph CW["コンテキストウィンドウ (200k トークン)"]
direction TB
A["🗨️ 会話履歴<br/>（プロンプトと応答の全文）"]
B["📄 読み込んだファイル<br/>（@参照・自律読み込み）"]
C["⚙️ コマンド出力<br/>（npm install, git log 等）"]
D["🔧 ツール呼び出し結果<br/>（MCPツールの応答）"]
E["📋 CLAUDE.md<br/>（システムプロンプト）"]
end
style CW fill:#1a1a2e,color:#eee,stroke:#4A90D9,stroke-width:2px
style A fill:#2d4a8a,color:#fff
style B fill:#2d4a8a,color:#fff
style C fill:#2d4a8a,color:#fff
style D fill:#2d4a8a,color:#fff
style E fill:#4a2d8a,color:#fffClaude Codeが採用するモデルのコンテキストウィンドウは200,000トークンだ。英語で約150,000語、日本語では文字数にしておよそ10万文字に相当する巨大な容量に見えるが、実際の開発セッションでは驚くほど速く埋まっていく。
コンテキストが埋まると何が起きるか
コンテキストウィンドウが飽和状態に近づくと、三つの問題が顕在化する。
1. 重要なルールが埋もれる。 セッション開始時に「テストは必ずmockを使わずに書いてください」と伝えていても、数百回のやり取りの後では、その指示が遠い過去として「希薄化」される。LLMは文脈の中で重要なものとそうでないものを暗黙的に重み付けするが、距離が遠いものほど影響力が弱まる傾向がある。
2. 指示が無視される。 厳密には「無視」ではなく、膨大なトークンの海の中で指示が相対的に目立たなくなる。特に矛盾する情報が多数存在する場合（複数の設計方針、修正の試行錯誤の残骸など）、Claudeは「最もらしい」応答をするが、それが意図と一致しなくなる。
3. 精度が全体的に落ちる。 関連性の低い情報が大量にあると、それがノイズとなって推論の精度を下げる。シンプルな質問への回答が妙に複雑になったり、コードの変更が意図せず関連性のない箇所に波及したりする。
コンテキストを消費するもの（消費量ランキング）
コンテキストの消費源を把握することは、管理の第一歩だ。消費量が大きい順に見ていこう。
1位：長い会話履歴（特に失敗した修正ループ）
最大の消費源は会話履歴そのものだ。特に破壊的なのは「失敗した修正のループ」だ。「これを直して→直っていない→もう一度→まだ違う→戻して」という試行錯誤の履歴が積み重なると、正しい文脈の何倍ものトークンが「失敗の記録」で占有される。そしてClaudeは過去の失敗パターンを参照しながら新しい提案を生成するため、悪循環に陥ることがある。
2位：大きなファイルの全読み込み
10,000行のファイルを丸ごと読み込むと、それだけで数万トークンを消費する。多くの場合、実際に必要なのはファイルの一部分だけだ。「関連する部分だけを参照する」という意識が重要になる。
3位：コマンドの大量出力
# 悪い例：大量の出力をそのままコンテキストに流す
npm install # node_modulesのインストールログが数千行
git log # デフォルトでは全履歴が出力される
docker build # ビルドログ全体これらのコマンド出力は膨大なテキストを生成する。npm install のログ、git log --all の全履歴、docker build の詳細ログは、それぞれ数千行に及ぶことがある。
4位：未使用MCPツールの一括ロード
MCPツールはそのスキーマ定義がコンテキストに含まれる。使用しないツールを大量にロードしていると、ツール定義だけで数千トークンが消費される。プロジェクトの性質に応じて必要なMCPツールのみを有効化する設定が重要だ。
コンテキスト管理の実践コマンド
Claude Codeは三つの基本的なコンテキスト管理コマンドを提供している。
/clear → 会話履歴を完全リセット（最もドラスティックな選択）
/compact → 重要情報を保持しつつ圧縮（バランス型）
@filename → 特定ファイルだけを参照（精密型）/clear は核オプションだ。会話履歴がゼロになるため、「ここまでの文脈を引き継いでほしい」場合には使えない。しかし別タスクに移るとき、あるいは会話が完全に迷走しているときは最善の選択だ。
/compact はより穏やかなアプローチだ。会話履歴をClaudeが要約し、重要な決定事項・実装済みの変更・未解決の問題などを保持しながらトークン数を削減する。長時間のセッションで「文脈は維持したいが容量は節約したい」という場面に適している。
@filename は精密なコンテキスト制御の要だ。「プロジェクト全体を把握して」という指示ではなく「このファイルのこの部分を参照して」と絞り込むことで、不要なファイルの読み込みを避けられる。
「いつ /clear するか」の判断基準
/clear のタイミングを体系化すると、以下のチェックリストが実用的だ。
即座に /clear すべき状況：
- 別のタスクや機能に移るとき（前のコンテキストは百害あって一利なし）
- Claudeが同じ誤りを2回以上繰り返したとき（コンテキスト汚染のサイン）
- 「さっきの指示を忘れたかのような」返答が続くとき
/compact を検討すべき状況：
- セッションが30分以上継続しているとき
- 会話のターン数が20回を超えたとき
- コマンド出力を多数受け取った後
@参照に切り替えるタイミング：
- 「大きなファイルを見て」という自然な流れになったとき
- Claude自身が「〜のファイル全体を確認します」と言い始めたとき（過剰な読み込みの前兆）
経験則として「セッションが進んでいて、Claudeの返答の質に少し違和感を覚えたら、それはコンテキストの問題かもしれない」と疑うクセをつけることが大切だ。
CLAUDE.mdのコンテキスト効率化
CLAUDE.mdはセッション開始時にシステムプロンプトとして読み込まれる特別なファイルだ。ここに記述するルールの「どこに書くか」が、思った以上に効果に影響する。
認知科学には「初頭効果（Primacy Effect）」と「新近効果（Recency Effect）」という概念がある。初頭効果は最初に見た情報が記憶に残りやすいという現象で、新近効果は最後に見た情報が処理されやすいという現象だ。LLMの処理においても類似の傾向が観察されており、これを「プロンプトの初頭・新近バイアス」と呼ぶことがある。
graph LR
subgraph CLAUDE.md
TOP["🔴 先頭部分<br/>（初頭効果：最も強く影響）<br/>──────────────<br/>最重要ルール<br/>よく違反されるルール"]
MID["⚪ 中間部分<br/>（影響は中程度）<br/>──────────────<br/>一般的なスタイルガイド<br/>ツール設定・参考情報"]
BTM["🔵 末尾部分<br/>（新近効果：処理直前に参照）<br/>──────────────<br/>重要ルールの再掲<br/>チェックリスト・禁止事項"]
end
TOP --> MID --> BTM
style TOP fill:#8B0000,color:#fff
style MID fill:#444,color:#fff
style BTM fill:#00008B,color:#fffこの特性を活用したCLAUDE.mdの設計原則は明確だ。最もよく違反されるルールを先頭と末尾に配置する。 たとえば「テストファイルを変更する前に必ず確認を求めること」というルールは、中間部分に一度書くだけでなく、ファイルの冒頭でも末尾でも言及する。
実際のCLAUDE.mdでの例：
<!-- 先頭部分 -->
# 重要ルール（必ず遵守）
- **テストファイルの変更前には必ず確認を求めること**
- 本番DBへの直接変更は禁止
- コミット前にlintを実行すること
<!-- 中間部分 -->
## コーディングスタイル
（通常のスタイルガイド...）
## アーキテクチャ方針
（設計方針...）
<!-- 末尾部分（先頭の重要ルールを繰り返す） -->
---
## 作業前チェックリスト
- [ ] テストファイルを変更する場合、ユーザーに確認したか？
- [ ] 本番環境への変更でないか？
- [ ] lintエラーはないか？この配置戦略により、セッションが長くなって「中間部分」が埋もれても、最重要ルールは先頭と末尾で「フレーム」として機能し続ける。
@参照 vs フルファイル読み込みの使い分け
「どのファイルをどう読ませるか」はコンテキスト節約の実践的なテクニックだ。
@参照が適切なケース：
# 特定クラスの実装を参照させたいとき
「@src/services/PaymentService.ts を参照して、
handleRefund メソッドのロジックを説明してください」
# 設定ファイルの確認
「@package.json を確認して、現在のReactのバージョンを教えてください」@参照では、指定したファイルのみがコンテキストに追加される。Claudeが「関連するかもしれない」と判断した他のファイルまで読み込む自律的な動作を抑制できる。
フルファイル読み込みを許可すべきケース：
逆に、Claudeが自律的に複数ファイルを読み込む動作を許可した方が良い場面もある。「このバグの原因を調査して」というタスクでは、Claudeが呼び出しチェーンを辿りながら関連ファイルを読む動作が正しい。ここで過度に参照ファイルを制限すると、根本原因に辿り着けないことがある。
ルールとしては：「答えの場所が分かっているとき」は@参照、「どこに問題があるか分からないとき」はClaudeの自律探索を信頼する、というバランスが実用的だ。
コンテキスト管理チートシート
┌─────────────────────────────────────────────────────┐
│ コンテキスト管理 クイックリファレンス │
├─────────────────────────────────────────────────────┤
│ │
│ 現象 → 対処法 │
│ ───────────────────────────────────────────────── │
│ 別タスクに移る → /clear │
│ 同じ失敗を2回繰り返した → /clear │
│ 文脈は維持したい → /compact │
│ セッション30分超 → /compact │
│ 特定ファイルだけ参照 → @filename │
│ │
│ CLAUDE.md 配置ルール │
│ ───────────────────────────────────────────────── │
│ 先頭 → 最重要ルール・よく違反されるルール │
│ 中間 → 一般的なスタイルガイド・設定 │
│ 末尾 → 重要ルールの再掲・チェックリスト │
│ │
│ @参照 vs 自律探索 │
│ ───────────────────────────────────────────────── │
│ 場所が分かる → @src/path/to/file.ts │
│ 調査が必要 → Claudeの自律読み込みを許可 │
│ │
│ コンテキスト消費量（大→小） │
│ ───────────────────────────────────────────────── │
│ 1. 失敗した修正ループの累積履歴 │
│ 2. 大きなファイルの全読み込み │
│ 3. npm install / git log 等の大量出力 │
│ 4. 未使用MCPツールの一括ロード │
│ │
└─────────────────────────────────────────────────────┘コンテキストウィンドウの管理は、慣れるまでは意識的に行う必要があるが、やがて自然な習慣になる。「そろそろ/compactする頃かな」という感覚が身についたとき、Claude Codeとの協働は新しいレベルに達する。限られたリソースを賢く使うこの技術は、AIと長時間作業する上での根本的なリテラシーだ。
次章では、Claude Codeをチームに導入する際の組織的な課題と解決策、そしてガバナンスの設計について扱う。