読むきっかけ
Claude Codeを使い始めてしばらく経つが、「なんとなくうまくいっている」という感覚で使い続けていた。
プロンプトを工夫したり、CLAUDE.mdを整えたりはしてきた。しかし、コンテキストをどう管理するかという発想はほとんどなかった。
記事のPart 15からPart 20は、まさにその「コンテキストエンジニアリング」と「運用戦略」を体系的に扱っている。読んで初めて、自分がいかに場当たり的な使い方をしていたかに気づいた。
後から公式のベストプラクティスドキュメントも読んだところ、記事の内容と重なる部分も多かったが、いくつか「そういうことだったのか」という補強があった。このエントリーはその両方を合わせた記録だ。
コンテキストウィンドウという制約
公式ドキュメントの書き出しがそのまま核心をついていた。
Most best practices are based on one constraint: Claude’s context window fills up fast, and performance degrades as it fills.
ウィンドウの上限は200,000トークン。ただしセッション開始時点で、すでに相当量が消費されている。自動でロードされるものだけでも：
- システムプロンプト（〜4,200トークン）
- MEMORY.md（〜680トークン）
- 環境情報（〜280トークン）
- MCP ツール一覧
- Skill の説明一覧
~/.claude/CLAUDE.mdと プロジェクトのCLAUDE.md
ここにユーザーの発言、Claudeの返答、ファイル読み込み結果、コマンド出力が積み重なっていく。ファイルを1つ読むだけで1,000〜2,000トークン消えることもある。
コンテキストが埋まるにつれ、Claudeは以前の指示を「忘れ」、精度が落ちてくる。これはモデルの問題ではなく、仕組みの問題だ。だから「コンテキストをどう管理するか」が、プロンプトをどう書くかと同じかそれ以上に重要になる。
WSCEフレームワーク
Anthropicが提唱する、コンテキストを最適化するための4戦略だ。
| 戦略 | 内容 |
|---|---|
| Write | 情報を構造化してからコンテキストに入れる |
| Select | 必要なセクションだけを選んで読み込む |
| Compress | 冗長な情報を凝縮して密度を上げる |
| Isolate | サブエージェントでコンテキストを分離する |
100ページのPDFをそのまま読み込むのではなく、構造化した要約だけを渡す。分析したいセクションだけを選ぶ。挨拶や繰り返しを削ってトランスクリプトを凝縮する。そして複数銘柄の比較なら、各銘柄の分析をサブエージェントに任せてサマリーだけを集める。
4つのうちどれか1つを意識するだけでも、コンテキストの質は大きく変わる。
戦略的コンパクト化
Claude Codeは自動でコンパクト（コンテキスト圧縮）してくれるが、タスクの途中で発生すると重要な文脈が失われることがある。そのため、自分でタイミングを制御するほうがいい。
- 01 探索フェーズ終了後 大量の調査内容を圧縮
- 02 マイルストーン完了後 次フェーズに向けてリセット
- 03 エラー解決後 デバッグの試行錯誤を捨てる
- 04 使用率 60% を超えたら 新しいセッションを開始する
/context で現在のトークン使用率を確認できる。
/context で現在のトークン使用率を確認できる。60%が一つの目安で、これを超えたら新しいセッションを開始するのが安全だ。
/clear、/compact、/btw の使い分け
公式ドキュメントを読んで、これらのコマンドの使い所がはっきりした。
/clear はコンテキストを完全にリセットする。関係のないタスクに移るときや、同じ間違いを2回以上訂正してもまだうまくいかないときに使う。長いセッションに無関係な会話が蓄積してきたら、/clear して新しいプロンプトで仕切り直すほうが早い。
/compact [指示] はコンテキストを圧縮しながら引き継ぐ。/compact APIの変更点に絞って のように焦点を指定できる。CLAUDE.md に "When compacting, always preserve the full list of modified files" のような指示を書いておけば、圧縮後も重要な文脈が残る。
/btw は、調べたいことがあるけどコンテキストを消費したくないときのサイドクエスチョン用だ。答えはオーバーレイで表示され、会話履歴に一切残らない。「このエラーコードって何だっけ」程度の確認に使うと、メインの流れを汚さずに済む。
また、同じ間違いを訂正してもうまくいかない場合は、訂正を積み重ねるより /clear して「学んだことを反映した最初のプロンプト」を書き直したほうがいい。失敗したアプローチがコンテキストに残ると、Claudeの判断を引きずり続ける。
探索→計画→実装→コミット
「計画を実装から分離する」という考え方は、間違った問題を解決するリスクを避けるためにある。
Shift+Tabでモードを切り替える。Planモードでは、Claudeは実行前に計画を提示して承認を求める。
ただし、毎回Planモードを使う必要はない。「diffを1文で説明できるような小さな変更」は直接やらせればいい。Planモードを使うのは、複数ファイルにまたがる変更や、アプローチが不確実なときだ。
並列化戦略
/fork 並列実行の基本原則は「最小限の並列化で最大の成果」だ。常に複数のClaudeを動かせばいいわけではない。並列インスタンスを追加するのは、真の必要性があるときだけでいい。
複数インスタンスが同じコードベースを触る場合は、Git Worktreesを使うとコンフリクトを防げる。
git worktree add ../project-feature-a feature-a
git worktree add ../project-feature-b feature-b同時に抱えるタスクは3〜4つまで。それ以上は認知オーバーヘッドが生産性を上回る、という指摘が腑に落ちた。
サブエージェントで調査を分離する
公式ドキュメントで「なるほど」と思ったのが、サブエージェントをコンテキスト管理の道具として使う考え方だ。
コードベースの調査をメインセッションでやると、大量のファイル読み込みがコンテキストを食う。その調査結果は実装には不要なことも多い。そこで：
サブエージェントを使って、認証システムがトークンリフレッシュをどう処理しているか調べて。再利用できる既存のOAuthユーティリティもあれば教えて。サブエージェントは別のコンテキストウィンドウで動き、調査結果のサマリーだけを返してくる。メインセッションは実装に集中したままでいられる。
レビューにも使える。実装直後に同じセッションで「このコードレビューして」と頼むと、Claudeは自分が書いたコードに引っ張られやすい。別のコンテキストで動くサブエージェントに頼めば、フレッシュな目で見てもらえる。
継続学習パターン
セッションをまたいで知識が引き継がれない問題への対処として、「発見をSkillとして保存する」という方法がある。
非自明な発見——デバッグの手順、プロジェクト固有のパターン、うまくいったワークアラウンド——をその場でSkillファイルに落としておく。/learn コマンドでセッション後に手動で抽出することもできる。
「またこのエラーか」という苛立ちは、知識を外部化することで防げる。
Skillへの保存が「手動で呼び出す手順書」だとすると、MEMORYはそれとは別の仕組みだ。発見・設定・好みをファイルとして保存しておくと、次のセッション開始時に自動で参照される。明示的に呼び出す必要がない分、忘れにくい。
トークン最適化
モデルの使い分けが、コスト効率の核心になる。
| モデル | 用途 | 特性 |
|---|---|---|
| Haiku | 反復タスク・明確な指示 | 安い・速い |
| Sonnet | 一般的なコーディング 90% | バランス |
| Opus | 設計・セキュリティ・複数ファイル | 高品質 |
- 最初の試行が失敗したとき
- 5 ファイル以上の変更
- アーキテクチャの意思決定
- セキュリティクリティカルなコード
Opusにアップグレードするのは、最初の試行が失敗したとき、5ファイル以上の変更、アーキテクチャの意思決定、セキュリティクリティカルなコードのときだ。
また、MCPの多くにはCLI相当のコマンドが存在する。GitHub MCPの代わりに gh コマンドを使うなど、CLIをSkillでラップすることで同等の機能をより少ないトークンで実現できる。
よくある落とし穴
公式ドキュメントの「Avoid common failure patterns」のセクションが具体的で参考になった。自分が心当たりのあるものばかりだった。
キッチンシンクセッション。 最初のタスクをこなしつつ、途中で別のことを聞き、またもとのタスクに戻る。コンテキストには関係ない情報が積み重なっていく。対処はシンプルで、タスクが変わったら /clear する。
訂正ループ。 Claudeが間違える → 訂正する → まだ間違える → また訂正する。コンテキストに失敗したアプローチが溜まっていき、ますます正しい方向に引っ張りにくくなる。2回訂正してもうまくいかなければ、/clear して「失敗から得た知識を反映した最初のプロンプト」を書き直す。
過剰なCLAUDE.md。 CLAUDE.mdが長くなると、Claude は重要なルールを見落とし始める。Claudeが既に正しくやっていることは書かない。削れるものは削る。
検証なしの信頼。 それっぽい実装が出てきても、エッジケースを処理していないことがある。テスト、スクリプト、スクリーンショット——何らかの「検証の仕組み」を用意していないと、自分が唯一のフィードバックループになる。
スコープのない調査。 「このあたり調べて」と曖昧に頼むと、Claudeは大量のファイルを読み込んで探索する。コンテキストが調査で埋まってしまう。調査はスコープを絞るか、サブエージェントに任せる。
どれも「コンテキストが何かに汚染されている」という構造は同じだ。症状が違っても、原因は似ている。
読んでみての所感
「プロンプトをうまく書く」という発想から、「コンテキストそのものを設計する」という発想への転換が、この6パートの核心だと感じた。
情報をどの形式で渡すか、いつ圧縮するか、どの粒度でタスクを分割するか——こうした設計の積み重ねが、Claude Codeの応答品質を根本から変える。
公式ドキュメントを読んで追加で気づいたのは、「落とし穴のほとんどがコンテキストの汚染に帰着する」という点だ。訂正ループも、キッチンシンクセッションも、スコープのない調査も、根っこは同じ。コンテキストをきれいに保つことが、品質を保つことに直結する。
まず試すのは、タスクの境界で /clear を習慣にすることと、調査タスクをサブエージェントに任せること。WSCEの「Compress」と合わせて、この3つが自分の使い方を変えそうだ。