コンテキスト管理

🔄 前回のおさらい: レッスン2でコアコマンド——/add、/clear、/compact、/undoなどの使い方を学びました。ここではこれらのコマンドを戦略的に使い、コンテキストを効果的に管理する方法を学びます。

コンテキストがすべてを決める

Claude Codeのレスポンスの質は、提供するコンテキスト次第です。適切なファイルを与えれば、すばらしい回答が得られます。無関係なものを詰め込めば、混乱した回答が返ってきます。

コンテキスト管理は単にファイルを追加することではありません。必要な結果を得るために、Claudeが見るものを戦略的にキュレーションすることです。

コンテキストの仕組み

Claudeのコンテキストを作業デスクに例えましょう。面積は限られています。デスク上のすべてが注意を奪い合います。

小さく整理されたデスク： モノが見つかる。効率的に作業できる。

巨大で散らかったデスク： モノが埋もれる。集中力が散る。

Claudeも同じです。関連ファイルが数個のほうが、間接的に関連するファイルが数十個より勝ります。

最小限のコンテキスト原則

何かを追加する前に問いましょう：「Claudeはこのタスクにこのファイルが必要か？」

はい、追加する：

• 質問対象や変更対象のファイル
• 使用するインターフェースを定義するファイル
• 従わせたいパターンがあるファイル
• 期待される挙動を示すテストファイル

いいえ、スキップする：

• 「念のため」のディレクトリ丸ごと
• トピックに間接的に関連するファイル
• Claudeが変更する必要のない大きな設定ファイル
• Claudeが参照する必要のないドキュメント

迷ったら： まず追加せずに始める。Claudeが情報不足に見えたら追加する。

コンテキストレイヤー戦略

一般的なものから具体的なものへ、レイヤーでコンテキストを構築します。

レイヤー1：プロジェクト理解

/add README.md package.json

高レベルのプロジェクト情報。これは何？技術スタックは？

レイヤー2：アーキテクチャ

/add src/index.js src/routes.js

エントリーポイントと構造。どう組織されている？

レイヤー3：機能コンテキスト

/add src/auth/*.js

作業中の特定の領域。

レイヤー4：タスクコンテキスト

/add src/auth/login.js src/auth/types.ts

現在のタスクの対象ファイル。

すべてのレイヤーが常に必要なわけではありません。簡単なバグ修正なら、レイヤー4に直行しましょう。

✅ 確認クイズ: なぜ「念のため」でディレクトリ全体を追加するのは避けるべきでしょうか？→コンテキストが散らかるとClaudeの注意力が分散し、レスポンスの質が落ちるからです。関連ファイル数個のほうが、無関係なファイル数十個より良い結果を生みます。

コンテキストの不調サイン

Claudeがコンテキストの問題を示すサイン：

「〜が見えません」 — ファイルが不足。追加しましょう。

存在しないコードへの言及 — 実際のコードがないので推測している。ソースファイルを追加。

スタイルやパターンの不一致 — 既存のコードを見ていない。従わせたいパターンの例を追加。

非常に遅いレスポンス — コンテキストが大きすぎるかも。/compactを試す。

古い無関係な内容への言及 — 古い情報でコンテキストが散らかっている。/clearして再構築を検討。

タスク別コンテキスト戦略

バグ修正

/clear
/add [バグのあるファイル]
/add [関連しそうなファイル]
> このエラーが出ている：[エラーメッセージ]
> バグを見つけて修正して。

最小限でフォーカスされたコンテキスト。問題の理解と修正に必要なものだけ。

機能開発

/clear
/add src/similar-feature/*        # 従うべきパターン
/add src/types/*.ts               # 型定義
/add tests/similar-feature.test.js # テストパターン
> Xを行う新機能を作成して。既存のパターンに従って。

コンテキストがClaudeにどのパターンに従うか示します。

コードレビュー

/add $(git diff --name-only HEAD~1)  # 変更されたファイルだけ
> これらの変更にバグ、スタイルの問題、潜在的な問題がないかレビューして。

実際に変更されたものにフォーカス。

リファクタリング

/add [リファクタリング対象のすべてのファイル]
> [コンポーネント]を[新しいパターン]を使うようにリファクタリングして。
> これらのファイル全体の使用箇所を更新して。

整合性のある変更のために、影響を受けるファイルをすべて先に追加。

大きなタスクのチャンキング

コンテキストに収まりきらないタスクもあります。解決策：作業をチャンクに分割。

やってはいけない：

/add src/**/*                    # 全部——多すぎる
> コードベース全体をTypeScriptに変換して

こうする：

# セッション1
/add src/utils/*
> utilsをTypeScriptに変換して。tsconfigはこちら。

# セッション2
/clear
/add src/models/*
> modelsをTypeScriptに変換して。utilsのパターンに合わせて。

# セッション3
/clear
/add src/services/*
> servicesをTypeScriptに変換して。

各セッションにフォーカスされたコンテキスト。作業はインクリメンタル。

まとめ

• コンテキストの質は量に勝る
• 最小限のコンテキスト原則：現在のタスクに必要なものだけ
• タスクの複雑さに応じて一般→具体のレイヤーでコンテキストを構築
• コンテキスト調整が必要なサインを見逃さない
• 大きなタスクはフォーカスされたセッションにチャンキング

次のレッスン： Claudeにもっと多くの作業を任せるためのマルチステップタスクのオーケストレーションを学びます。