Claude Codeが前の指示を忘れるときの対策｜コンテキスト不足を見分けて立て直す

Claude Codeとの作業が長くなると、「禁止したファイルへ触れた」「決めた完成条件と違う方向へ進んだ」と感じることがあります。同じ指示を長文で貼り直す前に、まず手を止めてください。原因は1つではありません。会話の情報量が増えて序盤の指示が押し出されたのか、それとも最初から仕様に複数の解釈が残っていたのか。この2つは対処がまったく違います。

この記事では、現在の状態を壊さずに原因を見分け、必要な情報だけを残して作業を再開する手順を、公式ドキュメントの記述にもとづいて紹介します。

まず「忘れた」と決めつけず、変更を止める

最初にやることは、新しい修正を頼むことではありません。変更を止めて、いま起きていることを記録することです。誤った変更の上にさらに修正を重ねると、どこから壊れたのか分からなくなります。

「忘れた」という感覚は、観測できる差に置き換えます。よくある症状は次のとおりです。

• 変更禁止と伝えた範囲のファイルに触れた
• 採用しないと決めた案へ戻った
• 完了した調査をもう一度やり始めた
• 未実行のテストを「実行済み」として扱った

公式の仕組み解説によると、コンテキスト(=Claudeが応答のたびに参照する作業記憶)には、会話の履歴だけでなく、読んだファイルの中身、コマンドの出力、CLAUDE.md、自動メモリ、読み込まれたSkillsまで入ります。大きなログを読ませただけでも使用量は増えます。そして上限に近づくと、古いツール出力から先に取り除かれ、その後に会話が要約されます。このとき序盤の詳しい指示が失われる場合がある、と公式に書かれています。

つまり「会話の最初に言ったのに」という指示ほど、長い作業では消えやすい位置にあります。これは故障ではなく仕組みです。だからこそ、症状が出たら次の3点を先にメモしてください。

1. 直前まで守られていた具体的な指示
2. 実際に起きた変更や発言
3. 期待していたファイル・出力・確認結果

これで「何となく忘れた」を、比較できる不一致に変えられます。

コンテキスト不足か仕様不足かを3段階で見分ける

切り分けは、状態 → 指示 → 結果の順に行います。

第1段階: /context で中身を見る。 公式のコマンド一覧によると、/context は現在のコンテキスト使用量を、会話・ファイル・ツール出力などに分類して表示します。使用量が大きく、序盤の会話にしかなかった指示だけが抜けているなら、コンテキスト不足の可能性が高まります。

第2段階: 依頼を読み直す。 対象ファイル、完成条件、変更禁止範囲、検証方法が最初から書いてあったでしょうか。「ログイン画面を直す」だけでは、見た目・認証処理・エラー表示のどれか決まりません。この場合は仕様不足です。短い会話でもずれます。Claude Codeへの指示の書き方を使い、対象・完成・禁止へ分解してください。

第3段階: 説明と実物を照合する。 Claudeの説明ではなく、実際の差分を見ます。Gitを使っているなら git diff です。Git公式の説明のとおり、引数なしの git diff で、まだ確定していない作業中の変更を一覧できます。

注意したいのは、残量の割合だけで原因を確定しないことです。Anthropicのプラットフォーム公式解説は、コンテキストは多ければ自動的に良いわけではなく、トークン(=文章の量の単位)が増えると正確さと想起が下がると説明しています。「何%を切ったら必ず忘れる」という固定の数字は公式にもありません。

また、/context の表示自体に版ごとの修正が入ることがあります。公式の変更履歴には、圧縮後の /context が古い使用量を表示する問題の修正が記録されています。画面の数字が説明と合わないときは、claude --version と変更履歴も見比べてください。

症状ごとの切り分け表

観測した症状	主な原因候補	最初に行う確認	次の対応
序盤に伝えた禁止事項だけが抜けた	圧縮による序盤指示の喪失	/context で使用状況を確認	恒久ルールを短くしてCLAUDE.mdへ移す
短い会話でも完成形がずれる	完成条件や対象範囲の不足	依頼に対象・完成・禁止があるか確認	測れる条件を補って1工程だけ依頼する
大きなログを読ませた後に不安定になった	ツール出力による使用量の増加	/context で重い項目を確認	必要部分だけ残し、焦点を指定して /compact
実行済みと未実行が混ざる	作業記録の不足	コマンド名と出力の証拠を確認	証拠がない項目を未実行へ戻す
別の作業へ移った後も前の話を引きずる	無関係な履歴の持ち越し	今回必要な履歴か確認	引継ぎメモを残して /clear

この表は診断の確定ではなく、最初の確認先を選ぶ目安です。症状が重なるときは、先に差分と実行結果を保存してから切り分けます。

残す情報を分け、同じ抜けを仕組みで防ぐ

再発防止の芯は、毎回守ってほしい情報を「会話の序盤」という消えやすい場所に置かないことです。

公式のメモリ解説によると、セッション(=1回の会話)はそれぞれ新しいコンテキストで始まり、会話をまたいで情報を残す仕組みは、人が書くCLAUDE.mdと、Claudeが書く自動メモリの2つです。共通のビルド手順、変更禁止範囲、命名規則のような恒久ルールは、短く具体的にCLAUDE.mdへ置きます。同じページは、具体的で簡潔な指示ほど守られやすいとも説明しています。書き方の粒度はCLAUDE.mdの書き方で整理しています。

ただし、今回だけの進捗や仮説までCLAUDE.mdへ詰め込まないでください。今回の作業メモは別のファイルに分けます。次の6項目で足ります。

作業メモ
- 目的:
- 完了条件:
- 変更してよい範囲:
- 変更禁止:
- 実行済みと証拠:
- 次の一手:

未確認のことは「未確認」と書き、予定と実績を混ぜません。別のセッションへ移るときは、AIコーディングの引継ぎメモの形で実行済みと未実行を分けて渡します。

もう1つ、公式が示している代替手段があります。絶対に毎回実行させたい機械的な処理は、CLAUDE.mdに書くのではなくフック(=決まったタイミングで自動実行されるコマンド)にするという選択肢です。CLAUDE.mdは強制設定ではなくコンテキストとして扱われるため、書けば必ず従うという保証はありません。「テスト前に必ず整形を走らせる」のような機械的処理は、フックのほうが確実です。

圧縮との関係も知っておくと安心です。コンテキストウィンドウの解説によると、プロジェクト直下のCLAUDE.mdは圧縮後に再び読み込まれます。一方、子ディレクトリのCLAUDE.mdやパス指定のルールは、対象ファイルを再び読むまで戻りません。「書いたのに効いていない」と感じたら、どの階層に書いたかも確認してください。

/compact・/clear・/rewindを目的で使い分け、1工程だけ再開する

コマンドを打つ前に、必ず現在の状態と差分を保存してください。順番を逆にすると、消えて困る情報ごと整理してしまいます。

コマンド早見表

コマンド	何をするか	使いどき	注意
/context	使用量の内訳を表示	切り分けの最初	表示の不具合は版によって修正あり
/compact	会話を要約に置き換える	同じ作業を続けたいとき	/compact API変更と未実行テストを優先 のように焦点を指定できる
/clear	空のコンテキストで新しい会話を始める	無関係な作業へ移るとき	前の会話は保存され /resume で戻れる
/rewind	チェックポイントへ会話やコードを戻す	直前の変更を取り消したいとき	Bashや外部プロセスの変更は対象外。Gitの代わりではない

セッション管理の公式解説によると、/clear をしても前の会話はローカルに保存され、/resume から再開できます。「消えるのが怖くて /clear できない」は心配しすぎです。逆に、/clear を最初の一手にするのも乱暴です。まず記録、それから整理、の順を守ってください。

/rewind については公式ベストプラクティスに大事な注意があります。チェックポイントが記録するのはClaudeのファイル編集ツールによる変更で、Bashコマンドや外部プロセスがファイルを変えた分は含まれません。公式にもGitの代替ではないと明記されています。だから再開前の確認は git diff のような実物の差分で行います。

同じベストプラクティスは、同じ問題を1つのセッションで2回を超えて訂正したら、学んだ内容を具体的な指示に反映して /clear でやり直すことを勧めています(これは製品の強制ルールではなく運用上の推奨です)。失敗した試行が積み重なった会話は、それ自体がノイズになるからです。

立て直したら、次の一手は1工程だけにします。調査・実装・検証を一度に混ぜません。

現在の差分を前提に、次は認証エラー表示だけを修正してください。
対象は src/pages/login.astro です。
共通CSSと認証設定は変更しません。
完了後は変更行と実行した確認を報告してください。

対象・禁止・証拠がそろっていれば、再開直後のずれをすぐ発見できます。指示が長くなりすぎるときは指示が長すぎて逆に伝わらない問題も参考にしてください。

よくある質問

Claude Codeが本当に指示を忘れたかどうかは、どう確認できますか？

まず /context で何がコンテキストを使っているか確認します。次に、元の依頼・Claudeの現在の説明・実際の差分の3つを比べます。完成条件や禁止範囲が最初から曖昧だったなら、コンテキスト不足ではなく仕様不足です。その場合は情報を足すのではなく、測れる条件に書き直すのが先です。

/compactと/clearはどう使い分けますか？

同じ作業を続けながら履歴を軽くするなら、残したい論点を指定した /compact です。無関係な別作業へ移るときや、失敗した試行が積み重なったときは、作業メモと差分を保存してから /clear で空の状態から始めます。

/clearすると前の会話は消えて戻れなくなりますか？

消えません。公式の説明では、/clear 後も前の会話は保存され、/resume から再開できます。ただし「いまの現在地」は会話の外の引継ぎメモにも残してから使うのが安全です。

CLAUDE.mdへ書けば、指示は必ず守られますか？

必ずではありません。公式ドキュメントでは、CLAUDE.mdも自動メモリも強制設定ではなくコンテキストとして扱われます。短く具体的に書くほど守られやすくなりますが、毎回必須の機械的処理はフック、成果の確認はテストやビルドなど、別の仕組みで補うのが公式の示す方向です。

/rewindがあればGitは使わなくても大丈夫ですか？

大丈夫とは言えません。チェックポイントはClaudeのファイル編集による変更が対象で、Bashや外部プロセスの変更は記録されず、公式にもGitの代替ではないとされています。差分の確認と履歴の保管は、Gitのような別の仕組みで持ってください。

まとめ

「忘れたように見える」の正体は、コンテキスト不足のことも、仕様不足のこともあります。残量の数字だけで決めつけず、記録 → 切り分け → 整理 → 1工程だけ再開、の順で立て直してください。次にやることは3つです。

• 症状が出たら新しい修正を頼まず、目的・期待・実際の差と git diff の結果を先に保存する
• /context で状態を見てから、/compact(続ける)か /clear(移る)かを選ぶ
• 毎回守ってほしいルールは会話に置かず、短く具体的にCLAUDE.mdへ移す(機械的な必須処理はフックも検討する)

コマンドの細かい仕様や上限値は変わることがあります。運用に組み込む前に、その時点の公式案内で確認してください。

公式一次情報

確認日: 2026-07-26

• How Claude Code works: コンテキストに入るもの(会話・ファイル・コマンド出力・CLAUDE.mdなど)と、上限接近時に古いツール出力から除かれ序盤の指示が失われ得る仕組みの説明
• Explore the context window: ファイル読み込みで使用量が増えること、/compact の要約の仕組み、圧縮後にプロジェクト直下のCLAUDE.mdが再注入されることの説明
• How Claude remembers your project: CLAUDE.mdと自動メモリはどちらも強制設定ではなくコンテキストであること、毎回必須の処理にはフックという選択肢があることの説明
• Manage sessions: セッションが保存され、/clear 後も /resume で前の会話へ戻れることの説明
• Commands: /clear・/compact・/context・/resume・/rewind など組み込みコマンドの役割一覧
• Best practices for Claude Code: 具体的な指示と検証可能な合格条件、無関係な作業間での /clear、チェックポイントがGitの代替ではないことの説明
• Claude Code cheatsheet: 初心者向けの用語集。コンテキストウィンドウが満ちると古い内容が圧縮・除外されることの説明
• Context windows: コンテキストは作業記憶であり、多いほど良いわけではなく、増えると正確さと想起が下がることの説明
• Changelog: 圧縮後の /context 表示の不具合修正など、版ごとの変更履歴
• Git - git-diff Documentation: 引数なしの git diff で未ステージの作業中の変更を確認できることの説明