放置4時間55分のインフラ構築と、Mac mini 24hランナーの3日間暗転——長時間ループ型エージェント運転の設計メモ

2026年6月、YouTubeで「Claude Codeを5時間放置｜AIに自律でインフラを作らせる時代」という動画が話題になりました。Claude Codeが約4時間55分かけてNested Hyper-Vラボを完全に自律構築したという実績です。著者（ITPRODX運営者）も同じくMac mini上でlaunchd 15分間隔の24時間ランナーを運用していますが、2026年8月15〜17日に3日間成果物ゼロという暗転を経験しました。その原因は「AIが無能だから」ではなく、実行エンジンの配線ミスとCLIへのプロンプト渡し方が原因だったという、泥臭い実測ログを著者が公開しています。

ここが業界的に重要なポイントです。長時間ループが「回る」のはエージェントが賢いからではなく、「同じ操作を繰り返しても壊れない中間ゲート」があるからです。hyperv-nestlabの事例では、L0からL1からL2からADといった各チェックポイント（中間状態）がREADMEに明示されており、どこかで失敗してもそこから再開できる仕組みが用意されています。著者の失敗は、Codexの使用量上限が起爆剤になり、朝便ランナーはCursorに切り替わったのに、24時間ランナーはCodex固定のままだったこと。結果、8月17日だけでrunner invocationが113回なのに成果物ゼロという「動いているつもり」の地獄に陥りました。さらに別系統では、cursor-agent -pへstdinパイプでプロンプトを渡していたため「Error: No prompt provided for print mode」で即終了、exit=0で終わるためwatchdogからは「成功した」と誤認されていました。

長時間ループを本番運転に載せるなら、モデル選びより先にエンジン統一・プロンプト渡し方法・成果物ベースの成功判定を固めることが先です。「INVOCATION数」と「成果物本数」を日次で並べて見ることで、こうした「見えない失敗」を早期に捕捉できます。プロセスの可視化がなければ、いくら出色のAIモデルを使っていても、実装の隅々で失敗を重ねることになります。