Claude Codeのコンテキスト管理を業務開発でどう使い分けるか

はじめに

前回は並行作業系のコマンドを業務開発の具体例で見ました。今回は、1つの会話を進める中で「考え方や状態をどう調整するか」に関わるコマンド、/plan /context /compact /clearを、同じく業務開発の場面に当てはめて整理します。

この4つは「会話が膨らんで動きが重くなる」「使える時間に限りがある」という、Claude Codeを長時間使うほど直面する問題に直結しています。順番に見ていきます。

/plan｜先に方針を確認してから進める

場面：既存の認証周りの仕組みを変更する対応。影響範囲が読みづらく、いきなり実装に入ると手戻りのリスクが高い。

Before：とりあえず実装してもらい、動かしてから問題点を直していく。認証は影響範囲が広いので、後から「このルートのチェックが漏れてた」が何回も出てくる。

After：/planでプランモードに切り替え、先に変更対象のファイルと方針をまとめてもらう。実装に入る前に「ここは触らない」「このAPIは互換性を保つ」という前提を確認してから進める。

後から直すコストと、先に方針を確認するコストを比べると、影響範囲が広い変更ほど後者が圧倒的に安い。

/context｜今どれだけ使っているかを見る

場面：仕様のすり合わせを続けているうちに、会話がだんだん重く感じてくる。何が原因か分からないまま続けている。

After：/contextで今の会話がどれだけ記憶できる範囲（コンテキスト）を使っているかを確認する。読み込んだファイルや過去の発言がどれくらい残っているかが分かるので、「そろそろ整理した方がいい」を感覚ではなく数字で判断できる。

Claude Codeには5時間ごとのリミットと、週単位のリミットの両方がある。会話が長くなるほど消費も増えるので、/contextでこまめに見ておくと、リミットに引っかかりそうなタイミングを早めに察知できる。重い作業を始める前に確認しておけば、「途中でリミットに当たって続きが翌日になる」という事態を避けやすくなる。

5時間リミットは時間が経てば回復するので、際どいタイミングは「今日中にこの作業を終わらせたいか」で判断材料が変わる。週次リミットの方は使い切ると次の週まで響くので、大きな作業の前ほど/contextを見る癖をつけている。

/compact｜焦点を絞って圧縮する

場面：DB設計について何度もやり直しながら議論し、会話がかなり長くなった。結論は出たが、議論の過程の発言がそのまま残っている。

Before：会話をそのまま続けるか、/clearで丸ごと消して結論だけ手で書き直すかの二択になる。後者は結論をまとめ直す手間がかかる。

After：/compactで会話を要約・圧縮する。「DB設計の結論部分だけ残して圧縮して」と焦点を指定すれば、議論の過程を削って必要な情報だけ残せる。会話をリセットせずに、そのまま実装に進める。

焦点を指定できるのが地味に大きい。指定なしの圧縮だと何が残るか運任せになるが、「ここだけ残して」と言えば確実にその情報を引き継いでくれる。

/clear｜新しい会話に切り替える

場面：午前中は認証周りの変更をやっていたが、午後から全く別の機能のバグ調査に移る。

After：/clearで新しい会話を始める。プロジェクトの記憶（CLAUDE.mdの内容）は引き継がれるので、プロジェクトのルールを毎回説明し直す必要はない。/compactのように一部を残すのではなく、丸ごと切り替えたいときはこちらの方が早い。

/compactと/clearの使い分けは、「今の会話の続きをやるか」で決めている。続きをやるなら情報を残して圧縮、別のタスクに移るなら丸ごと切り替える。

逆引き早見表

まとめ

会話の整理・計画系のコマンドは、どれも「今の会話の状態を把握してから次の手を決める」という共通点がありました。/contextで現状を見て、リミットを意識し、/compactで圧縮するか/clearで区切るかを選ぶ。大きな変更の前は/planで先に方針を固める。この流れを覚えておくと、会話が長くなるほど発生する「重くなってきた気がする」を感覚ではなく判断に変えられます。

最後まで読んでいただきありがとうございました。