コーディングエージェントを使っていて「同じスレッドで指示し続けるか? それとも新しくスレッドを立て直すか?」で迷われた方いらっしゃると思います。

「いや、完成するまでずっと同じスレッドだよ」「いや、1タスク1スレッドだよ」という方もいらっしゃるかもしれませんが・・・

同じスレッドで粘ると、トークンを食うし、コンテキスト圧縮や Lost in the Middle で精度がジワジワ落ちていく気がする。
かといって新規スレッドにすると、今度は文脈をまた一から作り直す&AIが理解しなおすことになりトークン消費やコンテキスト構築のコストがある気がする。

……どっちもデメリットがあるように見えて、判断に困りませんか？困ってませんかそうですか・・・

この記事は、その判断軸を整理したものです。

3行で

判断は1つの問いに集約できる：いま積み上がっている文脈は、次の指示にとって資産か、それとも負債か
トークン量そのものより「負債化のサイン」（却下済みの方針の再提案、パターン崩れ等）を見る。サインが出る前に先回りで圧縮 or 立て直す
状態をファイルに外出ししておくと、立て直しコスト自体が下がり、「粘るしかない」状況を減らせる

まずは論点の整理

判断の前に、この話に出てくる用語を一言ずつ整理しておきます。なんとなく雰囲気で使われがちですが、指している現象は別物です。

コンテキストウィンドウ … モデルが一度に読める入力量の上限。会話履歴・指示・読み込んだファイルなどが全部ここに乗る。Claude Code は現在1Mトークン¹。
トークンの限界 … そのウィンドウを使い切ること。超えそうになると、後述の圧縮が走るか、古い情報が押し出される。
context rot（コンテキストの腐敗） … ウィンドウが大きくても、埋まってくるほど精度がジワジワ落ちる 現象。容量を増やしても消えない¹。
Lost in the Middle … 長い文脈では、真ん中あたりの情報が無視されやすい（先頭と末尾は拾われやすい）という、LLM特有のクセ。
コンテキスト圧縮（compaction） … 会話履歴を要約に置き換えて、消費トークンを減らす操作。Claude Code では /compact。要約なので細かいニュアンスは落ちる（ここがデグレの種になる）。
コンテキスト隔離 … サブエージェントなどに別ウィンドウで作業させ、結果だけ本体に返すことで、本体の文脈を汚さないやり方。

ざっくり言うと、「埋まりすぎると精度が落ちる（rot / Lost in the Middle）」「減らそうとすると圧縮でニュアンスが落ちる」 という、どっちに転んでもじわじわ劣化する構造があるわけです。だからこそ「いつ切るか」の判断が効いてきます。

なお、新しくスレッドを立て直すと「コードを理解し直す」コストが気になりますが、エージェントはコードベースを全部読み直すわけではなく、必要な箇所だけ拾い直す ので、消費は多少にとどまります。この仕組みはこちらの記事に記載しています → https://qiita.com/hokutoh/items/cb6344af8c76b2672338

その文脈は「資産」か「負債」か

判断は結局、この1つの問いに集約できます。

いま積み上がっている文脈は、次の指示にとって資産か、それとも負債か。

新しいスレッドにして失われるのは、これまでに読んだファイルの中身・下した設計判断・「このプロジェクトはこういうクセだな」という学習・「approach A は X の理由でダメだった」という試行錯誤の履歴、といった 積み上げた文脈 です。これが次の指示にとってプラスに働くのかマイナスに働くのかが、分かれ目になります。

Anthropic 自身もセッション管理のガイドで、各ターンは分岐点であり、悪いセッションの多くはモデルが弱いからではなく 誤った文脈を長く引きずりすぎる ことで起きる、と整理しています¹。

資産 … 次の指示が、いま開いているファイル・進めている機能の延長線上にある。文脈を持っていることで再取得が省け、判断もブレない。→ 続ける
負債 … 話題が総入れ替えになる、あるいは文脈が古い前提・却下済みの方針で汚れている。持っているほど精度を下げる。→ 立て直す

「トークンがもったいないから続ける」でも「なんとなく不安だから毎回立て直す」でもなく、文脈の符号（プラスかマイナスか）で決める のがポイントです。

判断の指標

とはいえ「資産か負債か」だけだと抽象的なので、実地で使える指標に落とします。

1. タスクの連続性

次の指示が、直前の作業の延長かどうか。

同じ機能・同じファイル群をいじり続ける → 続ける
バックエンドからまったく無関係なフロント機能へ、のように話題が総入れ替え → 立て直す

2. コンテキスト使用率

Claude Code は1Mトークンの大きなウィンドウを持ちますが、前述のとおり 容量が増えても context rot は消えません¹。Lost in the Middle や圧縮による精度低下は、まさにこの「埋まりすぎ」で出てきます。

コミュニティではおおむね、自動圧縮が走る約80%より手前、60%あたりを目安に先回りして圧縮する のが良いと言われています²。「限界まで使ってから考える」だと、いちばん精度が落ちたタイミングで圧縮が走る、という最悪パターンになりがちです。

3. 劣化のサイン（これが一番わかりやすい）

数字を見るより、出力の挙動を見るほうが実地では確実です。以下が出たら、文脈はすでに負債化しています³。

同じ質問への答えが、セッション内で微妙にブレる
整理済みのはずのファイル構成を間違える
30分前に却下した方針を、また提案してくる
確立したパターン（命名規則、エラーハンドリングの書き方など）を破り始める
全体のゴールを見失って、目の前の局所最適だけを直そうとする

こうなったら、粘らず切る合図です。

二択を緩める：状態をファイルに外出しする

そもそも「続けるか立て直すか」で悩むのは、文脈が会話履歴の中にしか存在しない からです。立て直す＝その文脈を全部失う、という前提だから怖い。

逆に言えば、重要な状態を ファイルに外出し しておけば、新規スレッドでも会話履歴に頼らず安く文脈を再構築できます。

CLAUDE.md … プロジェクトの前提・規約・ディレクトリ構成
SPEC.md などの仕様ドキュメント … 何を作るか
進捗メモ／チェックポイント … いまどこまで進んだか、何を試して何がダメだったか

これでドキュメント側の文脈は外に出せました。ただ、外出しすべき文脈はもう一種類あります。コードの構造そのもの です。

疎結合なコードは「切りやすい」コード

別スレッドに分けた際にコストが懸念されるのは、結局 次のタスクを進めるのに、どれだけの範囲のコードを読み直さないといけないか です。ということは、コードがどう書かれているかが、そのまま立て直しコストを左右します。

AIエージェントがコードを再理解する方法はエージェント等によって異なりますがClaude Code等はベテランエンジニアと同じくGrep等であたりをつける形です。

AIエージェントを使ってコーディングしたとしても指示によっては1ファイルで作ってくることもあります。そこから追加指示で成長させていってもそのファイルに注ぎ足し注ぎ足しの秘伝のタレ化することもあります。
必然、別スレッドのAIからしてみるとベテランエンジニアと同じ叫びをしたくなるわけです。「なんだよこの汚ったねぇコードは！！」と。

疎結合・モジュール化されている … ある変更の影響範囲がそのモジュール内で閉じる。エージェントが拾い直すべきファイルが少なくて済む → 切っても安い
密結合 … 1か所いじるのに芋づる式で関連ファイルを読む羽目になる。新スレッドでの再取得コストが跳ね上がる → 切りづらい

つまり 疎結合の度合いが、そのまま「スレッドを切る安さ」になる わけです。

さらに、関数分け・クラス分けと素直な命名は、エージェントの検索（grep等）の効きにも直結します。きれいに分かれていれば検索が一発で当たりますが、巨大な関数に処理が詰まっていると、「ファイルは見つかったが、その中のどこが該当箇所か」をLLMが読み解く必要があり、これがトークンと精度の両方を食います。良い構造は、再取得を"安く・正確に"する という二重の効きがあるんですね。

言い換えると、

コードの状態	新スレッドでの立ち上がり
疎結合・適切に関数/クラス分割・素直な命名	関係する数ファイルだけ拾えば再開できる。切りやすい
密結合・巨大関数・暗黙の依存	影響範囲が読めず広く読み直しが必要。切りにくい

ここまで来ると、「いつ切るか」の前段に「そもそも切りやすいコードにしておく」という設計の話が効いてくるのが見えてきます。CLAUDE.md のような外部メモが"明示的に書いた文脈"だとすれば、疎結合なコード構造は"コード自体が体現している文脈"です。どちらも、会話履歴に頼らず新スレッドを安く立ち上げるための備えになります。

なお、これはコーディングエージェントのための特殊な工夫というより、人間にとって読みやすい・保守しやすいコードの条件とほぼ一致します。人間が読みやすいコードは、AIにとっても拾いやすい。 良い設計の効きどころが一つ増えた、くらいに捉えるのがちょうどいい気がします。

CLAUDE.md や copilot-instructions.md 等に、あらかじめ疎結合を促す方針を入れておくのが良いと思います。たとえば「1ファイルにまとめず責務ごとに分割する」「既存モジュールの境界を尊重する」のような一文を書いておくと、新規生成のたびに疎結合が効いてきます。

実際の選択肢は二択ではない

「続ける／立て直す」の間にも手段があります。状態の価値で使い分けます。

状況	取るべき手	補足
文脈に正の価値が残っている	手動 `/compact`	自動圧縮任せより、余裕があるうちに「何を残すか」指示して圧縮するほうが質が高い⁴
文脈が汚れている／話題が総入れ替え	`/clear` or 新規スレッド	丸腰で始めず、後述のブリーフを貼る
直前のミスをやり直したいだけ	`/rewind`	そのターンまで巻き戻す
読み込み中心の調査	サブエージェントに委譲	本体スレッドを汚さず、結果だけ受け取る

/clear や新規スレッドで立て直すときのコツは、いきなり本題に入らず、3〜5行のブリーフを最初の一通に貼る ことです⁵。

- 何を作っているか：認証ミドルウェアのリファクタ
- 制約：既存のJWT実装は変えない
- 関係するファイル：auth/middleware.go, auth/token.go
- 既にわかっていること：approach Y は X の理由でダメだった

このブリーフ1枚のほうが、ぐちゃぐちゃになった40メッセージ分の履歴より価値がある、というのは実感としてもよくわかります。

まとめ

同じスレッドで粘るか新しく立てるかは、文脈が資産か負債か で決める（トークン量そのものではない）
負債化のサイン（却下済みの方針の再提案、パターン崩れ等）が出る前に、先回りで圧縮 or 立て直す
状態をファイルに外出ししておけば、立て直しコスト自体が下がり、「粘るしかない」状況を減らせる
さらに 疎結合・モジュール化されたコードは"切りやすい"。良い設計は再取得を安く・正確にする
立て直すときは丸腰で始めず、3〜5行のブリーフを最初の一通に貼る

Anthropic. Using Claude Code: session management and 1M context. https://claude.com/blog/using-claude-code-session-management-and-1m-context ↩ ↩² ↩³ ↩⁴
Claude Code Context Management Guide. https://www.sitepoint.com/claude-code-context-management/ ↩
Claude Code compact command & context management. https://www.mindstudio.ai/blog/claude-code-compact-command-context-management ↩
同上。手動圧縮はまだ余裕があるうちに走るため、モデルが会話全体を鮮明に覚えており、要約の質が高い。 ↩
Claude Code Context Management: /clear, /compact. https://blink.new/blog/claude-code-context-management ↩