コードの自動修正や大規模なリファクタリングをお願いしている最中、Claude Code が突然止まってしまった経験はないだろうか。「try stopping」ボタンが出てループする、途中で応答が来なくなる、ターミナルがフリーズする——こういった状況で多くの開発者が犯す最大のミスは、何も確認せずにもう一度同じタスクをやり直してよいと頼んでしまうことです。
止まった時点で Claude Code がどこまで作業を終えていたかによっては、同じ変更を二重に適用したり、部分的に完成したコードの上に新しい変更が重なったりして、かえって状況が複雑になります。止まった直後に取るべき行動には正しい順序があります。
なぜ Claude Code はタスクの途中で止まるのか
原因によって対処が変わるため、まず状況を切り分けることが大切です。主なパターンは4つあります。
コンテキストウィンドウの枯渇: 会話履歴とコード変更が積み重なり、扱えるトークン量の上限に達した状態。「continuing...」と表示された後に止まる、あるいは突然応答が途切れる場合はこれが多いです。Claude Code は /compact コマンドでコンテキストを圧縮できるが、それでも長時間の大規模タスクでは上限に当たる。
レート制限: API 経由で使っている場合や Max プランで集中的に作業している場合に発生します。エラーメッセージに「429」や「overloaded」が含まれていればこれ。数分待てば回復することが多いです。
ツール実行の失敗: Bash ツールでコマンドがタイムアウトした、権限エラーが出た、あるいは無限ループするスクリプトを呼んでしまった場合。Claude Code がツール結果を受け取れずにハングします。
ネットワーク切断: VPN の再接続やスリープからの復帰後に接続が切れているケース。この場合は Claude Code を再起動すれば解決します。
原因に関わらず、最初にやることは共通しています。
ステップ1：止まった直後に git status を確認する
Claude Code が停止したら、まず何も操作せずに ターミナルを開いて以下を実行します。
# 変更されたファイルの一覧を確認
git status
# 期待する出力例（変更が途中まで行われていた場合）
# On branch feature/refactor-auth
# Changes not staged for commit:
# modified: src/auth/login.ts
# modified: src/auth/session.ts
#
# Untracked files:
# src/auth/types.tsこの出力だけで「Claude Code がどこまで手をつけたか」がわかる。変更されたファイルが git status に出ていれば、それらへの書き込みは完了しています。逆に nothing to commit であれば、Claude Code はまだ変更を開始する前に止まったか、またはスクラッチからやり直しても安全という意味です。
重要なのは、git status を確認する前に Claude Code を再起動しないこと。再起動すると会話履歴が消え、「どこまで依頼したか」の文脈を失ってしまう。
ステップ2：git diff で何が完了しているかを把握する
変更ファイルが確認できたら、次は中身を見ます。
# ステージング前の変更内容をすべて表示
git diff
# 特定のファイルだけ確認したい場合
git diff src/auth/login.tsgit diff の出力を眺めて、以下を判断します。
- 変更は論理的にまとまっているか（完結しているように見えるか）
- 途中で切れているコードブロックや、閉じられていない関数がないか
- 変更前の状態（
-行）と変更後の状態（+行）は整合しているか
コンパイルエラーや明らかなシンタックスエラーがある場合は、Claude Code が途中で止まったせいで不完全な状態になっている可能性が高いです。
# TypeScript プロジェクトであればコンパイルチェック
npx tsc --noEmit
# Python であれば構文チェック
python -m py_compile src/auth/login.pyここでエラーが出なければ「途中で止まったが、完了した範囲は正常」と判断できます。
ステップ3：状態によって再開パターンを選ぶ
状況確認が終わったら、3つのパターンのどれで再開するかを決める。
パターンA：変更が途中で止まっており、不完全な場合
まず変更を安全な状態に戻す。
# 変更を破棄して元の状態に戻す（git管理下のファイルのみ）
git checkout .
# 追跡されていない新規ファイルも削除する場合
git clean -fdクリーンな状態に戻してから、Claude Code を再起動して同じタスクを依頼します。ただし今度は「大きなタスクを小さく分割して依頼する」という後述の方法を使います。
パターンB：変更は完了しているが、Claude Code がその後の作業（テスト実行など）で止まった場合
変更はそのままにして、「ここまでは完了しています。次のステップ（テストの実行）から再開してください」と文脈を与えて再依頼します。
# 現在の変更内容をワークインプログレスコミットとして保存
git add -A
git commit -m "WIP: auth refactor (partial - session.ts remaining)"コミットしておくことで、再開後に Claude Code がさらに変更を加えても履歴が追いやすくなります。
パターンC：変更は完全に完了しているが、最後の応答が来なかった場合
テスト結果の確認やコードレビューのフィードバックをもらおうとした時に止まったケース。変更自体は問題ないため、そのまま変更をコミットして次のステップに進んでよい。
ステップ4：/compact コマンドで長いセッションを管理する
コンテキスト枯渇が原因で止まる場合は、長いタスクに入る前に /compact を使えば発生頻度を下げられます。
# Claude Code のチャット欄で実行
/compact
/compact は現在の会話履歴を要約して圧縮し、利用可能なコンテキスト容量を回復させる。完全にリセットするわけではなく、作業状態の要約は維持されるため、途中で呼んでも作業の文脈が消えることはありません。
目安として、会話が30〜40往復を超えてきたと感じたら、次の大きなサブタスクに移る前に /compact を挟む習慣をつけると止まる頻度が下がる。
また、コンテキストの消費を抑えるには、Claude Code に「変更したファイルの diff のみ出力する」「確認を省略して変更のみ適用する」といった指示をするのも有効です。
# 余分な説明を省いてコンテキストを節約する指示の例
「変更内容の説明は不要です。ファイルを直接編集してください。完了したらコミットしてください。」
コンテキスト最適化の詳細についてはClaude Code のトークン消費を半分に減らす実践テクニックも参考にしてほしい。
ステップ5：中断を前提にした「チェックポイント作業術」
大規模なタスクは途中で止まることを前提にして、作業を小さな単位に分割して依頼するのが現実的です。
悪い依頼の例（一度に全部頼む）:
「src/ 以下の全コンポーネントを TypeScript の strict モードに対応させ、
テストを書き、CI の設定も更新して、README も修正してください」
良い依頼の例（チェックポイントを挟む）:
ステップ1: 「src/components/ 以下のファイルを strict モード対応にしてください。
完了したらコミットして報告してください」
（完了・確認・コミット）
ステップ2: 「src/pages/ 以下を対応させてください。完了したらコミットしてください」
（完了・確認・コミット）
ステップ3: 「対応完了したコンポーネントのユニットテストを書いてください」
各ステップでコミットを挟むことで、途中で止まっても「どこまで完了したか」が git ログから明確にわかる。また、コミットのタイミングで自分が変更を確認するため、予期しない変更に早期に気づける。
個人的には「1タスク = 1コミット = 10〜20ファイル以内」を目安にしています。これを超えると止まった後のリカバリーが複雑になります。
ツールのタイムアウトが原因で止まるケースにはClaude Code の Bash ツール実行エラーを解決する完全ガイドも参照してほしい。
全体を振り返って
Claude Code がタスク途中で止まった時のリカバリーは、焦って再実行するより、git status → git diff の順で現在地を把握してから動くのが鉄則です。止まった原因（コンテキスト枯渇・レート制限・ツールエラー・ネットワーク）によって対処も変わるが、変更の状態を確認してから判断するという基本は共通しています。
チェックポイント作業術を習慣にするだけで、途中停止への耐性が格段に上がる。止まることを「失敗」ではなく「作業の区切り」として受け入れる設計で Claude Code を使いこなしてほしい。