Claude Code の ENOSPC エラーを根本から片付ける

ENOSPC が出た瞬間、手元で何が起きているのか

ある朝、私が回している自動更新のスケジュールタスクが途中で沈黙していました。ログには bash がコマンドに応答しなくなった記録だけが残り、その少し前に短く ENOSPC の文字。2026年4月15日のことです。

ENOSPC は「No space left on device」の略で、ディスクに書き込める空きブロックがゼロになったことを意味します。私のケースの直接の犯人は、パイプラインの途中で走らせていた npm install でした。4つの技術ブログを並行更新するなかで、複数リポジトリの node_modules が VM の約10GB を静かに埋め尽くし、ある一回でとうとう閾値を越えたのです。

Error: ENOSPC: no space left on device, write
  at Object.writeFileSync (fs.js:1234:15)
  at /workspace/debug.log

このエラーが厄介なのは、出た瞬間にすべてが固まることです。ログも書けない、ファイルも保存できない、当然 git commit も通らない。じわじわ溜まったものが、ある一瞬で壁になる——ディスクの問題はいつもこの形でやってきます。

なぜ満杯になるのか — 詰まりどころは大きく3つ

私が実際に踏んだ順に挙げます。

1. ビルド成果物とパッケージキャッシュの蓄積 これが私の事例の本丸でした。node_modules は1リポジトリで 500MB を超えることも珍しくなく、.next などのビルドキャッシュも繰り返し生成されて残り続けます。複数プロジェクトを行き来していると、削除されないままどんどん積み上がります。

2. デバッグログの暴走 Python や JavaScript のループの中に出力文が一つ紛れ込んでいると、数百万回まわった時点で数GBに達します。while True: の中の print は、想像よりずっと早くディスクを食いつぶします。

3. 一時ファイルの置き去り /tmp に前回の実行で作ったファイルが残り続けるパターンです。一つひとつは小さくても、走らせる回数が多いと地味に効いてきます。

まず、容量の出どころを掴む

復旧の前に、どこが膨れているのかを把握します。当て推量で消し始めると、消してはいけないものまで巻き込みます。

df -h
du -sh ~/* 2>/dev/null | sort -rh | head -10

df -h で使用率が90%を超えていれば逼迫しています。du の上位に node_modules や .next、巨大な .log が並んでいれば、それが今回の主因です。私の場合は他サイトの作業リポジトリが上位を占めていました。

詰まったときの、その場の手順

ステップ1: 一度落として再起動する Cowork や Claude Code を完全に終了し、数秒おいて立ち上げ直します。メモリ上に抱えていた一時ファイルが解放され、これだけで戻るケースもあります。

ステップ2: 容量を食っている実体を消す

# 1GB超のファイルを洗い出す
find ~ -type f -size +1G 2>/dev/null
# 古いログとビルドキャッシュを掃除
find ~ -name "*.log" -mtime +30 -delete 2>/dev/null
find ~ -type d -name "node_modules" -prune -exec du -sh {} + 2>/dev/null
find ~ -type d -name ".next" -exec rm -rf {} + 2>/dev/null

ここで注意したいのは、ステップ2で安易に npm install をやり直さないことです。満杯の原因がパッケージキャッシュなら、入れ直しは火に油を注ぐだけになります。私が同じ轍を踏んだのもこの点でした。

ステップ3: キャッシュをまとめて落とす

npm cache clean --force
rm -rf ~/.cowork/cache

ステップ4: それでも戻らないとき メニューの Cowork → Reset App Data でアプリ側のデータをリセットします（プロジェクトファイルは保護されます）。ここまでやっても解決しない場合は、使用率・エラーメッセージ・発生時刻を添えて Anthropic サポート（support@anthropic.com）に連絡するのが確実です。

二度と詰まらせない — 私がパイプラインに入れた3つの設計

その場しのぎの掃除より、構造側で詰まらせない仕組みを作るほうが、長い目で見て圧倒的に楽でした。両家の祖父がともに宮大工で、組み上げたものを何十年も手入れしながら持たせる姿を近くで見て育ったせいか、私はこういう「溜めない設計」に手をかけるのが性に合っています。

設計1: そもそも npm install をパイプラインから外した 記事を追加するだけなら、リポジトリを取得して MDX を書いて push するだけで足ります。ビルドは Cloudflare 側の CI に任せられるので、VM 上で node_modules を作る必要は実はありませんでした。これだけで disk 逼迫の最大要因が消えました。「やらない」が一番効く対策だったのは、少し皮肉でもあります。

設計2: 空き容量が閾値を割ったら自動で解放する 作業前に空きを測り、500MB を切っていたら他サイトの作業リポジトリ → npm のビルドキャッシュ → グローバルキャッシュの順に自動で削っていく処理を頭に入れました。

FREE_MB=$(df ~ --output=avail -m 2>/dev/null | tail -1 | tr -d ' ')
if [ "${FREE_MB:-0}" -lt 500 ]; then
  for OTHER in ~/repos/*; do
    [ "$OTHER" != "$WORK" ] && rm -rf "$OTHER" 2>/dev/null
  done
  npm cache clean --force 2>/dev/null
fi

設計3: 書き込めない場所に逃げ道を作る /tmp が別ユーザー所有で書き込めない環境にぶつかったときは、$HOME/repos にフォールバックするようにしました。詰まりそのものではありませんが、ENOSPC の復旧中に「書ける場所がない」で二重に詰まるのを防げます。

次の一手

いま手元の環境で df -h を一度だけ叩いてみてください。使用率が50%を超えているなら、du -sh ~/* | sort -rh | head で上位を眺め、不要な node_modules か古いログを一つ消しておく。それだけで、忙しい日に作業が固まる確率はぐっと下がります。私自身、月曜の朝にこの一行を打つのを習慣にしてから、ENOSPC でのやり直しはほぼなくなりました。