Claude Code を長く回すと、応答がもたつく瞬間があります。原因の多くはコンテキスト窓の圧迫。/context はその内訳をトークン数で見せるコマンドです。
もたつきの原因を数字にする
「なんとなく重い」という体感は、対処の手がかりになりません。何を削れば軽くなるのかが見えないからです。/context は、その重さをカテゴリ別のトークン数に変換します。Claude Code v2.1.170 で標準搭載。引数なしで /context と打つだけで、会話・システムプロンプト・ツール定義などに分かれた内訳が並びます。
公式ドキュメント “Explore the context window” は、この出力を a live breakdown by category with optimization suggestions と説明しています。数字だけでなく、削るヒントも一緒に出る。/context 自体は v1.0.86 から入っている古参のコマンドです。
/memory と役割を分ける
起動時にどの CLAUDE.md や auto memory が読まれたかまでは、/context では粒度が粗い。ファイル単位で確認したいときは /memory を使います。同じ「コンテキストを見る」でも、見える解像度が違います。
/context: カテゴリ別のトークン内訳と最適化提案。窓全体の埋まり具合を俯瞰する/memory: 起動時に読まれた CLAUDE.md と MEMORY.md の一覧。どのファイルが効いているかを特定する
最初のプロンプト前に載っているもの
勘違いしやすいのは、コンテキストが「自分の入力で埋まる」という前提です。実際は、最初のプロンプトを打つ前に複数のものがロードされています。
| ロードされる項目 | 代表的なトークン量 | 中身 |
|---|---|---|
| System prompt | 約 4.2k | 挙動・ツール使用・整形のコア指示。最初に必ず載る |
| Environment info | 約 0.3k | 作業ディレクトリ・OS・shell・git の状態 |
| Auto memory (MEMORY.md) | 約 0.7k | 先頭 200 行または 25KB の早い方まで |
| MCP tools (deferred) | 0.1k 〜 | 既定ではツール名のみ。スキーマは必要時に展開 |
| Skill descriptions | スキル数次第 | 呼べるスキルの 1 行説明だけ。本体は使う時に展開 |
| ~/.claude/CLAUDE.md / プロジェクト CLAUDE.md | 内容次第 | ユーザー設定とプロジェクト設定の 2 枚 |
これらの値は公式が representative numbers と明言しているとおり、環境やバージョンで変わります。固定値として覚えるものではなく、自分の /context で実測する前提の目安です。CLAUDE.md と MEMORY.md の使い分けは Claude Code memoryとは？CLAUDE.mdとの違いと運用設計の実例 で整理しています。
/context の出力をどう読むか
実際の出力はこうなります。バーの長さが窓に占める割合、右端がパーセント表示です。
> /context
⎿ Context Usage · claude-opus-4-8[1m]
System prompt 4.2k ▓░░░░░░░░░░ 0.4%
System tools 12.4k ▓░░░░░░░░░░ 1.2%
MCP tools 1.6k ░░░░░░░░░░░ 0.2%
Memory files 0.9k ░░░░░░░░░░░ 0.1%
Custom agents 0.5k ░░░░░░░░░░░ 0.1%
Messages 46.8k ▓░░░░░░░░░░ 4.7%
Free space 933k ░░░░░░░░░░░ 93.3%読む順番は Free space から。残量が 9 割あるなら、内訳を気にせず作業を続けて問題ありません。残量が 2 割を切ったあたりで、どのカテゴリが太っているかを上から見ます。上の例なら Messages（会話履歴）と System tools が支配的。
出力の下部には最適化の提案も付きます。たとえば古い MCP サーバーが大量のツールを抱えているとき、その接続を見直すよう促す行が出る。会話が長い場合は /compact や /clear を案内します。提案をそのまま実行するかは自分で判断しますが、どこから手を付けるかの当たりは付けやすくなります。
太っているカテゴリから手を打つ
Messages が大きいなら会話そのものが長い。System tools や MCP tools が大きいなら、つないでいるツールの定義が重い。原因のカテゴリで打ち手が変わります。会話なのかツールなのか、原因の側を 1 コマンドで切り分けられます。
/memory で読み込み元を裏取りする
Memory files が想定より大きいときは、/memory でロード元を確認します。
> /memory
Memory files loaded at startup:
1. ~/.claude/CLAUDE.md (user, 1.2k tokens)
2. ./CLAUDE.md (project, 0.8k tokens)
3. ~/.claude/.../MEMORY.md (auto memory, 0.7k tokens)どのファイルが何トークン乗っているかが行単位で出ます。肥大した CLAUDE.md を切り詰める判断は、ここを見てからにします。
MCP ツールと Skill が初期消費を左右する
窓を最初から圧迫する最大要因は、会話ではなく接続したツールです。会話をいくら畳んでも、ツール由来の消費は減りません。MCP サーバーを 6 つ繋いだまま大きめのリファクタを始めたとき、最初のプロンプト前に MCP 関連だけで 30k 近く埋まっていたことがありました。原因はツールスキーマの先読みでした。
MCP スキーマは既定で遅延ロード
公式ドキュメントは MCP tools の項目をこう書いています。By default, full schemas stay deferred and Claude loads specific ones on demand via tool search when a task needs them。既定ではツール名だけが載り、スキーマ本体はタスクが要求した時に展開される。だから /context の MCP tools が小さく見えても、作業中に膨らむ余地があります。
ENABLE_TOOL_SEARCH の 3 つの値
この遅延ロードの挙動は環境変数で変えられます。多数の MCP を常用するなら auto が無難です。
| 値 | 挙動 |
|---|---|
| （未設定） | ツール名のみ載せ、スキーマは必要時に検索して展開 |
auto | 窓の 10% に収まるならスキーマを先読み。超えるなら遅延のまま |
false | 全スキーマを起動時にロード。少数ツールなら検索の手間が消える |
# MCP を多数つないでいるなら、スキーマを遅延寄りにして初期消費を抑える
export ENABLE_TOOL_SEARCH=auto# 切替後の /context。MCP tools が数十k から 1k 台へ
MCP tools 1.4k ░░░░░░░░░░░ 0.1%先ほどの 30k のケースは、auto に変えただけで初期消費が 10 分の 1 以下に下がりました。常時すべてのツール定義を抱える必要は、ほとんどの作業でありません。
トレードオフもあります。遅延ロードにすると、Claude が必要なツールを探す一手間が増える。ツールを 2 つ 3 つしか繋いでいないなら、false で全部先読みした方が応答は素直です。接続数が一桁前半なら false、二桁を超えるなら auto。この分け方で実用上は足ります。判断材料はやはり /context の MCP tools 行の太さ。
呼ばれない Skill を窓の外に置く
Skill も同じ発想で削れます。disable-model-invocation: true を付けたスキルは起動時の一覧に載らず、/名前 で明示的に呼ぶまでコンテキストに入りません。モデルに自動で選ばせる必要がないスキルは、この指定で窓から外しておけます。
窓が埋まってきたときに何が残るか
残量が尽きる前に Claude Code は自動で圧縮をかけます。/compact の仕組み自体は Claude Code auto-compactの仕組みと/compactの使い方 で書いたので、ここでは /context 視点で 1 点だけ。圧縮で何が消え、何が残るかです。
System prompt, CLAUDE.md, memory, and MCP tools reload automatically. The skill listing is the one exception. Only skills you actually invoked are preserved.
公式の “What survives compaction” が挙げる例外がこれです。システムプロンプト・CLAUDE.md・memory・MCP ツールは圧縮後に自動で再ロードされる。ただし Skill の一覧だけは再注入されず、実際に呼んだスキルしか残りません。圧縮後に「使えるはずのスキルが候補に出てこない」と感じたら、この挙動が原因です。
消すのか、縮めるのか
無関係なタスクに移るなら /clear で会話を捨てる。続きの作業なら /compact で要約に畳む。診断してから選ぶのが順序です。/context で Messages が支配的だと確認できたときだけ、圧縮や /clear が効きます。原因が MCP tools 側なら、いくら会話を畳んでも軽くなりません。
窓を広げるか、会話を縮めるか
会話を削りたくない作業もあります。その場合は窓そのものを広げる選択肢があります。Fable 5、Opus 4.6 以降、Sonnet 4.6 は 100 万トークンのコンテキストに対応し、[1m] 付きのモデル名で有効化します。
ただし広い窓でも圧縮の挙動は変わりません。窓を広げるのは「会話を残したい」とき、/clear や /compact は「会話が不要になった」とき。/context の Free space を見て、どちらの問題かを先に決めます。
よくある疑問
/context はトークンを消費しますか
コマンド自体の出力は会話に残るので、わずかに Messages を増やします。とはいえ数百トークン規模。診断のために払うコストとしては誤差です。窓が逼迫してから何度も叩くより、作業の節目で 1 回見る使い方が向きます。
表示が実際の消費とずれることはありますか
あります。公式が representative numbers と書くとおり、内訳は概算です。特に MCP tools は遅延ロードの分が作業中に展開されるため、起動直後の値と進行後では数字が動く。絶対値ではなく、カテゴリ間の比率を見る道具として扱うのが実態に合います。
まとめ
/context は、何がトークンを食っているかをカテゴリ別の数字で出すコマンドです。要点を残します。
- 「重い」と感じたら
/contextで内訳を出し、Free spaceから読む - 最初のプロンプト前に System prompt・CLAUDE.md・MCP ツール名・Skill 一覧が載っている
- MCP スキーマは既定で遅延ロード。
ENABLE_TOOL_SEARCH=autoで初期消費を抑えられる - 自動起動が不要な Skill は
disable-model-invocation: trueで窓の外に置く - 圧縮で Skill 一覧は再注入されない。呼んだスキルだけが残る
- 会話が太っているのか、ツールが太っているのか。原因のカテゴリで打ち手を変える
数字を出してから手を打つ。Claude CodeのOpenTelemetry設定 でチーム全体のトークン消費を可視化するのと、考え方は同じです。