VS CodeとClaude Codeで、AIに24時間開発を回させていたところ、朝起きるとAIが止まっていたり、ディスクの容量が足りなくなっていたりしました。この記事では、その2つの失敗の原因と、私が行った対処を、用語の解説つきで紹介します。
この記事で分かること
- AI駆動開発で、サブエージェントが黙って止まる原因と、止まったことに気づくための仕組み
- WSL 2のディスクが、ファイルを消しても小さくならない理由と、そこで起きたこと
- AIを24時間回すときに、先に考えておきたいこと
用語メモ: AI駆動開発 設計や実装などの作業を、AIに任せながら進める開発の方法です。
私の開発環境
普段は、Windows 11の上にWSL 2でUbuntuを入れ、その中でDocker CEを動かしています。アプリのサーバーやデータベースは、コンテナごとに分けて(サンドボックス化して)起動し、動作を確認しています。
用語メモ
- WSL 2(Windows Subsystem for Linux 2): Windowsの中で、Linuxを動かすための機能です。
- Ubuntu: Linuxの種類(ディストリビューション)の一つです。
- Docker CE(Community Edition): Linux向けの、コンテナを動かすための無料版のDockerです。
- コンテナ: アプリを、必要な部品ごとまとめて隔離して動かす仕組みです。
- サンドボックス: 他の環境に影響が出ないように、隔離した安全な実行環境のことです。
マシンのスペックは、次のとおりです。
| 項目 | 内容 |
|---|---|
| OS | Windows 11 Pro |
| メモリ(RAM) | 64GB |
| CPU | AMD Ryzen A |
| SSD | 512GB |
開発では、VS CodeとClaude Codeを組み合わせた構成で進めています。私の使い方では、トークンあたりのコストパフォーマンスは、今のところClaude Codeが一番よいと感じています。定額のサブスクリプションで使えるので、長時間動かしても、費用が読みやすい点も気に入っています。
用語メモ: トークン AIが読み書きする文章の量を測る単位です。使った量に応じて費用がかかる方式では、長時間使うほど費用が増えます。
そこで、定額のサブスクリプションで使えるClaude Codeに切り替えました。
こうした環境で、24時間、開発を回し続けるパイプライン(作業の流れ)を作り、Claude Codeに作業させていました。夜に作業の様子を見届けてから寝ると、朝には止まっている、ということが起きました。
困ったこと1: サブエージェントが黙って停止して、全体が待ったままになる
最初の問題は、サブエージェントが、何も報告しないまま止まってしまうことでした。すると、全体を指揮しているオーケストレーターは、応答を待ち続けてしまいます。
用語メモ
- オーケストレーター: 複数のAI(エージェント)に作業を割り振り、進み具合をまとめて管理する、指揮役のエージェントです。
- サブエージェント: 指揮役から作業を任される、個別の作業担当のエージェントです。
オーケストレーション担当のエージェントに確認すると、「気づけませんでした」と謝ってきます。再発防止として、AGENTS.mdなどに「忘れないように」と書かせても、また忘れてしまいます。原因は、コンテキストウィンドウの問題で、話が飛んでしまうからです。私は、休ませずに24時間稼働させる、かなりハードな使い方をしているので、この問題が起きやすいのだと思います。
用語メモ
- AGENTS.md / CLAUDE.md: AIに守らせたいルールや手順を書いておく、指示用のファイルです。
- コンテキストウィンドウ: AIが一度に覚えておける、文章の範囲のことです。人間でいえば、一時的な記憶に近いものです。長時間の作業では、古い内容が押し出されて、忘れてしまいます。
解決方法: 「落ちないようにする」のではなく「落ちても気づく」ようにする
私が選んだ解決方法は、黙って落ちないようにするのではなく、黙って落ちても気づけるようにすることでした。ハートビートを設置して、毎回、状況を確認させるようにしたのです。
用語メモ: ハートビート 「動いています」という合図を、一定の間隔で出し続ける仕組みです。合図が途切れたら、止まったと判断できます。ちゃんと動いているかを確認する「死活監視」で、よく使われます。
設置方法は、とても簡単です。AIに「ハートビートを5分間隔で設置して、監視させろ」と指示するだけです。すると、決まった時間に自動で動くバッチ処理のように、動いているかどうかを、常に確認できる状態になり、うまく回るようになりました。
用語メモ: バッチ処理 決まった時間や条件で、まとめて自動的に実行される処理のことです。
困ったこと2: WSL 2のディスクが、ファイルを消しても小さくならない
2つ目は、WSL 2の上で動かしているUbuntuのストレージ(保存領域)がいっぱいになり、Windowsのドライブを圧迫したことです。
朝起きて、コンソールを見ると、ストレージの問題で、これ以上作業ができない、というメッセージが出ていました。私が作っているシステムは、大きなデータは扱わないはずだったので、少し予想外で、驚きました。
原因1: Dockerのビルドのたびに、古いイメージが溜まる
Dockerでは、ビルドのたびに、使われなくなった古いイメージが溜まりやすい性質があります。一応、掃除はしていました。
用語メモ
- イメージ: コンテナの元になる、アプリと実行環境をまとめたひな型です。
- ビルド: イメージを作る作業のことです。
原因2: WSLの仮想ディスクは、自動では縮まない
もう一つの原因は、WSLは、一度広がったストレージを、自動では縮めてくれないことでした。WSL 2は、Linuxのデータを、Windows上の「仮想ディスク」という、1つの大きなファイルに保存しています。このファイルは、使うにつれて大きくなりますが、Linuxの中で、ゴミのファイルを削除しても、Windows側のファイルは、自動では小さくなりません。コンソールで操作して縮めない限り、そのままです。これは、どうやら仕様のようです。
これを知らなかったので、原因にたどり着くまでに、少し時間がかかりました。しかも、私の環境では、なぜか、WSLのシャットダウンコマンド(wsl --shutdown)を実行しても、停止してくれませんでした。そのため、毎回、Windows 11を再起動してから、ディスクの縮小(リサイズ)をしなければならず、面倒でした。
補足: Docker Desktopを使っていない理由
Docker Desktopは、一定規模以上の企業では、有料になりました。そのため、仕事では使えず、仕方なく、WSL 2上のDocker CEを使っています。個人のPCでは、無償で使える範囲なので、Docker Desktopを使っています。利用条件は変わることがあるので、公式サイトで、最新の情報を確認してください。
用語メモ: Docker Desktop WindowsやMac向けに、Dockerを、画面付きで簡単に使えるようにしたアプリです。
まとめ
AI駆動開発を、24時間止めずに回していると、人間の作業では起きにくい失敗が出てきます。今回の2つの失敗から、私は、次の3つを学びました。
- AIは、黙って止まることがある。だから、止まっても気づける仕組みを、先に作る。 ハートビートで、動いているかを定期的に確認すると、朝になって初めて気づく、ということがなくなります。
- 「忘れないで」と指示するより、仕組みで補う。 コンテキストウィンドウには限りがあるので、長時間の作業では、指示を書いても忘れてしまいます。
- 長時間動かす環境は、ディスクの容量にも気を配る。 WSL 2の仮想ディスクは、自動では縮まないので、Dockerの掃除に加えて、容量を定期的に確認し、縮小の手順を用意しておくと安心です。
夜に見届けて寝て、朝に止まっていた、という経験から、24時間の体制ほど、「止まったことに気づく仕組み」と「資源の上限を見張ること」が大切だと感じました。