Claude Codeを長時間使っていると、必ず「コンテキストの上限」に突き当たります。会話が要約されて細部が消えたり、序盤に決めた方針をエージェントが忘れたように見えたり。この問題への対処として最初に紹介されがちなのが /compact（会話の圧縮）ですが、先に結論を言います。コンテキスト管理の主役は圧縮ではなく、/clear で区切ることと、そもそも余計なものを入れない設計です。 圧縮は、それでも足りないときの最後の手段。
この記事は、Claude Codeのコンテキストに何が入っているかの観測から、auto-compactの挙動、/compact と /clear の使い分け、入れない設計までを、執筆時点の公式ドキュメントを正として整理します。想定読者は、Claude Codeを日常的に使い始めて「セッションが長くなると調子が悪くなる」と感じている人です。コマンドの仕様は変わることがあるので、導入前に最新の公式ドキュメントを確認してください。
コンテキストには何が入っているのか。まず /context で見る
コンテキストウィンドウは「会話履歴」だけではありません。1セッションのコンテキストには、おおまかに次のものが同居しています。
- システムプロンプト: Claude Code本体の動作指示
- メモリ（CLAUDE.md）: プロジェクトやユーザー単位の指示ファイル。セッション開始時に読み込まれます
- ツール定義: 標準ツールに加え、接続したMCPサーバーが提供するツールの定義
- 会話履歴: あなたの指示とエージェントの応答
- ツールの実行結果: 読んだファイルの中身、コマンドの出力など
見落とされがちなのは最後の2つ以外、つまり「会話を始める前から埋まっている分」です。何も話していないのに、CLAUDE.mdとツール定義だけでコンテキストの一部は消費されています。そして実際の内訳は、組み込みのスラッシュコマンド /context で確認できます。何がどれだけ食っているかをまず観測する。コンテキスト管理はここから始めるのが正解です。
上限に近づくと何が起きるか。auto-compactの挙動
コンテキストの上限はモデルに依存しますが、無限ではありません。上限に近づくと、Claude Codeはauto-compactを実行します。それまでの会話を要約し、要約で履歴を置き換えて、空き容量を作ってからセッションを続ける動きです。
これ自体はよくできた安全装置で、作業が途中で強制終了するよりずっといい。ただし性質は理解しておく必要があります。要約は不可逆です。要約に入らなかった細部、たとえば「なぜその設計を却下したか」の理由や、エラーメッセージの正確な文字列は、要約後のセッションからは参照できません。長いセッションの後半で「さっき言ったはずのことが通じない」と感じる原因の多くはこれです。
auto-compactの有効・無効は設定で切り替えられます。切るという選択もありますが、その場合は上限に達した時点で自分で対処することになるので、まずは「いつ発動したかを意識する」ところから始めるのがおすすめです。
/compact の使い方と、覚えたときが一番危ない理由
/compact は、auto-compactを待たずに自分のタイミングで会話を圧縮するコマンドです。引数で「何を残すか」の指示も渡せます。
# 会話を要約して空きを作る
/compact
# 残してほしい観点を指示する
/compact 認証まわりの設計判断とテストの失敗内容は詳細に残して
節目で指示付きの /compact を打つのは、auto-compactに任せるより明らかに良い運用です。何が重要かを一番知っているのは自分なので、要約の品質を自分で制御できます。
ただ、私はこのコマンドを「覚えたときが一番危ない」と思っています。圧縮で延命できると分かると、1つのセッションを何時間も引っ張りたくなるからです。要約は劣化コピーです。圧縮を2回、3回と重ねたセッションは、原本のない伝言ゲームに近づいていきます。エージェントは自信を持って要約後の文脈で答え続けるので、劣化に気づきにくい。圧縮は「続きの文脈がどうしても必要な長作業」に限定して、原則は次の /clear に倒す。これがこの記事で一番言いたいことです。
主役は /clear。「圧縮」ではなく「区切り」で管理する
/clear は会話履歴を完全にリセットするコマンドです。CLAUDE.mdなどのメモリは次のセッションでも読み込まれるので、失われるのは会話とツール実行結果だけ。Anthropic自身のベストプラクティスでも、タスクの合間に /clear でコンテキストをリセットする運用が推奨されています。
「せっかく積み上げた文脈を捨てるのはもったいない」と感じるかもしれません。ここで発想を変えます。残したい文脈は、会話の中ではなくファイルに置くんです。
- 作業計画や設計判断は、Markdownのメモとしてリポジトリに書き出させる
- 長く守らせたいルールは CLAUDE.md に昇格させる（
#から始まる入力でその場で追記できます） - 次のセッションは、そのファイルを読ませてから始める
こうすると「1タスク1セッション」が基本形になります。会話は使い捨て、事実と判断はファイルに永続化。圧縮で会話を延命するより、区切って外部化するほうが、文脈の劣化が起きません。人間のチームが口頭の記憶ではなくドキュメントで引き継ぐのと同じ理屈です。
Claude Code公式: Manage Claude's memory（CLAUDE.md）Give Claude persistent instructions with CLAUDE.md files, and let Claude accumulate learnings automatically with auto memory.code.claude.comそもそも入れない設計。サブエージェントとMCPの足しすぎ
/clear と外部化を覚えたら、最後は「入れない設計」です。効く場所は3つあります。
1. 調査はサブエージェントに隔離する。 ファイルを大量に読む探索作業は、コンテキストを一番食います。サブエージェントは本体とは別のコンテキストで動き、結果の要点だけを返す仕組みなので、「広く読んで、結論だけ持ち帰る」仕事を任せると本体のコンテキストが汚れません。詳細は公式のサブエージェント解説を参照してください。
2. MCPサーバーを足しすぎない。 接続したMCPサーバーのツール定義は、使わなくてもコンテキストに載ります。サーバーを増やすほど、会話を始める前の消費が増える。この判断軸はMCPサーバーの設定ガイドに書いたので、そちらに譲ります。
3. CLAUDE.mdを肥大させない。 メモリは毎セッション読み込まれる固定費です。「たまにしか使わない手順」まで書き込むと、全セッションがその分を払い続けます。頻用するルールだけを残し、詳細な手順は別ファイルにして必要なときに読ませる構成が向いています。
定時実行やCIでは「何を入れるか」しか存在しない
補足として、自動化の文脈にも触れておきます。claude -p のヘッドレス実行や定時実行の運用では、セッションは毎回まっさらに始まります。会話が積み上がらないので /compact の出番はなく、コンテキスト管理は純粋に「起動時に何を読ませるか」の設計になります。対話モードで「入れない設計」を身につけておくと、そのまま自動化の設計に流用できるわけです。
なおコンテキストの使い方は、APIコストにも直結します。定時実行でのキャッシュとコストの観測は別記事にまとめてあります。
Claude Codeのプロンプトキャッシュ入門｜エージェント運用のコストを観測して設計するClaude Codeを定時実行で運用するときのAPIコストを左右するプロンプトキャッシュの仕組みを解説します。キャッシュが静かに切れる箇所、2026年8月末に追加された/costのキャッシュ行やエージェント別cacheTtlなどの観測・制御手段、日次運用での設計判断をまとめます。www.tentspace.net
圧縮は最後の手段。順番を間違えない
まとめます。Claude Codeのコンテキスト管理は、次の優先順位で考えるのがおすすめです。
- 観測する:
/contextで何が食っているかを見る - 入れない: サブエージェントへの隔離、MCPの取捨選択、CLAUDE.mdの節制
- 区切る: 1タスク1セッション。残したい文脈はファイルへ外部化し、
/clearで切る - 圧縮する: どうしても続きが必要な長作業だけ、指示付きの
/compact
/compact は便利ですが、最初に手を伸ばす道具ではありません。圧縮でセッションを延命し始めたら、それは区切りと外部化の設計を見直すサインです。上限との戦いに見える問題は、たいてい「何を入れるか」の設計の問題。順番を間違えなければ、コンテキストの上限はそれほど怖い相手ではないと思います。