AIの「作業記憶」を効率的に使う
Claude Codeのコンテキストウィンドウは最大1Mトークン（約400万文字）という巨大な容量を持っています。 しかし、これは無限ではありません。セッション内で行われたすべてのやり取り――CLAUDE.mdの内容、会話履歴、ツールの出力結果――がコンテキストに蓄積されていきます。
現在のコンテキスト使用量は/contextコマンドで確認できます。 私は作業の節目ごとにこのコマンドを実行し、残り容量を把握するようにしています。 残量を意識せずに作業を続けると、気づかないうちにAIの応答品質が劣化していく危険があります。
# コンテキスト使用量を確認
/context
# コストと使用量の詳細を確認
/cost
/usageコンテキスト使用率が高くなると、AIの性能が目に見えて劣化する現象があります。 これを私は「Agent Dumb Zone」と呼んでいます。 コンテキストが埋まるにつれて、Claudeは過去の文脈を正確に参照する能力が低下し、 指示の見落とし、同じ質問の繰り返し、的外れな回答が増えてきます。
ポイント: コンテキスト使用率が50%に達したら、手動で/compactを実行してください。 自動コンパクションが発動するのを待つのではなく、先手を打つことが品質維持の鍵です。 自動コンパクションは閾値に達してから動くため、その時点ではすでに性能劣化が始まっています。
# 手動でコンテキストを圧縮
/compact
# 自動コンパクションの閾値をカスタマイズする場合
# settings.json の env に設定
{
"env": {
"CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "50"
}
}Anthropic社のDexter Horthy氏の調査によると、 フロンティアLLMが安定的に従える命令数には上限があります。 その上限はおよそ150〜200命令です。 これを超えると、命令への準拠率が急激に低下します。
重要なのは、この「命令」にはCLAUDE.mdの記述、システムプロンプト、 利用可能なツールの定義、MCP接続のツール説明——これらすべてが含まれるということです。 つまり、MCPサーバーを10個接続してツール定義が200個になると、 それだけでCLAUDE.mdの指示に回す「バジェット」がほとんど残りません。
実践への影響: MCPサーバーの接続は4〜5個に絞ること。CLAUDE.mdは200行以内に収めること。 この2つのルールは、Instruction Budgetの観点からも裏付けられています。 「全部入り」の設定は、かえってAIの品質を下げるのです。
Dex氏は「コンテキストエンジニアリングとは、より良い命令 + よりシンプルなタスク + より小さなコンテキストウィンドウの組み合わせ」だと述べています。 RAGで大量の情報を詰め込むよりも、本当に必要な情報だけを的確に与える方が効果的です。
Claude Codeを使う上で最も重要な原則の一つが、1セッション1テーマです。 タスクを切り替えるときは/clearでコンテキストをリセットしてください。 長いセッションを続けるほど、AIの応答品質は確実に落ちていきます。
これはClaude Codeコミュニティでも繰り返し強調されている知見です。 「vanilla CC is better than any workflows with smaller tasks」――つまり、 複雑なワークフローを組むよりも、シンプルに1つのタスクに集中させた方が良い結果が出るということです。
# タスク切替時にコンテキストをリセット
/clear
# 良い例: 1セッション1テーマ
セッション1: 認証機能の実装
セッション2: テストの作成
セッション3: ドキュメントの更新
# 悪い例: 1セッションで複数テーマ
セッション1: 認証実装 → テスト → ドキュメント → バグ修正 → ...重要なセッションにはラベルをつけて管理できます。/renameでセッションに名前をつけ、後から/resumeで再開できます。 特に複数のClaudeインスタンスを同時に実行している場合、この管理は必須です。
Cat Wu氏が推奨するように、私も複数Claude同時実行時には必ずセッションにラベルをつけています。 ラベルがないと、どのセッションで何をしていたのかが分からなくなり、再開時に混乱します。
# セッションに名前をつける
/rename [TODO - 認証リファクタリング]
# セッションの一覧を確認して再開
/resume
# → セッション一覧が表示される
# → [TODO - 認証リファクタリング] を選択して再開
# ラベル命名の例
[TODO - 認証リファクタリング]
[WIP - API設計]
[DONE - テスト追加]
[BLOCKED - 外部API待ち]Claude Codeで作業中に失敗した場合、同じコンテキスト内で修正しようとするのは悪手です。 失敗した文脈がコンテキストに残っていると、Claudeは同じ間違いのパターンに引きずられやすくなります。
代わりに、Escキーを2回押すか/rewindコマンドで、直前の状態に巻き戻してください。 チェックポイントはgitベースで自動的に追跡されているため、コードの変更も含めて安全に元に戻せます。
ポイント: 「修正」より「巻き戻し」が正解です。 失敗した文脈を含むコンテキストで修正を重ねると、コンテキストが汚染されて品質がさらに劣化します。 思い切って巻き戻し、クリーンな状態からやり直す方が結果的に早く終わります。
# 直前の状態に巻き戻し
Esc Esc # Escキーを2回押す
# または
/rewind
# git checkpointで自動追跡されているため
# コードの変更も安全に巻き戻される私の経験上、トークンを最も大量に消費するのは大量テキストの読み込みとリライトの並列実行です。 具体的な実例を共有します。
あるプロジェクトで、LPの改修とSEO記事14本の生成を1セッションで並列処理しようとしました。 各記事のリサーチ、既存コンテンツの読み込み、リライト出力――これらがすべてコンテキストに蓄積された結果、一瞬で5時間の利用制限に到達してしまいました。
この経験から学んだのは、コンテンツ生成のような大量テキストを扱うタスクは、 必ずセッションを分けて処理すべきだということです。
すべてのタスクをClaude Codeに任せる必要はありません。 タスクの性質に応じて適切なAIツールに分散させることで、コンテキストの消費を抑えつつ全体の効率を上げられます。
Cat Wu氏が推奨する方法として、/modelコマンドで同一セッション内でもモデルを切り替えるテクニックがあります。 計画フェーズではOpus（深い思考が必要）、実行フェーズではSonnet（高速処理）と使い分けることで、 コストとスピードのバランスを最適化できます。
# 計画フェーズ: Opusで深く考える
/model opus
「認証システムのリファクタリング計画を立てて」
# 実行フェーズ: Sonnetで高速実装
/model sonnet
「計画に沿って実装して」Claude Codeは複数のセッションを同時に実行できますが、並列実行が安全なのは限られた条件下だけです。
ポイント: 並列実行してよいのは、コンテキスト量の見積もりができている単純作業の繰り返しのみです。 それ以外のタスク（調査が必要なもの、複雑な判断を含むもの）はセッションを分離して順次実行する方が安全です。
並列実行が適しているケース: 同じ構造のファイルを複数生成する、既知のパターンでリファクタリングする、テストを一括作成する。 並列実行を避けるべきケース: 未知のコードベースの調査、設計判断を伴う実装、大量のファイル読み込みが必要なタスク。
Claude Codeの出力品質を向上させる設定として、Thinking ModeとOutput Styleがあります。 Boris氏が推奨するこれらの設定を有効にすることで、AIの推論過程を可視化し、より詳細な出力を得られます。
Thinking Modeを有効にすると、Claudeが結論に至るまでの推論過程が表示されます。 これにより、AIがどのように判断しているかを確認でき、誤った推論を早期に発見できます。 Explanatoryスタイルでは、Insightボックス付きの詳細な出力が得られます。
# settings.json で設定
{
"thinking": true,
"outputStyle": "explanatory"
}
# または対話中に設定変更
/configコンテキスト管理は、Claude Codeを使いこなす上で最も実務的なスキルです。 1Mトークンという大容量に油断せず、50%で/compact、1セッション1テーマ、 失敗時は巻き戻し――この3つの原則を守るだけで、AIの応答品質は劇的に安定します。 タスク別のAI分散戦略も組み合わせれば、チーム全体の生産性を最大化できるはずです。