Claude Codeのコンテキストエンジニアリング——「何を入れるか」より「何を入れないか」が品質を決める

はじめに

「長いセッションになると精度が落ちる」「2時間前に決めたことをClaudeが忘れている」——これはClaudeの能力が下がったのではなく、コンテキストが汚染・肥大化したシグナルだ。

1Mトークンのコンテキストウィンドウが2026年3月にGA（一般提供）された。「もうコンテキスト管理は不要では？」と思うかもしれないが、実態は異なる。「大きなコンテキストウィンドウ = 何でも詰め込める」は誤解だ。

コンテキストには「注意力の予算（Attention Budget）」がある。不要な情報を入れるほど、重要な情報への注意力が相対的に低下する。「全部入れておけば安心」というアプローチが逆に品質を下げる。コンテキストエンジニアリングとは「何を入れ、何を入れないかを設計する技術」だ。

Attention Budgetとコンテキスト劣化のメカニズム

コンテキストウィンドウの全トークンが等しく有効なわけではない。アテンション機構の特性上、コンテキストの中間部分に置かれた情報は先頭・末尾に比べて注意が薄くなる（lost-in-the-middle問題）。

Claude Opus 4.6は業界例外的に高い長文精度を持つが、それでも「200K全てが均等に機能する」わけではない。

長時間セッションでは「Context Rot（コンテキスト劣化）」が発生する。経験がある人には見覚えのある症状ばかりだ。

• 記憶喪失：以前の決定（「このライブラリは使わない」等）を忘れて矛盾する提案をしてくる
• 再質問：すでに答えた質問を再度聞いてくる
• 矛盾実装：前のコードと整合しない実装を提案してくる

Anthropicは「コンテキストウィンドウに入れる情報には注意力の予算がある。不要な情報を追加するたびに、重要な情報への注意力が相対的に低下する」（「Effective context engineering for AI agents」）と説明している。CLAUDE.mdに「念のため」で設定を詰め込まない、関係ないファイルをコンテキストにロードしない、使っていないMCPサーバーを有効化しっぱなしにしない——この原則が日常的な実践になる。

/context と /compact で状態を把握・管理する

/context コマンドでコンテキストの現在の使用率と、MCPサーバーが何トークン消費しているかを確認できる。これを定期的に確認することが管理の出発点だ。

/compact に関して最もよくある間違いは「95%になるまで待ってから使う」ことだ。正しいタイミングは60%前後の先手を打つ使い方だ。

/compact                               # 会話履歴を要約・圧縮
/compact "進行中のバグ修正の詳細を保持して"  # フォーカス指定で圧縮

自動圧縮は約83.5%（200Kウィンドウなら約167K）に達したときに発動する。この時点ではすでにContext Rotが始まっている可能性が高い。

CLAUDE.mdにcompact時の保持情報を指定しておくと、圧縮後も重要な情報が残る。

## Compaction指示
コンテキスト圧縮時は以下を必ず保持すること：
変更済みファイルの完全なリスト
テスト実行コマンド
今回のセッションで決定したアーキテクチャの方針

コンテキストエンジニアリング4つの基本戦略

Anthropicが提唱する4つの戦略（Write・Select・Compress・Isolate）を順に見ていく。

① Write（書き込む）——重要情報をファイルに退避

コンテキストから外に出して保存することで、compactされても情報が残る。「今日の設計決定をdecisions.mdにまとめて保存して」という指示で決定事項を外部化する。CLAUDE.mdは自動compact後も保持される唯一の情報源のため、重要な設定・方針はここに書く。

② Select（選択する）——必要な情報だけをコンテキストに入れる

# 特定ファイルのみをコンテキストに含める
@src/auth.ts の認証ロジックを見直してください
# 関連ファイルだけ読む
「この機能に関係するファイルを特定してから、そのファイルだけ読んで」

「念のためcodebase全体を読む」は注意力予算の無駄遣いだ。必要なファイルを絞って渡す。

③ Compress（圧縮する）——戦略的なタイミングでcompact

マイルストーン達成後、方向転換時、実装フェーズ移行時など「区切り」のタイミングでcompactするのが効果的だ。ランダムなタイミングで圧縮するより、重要な情報を「その時点での要約」として残せる。

④ Isolate（分離する）——サブエージェントでコンテキストを守る

コードベース探索や調査系タスクをサブエージェントに委譲することで、メインセッションのコンテキストを保護する。

「このコードベースの認証パターンを調査して要約だけ返して。
 詳細は自分でコンテキストに持つ必要はない」

サブエージェントは独立したコンテキストウィンドウで動作するため、調査中に膨大なファイルを読んでもメインセッションには影響しない。

CLAUDE.mdのコンテキスト管理設計

CLAUDE.mdは自動compact後も保持される唯一の情報源だが、同時にコンテキストウィンドウに常駐するコストがある。CLAUDE.mdの全般的な設計・活用方法は「CLAUDE.mdとフィードバックループ」記事を参照いただくとして、ここではコンテキスト管理の観点に絞る。

# 悪い例（コンテキストを圧迫）
技術スタックの詳細（30行）
全APIエンドポイントの説明（50行）
→ これら全てがセッション内に常駐し、Attention Budgetを消費し続ける
# 良い例（最小限＋オンデマンドロード）
# プロジェクト概要（3行以内）
詳細は @docs/architecture.md を参照。
技術詳細: /use tech-context  ← 必要な時だけロード

Claude Codeが「コンテキスト系の質問」（情報不足による質問）をする際、その直前のツール呼び出しは全てReadであることが多い。ファイルを読んだが必要な情報がなかったため質問が発生しているため、CLAUDE.mdに事前記載することで中断を防げる。記載すべき情報を最小限に絞るなら、プロジェクト方針と技術選定の理由、使用中の外部サービス、意思決定の前例とその理由だ。

ビフォーアフター

Before（コンテキスト管理なし）

3時間のセッションで2時間を過ぎたころから症状が出始める。「以前決めたDB設計と違う実装を提案してくる」「さっき答えた質問をまた聞いてくる」。「今日のClaudeの精度が悪い」と感じてセッションを捨て、最初からやり直すコストとロスが発生する。

After（コンテキストエンジニアリング）

CLAUDE.mdには必要最小限の設定（詳細はSkillsに分離）を書き、/context で定期的に使用量を確認する。60%到達時点で /compact "進行中のタスクの詳細を保持して" を実行し、重要な決定は decisions.md に書き出してcompactで消えないようにする。調査タスクはサブエージェントに委託してメインを汚染しない。結果として、6時間以上のセッションでも初期と同等の精度を維持できる。

まとめ

コンテキストエンジニアリングは「特別な技術」ではなく、習慣の問題だ。

• 今すぐ（1分）: セッション中に /context で現在の使用量を確認する
• 今日中: 次に60%を超えたら /compact を試す（95%まで待たない）
• 今週: CLAUDE.mdを見直し、詳細情報をSkillsファイルに分離する
• CLAUDE.mdに追加: ## Compaction指示 セクションを書いて保持すべき情報を明記する

「長いセッションになると精度が落ちる」のはClaudeのせいではない。コンテキストの設計を変えれば、6時間後でも最初と同じように動いてくれる。それを実感すると、セッションの組み方が変わってくる。