Claude Code のコンテキスト圧縮のあと、AI は同じには戻らない — 何が落ちるかと、ファイルで認識を合わせ直す運用

いつもと同じ調子で指示を出しているのに、返ってくるものが、なんとなく前と違う。
書かせている文章の語尾が変わっていて、少し前に決めたばかりの細かい取り決めが効かなくなっている。
履歴をさかのぼると、途中で自動の要約が挟まっていました。

Claude Code は、会話が長くなってコンテキスト（AI が一度に覚えていられる会話の量）が上限に近づくと、それまでの履歴を要約に置き換えます。
コンパクションと呼ばれる動きで、こちらが頼まなくても必要になった時点で挟まります。
そのあと、まったく同じ振る舞いには戻りません。

この記事で扱うのは、圧縮のあとに何が残って何が落ちるのかの整理と、会話で伝え直す以外の手段です。
作業メモの雛形と、圧縮に気づいたら打つ短い確認プロンプトも一緒に置いておきます。

書いているのは体感で、前後の分量を測ったわけでも、出力を並べて採点したわけでもありません。
仕様として確認が取れているのは、モデル側から圧縮の発生を検出できないことと、手動の `/compact` に残す内容を指示できることの2点だけです。
それ以外は、日常的に長いセッションを回している中で気づいた範囲の話になります。

幹は残り、細かい考え方が落ちる

何を作っていて、どこまで進んだかという幹の部分は、だいたい残っています。
落ちるのは、その周りにあった細かい考え方です。

繰り返し見ているのは、この3つです。

• 出力の質感が変わる。言葉遣いが少し動いて、文章のクオリティやニュアンスがずれる

• 途中で決めた「今回はこうする」という一時的なルールが効かなくなる

• 一度合意したはずの前提を、もう一度説明し直すことになる

3つ目は、ファイルに書いてある内容なら起きにくい。
効かなくなるのは、会話の中だけで決めた部分です。

質感の変化は、いちばん気づきにくいところだと思います。
間違ったものが返ってくるわけではないので、レビューでは引っかかりません。
文章を書かせている場合だと、語尾の癖が変わったあたりで気づくことが多い、というのが私の体感です。

自動で挟まる圧縮には、残すものを指定できない

圧縮は要約なので、必ず取捨選択が起きます。
そして自動で挟まる分については、その基準がこちらの手の内にありません。
「この決めごとは絶対に残して」と会話で頼んでも、その頼み自体が要約の対象です。

手動なら少し違います。
`/compact` は引数を取れるので、`/compact "決定事項と作業ルールを残して"` のように、何を優先して残すかを添えられます。
ただし効くのは、自分で打ったその1回だけです。
そのあと自動で挟まる分までは、事前に狙えません。

もうひとつ、運用に効いてくる仕様があります。
モデル側からは、圧縮が起きたかどうかを検出できません。
セッションの開始直後も、圧縮の直後も、普通の途中も、向こうから見ると同じ状態です。

つまり「圧縮されたら作業メモを読み直して」という条件付きのルールは書けません。
条件を判定する手段がないからです。
気づく役目は人間の側にある、という前提で組む必要があります。

会話に置いたルールは、消えたら戻せない

様子がおかしいと気づいたとき、最初にやるのはチャットで伝え直すことだと思います。
それで直ります。
ただ、直るのはその場かぎりです。
言い直した内容も履歴の一部なので、次の圧縮ではまた候補になります。

差が出るのは、消えたあとに戻せるかどうかです。
会話の中だけで決めたことは、要約に巻き込まれた時点で元の文言がどこにも残っていません。
思い出して打ち直すしかなく、その再現がどこまで正確かは自分でも分からない。
ファイルに書いたことは実体が手元にあるので、読ませ直せば同じ内容がそのまま戻ります。

`CLAUDE.md` は圧縮のあとに自動で読み直される、という説明を見かけます。
ただ、そうならなかったという報告も公式のイシューに出ていて、この挙動は揺れているようです。
自動で戻ることに賭ける形にはしないほうがいい。
狙うのは、こちらが一行打てば確実に元へ戻せる状態のほうです。

ファイルの役割を3つに分ける

全部を1枚に書くと破綻するので、置き場所を性質で分けます。

恒久ルール → `CLAUDE.md`

プロジェクトが続くかぎり変わらないものを置きます。
使う言語とバージョン、命名規則、ディレクトリ構成、返答の形式、やらないこと。
明日も同じことを言う内容なら、この階層に入れます。

進行中の作業文脈と決定事項 → `NOTES.md`

今日決めたこと、いまのタスク、その場かぎりのルール、保留にした論点を書きます。
プロジェクト直下に置いて、必要なときに読ませる形で使います（読ませ方は後述します）。
ファイル名は好きなもので構いません。
この記事では `NOTES.md` で通します。

調査結果や長い出力 → レポートファイル

調べた内容を会話に貼らせると、それ自体が履歴を膨らませて次の圧縮を早めます。
結果はファイルに書き出させて、会話にはパスだけ残す。
置き場所は `docs/reports/` のようにまとめるか、`NOTES.md` と同じ階層に並べておけば足ります。
こうしておくと、セッションが変わっても調べ直しが要りません。

NOTES.md の雛形と、太らせない決まりごと

そのまま貼って使える形にしたのがこれです。

# 作業メモ

## いま何をやっているか
- ゴール:
- 現在の段階:

## 決めたこと（覆すときは行ごと書き換える）
- 2026-08-06 ○○の方式は A を採用。理由:
- 2026-08-06 △△には手を入れない。理由:

## 今回だけのルール
- 出力は日本語、コード内コメントは英語
- 既存の関数シグネチャは変えない

## 次にやること
1.
2.

## 保留・未解決
-

節はこの5つで足ります。
増やすと書かなくなるので、5つで止めます。

書くのは自分でなくても構いません。
決めごとが出たところで、そのまま頼めば足ります。

いま決めた方針を NOTES.md の「決めたこと」に1行で追記して

決めごとが出た瞬間に足す、という部分だけは守っています。
あとでまとめて書こうとすると、そのときにはもう圧縮が入っていて、何を決めたのか自分でも曖昧になっています。

そして、このファイル自体も太らせません。
40行から50行くらいを上限の目安にして、終わったタスクの行は消していきます。
`CLAUDE.md` に書きすぎると埋もれるのと同じことが、`NOTES.md` でも起きます。

決定を覆したときは、追記ではなく該当の行を書き換えます。
古い決定が下に残っていると、AI がそちらを前提にして走り出すことがあります。

圧縮が起きたと分かるサイン

自動の圧縮は静かに入るので、気づかないまま作業を続けがちです。
目印にしているのは3つ。

• 画面に圧縮中の表示が出て、それまでのやりとりが要約に置き換わる（表示のされ方は環境やバージョンで変わる）

• 語尾や言葉遣いが変わる

• こちらが説明済みの前提を、もう一度聞き返してくる

2つ目と3つ目は圧縮以外の理由でも起きますが、揃って出てきたら疑っていいと思います。

圧縮のあとに打つ確認プロンプト

気づいたとき、あるいは新しいセッションを開いたときに打つのがこれです。

NOTES.md を読んで、進行中のゴール・決定事項・今回だけのルールを
箇条書きで復唱してから、続きに入ってください。

復唱させる部分が要点です。
読ませるだけだと、読んだのかどうか、どう解釈したのかが分かりません。

ただし復唱には穴があります。
会話にまだ残っている情報だけで、それらしい箇条書きを組み立てられてしまう場合があるからです。
見分けたいなら、会話には一度も出していない一行を `NOTES.md` に入れておきます。
保留にした論点あたりが向いています。
その行が復唱に出てくれば、ファイルを実際に読んでいます。

復唱の内容が自分の認識とずれていたときは、ファイルのほうを直します。
口頭で訂正しても、次の圧縮でまた同じずれが出ます。

圧縮を条件にしたルールは書けませんが、条件のないルールなら置けます。
「作業の区切りごとに `NOTES.md` を読み直す」「新しいファイルへ着手する前に決定事項を確認する」といった形です。
判定のいらない習慣にしておけば、圧縮を検出できなくても結果的に間に合います。

前のセッションの履歴から検索して拾い直す手もあります。
ただ、そうすると要らない試行錯誤や捨てた方針まで一緒に入ってきます。
必要なことをファイルに書き出して、そこだけ読ませるほうが安定すると考えています。

日をまたぐ開発と、長丁場のリファクタリング

効きやすい場面を2つ挙げます。

日をまたぐ開発では、圧縮より先にセッションのほうが切れます。
昨日の決定事項を今日また説明するところから始まるなら、その説明の中身が `NOTES.md` に入るべきものです。
翌朝は復唱から始めれば、前日の終盤と同じ前提に戻せます。
よく見返すのは「決めたこと」の節です。

長丁場のリファクタリングでは、圧縮が複数回入ります。
命名規則や、触らないと決めたファイルの範囲は、後半ほど守られなくなります。
このあたりは今日だけのルールではないので、`CLAUDE.md` 側へ移してしまうほうが確実です。

なお、長いセッションで出力が崩れる原因は圧縮だけではありません。
圧縮が入る前の、コンテキストが膨らんでいく過程でも精度は落ちます。
そちらへの対処は別記事に分けました。

ファイルを作る前に試せる、もっと安い手

その前に確かめておきたいことがあります。

切りのいいところで、自分から `/compact "決定事項と作業ルールを残して"` を打っておく。
自動で挟まるのを待つより、残すものを指定できるぶん結果が読めます。
`/context` を打てば、いま何がコンテキストを食っているかが見えます。
区切りが付いているなら、`/clear` して要点を渡し直すのがいちばん速い。

これで足りる場面は、思っているより多いです。
ファイルでの認識合わせが要るのは、日をまたぐ場合と、同じ決めごとを何度も使い回す場合です。

毎回書くほうが遅くなる場面

この運用は万能ではありません。

半日で終わる作業だと、書く手間のほうが上回ります。
振る舞いが多少変わるのを承知したうえで、圧縮が入ったまま最後まで進める日もあります。
ファイル化は手段であって、常に必須ではありません。

どのルールが落ちて、どれが残るのかの規則性も、まだ掴めていません。
そのため「重要なものだけ書けばいい」という選別ができず、決定事項は全部書く、という雑な運用になっています。
選別できるようになれば、書く量はもっと減らせるはずです。

効果を数字では言えません。
測っていないからです。
言えるのは、同じことを打ち直す回数が減った、という体感までになります。
しかも同じ時期に作業の委譲先も増やしているので、ファイル化だけの効果としては切り分けられていません。

まとめ

• 圧縮のあとも作業の幹は残るが、言葉遣いや文章の調子、一時的なルールといった細かい部分は落ちる

• 自動で挟まる分は残すものを指定できない（手動の `/compact` なら引数で優先順を添えられる）

• モデル側は圧縮の発生を検出できないので、「圧縮されたらメモを読み直す」のような条件付きルールは書けない

• 会話で決めたことは消えると元の文言が残らないが、ファイルに書いたことは読ませ直せばそのまま戻る

• 恒久ルールは `CLAUDE.md`、進行中の決定事項は `NOTES.md`、調査結果はレポートファイルに分ける

• 復唱させるときは、会話に出していない一行が返ってくるかで、実際に読んだかを確かめる

• 先に `/context`・`/clear`・手動の `/compact` で足りないかを見てから、ファイル運用に進む

次の一手としては、いま動いているプロジェクトに `NOTES.md` を1枚作って、上の雛形を貼り、今日決めたことを3行だけ書いてみてください。
次に圧縮が入ったとき、その3行を復唱させるところから再開できます。

宣伝：デスクトップを「壁紙だけ」にする猫ランチャーを作りました

最後にひとつだけ宣伝です。

散らかったデスクトップのアイコンをまるごとあずけて、画面を壁紙だけにするWindows用ランチャー「NyanDeck」をBOOTHで公開しています。
配信や画面共有でデスクトップが映る事故を防ぎたい人向けに作ったもので、ワンクリックで中身を隠す目隠しモードや、画面の端に格納してホバーで呼び出す機能があります。

無料版だけでも普通に使えるので、デスクトップが散らかっている自覚のある方はどうぞ。

どういうツールかは紹介記事にまとめています。

ダウンロードはこちらから。

この記事が参考になったら、ぜひ「スキ」をお願いします。

あわせて読みたい

圧縮が入る前の段階での劣化と、その対処はこちらに。

`CLAUDE.md` に何を書き、何を書かないかはこちらに。