Article

Claude Codeでコンテキストウィンドウを無駄にしない運用方法

長い作業でClaude Codeの精度が落ちるのはコンテキストウィンドウが埋まるからです。/compact・/clear・/rewind・サブエージェント委譲・セッション再開の5つの手法で、作業が長引いても品質を保つ運用方法を整理します。

This article is not published in this language yet, so the Japanese version is shown instead.

Claude Codeの公式ドキュメントに「コンテキストウィンドウが埋まるにつれてLLMの性能は低下する（context window fills up fast, and performance degrades as it fills）」と明記されています。長い作業で「さっきと違う動きをする」「依頼した内容を忘れている」と感じたら、コンテキスト管理を見直す必要があります。この記事では、コンテキストウィンドウの消費を抑え、長時間の作業でも品質を維持するための5つの手法を整理します。

なぜ長い作業で精度が落ちるのか

Claude Codeの会話履歴には、すべてのメッセージ・ファイルの読み込み内容・コマンドの出力が蓄積されます。デバッグセッション1回や大きなコードベースの調査だけで数万トークンを消費することがあります。

コンテキストが埋まってくると2つの問題が起きます。

前半の指示を「忘れる」: 文脈が長くなるほど早い段階の会話への注意が薄れます
不要な情報に引きずられる: 別タスクで読んだファイルや試みた失敗アプローチがノイズになります

コンテキスト使用量はいつでも確認できます。

/context

残り容量とトークン内訳が表示されます。数値を見て先手を打つのが鉄則です。

手法1：タスクの切れ目で `/clear` を使う

最もシンプルな対策が /clear です。会話履歴とすべてのファイル読み込みをリセットし、コンテキストを白紙に戻します。

/clear

使うタイミング: 無関係なタスクに移る前。「認証機能を直した、次はUIの改善だ」という切れ目が典型的な使いどころです。

公式Best Practicesでは「同一セッションで無関係なタスクを続けるな（The kitchen sink session）」というアンチパターンを筆頭に挙げています。1セッション=1タスクが基本原則です。

また、同じ問題で2回以上修正を繰り返している場合も /clear のサインです。失敗した修正アプローチが積み重なったコンテキストは、同じ誤りを誘発します。/clear してより具体的な初期プロンプトで再スタートするほうが、長くなったセッションを続けるより速く解決する場合がほとんどです。

手法2：`/compact` でコンテキストを圧縮する

作業を途中でリセットしたくない場合は /compact を使います。会話履歴を圧縮しながら、重要な情報（コードの状態・決定事項・変更したファイル）を残します。

/compact

圧縮の方針を指示することもできます。

/compact 変更したAPIのエンドポイントとテスト結果を優先して残す

Claude Code自体が自動コンパクションをサポートしています。コンテキスト上限に近づくと自動的に要約を作成し、会話を継続します。ただし、自動コンパクションに全依存せず、重要なポイントで手動 /compact を使うほうがコントロールしやすいです。

CLAUDE.mdにコンパクション方針を書く

毎回指示しなくても済むよう、CLAUDE.mdにコンパクション時の保持方針を記述できます。

# コンパクション時の保持方針
コンパクション時は以下を必ず残す：
- 変更したファイルの完全なリスト
- 実行したテストコマンドと結果
- 承認済みの実装計画

この指示がCLAUDE.mdに書かれていれば、自動コンパクション時も反映されます。

手法3：`/rewind` でポイントに戻る

作業の途中でコンテキストの一部だけを整理したい場合は Esc + Esc または /rewind を使います。

/rewind

リワインドメニューが開き、次の操作を選べます。

会話だけを復元: コードはそのままに、会話を以前の状態に戻す
コードだけを復元: ファイルを以前の状態に戻す（Gitの置き換えではない）
両方を復元: 会話とコードを同時に以前の状態に戻す
指定地点から要約: 選択したメッセージ以降を圧縮し、それ以前の文脈はそのまま残す

「指定地点から要約」はとくに便利です。長い調査のログだけを圧縮して、初期の依頼内容や重要な決定は残す、という使い方ができます。

チェックポイントはClaude Codeが変更を加えるたびに自動作成されます。セッションを閉じた後もチェックポイントは残るため、翌日のセッションからでも /rewind で戻ることができます。

手法4：調査はサブエージェントに委譲する

コンテキストを消費する最大の原因の一つが「コードベースの探索」です。大量のファイルを読み込ませると、それだけでコンテキストが埋まります。

調査タスクはサブエージェントに委譲することで、メインコンテキストへの影響を防げます。

サブエージェントを使って認証モジュールのファイル構成と
トークンリフレッシュの仕組みを調査してください

サブエージェントは独立したコンテキストウィンドウで動作し、調査結果のサマリーだけをメイン会話に返します。ファイルの読み込みコストがサブエージェント側に吸収されるため、メインコンテキストはほぼ汚染されません。

サマリーの形式も指定すると効果的です。

repo-scoutエージェントを使ってsrc/auth/以下を調査し、
400字以内で次の形式でまとめてください：
- 主要ファイル（最大5件）
- 認証フローの概要
- 注目すべき依存関係

サブエージェントの詳細については「Claude Codeのサブエージェントとは？使いどころと注意点」を参照してください。

手法5：セッションを引き継いで再開する

複数のセッションにまたがる長期作業は、適切にセッションを分割して管理します。

セッションを名前付きで継続する

claude --continue

直近のセッションを再開します。セッションがなければそのまま新規開始です。

claude --resume

セッション一覧から選んで再開します。長期作業を複数の名前付きセッションで管理している場合に使います。

セッションに名前をつける

/rename oauth-migration

作業内容を表す名前を付けると、後から見つけやすくなります。「oauth-migration」「ui-refactor-sprint」のようにブランチ名に近い命名が管理しやすいです。

引き継ぎメモを残す

セッションをまたぐ場合、翌日の自分への申し送りを残しておくと再開コストが下がります。

次のセッションの前に確認すること：
- api/users.ts の型エラーは未解決
- テストのうち2件がflaky（詳細はNOTES.mdに記載）
- 依存追加の承認待ち

このメモを NOTES.md または CLAUDE.md に書いておき、次のセッション開始時に @NOTES.md で参照すると、前回の文脈を最小コストで復元できます。

`/btw` でサイドクエスチョンを処理する

メインの作業とは別に「ちょっと確認したいこと」が出てきた場合は /btw を使います。

/btw このエラーメッセージは何を意味しますか？

回答は消えるオーバーレイとして表示され、会話履歴に残りません。確認のためにコンテキストを消費したくない細かい質問に向いています。

コンテキスト管理の判断フロー

状況	推奨アクション
無関係な別タスクに移る	`/clear` でリセット
同じ問題で2回以上修正を繰り返した	`/clear` して再スタート
作業は続けたいがコンテキストが重い	`/compact` で圧縮
誤った方向に進んだと気づいた	`/rewind` で巻き戻す
大量ファイルの調査が必要	サブエージェントに委譲
長期作業でセッションをまたぐ	`--continue` / `--resume` で再開
小さな確認をしたい	`/btw` で聞く