Claude Rulesが無視される、後半で言うこと聞かない——コンテキストを立て直す3つのコマンド /btw・/rewind・/clear
ルールを書いた。
.claude/rulesに構成ルールを定義して、設計書の出力形式を細かく指定した。なのに、セッションが長くなると無視される。
最初は守ってくれる。でもApp Routerの設計、Prismaスキーマ、コンポーネント設計と進むうちに、全部1ファイルに詰め込まれる。「分割して」と言う。直る。でも次のセクションでまた1ファイルに戻る。「だから分割してって」。また直る。また戻る。
プロンプトの書き方が悪いのかと思った。ルールの粒度を変えた。具体例を足した。期待される出力のサンプルまでつけた。効かない。
3回目くらいで気づいた。最初のうちは守ってくれてた。セッション序盤は完璧に分割されてた。でも作業が進んで、修正のやりとりが積み重なるほどルールが効かなくなる。
原因はルールじゃなかった。コンテキストが汚れてた。
Claudeには1回のセッションで見える範囲がある。コンテキストウィンドウと呼ばれていて、その中でルールが占めるのは最初に読み込まれた数百トークン（テキストの処理単位）ぶん。一方、途中の質問と回答、修正と再修正が何千トークンも占めてる。そりゃ埋もれる。ルールが悪いんじゃなくて、ルールが見えなくなってた。
1回の質問が、残りの全ターンに効いてくる
コンテキストウィンドウをホワイトボードに例えるとわかりやすい。書いたことは全部残る。関係ない質問も、失敗した修正指示も、消えない。
セッション中に何気なく挟む質問が積もると、コンテキストのかなりの割合を食うことがある。「これどういう意味？」「この書き方で合ってる？」くらいの軽い質問でも。地味にきつい。ただの空間の無駄じゃなくて、コンテキスト内の全テキストが次の出力に影響するから、ノイズが増えるほど精度が落ちる。
| やり方 | コンテキストコスト | 出力品質への影響 |
|---|---|---|
| メインに直接質問 | 恒久的に残る | 下がる（ノイズ増） |
/btwで確認 |
ゼロ | 影響なし |
/rewindで巻き戻し |
マイナス（ゴミが消える） | 上がる |
汚さない・汚れたら戻す・溢れたら切る。ここからはその実践の話。
/btw: 作業を止めずに方針を確認する
作業中に「今どういう方針で進めてる？」と確認したいことがある。でもそれをメインの会話に打つと、質問と回答がコンテキストに残る。
/btwはそれを解決する。一時的な別窓で、メインのコンテキストには一切残らない。
/btw 設計書の構成どうなってる？ルーティングとスキーマは分かれてる？
Claude が作業中でも中断されない。答えがインラインで返ってきて、消える。メインセッションのコンテキストは無傷。
自分の使い方はこう:
- 「開発者が理解しやすい形で分割されてる？」
- 「構成を先に決めてから書いてる？」
- 「ルール守れてる？」
方針がずれてなければそのまま。ずれてたら次の
/rewindの出番。
ただし
/btwは確認専用。ツールが一切使えないので、ファイルを読むことも、コマンドを実行することもできない。今のコンテキストに入っている情報だけで答えてくれる。
重要なのは、 /btw で方針変更を伝えてもメインのClaudeには届かない ということ。メインセッションは質問があったことすら知らない。方針変更は届かない。
変えたいなら、メインに直接割り込むか、
/rewindでやり直す。
/rewind: 間違いを「なかったこと」にする
「違う、そうじゃなくて」を繰り返すと何が起きるか。
間違った出力 + 修正指示 + 修正された出力。3つ全部がコンテキストに残る。修正を2回繰り返したら、正解の出力1つに対してゴミが5つ。コンテキストの大半が「こうしないで」の記録で埋まる。
/rewindは間違いが起きたチェックポイントまで巻き戻す。間違いも修正指示も消える。きれいな状態から、今度はもっと明確な指示でやり直せる。
/rewind # または Esc を2回押す
まず過去のチェックポイント一覧が出る。戻りたい地点を選ぶと、次の選択肢が出る:
- Restore code and conversation: コードも会話もその地点まで戻す
- Restore conversation: 会話だけ戻す（コードは今のまま）
- Restore code: コードだけ戻す（会話は今のまま）
- Summarize up to here: 選んだ地点より前の会話を要約に圧縮。最近の作業は残る
- Summarize from here: 選んだ地点以降の会話を要約に圧縮。序盤の指示は残る
設計のフェーズ1→2の切り替えで、フェーズ1の細かいやりとりを「Summarize up to here」で圧縮して持ち越すのが便利。
「修正」より「やり直し」が精度出る理由
コンテキストに間違いが残ってると、モデルはそれも参照して次の出力を作る。「こうしないで」という否定形の指示は肯定形より効きが悪い。間違いを消して、正しい指示だけある状態のほうが確実に精度が出る。
冒頭の設計書がまさにそう。「分割して」を3回繰り返すより、巻き戻して「ルーティング・スキーマ・コンポーネントの3ファイルに分けて」と1回言い直したら一発で通った。
/btw → /rewind のループ
この2つを組み合わせると安定する。
- タスクを開始する
-
/btw
で方針を確認する - ずれてなければ放置、ずれてたら
/rewind
- 巻き戻した地点から、より明確な指示で再開
- また
/btw
で確認
ポイントは コンテキストに間違いを蓄積させない こと。途中で「違う」を積み重ねるのではなく、発見したら巻き戻して正しい道だけ残す。
/clear: 話題を完全に切り替える
タスクが終わって次の作業に移るとき。前のタスクのコンテキストは全部邪魔になる。
/clearは会話履歴をまるごと消す。ただし:
- コードの変更はそのまま残る
- CLAUDE.md やメモリも残る
- プロジェクトの知識は保持される
「やり直し」が
/rewind、「別の仕事」が
/clear。
リファクタリングが終わって次はテストを書く、みたいな場面。前のリファクタリングの試行錯誤がコンテキストに残ってると、テスト生成の質に影響する。
/clearして「テストを書いて」から始めたほうがいい。
/branch と claude -w: 並行作業するなら
/branchは会話履歴を分岐させる。過去のチェックポイントから別の会話を派生できる。
正直、まだ使いどころがわからない。
理由はシンプルで、会話だけ分岐してファイルシステムは共有されてる。両方のブランチで同じファイルを触ったら事故る。「どっちの変更が正？」が曖昧になる。
コードごと分離したいなら
claude -wのほうが安全だと思ってる。
claude -w feature-auth
これはgitのworktree（独立した作業ディレクトリ）を作って、物理的に別ディレクトリで作業する。ファイルが衝突する可能性がゼロ。
-
/branch
: 会話は分岐、ファイルは共有 → 同じファイル触ると危ない -
claude -w
: 会話もファイルも完全分離 → 安全だけどセットアップが一手間
並行して「API設計」と「コンポーネント設計」を進めたいとき、
claude -wで2つの作業を完全に分けるほうが確実。終わったらgitでマージすればいい。
使い分け早見表
| やりたいこと | コマンド | コンテキストへの影響 |
|---|---|---|
| 方針が合ってるか確認 | /btw |
残らない |
| 方向がずれた、やり直し | /rewind |
間違いが消える |
| 別の仕事に切り替え | /clear |
全部消える（コードは残る） |
| コードごと並行作業 | claude -w |
完全に別世界 |
| 会話だけ分岐（上級者向け） | /branch |
ファイル共有に注意 |
余談: 裏で何が起きてるか
ここからは興味がある人向け。
/btwが軽い理由を仕組みから説明する。
Claude APIはステートレス。サーバーは前の会話を覚えてない。
「え、でもセッション中はちゃんと前の話を覚えてるじゃん」と思うかもしれない。あれはClaude Code（手元のアプリ）が会話の全文をローカルに保存していて、毎ターンその全文をサーバーに送り直してる。サーバーは毎回「初めまして」の状態で、全文が来るから文脈がわかるだけ。
だから会話が長くなれば送信量も増えるし、ゴミが混じってたら毎回ゴミごと送り直すことになる。コンテキスト管理が精度に直結する理由がここにある。
「え、非効率じゃない？」と思うけど、ここでプロンプトキャッシュが効いてくる。
Claude Codeが裏でキャッシュポイントを設定していて、「ここまでは前回と同じ」と判断できる部分のGPU処理をスキップする。キャッシュが効いた部分の処理コストは通常の1/10。送信はされるけど処理は再利用される。
/btwのエージェントはメインセッションのキャッシュをそのまま借りる。だから会話全体を1から処理し直す必要がなくて、ほぼコストがかからない。
さらに言うと、会話が長くなりすぎたら自動圧縮（compaction）も走る。コンテキストが限界に近づくと、古いやりとりを要約に圧縮してくれる。完全に放置しても破綻はしないけど、そこまで膨らむ前に自分で
/rewindや
/clearで管理するほうが精度は高い。
仕組みがわかると、なぜコンテキスト管理が効くのか腑に落ちると思う。
コンテキストは勝手に汚れる
/btwで確認してもコンテキストは汚れない。/rewindで巻き戻せばルールが効く状態に戻る。/clearで切り替えれば次のタスクはクリーンに始まる。
振り返ると、精度が落ちてたときは全部コンテキストの状態が原因だった。