Claude Code コマンド整理術｜「重い」の正体はコンテキスト

この記事でわかること

Claude Code のセッションで、実際に何が消費されているのか
「重くなったら閉じて作り直す」より、ずっと安いやり方
/compact と /clear の違いと、どちらを打つべきかの判断基準
毎回の前提説明を CLAUDE.md に移して、説明そのものをなくす方法
見かけたコマンドが動かなかったときに、自分で確かめる方法

対象は、Claude Code をすでに使っている方です。プロンプトを打って結果を受け取る流れには慣れてきたけれど、スラッシュコマンドはあまり使っていない、というあたりを想定しています。ターミナルと Git の基本操作は前提としますが、それ以外はこの記事の中で説明します。

1. なぜ Claude Code は「重くなる」のか

作業を進めているうちに、返事がだんだん遅くなる。さっき伝えたはずの前提を忘れている。そんなとき、多くの人は画面を閉じて最初からやり直します。

実はこれが、いちばん高くつくやり方です。

いま重くて困っている方は、4章の判断表まで飛んでください。ここから先は、なぜそうなるのかの話です。

コンテキストウィンドウ ― 会話もファイルも同じ枠を使っている

Claude Code とのやり取りでは、次のものが同じひとつの枠を共有しています。

これまでの会話
読み込んだファイルの中身
コマンドの実行結果
CLAUDE.md などの設定

この枠をコンテキストウィンドウと呼びます。名前のとおり有限です。埋まってくると応答が鈍り、それまでのやり取りをそのままの形では保持できなくなります。会話が長くなるほど重くなるのは、このためです。

チャット画面に慣れていると、会話はいくらでもスクロールできるものに感じます。でも実際には、会話を続けること自体にコストがかかっています。ここさえ押さえれば、 Claude Code のコマンドの大半は自然に整理できます。

整理の軸は「減らす・見る・戻す」

コンテキストが有限のリソースなら、打てる手も限られます。

減らす — 毎回同じ説明をしなくて済むようにする
見る — いま何がどれだけ枠を使っているかを知る
戻す — 埋まった枠を空ける

この3つに、そもそも枠を汚さないという一手を加えると、打てる手はほぼ出そろいます。この記事も、この順番でコマンドを紹介していきます。名前を覚えるのではなく、「いまやりたいのはどれか」で引けるようになるのが目標です。

Visual Note 1: コンテキストのライフサイクルと4つの介入点

スラッシュコマンドは、AI へのお願いではありません

先頭に / を付けて入力するものをスラッシュコマンドと呼びます。これは Claude への依頼ではなく、Claude Code というツール自体への操作です。

「コンテキストを圧縮しておいて」と文章で頼んでも、会話は要約されません。 /compact と入力して実行する必要があります。細かい話ですが、最初につまずくのはたいていここです。

2. 減らす ― 毎回同じ説明をやめる

新しいプロジェクトを始めるたびに、使っている技術を説明し、コーディング規約を伝え、ディレクトリ構成を書く。よくある光景です。

この説明は毎回コンテキストを消費します。しかも内容はほとんど変わりません。それならファイルに書いて置いておけば済みます。それが CLAUDE.md です。

/init ― プロジェクトの説明書を自動で作る

/init

Claude がプロジェクトを読み取り、構成や依存関係、規約をまとめた CLAUDE.md を作ります。ゼロから手で書く必要はありません。

ただ、できたものをそのまま使うのはおすすめしません。自動生成なので、「このディレクトリは移行中なので触らない」「このライブラリは非推奨だが残っている」といったチーム固有の事情までは拾えないからです。叩き台として受け取って、足りない前提を書き足す。この使い方が現実的です。

/memory ― プロジェクトをまたぐ好みを書く

/memory

CLAUDE.md とメモリ設定を編集するコマンドです。ここで知っておきたいのは、 CLAUDE.md はひとつではない、という点です。

たとえば、次のような指示を毎回書いていませんか。

- まずテストから書いてほしい
- 継承より合成を優先してほしい
- 複雑な処理にはコメントで意図を書いてほしい
- 断りなく any を使わないでほしい

これらはプロジェクトが変わっても言い続けることです。であれば、プロジェクト直下ではなくユーザー単位のファイル（~/.claude/CLAUDE.md）に置きます。毎回同じことを書き直しているなら、それは上の階層に移すサインです。

CLAUDE.md はさらに細かく階層を分けられ、分け方しだいでルールの効き方が変わります。そこは1本の記事になる話なので、詳しくは CLAUDE.md は「4層」に分けると安定するを参照してください。

この2つは時短の話に見えますが、実際にはコンテキストの節約でもあります。説明に使っていた枠が、そのまま作業に回せるようになります。

3. 見る ― 見えないものは管理できない

「なんとなく重くなってきた気がする」で判断していると、打つべきタイミングを逃します。まず、いま何がどれだけ枠を使っているのかを見ます。

/context ― 何が枠を占めているかを見る

/context

いまのコンテキスト使用量を、色分けしたグリッドで表示します。残量がわかるだけでなく、内訳が見えるのが大事なところです。

よくあるのが、調査のために読み込ませた大きなファイルやログが、枠の大半を占めているケースです。会話が長いせいだと思っていたら、原因は1回の読み込みだった。これは /context を見ないと気づけません。原因がわかれば、次に打つ手も決まります。

重くなったと感じたら、まずこれです。

/usage ― コストと使用量を確認する

/usage

セッションのコスト、プランの使用量、利用状況を表示します。 /cost と /stats は同じコマンドの別名なので、どれで打っても構いません。

/context が「枠の残り」を見るものだとすれば、/usage は「お金と上限の残り」を見るものです。役割が違うので、両方知っておくと安心です。

/autocompact ― 実は放っておいても要約される

/autocompact

いまの Claude Code は、コンテキストが一定まで埋まると自動的に会話を要約します。このコマンドは、その発動タイミングを設定するものです。

ここは押さえておく価値があります。放っておいても要約されるということは、次に紹介する /compact は「詰まる前の救命措置」ではない、ということです。自分の好きなところで区切るための、手動の操作だと考えてください。

4. 戻す ― セッションを捨てない

ここが本題です。行き詰まったときの選択肢は、「閉じてやり直す」だけではありません。

/compact ― 要約して枠を空ける

/compact

それまでの会話を要約して、コンテキストを空けます。作業内容や決めたことは要約として残るので、文脈を失わずに枠だけ回復できます。

打つのは、区切りのいいタイミングです。ひとつの機能を実装し終えたとき。設計の方針が固まったとき。「ここから先は別の作業」と思えたとき。作業の切れ目で打っておくと、その後が軽くなります。

なお /compact は、後ろに要約の方針を書いて渡せます。

/compact 認証まわりの決定を残して

長い調査のあとで「この部分だけは落としたくない」というときに使えます。

/clear ― 文脈を捨てて仕切り直す

/clear

空のコンテキストで新しいセッションを始めます。/compact が要約して残すのに対して、こちらは文脈を捨てます。

同じ提案が何度も返ってくる。話が完全に脱線した。そもそも別の作業に移りたい。こういうときは要約しても意味がないので、/clear で仕切り直します。

不安になるところですが、前のセッションは消えていません。 ディスクに残っていて、あとから戻れます。安心して打って大丈夫です。

/resume と /rewind ― 捨てても戻れる

/resume

前の会話を再開します。/continue は別名です。/clear したあとで「やっぱりさっきの続きが要る」となっても、ここから戻せます。

/rewind

会話を過去の地点まで巻き戻します。/checkpoint、/undo は別名です。

たとえば、3回前のやり取りで方針を取り違えて、そこから先がすべて的外れになった。こういうときに、全部を捨てずに、おかしくなる前まで戻せます。 /clear の手前にある中間的な選択肢だと考えてください。

結局どれを打つか ― 判断基準は「作業を続けたいか」だけ

迷ったときの基準はひとつです。いまの作業を続けたいかどうか。

状況	打つもの	何が起きるか
作業は続けたい。ただ重い	`/compact`	文脈を要約して残す
数手前から間違えた	`/rewind`	その地点まで戻す
話が脱線した／別の作業に移る	`/clear`	文脈を捨てる
さっきの会話に戻りたい	`/resume`	前のセッションを開く

「閉じてやり直す」が選択肢に入っていないことに注目してください。この4つで、たいていの場面は間に合います。

Visual Note 2: 症状から引くコマンド判断フロー

この図には、5章と7章で出てくる症状（作業中に別のことが気になった、動作がおかしい）も入れてあります。困ったときの逆引きに使ってください。

5. そもそも汚さない ― 本筋を止めずに寄り道する

コンテキストは、空けるより最初から汚さないほうが効率的です。そのための手段が2つあります。

/btw ― 主線を止めずに横の質問をする

/btw リフレッシュトークンの保存先は、一般的にどこが使われますか？

実装に集中しているときに、ふと別の疑問が浮かぶことがあります。そのまま聞くと、いま進めている作業の文脈に関係のない話が混ざります。かといってメモして後回しにすると、たいてい忘れます。

/btw は、進行中の作業を止めずに横道の質問を投げるためのコマンドです。公式の説明も「主となる会話を中断せずに、ちょっとした横の質問をする」となっています。思いついたことを、主線を汚さずに片づけられます。

! ― シェルの出力をその場で取り込む

行頭に ! を付けると、シェルコマンドをその場で実行して、出力を会話に取り込めます。

! git status
! npm test

git status の結果を Claude に見せたいとき、ターミナルに切り替えて実行し、出力をコピーして戻ってきて貼り付ける。この往復が要らなくなります。

注意点が2つあります。ひとつは、これは「Claude にコマンドを実行させる」ものではなく、「自分で実行して、その結果を会話に流し込む」ものだということ。もうひとつは、流し込んだ出力もコンテキストを消費するということです。数千行のテストログをそのまま取り込むと、かえって枠を圧迫します。必要な部分に絞って渡します。

6. 出力の質と速度を変える

ここまでは「コンテキストの量」の話でした。ここからは別の軸で、返ってくる答えの質と速度を調整するコマンドです。

/model ― セッションの途中でモデルを切り替える

/model

ひとつのセッションの中で、モデルを切り替えられます。込み入った設計を考えるときと、決まった内容を素早く書き出すときでは、向いているモデルが違います。

具体的なモデル名はこの記事には書きません。入れ替わりが早く、すぐ古くなるからです。 /model を実行すれば、そのとき使えるものが表示されます。

/fast と /effort ― 応答の速さと労力を調整する

/fast

高速モードのオン・オフを切り替えます。アイデアを試している段階や、とりあえず動かして確かめたい段階など、応答が速いほうが作業のテンポに合う場面があります。そのときに使います。

/effort

モデルがどれだけ労力をかけて取り組むかを設定します。/fast と近い領域ですが、こちらは労力そのものの調整です。急ぎたい場面と、慎重にやりたい場面で使い分けます。

7. 環境そのものがおかしいとき

コマンドが効かない。返事が明らかに変。設定の問題なのか、権限なのか、インストールが壊れているのかもわからない。そういうときのためのコマンドです。

/doctor ― 入れ直す前に、まずこれ

/doctor

Claude Code の環境状態を診断します。/checkup は別名です。

再インストールする前に、まずこれを実行してください。原因が環境側にあるのかそうでないのかの切り分けができます。入れ直しは、それでも直らなかったときの話です。

/terminal-setup ― 名前から誤解されやすいコマンド

/terminal-setup

ターミナルの改行キーバインド（Option+Enter や Shift+Enter など）を設定します。長い指示を複数行で書きたいのに、改行しようとして送信されてしまう。あれを防ぐためのものです。

この名前から「Claude にターミナルの出力を見せる設定」だと説明されることがありますが、そうではありません。ターミナルの出力を渡したいときは、5章で紹介した ! を使います。

8. 情報は古くなります ― だから /help を打つ

最後に、この記事の賞味期限の話をします。 AI ツールのコマンドは追加も改名も廃止も頻繁に起こるので、どんな記事も書かれた瞬間から古くなり始めます。この記事も例外ではありません。

/help ― 現物を確認する習慣

/help

使えるコマンドの一覧と、それぞれの短い説明が表示されます。

このコマンドの本当の価値は、困ったときのヘルプであることではありません。記事に書かれた情報と、手元の現実を突き合わせる手段であることです。

どこかで見たコマンドが動かなかったら、/help で現物を確認する。

コマンド名は変わります。でも「コンテキストは有限で、減らす・見る・戻すという 3つの介入点がある」という構造は、そう簡単には変わりません。構造を覚えて、名前は毎回確認する。これがいちばん寿命の長いやり方です。

まとめ

Claude Code で行き詰まる原因は、モデルの性能ではないことがほとんどです。コンテキストという有限のリソースを、管理せずに使い切っているだけです。

覚えておきたいのは、コマンドの一覧ではなく次の3語です。

減らす — /init と /memory で、毎回の説明をなくす
見る — /context で残量と内訳を確認する
戻す — /compact で要約し、/clear で仕切り直し、/resume と /rewind で戻る

そして、詰まったときに画面を閉じないこと。これだけで日々の手戻りはかなり減ります。

次にセッションが重くなったら、まず /context です。何が枠を使っているかが見えると、その次に打つコマンドは自然に決まります。